Re: [Python-Dev] PEP 572: Now with 25% less reference implementation!

[Chris Angelico]

On Sat, Apr 21, 2018 at 1:50 AM, Guido van Rossum  wrote:
> Maybe annotations should get a brief mention in the Rejected Ideas section,
> with your explanation here added. (And maybe my response.)

Good idea. Actually, since it's a syntactic difference, I've promoted
it to the "Differences" section.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Now with 25% less reference implementation!

[Guido van Rossum]

Maybe annotations should get a brief mention in the Rejected Ideas section,
with your explanation here added. (And maybe my response.)

On Thu, Apr 19, 2018 at 11:31 PM, Chris Angelico  wrote:

> On Fri, Apr 20, 2018 at 2:45 PM, Dmitry Malinovsky 
> wrote:
> > Hello Chris, and thank you for working on this PEP!
> >
> > What do you think about using variable type hints with this syntax?
> > I tried to search through python-dev and couldn't find a single post
> > discussing that question.
> > If I missed it somehow, could you please include its conclusions into
> the PEP?
>
> I'm ignoring them for the sake of the PEP, because it'd complicate the
> grammar for little benefit. If someone wants to add an enhancement
> later, that's fine; but the proposal can stand without it, and with
> it, it'll make for even more noise in a line full of colons.
>
> > For instance, as I understand now the parser will fail on this snippet:
> >
> > while data: bytes := stream.read():
> > print("Received data:", data)
> >
> > Do brackets help?
> >
> > while (data: bytes := stream.read()):
> > print("Received data:", data)
> >
> > IIUC, in 3.7 It is invalid syntax to specify a type hint for a for loop
> item;
> > should brackets help? Currently they don't:
> >
> > Python 3.7.0b3+ (heads/3.7:7dcfd6c, Mar 30 2018, 21:30:34)
> > [Clang 9.0.0 (clang-900.0.39.2)] on darwin
> > Type "help", "copyright", "credits" or "license" for more
> information.
> > >>> for (x: int) in [1,2,3]:
> >   File "", line 1
> > for (x: int) in [1,2,3]:
> >   ^
> > SyntaxError: invalid syntax
>
> And that's another good reason not to bother, at least for now. I'm
> not sure whether you can use a Py2-style type hint comment on a for
> loop, but if so, you should also be able to do it on a while loop or
> anything. Or, of course, you can just annotate the variable before the
> loop, if you want to.
>
> ChrisA
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Now with 25% less reference implementation!

[Guido van Rossum]

If you want type hints you can use a variable annotation without
initialization before the statement:

data: bytes
while data := stream.read():
print("Got", data)

On Thu, Apr 19, 2018 at 9:45 PM, Dmitry Malinovsky 
wrote:

