Re: [Python-Dev] PEP 572: Assignment Expressions

[Paul Moore]

On 20 April 2018 at 07:46, Chris Angelico  wrote:
> On Fri, Apr 20, 2018 at 1:30 PM, Stephen J. Turnbull
>  wrote:
>> Christoph Groth writes:
>>
>>  > Wouldn't it be a pity not to liberate assignments from their boring
>>  > statement existence?
>>
>> Maybe not.  While it would be nice to solve the loop-and-a-half
>> "problem" and the loop variable initialization "problem" (not everyone
>> agrees these are even problems, especially now that we have
>> comprehensions and generator expressions), as a matter of taste I like
>> the fact that this particular class of side effects is given weighty
>> statement syntax rather than more lightweight expression syntax.
>>
>> That is, I find statement syntax more readable.
>>
>
> If you've read the PEP, you'll see that it encourages the use of
> assignment statements whereever possible. If statement syntax is
> generally more readable, by all means, use it. That doesn't mean there
> aren't situations where the expression syntax is FAR more readable.
>
> Tell me, is this "more readable" than a loop with an actual condition in it?
>
> def sqrt(n):
> guess, nextguess = 1, n
> while True:
> if math.isclose(guess, nextguess): return guess
> guess = nextguess
> nextguess = n / guess
>
> Readable doesn't mean "corresponds closely to its disassembly",
> despite the way many people throw the word around. It also doesn't
> mean  "code I like", as opposed to "code I don't like". The words for
> those concepts are "strongly typed" and "dynamically typed", as have
> been demonstrated through MANY online discussions. (But I digress.)
> Readable code is code which expresses an algorithm, expresses the
> programmer's intent. It adequately demonstrates something at a
> *higher* abstraction level. Does the algorithm demonstrated here
> include an infinite loop? No? Then it shouldn't have "while True:" in
> it.

Thanks Chris - this is a very good explanation of how we can
(somewhat) objectively look at "readability", and not one I'd really
considered before. It's also an extremely good argument (IMO) that the
loop-and-a-half construct would benefit from improvement.

In my opinion, it's only partially related to the assignment
expression discussion, though. Yes, assignment expressions "solve" the
loop-and-a-half situation. I'm unsure how *much* I like the look of
the resulting code, but I concede that's a "code I like" vs "code I
don't like" situation. But assignment expressions are much more
general than that, and as a general construct, they should be
evaluated based on how many problems like this they solve, and whether
the downsides justify it. We've already had the comprehension use case
marginalised as no longer being a key use case for the proposal,
because they weren't as "obviously" improved as some people had hoped.
So overall, I think assignment expressions have proved to be a bit
useful in some cases, and less so in others.

Clearly any proposal can be picked to death with enough time to look
for flaws. And part of the Zen is "Now is better than never". But I
think in this case, "Although never is often better than *right* now"
applies - we've had some very productive discussions, and you've done
an incredible job of managing them and capturing the results, but it
feels to me that the overall result is that there's likely a better
solution still out there, that needs a new intuition to solve.

> Now, this is a pretty obvious example. I deliberately wrote it so you
> could simply lift the condition straight into the while header. And I
> hope that everyone here agrees that this would be an improvement:
>
> def sqrt(n):
> guess, nextguess = 1, n
> while not math.isclose(guess, nextguess):
> guess = nextguess
> nextguess = n / guess
> return guess
>
> But what if the condition were more complicated?
>
> def read_document(file):
> doc = ""
> while (token := file.get_next_token()) != "END":
> doc += token
> return doc
>
> The loop condition is "while the token is not END", or "while
> get_next_token() doesn't return END", depending on your point of view.
> Is it "more readable" to put that condition into the while header, or
> to use an infinite loop and a break statement, or to duplicate a line
> of code before the loop and at the bottom of the loop? Which one best
> expresses the programmer's intention?

The version that captures the value and tests it. I agree completely
here. But we do have other options:

def read_document(file):
doc = ""
for token in token_stream(file, terminator="END"):
doc += token
return doc

