map/filter/reduce/lambda opinions and background unscientificmini-survey

[Ron Adam]

File "<stdin>", line 1
(,)
^
SyntaxError: invalid syntax

You've wandered way off into the woods now.

Yes, ummm seems soo... err.

This is one of those Python isn't quite consistent for practical reasons
area. I don't create empty tuples that way very often, but [] is to ()
is to {} is pretty obvious so I don't really have a good excuse.

()

()

Well in my previous explanation I *mean* it to be empty parenthesis.

Does that help?

Cheers,
Ron

 

[Erik Max Francis]

Well in my previous explanation I *mean* it to be empty parenthesis.

Does that help?

Maybe it might be beneficial to learn a little more of the language
before proposing such wide-reaching (and un-Pythonic) reforms?

 

[Ron Adam]

Maybe it might be beneficial to learn a little more of the language
before proposing such wide-reaching (and un-Pythonic) reforms?

Hi Erik,

Getting more sleep is the answer to not making those kinds of oversights
in this case.

It's really was not a (my) proposal, but a suggestion someone else made.
It seemed like an interesting idea and I wanted to see what kind of
problems and benefits it would have. Discussing an idea with other
before it's fully thought out is a good way to explore its possibilities
even though it may mean appearing silly at times, which I don't mind.

In the previous posts I was attempting to show a possible pattern or
logic which doesn't currently correspond to the languages syntax using
parenthesis.

That's as close to an empty parenthesis as Python gets. I was really
trying to explain an underlying concept, not show actual python code.

And the conclusion (opinion) I've come to, is such a change might be
made to work, but it would be very confusing to most people who have
gotten use to the current None usage. And difficult to emplement in a
way that's consistant overall.

An alternative is to use a different word such as 'undefined'. Then
None can be used as it is currently, and undefined, can be used to test
for in a comparison for undefined names. Assigning a name to undefined
could be used as an alternative to delete a name but so far I don't see
an advantage to doing that way over using del.



if name is undefined: do something.

Instead of:

try:
name
except:
do something


And maybe:

name = undefined

can be used in expressions where del name can't?

But so far this doesn't seem useful enough to propose and it would
probably cause more problems (or confusion) than it solves.

Cheers,
Ron

 

[Christopher Subich]

Why would it rule out ()?

Generator expressions. Mind you, Py3k might want to unify generators
and lists in some way anyway, freeing up ().

You need to put a lambda express in ()'s anyways if you want to use it
right away.

print (lambda x,y:x+y)(1,2)

Although print <x+y with (x,y)>(1,2) has natural grouping: the lambda
itself is effectively a single token. I also like the infix style
reminiscent of Python's existing comprehensions.

Hell, call it a 'function comprehension' or 'expression comprehension,'
and we can pretend we invented the damn thing.

My choice:

name = (let x,y return x+y) # easy for beginners to understand
value = name(a,b)

value = (let x,y return x+y)(a,b)

And a zero-argument lambda is (aside from really arcane)?
(let return 2)?

I think the association of (lambda) to [list_comp] is a nice
distinction. Maybe a {dictionary_comp} would make it a complete set. ;-)

Yeah, dictionary comprehensions would be an interesting feature.
Syntax might be a bit unwieldy, though, and I doubt they'd be used often
enough to be worth implementing, but still neat.

 

[Steven Bethard]

I think the association of (lambda) to [list_comp] is a nice
distinction. Maybe a {dictionary_comp} would make it a complete set. ;-)

Yeah, dictionary comprehensions would be an interesting feature.
Syntax might be a bit unwieldy, though, and I doubt they'd be used often
enough to be worth implementing, but still neat.

Dict comprehensions were recently rejected:
http://www.python.org/peps/pep-0274.html
The reason, of course, is that dict comprehensions don't gain you much
at all over the dict() constructor plus a generator expression, e.g.:
dict((i, chr(65+i)) for i in range(4))

STeVe

 

[George Sakkis]

I think the association of (lambda) to [list_comp] is a nice
distinction. Maybe a {dictionary_comp} would make it a complete set. ;-)

Yeah, dictionary comprehensions would be an interesting feature.
Syntax might be a bit unwieldy, though, and I doubt they'd be used often
enough to be worth implementing, but still neat.

Dict comprehensions were recently rejected:
http://www.python.org/peps/pep-0274.html
The reason, of course, is that dict comprehensions don't gain you much
at all over the dict() constructor plus a generator expression, e.g.:
dict((i, chr(65+i)) for i in range(4))

Sure, but the same holds for list comprehensions: list(i*i for i in
xrange(10)). The difference is historic I guess; list comprehensions
preceded generator expressions and so they cannot be removed, at least
not before 3.0. I wonder if they will/should be in the language when
the constraint of backwards compatibility is lifted. IMO they should
not (TIOOWTDI, uniformity among builtin data structures, not
overwhelmingly more useful than set or dict comprehensions), but
there's a long way till that day.

George

 

[Terry Reedy]

Sure, but the same holds for list comprehensions: list(i*i for i in
xrange(10)). The difference is historic I guess; list comprehensions
preceded generator expressions and so they cannot be removed, at least
not before 3.0. I wonder if they will/should be in the language when
the constraint of backwards compatibility is lifted.

Guido has asked himself the same question. Some developers who love l.c.s
are sure they will stay. I am not. I think it might depend on whether
they have any real advantages in the context of the 3.0 engine and design,
which don't exist yet.

IMO they should
not (TIOOWTDI, uniformity among builtin data structures, not
overwhelmingly more useful than set or dict comprehensions), but
there's a long way till that day.

Yes.

Terry J. Reedy