Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

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

Re: [Python-Dev] assignment expressions: an alternative alternative proposal

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,

Re: [Python-Dev] PEP 572: Assignment Expressions

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

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

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

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

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)

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

[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 >>

Re: [Python-Dev] PEP 572: Assignment Expressions

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

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

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

Re: [Python-Dev] PEP 572: Assignment Expressions

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

Re: [Python-Dev] PEP 572: Assignment Expressions

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

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

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

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

[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

Re: [Python-Dev] assignment expressions: an alternative proposal

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,

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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 >

Re: [Python-Dev] PEP 572: 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 =

Re: [Python-Dev] assignment expressions: an alternative alternative proposal

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:

Re: [Python-Dev] assignment expressions: an alternative alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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):

Re: [Python-Dev] assignment expressions: an alternative proposal

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: ...

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

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

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

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

Re: [Python-Dev] PEP 572: Assignment Expressions

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

Re: [Python-Dev] PEP 572: Assignment Expressions

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

Re: [Python-Dev] PEP 572: Assignment Expressions

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

Re: [Python-Dev] PEP 572: Assignment Expressions

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

Re: [Python-Dev] PEP 572: Assignment Expressions

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

Re: [Python-Dev] PEP 572: Assignment Expressions

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,

Re: [Python-Dev] PEP 572: Assignment Expressions

> > 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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] PEP 572: Assignment Expressions

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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 >>

Re: [Python-Dev] PEP 575: Unifying function/method classes

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

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods

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

[Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

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

Re: [Python-Dev] PEP 572: Assignment Expressions

[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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] PEP 572: Assignment Expressions

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] PEP 572: Assignment Expressions

[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

Re: [Python-Dev] assignment expressions: an alternative proposal

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.

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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 --

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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 >>

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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 I haven't seen it, either. Hm. I

Re: [Python-Dev] assignment expressions: an alternative proposal

On 25 April 2018 at 01:35, Yury Selivanov wrote: > On Tue, Apr 24, 2018 at 11:31 AM, Nick Coghlan wrote: >> I *do* think the "no name rebinding except in a while loop header" >> restriction would be annoying for the if/elif use case and the while >>

Re: [Python-Dev] assignment expressions: an alternative proposal

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 barely >> readable to my eye. > > There's no advantage to using binding-expressions unless

Re: [Python-Dev] assignment expressions: an alternative proposal

On 04/24/2018 08:35 AM, 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()) ... And then the common code below that only cares

Re: [Python-Dev] assignment expressions: an alternative proposal

On 04/24/2018 08:19 AM, Yury Selivanov wrote: Yes, because I'm trying to think about this from a pragmatic side of things. My question to myself: "what syntax could I use that would prevent me from making '=' vs '==' mistake when I code?" To me, the answer is that I usually want to compare

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:28 AM, Chris Angelico wrote: > On re-thinking this, I think the distinction IS possible, but (a) only > in function/class scope, not at global; and (b) would be defined in > terms of lexical position, not run-time. For instance: > > def f(): > (a

Re: [Python-Dev] assignment expressions: an alternative proposal

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" --

Re: [Python-Dev] assignment expressions: an alternative proposal

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 barely > readable to my eye. 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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

[Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

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:

Re: [Python-Dev] assignment expressions: an alternative proposal

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,

Re: [Python-Dev] assignment expressions: an alternative proposal

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

[Python-Dev] assignment expressions: an alternative proposal

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]

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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: > >> >

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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)

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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.

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] PEP 572: Assignment Expressions

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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:

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] assignment expressions: an alternative proposal

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

[Python-Dev] assignment expressions: an alternative proposal

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

Re: [Python-Dev] PEP 572: Assignment Expressions

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* >

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods

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

Re: [Python-Dev] PEP 572: Assignment Expressions

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

Re: [Python-Dev] PEP 572: Assignment Expressions

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

Re: [Python-Dev] PEP 572: Assignment Expressions

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

Re: [Python-Dev] PEP 572: Assignment Expressions

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

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods

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

Re: [Python-Dev] PEP 572: Assignment Expressions

[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

Re: [Python-Dev] PEP 572: Assignment Expressions

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

Re: [Python-Dev] PEP 572: Assignment Expressions

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)

Re: [Python-Dev] PEP 572: Assignment Expressions

[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

Re: [Python-Dev] PEP 572: Assignment Expressions

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

  1   2   >