(This point about rewriting to use for and an iterator applies to
Chris Barker's fp.readline() example as well).

Sure, token_stream might need a loop-and-a-half internally[1]. But
from the user's point of view that's "low level" code, so not so
important (ultimately, this is all about abstracting intent). And
people maybe aren't used to writing "helper" iterators qui

Re: [Python-Dev] PEP 572: Assignment Expressions

[Chris Angelico]

On Fri, Apr 20, 2018 at 6:32 PM, Paul Moore  wrote:
>> def read_document(file):
>> doc = ""
>> while (token := file.get_next_token()) != "END":
>> doc += token
>> return doc
>>
>> The loop condition is "while the token is not END", or "while
>> get_next_token() doesn't return END", depending on your point of view.
>> Is it "more readable" to put that condition into the while header, or
>> to use an infinite loop and a break statement, or to duplicate a line
>> of code before the loop and at the bottom of the loop? Which one best
>> expresses the programmer's intention?
>
> The version that captures the value and tests it. I agree completely
> here. But we do have other options:
>
> def read_document(file):
> doc = ""
> for token in token_stream(file, terminator="END"):
> doc += token
> return doc
>
> (This point about rewriting to use for and an iterator applies to
> Chris Barker's fp.readline() example as well).
>
> Sure, token_stream might need a loop-and-a-half internally[1]. But
> from the user's point of view that's "low level" code, so not so
> important (ultimately, this is all about abstracting intent). And
> people maybe aren't used to writing "helper" iterators quite this
> freely, but that's a matter of education. So agreed - assignment
> expressions help with loop-and-a-half constructs. But we have other
> ways of dealing with them, so that's a relatively manageable
> situation.
>
> It's *still* all about cost-benefit trade-offs, with no clear winner
> (in my view).

You can always add another level of indirection. Always. Pushing
something off into another function is helpful ONLY if you can
usefully name that function, such that anyone who's reading the
calling code can ignore the function and know everything they need to
know about it. Otherwise, all you've done is force them to look
elsewhere for the code. A bunch of single-use helper functions does
not generally improve a module.

> [1] Although actually not - in *this* case, iter(file.get_next_token,
> 'END') is exactly what you need. But I concede that it's possible to
> demonstrate examples where that isn't the case.

The easiest way is to pick any comparison other than equality. If you
want "is" / "is not", or if there are several termination conditions
(so the check is "in {x, y, z}"), iter() can't help you.

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 575: Unifying function/method classes

[Jeroen Demeyer]

On 2018-04-14 23:14, Guido van Rossum wrote:

That actually sounds like a pretty big problem. I'm sure there is lots
of code that doesn't *just* duck-type nor calls inspect but uses
isinstance() to decide how to extract the desired information.


I have been thinking about this some more...

One solution to improve backwards compatibility would be to duplicate 
some classes. For example, make a separate class for bound methods in 
extension types, which would be literally a duplicate of the existing 
types.MethodType class (possibly with a different name). In other words, 
a bound method of an extension type would work exactly the same way as 
an existing bound method but it would artificially be a different class 
for the benefit of non-duck-typing.

___
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: Assignment Expressions

[Christoph Groth]

Steven Turnbull wrote:

Christoph Groth writes:


Wouldn't it be a pity not to liberate assignments from their boring
statement existence?


Maybe not.  While it would be nice to solve the loop-and-a-half
"problem" and the loop variable initialization "problem" (not everyone
agrees these are even problems, especially now that we have
comprehensions and generator expressions), as a matter of taste I like
the fact that this particular class of side effects is given weighty
statement syntax rather than more lightweight expression syntax.


I think that this is the crucial point.  If it is indeed a design
principle of Python that expressions should not have the side-effect of
assigning names, than the whole discussion of PEP 572 could have been
stopped early on.  I didn't have this impression since core devs
participated constructively in the discussion.


That is, I find statement syntax more readable.


Many people will agree that := is more readable when used in cases where
it's meant to be used (as listed in the PEP).  Your objection seems to
refer to the potential for "clever" misuse, like

i := (a := list(iterator)).index(elem)

instead of

a := list(iterator)
i := a.index(elem)

I think that the ":=" syntax catches the eye and makes it easy to spot
even hidden assignment expressions that shouldn't have been used.

Note that the proposed syntax can be actually *more* readable even when
used as a statement, like in

equal := a == b

Personally, I even slightly prefer

a := 3

to the commonplace

a = 3

because it visually expresses the asymmetry of the operation.  (And no,
Turbo Pascal was not my first programming language. :-)

Christoph
___
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: Assignment Expressions

[Paul Moore]

On 20 April 2018 at 12:25, Christoph Groth  wrote:
>> Maybe not.  While it would be nice to solve the loop-and-a-half
>> "problem" and the loop variable initialization "problem" (not everyone
>> agrees these are even problems, especially now that we have
>> comprehensions and generator expressions), as a matter of taste I like
>> the fact that this particular class of side effects is given weighty
>> statement syntax rather than more lightweight expression syntax.
>
> I think that this is the crucial point.  If it is indeed a design
> principle of Python that expressions should not have the side-effect of
> assigning names, than the whole discussion of PEP 572 could have been
> stopped early on.  I didn't have this impression since core devs
> participated constructively in the discussion.

I don't think it's a "design principle" as such, but it *is* true that
until this point, functions with side effects excluded, Python's
expression syntax has not included any means of assigning names, and
that's expected behaviour (in the sense that when looking for where a
name could have been bound, Python programmers do not look closely at
the detail of expressions, because they can't be the source of an
assignment). This PEP explicitly changes that, and that's a fairly
radical change from current expectations.

As to why core devs participated in the discussion, I can't speak for
anyone else but for me:

1. PEPs deserve to be taken seriously - Chris put a lot of work into
this PEP and simply dismissing it isn't giving it a fair hearing. The
PEP didn't come out of nowhere, there had been previous discussions
that established it was worth writing a PEP.
2. I hadn't really thought of the PEP in those terms. Now that you've
mentioned it, "Python has never before had syntax that assigns names
from within an expression" is quite a significant change, and one the
PEP needs to examine the implications of. It's mostly been covered in
the discussions by now, of course.
3. It was of interest to me. Just because I'm interested in a proposal
doesn't necessarily mean it's a good idea.
4. I didn't like the idea much, and I wanted to raise my objections.
Maybe they could be addressed, maybe not, but participation doesn't
imply endorsement.

Paul
___
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 interpreted differently, but maintaining
> the
> > existing beh

Re: [Python-Dev] PEP 572: Assignment Expressions

[Chris Barker - NOAA Federal]

> Personally, I even slightly prefer
>
> a := 3
>
> to the commonplace
>
> a = 3
> because it visually expresses the asymmetry of the operation.

Careful here! That’s a fine argument for using := in a new language,
but people using := when they don’t need an expression because they
like the symbol better is a reason NOT to do this.

And yes, normally aspirated Pascal WAS my first programming language. :-)

-CHB
___
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: Assignment Expressions

[Ethan Furman]

On 04/20/2018 08:07 AM, Chris Barker - NOAA Federal wrote:

On 04/20/2018 04:25 AM, Christoph Groth wrote:



Personally, I even slightly prefer

a := 3

to the commonplace

a = 3
because it visually expresses the asymmetry of the operation.


Careful here! That’s a fine argument for using := in a new language,
but people using := when they don’t need an expression because they
like the symbol better is a reason NOT to do this.


Unless it's a bug magnet, that doesn't strike me as a good reason NOT to do 
this.

--
~Ethan~

___
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: Assignment Expressions

[Chris Angelico]

On Fri, Apr 20, 2018 at 10:51 PM, Paul Moore  wrote:
> 2. I hadn't really thought of the PEP in those terms. Now that you've
> mentioned it, "Python has never before had syntax that assigns names
> from within an expression" is quite a significant change, and one the
> PEP needs to examine the implications of. It's mostly been covered in
> the discussions by now, of course.

Depending on your definition of "assignment", a lambda function could
count as a means of assigning a variable in a subexpression. But yes,
there is no convenient way to assign to something in a wider scope.

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: Assignment Expressions

[Nick Coghlan]

On 20 April 2018 at 21:25, Christoph Groth  wrote:
> Steven Turnbull wrote:
>>
>> Christoph Groth writes:
>>
>>> Wouldn't it be a pity not to liberate assignments from their boring
>>> statement existence?
>>
>>
>> Maybe not.  While it would be nice to solve the loop-and-a-half
>> "problem" and the loop variable initialization "problem" (not everyone
>> agrees these are even problems, especially now that we have
>> comprehensions and generator expressions), as a matter of taste I like
>> the fact that this particular class of side effects is given weighty
>> statement syntax rather than more lightweight expression syntax.
>
>
> I think that this is the crucial point.  If it is indeed a design
> principle of Python that expressions should not have the side-effect of
> assigning names, than the whole discussion of PEP 572 could have been
> stopped early on.  I didn't have this impression since core devs
> participated constructively in the discussion.

There were a couple of factors at play there. Firstly, python-ideas
and python-dev play different roles in the process, with python-ideas
focused on "Help PEP authors put forward the most compelling proposal
possible", and then python-dev providing the far more stringent filter
of "Do we sincerely believe the long term improvements in language
learnability and code maintainability arising from this change will
outweigh the inevitable near term costs?" (python-ideas does consider
the latter question as well, but we're more willing to spend time on
ideas that only reach the level "Maybe? Depending on your point of
view?").

Secondly, the original PEP proposed sublocal scopes *precisely* to
help preserve that property by limiting the impact of any name binding
side effects to a single statement (albeit an arbtirarily long nested
suite in the case of compound statements).

My own enthusiasm for the idea largely waned after folks successfully
campaigned for "we'd prefer side effects to introducing a new kind of
scope" (and while I'm definitely sympathetic to the "Python's name
lookup scoping rules are already excessively complicated" point of
view, I also think that if "=" and ":=" both target the same kind of
scope, there isn't enough new expressiveness introduced by the latter
to justify the syntactic complexity of adding it).

