[Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
Łukasz Langa
my intuitive objection to the idea before posting anything.
I feel that (name := expression) doesn't fit the narrative of PEP 20. It
doesn't remove complexity, it only moves it. What was its own assignment before
now is part of the logic test. This saves on vertical whitespace but makes
parsing and understanding logic tests harder. This is a bad bargain: logic
tests already contain a lot of complexity that human readers have to cope with.
Proponents of := argue it makes several patterns flatter (= better than nested)
to express. Serial regular expression matching is a popular example. However,
(name := expression) itself is making logic tests more nested, not flatter. It
makes information in the logic test denser (= worse than sparse). Since it also
requires an additional pair of parentheses, it forces the reader to decompose
the expression in their head.
:= also goes against having one obvious way to do it. Since it's an expression,
it can also be placed on its own line or in otherwise weird places like
function call arguments. I anticipate PEP 8 would have to be extended to
explicitly discourage such abuse. Linters would grow rules against it. This is
noise.
I'm -1 on PEP 572, I think it's very similar in spirit to the rejected PEP 463.
-- Ł
Chris Angelico
> := also goes against having one obvious way to do it. Since it's an expression,
> it can also be placed on its own line or in otherwise weird places like
> function call arguments. I anticipate PEP 8 would have to be extended to
> explicitly discourage such abuse. Linters would grow rules against it. This is
> noise.
Does this argument also apply to the if/else expression? Do linters
need rules to advise against people writing code like:
print(x) if x is None else print(y)
? It's perfectly legal to write code like this. But I don't see people
abusing this sort of thing.
ChrisA
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/dev-python%2Bgarchive-30976%40googlegroups.com
Guido van Rossum
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Łukasz Langa
> On 25 Apr, 2018, at 1:28 PM, Guido van Rossum <gu...@python.org> wrote:
>
> You don't seem to grasp the usability improvements this will give. I hear you but at this point appeals to Python's "Zen" don't help you.
This reads dismissive to me. I did read the PEP and followed the discussion on
python-dev. I referred to PEP 20 because it distills what's unique about the
value proposition of Python. It's our shared vocabulary.
Can you address the specific criticism I had? To paraphrase it without PEP 20
jargon:
> (name := expression) makes code less uniform. It inserts more information
> into a place that is already heavily packed with information (logic tests).
-- Ł
Łukasz Langa
> On 25 Apr, 2018, at 1:24 PM, Chris Angelico <ros...@gmail.com> wrote:
>
> On Thu, Apr 26, 2018 at 6:21 AM, Łukasz Langa <luk...@langa.pl> wrote:
>> := also goes against having one obvious way to do it. Since it's an expression,
>> it can also be placed on its own line or in otherwise weird places like
>> function call arguments. I anticipate PEP 8 would have to be extended to
>> explicitly discourage such abuse. Linters would grow rules against it. This is
>> noise.
>
> Does this argument also apply to the if/else expression? Do linters
> need rules to advise against people writing code like:
>
> print(x) if x is None else print(y)
>
> ? It's perfectly legal to write code like this. But I don't see people
> abusing this sort of thing.
from a regular if statement. It's also different from the C equivalent.
`:=` on the other hand is deciptively similar to `=`.
But yeah, I think worrying about abuse of the feature is a red herring. The
gist of my criticism of your PEP is about the decreased balance in information
density.
-- Ł
Tim Peters
>> You don't seem to grasp the usability improvements this will give.
>> I hear you but at this point appeals to Python's "Zen" don't help you.
[Łukasz Langa <luk...@langa.pl>]
> This reads dismissive to me. I did read the PEP and followed the discussion on
> python-dev. I referred to PEP 20 because it distills what's unique about the
> value proposition of Python. It's our shared vocabulary.
>
> Can you address the specific criticism I had? To paraphrase it without PEP 20
> jargon:
> (name := expression) makes code less uniform. It inserts more information
> into a place that is already heavily packed with information (logic tests).
I'll take a crack at that. It's not about "head arguments" at all. I
sat out the first hundred messages about this on python-ideas, and
looked at code instead. What I found had little to do with any of the
head (abstract) arguments passionately debated for the duration ;-)
In real life, I found a great many conditional tests that not only
weren't "heavily packed" with information, they were simply of the
form:
NAME = expression
if NAME:
... use NAME ...
That looks more like assembly language than Python ;-) I saw no harm
at all, and a little gain, in
if NAME := expression:
... use NAME ...
instead. But even a little gain adds up when it happens so often.
Of course there have been better examples given of bigger gains. But
in no case have the tests in those examples been "heavily packed with
information". If they had been, I would have suggested instead
breaking the test clauses _out_ of the conditional statements, and
giving them names each on their own dedicated lines, with comments
explaining what the heck the _intents_ are, even at the cost of adding
an indentation level or two. Sometimes conditionals are _already_ "too
dense". But more often they're very sparse.
This becomes a question of seasoned judgment. For example, here's a
real loop summing a series expansion, until the new terms become so
small they make no difference to the running total (a common enough
pattern in code slinging floats or decimals):
while True:
old = total
total += term
if old == total:
return total
term *= mx2 / (i*(i+1))
i += 2
To my eyes, this is genuinely harder to follow, despite its relative brevity:
while total != (total := total + term):
term *= mx2 / (i*(i+1))
i += 2
return total
So I wouldn't use binding expressions in that case. I don't have a
compelling head argument for _why_ I find the latter spelling harder
to follow, but I don't need a theory to know that I in fact do.
But neither do I need a compelling head argument for "why" to know
that in many other cases I find that the use of binding expressions
improves the code. You shouldn't believe me even if I pretended to
have one and passionately argued for it. But, by the same token, I'm
spectacularly unmoved by other peoples' head arguments.
For that reason, the messages that sway me are those showing real
code, or at least plausibly realistic code. In the majority of those
so far, binding expressions would be a small-to-major win.
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/dev-python%2Bgarchive-30976%40googlegroups.com
Guido van Rossum
> On 25 Apr, 2018, at 1:28 PM, Guido van Rossum <gu...@python.org> wrote:
>
> You don't seem to grasp the usability improvements this will give. I hear you but at this point appeals to Python's "Zen" don't help you.
This reads dismissive to me. I did read the PEP and followed the discussion on
python-dev.
And that's how big decisions get made. Nobody can predict the outcome with sufficient accuracy. It's like buying a new car or house. In the end you decide with your gut.
I referred to PEP 20 because it distills what's unique about the
value proposition of Python. It's our shared vocabulary.
Can you address the specific criticism I had? To paraphrase it without PEP 20
jargon:
> (name := expression) makes code less uniform. It inserts more information
> into a place that is already heavily packed with information (logic tests).
Antoine Pitrou
Tim Peters <tim.p...@gmail.com> wrote:
>
> To my eyes, this is genuinely harder to follow, despite its relative brevity:
>
> while total != (total := total + term):
but otherwise?
> For that reason, the messages that sway me are those showing real
> code, or at least plausibly realistic code. In the majority of those
> so far, binding expressions would be a small-to-major win.
expressions wouldn't be a win, but I'm not sure that would be a
constructive use of mailing-list bandwidth.
Regards
Antoine.
Ethan Furman
> This becomes a question of seasoned judgment. For example, here's a
> real loop summing a series expansion, until the new terms become so
> small they make no difference to the running total (a common enough
> pattern in code slinging floats or decimals):
>
> while True:
> old = total
> total += term
> if old == total:
> return total
> term *= mx2 / (i*(i+1))
> i += 2
>
> To my eyes, this is genuinely harder to follow, despite its relative brevity:
>
> while total != (total := total + term):
> term *= mx2 / (i*(i+1))
> i += 2
> return total
>
> So I wouldn't use binding expressions in that case. I don't have a
> compelling head argument for _why_ I find the latter spelling harder
> to follow, but I don't need a theory to know that I in fact do.
while total != (total + term as total):
...
I find still intelligible. (Yes, I know "as" is dead, just wanted to throw that out there.)
--
~Ethan~
Steven D'Aprano
>
> > On 25 Apr, 2018, at 1:28 PM, Guido van Rossum <gu...@python.org> wrote:
> >
> > You don't seem to grasp the usability improvements this will give. I hear you but at this point appeals to Python's "Zen" don't help you.
>
> This reads dismissive to me. I did read the PEP and followed the discussion on
> python-dev. I referred to PEP 20 because it distills what's unique about the
> value proposition of Python. It's our shared vocabulary.
Every programming language has a shared vocabulary. That's hardly unique
to Python.
> Can you address the specific criticism I had? To paraphrase it without PEP 20
> jargon:
>
> > (name := expression) makes code less uniform. It inserts more information
> > into a place that is already heavily packed with information (logic tests).
I'm not Guido, but I'll make an attempt.
I think the comment about "less uniform" isn't meaningful. Uniform in
what way?
I don't even know how to interpret the uniform comment here, unless you
mean to imply that every statement and expression in Python currently
has the same information density, and binding-expressions will violate
that. That's clearly not the case, so I'm left puzzled by what you mean.
As for your observation that binding-expressions don't reduce
complexity, they merely move it, I think you may be right. But
then it is a truism that complexity is never reduced, only moved, so
that's likely to be true for any feature (including existing ones).
Should we move back to assembly language programming because Python
hasn't reduced complexity, only moved it? I don't think so.
Clearly binding-expressions do add a little more complexity to the
language, and they do move code from vertically separated statements to
horizontally laid-out expressions.
But why is this necessarily a bad thing? Exactly the same complaint can
be made about comprehensions, and look at how wildly successful they
have been.
Offset against the increase in horizontal complexity is a corresponding
decrease in vertical complexity, and that's beneficial.
Whatever cost they have has to be offset against the benefits, and I
think the feature will come ahead on the plus side overall. Of course,
like any syntactic feature, it may be abused by those who (by accident
or design) write obfuscated or excessively complex code. We shouldn't
ignore that risk, but nor should we use that as an excuse to dismiss the
feature's benefits.
--
Steve
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/dev-python%2Bgarchive-30976%40googlegroups.com
Tim Peters
>>
>> while total != (total := total + term):
> but otherwise?
work, so trying reading that again? When, e.g., `total` reaches 1.0
and `term` reaches 1e-30, this becomes:
while 1.0 != (total := 1.0 + 1-e30):
which leaves `total` unchanged (1.0 + 1e-30 == 1.0) and then
while 1.0 != 1.0:
causes the loop to exit (`while False:`).
>> For that reason, the messages that sway me are those showing real
>> code, or at least plausibly realistic code. In the majority of those
>> so far, binding expressions would be a small-to-major win.
> I'm sure it's possible to find thousands of line of code where binding
> expressions wouldn't be a win, but I'm not sure that would be a
> constructive use of mailing-list bandwidth.
Note that I managed to move the PEP _away_ from general "assignment
expressions" to the much simpler "binding expressions" precisely _by_
illustrating, via real code, why the generality of the former wasn't
actually useful in any case I looked at. If something is always - or
almost always - useless, that can be shown via considering realistic
code. That was far more productive than endless abstract debates.
Ethan Furman
Chris Angelico
> On Wed, 25 Apr 2018 16:55:43 -0500
> Tim Peters <tim.p...@gmail.com> wrote:
>>
>> To my eyes, this is genuinely harder to follow, despite its relative brevity:
>>
>> while total != (total := total + term):
>
> Does it even work? Perhaps if the goal is to stop when total is NaN,
> but otherwise?
rebinding happens. It's 100% unambiguous to the compiler... but still
pretty unclear to a human. And I think the multiple use of 'total' is
to blame for that. So I agree with Tim that this particular example is
better in longhand.
ChrisA
Guido van Rossum
On 04/25/2018 02:55 PM, Tim Peters wrote:
To my eyes, this is genuinely harder to follow, despite its relative brevity:
while total != (total := total + term):
term *= mx2 / (i*(i+1))
i += 2
return total
So I wouldn't use binding expressions in that case. I don't have a
compelling head argument for _why_ I find the latter spelling harder
to follow, but I don't need a theory to know that I in fact do.
I know why I do: I see "while total != total" and my gears start stripping. On the other hand,
while total != (total + term as total):
...
I find still intelligible. (Yes, I know "as" is dead, just wanted to throw that out there.)
The example is supposed to load the left operand to != on the stack before loading the right operand, but the rule that says the left operand is evaluated before the right operand is much weaker than other evaluation order rules (like the rule stating that the arguments are evaluated before the function is called -- and before you laugh, in Algol-60 that wasn't always the case).
This argument applies regardless of which syntactic form you use, and no matter what we choose, the PEP will have to clarify evaluation order in more cases than the current reference manual. (IIRC Nathaniel brought this up.)
Antoine Pitrou
Chris Angelico <ros...@gmail.com> wrote:
> On Thu, Apr 26, 2018 at 8:08 AM, Antoine Pitrou <soli...@pitrou.net> wrote:
> > On Wed, 25 Apr 2018 16:55:43 -0500
> > Tim Peters <tim.p...@gmail.com> wrote:
> >>
> >> To my eyes, this is genuinely harder to follow, despite its relative brevity:
> >>
> >> while total != (total := total + term):
> >
> > Does it even work? Perhaps if the goal is to stop when total is NaN,
> > but otherwise?
>
> Yes, it does, because the first "total" is looked up before the
> rebinding happens. It's 100% unambiguous to the compiler... but still
> pretty unclear to a human. And I think the multiple use of 'total' is
> to blame for that. So I agree with Tim that this particular example is
> better in longhand.
for the explanation), the shorthand version appears completely bonkers.
Regards
Antoine.
Tim Peters
>>>>
>>>> while total != (total := total + term):
>>> but otherwise?
>> rebinding happens. It's 100% unambiguous to the compiler... but still
>> pretty unclear to a human. And I think the multiple use of 'total' is
>> to blame for that. So I agree with Tim that this particular example is
>> better in longhand.
> for the explanation),
you weren't seeing. Next time explain why you think something is
broken?
> the shorthand version appears completely bonkers.
However, without looking at real code, people are just flat-out
guessing about how bad - or good - things _can_ get, no matter how
confident they sound.
So at least give me credit for presenting the _worst_ brief
binding-expression example you've seen too ;-)
Yury Selivanov
[..]
starting their own thread about how PEP 572 threatens readability or
doesn't reach the bar for new syntax (etc.). These arguments are entirely
emotional and subjective.
we fully explore that path. I don't like ':=' and I thought that using '='
can make the idea more appealing to myself and others. It didn't, sorry if
it caused any distraction. Although adding a new ':=' operator isn't my main
concern.
I think it's a fact that PEP 572 makes Python more complex.
Teaching/learning Python will inevitably become harder, simply because
there's one more concept to learn.
Just yesterday this snippet was used on python-dev to show how great the
new syntax is:
my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf))
To my eye this is an anti-pattern. One line of code was saved, but the
other line becomes less readable. The fact that 'buf' can be used after
that line means that it will be harder for a reader to trace the origin of
the variable, as a top-level "buf = " statement would be more visible.
The PEP lists this example as an improvement:
[(x, y, x/y) for x in input_data if (y := f(x)) > 0]
I'm an experienced Python developer and I can't read/understand this
expression after one read. I have to read it 2-3 times before I trace where
'y' is set and how it's used. Yes, an expanded form would be ~4 lines
long, but it would be simple to read and therefore review, maintain, and
update.
Assignment expressions seem to optimize the *writing code* part, while
making *reading* part of the job harder for some of us. I write a lot of
Python, but I read more code than I write. If the PEP gets accepted I'll
use
the new syntax sparingly, sure. My main concern, though, is that this PEP
will likely make my job as a code maintainer harder in the end, not easier.
I hope I explained my -1 on the PEP without sounding emotional.
Thank you,
Yury
Yury
Python-Dev mailing list
Pytho...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Antoine Pitrou
Tim Peters <tim.p...@gmail.com> wrote:
>
> > the shorthand version appears completely bonkers.
>
> I wouldn't go that far, but I already said I wouldn't write it that way.
>
> However, without looking at real code, people are just flat-out
> guessing about how bad - or good - things _can_ get, no matter how
> confident they sound.
>
> So at least give me credit for presenting the _worst_ brief
> binding-expression example you've seen too ;-)
credits for it :-) But I hope you'll use them responsibly!
Regards
Antoine.
Chris Angelico
<yseliv...@gmail.com> wrote:
> Just yesterday this snippet was used on python-dev to show how great the
> new syntax is:
>
> my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf))
>
> To my eye this is an anti-pattern. One line of code was saved, but the
> other line becomes less readable. The fact that 'buf' can be used after
> that line means that it will be harder for a reader to trace the origin of
> the variable, as a top-level "buf = " statement would be more visible.
elsewhere. Otherwise, the name 'buf' is an implementation detail of
the fact that this function wants both a buffer and a size. Should you
want to expand this out over more lines, you could do this:
template = [None]
buf = template*get_size()
length = len(buf)
my_func(arg, buffer=buf, size=length)
What are the names 'template' and 'length' achieving? Why should they
claim your attention? They are useless relics of a done-and-dusted
calculation, being retained for no reason. They do not deserve
top-level placement.
The form as given above is starting to get a bit noisy, but I strongly
disagree that 'buf' deserves to be a stand-alone name. It is as
valueless as 'template' is.
ChrisA
Antoine Pitrou
Chris Angelico <ros...@gmail.com> wrote:
> On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov
> <yseliv...@gmail.com> wrote:
> > Just yesterday this snippet was used on python-dev to show how great the
> > new syntax is:
> >
> > my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf))
> >
> > To my eye this is an anti-pattern. One line of code was saved, but the
> > other line becomes less readable. The fact that 'buf' can be used after
> > that line means that it will be harder for a reader to trace the origin of
> > the variable, as a top-level "buf = " statement would be more visible.
>
> Making 'buf' more visible is ONLY a virtue if it's going to be used
> elsewhere. Otherwise, the name 'buf' is an implementation detail of
> the fact that this function wants both a buffer and a size. Should you
> want to expand this out over more lines, you could do this:
>
> template = [None]
> buf = template*get_size()
> length = len(buf)
> my_func(arg, buffer=buf, size=length)
>
> What are the names 'template' and 'length' achieving? Why should they
> claim your attention?
it claim my attention?
It's not any different: it's just something that's used in a statement
then unnecessary. Yet it will persist until the end of the enclosing
scope, being retained for no reason. Perhaps we need C-like nested
scopes, if such is the concern about names that live for too long?
(of course, the fact that `my_func` needs you to pass its argument's
length as a separate argument, while it could compute it by itself, is
a bit silly)
As a side note, personally, I'm usually much more concerned about the
lifetime of *values* than the lifetime of names. The latter are cheap,
the former can represent expensive resources.
Regards
Antoine.
Yury Selivanov
[..]
> >
> > To my eye this is an anti-pattern. One line of code was saved, but the
> > other line becomes less readable. The fact that 'buf' can be used after
> > that line means that it will be harder for a reader to trace the origin
of
> > the variable, as a top-level "buf = " statement would be more visible.
> Making 'buf' more visible is ONLY a virtue if it's going to be used
> elsewhere. Otherwise, the name 'buf' is an implementation detail of
> the fact that this function wants both a buffer and a size. Should you
> want to expand this out over more lines, you could do this:
poor job at writing it.
My point is that "buf" can still be used below that line, and therefore
sometimes it will be used, as a result of quick refactoring or poor coding
style. It's just how things happen when you write code: it gets rewritten
and parts of it left outdated or not properly revised. *If* "buf" is used
below that line it *will* be harder to find where it was initially set.
Anyways, I don't want to distract everyone further so I'm not interested
in continuing the discussion about what is readable and what is not.
My own opinion on this topic is unlikely to change. I wanted to explain
my -1; hopefully it will be noted.
Yury
Łukasz Langa
On 25 Apr, 2018, at 5:20 PM, Chris Angelico <ros...@gmail.com> wrote:On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov
<yseliv...@gmail.com> wrote:Just yesterday this snippet was used on python-dev to show how great the
new syntax is:
my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf))
To my eye this is an anti-pattern. One line of code was saved, but the
other line becomes less readable. The fact that 'buf' can be used after
that line means that it will be harder for a reader to trace the origin of
the variable, as a top-level "buf = " statement would be more visible.
Making 'buf' more visible is ONLY a virtue if it's going to be used
elsewhere. Otherwise, the name 'buf' is an implementation detail of
the fact that this function wants both a buffer and a size.
Wes Turner
-- Ł
Raymond Hettinger
After re-reading all the proposed code samples, I believe that
adopting the PEP will make the language harder to teach to people
who are not already software engineers. To my eyes, the examples
give ample opportunity for being misunderstood and will create a
need to puzzle-out the intended semantics.
On the plus side, the proposal does address the occasional minor
irritant of writing an assignment on a separate line. On the minus side,
the visual texture of the new code is less appealing. The proposal
also messes with my mental model for the distinction between
expressions and statements.
It probably doesn't matter at this point (minds already seem to be made up),
but put me down for -1. This is a proposal we can all easily live without.
Raymond
Tim Peters
> adopting the PEP will make the language harder to teach to people
> who are not already software engineers.
decades, most of which did have some form of embedded assignment.
Yes, I'm a software engineer, but I've always pitched in on "help
forums" too. One language feature conspicuous by absence in newbie
confusions was, consistently, assignment expressions. Read any book
or tutorial for such a language, and you'll find very little space
devoted to them too.
What's to learn? If they understand "binding a name" _at all_ (which
they must to even begin to write a non-trivial program), the only
twist is that a binding expression returns the value being bound.
Binding expressions certainly wouldn't be the _first_ thing to teach
people. But by the time it would make sense to teach them, it's hard
for me to grasp how a student could struggle with such a tiny
variation on what they've already learned (all the subtleties are in
what - exactly - "binding"means - which they already faced the first
time they saw "j = 1").
> To my eyes, the examples give ample opportunity for being
> misunderstood and will create a need to puzzle-out the intended semantics.
> ...
Łukasz Langa
One language feature conspicuous by absence in newbie
confusions was, consistently, assignment expressions. Read any book
or tutorial for such a language, and you'll find very little space
devoted to them too.
What's to learn? If they understand "binding a name" _at all_ (which
they must to even begin to write a non-trivial program), the only
twist is that a binding expression returns the value being bound.
To my eyes, the examples give ample opportunity for beingmisunderstood and will create a need to puzzle-out the intended semantics.
Some do, many don't.
Greg Ewing
> What was its own assignment before
> now is part of the logic test. This saves on vertical whitespace but makes
> parsing and understanding logic tests harder.
Another way to say this is that expressions are no longer
restricted to being trees, but can be general DAGs, which
require more mental effort to understand.
Hmmm, maybe they should be called "spaghetti expressions". :-)
--
Greg
Steven D'Aprano
> Łukasz Langa wrote:
> >What was its own assignment before
> >now is part of the logic test. This saves on vertical whitespace but makes
> >parsing and understanding logic tests harder.
>
> Another way to say this is that expressions are no longer
> restricted to being trees, but can be general DAGs, which
> require more mental effort to understand.
Is that right? I presume you mean that there can be cycles in
expressions involving binding-expressions. If not, what do you mean?
Can you give an example of a Python expression, involving PEP 572
binding-expressions, that is not a tree but a more general DAG or that
contains cycles?
--
Steve
Chris Angelico
> On Thu, Apr 26, 2018 at 05:22:58PM +1200, Greg Ewing wrote:
>> Łukasz Langa wrote:
>> >What was its own assignment before
>> >now is part of the logic test. This saves on vertical whitespace but makes
>> >parsing and understanding logic tests harder.
>>
>> Another way to say this is that expressions are no longer
>> restricted to being trees, but can be general DAGs, which
>> require more mental effort to understand.
>
> Is that right? I presume you mean that there can be cycles in
> expressions involving binding-expressions. If not, what do you mean?
>
> Can you give an example of a Python expression, involving PEP 572
> binding-expressions, that is not a tree but a more general DAG or that
> contains cycles?
A DAG is a directed *acyclic* graph, so it still can't contain cycles.
But I have no idea what kind of expression isn't a tree as a
consequence of having an assignment in it.
ChrisA
Raymond Hettinger
> On Apr 26, 2018, at 12:40 AM, Tim Peters <tim.p...@gmail.com> wrote:
>
> [Raymond Hettinger <raymond....@gmail.com>]
>> After re-reading all the proposed code samples, I believe that
>> adopting the PEP will make the language harder to teach to people
>> who are not already software engineers.
>
> Can you elaborate on that?
discussion, far more of a source of confusion than the occasional
question of why Python doesn't have embedded assignment.
Also, it is of concern that a number of prominent core dev
respondents to this thread have reported difficulty scanning
the posted code samples.
> I've used dozens of languages over the
> decades, most of which did have some form of embedded assignment.
It has virtues that make it suitable even for elementary school children.
We can show well-written Python code to non-computer folks and walk
them through what it does without their brains melting (something I can't
do with many of the other languages I've used). There is a virtue
in encouraging simple statements that read like English sentences
organized into English-like paragraphs, presenting itself like
"executable pseudocode".
Perl does it or C++ does it is unpersuasive. Its omission from Python
was always something that I thought Guido had left-out on purpose,
intentionally stepping away from constructs that would be of help
in an obfuscated Python contest.
> Yes, I'm a software engineer, but I've always pitched in on "help
> forums" too.
of professionals, almost every week for over six years. That's given
me a keen sense of what is hard to teach. It's okay to not agree
with my assessment, but I would like for fruits of my experience
to not be dismissed in a single wisp of a sentence. Any one feature
in isolation is usually easy to explain, but showing how to combine
them into readable, expressive code is another matter. And as
Yuri aptly noted, we spend more time reading code than writing code.
If some fraction of our users finds the code harder to scan
because the new syntax, then it would be a net loss for the language.
I hesitated to join this thread because you and Guido seemed to be
pushing back so hard against anyone's who design instincts didn't favor
the new syntax. It would be nice to find some common ground and
perhaps stipulate that the grammar would grow in complexity, that a new
operator would add to the current zoo of operators, that the visual texture
of the language would change (and in a way that some including me
do not find pleasing), and that while simplest cases may afford
a small net win, it is a certitude that the syntax will routinely be
pushed beyond our comfort zone.
While the regex conditional example looks like a win, it is very modest win
and IMHO not worth the overall net increase language complexity.
Like Yuri, I'll drop-out now. Hopefully, you all wind find some value
in what I had to contribute to the conversation.
Raymond
Tim Peters
>> One language feature conspicuous by absence in newbie
>> confusions was, consistently, assignment expressions. Read any book
>> or tutorial for such a language, and you'll find very little space
>> devoted to them too.
[Łukasz Langa <luk...@langa.pl>]
> Well, you have an entire code style built around this feature called Yoda
> conditions. You teach people on Day 1 to never ever confuse == with =. Some
> compilers even warn about this because so many people did it wrong.
Sorry, I couldn't follow that. In languages like C that use easily
confused operator symbols, sure, people are forever typing "=" when
they mean "==". That's nothing to do with whether they _understand_
what the different operators do, though. They do. In languages like
Icon (that use "=" for numeric comparison and ":=" for assignment),
that never occurs. But I'm not sure that addressed the point you were
making.
>> What's to learn? If they understand "binding a name" _at all_ (which
>> they must to even begin to write a non-trivial program), the only
>> twist is that a binding expression returns the value being bound.
> Ha, not in Python! Here we have *different syntax* for assignments in
> expressions.
Yes, binding expressions in the current PEP support an extremely
limited subset of what Python's assignment statements support. That
they use different operator symbols is irrelevant to that the meaning
of "binding a name" is exactly the same for both.. _That's_ the "hard
part" to learn.
> Well, you can also use it as a statement. But don't!
Why not? _Every_ expression in Python can be used as a statement.
Nothing forbids it, and that's even (very!) useful at an interactive
prompt.
> We have a better one for that.
As a matter of style, sure, it's best to use the simplest thing that
works. As a statement in a program (as opposed to typed at a shell),
"a := 3" has the unnecessary (in that context) property of returning
(and discarding 3), so it's better style to use "a = 3" in that
context.
> And that one supports type annotations, can unpack and assign to many
> targets at the same time, and can even increment, multiply and so on, at once.
> But the other one can't.
So? math.sqrt() blows up when passed -1, but cmath.sqrt() doesn't.
Different tools for different tasks.
> So only use the Pascal one in expressions. But don't forget parentheses,
> otherwise it will bind the thing you probably didn't want anyway.
[Raymond]
>>> To my eyes, the examples give ample opportunity for being
>>> misunderstood and will create a need to puzzle-out the intended
>>> semantics.
>> Some do, many don't.
> As soon as we have to wrap a part of an expression in parentheses, parsing
> the entire thing becomes more complex. Often enough it will cause the
> expression to exceed whatever line length limit the codebase pledged not to
> exceed, causing one line to become three. And again, making it trickier for
> a regular Łukasz to understand what's going on.
At this point I think you must have a lower opinion of Python
programmers than I have ;-) If adding even a dozen characters to a
line makes it exceed a reasonable line-length guide, the code was
almost certainly too confusingly dense to begin with. All the
binding-expression examples I've given as "improvements" had _oceans_
of horizontal white space to swim in.
Guido's if/elif/elif/elif/ ... complex text-processing example didn't,
but because the current lack of an ability to bind-and-test in one
gulp forced the `elif` parts to be ever-more-deeply-indented `if`
blocks instead.
So, to match your sarcasm, here's mine: try using a feature for what
it's good at instead of for what it's bad at ;-)
Steven D'Aprano
> So only use the Pascal one in expressions. But don't forget
> parentheses, otherwise it will bind the thing you probably didn't want
> anyway.
Binding expressions are no worse than any other expression: sometimes
you need to bracket terms to change the default precedence, and
sometimes you don't.
And sometimes, even if we don't *need* parens, we use them anyway
because it makes the expression easier to read and understand.
Unless you have a language with no operator precedence at all, a purely
left-to-right evaluation order like Forth or (I think?) APL, there will
always be circumstances where parens are needed. Criticising binding-
expressions for that reason, especially implying that we must always use
parens, is simply FUD.
[...]
> As soon as we have to wrap a part of an expression in parentheses,
> parsing the entire thing becomes more complex.
Unless it becomes less complex to read and understand.
I for one always have difficulty parsing complex boolean tests unless I
bracket some or all of the parts, even when they're not strictly needed.
Consequently I try very hard not to write complex bool tests in the
first place, but when I can't avoid it, a few extra brackets really
helps simplify the logic.
> Often enough it will
> cause the expression to exceed whatever line length limit the codebase
> pledged not to exceed, causing one line to become three.
Just how often are your lines within two characters of the maximum
column so that adding a pair of brackets () will "often enough" put it
over the limit? Seems pretty unlikely to me. This sounds really like
picking at straws.
--
Steve
Greg Ewing
> <yseliv...@gmail.com> wrote:
>
>> my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf))
expression that also makes it a keyword argument:
my_func(arg, buffer ::= [None]*get_size(), size = len(buffer))
--
Greg
Greg Ewing
> Ha, not in Python! Here we have *different syntax* for assignments in
> expressions. Well, you can also use it as a statement. But don't!
This is what I least like about the proposal. We should
be moving in the direction of removing warts, but here
we would be *creating* one (two different assignment
operators with overlapping use cases) that we won't be
able to get rid of without a Python 4000 (that Guido has
promised won't happen).
--
Greg
Tim Peters
>>> After re-reading all the proposed code samples, I believe that
>>> adopting the PEP will make the language harder to teach to people
>>> who are not already software engineers.
> discussion, far more of a source of confusion than the occasional
> question of why Python doesn't have embedded assignment.
recurring discussion in your experience? Or are you predicting that
adding ":=" will create that situation?
> Also, it is of concern that a number of prominent core dev
> respondents to this thread have reported difficulty scanning
> the posted code samples.
>> I've used dozens of languages over the
>> decades, most of which did have some form of embedded assignment.
> Python is special, in part, because it is not one of those languages.
> It has virtues that make it suitable even for elementary school children.
> We can show well-written Python code to non-computer folks and walk
> them through what it does without their brains melting (something I can't
> do with many of the other languages I've used). There is a virtue
> in encouraging simple statements that read like English sentences
> organized into English-like paragraphs, presenting itself like
> "executable pseudocode".
that's true. But I didn't mention those dozens of languages because I
seek to emulate them, but to establish that I've had decades of
experience with embedded assignments in a wide variety of languages
and language communities.
> Perl does it or C++ does it is unpersuasive.
> Its omission from Python was always something that I thought Guido had
> left-out on purpose, intentionally stepping away from constructs that would
> be of help in an obfuscated Python contest.
the most profound: there were exactly and only 3 scopes at first:
local, global, and builtin. Functions (for example) could still nest,
but had no way to access names local to enclosing functions save via
deep trickery. That was a noble experiment (it was a deliberate
attempt to avoid complex scoping rules), but eventually proved too
restrictive in practice.
This is nothing compared to that ;-) But it's a tiny bit related in
that biting the arbitrarily-deeply-nested-scopes bullet was aimed more
at experienced programmers than at newbies. The scoping rules became
far harder to explain as a result - but far more what experienced
programmers expected.
>> Yes, I'm a software engineer, but I've always pitched in on "help
>> forums" too.
> That's not really the same.
> I've taught Python to many thousands of professionals, almost
> every week for over six years. That's given me a keen sense of
> what is hard to teach. It's okay to not agree with my assessment,
> but I would like for fruits of my experience to not be dismissed in a
> single wisp of a sentence.
a raw assertion in your original message, without enough detail to
even know _what_ it is you thought would be hard to teach. Your
elaboration is helping.
> Any one feature in isolation is usually easy to explain, but showing
> how to combine them into readable, expressive code is another matter.
be hard to teach if they're added, but ... how to use them
intelligently (if ever)? That's progress, if so.
That part I can see having major trouble with. Even the proponents of
this PEP don't always agree with each other about which examples are
"good ones".
> And as Yuri aptly noted, we spend more time reading code than writing code.
> If some fraction of our users finds the code harder to scan
> because the new syntax, then it would be a net loss for the language.
course. I don't know how to quantify that (not even to the extent of
determining the sign bit) in advance. I'm also at least as concerned
about - indeed - professional software engineers as beginners.
> I hesitated to join this thread because you and Guido seemed to be
> pushing back so hard against anyone's who design instincts didn't favor
> the new syntax.
by emotional tirades and FUD, of which there's always plenty in
threads that have gone on for hundreds of messages (I don't know
whether you followed any of this on python-ideas, but most arguments
on python-dev were already many-times-over old by the time it first
appeared here).
> It would be nice to find some common ground and perhaps stipulate that the
> grammar would grow in complexity, that a new operator would add to the
> current zoo of operators, that the visual texture of the language would change
> (and in a way that some including me do not find pleasing), and that while
> simplest cases may afford a small net win, it is a certitude that the syntax
> will routinely be pushed beyond our comfort zone.
>
> While the regex conditional example looks like a win, it is very modest win
> and IMHO not worth the overall net increase language complexity.
>
> Like Yuri, I'll drop-out now. Hopefully, you all wind find some value
> in what I had to contribute to the conversation.
respect your -1, and am grateful for your thoughtful elaboration.
Indeed, I'll feel better now when Guido rejects it ;-)
Greg Ewing
> As a statement in a program (as opposed to typed at a shell),
> "a := 3" has the unnecessary (in that context) property of returning
> (and discarding 3), so it's better style to use "a = 3" in that
> context.
and only assignment symbol, the compiler could easily optimise
away the extra DUP_TOP or whatever is involved.
--
Greg
Greg Ewing
> To my eyes, this is genuinely harder to follow, despite its relative brevity:
>
> while total != (total := total + term):
of subtlety at play:
1. total isn't just naming a subexpression, it's being
rebound to something that depends on its previous value.
2. Order of evaluation is being relied on to ensure that
the new value of total is compared to its old value.
Steven D'Aprano
> Tim Peters wrote:
> >As a statement in a program (as opposed to typed at a shell),
> >"a := 3" has the unnecessary (in that context) property of returning
> >(and discarding 3), so it's better style to use "a = 3" in that
> >context.
>
> That seems like a post-hoc justification. If := were the one
> and only assignment symbol, the compiler could easily optimise
> away the extra DUP_TOP or whatever is involved.
aren't part of the language specification.
And to steal an earlier idea from Tim, it is especially unfortunate if
you copy
data := sorted(huge_list_with_billions_of_items)
from a program and paste it into your REPL, then can't type again for an
hour or two.
The longer I think about this, the more I am convinced that having two
forms of assignment, one a statement with no return value and the other
an expression with a return value, is a feature, not a wart or bug. Yes,
it does add some complexity to the language, but it is *useful*
complexity. If all complexity was bad, we'd still be programming by
flicking toggle switches.
--
Steve
Terry Reedy
> On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov
> <yseliv...@gmail.com> wrote:
>> Just yesterday this snippet was used on python-dev to show how great the
>> new syntax is:
>>
>> my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf))
get_size(), so the wrong value is being named and saved.
'size=len(buf)' is, in a sense, backwards.
buflen = get_size()
my_func(arg, buffer = [None]*buflen, size=buflen)
Is standard, clear Python code. I do not see that
my_func(arg, buffer=[None]*(buflen:=get_size()), size=buflen)
is an improvement.
--
Terry Jan Reedy
Steven D'Aprano
> On 4/25/2018 8:20 PM, Chris Angelico wrote:
> >On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov
> ><yseliv...@gmail.com> wrote:
> >>Just yesterday this snippet was used on python-dev to show how great the
> >>new syntax is:
> >>
> >> my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf))
>
> What strikes me as awful about this example is that len(buf) is
> get_size(), so the wrong value is being named and saved.
> 'size=len(buf)' is, in a sense, backwards.
culpa.
But Yury is misrepresenting the context in which I came up with that
snippet. It was not "to show how great the new syntax is", but to try to
give a *more realistic example of what we might right, instead of the
toy example he had given:
Yuri claimed that
my_func(a=(b:=foo))
was "barely readable" and I responded:
There's no advantage to using binding-expressions unless
you're going to re-use the name you just defined, and that
re-use will give you a hint as to what is happening:
Alas, my spur of the moment example was crap, as you point out, but the
point still stands: Yuri's example is mysterious, because there's a
local variable b assigned to which doesn't seem to be used anywhere. It
is either a mistake of some sort, simply poor code, or maybe b is used
somewhere else in the function. Which seems poor style: if b is intended
to be used elsewhere in the function, why not use normal assignment?
Using a binding expression is a hint that it is likely *intended* to
only be used in the current expression, or block. That's not a rule
that the compiler ought to enforce, but it is a reasonable stylistic
idiom, like using ALLCAPS for constants. At least, that's my opinion.
So, crappy example or not, if I see a binding expression, that hints
that the name used is needed in the current expression multiple times.
It certainly should motivate me to look further ahead in the current
expression to see where the newly defined variable is used next, and if
it is only used once, to wonder if there has been some mistake.
Whereas a stand alone assignment doesn't really give any hint (apart
from vertical proximity, which is a very poor hint) as to how often and
where a variable is used.
--
Steve
Antoine Pitrou
Łukasz Langa <luk...@langa.pl> wrote:
> > On 25 Apr, 2018, at 5:20 PM, Chris Angelico <ros...@gmail.com> wrote:
> >
> > On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov
> > <yseliv...@gmail.com> wrote:
> >> Just yesterday this snippet was used on python-dev to show how great the
> >> new syntax is:
> >>
> >> my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf))
> >>
> >> To my eye this is an anti-pattern. One line of code was saved, but the
> >> other line becomes less readable. The fact that 'buf' can be used after
> >> that line means that it will be harder for a reader to trace the origin of
> >> the variable, as a top-level "buf = " statement would be more visible.
> >
> > Making 'buf' more visible is ONLY a virtue if it's going to be used
> > elsewhere. Otherwise, the name 'buf' is an implementation detail of
> > the fact that this function wants both a buffer and a size.
>
> You're claiming that `:=` is nicer in this situation because it's less
> prominent than regular assignment and thus doesn't suggest that the name
> stays visible later.
>
> But as others said, `:=` *does* make the name visible later until the
> enclosing scope ends. In fact, a large part of its appeal is that you
> can use the result later (as in the `re.search()` example). Will it be
> visible enough to the reaser in those cases then?
>
> There seems to be a conflict there.
Not only, but seeing `:=` hints that something *special* is going on
(some inner expression is being bound to a name). So now we have to be
extra careful when reading and reviewing code written that people who
like using that syntactical feature.
I also wonder how long it will be before someone writes:
def f(arg):
global _lazy_value
if predicate(arg) and (_lazy_value := frobnicate()) > arg:
...
(or something similar with "nonlocal")
Regards
Antoine.
Antoine Pitrou
> > Tim Peters wrote:
> > >As a statement in a program (as opposed to typed at a shell),
> > >"a := 3" has the unnecessary (in that context) property of returning
> > >(and discarding 3), so it's better style to use "a = 3" in that
> > >context.
> >
> > That seems like a post-hoc justification. If := were the one
> > and only assignment symbol, the compiler could easily optimise
> > away the extra DUP_TOP or whatever is involved.
>
> Its still bad form to rely on compiler-dependent optimizations which
> aren't part of the language specification.
specification. We are talking about a trivial optimization that any
runtime could easily implement (e.g. if a sequence `DUP_TOP, STORE_FAST,
POP_TOP` occurs, replace it with `STORE_FAST`).
Any runtime already has to implement a set of performance properties
that's far less trivial than that. For example, any decent runtime is
expected to provide amortized O(1) list append or dict insertion. You
are breaking user expectations if you don't.
> And to steal an earlier idea from Tim, it is especially unfortunate if
> you copy
>
> data := sorted(huge_list_with_billions_of_items)
>
> from a program and paste it into your REPL, then can't type again for an
> hour or two.
assigned value make their REPLs work? I'm sure they don't inflict that
on their users, so it's certainly a solvable problem.
(abstractly: if the user is executing a top-level assignment expression,
don't display the assignment result)
> The longer I think about this, the more I am convinced that having two
> forms of assignment, one a statement with no return value and the other
> an expression with a return value, is a feature, not a wart or bug.
It's nice to innovate, but being the only one to do something may very
well mean that you're doing something ridiculous.
Regards
Antoine.
Antoine Pitrou
Steven D'Aprano <st...@pearwood.info> wrote:
> On Thu, Apr 26, 2018 at 05:22:58PM +1200, Greg Ewing wrote:
> > Łukasz Langa wrote:
> > >What was its own assignment before
> > >now is part of the logic test. This saves on vertical whitespace but makes
> > >parsing and understanding logic tests harder.
> >
> > Another way to say this is that expressions are no longer
> > restricted to being trees, but can be general DAGs, which
> > require more mental effort to understand.
>
> Is that right? I presume you mean that there can be cycles in
> expressions involving binding-expressions. If not, what do you mean?
>
> Can you give an example of a Python expression, involving PEP 572
> binding-expressions, that is not a tree but a more general DAG or that
> contains cycles?
Depends if you mean a graph between names or values?
If between names, you can even have cycles AFAICT:
((a: = a + b), (b: = a))
Regards
Antoine.
Chris Angelico
> On Thu, 26 Apr 2018 17:29:17 +1000
> Steven D'Aprano <st...@pearwood.info> wrote:
>> On Thu, Apr 26, 2018 at 07:16:28PM +1200, Greg Ewing wrote:
>> > Tim Peters wrote:
>> > >As a statement in a program (as opposed to typed at a shell),
>> > >"a := 3" has the unnecessary (in that context) property of returning
>> > >(and discarding 3), so it's better style to use "a = 3" in that
>> > >context.
>> >
>> > That seems like a post-hoc justification. If := were the one
>> > and only assignment symbol, the compiler could easily optimise
>> > away the extra DUP_TOP or whatever is involved.
>>
>> Its still bad form to rely on compiler-dependent optimizations which
>> aren't part of the language specification.
>
> If such were the need, you could very well make it part of the language
> specification. We are talking about a trivial optimization that any
> runtime could easily implement (e.g. if a sequence `DUP_TOP, STORE_FAST,
> POP_TOP` occurs, replace it with `STORE_FAST`).
value. It's semantically different.
> Any runtime already has to implement a set of performance properties
> that's far less trivial than that. For example, any decent runtime is
> expected to provide amortized O(1) list append or dict insertion. You
> are breaking user expectations if you don't.
instance, that string subscripting (an O(1) operation in CPython) is
allowed to be O(n) in other Python implementations?
Now you do.
ChrisA
Antoine Pitrou
Chris Angelico <ros...@gmail.com> wrote:
> >
> > If such were the need, you could very well make it part of the language
> > specification. We are talking about a trivial optimization that any
> > runtime could easily implement (e.g. if a sequence `DUP_TOP, STORE_FAST,
> > POP_TOP` occurs, replace it with `STORE_FAST`).
>
> Not at the REPL, no. At the REPL, you need to actually print out that
> value. It's semantically different.
so that's entirely a strawman. The REPL doesn't care that it will
spend a fraction of microseconds executing two additional bytecodes
before presenting something to the user.
> > Any runtime already has to implement a set of performance properties
> > that's far less trivial than that. For example, any decent runtime is
> > expected to provide amortized O(1) list append or dict insertion. You
> > are breaking user expectations if you don't.
>
> You assume that, but it isn't always the case.
> Did you know, for instance, that string subscripting (an O(1) operation in CPython) is
> allowed to be O(n) in other Python implementations?
design decision such as how to represent string values internally
(utf-8 vs. fixed-width, etc.). We are talking about optimizing a
trivial bytecode sequence into another more trivial bytecode sequence.
CPython can easily do it. PyPy can easily do it. Other runtimes can
easily do it.
If some implementation is significantly slower because it can't
optimize away pointless DUP_TOPs *and* it implements DUP_TOP
inefficiently enough to have user-noticeable effect, then it's either
1) a deliberate toy, a proof-of-concept not meant for serious use, or
2) a pile of crap produced by incompetent people.
So there's zero reason to bother about efficiency issues here.
Regards
Antoine.
Steve Holden
> On 25 Apr, 2018, at 1:28 PM, Guido van Rossum <gu...@python.org> wrote:
>
> You don't seem to grasp the usability improvements this will give. I hear you but at this point appeals to Python's "Zen" don't help you.
This reads dismissive to me. I did read the PEP and followed the discussion on
python-dev. I referred to PEP 20 because it distills what's unique about the
value proposition of Python. It's our shared vocabulary.
Can you address the specific criticism I had? To paraphrase it without PEP 20
jargon:
> (name := expression) makes code less uniform. It inserts more information
> into a place that is already heavily packed with information (logic tests).
Steve Holden
On Thu, Apr 26, 2018 at 03:31:13AM -0400, Terry Reedy wrote:
> On 4/25/2018 8:20 PM, Chris Angelico wrote:
> >On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov
> ><yseliv...@gmail.com> wrote:
> >>Just yesterday this snippet was used on python-dev to show how great the
> >>new syntax is:
> >>
> >> my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf))
>
> What strikes me as awful about this example is that len(buf) is
> get_size(), so the wrong value is being named and saved.
> 'size=len(buf)' is, in a sense, backwards.
Terry is absolutely right, and I'm to blame for that atrocity. Mea
culpa.
Greg Ewing
> Well, how do languages where assignment is an expression returning the
> assigned value make their REPLs work? I'm sure they don't inflict that
> on their users, so it's certainly a solvable problem.
offhand, but here's a possible solution:
x := expr # doesn't print anything
(x := expr) # prints the result
I.e. special-case a stand-alone assignment, but
allow overriding that with parens if needed.
--
Greg
Greg Ewing
> Depends if you mean a graph between names or values?
>
> If between names, you can even have cycles AFAICT:
>
> ((a: = a + b), (b: = a))
a cycle between *values*, since the new values being
bound are calculated from the previous values of the
names.
--
Greg
Stephen J. Turnbull
> > On 25 Apr, 2018, at 5:20 PM, Chris Angelico <ros...@gmail.com> wrote:
> You're claiming that `:=` is nicer in this situation because it's less
> prominent than regular assignment and thus doesn't suggest that the name
> stays visible later.
FWIW, I read what he wrote as "*assuming* buf is not going to be used
later", and thus took a more nuanced idea from it: Use a separate
statement when you do use it later, and use a binding expression when
its scope is *in fact* only that line.
BTW, I don't find the "it could be misused, so it will be misused"
argument persuasive. I agree it's true, but don't think it matters,
per the "consenting adults" principle, since binding expressions have
other, important, use cases.
We could add a statement to PEP 8 mildly deprecating this particular
use. How about this:
In some examples, the binding expression is used in function
arguments where one argument depends on an earlier one, such as
foo(buffer=(buf := [None]*get_size()), size=len(buf))
In examples like this one, it is preferable where possible to
refactor the function to calculate the dependent variable itself,
or to use an assignment statement to define the bound variable.
The latter style is *strongly* preferred when the bound variable
will be used later in the scope.
Steve
David Mertz
[Raymond Hettinger <raymond....@gmail.com>]
> Python is special, in part, because it is not one of those languages.
> It has virtues that make it suitable even for elementary school children.
> We can show well-written Python code to non-computer folks and walk
> them through what it does without their brains melting (something I can't
> do with many of the other languages I've used). There is a virtue
> in encouraging simple statements that read like English sentences
> organized into English-like paragraphs, presenting itself like
> "executable pseudocode".
Steven D'Aprano
> I also wonder how long it will be before someone writes:
>
> def f(arg):
> global _lazy_value
> if predicate(arg) and (_lazy_value := frobnicate()) > arg:
> ...
>
> (or something similar with "nonlocal")
use of a global, including the current version:
def f(arg):
global _lazy_value
_lazy_value = frobnicate()
if predicate(arg) and _lazy_value > arg:
...
I'm not putting either version forward as paragons of Pythonic code, but
honestly, they're not so awful that we should reject this PEP because of
the risk that somebody will do this. People write crappy code and misuse
features all the time. I cannot count the number of times people write
list comps just for the side-effects, intentionally throwing away the
resulting list:
[alist.sort() for alist in list_of_lists]
[print(alist) for alist in list_of_lists]
and the honest truth is that when I'm engaged in exploratory coding in
the REPR, sometimes if I'm feeling lazy I'll do it too. The world goes
on, and comprehensions are still useful even if people sometimes misuse
them.
--
Steve
Steven D'Aprano
> Antoine Pitrou wrote:
> >Well, how do languages where assignment is an expression returning the
> >assigned value make their REPLs work? I'm sure they don't inflict that
> >on their users, so it's certainly a solvable problem.
>
> I can't think of any such language that has a REPL
> offhand, but here's a possible solution:
[steve@ando ~]$ rhino
Rhino 1.7 release 0.7.r2.3.el5_6 2011 05 04
js> x = (a = 99) + 1
100
Here's the standard Ruby REPL:
[steve@ando ~]$ irb
irb(main):001:0> x = (a = 99) + 1
=> 100
So both of these REPLs do print the result of the expression.
R, on the other hand, doesn't print the results of assignment
expressions:
> x <- (a <- 99) + 1
> c(x, a)
[1] 100 99
Rhino, however, does suppress printing if you prefix the variable with
"var" or "const".
--
Steve
David Mertz
Yes, binding expressions in the current PEP support an extremely
limited subset of what Python's assignment statements support.[...]
Nick Coghlan
>> Can you give an example of a Python expression, involving PEP 572
>> binding-expressions, that is not a tree but a more general DAG or that
>> contains cycles?
>
> But I have no idea what kind of expression isn't a tree as a
> consequence of having an assignment in it.
At a parsing level, the expression remains a tree, it's just that one
of the nodes is a name lookup. At a logical level though, binding
expressions do indeed mean that expressions involving binding
expressions are at least arguably better modelled with a DAG rather
than as a tree the way they are now:
# The arithmetic expression is a tree including two nodes that
look up "c". The DAG is only needed at a statement level.
c = expr()
a*c + b*c
# Whereas this backref to "c" pulls the DAG down to the expression level
a*(c := expr()) + b*c
Historically, that kind of order-of-evaluation dependence in Python
has only been a problem for functions with side effects, so the folks
asking that this be seen as a major complexity increase for expression
level semantics have an entirely valid point. The PEP aims to address
that point by saying "Don't use binding expressions when the order of
evaluation would be ambiguous", but that's as a response to a valid
concern, not a dismissal of it.
Cheers,
Nick.
--
Nick Coghlan | ncog...@gmail.com | Brisbane, Australia
Łukasz Langa
> On Apr 25, 2018, at 11:10 PM, Steven D'Aprano <st...@pearwood.info> wrote:
> Criticising binding-
> expressions for that reason, especially implying that we must always use
> parens, is simply FUD.
The PEP has more examples with parentheses than without.
>> As soon as we have to wrap a part of an expression in parentheses,
>> parsing the entire thing becomes more complex.
>
> Unless it becomes less complex to read and understand.
You're ignoring the context of the discussion. The new parentheses are there because there's a new assignment there. That's more complex.
>> Often enough it will
>> cause the expression to exceed whatever line length limit the codebase
>> pledged not to exceed, causing one line to become three.
>
> Just how often are your lines within two characters of the maximum
> column so that adding a pair of brackets () will "often enough" put it
> over the limit? Seems pretty unlikely to me.
Again, you're ignoring the context of the discussion. Assuming := will have spaces around it in PEP 8, this is adding *at least* 7 characters if the name of your choice is a single character.
> This sounds really like
> picking at straws.
The entire point of the PEP is to make things "nicer". It doesn't fundamentally enable programmers to do anything they couldn't do before.
If you think demonstrating cases where the end result won't be an improvement is picking at straws, then maybe the improvement of PEP 572 is as well.
-- Ł
Lukasz Langa
> So, to match your sarcasm, here's mine: try using a feature for what
> it's good at instead of for what it's bad at ;-)
Yes, this is the fundamental wisdom. Judging which is which is left as an
exercise to the programmer.
With this, I'm leaving the discussion. With Guido and you on board for PEP
572, I feel that Chris' streak is indeed about to break.
Some parting hair-splitting follows.
> [Uncle T]
>>> One language feature conspicuous by absence in newbie
>>> confusions was, consistently, assignment expressions. Read any book
>>> or tutorial for such a language, and you'll find very little space
>>> devoted to them too.
>
> [Łukasz Langa <luk...@langa.pl>]
>> Well, you have an entire code style built around this feature called Yoda
>> conditions. You teach people on Day 1 to never ever confuse == with =. Some
>> compilers even warn about this because so many people did it wrong.
>
[Uncle T]
> Sorry, I couldn't follow that.
You implied that newbies don't have to even know about assignments in
expressions. I wanted to demonstrate that this isn't really the case because
mistaking `=` for `==` is a relatively common occurence for newbies. If you
want to argue that it isn't, I'd like to point out that the WordPress code
style *requires* Yoda conditions because it was enough of a hindrance. ESLint
(a JavaScript linter) also has a warning about assignment in a conditional.
[Uncle T]]
> In languages like C that use easily
> confused operator symbols, sure, people are forever typing "=" when
> they mean "==". That's nothing to do with whether they _understand_
> what the different operators do, though.
What you're saying is true. But for it to be true, newbies *have to* learn the
distinction, and the fact that yes, sometimes the programmer indeed meant to
put a single `=` sign in the conditional. That's why we'll end up with the
Pascal assignment operator. And that *is* a thing that you will have to
explain to newbies when they encounter it for the first time. Sadly, googling
for a colon followed by an equal sign isn't trivial if you don't know what
you're looking for.
[Łukasz]
>> Well, you can also use it as a statement. But don't!
>
[Uncle T]]
> Why not? _Every_ expression in Python can be used as a statement.
> Nothing forbids it, and that's even (very!) useful at an interactive
> prompt.
Because it suggests different intent, because it's limited, because it's slower
at runtime, and because PEP 572 says so itself.
> At this point I think you must have a lower opinion of Python
> programmers than I have ;-) If adding even a dozen characters to a
> line makes it exceed a reasonable line-length guide, the code was
> almost certainly too confusingly dense to begin with.
Around 5% of if and elif statements in the standard library don't fit a single
line *as is*. Sure, that's a low percentage but that's over 1,000 statements.
If you're putting an `if` statement in a method, you are already starting out
with 71 characters left on the line. Four of those are going to be taken by
"if", a space, and the colon. Adding a parenthesized assignment expression
takes at least 10% of that available space.
The silver lining for me is that this makes the environment riper for
auto-formatting.
Terry Reedy
That is exactly what I wrote in the continuation that Steven snipped.
--
Terry Jan Reedy
Zero Piraeus
On 25 April 2018 at 21:28, Guido van Rossum <gu...@python.org> wrote:
> A very emotional appeal, you don't seem to grasp the usability improvements
> help you.
thinking "there's no way this is actually going to happen" and "what,
this might actually happen?"
Since it now looks like it really *does* have a decent chance, and
maybe another -1 has a small chance of tipping the balance: my
reaction to the proposal is also emotional. Visceral, in fact, to the
extent that I'd aim to read and write less Python if it became
commonplace.
I don't have arguments. I just have an instinctive "ugh, no".
-[]z.
Terry Reedy
> Antoine Pitrou wrote:
>> Well, how do languages where assignment is an expression returning the
>> assigned value make their REPLs work? I'm sure they don't inflict that
>> on their users, so it's certainly a solvable problem.
>
> I can't think of any such language that has a REPL
> offhand, but here's a possible solution:
>
>
> x := expr # doesn't print anything
Ugh! The only reason I would bother typing the : in a top level
assignment would be to get the print without having to retype the name,
as in
>>> x = expr
>>> x
I consider echoing top-level interactive assignments to be a feature of
the proposal.
--
Terry Jan Reedy
Tim Peters
>> So, to match your sarcasm, here's mine: try using a feature for what
>> it's good at instead of for what it's bad at ;-)
[Lukasz Langa <luk...@langa.pl>]
> Yes, this is the fundamental wisdom. Judging which is which is left as an
> exercise to the programmer.
>
> With this, I'm leaving the discussion. With Guido and you on board for PEP
> 572, I feel that Chris' streak is indeed about to break.
I still expect it could go either way, but do wish people didn't
believe it will be a major loss if "the other side wins". I'll be
fine regardless - and so will everyone else. Guido rarely makes
language design mistakes. In this case he's seeing serious opposition
from several core developers, and you shouldn't believe either that he
just dismisses that.
[Łukasz Langa]
>>> Well, you have an entire code style built around this feature called Yoda
>>> conditions. You teach people on Day 1 to never ever confuse == with =. Some
>>> compilers even warn about this because so many people did it wrong.
>> Sorry, I couldn't follow that.
Part of the problem here is that I had never seen "Yoda conditions"
before, and had no idea what it meant. Some later Googling suggests
it's "a thing" youngsters say at times ;-)
> You implied that newbies don't have to even know about assignments in
> expressions. I wanted to demonstrate that this isn't really the case because
> mistaking `=` for `==` is a relatively common occurence for newbies. If you
> want to argue that it isn't, I'd like to point out that the WordPress code
> style *requires* Yoda conditions because it was enough of a hindrance. ESLint
> (a JavaScript linter) also has a warning about assignment in a conditional.
What does that have to do with Python? If they try to use "=" in an
expression now, they get a SyntaxError. The PEP doesn't change
anything about that. Indeed, that's why it uses ":=" instead. I have
experience in other languages with embedded assignments that also use
":=", and it's _never_ the case that people type ":=" when they intend
"equality test" in those. The horrid "I typed = when I meant =="
mistakes are unique to languages that mindlessly copied C. The
mistakes aren't primarily due to embedded assignments, they're due to
that even highly experienced programmers sometimes type "=" when
they're _thinking_ "equals". Nobody types ":=" when they're thinking
"equals".
> ...
> What you're saying is true. But for it to be true, newbies *have to* learn the
> distinction, and the fact that yes, sometimes the programmer indeed meant to
> put a single `=` sign in the conditional.
Again, the PEP is about Python: a single "=" in a conditional is, and
will remain, a SyntaxError. So nobody can sanely intend to put a
single "=" in a condition _in Python_ unless they're writing a test
intending to provoke a syntax error.
> That's why we'll end up with the Pascal assignment operator.
":=" is already in the PEP.
> And that *is* a thing that you will have to explain to newbies when they encounter
> it for the first time.
Sure. That doesn't frighten me, though. It's easy to explain what it
does - although it may be hard to explain when it's _desirable_ to use
it.
> Sadly, googling for a colon followed by an equal sign isn't trivial if you don't
> know what you're looking for.
To judge from Stackoverflow volume, the single most misunderstood of
all Python operators - by far - is "is" - try Googling for that ;-)
In far second and third places are "and" and "or", for which searches
are also useless.
Regardless, I'm not concerned about one-time tiny learning curves.
Don't know what ":=" means already? Ask someone. If you know what
"=" means, you're already close to done. Given that you already
understand what "binding a name" means, ":=" may well be the simplest
of all Python's operators (there's no computation _to_ be understood,
and no possibility either of a dunder method changing its meaning
depending on operand type(s)).
>>> Well, you can also use it as a statement. But don't!
>> Why not? _Every_ expression in Python can be used as a statement.
>> Nothing forbids it, and that's even (very!) useful at an interactive
>> prompt.
> Because it suggests different intent, because it's limited, because it's slower
> at runtime, and because PEP 572 says so itself.
I didn't say you're _required_ to use it as a statement. Regardless
of what PEPs say, people will do what they find most useful. I trust
people to figure this out quickly for themselves.
>> At this point I think you must have a lower opinion of Python
>> programmers than I have ;-) If adding even a dozen characters to a
>> line makes it exceed a reasonable line-length guide, the code was
>> almost certainly too confusingly dense to begin with.
> Around 5% of if and elif statements in the standard library don't fit a single
> line *as is*. Sure, that's a low percentage but that's over 1,000 statements.
> If you're putting an `if` statement in a method, you are already starting out
> with 71 characters left on the line. Four of those are going to be taken by
> "if", a space, and the colon. Adding a parenthesized assignment expression
> takes at least 10% of that available space.
Confirming that you do have a lower opinion of them ;-) Are you
picturing people stampeding to introduce ":=" in every place they
possibly could? I may be wrong, but I don't expect that at all. I
expect a vast majority of uses in real life will replace:
name = expression
if name:
by
if name := expression:
and
while True:
name = expression
if name comparison expression2:
break
by
while (name := expression) inverted_comparison expression2:
_provided that_ the latter spelling doesn't make the line
uncomfortably long. In all the code of mine I've seen a good use for
it, there's a whole lot of empty horizontal screen space to spare,
even after recoding. In places where I already had "long lines", I
didn't even check to see whether a binding operation could be used too
- why would I? I don't feel _compelled_ to use it - I'm only looking
to reduce redundancy where it's an obvious win.
> The silver lining for me is that this makes the environment riper for
> auto-formatting.
See? It's win-win for you too no matter how this turns out ;-)
Kirill Balunov
my_func(arg, buffer=[None]*get_size() as buf, size=buf)
Steven D'Aprano
> Since it now looks like it really *does* have a decent chance, and
> maybe another -1 has a small chance of tipping the balance: my
> reaction to the proposal is also emotional. Visceral, in fact, to the
> extent that I'd aim to read and write less Python if it became
> commonplace.
ternary if, type annotations and list comprehensions.
All of them have become great additions to the language.
I hated the idea of aping C and adding += operators and swore I'd never
use them. That lasted, well, about a month.
Just sayin'.
--
Steve
Tim Peters
>> maybe another -1 has a small chance of tipping the balance: my
>> reaction to the proposal is also emotional. Visceral, in fact, to the
>> extent that I'd aim to read and write less Python if it became
>> commonplace.
> ternary if, type annotations and list comprehensions.
>
> All of them have become great additions to the language.
>
> I hated the idea of aping C and adding += operators and swore I'd never
> use them. That lasted, well, about a month.
>
> Just sayin'.
try. Frankly, I've grown tired of editing it out of all the packages
I download anyway ;-)
Steven D'Aprano
>
> > On Apr 25, 2018, at 11:10 PM, Steven D'Aprano <st...@pearwood.info> wrote:
> > Criticising binding-
> > expressions for that reason, especially implying that we must always use
> > parens, is simply FUD.
>
> The PEP has more examples with parentheses than without.
Yes? Parens aren't mandatory, and my point that other operators also
sometimes needs parens still holds.
> >> As soon as we have to wrap a part of an expression in parentheses,
> >> parsing the entire thing becomes more complex.
> >
> > Unless it becomes less complex to read and understand.
>
> You're ignoring the context of the discussion. The new parentheses are
> there because there's a new assignment there. That's more complex.
I'm not ignoring the context of the discussion. I'm comparing binding-
expression with and without parens. That's what I thought you were
doing.
If that wasn't your intended meaning, then I apologise but please
understand why I answered the way I did.
I still stand by my argument: parens are not always needed, and even
when they are not needed, adding them can sometimes make things
*easier* and *less complex* to read.
[...]
> If you think demonstrating cases where the end result won't be an
> improvement is picking at straws, then maybe the improvement of PEP
> 572 is as well.
Any feature can have cases where the end result is worse than not using
the feature. That *alone* isn't a strong argument against a feature.
Do you have much existing code using binding expressions? Of course not.
Will you be adding them to code that already exists? Probably not -- you
can't do so until you are using 3.8 at minimum, and if your code needs
to be backwards compatible, you can't use it until you've dropped
support for 3.7 and older. That might not be for five or ten years.
So it is likely that for most people only new code will use this
feature. It is not reasonable to say that if I have existing code like
this:
spam = expression
if long_condition_that_takes_up_most_of_the_line == spam or spam:
...
that I'm going to immediately change it to a one-liner:
if long_condition_that_takes_up_most_of_the_line == (spam := expression) or spam:
...
and push it over the maximum line width. With or without parentheses.
Why would I do something so silly? Using binding expressions isn't
mandatory and most coders don't intentionally do things that make their
code worse.
And if I wouldn't change existing code and push it over the limit, why
would I write new code that does it? Especially when there are much
better alternatives:
if (long_condition_that_takes_up_most_of_the_line
== (spam:=expression)
or spam):
...
We have a history of adding features that can be abused, but aren't.
People hardly ever abuse list comps with overly long and complex
multiple-loop comprehensions:
[... for a in sequence for b in something for c in another for d in something_else]
I'm sure we've all seen one or two of those. But it doesn't happen
enough to matter. Same with if...elif...else chains. People didn't
immediately run out and replace every single if chain into nested
ternary if expressions, pushing their lines out to beyond the maximum
line width:
expression if condition else (expression if condition else (expression if condition else (expression if condition else expression)))
Real people don't abuse comprehensions or ternary if enough for us to
regret adding them to the language. I'm sure that they won't abuse this
feature either. The Python community simply doesn't have the culture of
abusing syntax in this way and writing overly dense one-liners, and I
don't think it is reasonable to say this feature will tip the balance.
It is reasonable to say that *some* code will be made worse by this,
because there's always *someone* who will abuse syntax. There are those
who insist on writing list comprehensions for their side-effects:
# return and throw away a list of Nones
[print(item) for item in bunch_of_stuff]
but I don't think this happens enough to make us regret adding
comprehensions to the language.
--
Steve
Wes Turner
Chris Angelico
> IDK, I could just be resistant to change, but this seems like something that
> will decrease readability -- and slow down code review -- without any real
> performance gain. So, while this would be useful for golfed-down (!)
> one-liners with pyline,
> I'm -1 on PEP 572.
performance gain" is hardly a criticism.
> How do I step through this simple example with a debugger?
>
> if re.search(pat, text) as match:
> print("Found:", match.group(0))
in 'match'. Then the cursor would be put either on the 'print' (if the
RE matched) or on the next executable line (if it didn't).
> From https://en.wikipedia.org/wiki/Assignment_(computer_science) :
>
>> In some languages the symbol used is regarded as an operator (meaning that
>> the assignment has a value) while others define the assignment as a
>> statement (meaning that it cannot be used in an expression).
>
>
> PEP 572 -- Assignment Expressions
> PEP 572 -- Assignment Operator (:=) and Assignment Expressions
ChrisA
Python-Dev mailing list
Pytho...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Chris Barker
> And that *is* a thing that you will have to explain to newbies when they encounter
> it for the first time.
Sure. That doesn't frighten me, though. It's easy to explain what it
does - although it may be hard to explain when it's _desirable_ to use
it.
To judge from Stackoverflow volume, the single most misunderstood of
all Python operators - by far - is "is" -
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris....@noaa.gov
Tim Peters
>> > they encounter it for the first time.
>> does - although it may be hard to explain when it's _desirable_ to use
>> it.
> I've found that newbies fall into two camps: folks to whom programming comes
> naturally, and those that it doesn't (OK, it's a distribution, but a bimodal
> one). And folks that are struggling with programming can struggle even with
> simple assignment (name binding), particularly when you add even function
> local scope.
length many times: what a binding expression does is "easy to
explain" GIVEN THAT someone ALREADY UNDERSTANDS how binding a name
works. The latter in fact seems difficult for a significant number of
people to learn, but it's utterly unavoidable that they learn it if
they're ever to write non-trivial Python programs. That's been true
since Python's first release.
Binding expressions would be introduced much later in any sane course.
At THAT point, for students who haven't already dropped out, the
semantics are darned-near trivial to explain: it binds the name to
the object the expression evaluates to (all of which they _already_
understand by this point), and the value of the binding expression is
that object (the only new bit).
Unlike as for most other operators, you don't even have to weasel-word
it to account for that a magical dunder method may change what ":="
does. As for the "is" operator, the meaning is baked into the
language and can't be altered in the slightest.
> So having one more way to do assignment WILL make it harder to
> teach, not because it's that hard, but because it's one more thing to learn.
above, I can't see it getting beyond a single digit, GIVEN THAT a
student has already masteredf the far more complex assignment
_statement_ (binding expressions are limited to the single simplest
case of the many things an assignment statement can do). "And it
returns the object" is a yawn. But, as I already granted, it may be
truly hard to explain when it's a desirable thing to use. That takes
experience and "good judgment", which - according to me - can be
learned but can't really be taught.
> But the fact is that as Python has evolved (particularly with the jump to
> py3) it has become less and less of a "scripting" language, and more of a
> "systems" language. And also harder to learn. Anyone remember CP4E? Python
> is not as good choice as a "newbie" language as it once was.
life easier for beginners. For example, would anyone in their right
mind even mention async gimmicks when teaching beginners?
Against that, though, one of the most unintentionally funny tech
things I ever read was Bjarne Stroustrup writing about why C++ is an
excellent choice for beginners. But he does have a point: if you
throw away the bulk of everything C++ added, there's an easily usable
little language exceedingly well hidden under it all ;-)
> Adding := will move it a little bit more along the complexity path -- not
> much, and that's where Python has gone anyway, so as Tim said, no one's
> going to suffer either way this decision goes.
...
>> all Python operators - by far - is "is" -
> You now, I think instructors like me are partly responsible. "is" is rarely
> useful outside of comparing to singletons. Yet I use it early in instruction
> to do checks on name binding and show things with mutablilty, etc.... which
> has the unfortunate side effect of making it seem like a more common
> operator than it is.
>
> I've even had students write code like:
>
> if x is 3:
>
> and thanks to interning, it appears to work!
simple, but "but under exactly what conditions are `x` and `y` bound
to the same object?" is intractable. It seems to take a long time to
get across the point, that the question itself is misguided. A full
answer requires delving into transient implementation details, which
is counterproductive because they _are_ accidents of the
implementation du jour. What questioners need to be nudged into
asking instead is for examples of when using "is" is thoroughly sane.
Wes Turner
On Friday, April 27, 2018, Chris Angelico <ros...@gmail.com> wrote:
On Fri, Apr 27, 2018 at 8:18 PM, Wes Turner <wes.t...@gmail.com> wrote:
> IDK, I could just be resistant to change, but this seems like something that
> will decrease readability -- and slow down code review -- without any real
> performance gain. So, while this would be useful for golfed-down (!)
> one-liners with pyline,
> I'm -1 on PEP 572.
PEP 572 has never promised a performance gain, so "without any real
performance gain" is hardly a criticism.
> How do I step through this simple example with a debugger?
>
> if re.search(pat, text) as match:
> print("Found:", match.group(0))
Step the 'if' statement. It will call re.search() and stash the result
in 'match'. Then the cursor would be put either on the 'print' (if the
RE matched) or on the next executable line (if it didn't).
> From https://en.wikipedia.org/wiki/Assignment_(computer_science) :
>
>> In some languages the symbol used is regarded as an operator (meaning that
>> the assignment has a value) while others define the assignment as a
>> statement (meaning that it cannot be used in an expression).
>
>
> PEP 572 -- Assignment Expressions
> PEP 572 -- Assignment Operator (:=) and Assignment Expressions
Huh? I don't get your point.
ChrisA
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
Chris Angelico
>
>
> On Friday, April 27, 2018, Chris Angelico <ros...@gmail.com> wrote:
>>
>> On Fri, Apr 27, 2018 at 8:18 PM, Wes Turner <wes.t...@gmail.com> wrote:
>> > IDK, I could just be resistant to change, but this seems like something
>> > that
>> > will decrease readability -- and slow down code review -- without any
>> > real
>> > performance gain. So, while this would be useful for golfed-down (!)
>> > one-liners with pyline,
>> > I'm -1 on PEP 572.
>>
>> PEP 572 has never promised a performance gain, so "without any real
>> performance gain" is hardly a criticism.
>>
>> > How do I step through this simple example with a debugger?
>> >
>> > if re.search(pat, text) as match:
>> > print("Found:", match.group(0))
>>
>> Step the 'if' statement. It will call re.search() and stash the result
>> in 'match'. Then the cursor would be put either on the 'print' (if the
>> RE matched) or on the next executable line (if it didn't).
>
>
> Right. Pdb doesn't step through the AST branches of a line, so ternary
> expressions and list comprehensions and defining variables at the end of the
> line are 'debugged' after they're done.
>
> Similarly, code coverage is line-based; so those expressions may appear to
> be covered but are not.
covered when it isn't, due to an assignment expression?
ChrisA
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Wes Turner
ChrisA
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
Chris Angelico
expressions? If your code coverage checker is unable to handle
if/else, it's unable to handle it whether there's an assignment in
there or not.
I don't understand why people bring up all these arguments that have
absolutely nothing to do with the proposal at hand. None of this has
in any way changed.
ChrisA
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Tim Peters
> ...
> absolutely nothing to do with the proposal at hand. None of this has
> in any way changed.
contributed at least twice, it will be seen as a Golden Opportunity to
re-litigate every decision that's ever been made ;-)
Some amount of that seems healthy to me (people are thinking about
"language design" from a larger view than the proposal du jour). In
this specific case, line-oriented coverage tools have missed
accounting for all possible code paths since day #1; e.g.,
x = f() or g()
You don't need to reply to messages so obviously irrelevant to the PEP
unless you want to. It's not like Guido will read them and go "oh! a
binding expression in a ternary conditional is a fundamentally new
potential problem for a line-oriented coverage tool! that's fatal"
;-)
Wes Turner
On Friday, April 27, 2018, Tim Peters <tim.p...@gmail.com> wrote:
[Chris Angelico <ros...@gmail.com>]
> ...
> I don't understand why people bring up all these arguments that have
> absolutely nothing to do with the proposal at hand. None of this has
> in any way changed.
That's easy: any time there's a long thread to which Guido has
contributed at least twice, it will be seen as a Golden Opportunity to
re-litigate every decision that's ever been made ;-)
Some amount of that seems healthy to me (people are thinking about
"language design" from a larger view than the proposal du jour). In
this specific case, line-oriented coverage tools have missed
accounting for all possible code paths since day #1; e.g.,
x = f() or g()
You don't need to reply to messages so obviously irrelevant to the PEP
unless you want to. It's not like Guido will read them and go "oh! a
binding expression in a ternary conditional is a fundamentally new
potential problem for a line-oriented coverage tool! that's fatal"
;-)
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
Chris Angelico
> [Chris Angelico <ros...@gmail.com>]
>> ...
>> I don't understand why people bring up all these arguments that have
>> absolutely nothing to do with the proposal at hand. None of this has
>> in any way changed.
>
> That's easy: any time there's a long thread to which Guido has
> contributed at least twice, it will be seen as a Golden Opportunity to
> re-litigate every decision that's ever been made ;-)
> Some amount of that seems healthy to me (people are thinking about
> "language design" from a larger view than the proposal du jour). In
> this specific case, line-oriented coverage tools have missed
> accounting for all possible code paths since day #1; e.g.,
>
> x = f() or g()
>
> You don't need to reply to messages so obviously irrelevant to the PEP
> unless you want to. It's not like Guido will read them and go "oh! a
> binding expression in a ternary conditional is a fundamentally new
> potential problem for a line-oriented coverage tool! that's fatal"
> ;-)
understand the objection enough to know that it's actually irrelevant
:| I'm going to start ignoring any message that I don't understand, in
the hopes that it doesn't actually mean anything. :|
ChrisA
Tres Seaver
> In this specific case, line-oriented coverage tools have missed
> accounting for all possible code paths since day #1; e.g.,
>
> x = f() or g()
>
> You don't need to reply to messages so obviously irrelevant to the PEP
> unless you want to. It's not like Guido will read them and go "oh! a
> binding expression in a ternary conditional is a fundamentally new
> potential problem for a line-oriented coverage tool! that's fatal" ;-)
I haven't seen anything in this discussion which indicates that binding
expressions will change that at all.
Tres.
--
===================================================================
Tres Seaver +1 540-429-0999 tse...@palladion.com
Palladion Software "Excellence by Design" http://palladion.com
Tim Peters
[Wes Turner <wes.t...@gmail.com>]
>
> x = 2
> if (x == 3) or (x := 3):
> print(x)
>
> What do we call that mistake?
about it that's undefined. So I fail to see how showing that example
anywhere would do anyone any good.
You can do the same kind of thing today via, e.g.,
class Bindable:
def __init__(self, value):
self.bind(value)
def bind(self, value):
self.value = value
return value
def __bool__(self):
return bool(self.value)
def __eq__(self, other):
return self.value == other
def __str__(self):
return str(self.value)
Then:
>>> x = Bindable(2)
>>> if x == 3 or x.bind(3):
... print(x)
3
And I wouldn't put that example anywhere in any docs either ;-)
Python-Dev mailing list
Pytho...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Tim Peters
> I haven't seen anything in this discussion which indicates that binding
> expressions will change that at all.
operators are exactly as irrelevant to control-flow analyzers as,
e.g., introducing a floor division operator (//) was.
Data-flow analyzers (if there are any for Python) are a different
story, since they need to be aware of all (re)binding operations -
although at the byte code level, all such sites remain equally
apparent (no new flavor of "store" operation is added by this PEP).
Wes Turner
Glenn Linderman
That's easy: any time there's a long thread to which Guido has
contributed at least twice, it will be seen as a Golden Opportunity to
re-litigate every decision that's ever been made ;-)
Armin Rigo
On 26 April 2018 at 07:50, Raymond Hettinger
<raymond....@gmail.com> wrote:
>> [Raymond Hettinger <raymond....@gmail.com>]
>>> After re-reading all the proposed code samples, I believe that
>>> adopting the PEP will make the language harder to teach to people
>>> who are not already software engineers.
>
> (...)
>
> Python is special, in part, because it is not one of those languages.
> It has virtues that make it suitable even for elementary school children.
> We can show well-written Python code to non-computer folks and walk
> them through what it does without their brains melting (something I can't
> do with many of the other languages I've used). There is a virtue
> in encouraging simple statements that read like English sentences
> organized into English-like paragraphs, presenting itself like
> "executable pseudocode".
I must admit that when I heard about this PEP I thought "this April
1st joke was already done long ago". I'm sorry to discover that, this
time, it is not actually one. Thank you, Raymond, for an unlikely
attempt at reminding people what made Python so special---in your
opinion, and mine.
A bientôt,
Armin.
Cesare Di Mauro
Hi,
On 26 April 2018 at 07:50, Raymond Hettinger
<raymond....@gmail.com> wrote:
>> [Raymond Hettinger <raymond....@gmail.com>]
>>> After re-reading all the proposed code samples, I believe that
>>> adopting the PEP will make the language harder to teach to people
>>> who are not already software engineers.
>
> (...)
>
> Python is special, in part, because it is not one of those languages.
> It has virtues that make it suitable even for elementary school children.
> We can show well-written Python code to non-computer folks and walk
> them through what it does without their brains melting (something I can't
> do with many of the other languages I've used). There is a virtue
> in encouraging simple statements that read like English sentences
> organized into English-like paragraphs, presenting itself like
> "executable pseudocode".
I must admit that when I heard about this PEP I thought "this April
1st joke was already done long ago". I'm sorry to discover that, this
time, it is not actually one. Thank you, Raymond, for an unlikely
attempt at reminding people what made Python so special---in your
opinion, and mine.
A bientôt,
Armin.
Steven D'Aprano
> if ((1) or (x := 3)):
> if ((y := func(x)) if x else (x := 3))
already possible in Python.
Do you see a lot of code like:
if (1 or sequence.append(3) or sequence[-1]):
in real life? If you do, then I'm really, really sorry that you are
forced to deal with such rubbish code, but honestly, the vast bulk of
Python programmers do not write like that, and they won't write this
either:
if (1 or (x := 3)):
[...]
> define the variable in cases where that part of the line doesn't run but
> reads as covered.
/sarcasm
I guess adding print() to the language was a mistake, because we
can write rubbish code like this:
if 1 or print(x):
and then be confused by the fact that x doesn't get printed.
/end sarcasm
In another post, you insisted that we need to warn in the PEP and the
docs not to do this sort of thing. Should we also go through and add
these warnings to list.append, dict.update, set.add, etc?
I trust that the answer to that is obviously no.
And neither do we have to assume that people who use binding-expressions
will lose their minds and start writing the sort of awful code that
they don't write with anything else.
--
Steve
Python-Dev mailing list
Pytho...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Steve Holden
[Lukasz]
>> > And that *is* a thing that you will have to explain to newbies when
>> > they encounter it for the first time.
[...]
Sure. What I wrote was shorthand for what's already been covered at
length many times: what a binding expression does is "easy to
explain" GIVEN THAT someone ALREADY UNDERSTANDS how binding a name
works. The latter in fact seems difficult for a significant number of
people to learn, but it's utterly unavoidable that they learn it if
they're ever to write non-trivial Python programs. That's been true
since Python's first release.
Binding expressions would be introduced much later in any sane course.
At THAT point, for students who haven't already dropped out, the
semantics are darned-near trivial to explain: it binds the name to
the object the expression evaluates to (all of which they _already_
understand by this point), and the value of the binding expression is
that object (the only new bit).
Unlike as for most other operators, you don't even have to weasel-word
it to account for that a magical dunder method may change what ":="
does. As for the "is" operator, the meaning is baked into the
language and can't be altered in the slightest.
> So having one more way to do assignment WILL make it harder to
> teach, not because it's that hard, but because it's one more thing to learn.
[...]
> You now, I think instructors like me are partly responsible. "is" is rarely
> useful outside of comparing to singletons. Yet I use it early in instruction
> to do checks on name binding and show things with mutablilty, etc.... which
> has the unfortunate side effect of making it seem like a more common
> operator than it is.
>
> I've even had students write code like:
>
> if x is 3:
>
> and thanks to interning, it appears to work!
Yup, that's the real problem with "is": its semantics are dead
simple, but "but under exactly what conditions are `x` and `y` bound
to the same object?" is intractable. It seems to take a long time to
get across the point, that the question itself is misguided. A full
answer requires delving into transient implementation details, which
is counterproductive because they _are_ accidents of the
implementation du jour. What questioners need to be nudged into
asking instead is for examples of when using "is" is thoroughly sane.
Ned Batchelder
> On 04/27/2018 05:11 PM, Tim Peters wrote:
>
>> In this specific case, line-oriented coverage tools have missed
>> accounting for all possible code paths since day #1; e.g.,
>>
>> x = f() or g()
>>
>> You don't need to reply to messages so obviously irrelevant to the PEP
>> unless you want to. It's not like Guido will read them and go "oh! a
>> binding expression in a ternary conditional is a fundamentally new
>> potential problem for a line-oriented coverage tool! that's fatal" ;-)
> FWIW, Ned Batchelder's 'coverage.py' does a good job with branch coverage.
> I haven't seen anything in this discussion which indicates that binding
> expressions will change that at all.
>
>
Coverage.py can measure branch coverage, but it is still line-oriented.
There's no support for conditionals and branches within a line (though
I've done some wicked hacks to experiment with it:
https://nedbatchelder.com/blog/200804/wicked_hack_python_bytecode_tracing.html).
It's entirely true that binding expressions don't change this situation
at all, EXCEPT that the entire point of binding expressions is to be
able to express in one statement what used to take more than one. With
binding expressions, actions may be coverage-hidden within one statement
that without them would have been coverage-visible in more than one
statement.
I'm not sure that's an argument against binding expressions, but we
should at least acknowledge that the motivation for them is to provide
the option to write fewer, longer statements. That option is not always
a good idea, for a variety of reasons.
--Ned.
Chris Angelico
> It's entirely true that binding expressions don't change this situation at
> all, EXCEPT that the entire point of binding expressions is to be able to
> express in one statement what used to take more than one. With binding
> expressions, actions may be coverage-hidden within one statement that
> without them would have been coverage-visible in more than one statement.
and without assignment expressions, with a few exceptions where
coverage is *improved* by them (where the alternative is to duplicate
a function call). By combining multiple lines into one, we also ensure
that all of it is executed exactly once, instead of having conditional
execution.
ChrisA
Rob Cliffe via Python-Dev
more likely to be accepted is to launch an over-the-top attack on it.
Then more moderate people - who were/are not necessarily in favour of
the PEP - feel pressurised into defending it.
Hah!
Watch this space for my vicious, vitriolic, withering attack on PEP 463
(Exception-catching expressions)! :-)
Best wishes
Rob Cliffe