undefined | Better HN

0 pointsfilmor9y ago0 comments

Your first point is incorrect, lambda works with the first syntax for both python 2 and 3. What /has/ changed, however, is the implicit destructuring:

    l = lambda (a, b): a + b
    l((1, 2))

I suspect there are very good reasons not to allow something like this.

With regard to the second point, I also would have liked a more "gradual" step there, I find myself (especially in REPL environments) often doing `list(map(sth, sth))`. A `mapi`, `filteri` or something like this would probably not be zenny enough.

Both don't pose very strong points for python 2 > 3.

0 comments

3 comments · 3 top-level

rhaps0dy9y ago

PEP 3113 -- Removal of Tuple Parameter Unpacking http://legacy.python.org/dev/peps/pep-3113/

These seem like OK reasons, but I find myself continuously needing the destructuring idiom in lambdas, while these introspection and documentation concerns are just not there for me.

However tuple-parameters being an exception to rules (such as args and kwargs not being usable with them) is more compelling. And allowing destructuring only in lambdas would be weird, because they wouldn't be normal function objects any more.

Unless the destructuring was only syntactic sugar for the translation in the PEP? But that's again inconsistent.

Marat_Dukhan9y ago

Yes, lack of implicit tuple unpacking in lambda is what forces me to write `lambda a_b`.

Python 2.7 has imap and ifilter in itertools. Python 3 could have imported them into global namespace to simplify usage without breaking map/filter functions.

xrange9y ago

>I find myself (especially in REPL environments) often doing `list(map(sth, sth))`.

This. I wonder if you could have a switch to make ipython print out the list instead of the iterator object at the REPL.

j / k navigate · click thread line to collapse