Cheers,
Nick.

P.S. While I'm not planning to work on it myself anytime soon, I think
the sublocal scoping semantics proposed in earlier versions of PEP 572
would provide a *much* better developer experience for PEP 3150's
"given" clause (which is currently deferred indefinitely, as even I
don't particularly like the current incarnation of that proposal).

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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: Assignment Expressions

[Nick Coghlan]

On 21 April 2018 at 01:49, Chris Angelico  wrote:
> On Fri, Apr 20, 2018 at 10:51 PM, Paul Moore  wrote:
>> 2. I hadn't really thought of the PEP in those terms. Now that you've
>> mentioned it, "Python has never before had syntax that assigns names
>> from within an expression" is quite a significant change, and one the
>> PEP needs to examine the implications of. It's mostly been covered in
>> the discussions by now, of course.
>
> Depending on your definition of "assignment", a lambda function could
> count as a means of assigning a variable in a subexpression. But yes,
> there is no convenient way to assign to something in a wider scope.

We used to sort of have one (Python 2 list comprehensions), and the
behaviour was sufficiently unpopular that Py3 introduced an implicitly
nested scope to keep the iteration variable name from leaking :)

That history is a non-trivial part of why I advocated more strongly
for the original sublocal scoping version of the proposal: with
tighter lexical scoping for expression level assignments, I think we'd
be able to avoid most of the downsides that come from reinstating the
ability for expressions to bind and rebind names.

However, given how those original discussions went, I now think the
only way that option might be successfully pitched to people would be
to propose a statement-level variant of it first (perhaps in the form
of a heavily revised variant of PEP 3150's given clause), and then
only propose "expression level name binding with implicit sublocal
scopes" after the semantics of sublocal scoping were already
established elsewhere.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2018-04-13 - 2018-04-20)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open6587 (+15)
  closed 38484 (+32)
  total  45071 (+47)

Open issues with patches: 2573 


Issues opened (30)
==

#33274: minidom removeAttributeNode returns None
https://bugs.python.org/issue33274  opened by iter

#33275: glob.glob should explicitly note that results aren't sorted
https://bugs.python.org/issue33275  opened by Ben FrantzDale

#33276: Clarify that __path__ can't be set to just anything
https://bugs.python.org/issue33276  opened by brett.cannon

#33277: Deprecate __loader__, __package__, __file__, and __cached__ on
https://bugs.python.org/issue33277  opened by brett.cannon

#33278: libexpat uses HAVE_SYSCALL_GETRANDOM instead of HAVE_GETRANDOM
https://bugs.python.org/issue33278  opened by lemburg

#33280: Update link to Tcl/Tk 8.6 man pages in tkinter.rst
https://bugs.python.org/issue33280  opened by adelfino

#33281: ctypes.util.find_library not working on macOS
https://bugs.python.org/issue33281  opened by Ian Burgwin

#33282: Subprocess Popen communicate hung if stdin not given to Popen,
https://bugs.python.org/issue33282  opened by JatinGoel

#33284: Increase test coverage for numbers.py
https://bugs.python.org/issue33284  opened by Barry Devlin

#33286: Conflict between tqdm and multiprocessing on windows
https://bugs.python.org/issue33286  opened by schwemro

#33289: askcolor is returning floats for r,g,b values instead of ints
https://bugs.python.org/issue33289  opened by Bryan.Oakley

#33294: Support complex expressions for py-print command.
https://bugs.python.org/issue33294  opened by Martin Liška

#33295: ERROR: test_sites_no_connection_close (test.test_urllib2net.Ot
https://bugs.python.org/issue33295  opened by inada.naoki

#33296: datetime.datetime.utcfromtimestamp call decimal causes precisi
https://bugs.python.org/issue33296  opened by anglister

#33297: Mention Pillow package on tkinter.rst to work with more image 
https://bugs.python.org/issue33297  opened by adelfino

#33300: Bad usage example in id() DocString
https://bugs.python.org/issue33300  opened by gneff

#33301: Add __contains__ to pathlib
https://bugs.python.org/issue33301  opened by Alok Singh

#33302: The search for pyvenv.cfg doesn't match PEP 405
https://bugs.python.org/issue33302  opened by mattheww

#33303: ElementTree Comment text isn't escaped
https://bugs.python.org/issue33303  opened by johnburnett

#33305: Improve syntax error for numbers with leading zero
https://bugs.python.org/issue33305  opened by steven.daprano

#33306: Improving SyntaxError for unmatched parentheses
https://bugs.python.org/issue33306  opened by serhiy.storchaka

#33309: Unittest Mock objects do not freeze arguments they are called 
https://bugs.python.org/issue33309  opened by slacknate

#33311: cgitb: remove parentheses when the error is in module
https://bugs.python.org/issue33311  opened by sblondon

#33312: ubsan undefined behavior sanitizer flags struct _dictkeysobjec
https://bugs.python.org/issue33312  opened by gregory.p.smith

#33314: Bad rendering in the documentation for the os module
https://bugs.python.org/issue33314  opened by pablogsal

#33315: Allow queue.Queue to be used in type annotations
https://bugs.python.org/issue33315  opened by sproshev

#33316: PyThread_release_lock always fails
https://bugs.python.org/issue33316  opened by Ivan.Pozdeev

#33317: `repr()` of string in NFC and NFD forms does not differ
https://bugs.python.org/issue33317  opened by pekka.klarck

#33318: Move folding tuples of constants into compiler.c from peephole
https://bugs.python.org/issue33318  opened by serhiy.storchaka

#33319: `subprocess.run` documentation doesn't tell is using `stdout=P
https://bugs.python.org/issue33319  opened by pekka.klarck



Most recent 15 issues with no replies (15)
==

#33319: `subprocess.run` documentation doesn't tell is using `stdout=P
https://bugs.python.org/issue33319

#33318: Move folding tuples of constants into compiler.c from peephole
https://bugs.python.org/issue33318

#33316: PyThread_release_lock always fails
https://bugs.python.org/issue33316

#33315: Allow queue.Queue to be used in type annotations
https://bugs.python.org/issue33315

#33314: Bad rendering in the documentation for the os module
https://bugs.python.org/issue33314

#33311: cgitb: remove parentheses when the error is in module
https://bugs.python.org/issue33311

#33309: Unittest Mock objects do not freeze arguments they are called 
https://bugs.python.org/issue33309

#33306: Improving SyntaxError for unmatched parentheses
https://bugs.python.org/issue33306

#33303: ElementTree Comment text isn't escaped
https://bugs.python.org/issue33303

#33302: The search for pyvenv.cfg doesn't match PEP 405
https://bugs.python.org/issue33302

#33301: Add __contains

Re: [Python-Dev] PEP 572: Assignment Expressions

[Christoph Groth]

Chris Barker - NOAA Federal wrote:

> > Personally, I even slightly prefer
> >
> > a := 3
> >
> > to the commonplace
> >
> > a = 3
> > because it visually expresses the asymmetry of the operation.
>
> Careful here! That’s a fine argument for using := in a new language,
> but people using := when they don’t need an expression because they
> like the symbol better is a reason NOT to do this.

