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 Thu, Jul 5, 2018 at 3:15 PM, Guido van Rossum wrote:
> Let me be slightly contrarian. :-)
>
> On Wed, Jul 4, 2018 at 9:12 PM Chris Angelico wrote:
>> 2) Is the result of the expression the modified value or the original?
>
> Someone (sadly I forget who) showed, convincingly (to me anyways :-)
Let me be slightly contrarian. :-)
On Wed, Jul 4, 2018 at 9:12 PM Chris Angelico wrote:
> Definitely against augmentation, for several reasons:
>
> 1) Spelling - should it be :+= or +:= ?
>
That one's easy. As Nick's (withdrawn) PEP 577 shows it should be simply
`+=`.
> 2) Is the result of
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
Shawn Chen wrote:
The PEP 484 is proposing a type hint which can annotate the type of each
parameters. How ever code written in this format can not be run for
python3.5 and below.
You're a bit late. Parameter annotations have been a part
of the language since at least 3.1. PEP 484 just
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
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
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,
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
[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
>
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
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
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 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 --
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 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 =
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
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
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: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
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
[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 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 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
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
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 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
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
[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?)
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 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
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
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)
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
>
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
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.
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 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 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,
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
[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
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
>
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
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).
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 =
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 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
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
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
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
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
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 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".
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
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
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
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
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
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
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, 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:
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 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
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
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
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
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
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
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
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.
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.
> ___
>
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,
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
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
1 - 100 of 109 matches
Mail list logo
