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

2018-04-20 Thread 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!

2018-04-20 Thread 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!

2018-04-20 Thread 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!

2018-04-20 Thread 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!

2018-04-19 Thread 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

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

2018-04-19 Thread Chris Angelico 
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 incorporated
expression, with the additional side-effect that the target is assigned
that value::

# Handle a matched regex
if (match := pattern.search(data)) is not None:
...

# A more explicit alternative to the 2-arg form of iter() invocation
while (value := read_next_item()) is not None:
...

# Share a subexpression between a comprehension filter clause and its output
filtered_data = [y for x in data if (y := f(x)) is not None]


Differences from regular assignment statements
--

Most importantly, since ``:=`` is an expression, it can be used in contexts
where statements are illegal, including lambda functions and comprehensions.

An assignment statement can assign to multiple targets, left-to-right::

x = y = z = 0

The equivalent assignment expression is parsed as separate binary operators,
and is therefore processed right-to-left, as if it were spelled thus::

assert 0 == (x := (y := (z := 0)))

Augmented assignment is not supported in expression form::

>>> x +:= 1
  File "", line 1
x +:= 1
^
SyntaxError: invalid syntax

Otherwise, the semantics of assignment are identical in statement and
expression forms.