Perhaps you are right and it is indeed unrealistic to expect people to
(eventually) shift to using := for simple assignments after 28 years of
Python...

Then I think it would be also OK to introduce a fully general ":=" but
discourage its use in assignment statements.  However, it seems strange
to forbid the use of one expression (namely ":=") as a statement while
all other expressions are allowed.  (So there seems no alternative to
accepting both = and := in statements, and if I understand you correctly
you consider this a problem.)

One way or the other, I'd like to underline a point that I made
yesterday: I believe that it's important for sanity that taking any
existing assignment statement and replacing all occurrences of "=" by
":=" does not have any effect on the program.

PEP 572 currently proposes to make ":=" a binary operator that is
evaluated from right to left.

Christoph
___
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: Assignment Expressions

[Antoine Pitrou]

On Fri, 20 Apr 2018 13:25:02 +0200
Christoph Groth  wrote:
> 
> I think that this is the crucial point.  If it is indeed a design
> principle of Python that expressions should not have the side-effect of
> assigning names, than the whole discussion of PEP 572 could have been
> stopped early on.  I didn't have this impression since core devs
> participated constructively in the discussion.

python-dev and python-ideas are two different mailing-lists with
different participants, so there's a selection bias here.  People who
are willing follow lengthy python-ideas discussions may be more
tolerant to adventurous language changes.  Many core developers
(including myself) don't read python-ideas routinely.

Regards

Antoine.


___
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: Assignment Expressions

[Mike Miller]

On 2018-04-19 23:52, Chris Angelico wrote:

