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 --
>>
[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 Storch
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 --
>>
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. That
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 in
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 (
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
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 not
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 had
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 alr
On 25.04.18 05:43, 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. Indeed, you may
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, hobbyist
was going to tell
instead of := maybe => better
:= too close to other langs
Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
Of the proposed syntaxes, I dislike identifer := expression less, but
>
I'd still rather not see it added.
> ___
> P
On Wed, Jul 04, 2018 at 03:21:29PM +0400, Abdur-Rahmaan Janhangeer wrote:
> was going to tell
>
> instead of := maybe => better
>
> := too close to other langs
The fact that := will be familiar to many people (especially if they
know Go, Pascal or Eiffel etc) is a point in its favour.
https://
agree for =>
but how many people use pascal eiffel etc? (go has a chance)
that's a reminder of an old, fading epoch, bland IDEs, hard-to-crunch fonts
BDL Guido once remarked in a pycon talk that today agencies would've
charged you a high price to tell you what the word python might tickle in
the
On 2 July 2018 at 17:38, Petr Viktorin wrote:
> Anyway, the SUSE tests seem to fail on .pyc files. The main change in that
> area was [PEP 552], try starting there. AFAIK, SUSE is ahead of Fedora in
> the reproducible builds area; perhaps that's where the difference is.
In particular, if a build
On 4 July 2018 at 22:00, Nick Coghlan wrote:
> On 2 July 2018 at 17:38, Petr Viktorin wrote:
>> Anyway, the SUSE tests seem to fail on .pyc files. The main change in that
>> area was [PEP 552], try starting there. AFAIK, SUSE is ahead of Fedora in
>> the reproducible builds area; perhaps that's
The PEP 572 has been approved, it's no longer worth it to discuss it ;-)
Victor
2018-07-04 13:21 GMT+02:00 Abdur-Rahmaan Janhangeer :
> was going to tell
>
> instead of := maybe => better
>
> := too close to other langs
>
> Abdur-Rahmaan Janhangeer
> https://github.com/Abdur-rahmaanJ
>
>> Of the
Yes, see my issue https://bugs.python.org/issue34022 to discuss how to
fix tests.
Victor
2018-07-04 14:05 GMT+02:00 Nick Coghlan :
> On 4 July 2018 at 22:00, Nick Coghlan wrote:
>> On 2 July 2018 at 17:38, Petr Viktorin wrote:
>>> Anyway, the SUSE tests seem to fail on .pyc files. The main cha
With PEP 572's formal acceptance now expected to be just a matter of
time, I'll limit any further personal expressions of opinion on the
change and the process taken to achieve it to other venues :)
However, there's a design aspect I do need to address, which is to
make sure that PEP 558 (my propo
On 04.07.2018 15:29, Victor Stinner wrote:
The PEP 572 has been approved, it's no longer worth it to discuss it ;-)
Victor
As of now, https://www.python.org/dev/peps/pep-0572/ is marked as "draft".
2018-07-04 13:21 GMT+02:00 Abdur-Rahmaan Janhangeer :
was going to tell
instead of := maybe
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 rea
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 in
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 "all
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 i
On Wed, 2018-07-04 at 22:05 +1000, Nick Coghlan wrote:
> Running the following locally fails for me:
>
> $ SOURCE_DATE_EPOCH=`date` ./python -m test test_py_compile
> test_compileall
Just if this is taken literally, it is wrong. According to https:
//reproducible-builds.org/specs/source-date-
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 e
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, but
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
Now that it's a done deal, I am closely reviewing the semantics section
of PEP 572. (I had expected one more posting of the final PEP, but it
seems the acceptance came somewhere in a thread that was already muted.)
Since there has been no final posting that I'm aware of, I'm referring
to https://w
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 t
Correct, there shouldn't be any additional corner cases for your PEP due to
inline assignments. We're not introducing new scopes nor other runtime
mechanisms; the target of an inline assignment is either a global or a cell
(nonlocal) defined at a specific outer level.
What I wish we had (quite ind
Thanks for thinking about the details! I want to answer all of these but
right now I have some social obligations so it may be a few days. I expect
the outcome of this investigation to result in an improved draft for PEP
572.
On Wed, Jul 4, 2018 at 7:29 AM Steve Dower wrote:
> Now that it's a do
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 imp
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 2018-07-04 03:31, INADA Naoki wrote:
I think both PEPs are relying on FASTCALL calling convention,
and can't be accepted until FASTCALL is stable & public.
First of all, the fact that FASTCALL has not been made public should
not prevent from discussing those PEPs and even making a
(provision
On Wed, Jul 04, 2018 at 03:36:18PM +0300, Ivan Pozdeev via Python-Dev wrote:
> On 04.07.2018 15:29, Victor Stinner wrote:
> >The PEP 572 has been approved, it's no longer worth it to discuss it ;-)
> >
> >Victor
>
> As of now, https://www.python.org/dev/peps/pep-0572/ is marked as "draft".
https:
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():
> > ...print(globals().update(
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
Just a quickie:
[Steve Dower]
> > The PEP uses the phrase "an assignment expression
> occurs in a comprehension" - what does this mean?
It's about static analysis of the source code, at compile-time, to
establish scopes. So "occurs in" means your eyeballs see an assignment
expression in a compr
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 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 bre
[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 br
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 be
[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 que
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
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):
Apparently I have made it into "club of three who don't care much about
opinions of others" for the crime of a single +0.5 for PEP-572 without
participating in the discussion at all (neither did Jason).
https://twitter.com/SerhiyStorchaka/status/1014274554452209665
This is a new high for Twitte
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:
https://www.ibtimes.co.uk/coding-uk-classroom-python-overtakes-french-mo
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 menti
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 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 12:09 PM Chris Angelico wrote:
>
> Even assuming your figures to be 100% accurate, I don't think you can
> accept that scaling. Are you claiming that every high school student
> (a) continues to use Python forever, and (b) continues to use it at a
> non-professional level?
I was going to answer that I agree the language there is unwarranted,
but then it came to me that the best way to keep things civil is perhaps
not to discuss Twitter-emitted opinions back on python-dev.
Regards
Antoine.
On Wed, 4 Jul 2018 17:48:21 +0200
Stefan Krah wrote:
> Apparently I have
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.
Is
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, espe
On 04Jul2018 1021, Tim Peters wrote:
Same as now, `i` is local to the synthetic nested function created for
the genexp. The scope of `a` is determined by pretending the assignment
occurred in the block containing the outermost (textually - static
analysis) comprehension. In this case, `a = an
On 04/07/18 16:48, Stefan Krah wrote:
Apparently I have made it into "club of three who don't care much about
opinions of others" for the crime of a single +0.5 for PEP-572 without
participating in the discussion at all (neither did Jason).
https://twitter.com/SerhiyStorchaka/status/10142745544
Just to clarify, the club of three in _my_ twit are the three authors of
the PEP.
Also, how about you not telling me what to say?
--
Ivan
On 4 July 2018 at 16:48, Stefan Krah wrote:
>
> Apparently I have made it into "club of three who don't care much about
> opinions of others" for the crim
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
> look
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 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 p
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 no
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 expla
[Steve Dower]
> Okay, so as far as the specification goes, saying "assignment
> > expressions in comprehensions get or create a cell variable in the
> > defining scope and update its value" satisfies me just fine (or some
> > other wording that more closely mirrors the actual behaviour - all my
Hi,
Let's say that the PEP 572 (assignment expression) is going to be
approved. Let's move on and see how it can be used in the Python
stdlib.
I propose to start the discussion about "coding style" (where are
assignment expressions appropriate or not?) with the "while True"
case.
I wrote a WIP p
On 04.07.2018 10:10, Nathaniel Smith wrote:
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, hob
On Wed, Jul 4, 2018 at 3:51 PM, Victor Stinner wrote:
> My question is now: for which "while True" patterns are the assignment
> expression appropriate? There identified different patterns.
>
>
> == Pattern 1, straighforward ==
>
> while True:
> line = input.readline()
> if not line:
>
On Wed, Jul 4, 2018 at 4:10 PM, Ivan Pozdeev via Python-Dev
wrote:
> On 04.07.2018 10:10, Nathaniel Smith wrote:
>> Right, Python has a *very strong* convention that each line should
>> have at most one side-effect, and that if it does have a side-effect
>> it should be at the outermost level.
>
>
On 2018-07-04 23:51, Victor Stinner wrote:
[snip]
(C)
while True:
chunk = self.raw.read()
if chunk in empty_values:
nodata_val = chunk
break
...
"nodata_val = chunk" cannot be put into the "chunk := self.raw.read()"
assignment expression combined with a test. At
On the 3360 for loops of the stdlib (*), I only found 2 loops which
would benefit of assignment expressions.
It's not easy to find loops which:
- build a list,
- are simple enough to be expressed as list comprehension,
- use a condition (if),
- use an expression different than just a variable name
Recently on Python-Dev:
On 2018-07-03 15:24, Chris Barker wrote:
> On Tue, Jul 3, 2018 at 2:51 PM, Chris Angelico On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka
>
> > I believe most Python users are not
> > professional programmers -- they are sysadmins, scientists, hobbyists
>
The code comes from Lib/_pyio.py. Simplified code:
---
nodata_val = b""
...
if n is None or n == -1:
...
current_size = 0
while True:
chunk = self.raw.read()
if chunk in empty_values:
nodata_val = chunk
break
current_size += len(chunk)
On Thu, Jul 5, 2018 at 10:03 AM, Victor Stinner wrote:
> On the 3360 for loops of the stdlib (*), I only found 2 loops which
> would benefit of assignment expressions.
>
> It's not easy to find loops which:
> - build a list,
> - are simple enough to be expressed as list comprehension,
> - use a co
On 04Jul2018 1518, Tim Peters wrote:
> The only new thing is specifying the scope of `a`, where "local to f"
> means exactly the same thing as for any other name local to a function
> today. So far as the PEP semantics go, it doesn't even matter whether
> an implementation _does_ implement some fo
On Thu, Jul 5, 2018 at 9:52 AM, Mike Miller wrote:
> Compromise:
>
> Fortunately there is a compromise design that is chosen often these days in
> new languages---restricting these assignments to if/while (potentially
> comp/gen) statements. We can also reuse the existing "EXPR as NAME" syntax
>
On Thu, Jul 5, 2018 at 10:20 AM, Steve Dower wrote:
> On 04Jul2018 1518, Tim Peters wrote:
>> The only new thing is specifying the scope of `a`, where "local to f"
>> means exactly the same thing as for any other name local to a function
>> today. So far as the PEP semantics go, it doesn't even m
[Victor Stinner]Let's say that the PEP 572 (assignment expression) is going
to be
> approved. Let's move on and see how it can be used in the Python stdlib.
>
Ugh - how adult ;-)
> I propose to start the discussion about "coding style" (where are
> assignment expressions appropriate or not?) wi
On 04.07.2018 10:10, Nathaniel Smith wrote:
I think the most striking evidence for this is that during the
discussion of PEP 572 we discovered that literally none of us –
including Guido – even *know* what the order-of-evaluation is inside
expressions.
If has stricken me that this is a highligh
2018-07-05 2:15 GMT+02:00 Chris Angelico :
> On Thu, Jul 5, 2018 at 10:03 AM, Victor Stinner wrote:
>> On the 3360 for loops of the stdlib (*), I only found 2 loops which
>> would benefit of assignment expressions.
>>
>> It's not easy to find loops which:
>> - build a list,
>> - are simple enough
On Thu, Jul 5, 2018 at 10:33 AM, Victor Stinner wrote:
> 2018-07-05 2:15 GMT+02:00 Chris Angelico :
>> On Thu, Jul 5, 2018 at 10:03 AM, Victor Stinner wrote:
>>> On the 3360 for loops of the stdlib (*), I only found 2 loops which
>>> would benefit of assignment expressions.
>>>
>>> It's not easy
On 05.07.2018 2:29, Nathaniel Smith wrote:
On Wed, Jul 4, 2018 at 4:10 PM, Ivan Pozdeev via Python-Dev
wrote:
On 04.07.2018 10:10, Nathaniel Smith wrote:
Right, Python has a *very strong* convention that each line should
have at most one side-effect, and that if it does have a side-effect
it s
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 do
[Steve Dower]
> In that case, please provide more examples of how it should work when
> the assignment expression appears to define a variable in a scope that
> is not on the call stack.
>
Sorry, I'm not clear what you're asking about. Python's scopes are
determined statically, at compile-time -
On Wed, Jul 04, 2018 at 04:52:54PM -0700, Mike Miller wrote:
> Additionally, I have noticed a dichotomy between prolific "C programmers"
> who've supported this PEP and many Python programmers who don't want it.
Prolific C programmers like me, hey?
*shakes head in a combination of amusement a
On 05.07.2018 3:40, Ivan Pozdeev via Python-Dev wrote:
On 05.07.2018 2:29, Nathaniel Smith wrote:
On Wed, Jul 4, 2018 at 4:10 PM, Ivan Pozdeev via Python-Dev
wrote:
On 04.07.2018 10:10, Nathaniel Smith wrote:
Right, Python has a *very strong* convention that each line should
have at most one
On 2018-07-05 01:11, Victor Stinner wrote:
The code comes from Lib/_pyio.py. Simplified code:
---
nodata_val = b""
...
if n is None or n == -1:
...
current_size = 0
while True:
chunk = self.raw.read()
if chunk in empty_values:
nodata_val = chunk
On 05.07.2018 3:36, Chris Angelico wrote:
On Thu, Jul 5, 2018 at 10:33 AM, Victor Stinner wrote:
2018-07-05 2:15 GMT+02:00 Chris Angelico :
On Thu, Jul 5, 2018 at 10:03 AM, Victor Stinner wrote:
On the 3360 for loops of the stdlib (*), I only found 2 loops which
would benefit of assignment e
On 05/07/2018 01:25, Tim Peters wrote:
== Pattern 5, two variables ==
while True:
m = match()
if not m:
break
j = m.end()
if i == j:
break
...
replaced with:
while (m := match()) and (j := m.end()) == i:
I ass
On 05/07/2018 00:15, Nathaniel Smith wrote:
On Wed, Jul 4, 2018 at 3:51 PM, Victor Stinner wrote:
My question is now: for which "while True" patterns are the assignment
expression appropriate? There identified different patterns.
== Pattern 1, straighforward ==
while True:
line = inpu
On 05.07.2018 1:51, Victor Stinner wrote:
Hi,
Let's say that the PEP 572 (assignment expression) is going to be
approved. Let's move on and see how it can be used in the Python
stdlib.
I propose to start the discussion about "coding style" (where are
assignment expressions appropriate or not?)
On 05.07.2018 2:52, Mike Miller wrote:
Recently on Python-Dev:
On 2018-07-03 15:24, Chris Barker wrote:
> On Tue, Jul 3, 2018 at 2:51 PM, Chris Angelico > On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka
>
> > I believe most Python users are not
> > professional programmers -- the
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 my
Victor Stinner in "Assignment expression and coding style: the while
True case" and others have brought to attention
that the AE as currently written doesn't support all the capabilities of
the assignment statement, namely:
* tuple unpacking
* augmented assignment
(I titled the letter "all c
On Thu, Jul 5, 2018 at 1:13 AM Jeroen Demeyer wrote:
>
> On 2018-07-04 03:31, INADA Naoki wrote:
> > I think both PEPs are relying on FASTCALL calling convention,
> > and can't be accepted until FASTCALL is stable & public.
>
> First of all, the fact that FASTCALL has not been made public should
>
[Ivan Pozdeev]
> Victor Stinner in "Assignment expression and coding style: the while
> True case" and others have brought to attention
>
> that the AE as currently written doesn't support all the capabilities of
> the assignment statement, namely:
>
> * tuple unpacking
> * augmented assignment
>
Hello,
Here, I am proposing a change on python type annotation.
Python was born to be a simple and elegant language. However recent change has
again introduce new incompatibility to python.
The PEP 484 is proposing a type hint which can annotate the type of each
parameters. How ever code writ
On Thu, Jul 5, 2018 at 1:28 PM, Ivan Pozdeev via Python-Dev
wrote:
> Victor Stinner in "Assignment expression and coding style: the while True
> case" and others have brought to attention
>
> that the AE as currently written doesn't support all the capabilities of the
> assignment statement, namel
Type hints like in PEP 484 work on all Python 3 versions, and something
similar to your proposal is already supported on Python 2 [1].
[1]: https://mypy.readthedocs.io/en/latest/python2.html
On July 4, 2018 11:08:27 PM Shawn Chen wrote:
Hello,
Here, I am proposing a change on python type a
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
1 - 100 of 109 matches
Mail list logo