> Hello Chris, and thank you for working on this PEP!
>
> What do you think about using variable type hints with this syntax?
> I tried to search through python-dev and couldn't find a single post
> discussing that question.
> If I missed it somehow, could you please include its conclusions into the
> PEP?
>
> For instance, as I understand now the parser will fail on this snippet:
>
> while data: bytes := stream.read():
> print("Received data:", data)
>
> Do brackets help?
>
> while (data: bytes := stream.read()):
> print("Received data:", data)
>
> IIUC, in 3.7 It is invalid syntax to specify a type hint for a for loop
> item;
> should brackets help? Currently they don't:
>
> Python 3.7.0b3+ (heads/3.7:7dcfd6c, Mar 30 2018, 21:30:34)
> [Clang 9.0.0 (clang-900.0.39.2)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> for (x: int) in [1,2,3]:
>   File "", line 1
> for (x: int) in [1,2,3]:
>   ^
> SyntaxError: invalid syntax
>
> Thanks,
>
> > On 20 Apr 2018, at 09:10, Chris Angelico  wrote:
> >
> > Working on the reference implementation for PEP 572 is turning out to
> > be a massive time sink, both on my personal schedule and on the PEP's
> > discussion. I can't just hold off all discussion on a topic until I
> > figure out whether something is possible or not, because that could
> > take me several days, even a week or more. And considering the massive
> > backlash against the proposal, it seems like a poor use of my time to
> > try to prove that something's impossible, find that I don't know
> > enough about grammar editing to be able to say anything more than
> > "well, I couldn't do it, but someone else might be able to", and then
> > try to resume the discussion with no more certainty than we had
> > before.
> >
> > So here's the PEP again, simplified. I'm fairly sure it's just going
> > to be another on a growing list of rejected PEPs to my name, and I'm
> > done with trying to argue some of these points. Either the rules get
> > simplified, or they don't. Trying to simplify the rules and maintain
> > perfect backward compatibility is just making the rules even more
> > complicated.
> >
> > PEP 572, if accepted, *will* change the behaviour of certain
> > constructs inside comprehensions, mainly due to interactions with
> > class scope that make no sense unless you know how they're implemented
> > internally. The official tutorial pretends that comprehensions are
> > "equivalent to" longhand:
> >
> > https://docs.python.org/3/tutorial/datastructures.html?
> highlight=equivalent#list-comprehensions
> > https://docs.python.org/3/howto/functional.html?highlight=equivalent#
> generator-expressions-and-list-comprehensions
> >
> > and this is an inaccuracy for the sake of simplicity. PEP 572 will
> > make this far more accurate; the only difference is that the
> > comprehension is inside a function. Current semantics are far more
> > bizarre than that.
> >
> > Do you want absolutely 100% backward compatibility? Then reject this
> > PEP. Or better still, keep using Python 3.7, and don't upgrade to 3.8,
> > in case something breaks. Do you want list comprehensions that make
> > better sense? Then accept that some code will need to change, if it
> > tried to use the same name in multiple scopes, or tried to use ancient
> > Python 2 semantics with a yield expression in the outermost iterable.
> >
> > I'm pretty much ready for pronouncement.
> >
> > https://www.python.org/dev/peps/pep-0572/
> >
> > ChrisA
> >
> > PEP: 572
> > Title: Assignment Expressions
> > Author: Chris Angelico 
> > Status: Draft
> > Type: Standards Track
> > Content-Type: text/x-rst
> > Created: 28-Feb-2018
> > Python-Version: 3.8
> > Post-History: 28-Feb-2018, 02-Mar-2018, 23-Mar-2018, 04-Apr-2018,
> 17-Apr-2018
> >
> >
> > Abstract
> > 
> >
> > This is a proposal for creating a way to assign to variables within an
> > expression. Additionally, the precise scope of comprehensions is
> adjusted, to
> > maintain consistency and follow expectations.
> >
> >
> > Rationale
> > =
> >
> > Naming the result of an expression is an important part of programming,
> > allowing a descriptive name to be used in place of a longer expression,
> > and permitting reuse.  Currently, this feature is available only in
> > statement form, making it unavailable in list comprehensions and other
> > expression contexts.  Merely introducing a way to assign as an expression
> > would create bizarre edge cases around comprehensions, though, and to
> avoid
> > the worst of the confusions, we change the definition of comprehensions,
> > causing some edge cases to be 

Re: [Python-Dev] PEP 572: Now with 25% less reference implementation!

[Chris Angelico]

On Fri, Apr 20, 2018 at 2:45 PM, Dmitry Malinovsky  wrote:
> Hello Chris, and thank you for working on this PEP!
>
> What do you think about using variable type hints with this syntax?
> I tried to search through python-dev and couldn't find a single post
> discussing that question.
> If I missed it somehow, could you please include its conclusions into the PEP?

I'm ignoring them for the sake of the PEP, because it'd complicate the
grammar for little benefit. If someone wants to add an enhancement
later, that's fine; but the proposal can stand without it, and with
it, it'll make for even more noise in a line full of colons.

> For instance, as I understand now the parser will fail on this snippet:
>
> while data: bytes := stream.read():
> print("Received data:", data)
>
> Do brackets help?
>
> while (data: bytes := stream.read()):
> print("Received data:", data)
>
> IIUC, in 3.7 It is invalid syntax to specify a type hint for a for loop item;
> should brackets help? Currently they don't:
>
> Python 3.7.0b3+ (heads/3.7:7dcfd6c, Mar 30 2018, 21:30:34)
> [Clang 9.0.0 (clang-900.0.39.2)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> for (x: int) in [1,2,3]:
>   File "", line 1
> for (x: int) in [1,2,3]:
>   ^
> SyntaxError: invalid syntax

And that's another good reason not to bother, at least for now. I'm
not sure whether you can use a Py2-style type hint comment on a for
loop, but if so, you should also be able to do it on a while loop or
anything. Or, of course, you can just annotate the variable before the
loop, if you want to.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Now with 25% less reference implementation!

[Dmitry Malinovsky]

Hello Chris, and thank you for working on this PEP!

What do you think about using variable type hints with this syntax?
I tried to search through python-dev and couldn't find a single post
discussing that question.
If I missed it somehow, could you please include its conclusions into the PEP?

For instance, as I understand now the parser will fail on this snippet:

while data: bytes := stream.read():
print("Received data:", data)

Do brackets help?

while (data: bytes := stream.read()):
print("Received data:", data)

IIUC, in 3.7 It is invalid syntax to specify a type hint for a for loop item;
should brackets help? Currently they don't:

Python 3.7.0b3+ (heads/3.7:7dcfd6c, Mar 30 2018, 21:30:34)
[Clang 9.0.0 (clang-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> for (x: int) in [1,2,3]:
  File "", line 1
for (x: int) in [1,2,3]:
  ^
SyntaxError: invalid syntax

Thanks,

> On 20 Apr 2018, at 09:10, Chris Angelico  wrote:
> 
> Working on the reference implementation for PEP 572 is turning out to
> be a massive time sink, both on my personal schedule and on the PEP's
> discussion. I can't just hold off all discussion on a topic until I
> figure out whether something is possible or not, because that could
> take me several days, even a week or more. And considering the massive
> backlash against the proposal, it seems like a poor use of my time to
> try to prove that something's impossible, find that I don't know
> enough about grammar editing to be able to say anything more than
> "well, I couldn't do it, but someone else might be able to", and then
> try to resume the discussion with no more certainty than we had
> before.
> 
> So here's the PEP again, simplified. I'm fairly sure it's just going
> to be another on a growing list of rejected PEPs to my name, and I'm
> done with trying to argue some of these points. Either the rules get
> simplified, or they don't. Trying to simplify the rules and maintain
> perfect backward compatibility is just making the rules even more
> complicated.
> 
> PEP 572, if accepted, *will* change the behaviour of certain
> constructs inside comprehensions, mainly due to interactions with
> class scope that make no sense unless you know how they're implemented
> internally. The official tutorial pretends that comprehensions are
> "equivalent to" longhand:
> 
> https://docs.python.org/3/tutorial/datastructures.html?highlight=equivalent#list-comprehensions
> https://docs.python.org/3/howto/functional.html?highlight=equivalent#generator-expressions-and-list-comprehensions
> 
> and this is an inaccuracy for the sake of simplicity. PEP 572 will
> make this far more accurate; the only difference is that the
> comprehension is inside a function. Current semantics are far more
> bizarre than that.
> 
> Do you want absolutely 100% backward compatibility? Then reject this
> PEP. Or better still, keep using Python 3.7, and don't upgrade to 3.8,
> in case something breaks. Do you want list comprehensions that make
> better sense? Then accept that some code will need to change, if it
> tried to use the same name in multiple scopes, or tried to use ancient
> Python 2 semantics with a yield expression in the outermost iterable.
> 
> I'm pretty much ready for pronouncement.
> 
> https://www.python.org/dev/peps/pep-0572/
> 
> ChrisA
> 
> PEP: 572
> Title: Assignment Expressions
> Author: Chris Angelico 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 28-Feb-2018
> Python-Version: 3.8
> Post-History: 28-Feb-2018, 02-Mar-2018, 23-Mar-2018, 04-Apr-2018, 17-Apr-2018
> 
> 
> Abstract
> 
> 
> This is a proposal for creating a way to assign to variables within an
> expression. Additionally, the precise scope of comprehensions is adjusted, to
> maintain consistency and follow expectations.
> 
> 
> Rationale
> =
> 
> Naming the result of an expression is an important part of programming,
> allowing a descriptive name to be used in place of a longer expression,
> and permitting reuse.  Currently, this feature is available only in
> statement form, making it unavailable in list comprehensions and other
> expression contexts.  Merely introducing a way to assign as an expression
> would create bizarre edge cases around comprehensions, though, and to avoid
> the worst of the confusions, we change the definition of comprehensions,
> causing some edge cases to be interpreted differently, but maintaining the
> existing behaviour in the majority of situations.
> 
> 
> Syntax and semantics
> 
> 
> In any context where arbitrary Python expressions can be used, a **named
> expression** can appear. This is of the form ``target := expr`` where
> ``expr`` is any valid Python expression, and ``target`` is any valid
> assignment target.
> 
> The value of such a named expression is the same as the