And are limited to conditions that check the truthiness/falsiness of
the value you care about. So that works for re.match, but not for
anything that might return -1 (a lot of C APIs do that, so if you're
working with a thin wrapper, that might be all you get), and it'll
encourage people to use this form when "is not None" would be more
appropriate (setting up for a failure if ever the API returned a


From the previously discussed code, it might look like this:

while (file.get_next_token() as token) != -1:
doc += token

Shouldn't be needed often, but I find it readable enough.

More generally, I've been -0 on this idea because I've come to appreciate 
Python's less-clever i.e. "dumb" loop syntax, and ":=" combined with 
assignment-expressions doesn't feel like Python at all but rather Pascal and C 
had a love-child, haha.


I could mildly support the "as" syntax however, since it is so darn readable and 
has analogues in other places.


That leaves what to do with "with".  Guess I missed the part in the discussion 
where we couldn't fit the syntax into it.  Would requiring parens here not work?


with (expr() as name) as conman:
pass

This should rarely be necessary or useful, correct?  Perhaps disallow for now.

On assignment to names/subscripts, just names sounds simpler for the first 
round.

Also the current "while" itself could be a bit simpler by making the expression 
optional and slightly less verbose:


while:
points = learner.get(static_hint)
if not points:
   break


Thanks for the hard work,
-Mike
___
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: Assignment Expressions

[Christoph Groth]

Nick Coghlan wrote:

> I also think that if "=" and ":=" both target the same kind of scope,
> there isn't enough new expressiveness introduced by the latter to
> justify the syntactic complexity of adding it.

OK, but then how about introducing assignment expressions with the "="
operator but *requiring* extra parens (similar to how modern C compilers
warn about assignment expressions without parens), e.g.

while (obj = get()):
process(obj)

The semantics of assignment expressions could be exactly what I proposed
for ":=", i.e. completely consistent with assignment statements.

Assignment statements could be either left as they are or could be
treated as expressions.  That second choice would have consequences for
interactive sessions:

>>> a = 3
3



The above would bring the benefits of assignment expressions in a
minimally invasive but safe way.  Moreover, it would not feel like
Pascal!  The only downside is that "=" stands out less than ":=" so that
the presence of side-effects would be somewhat less visible.

Christoph
___
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: Assignment Expressions

[Ethan Furman]

On 04/20/2018 11:15 AM, Christoph Groth wrote:

Nick Coghlan wrote:


I also think that if "=" and ":=" both target the same kind of scope,
there isn't enough new expressiveness introduced by the latter to
justify the syntactic complexity of adding it.


OK, but then how about introducing assignment expressions with the "="
operator but *requiring* extra parens (similar to how modern C compilers
warn about assignment expressions without parens), e.g.


Using a single "=" for assignment expressions isn't going to happen.  Period.

--
~Ethan~

___
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: Assignment Expressions

[Christoph Groth]

Ethan Furman wrote:
> On 04/20/2018 11:15 AM, Christoph Groth wrote:
> > Nick Coghlan wrote:
> >
> >> I also think that if "=" and ":=" both target the same kind of scope,
> >> there isn't enough new expressiveness introduced by the latter to
> >> justify the syntactic complexity of adding it.
> >
> > OK, but then how about introducing assignment expressions with the "="
> > operator but *requiring* extra parens (similar to how modern C
> > compilers warn about assignment expressions without parens), e.g.
> 
> Using a single "=" for assignment expressions isn't going to happen.
> Period.

Huh, I didn't want to irritate anyone!

Guido wrote [1] on python-ideas:

> I also think it's fair to at least reconsider adding inline
> assignment, with the "traditional" semantics (possibly with mandatory
> parentheses).  This would be easier to learn and understand for people
> who are familiar with it from other languages (C++, Java, JavaScript).

I interpreted this in the way that he at least doesn't rule out "= with
parens" completely.  Perhaps he meant ":= with parens", but that would
seem redundant.

[1]
https://mail.python.org/pipermail/python-ideas/2018-March/049409.html
___
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: Assignment Expressions

[Ethan Furman]

On 04/20/2018 11:31 AM, Christoph Groth wrote:

Ethan Furman wrote:

On 04/20/2018 11:15 AM, Christoph Groth wrote:



OK, but then how about introducing assignment expressions with the "="
operator but *requiring* extra parens (similar to how modern C
compilers warn about assignment expressions without parens), e.g.


Using a single "=" for assignment expressions isn't going to happen.
Period.


Huh, I didn't want to irritate anyone!


No worries.  It's just not going to happen.  ;)



Guido wrote [1] on python-ideas:


I also think it's fair to at least reconsider adding inline
assignment, with the "traditional" semantics (possibly with mandatory
parentheses).  This would be easier to learn and understand for people
who are familiar with it from other languages (C++, Java, JavaScript).


I interpreted this in the way that he at least doesn't rule out "= with
parens" completely.  Perhaps he meant ":= with parens", but that would
seem redundant.


Ah.  I believe he was referring to not having a statement-local binding, but a normal binding instead (so either local 
or global depending on where the expression occurred).


--
~Ethan~
___
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: Assignment Expressions

[Guido van Rossum]

Christoph's interpretation is correct. I don't rule that out. I also
separately proposed := as something that more people could get behind,
though perhaps it's all moot, and perhaps the PEP would gain clarity if it
went back to proposing "=". (Mostly kidding.)

On Fri, Apr 20, 2018 at 11:47 AM, Ethan Furman  wrote:

> On 04/20/2018 11:31 AM, Christoph Groth wrote:
>
>> Ethan Furman wrote:
>>
>>> On 04/20/2018 11:15 AM, Christoph Groth wrote:
>>>
>>
> OK, but then how about introducing assignment expressions with the "="
 operator but *requiring* extra parens (similar to how modern C
 compilers warn about assignment expressions without parens), e.g.

>>>
>>> Using a single "=" for assignment expressions isn't going to happen.
>>> Period.
>>>
>>
>> Huh, I didn't want to irritate anyone!
>>
>
> No worries.  It's just not going to happen.  ;)
>
>
> Guido wrote [1] on python-ideas:
>>
>> I also think it's fair to at least reconsider adding inline
>>> assignment, with the "traditional" semantics (possibly with mandatory
>>> parentheses).  This would be easier to learn and understand for people
>>> who are familiar with it from other languages (C++, Java, JavaScript).
>>>
>>
>> I interpreted this in the way that he at least doesn't rule out "= with
>> parens" completely.  Perhaps he meant ":= with parens", but that would
>> seem redundant.
>>
>
> Ah.  I believe he was referring to not having a statement-local binding,
> but a normal binding instead (so either local or global depending on where
> the expression occurred).
>
> --
> ~Ethan~
>
> ___
> 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!

[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: Assignment Expressions

[Chris Angelico]

On Sat, Apr 21, 2018 at 2:17 AM, Christoph Groth
 wrote:
> Chris Barker - NOAA Federal wrote:
>
>> > Personally, I even slightly prefer
>> >
>> > a := 3
>> >
>> > to the commonplace
>> >
>> > a = 3
>> > because it visually expresses the asymmetry of the operation.
>>
>> Careful here! That’s a fine argument for using := in a new language,
>> but people using := when they don’t need an expression because they
>> like the symbol better is a reason NOT to do this.
>
> Perhaps you are right and it is indeed unrealistic to expect people to
> (eventually) shift to using := for simple assignments after 28 years of
> Python...

It's not just 28 years of Python. It's also that other languages use
"=" for assignment. While this is by no means a clinching argument, it
does have some weight; imagine if Python used "=" for comparison and
":=" for assignment - anyone who works simultaneously with multiple
languages is going to constantly type the wrong operator. (I get this
often enough with comment characters, but my editor will usually tell
me straight away if I type "// blah" in Python, whereas it won't
always tell me that I used "x = 1" when I wanted one of the other
forms.)

> One way or the other, I'd like to underline a point that I made
> yesterday: I believe that it's important for sanity that taking any
> existing assignment statement and replacing all occurrences of "=" by
> ":=" does not have any effect on the program.
>
> PEP 572 currently proposes to make ":=" a binary operator that is
> evaluated from right to left.

This is one of the points that I was halfway through working on when I
finally gave up on working on a reference implementation for a
likely-doomed PEP. It might be possible to make := take an entire
sequence of assignables and then set them left to right; however, this
would be a lot more complicated, and I'm not even sure I want that
behaviour. I don't want to encourage people to replace all "=" with
":=" just for the sake of it. The consistency is good if it can be
achieved, but you shouldn't actually DO that sort of thing normally.

Consider: one of the important reasons to define the assignment order
is so you can reference a subscript and also use it. For instance:

idx, items[idx] = new_idx, new_val

But you don't need that with :=, because you can:

items[idx := new_idx] = new_val

(and you can use := for the second one if you wish). And actually,
this one wouldn't even change, because it's using tuple unpacking, not
the assignment order of chained assignments. I cannot think of any
situation where you'd want to write this:

idx = items[idx] = f()

inside an expression, and thus need to write it as:

g(items[idx] := idx := f())

So I have no problem with a style guide saying "yeah just don't do
that", and the PEP saying "if you do this, the semantics won't be
absolutely identical to '='". Which it now does.

Now, if someone else wants to work on the reference implementation,
they're welcome to create this feature and then see whether they like
it. But since I can't currently prove it's possible, I'm not going to
specify it in the PEP.

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: Assignment Expressions

[Chris Angelico]

On Sat, Apr 21, 2018 at 2:50 AM, Mike Miller  wrote:
>
> On 2018-04-19 23:52, Chris Angelico wrote:
>>
>> And are limited to conditions that check the truthiness/falsiness of
>> the value you care about. So that works for re.match, but not for
>> anything that might return -1 (a lot of C APIs do that, so if you're
>> working with a thin wrapper, that might be all you get), and it'll
>> encourage people to use this form when "is not None" would be more
>> appropriate (setting up for a failure if ever the API returned a
>
>
> From the previously discussed code, it might look like this:
>
> while (file.get_next_token() as token) != -1:
> doc += token

Except that that's now a feature of expressions, NOT of the loop
construct. And then you're left with: why not permit this everywhere?

> That leaves what to do with "with".  Guess I missed the part in the
> discussion where we couldn't fit the syntax into it.  Would requiring parens
> here not work?
>
> with (expr() as name) as conman:
> pass
>
> This should rarely be necessary or useful, correct?  Perhaps disallow for
> now.

What would these mean?

from contextlib import closing
with open(fn) as f:
with (open(fn) as f):
with closing(urlopen(url)) as dl:
with closing(urlopen(url) as dl):
with (closing(urlopen(url)) as dl):

One of these is not like the others...

> Also the current "while" itself could be a bit simpler by making the
> expression optional and slightly less verbose:
>
> while:
> points = learner.get(static_hint)
> if not points:
>break

As an alias for "while True"? Not a lot of benefit. I'd rather do
something like this:

while "get more learners":

which at least tells the next reader that there is a condition, even
if not a coded one.

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: Assignment Expressions

[David Mertz]

It's horrors like this:

g(items[idx] := idx := f())

That make me maybe +0 if the PEP only allowed simple name targets, but
decisively -1 for any assignment target in the current PEP.

I would much rather never have to read awful constructs like that than get
the minor convenience of:

if (val := some_expensive_func()) > 0:
x = call_something(val)

On Fri, Apr 20, 2018, 3:39 PM Chris Angelico  wrote:

> On Sat, Apr 21, 2018 at 2:17 AM, Christoph Groth
>  wrote:
> > Chris Barker - NOAA Federal wrote:
> >
> >> > Personally, I even slightly prefer
> >> >
> >> > a := 3
> >> >
> >> > to the commonplace
> >> >
> >> > a = 3
> >> > because it visually expresses the asymmetry of the operation.
> >>
> >> Careful here! That’s a fine argument for using := in a new language,
> >> but people using := when they don’t need an expression because they
> >> like the symbol better is a reason NOT to do this.
> >
> > Perhaps you are right and it is indeed unrealistic to expect people to
> > (eventually) shift to using := for simple assignments after 28 years of
> > Python...
>
> It's not just 28 years of Python. It's also that other languages use
> "=" for assignment. While this is by no means a clinching argument, it
> does have some weight; imagine if Python used "=" for comparison and
> ":=" for assignment - anyone who works simultaneously with multiple
> languages is going to constantly type the wrong operator. (I get this
> often enough with comment characters, but my editor will usually tell
> me straight away if I type "// blah" in Python, whereas it won't
> always tell me that I used "x = 1" when I wanted one of the other
> forms.)
>
> > One way or the other, I'd like to underline a point that I made
> > yesterday: I believe that it's important for sanity that taking any
> > existing assignment statement and replacing all occurrences of "=" by
> > ":=" does not have any effect on the program.
> >
> > PEP 572 currently proposes to make ":=" a binary operator that is
> > evaluated from right to left.
>
> This is one of the points that I was halfway through working on when I
> finally gave up on working on a reference implementation for a
> likely-doomed PEP. It might be possible to make := take an entire
> sequence of assignables and then set them left to right; however, this
> would be a lot more complicated, and I'm not even sure I want that
> behaviour. I don't want to encourage people to replace all "=" with
> ":=" just for the sake of it. The consistency is good if it can be
> achieved, but you shouldn't actually DO that sort of thing normally.
>
> Consider: one of the important reasons to define the assignment order
> is so you can reference a subscript and also use it. For instance:
>
> idx, items[idx] = new_idx, new_val
>
> But you don't need that with :=, because you can:
>
> items[idx := new_idx] = new_val
>
> (and you can use := for the second one if you wish). And actually,
> this one wouldn't even change, because it's using tuple unpacking, not
> the assignment order of chained assignments. I cannot think of any
> situation where you'd want to write this:
>
> idx = items[idx] = f()
>
> inside an expression, and thus need to write it as:
>
> g(items[idx] := idx := f())
>
> So I have no problem with a style guide saying "yeah just don't do
> that", and the PEP saying "if you do this, the semantics won't be
> absolutely identical to '='". Which it now does.
>
> Now, if someone else wants to work on the reference implementation,
> they're welcome to create this feature and then see whether they like
> it. But since I can't currently prove it's possible, I'm not going to
> specify it in the PEP.
>
> 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/mertz%40gnosis.cx
>
___
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: Assignment Expressions

[Chris Angelico]

On Sat, Apr 21, 2018 at 6:04 AM, David Mertz  wrote:
> It's horrors like this:
>
> g(items[idx] := idx := f())
>
> That make me maybe +0 if the PEP only allowed simple name targets, but
> decisively -1 for any assignment target in the current PEP.

But that's my point: you shouldn't need to write that. Can anyone give
me a situation where that kind of construct is actually useful? Much
more common would be to use := inside the square brackets, which makes
the whole thing a lot more sane.

You can ALWAYS write stupid code. Nobody can or will stop you.

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: Assignment Expressions

[Guido van Rossum]

Does the PEP currently propose to *allow* that horrible example? I thought
Tim Peters successfully pleaded to *only* allow a single "NAME := ".
You don't have to implement this restriction -- we know it's possible to
implement, and if specifying this alone were to pull enough people from -1
to +0 there's a lot of hope!

On Fri, Apr 20, 2018 at 1:12 PM, Chris Angelico  wrote:

> On Sat, Apr 21, 2018 at 6:04 AM, David Mertz  wrote:
> > It's horrors like this:
> >
> > g(items[idx] := idx := f())
> >
> > That make me maybe +0 if the PEP only allowed simple name targets, but
> > decisively -1 for any assignment target in the current PEP.
>
> But that's my point: you shouldn't need to write that. Can anyone give
> me a situation where that kind of construct is actually useful? Much
> more common would be to use := inside the square brackets, which makes
> the whole thing a lot more sane.
>
> You can ALWAYS write stupid code. Nobody can or will stop you.
>
> 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: Assignment Expressions

[Chris Angelico]

On Sat, Apr 21, 2018 at 6:59 AM, Guido van Rossum  wrote:
> Does the PEP currently propose to *allow* that horrible example? I thought
> Tim Peters successfully pleaded to *only* allow a single "NAME := ".
> You don't have to implement this restriction -- we know it's possible to
> implement, and if specifying this alone were to pull enough people from -1
> to +0 there's a lot of hope!

I don't see much value in restricting the assignment target to names
only, but if that's what it takes, it can be restricted, at least
initially. As to chaining... well, since the entire construct (target
:= expr) is an expression, it can be used on the right of :=, so short
of outright forbidding it, there's not a lot to be done.

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: Assignment Expressions

[Guido van Rossum]

On Fri, Apr 20, 2018 at 2:04 PM, Chris Angelico  wrote:

> On Sat, Apr 21, 2018 at 6:59 AM, Guido van Rossum 
> wrote:
> > Does the PEP currently propose to *allow* that horrible example? I
> thought
> > Tim Peters successfully pleaded to *only* allow a single "NAME :=
> ".
> > You don't have to implement this restriction -- we know it's possible to
> > implement, and if specifying this alone were to pull enough people from
> -1
> > to +0 there's a lot of hope!
>
> I don't see much value in restricting the assignment target to names
> only, but if that's what it takes, it can be restricted, at least
> initially.


All of this is an exercise in listening and compromise, not in solving
puzzles.


> As to chaining... well, since the entire construct (target
> := expr) is an expression, it can be used on the right of :=, so short
> of outright forbidding it, there's not a lot to be done.
>

It would be more work but it can definitely be done (perhaps by introducing
a syntactic construct of intermediate precedence). People could write "a :=
(b := foo())" but that way they resolve the ambiguity. Although if we
restrict targets to just names there's less concern about ambiguity.

-- 
--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: Assignment Expressions

[Tim Peters]

[Guido, about
 g(items[idx] := idx := f())
]
> Does the PEP currently propose to *allow* that horrible example? I thought
> Tim Peters successfully pleaded to *only* allow a single "NAME := ".

I was "successful" only in that the two of us agreed that would be far
less disruptive, and quite possibly an actual improvement ;-)  But I
only argued for limiting assignment expressions to the form

 identifier ":=" expression

I expected that, given that expressions "naturally nest", chained
targets could still be specified:

a := b := c:= 5

but since they're all plain names there's no way to tell whether the
bindings occur "left to right" or "right to left" short of staring at
the generated code.  I have no use case for chaining plain-name
targets in assignment expressions, but didn't see a good reason to
torture the implementation to forbid it.  I expected chaining would
just be an unused-in-practice possibility.  Much like, e.g.,

a in b in c in d

is an unused-in-practice possibility.

And I'll take this opportunity to repeat the key point for me:  I
tried hard, but never found a single case based on staring at real
code where allowing _fancier_ (than "plain name") targets would be a
real improvement.  In every case I thought it _might_ help, it turned
out that it really didn't unless Python _also_ grew an analog to C's
"comma operator" (take only the last result from a sequence of
expressions).  I'll also note that I asked if anyone else had a
real-life example, and got no responses.


There were lots of "real life" cases where plain-name targets allowed
for code improvement, though.


> You don't have to implement this restriction -- we know it's possible to
> implement, and if specifying this alone were to pull enough people from -1
> to +0 there's a lot of hope!

Given my experience with _trying_ to find use cases for fancier
targets, and getting burned every time, I'm on the minus side of the
current PEP, because - best I can tell - all the extra complexity
would create an "attractive nuisance" :-(
___
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: Assignment Expressions

[Mike Miller]

On 2018-04-20 12:43, Chris Angelico wrote:
> Except that that's now a feature of expressions, NOT of the loop
> construct. And then you're left with: why not permit this everywhere?

Sorry, I didn't understand.  Didn't mean to imply it couldn't be used 
everywhere.

> What would these mean?

My expectations:

with open(fn) as f:   # current behavior
with (open(fn) as f): # syntax error, missing clause
with closing(urlopen(url)) as dl: # current behavior
with closing(urlopen(url) as dl): # syntax error, missing clause
with (closing(urlopen(url)) as dl):   # syntax error, missing clause

In other words, the with statement would continue to require an as clause 
outside of the parentheses.  A double name binding doesn't seem very useful however.


-Mike
___
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: Assignment Expressions

[Jelle Zijlstra]

2018-04-20 14:54 GMT-07:00 Mike Miller :

>
> In other words, the with statement would continue to require an as clause
> outside of the parentheses.  A double name binding doesn't seem very useful
> however.
>
> The with statement does not require an as clause.
___
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: Assignment Expressions

[Mike Miller]

On 2018-04-20 14:59, Jelle Zijlstra wrote:
> In other words, the with statement would continue to require an as clause
> outside of the parentheses.  A double name binding doesn't seem very 
useful
> however.
>
> The with statement does not require an as clause.

Sorry, more precisely a contenxt-manager object to be returned.  So perhaps this 
"with" issue may not be one at all.


___
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: Assignment Expressions

[MRAB]

On 2018-04-20 22:33, Tim Peters wrote:
[snip]


And I'll take this opportunity to repeat the key point for me:  I
tried hard, but never found a single case based on staring at real
code where allowing _fancier_ (than "plain name") targets would be a
real improvement.  In every case I thought it _might_ help, it turned
out that it really didn't unless Python _also_ grew an analog to C's
"comma operator" (take only the last result from a sequence of
expressions).  I'll also note that I asked if anyone else had a
real-life example, and got no responses.

Could a semicolon in a parenthesised expression be an equivalent to C's 
"comma operator"?


[snip]
___
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: Assignment Expressions

[Chris Angelico]

On Sat, Apr 21, 2018 at 8:07 AM, Mike Miller  wrote:
> On 2018-04-20 14:59, Jelle Zijlstra wrote:
>> In other words, the with statement would continue to require an as
>> clause
>> outside of the parentheses.  A double name binding doesn't seem very
>> useful
>> however.
>>
>> The with statement does not require an as clause.
>
> Sorry, more precisely a contenxt-manager object to be returned.  So perhaps
> this "with" issue may not be one at all.

That's completely different, and isn't a syntactic point. They may
bomb with AttributeError at run time, but they also may not.

> My expectations:
>
> with open(fn) as f:   # current behavior
> with (open(fn) as f): # syntax error, missing clause
> with closing(urlopen(url)) as dl: # current behavior
> with closing(urlopen(url) as dl): # syntax error, missing clause
> with (closing(urlopen(url)) as dl):   # syntax error, missing clause

The second and fifth could be special cased as either the same as
first and third, or as SyntaxErrors. (But which?) The fourth one is
very tricky. If 'expr as name' is allowed inside arbitrary
expressions, why shouldn't it be allowed there? The disconnect between
viable syntax and useful statements is problematic here.

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: Assignment Expressions

[Anthony Flury via Python-Dev]

I am entirely new to this list, but if I can I would like share my 
comments :


 * I do think this proposal  :=  has merit in my
   opinion; it does make some code more readable.

 * I think readability is only improved if :

 * target is restricted to a simple name - I don't see a benefit in
   more complex targets
 * chaining is not allowed - I think the construct :

            while (line := input.read_row()) is not None:
                    process_line(line)

        Is readable, but :

            while (current_line := line := input.read_row()) is not
   None:
                    line = process_line(line)

  is not obvious - and certainly isn't any more obvious than :

            while (line := input.read_row()) is not None:
                    current_line = line
                line = process_line(line)

 * The current expectations of how comprehensions work should also be
   honored; I don't claim to have fully followed all of the discussions
   around this, but it seems to me that comprehensions work in a
   particular way because of a concerted effect (especially in Python
   3) to make them that way. They are self contained and don't leak
   values in their containing scope. Similarly I think that setting
   variables within a comprehension is just for the benefit of readable
   code within the comprehension - i.e. :

stuff = [[y, x/y] for x in range(5) for y in [f(x)]]

                can become :

stuff = [[y := f(x), x/y] for x in range(5)]

So - overall from me a conditional +1 - conditions as above; if they are 
not possible then -1 from me.


--
Anthony Flury
email : *anthony.fl...@btinternet.com*
Twitter : *@TonyFlury *

___
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: Assignment Expressions

[Tim Peters]

[Chris Angelico ]
> I don't see much value in restricting the assignment target to names
> only, but if that's what it takes, it can be restricted, at least
> initially.

I believe this point was made most clearly before by Terry Reedy, but
it bears repeating :-)  This is from the PEP's motivation:

"""
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.
"""

As "head arguments" go, that's a good one!  But restricting assignment
expressions to

identifier ":=" expression

satisfies it.  If what's of value is to name the result of an
expression, that single case handles that and _only_ that.  In a
sense, it's "the simplest thing that could possibly work", and that's
generally a good thing to aim for.

Python assignment _statements_ are way more complex than that.
Besides just giving names to expression results, they can also
implicitly invoke arbitrarily complex __setitem__ and __setattr__
methods on targets, rely on all sorts of side effects across chained
assignments, and support funky syntax for magically iterating over an
expression's iterable result.

While that can all be useful _in_ an assignment statement, the PEP's
motivation doesn't say a word about why any of _that_ would also be
useful buried inside an assignment expression.  There doesn't appear
to be a good "head argument" for why, besides "why not?".  That's not
enough.

I think it's no coincidence that every example of an _intended_ use is
of the simple

identifier ":=" expression

form. There are no examples of fancier targets in the PEP, and - more
importantly - also none I saw in the hundreds of mailing-list messages
since this started.  Except for a few of mine, where I tried to
demonstrate why _trying_ fancier targets in examples derived from real
code made the original "loop and a half" code _worse_  And where other
people were illustrating how incomprehensibly code _could_ be written
(which isn't a real interest of mine).

Short course:  e.g., while a general assignment expression can
"unpack" an iterable expression result, giving names to its elements,
there's no clean way to _use_ the names bound by the unpacking _in_
the "if" or "while" tests.   That's fine for `for` loops (only the
_body_ of the loop needs the names), but in conditional constructs you
typically want to use the names _in_ the condition being tested.

if ((a, b, c) := func_returning_triple()) and b > 0:
process(a+b, b+c, a+c)

seems to be as good as it gets, but inherently relies on "a trick":
that a 3-tuple is always truthy, regardless of content.  OTOH,

if ((a, b, c) := func_returning_triple())[1] > 0:

doesn't rely on a trick, but can't use the name `b` in the test(!).

if [((a, b, c) := func_returning_triple()), b > 0][-1]::

manages to avoid "a trick", and to use the natural `b > 0`, but is ...
strained ;-)

So, to my eyes, this is a clear improvement over all of those:

a, b, c = func_returning_triple()
if b > 0:
process(a+b, b+c, a+c)

Of course I could be cherry-picking a bad example there, but that's
not the intent:  I'm still waiting for anyone to post an example where
a "fancy" assignment-expression target would actually make code
clearer.  I haven't found one.

There are lots of examples when the target is a plain single name.

Why the stark difference?  I don't need deep theoretical reasons to
see that there _is_ one, or to conclude that - in the absence of
compelling use cases - complex assignment-expression targets are
probably a Poor Idea.
___
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

[Python-Dev] Introducing python.zulipchat.com

[Brett Cannon]

As an experiment we have gotten an instance of Zulip running for Python's
development at https://python.zulipchat.com (IOW this is for discussing the
development *of* Python only*)*. As Guido has put it you can view Zulip
like "hyper-interactive email" as we have streams corresponding to
equivalent mailing lists and all messages fall under a topic so
conversations are on-topic.

