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 teach?
> >>
> >> By whom? Almost no addition has ever made a
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 defin
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 differe
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 " or
>> "if diff, which we def
[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 intermediate variables.
Well, th
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
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
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/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
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
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
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
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
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'
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 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.
>
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 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 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 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 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 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 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 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 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
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 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
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
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: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
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: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 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 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 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 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 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
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 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
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
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: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
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 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: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 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: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 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 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 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 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: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 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 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: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 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 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 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 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 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: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
[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 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
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 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
[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
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
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
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 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-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 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
>
> 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 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
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 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 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 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 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 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 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 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 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
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, 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
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 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 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
[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 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
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 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 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 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
[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: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
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 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)
1 - 100 of 105 matches
Mail list logo
