On Wed, 4 Jul 2018 at 07:42 Antoine Pitrou wrote:
> On Wed, 4 Jul 2018 09:43:04 -0300
> Brett Cannon wrote:
> >
> > I think this is a very key point that the "this is bad" crowd is
> > overlooking. Even if this syntax turns out to not be that useful, abusing
> > the walrus operator can be fixed
On 2018-07-04 00:25, Nathaniel Smith wrote:
The only cases that seem potentially valuable to me are the ones that
are literally the form 'if := ` and 'while :=
'. (I suspect these are the only cases that I would allow in
code that I maintain.) The PEP does briefly discuss the alternative
On Wed, Jul 4, 2018 at 7:42 PM Steven D'Aprano wrote:
> On Wed, Jul 04, 2018 at 01:00:41PM -0700, Devin Jeanpierre wrote:
> > On Wed, Jul 4, 2018 at 11:04 AM Steven D'Aprano wrote:
> > > Did you actually mean arbitrary simple statements?
> > >
> > > if import math; mylist.sort(); print("WTF am I
On Wed, Jul 4, 2018 at 7:20 AM, David Mertz wrote:
>
> That said, this is a silly game either way. And even though you CAN
> (sometimes) bind in an expression pre-572, that's one of those perverse
> corners that one shouldn't actually use.
>
not only shouldn't by hardly anyone ever does /
On 7/4/2018 3:34 PM, Steven D'Aprano wrote:
On Wed, Jul 04, 2018 at 03:24:08PM -0400, Terry Reedy wrote:
On 7/4/2018 9:35 AM, Steven D'Aprano wrote:
On Wed, Jul 04, 2018 at 05:02:07PM +1000, Chris Angelico wrote:
On Wed, Jul 4, 2018 at 4:07 PM, Serhiy Storchaka
wrote:
"Assignment is a
On 7/4/2018 2:32 PM, Sven R. Kunze wrote:
Sorry for adding yet another mail. :-(
On 04.07.2018 10:54, Serhiy Storchaka wrote:
Sorry, this PEP was rewritten so many times that I missed your Appendix.
while total != (total := total + term):
term *= mx2 / (i*(i+1))
i += 2
return total
On 7/4/2018 1:50 PM, Yury Selivanov wrote:
On Wed, Jul 4, 2018 at 1:35 PM Ivan Pozdeev via Python-Dev
wrote:
On 04.07.2018 11:54, Serhiy Storchaka wrote:
while total != (total := total + term):
term *= mx2 / (i*(i+1))
i += 2
return total
This code looks clever that the original
On Wed, Jul 04, 2018 at 01:00:41PM -0700, Devin Jeanpierre wrote:
> On Wed, Jul 4, 2018 at 11:04 AM Steven D'Aprano wrote:
> > Did you actually mean arbitrary simple statements?
> >
> > if import math; mylist.sort(); print("WTF am I reading?"); True:
> > pass
>
> Yes.
Okay, you just broke
On 04.07.2018 4:26, Tim Peters wrote:
[INADA Naoki]
> ...
> On the other hand, I understand PEP 572 allows clever code
> simplifies tedious code. It may increase readability of non-dirty
code.
The latter is the entire intent ,of course. We can't force people to
write readable code, but I
On 04.07.2018 21:18, Steven D'Aprano wrote:
Read the Appendix to the PEP:
https://github.com/python/peps/blob/master/pep-0572.rst
Yes, I did after I realized where that example came from. But my point
was actually to understand the evaluation order because Uncle Timmy
won't be around to
On Wed, Jul 4, 2018 at 11:04 AM Steven D'Aprano wrote:
> Did you actually mean arbitrary simple statements?
>
> if import math; mylist.sort(); print("WTF am I reading?"); True:
> pass
Yes. To quote PEP 572: "This is a tool, and it is up to the programmer
to use it where it makes sense, and
On Wed, Jul 04, 2018 at 03:24:08PM -0400, Terry Reedy wrote:
> On 7/4/2018 9:35 AM, Steven D'Aprano wrote:
> >On Wed, Jul 04, 2018 at 05:02:07PM +1000, Chris Angelico wrote:
> >>On Wed, Jul 4, 2018 at 4:07 PM, Serhiy Storchaka
> >>wrote:
> >
> >>"Assignment is a statement" -- that's exactly the
On 7/4/2018 9:35 AM, Steven D'Aprano wrote:
On Wed, Jul 04, 2018 at 05:02:07PM +1000, Chris Angelico wrote:
On Wed, Jul 4, 2018 at 4:07 PM, Serhiy Storchaka wrote:
"Assignment is a statement" -- that's exactly the point under discussion.
I believe that this is Chris quoting and commenting
On Wed, Jul 04, 2018 at 08:32:32PM +0200, Sven R. Kunze wrote:
> >>while total != (total := total + term):
> >> term *= mx2 / (i*(i+1))
> >> i += 2
> >>return total
>
> This very example here caught my eye.
>
> Isn't total not always equal to total? What would "regular" Python have
>
On Wed, Jul 4, 2018, 09:09 Steven D'Aprano wrote:
> On Wed, Jul 04, 2018 at 12:10:11AM -0700, Nathaniel Smith wrote:
>
> > Right, Python has a *very strong* convention that each line should
> > have at most one side-effect,
>
> import math, fractions, decimal
>
> (PEP 8 be damned, sometimes,
Sorry for adding yet another mail. :-(
On 04.07.2018 10:54, Serhiy Storchaka wrote:
Sorry, this PEP was rewritten so many times that I missed your Appendix.
while total != (total := total + term):
term *= mx2 / (i*(i+1))
i += 2
return total
This very example here caught my eye.
On Tue, Jul 3, 2018 at 11:52 PM Chris Angelico wrote:
> On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka
> wrote:
> > I believe most Python users are not
> > professional programmers -- they are sysadmins, scientists, hobbyists and
> > kids --
>
> [citation needed]
>
Let's focus on France:
1)
On Wed, Jul 4, 2018 at 2:16 PM Tim Peters wrote:
>
> [Yury Selivanov]
> > Wow, I gave up on this example before figuring this out (and I also
>
> > stared at it for a good couple of minutes). Now it makes sense. It's
>
> > funny that this super convoluted snippet is shown as a good example
>
>
On Wed, Jul 4, 2018 at 12:36 PM Stéfane Fermigier wrote:
>
> And dissimilar to countries where CS is not taught in schools, or another
> language is used (Scratch or other block-languages are usually popular).
>
Just found:
On 04/07/2018 02:54, Terry Reedy wrote:
The 2-argument form of iter is under-remembered and under-used. The
length difference is 8.
while (command := input("> ")) != "quit":
for command in iter(lambda: input("> "), "quit"):
A general principle that Chris Angelico has repeatedly
Forwarding the reply to the list. Accidentally pressed the wrong button and
sent this message personally to Serhiy. Sorry :)
ср, 4 июл. 2018 г. в 11:57, Serhiy Storchaka :
> > if reductor := dispatch_table.get(cls):
> > rv = reductor(x)
> > elif reductor := getattr(x, "__reduce_ex__", None):
On Wed, Jul 04, 2018 at 08:33:17PM +0300, Ivan Pozdeev via Python-Dev wrote:
> >>while total != (total := total + term):
> >> term *= mx2 / (i*(i+1))
> >> i += 2
> >>return total
[...]
> It took me a few minutes to figure out that this construct actually
> checks term == 0.
That's badly
[Yury Selivanov]
> Wow, I gave up on this example before figuring this out (and I also
> > stared at it for a good couple of minutes). Now it makes sense. It's
> > funny that this super convoluted snippet is shown as a good example
> > for PEP 572. Although almost all PEP 572 examples are
On Wed, Jul 04, 2018 at 10:13:15AM -0700, Devin Jeanpierre wrote:
> > > In Python it'd look like this:
> > >
> > > if x = expr(); x < 0:
> > > do_stuff()
[...]
> > Python's parser is restricted to LL(1) by design, so treating semicolons
> > in "if" statements as a special case might not even
[Serhiy Storchaka]
> > Sorry, this PEP was rewritten so many times that I missed your
> [Tim's] Appendix.
> >
> >> while total != (total := total + term):
> >> term *= mx2 / (i*(i+1))
> >> i += 2
> >> return total
> >
> > This code looks clever that the original while loop with a
On Wed, Jul 4, 2018 at 1:35 PM Ivan Pozdeev via Python-Dev
wrote:
>
> On 04.07.2018 11:54, Serhiy Storchaka wrote:
> >> while total != (total := total + term):
> >> term *= mx2 / (i*(i+1))
> >> i += 2
> >> return total
> >
> > This code looks clever that the original while loop with a
On 04.07.2018 11:54, Serhiy Storchaka wrote:
04.07.18 10:06, Tim Peters пише:
[Tim]
>> I really don't know what Guido likes best about this, but for me
it's
>> the large number of objectively small wins in `if` and `while`
>> contexts. They add up. That conclusion surprised me. That
On Wed, Jul 4, 2018 at 6:36 AM Steven D'Aprano wrote:
>
> On Wed, Jul 04, 2018 at 01:03:02AM -0700, Devin Jeanpierre wrote:
>
> > The PEP doesn't talk about it, but FWIW, Go and C++17 if statements
> > allow you to put arbitrary simple statements in the suite header, and
> > by doing that, solves
On Wed, Jul 4, 2018 at 12:13 PM Steven D'Aprano wrote:
> On Wed, Jul 04, 2018 at 10:20:35AM -0400, David Mertz wrote:
> > Hmmm... I admit I didn't expect quite this behavior. I'm don't actually
> > understand why it's doing what it does.
> >
> > >>> def myfun():
> > ...
On Wed, Jul 04, 2018 at 10:20:35AM -0400, David Mertz wrote:
> Hmmm... I admit I didn't expect quite this behavior. I'm don't actually
> understand why it's doing what it does.
>
> >>> def myfun():
> ...print(globals().update({'foo', 43}), foo)
Try it with a dict {'foo': 43} instead of a set
On Wed, Jul 04, 2018 at 12:10:11AM -0700, Nathaniel Smith wrote:
> Right, Python has a *very strong* convention that each line should
> have at most one side-effect,
import math, fractions, decimal
(PEP 8 be damned, sometimes, especially in the REPL, this is much
better than three separate
On Wed, 4 Jul 2018 09:43:04 -0300
Brett Cannon wrote:
>
> I think this is a very key point that the "this is bad" crowd is
> overlooking. Even if this syntax turns out to not be that useful, abusing
> the walrus operator can be fixed with a comment of "hard to follow; please
> simplify" without
Hmmm... I admit I didn't expect quite this behavior. I'm don't actually
understand why it's doing what it does.
>>> def myfun():
...print(globals().update({'foo', 43}), foo)
...
>>> myfun()
Traceback (most recent call last):
File "", line 1, in
File "", line 2, in myfun
TypeError: cannot
On Wed, Jul 4, 2018 at 11:52 PM, David Mertz wrote:
> On Wed, Jul 4, 2018 at 3:02 AM Chris Angelico wrote:
>>
>> "Assignment is a statement" -- that's exactly the point under discussion.
>> "del is a statement" -- yes, granted
>> "function and class declarations are statements" -- class, yes,
On Wed, Jul 4, 2018 at 3:02 AM Chris Angelico wrote:
> "Assignment is a statement" -- that's exactly the point under discussion.
> "del is a statement" -- yes, granted
> "function and class declarations are statements" -- class, yes, but
> you have "def" and "lambda" as statement and expression
On Wed, Jul 04, 2018 at 05:02:07PM +1000, Chris Angelico wrote:
> On Wed, Jul 4, 2018 at 4:07 PM, Serhiy Storchaka wrote:
> "Assignment is a statement" -- that's exactly the point under discussion.
Not any more it isn't. We've now gone from discussion to bitter
recriminations *wink*
> "del
On Wed, Jul 04, 2018 at 01:03:02AM -0700, Devin Jeanpierre wrote:
> The PEP doesn't talk about it, but FWIW, Go and C++17 if statements
> allow you to put arbitrary simple statements in the suite header, and
> by doing that, solves all the issues you and the PEP mentioned.
Whether they solve
On Tue, Jul 03, 2018 at 03:24:09PM -0700, Chris Barker via Python-Dev wrote:
> Over the years I've been using it (most of its life), Python has evolved to
> become much less of a "scripting" language, and much more of a "systems"
> language, and this addition is a (pretty significant) step more
On Tue, Jul 3, 2018, 22:27 Tim Peters, wrote:
> [INADA Naoki]
> > ...
> > On the other hand, I understand PEP 572 allows clever code
> > simplifies tedious code. It may increase readability of non-dirty
> code.
>
> The latter is the entire intent ,of course. We can't force people to
> write
On Wed, Jul 4, 2018 at 7:59 PM, Stéfane Fermigier wrote:
>
>
> On Tue, Jul 3, 2018 at 11:52 PM Chris Angelico wrote:
>>
>> On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka
>> wrote:
>> > I believe most Python users are not
>> > professional programmers -- they are sysadmins, scientists,
2018-07-04 9:58 GMT+02:00 Serhiy Storchaka :>
04.07.18 05:42, Steven D'Aprano пише:
>> There is a deferred feature request to optimize "for x in [item]" as
>> equivalent to "for x in (item,)", to avoid constructing a list:
>>
>> https://bugs.python.org/issue32856
>
>
> No, this optimization was
04.07.18 10:06, Tim Peters пише:
[Tim]
>> I really don't know what Guido likes best about this, but for me it's
>> the large number of objectively small wins in `if` and `while`
>> contexts. They add up. That conclusion surprised me. That there are
>> occasionally bigger wins to be
On Tue, 3 Jul 2018 15:24:09 -0700
Chris Barker via Python-Dev wrote:
>
> fair enough, but I think we all agree that *many*, if not most, Python
> users are "not professional programmers". While on the other hand everyone
> involved in discussion on python-dev and python-ideas is a serious (If
On Wed, Jul 4, 2018 at 12:26 AM Nathaniel Smith wrote:
> The only cases that seem potentially valuable to me are the ones that
> are literally the form 'if := ` and 'while :=
> '. (I suspect these are the only cases that I would allow in
> code that I maintain.) The PEP does briefly discuss the
04.07.18 05:42, Steven D'Aprano пише:
On Tue, Jul 03, 2018 at 09:54:22PM -0400, Terry Reedy wrote:
results = [(x, y, x/y) for x in input_data for y in [f(x)] if y > 0]
Would (f(x),) be faster?
There is a deferred feature request to optimize "for x in [item]" as
equivalent to "for x in
04.07.18 04:54, Terry Reedy пише:
Would (f(x),) be faster?
No. Both "for y in [f(x)]" and "for y in (f(x),)" are compiled to the
same bytecode. Run your microbenchmarks again, the difference is a small
random variation.
https://bugs.python.org/issue32925
stuff = [[y := f(x), x/y] for x
On Tue, Jul 3, 2018 at 11:14 PM, Serhiy Storchaka wrote:
> 04.07.18 04:26, Tim Peters пише:
>>
>> I really don't know what Guido likes best about this, but for me it's the
>> large number of objectively small wins in `if` and `while` contexts. They
>> add up. That conclusion surprised me.
On Tue, Jul 3, 2018 at 11:07 PM, Serhiy Storchaka wrote:
> 04.07.18 00:51, Chris Angelico пише:
>>
>> On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka
>> wrote:
>>>
>>> I believe most Python users are not
>>> professional programmers -- they are sysadmins, scientists, hobbyists and
>>> kids --
[Tim]
>> I really don't know what Guido likes best about this, but for me it's
> >> the large number of objectively small wins in `if` and `while`
> >> contexts. They add up. That conclusion surprised me. That there are
> >> occasionally bigger wins to be had is pure gravy.
>
[Serhiy
On Wed, Jul 4, 2018 at 4:07 PM, Serhiy Storchaka wrote:
> 04.07.18 00:51, Chris Angelico пише:
>>
>> On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka
>> wrote:
>>>
>>> I believe most Python users are not
>>> professional programmers -- they are sysadmins, scientists, hobbyists and
>>> kids --
>>
04.07.18 04:26, Tim Peters пише:
I really don't know what Guido likes best about this, but for me it's
the large number of objectively small wins in `if` and `while`
contexts. They add up. That conclusion surprised me. That there are
occasionally bigger wins to be had is pure gravy.
04.07.18 03:24, INADA Naoki пише:
I feel PEP 572 breaks border between expression and statement, and it makes
readability of dirty code worse.
Thank you, this is what I meant.
On the other hand, I understand PEP 572 allows clever code simplifies
tedious
code. It may increase readability of
04.07.18 00:51, Chris Angelico пише:
On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka wrote:
I believe most Python users are not
professional programmers -- they are sysadmins, scientists, hobbyists and
kids --
[citation needed]
I don't understand what citation do you need.
In
On Tue, Jul 03, 2018 at 09:54:22PM -0400, Terry Reedy wrote:
> > results = [(x, y, x/y) for x in input_data for y in [f(x)] if y > 0]
>
> Would (f(x),) be faster?
There is a deferred feature request to optimize "for x in [item]" as
equivalent to "for x in (item,)", to avoid constructing a
On 7/3/2018 5:37 PM, Serhiy Storchaka wrote:
I like programming languages in which all are expressions (including
function declarations, branching and loops) and you can use an
assignment at any point, but Python is built on other ways, and I like
Python too. PEP 572 looks violating several
[INADA Naoki]
> ...
> On the other hand, I understand PEP 572 allows clever code
> simplifies tedious code. It may increase readability of non-dirty code.
The latter is the entire intent ,of course. We can't force people to write
readable code, but I don't understand the widespread assumption
> > In particularly mutating and
> > non-mutating operations are separated. The assignment expression breaks
> > this.
>
> [citation needed]
>
> In terms of blending mutating and non-mutating operations, augmented
> assignment is far worse. Contrast:
>
> >>> x = 1
> >>> y = x
> >>> x += 1
>
>
On Tue, Jul 3, 2018 at 2:51 PM, Chris Angelico wrote:
> On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka
> wrote:
> > I believe most Python users are not
> > professional programmers -- they are sysadmins, scientists, hobbyists and
> > kids --
>
> [citation needed]
fair enough, but I think we
On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka wrote:
> I believe most Python users are not
> professional programmers -- they are sysadmins, scientists, hobbyists and
> kids --
[citation needed]
> In particularly mutating and
> non-mutating operations are separated. The assignment expression
I like programming languages in which all are expressions (including
function declarations, branching and loops) and you can use an
assignment at any point, but Python is built on other ways, and I like
Python too. PEP 572 looks violating several Python design principles.
Python looks simple
60 matches
Mail list logo