The instance is currently rather open at the suggestion of Zulip, so people
can create new streams, add bots, etc. There are already bots I have added
for commit notifications, Travis failures, and deployments of Bedevere and
The Knights Who Say Ni.

The invite message when you sign up mentions all this, the CoC, etc., so do
give it a read. Otherwise feel free to join and help us decide if this is
useful enough to make a permanent thing for Python's development!
___
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: Assignment Expressions

[Tim Peters]

[Tim]
>> And I'll take this opportunity to repeat the key point for me:  I
>> tried hard, but never found a single case based on staring at real
>> code where allowing _fancier_ (than "plain name") targets would be a
>> real improvement.  In every case I thought it _might_ help, it turned
>> out that it really didn't unless Python _also_ grew an analog to C's
>> "comma operator" (take only the last result from a sequence of
>> expressions).  I'll also note that I asked if anyone else had a
>> real-life example, and got no responses.

[MRAB ]
> Could a semicolon in a parenthesised expression be an equivalent to C's
> "comma operator"?

I expect it could, but I it's been many years since I tried hacking
Python's grammar, and I wouldn't want a comma operator anyway ;-)

To recycle a recently-posted example, instead of one of these 3:

if ((a, b, c) := func_returning_triple()) and b > 0:
process(a+b, b+c, a+c)

