Re: [Python-Dev] The `for y in [x]` idiom in comprehensions
On Feb 22 2018, Serhiy Storchaka wrote: > 1. Inner generator expression: > > result = [y + g(y) for y in (f(x) for x in range(10))] > [...] > > And maybe there are other ways. I think the syntax recently brough up by Nick is still the most beautiful: result = [ (f(x) as y) + g(y) for x in range(10)] ..but I wonder if it is feasible to make the interpreter sufficiently smart to evaluate the first summand before the second. Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The `for y in [x]` idiom in comprehensions
On Sun, Feb 25, 2018 at 11:02 PM, Nikolaus Rath wrote:
> On Feb 22 2018, Serhiy Storchaka wrote:
>> 1. Inner generator expression:
>>
>> result = [y + g(y) for y in (f(x) for x in range(10))]
>>
> [...]
>>
>> And maybe there are other ways.
>
> I think the syntax recently brough up by Nick is still the most
> beautiful:
>
> result = [ (f(x) as y) + g(y) for x in range(10)]
>
> ..but I wonder if it is feasible to make the interpreter sufficiently
> smart to evaluate the first summand before the second.
It already has to. The order of evaluation in Python is well defined,
mostly "left to right". But if you allow this in a comprehension, the
obvious next step will be "do we allow this in ANY expression?", and
the answer has to either be "yes" or "no, because {reasons}" for some
very good value of 'reasons'.
ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The `for y in [x]` idiom in comprehensions
On Feb 25 2018, Chris Angelico wrote: > On Sun, Feb 25, 2018 at 11:02 PM, Nikolaus Rath wrote: >> On Feb 22 2018, Serhiy Storchaka wrote: >>> 1. Inner generator expression: >>> >>> result = [y + g(y) for y in (f(x) for x in range(10))] >>> >> [...] >>> >>> And maybe there are other ways. >> >> I think the syntax recently brough up by Nick is still the most >> beautiful: >> >> result = [ (f(x) as y) + g(y) for x in range(10)] >> >> ..but I wonder if it is feasible to make the interpreter sufficiently >> smart to evaluate the first summand before the second. > > It already has to. The order of evaluation in Python is well defined, > mostly "left to right". Ah, then the problem is how to evaluate result = [ y + g(f(x) as y) for x in range(10)] I don't think there'd be a good reason to allow one but not the other. > But if you allow this in a comprehension, the > obvious next step will be "do we allow this in ANY expression?" Yes, of course. After all, IIRC Nick proposed it to simplify ternary expressions. Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The `for y in [x]` idiom in comprehensions
Le 25/02/2018 à 14:11, Nikolaus Rath a écrit : > On Feb 25 2018, Chris Angelico wrote: >> On Sun, Feb 25, 2018 at 11:02 PM, Nikolaus Rath wrote: >>> On Feb 22 2018, Serhiy Storchaka wrote: 1. Inner generator expression: result = [y + g(y) for y in (f(x) for x in range(10))] >>> [...] And maybe there are other ways. >>> >>> I think the syntax recently brough up by Nick is still the most >>> beautiful: >>> >>> result = [ (f(x) as y) + g(y) for x in range(10)] Honestly I find this version the most readable while the double for loop is completely weird to me, despite doing python for a living for years. I really hope the later doesn't become a common idiom. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The `for y in [x]` idiom in comprehensions
23.02.18 19:30, Guido van Rossum пише: I'm not saying anything new here, but since you asked specifically for my opinion: I don't care for the idiom; it's never occurred to me before, and it smells of cleverness. If I saw it in a code review I would probably ask for a regular for-loop to make the code more maintainable. But if you say it's useful for some class of users and it would be more useful if it was faster, I'm fine with the optimization. The optimization is also clever, and here I appreciate cleverness! Thank you. Given the contradictory relation of other core developers to this idiom, and small total effect of this optimization (since the problem solved by using this idiom is rarely occurred), I'm inclined to defer this optimization on to some time (months or years). Maybe something will be changed during this period: either this idiom will become more popular, or new arguments against using it will be found, or better solution will be found, or this optimization will become the part of more general optimization. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The `for y in [x]` idiom in comprehensions
On Mon, Feb 26, 2018 at 12:11 AM, Nikolaus Rath wrote: > On Feb 25 2018, Chris Angelico wrote: >> On Sun, Feb 25, 2018 at 11:02 PM, Nikolaus Rath wrote: >>> On Feb 22 2018, Serhiy Storchaka wrote: 1. Inner generator expression: result = [y + g(y) for y in (f(x) for x in range(10))] >>> [...] And maybe there are other ways. >>> >>> I think the syntax recently brough up by Nick is still the most >>> beautiful: >>> >>> result = [ (f(x) as y) + g(y) for x in range(10)] >>> >>> ..but I wonder if it is feasible to make the interpreter sufficiently >>> smart to evaluate the first summand before the second. >> >> It already has to. The order of evaluation in Python is well defined, >> mostly "left to right". > > Ah, then the problem is how to evaluate > > result = [ y + g(f(x) as y) for x in range(10)] > That ought to raise UnboundLocalError, since y is evaluated before g's arguments. If you're reusing an expression, it isn't too much hassle to demand that the *first* instance of that expression be the one with the 'as' clause. Generally "first" means "leftmost", with rare exceptions (eg it'd be "y if (expr as y) else y" with the assignment in the middle), so that shouldn't bother most people. >> But if you allow this in a comprehension, the >> obvious next step will be "do we allow this in ANY expression?" > > Yes, of course. After all, IIRC Nick proposed it to simplify ternary > expressions. The trouble with allowing 'expr as name' in any context is that it's pretty much guaranteed to create confusion in a 'with' statement. Compare: with open(fn) as f: with (open(fn) as f): with contextlib.closing(open(fn)) as f: with (contextlib.closing(open(fn)) as f): Do they all do the same thing? Can you see at a glance which one is different, and *how* it's different? And I'm sure there are other situations where it would be similarly confusing, yet still potentially useful. Does this just get filed under "consenting adults"? Speaking as a C programmer who's quite happy to write code like "while ((var = func()) != sentinel)", I wouldn't object to this coming up in Python; the "as name" syntax has the huge advantage over C's syntax in that you can't accidentally leave off one equals sign and get the wrong behaviour. But I know that a lot of people dislike this at a more fundamental level. If someone wants to push for this, I think it probably needs a PEP - it's a point that comes up periodically. I don't think it's ever had a PEP written about it, but it's a bit hard to search for; maybe someone else knows off hand? ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The `for y in [x]` idiom in comprehensions
On Sun, Feb 25, 2018 at 6:36 AM, Serhiy Storchaka wrote: > 23.02.18 19:30, Guido van Rossum пише: > >> I'm not saying anything new here, but since you asked specifically for my >> opinion: I don't care for the idiom; it's never occurred to me before, and >> it smells of cleverness. If I saw it in a code review I would probably ask >> for a regular for-loop to make the code more maintainable. >> >> But if you say it's useful for some class of users and it would be more >> useful if it was faster, I'm fine with the optimization. The optimization >> is also clever, and here I appreciate cleverness! >> > > Thank you. Given the contradictory relation of other core developers to > this idiom, and small total effect of this optimization (since the problem > solved by using this idiom is rarely occurred), I'm inclined to defer this > optimization on to some time (months or years). Maybe something will be > changed during this period: either this idiom will become more popular, or > new arguments against using it will be found, or better solution will be > found, or this optimization will become the part of more general > optimization. > Yeah, it doesn't seem there's any hurry. Opinions on the idiom are definitely, um, divided. :-) FWIW I don't care much about the 'f(x) as y' solution either, and being new syntax it has a much higher bar. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Exhaustively test dataclass hashing when no hash= value is provided. This is in anticipation of changing how non-default hashing is handled. (GH-5834) (GH-5889)
Thanks. Do you know if this gets backported to 3.7? Eric. On 2/25/2018 1:36 PM, Terry Reedy wrote: On 2/25/2018 11:56 AM, Eric V. Smith wrote: + # specify any value in the deecorator). I fixed this through the web interface. The CI now knows that a comment change does not need testing. I could not request a review from ericvsmith though. tjr ___ Python-checkins mailing list python-check...@python.org https://mail.python.org/mailman/listinfo/python-checkins ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 3.7.0b2 code cutoff soon!
Just a reminder that 3.7.0b2 is almost upon us. Please get your feature fixes, bug fixes, and documentation updates in before 2018-02-26 ~23:59 Anywhere on Earth (UTC-12:00). That's a little over 1.5 days from now. Also, as previously noted, for those of you who asked for and received extensions for a few remaining 3.7.0 features, those extensions expire as of the b2 cutoff so please plan accordingly. Looking ahead, we need to start locking down 3.7.0 so that our downstream users, that is, third-party package developers, Python distributors, and end users, can test their code with confidence that the actual release of 3.7.0 will hold no unpleasant surprises. So please assume that the 3.7.0 ABI will be frozen as of beta 3, in 4 weeks on 2018-03-26, and that only doc updates and the kinds of bug fixes appropriate for a maintenance release should be going into the 3.7 branch after 3.7.0b3 without further discussion. Thanks again for all of your hard work towards making 3.7.0 yet another great release! --Ned -- Ned Deily n...@python.org -- [] ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
