On Tue, Apr 24, 2018 at 8:31 AM, Chris Angelico wrote:
> 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 updat
On 4/24/2018 8:56 PM, Tim Peters wrote:
The alternative is typing the
sub-expression(s) of interest by hand at the debugger prompt, or
adding print()s, both of which are prone to introducing typos, or
changing results radically due to triggering side effects in the code
invoked by the duplicate
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
https://mail.python.org/mailman/listinfo/python-
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 alternative is typing 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, "l
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 = expr
>> assert (target := _rhs)
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 expressions they name. In
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) of interest by hand at t
[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 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 restriction to single
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 expr
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 entirely equivalent to a
simp
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 of Guido chiming in, it
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 in the meanwhile. Be
[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 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, either.
Just to thi
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 code like that but I've
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
> cons
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 = gcd(diff
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:
> >
> > ( NAME = expr )
> >
> > I know tha
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 pain point in
> C/C++/Jav
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):
>>> value_I_want = process(some_value)
>>
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:
...
But this pattern is m
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 against
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
https://mail.python.org/
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 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 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 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 expressio
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 value, how are they
not the sam
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, thes
>
> 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 be
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 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 tho
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
>> function scope - is th
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 diff
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 th
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 g
[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 years ago ;-)
> Tho
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 cours
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 raw beginners the seman
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 have to do with anythi
[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 anyway
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. Ad
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 I supposed to notice t
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 -- m
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 t
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 comparing local variab
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 binding-expressions unless you're going to
>>> re-use the name you just defin
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
>>
>> if 2 == x:
>>
>> ? I never write code li
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 I haven't seen it, e
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 barely
>>> readable to my eye.
>>
>> There's no adv
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 mean this:
const
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
>> use case:
>>
>> while (item = get_item()) i
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 you're going to
> re-
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 abou
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 loca
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 = 1) # Legal; 'a' h
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" -- boom, we have an unexpe
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 hint
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 don't like wild-card i
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
>> it's too big a deal since the restrictions are f
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 wi
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: Chri
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, it doesn't. The check
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 likely usage) and are limited
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] https://mail.python.org/pipermail/python-dev/2018-April/1
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 is NOT an error:
Y
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:
> >>
> >> ( NAME = expr )
> >>
> >> I know that it
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 unambiguous to a computer, I think for
>>> most hum
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) # also assignment
>>> (a = 1) # error, why
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 to a computer, I think for
>>> most humans it
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 argument a has the value of b
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 has the value of b, but
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 set of arcane and
>> ar
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. dec
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 the second, with pare
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 was proposed before and this idea was rejected
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 wr
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 of
>> explaining the discrepancies in this list
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 dichotomy, though, which
is genuine
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 rejected, because
>> accidentally using '=' i
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 addressin
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 assignment
>
> a, b = 1
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 equal
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:
>>>
>>> ( NAME = expr )
>>>
>>> I know that it was proposed before
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 this idea was rejected, because
> > accidental
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 idea was rejected, because
>> accidentally using
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 point in
> C/C++/JavaScript.
>
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 w
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*
> something, you can'
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
> PyCMethod_CLASS. It
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
construc
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 p
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 try/except/finally
> was
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 diff, which we define as x - x
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 ev
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
>> "if diff, which we define
[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 like function
> calls. But wha
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) > 1:
>
> That doesn't work, be
1 - 100 of 105 matches
Mail list logo
