On 2018-04-24 12:59, Chris Angelico wrote:
Aside from the restriction to binding only to a simple name, and the
fact that they're also an expression with the same value, how are they
not the same as plain assignment? Any discrepancies should be
considered bugs.
Slightly different in that they
On 23.04.2018 23:41, Tim Peters wrote:
Why? "Give the result of an expression a name" is already heavily
used in Python - it's just that the _contexts_ in which it can be done
are very limited now.
Which is a good thing IMO. It keeps stuff simple to reason about.
At least to me, the objective
On Wed, Apr 25, 2018 at 1:49 AM, Yury Selivanov wrote:
> On Tue, Apr 24, 2018 at 11:34 AM, Steven D'Aprano wrote:
>> On Tue, Apr 24, 2018 at 11:05:57AM -0400, Yury Selivanov wrote:
>>
>>> Well, `my_func(a=(b:=foo))` or `my_func(b:=foo)` are also
On Tue, Apr 24, 2018 at 11:58 AM, Chris Angelico wrote:
> On Wed, Apr 25, 2018 at 1:49 AM, Yury Selivanov
> wrote:
>> On Tue, Apr 24, 2018 at 11:34 AM, Steven D'Aprano
>> wrote:
[..]
>>> There's no advantage to using
On Wed, Apr 25, 2018 at 5:54 AM, Mike Miller wrote:
> Also, these "binding expressions" are not exactly plain assignment, as it
> has been known.
Aside from the restriction to binding only to a simple name, and the
fact that they're also an expression with the same
On 04/24/2018 12:59 PM, Chris Angelico wrote:
On Wed, Apr 25, 2018 at 5:54 AM, Mike Miller wrote:
Also, these "binding expressions" are not exactly plain assignment, as it
has been known.
Aside from the restriction to binding only to a simple name, and the
fact that they're also an
On Tue, 24 Apr 2018 09:38:33 -0400
Yury Selivanov wrote:
> I propose to use the following syntax for assignment expressions:
>
> ( NAME = expr )
>
> I know that it was proposed before and this idea was rejected, because
> accidentally using '=' in place of '==' is a
On 04/24/2018 02:21 AM, Victor Stinner wrote:
WARNING! I was (strongly) opposed to PEP 448 Unpacking Generalizations
(ex: [1, 2, *list]) and PEP 498 f-string (f"Hello {name}"), whereas I
am now a happy user of these new syntaxes. So I'm not sure that I have
good tastes :-)
Cool, you're
On 24/04/18 17:11, Yury Selivanov wrote:
On Tue, Apr 24, 2018 at 12:03 PM, Ethan Furman wrote:
[..]
But I do write this:
def wrapper(func, some_value):
value_I_want = process(some_value)
def wrapped(*args, **kwds):
if value_I_want == 42:
...
On Wed, Apr 25, 2018 at 7:29 AM, Anthony Flury via Python-Dev
wrote:
> On 24/04/18 17:11, Yury Selivanov wrote:
>>
>> On Tue, Apr 24, 2018 at 12:03 PM, Ethan Furman wrote:
>> [..]
>>>
>>> But I do write this:
>>>
>>>def wrapper(func, some_value):
On 2018-04-23 15:36, Guido van Rossum wrote:
- the semantics are subtly different from all other uses of 'as' in Python; I'd
like to reserve 'as' for "not a plain assignment"
It's conceptually similar to "import as", no? The keyword "as" is a fuzzy yet
intuitive concept already.
Also,
On 2018-04-23 14:19, Barry Warsaw wrote:
Me too. Plus we *already* have precedence for spelling name bindings in
similar constructs, such as import statements, with statements, and exceptions.
It seems like a natural and Pythonic approach to extend that same spelling to
binding expressions
On 2018-04-24 02:21, Victor Stinner wrote:
> I have been asked to express myself on the PEP 572. I'm not sure that
Thanks. Well written and I've had the same thoughts myself.
___
Python-Dev mailing list
Python-Dev@python.org
On 04/24/2018 08:56 AM, Yury Selivanov wrote:
On Tue, Apr 24, 2018 at 11:51 AM, Ethan Furman wrote:
When I compare to variables from outer scopes they *usually* are on
the *right* side of '=='.
You mean something like
if 2 == x:
? I never write code like that, and
On Wed, Apr 25, 2018 at 2:23 AM, Steven D'Aprano wrote:
> On Tue, Apr 24, 2018 at 11:25:58AM -0400, Yury Selivanov wrote:
>
>> No, it doesn't. The check is performed during compile phase, and
>> Python does not unroll loops. Anyways, read below.
>
> What does unrolling loops
>
> Just reading this:
>
> https://www.bfilipek.com/2018/04/refactoring-with-c17-stdoptional.html
>
> about C++17, and what did I see? An example with a semicolon in
> parentheses!
>
Isn't that kind of the C++ motto? "Leave no syntactic stone unturned."
Whereas in Python, the syntax motto might
Hi,
I have been asked to express myself on the PEP 572. I'm not sure that
it's useful, but here is my personal opinion on the proposed
"assignment expressions".
PEP 572 -- Assignment Expressions:
https://www.python.org/dev/peps/pep-0572/
First of all, I concur with others: Chris Angelico did a
On Wed, Apr 25, 2018 at 1:56 AM, Yury Selivanov wrote:
> On Tue, Apr 24, 2018 at 11:51 AM, Ethan Furman wrote:
>
>>> When I compare to variables from outer scopes they *usually* are on
>>> the *right* side of '=='.
>>
>>
>> You mean something like
>>
On 2018-04-20 12:02, Jeroen Demeyer wrote:
One solution to improve backwards compatibility would be to duplicate
some classes. For example, make a separate class for bound methods in
extension types, which would be literally a duplicate of the existing
types.MethodType class (possibly with a
[Antoine]
> ...
> Yes... I think most will agree that Python is generally easy to take up
> for people coming from C++ etc., so my "easier to learn and teach" was
> mostly about non-programmers.
[Tim]
>> even for raw beginners the semantics are the tiniest part of what
>> they need to learn
On Apr 24, 2018, at 06:55, Antoine Pitrou wrote:
>
> If the ambition is to find a piece of syntax that reads as "binds",
> then we can use a variation on the FLUFL operator: "<->".
FLUFL Override Approved!
-Barry
signature.asc
Description: Message signed with OpenPGP
On Tue, Apr 24, 2018 at 12:03 PM, Ethan Furman wrote:
[..]
> But I do write this:
>
> def wrapper(func, some_value):
> value_I_want = process(some_value)
> def wrapped(*args, **kwds):
> if value_I_want == 42:
> ...
But this pattern is more rare than
On Wed, Apr 25, 2018 at 2:28 AM, Steven D'Aprano wrote:
> On Tue, Apr 24, 2018 at 10:58:24AM -0400, Yury Selivanov wrote:
>
>> Since 'diff' and 'g' must be new names according to rule (3), those
>> who read the code will notice that both were not previously bound.
>
> How am
On 2018-04-21 03:15, Tim Peters wrote:
[Tim]
>> And I'll take this opportunity to repeat the key point for me: I
>> tried hard, but never found a single case based on staring at real
>> code where allowing _fancier_ (than "plain name") targets would be a
>> real improvement. In every case I
[Chris Angelico ]
> Hopefully you have seen, or soon will see, the latest posting of the
> PEP, in which assignment targets are restricted to simple names. :)
I haven't yet, but look forward to it! You have the patience of a
saint to endure all this - I would have given up 6
On Tue, Apr 24, 2018 at 11:25:58AM -0400, Yury Selivanov wrote:
> No, it doesn't. The check is performed during compile phase, and
> Python does not unroll loops. Anyways, read below.
What does unrolling loops have to do with anything? And besides, loop
unrolling is an implementation detail --
On Tue, Apr 24, 2018 at 11:35:20AM -0400, Yury Selivanov wrote:
> Yes, it would force users to come up with better names *iff* they want
> to use this new sugar:
>
> if (first_target = get_first_candidate()) ...
> elif (second_target = get_second_candidate()) ...
They're not better names.
On Wed, Apr 25, 2018 at 2:40 AM, Tim Peters wrote:
> [Antoine]
>> ...
>> Yes... I think most will agree that Python is generally easy to take up
>> for people coming from C++ etc., so my "easier to learn and teach" was
>> mostly about non-programmers.
>
> [Tim]
>>> even for
On Wed, Apr 25, 2018 at 02:42:08AM +1000, Chris Angelico wrote:
> > from math import *
> > process(arg, (pi = 1), pi+1) # allowed
> That's not allowed at local scope (at least, it's not allowed at
> function scope - is there any other "local scope" at which it is
> allowed?).
Of
On Wed, Apr 25, 2018 at 2:57 AM, Steven D'Aprano wrote:
> On Wed, Apr 25, 2018 at 02:42:08AM +1000, Chris Angelico wrote:
>
>> > from math import *
>> > process(arg, (pi = 1), pi+1) # allowed
>
>
>> That's not allowed at local scope (at least, it's not allowed at
>>
On Tue, Apr 24, 2018 at 10:58:24AM -0400, Yury Selivanov wrote:
> Since 'diff' and 'g' must be new names according to rule (3), those
> who read the code will notice that both were not previously bound.
How am I supposed to notice that they've never been bound without
carefully reading through
On 2018-04-24 16:34, Jeroen Demeyer wrote:
On the other hand, if you are passing the function object, then you can
get __self__ from it (unless it's an unbound method: in that case
__self__ is NULL and self is really args[0]). So there wouldn't be a
need for passing "self". I'm not saying that
On Tue, Apr 24, 2018 at 10:29:11PM +0100, Anthony Flury via Python-Dev wrote:
> If Python is going to do assignment expressions we shouldn't overload
> parens in my opinion - we should have a separate operator - doing this
> avoids needing to exclude rebinding, and makes such expressions
>
[Tim]
>> Binding expressions are debugger-friendly in that they _don't_ just
>> vanish without a trace. It's their purpose to _capture_ the values of
>> the expressions they name. Indeed, you may want to add them all over
>> the place inside expressions, never intending to use the names, just
>>
On 2018-04-24 23:32, Cameron Simpson wrote:
On 24Apr2018 08:51, Ethan Furman wrote:
When I compare to variables from outer scopes they *usually* are on
the *right* side of '=='.
You mean something like
if 2 == x:
? I never write code like that, and I haven't seen it,
On Tue, Apr 24, 2018 at 08:10:49PM -0500, Tim Peters wrote:
> Binding expressions are debugger-friendly in that they _don't_ just
> vanish without a trace. It's their purpose to _capture_ the values of
> the expressions they name. Indeed, you may want to add them all over
> the place inside
On Tue, Apr 24, 2018 at 8:24 PM, Nick Coghlan wrote:
> I also think it would be good for the PEP to spell out the following
> semantic invariant for code running in a regular namespace:
>
> _rhs = expr
> assert (target := _rhs) is _rhs and target is _rhs
>
> It's the
On Tue, Apr 24, 2018 at 8:56 PM, Tim Peters wrote:
> It would actually be quite convenient, and far less error-prone, to
> add a binding construct inside a complicated expression for purposes
> of running under a debugger. The alternative is typing the
> sub-expression(s)
On 25 April 2018 at 03:01, Tim Peters wrote:
> assignment statement buried deep inside expressions. But in
> conventional use, "binding" is restricted to identifiers, which vastly
> simplifies the mental model for "the worst" that can happen.
[snip]
> But, in the absence
[Victor Stinner]
...
> Tim Peter gaves the following example. "LONG" version:
>
> diff = x - x_base
> if diff:
> g = gcd(diff, n)
> if g > 1:
>return g
>
> versus the "SHORT" version:
>
> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
>return g
>
> == Write ==
>
> If your
On 25 April 2018 at 06:23, Mike Miller wrote:
> Now, I agree that's not a difference of much consequence, but the difference
> from "import as" is not either.
Since this example has been brought up by a few folks now, I'll note
that "import x.y.z as c" has never been
On Tue, Apr 24, 2018 at 2:21 AM, Victor Stinner wrote:
> == Write code for babies! ==
>
> Please don't write code for yourself, but write code for babies! :-)
> These babies are going to maintain your code for the next 5 years,
> while you moved to a different team or project
We should really take this back to python-ideas at this point.
On Tue, Apr 24, 2018 at 3:16 PM, Antoine Pitrou wrote:
> On Tue, 24 Apr 2018 09:38:33 -0400
> Yury Selivanov wrote:
> > I propose to use the following syntax for assignment expressions:
On Tue, Apr 24, 2018 at 10:42:35PM +0200, Sven R. Kunze wrote:
> gcd(diff, n) is to me a perfect name, and please don't tell me g is
> better. ;)
Sorry, gcd(diff, n) is not the "perfect name", and I will tell you that
sometimes g is better.
Which would you prefer to see and read?
g =
On 24Apr2018 08:51, Ethan Furman wrote:
When I compare to variables from outer scopes they *usually* are on
the *right* side of '=='.
You mean something like
if 2 == x:
? I never write code like that, and I haven't seen it, either.
Just to this, I also never write
On Wed, Apr 25, 2018 at 1:43 PM, Steven D'Aprano wrote:
> On Tue, Apr 24, 2018 at 08:10:49PM -0500, Tim Peters wrote:
>
>> Binding expressions are debugger-friendly in that they _don't_ just
>> vanish without a trace. It's their purpose to _capture_ the values of
>> the
Nick Coghlan wrote:
I'd be +0 on an "is=" spelling
But "is=' looks like some kind of comparison
operator. This seems even more conusing to me.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
On 2018-04-24 21:05, Nathaniel Smith wrote:
On Tue, Apr 24, 2018 at 8:56 PM, Tim Peters wrote:
It would actually be quite convenient, and far less error-prone, to
add a binding construct inside a complicated expression for purposes
of running under a debugger. The
On Tue, Apr 24, 2018 at 03:54:30PM -0700, Guido van Rossum wrote:
> We should really take this back to python-ideas at this point.
Please no :-(
Variants of "let" etc were discussed earlier and didn't seem to get much
interest. Although I don't think "var" specifically was suggested
before,
On 25 April 2018 at 13:56, Guido van Rossum wrote:
> On Tue, Apr 24, 2018 at 8:24 PM, Nick Coghlan wrote:
>>
>> I also think it would be good for the PEP to spell out the following
>> semantic invariant for code running in a regular namespace:
>>
>> _rhs
On Tue, Apr 24, 2018 at 4:27 PM, Antoine Pitrou wrote:
> On Tue, 24 Apr 2018 01:06:30 -0500
> Tim Peters wrote:
>>
>> > - does it make Python easier to learn and teach?
>>
>> By whom? Almost no addition has ever made a language easier to learn
>> for
On Tue, Apr 24, 2018 at 5:23 PM, Greg Ewing wrote:
> Stephen J. Turnbull wrote:
>>
>> Neologisms are usually written in the
>> other order: "dead on arrival (DOA, for short)." ;-)
>
>
> Maybe we can make use of that?
>
>if (x - x_base) (diff) and gcd(diff, n) (g)
[Stephen J. Turnbull[
>> Neologisms are usually written in the other order:
>> "dead on arrival (DOA, for short)." ;-)
[Greg Ewing ]
> Maybe we can make use of that?
>
>if (x - x_base) (diff) and gcd(diff, n) (g) > 1:
>
> That doesn't work, because the (...) look
On 24 April 2018 at 08:12, Greg Ewing wrote:
> Chris Jerdonek wrote:
>
> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
>>>
> "if diff, which we let equal x - x_base, and g, which ..." or
>> "if diff, which we set equal to x - x_base, and g, which " or
On Tue, 24 Apr 2018 16:38:39 +1000
Chris Angelico wrote:
> On Tue, Apr 24, 2018 at 4:27 PM, Antoine Pitrou wrote:
> > On Tue, 24 Apr 2018 01:06:30 -0500
> > Tim Peters wrote:
> >>
> >> > - does it make Python easier to learn and
Chris Jerdonek wrote:
if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
"if diff, which we let equal x - x_base, and g, which ..." or
"if diff, which we set equal to x - x_base, and g, which " or
"if diff, which we define to be x - x_base, and g, which " or
"if diff, which we
Stephen J. Turnbull wrote:
Neologisms are usually written in the
other order: "dead on arrival (DOA, for short)." ;-)
Maybe we can make use of that?
if (x - x_base) (diff) and gcd(diff, n) (g) > 1:
That doesn't work, because the (...) look like function
calls. But what if we used a
[Steve Holden ]
>> ...
>> The assignment expression seems like a vary natural way to introduce
>> variables of limited (controlled?) scope, [...]
[Antoine Pitrou ]
> AFAIU, the scope isn't limited to the "if" block, it's a regular local
> variable. I
On Tue, 24 Apr 2018 01:06:30 -0500
Tim Peters wrote:
>
> > - does it make Python easier to learn and teach?
>
> By whom? Almost no addition has ever made a language easier to learn
> for raw beginners: every addition is something they eventually need
> to learn. We
[Antoine]
>>> - does it make Python easier to learn and teach?
[Tim]
>> By whom? Almost no addition has ever made a language easier to learn
>> for raw beginners: every addition is something they eventually need
>> to learn. We could make Python easier to learn for beginners by
>> throwing out
On Tue, Apr 24, 2018 at 5:12 PM, Greg Ewing wrote:
> Chris Jerdonek wrote:
>
if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
>
>
>> "if diff, which we let equal x - x_base, and g, which ..." or
>> "if diff, which we set equal to x - x_base, and g, which
[Antoine Pitrou ]
> ...
> Having to break things out over multiple lines is a fact of life, if
> only for readability when implementing (and maintaining!) non-trivial
> processing routines. It's a good thing to be used to it, and to learn to
> choose good names for
In PEP 573, instead of passing the defining class to the C function, why
not pass the function object itself? That is far more general: once you
have the function object, you can still access the defining class using
your PyCMethod_CLASS. It's also more future-proof: if we ever decide to
add
On Tue, 24 Apr 2018 01:55:13 -0500
Tim Peters wrote:
> [Antoine]
> > Constructs like "with ..." or "try / except / finally" make the
> > language easier to learn compared to the dances they are meant to
> > replace.
>
> They nevertheless need to be taught & learned (and
On 24/04/2018 02:42, Chris Jerdonek wrote:
On Mon, Apr 23, 2018 at 4:54 PM, Greg Ewing wrote:
Tim Peters wrote:
if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
return g
My problem with this is -- how do you read such code out loud?
It could be...
"if
On 24 April 2018 at 18:17, Jeroen Demeyer wrote:
> In PEP 573, instead of passing the defining class to the C function, why not
> pass the function object itself? That is far more general: once you have the
> function object, you can still access the defining class using your
What facilities does the interpreter currently have for extracting common
subexpressions, and how would it verify in such a dynamic environment that
such extractions wouldn't alter the semantics of the program? Explicit
(assignment using :=) is better than implicit (by optimizations hidden to
the
I do think the pronunciation issue that Greg notices is important. I teach
Python for most of my living, and reading and discussing code segments is
an important part of that. When focussing on how Python actually *spells*
something, you can't always jump to the higher-level meaning of a
If PEP 575's new call doesn't have any surprising restrictions,
I think that completely dropping METH_METHOD would be the
best way of resolving this.
I suggest we push PEP 575 first and if it gets accepted, I will rebase
PEP 573 to these changes.
On Tue, Apr 24, 2018 at 4:34 PM, Jeroen Demeyer
On 24/04/18 14:50, Yury Selivanov wrote:
On Tue, Apr 24, 2018 at 9:46 AM, Nick Coghlan wrote:
On 24 April 2018 at 23:38, Yury Selivanov wrote:
I propose to use the following syntax for assignment expressions:
( NAME = expr )
I know that it
On Tue, Apr 24, 2018 at 10:56 AM, Chris Angelico wrote:
[..]
>> A lot of other questions arise though. PEP 572 proposes:
>>
>> a = 1 # assignment
>> a := 1 # also assignment
>> (a := 1) # also assignment
>> (a = 1) # error, why?
>
> Your third example is just the same as
Thanks for thinking this through, Yury. :)
FWIW, I'm still unconvinced that an assignment expression is worth it.
It's hard to say, though, without seeing how much folks would actually
use it (and I don't have my own time machine unfortunately). IIRC, in
the past several proposed syntax (e.g.
On Tue, Apr 24, 2018 at 10:49 AM, Paul Moore wrote:
[..]
>>> 3. Most importantly: it is *not* allowed to mask names in the current
>>> local scope.
>>
>> While I agree this would be unambiguous to a computer, I think for
>> most humans it would be experienced as a confusing
On Wed, Apr 25, 2018 at 12:54 AM, Anthony Flury via Python-Dev
wrote:
> As discussed previously by others on this exact proposals, you now have the
> issue of confusion when using keyword arguments : *my_func(a = b)* :
> clearly that is a call to `my_func' where argument a
On Tue, Apr 24, 2018 at 10:54 AM, Anthony Flury via Python-Dev
wrote:
[..]
> As discussed previously by others on this exact proposals, you now have the
> issue of confusion when using keyword arguments : *my_func(a = b)* :
> clearly that is a call to `my_func' where
On 24 April 2018 at 15:58, Yury Selivanov wrote:
> On Tue, Apr 24, 2018 at 10:49 AM, Paul Moore wrote:
> [..]
3. Most importantly: it is *not* allowed to mask names in the current
local scope.
>>>
>>> While I agree this would be unambiguous
On Wed, Apr 25, 2018 at 1:03 AM, Yury Selivanov wrote:
> On Tue, Apr 24, 2018 at 10:56 AM, Chris Angelico wrote:
> [..]
>>> A lot of other questions arise though. PEP 572 proposes:
>>>
>>> a = 1 # assignment
>>> a := 1 # also assignment
>>> (a := 1)
On Wed, Apr 25, 2018 at 12:58 AM, Yury Selivanov
wrote:
> On Tue, Apr 24, 2018 at 10:49 AM, Paul Moore wrote:
> [..]
3. Most importantly: it is *not* allowed to mask names in the current
local scope.
>>>
>>> While I agree this would be
On Tue, Apr 24, 2018 at 09:50:34AM -0400, Yury Selivanov wrote:
> On Tue, Apr 24, 2018 at 9:46 AM, Nick Coghlan wrote:
> > On 24 April 2018 at 23:38, Yury Selivanov wrote:
> >> I propose to use the following syntax for assignment expressions:
> >>
>
On Tue, Apr 24, 2018 at 11:07 AM, Chris Angelico wrote:
[..]
> x = 1
> if (x = 2): ...
>
> This, according to your proposal, raises SyntaxError - not because a
> comparison was wanted and an assignment was made, but because the name
> already had a value. And, even worse, this
Yury Selivanov wrote:
> I propose to use the following syntax for assignment expressions:
>
> ( NAME = expr )
Yury, did you notice the subthread [1] that discusses the merits and
problems of the same idea (except for your point 3)?
[1]
I propose to use the following syntax for assignment expressions:
( NAME = expr )
I know that it was proposed before and this idea was rejected, because
accidentally using '=' in place of '==' is a pain point in
C/C++/JavaScript.
That said, I believe we can still use this syntax as long as
On 24 April 2018 at 22:30, David Mertz wrote:
> I do think the pronunciation issue that Greg notices is important. I teach
> Python for most of my living, and reading and discussing code segments is an
> important part of that. When focussing on how Python actually *spells*
>
On 24 April 2018 at 23:38, Yury Selivanov wrote:
> I propose to use the following syntax for assignment expressions:
>
> ( NAME = expr )
>
> I know that it was proposed before and this idea was rejected, because
> accidentally using '=' in place of '==' is a pain
On Tue, Apr 24, 2018 at 9:46 AM, Nick Coghlan wrote:
> On 24 April 2018 at 23:38, Yury Selivanov wrote:
>> I propose to use the following syntax for assignment expressions:
>>
>> ( NAME = expr )
>>
>> I know that it was proposed before and this
On Tue, 24 Apr 2018 23:46:34 +1000
Nick Coghlan wrote:
> On 24 April 2018 at 23:38, Yury Selivanov wrote:
> > I propose to use the following syntax for assignment expressions:
> >
> > ( NAME = expr )
> >
> > I know that it was proposed before and
On 24 April 2018 at 23:50, Yury Selivanov wrote:
> On Tue, Apr 24, 2018 at 9:46 AM, Nick Coghlan wrote:
>> On 24 April 2018 at 23:38, Yury Selivanov wrote:
>>> I propose to use the following syntax for assignment expressions:
On Tue, Apr 24, 2018 at 10:07 AM, Nick Coghlan wrote:
>> "=" is always an assignment.
>> "==" is always an equality check.
>
> That's not the distinction I meant, I meant the difficulty of
> explaining the discrepancies in this list:
>
> a = 1 # Assignment
> (a = 1) # Also
On 2018-04-24 14:53, Nick Coghlan wrote:
In PEP 575, I'm already proposing a flag (METH_ARG0_FUNCTION) to pass the
function *instead* of self. Unless PEP 573 is rejected, maybe that should
change to passing the function *in addition* to self.
That would definitely be an elegant way of
On 24 April 2018 at 14:46, Nick Coghlan wrote:
> On 24 April 2018 at 23:38, Yury Selivanov wrote:
>> I propose to use the following syntax for assignment expressions:
>>
>> ( NAME = expr )
>>
>> I know that it was proposed before and this idea was
On 04/23/2018 06:42 PM, Chris Jerdonek wrote:
On Mon, Apr 23, 2018 at 4:54 PM, Greg Ewing wrote:
Tim Peters wrote:
if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
return g
My problem with this is -- how do you read such code out loud?
It could be--
"if diff, which we let
On 25 April 2018 at 00:23, Yury Selivanov wrote:
> A lot of other questions arise though. PEP 572 proposes:
>
> a = 1 # assignment
> a := 1 # also assignment
> (a := 1) # also assignment
> (a = 1) # error, why?
That's just the typical assignment/expression
On Wed, Apr 25, 2018 at 12:23 AM, Yury Selivanov
wrote:
> On Tue, Apr 24, 2018 at 10:07 AM, Nick Coghlan wrote:
>
>>> "=" is always an assignment.
>>> "==" is always an equality check.
>>
>> That's not the distinction I meant, I meant the difficulty
On 25 April 2018 at 00:54, Eric Snow wrote:
> Regardless, your 3 rules would benefit either syntax. Nick may have a
> point that the rules might be an excessive burden, but I don't think
> it's too big a deal since the restrictions are few (and align with the
> most
On Tue, Apr 24, 2018 at 11:15 AM, Steven D'Aprano wrote:
[..]
>> >> 3. Most importantly: it is *not* allowed to mask names in the current
>> >> local scope.
>
> That means you can't rebind existing variables. That means you can't
> rebind to the same variable in a loop.
No,
The most notable change since last posting is that the assignment
target is no longer as flexible as with the statement form of
assignment, but is restricted to a simple name.
Note that the reference implementation has not been updated.
ChrisA
PEP: 572
Title: Assignment Expressions
Author:
On Tue, Apr 24, 2018 at 11:03:35AM -0400, Yury Selivanov wrote:
> My point was that when you see lots of '=' and ':=' used at the
> statement level, one might try to write "if x = 1" instead of "if x :=
> 1" -- boom, we have an unexpected SyntaxError for some users.
That's a *good* thing. They
On Tue, Apr 24, 2018 at 11:31 AM, Nick Coghlan wrote:
> On 25 April 2018 at 00:54, Eric Snow wrote:
>> Regardless, your 3 rules would benefit either syntax. Nick may have a
>> point that the rules might be an excessive burden, but I don't think
On Wed, Apr 25, 2018 at 1:15 AM, Steven D'Aprano wrote:
> By the way, the check for existing variables cannot help to be either
> incomplete or incorrect if you try to do it at compile time:
>
>
> from module import *
> (x = 2) # allowed or not allowed?
>
>
> If you
On Tue, Apr 24, 2018 at 11:27 AM, Steven D'Aprano wrote:
> On Tue, Apr 24, 2018 at 11:03:35AM -0400, Yury Selivanov wrote:
>
>> My point was that when you see lots of '=' and ':=' used at the
>> statement level, one might try to write "if x = 1" instead of "if x :=
>> 1" --
1 - 100 of 107 matches
Mail list logo