if ((a, b, c) := func_returning_triple())[1] > 0:


if [((a, b, c) := func_returning_triple()), b > 0][-1]::
...

it would allow this instead:

if ((a, b, c) := func_returning_triple(); b > 0):
...

That's better than any of the first three, but I'm not sure it's
better than the original

a, b, c = func_returning_triple()
if b > 0:
...

It _may_ be more readable in other complex-target examples, though.

It's also what's wanted in one of the running plain-name target
examples, _not_ involving a conditional context:

r1, r2 = (D := sqrt(b**-4*a*c); a2 := 2*a; ((-b+D)/a2), (-b-D)/a2))

And if I saw enough code like that, I'd write a PEP suggesting that
Python introduce separate assignment statements where name bindings
persisted across statement boundaries ;-)
___
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: Assignment Expressions

[Chris Angelico]

On Sat, Apr 21, 2018 at 11:38 AM, Anthony Flury via Python-Dev
 wrote:
> I am entirely new to this list, but if I can I would like share my comments
> :
>
>  * I do think this proposal  :=  has merit in my
>opinion; it does make some code more readable.
>
>  * I think readability is only improved if :

There's that word "readability" again. Sometimes I wish the Zen of
Python didn't use it, because everyone seems to think that "readable"
means "code I like".

>  * The current expectations of how comprehensions work should also be
>honored; I don't claim to have fully followed all of the discussions
>around this, but it seems to me that comprehensions work in a
>particular way because of a concerted effect (especially in Python
>3) to make them that way. They are self contained and don't leak
>values in their containing scope. Similarly I think that setting
>variables within a comprehension is just for the benefit of readable
>code within the comprehension - i.e. :
>
> stuff = [[y, x/y] for x in range(5) for y in [f(x)]]
>
> can become :
>
> stuff = [[y := f(x), x/y] for x in range(5)]
>
> So - overall from me a conditional +1 - conditions as above; if they are not
> possible then -1 from me.

Perfectly self-contained. They do everything in their own scope.
Except ... except that they don't.

$ python3.7
Python 3.7.0a4+ (heads/master:95e4d58913, Jan 27 2018, 06:21:05)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class X:
... x = ["spam", "ham"]
... print(["1: "+x for x in x])
... print(["2: "+x for _ in range(1) for x in x])
...
['1: spam', '1: ham']
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 4, in X
  File "", line 4, in 
UnboundLocalError: local variable 'x' referenced before assignment
>>> class Y:
... prefix = "3: "
... print([prefix + x for x in ["spam", "ham"]])
...
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in Y
  File "", line 3, in 
NameError: name 'prefix' is not defined

Introducing expression assignments will make these oddities even more
obvious. You'd be able to demonstrate things like this at function
scope, not just with a class. But the oddities are there, and they are
inherent to the current definition of a comprehension. That's why the
changes are being recommended. They will simplify the peculiarities of
comprehensions, make them far closer to a naive transformation into
longhand, and extremely close to a non-naive-but-still-simple
transformation into longhand.

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: Assignment Expressions

[Nick Coghlan]

On 21 April 2018 at 07:33, Tim Peters  wrote:
> I expected that, given that expressions "naturally nest", chained
> targets could still be specified:
>
> a := b := c:= 5
>
> but since they're all plain names there's no way to tell whether the
> bindings occur "left to right" or "right to left" short of staring at
> the generated code.

The fact class namespaces are ordered by default now allow us to
demonstrate the order of multiple target assignments and tuple
unpacking without staring at generated code:

>>> class AssignmentOrder:
... a = b = c = 0
... d, e, f = range(3)
...
>>> class ReversedAssignmentOrder:
... c = b = a = 0
... f, e, d = range(3)
...
>>> [attr for attr in AssignmentOrder.__dict__ if not attr.startswith("_")]
['a', 'b', 'c', 'd', 'e', 'f']
>>> [attr for attr in ReversedAssignmentOrder.__dict__ if not 
>>> attr.startswith("_")]
['c', 'b', 'a', 'f', 'e', 'd']

So that's a situation where "name = alias = value" could end up
matching "alias := name := value"

(Even in earlier versions, you can illustrate the same assignment
ordering behaviour with the enum module, and there it makes even more
of a difference, as it affects which name binding is considered the
canonical name, and which are considered aliases).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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