Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Pep 572 update #654
@Rosuav, @tim-one: On the plane home from PyCon I did some major surgery on PEP 572. The tl;dr is that I removed the changes to comprehensions and added Tim's proposal for making := inside a comprehension write the target in the containing scope. There's a bit more, below are the bullets from my local commits.
Do you want discussion here or on the ML?
One point that I find curious is that top-level assignment with
Personally, I would prefer to remove the special cases and just say that
The grammar of Python is already a scarily complicated beast to look into. Adopting all of these special cases will make it even more so. Are you happy with the future of Python being "anyone can tinker with the stdlib, someone who knows C can tinker with the implementation of CPython, and only a core dev with at least twenty years' experience can look at the grammar"? Okay, so that's a bit of hyperbole, but only a bit. Every change is going to add some complexity, but IMO the goal should be to add as little as possible.
WRT co-authorship: with the edits you've made here, you absolutely merit putting your own name on it. Tim Peters less obviously, but I definitely wouldn't object to him being a co-author if you and/or he feel it's appropriate.
Here please. The list has become too dysfunctional. I am even thinking that we may recommend to have all discussions in a dedicated tracker or issue.
The justification for disallowing top level
Yeah, but as I said that would weaken support for the proposal.
Most of these special cases will have to checked in the second stage.
But if I'm co-author it's less clear that I can also approve (judge and jury and so on). Tim contributed the special case for
Good point. I'll leave it up to your discretion; at this point, it's another political decision really. You have the power to decide, regardless of authorship status; and you absolutely have merited it, by any logical measurement. Deciding to forego that authorship is your call.
Tim as co-author is fine in my view.
I should clarify some things: I don't have git. I don't know how to use git. I barely know enough about github to enter this comment. And I don't have a C compiler (my MSDN subscription "got lost" somehow when they migrated accounts on their side, and I gave up after some hours of trying to get that straightened out). That's why all I do now is type at mailing lists ;-) Presumably all of that could be repaired with reasonable effort, but there are so many other things I like doing that's not likley to rise to the top of my list soon.
That's why, e.g., when I suggested specific changes for the Reference Manual, I posted the new text rather than generate a patch. It's about all I can do for now.
Since I want the PEP to succeed, whether I'm added as co-author is a purely political issue to me: would that help, or hurt, the PEP's chances? I couldn't care less whether my name is on it either way, and I'm currently unable to generate or test patches either way either.
OK, I've sent some updates:
@tim-one If you have time and energy, it would be great if you could provide some motivating examples from your own life.
There are some TODOs in the text, and there's a section of open issues (with some overlap with the TODOs). Would be great to see opinions on these.
I have another example that quite impressed me at the time. But I never posted it because nobody (except Mark Dickinson) would find it obvious on first or second reading ;-) Nevertheless, there may be some use in adding an example that isn't mindless ;-) Somebody else can judge that:
Where all variables are positive integers, and
It's not obvious why that works, but is no more obvious in the "loop and a half" form. It's hard to prove correctness without building on the right insight (the "arithmetic mean - geometric mean inequality"), and knowing some non-trivial things about how nested floor functions behave. That is, the challenges are in the math, not really in the coding.
If you do know all that, then the assignment-expression form is easily read as "while the current guess is too large, get a smaller guess", where the "too large?" test and the new guess share an expensive sub-expression.
To my eyes, the original form is harder to understand:
- Remove changes to comprehension scope - Make := in comprehensions assign to containing non-comprehension scope - Clarify binding precedence (tighter than comma, not at same level as =) - Remove mention of more complex targets in the future - Explicitly disallow toplevel := - Rewrite section on differences with =, enumerating all of them - Remove "here's how this could be written without :=" from examples
- Tweak first paragraph of "Syntax and semantics" - Add "Exception cases" (various explicit prohibitions) - Clarify that lambda is a containing scope - Clarify that := and = just don't mix - Added "Open questions" section - Added two new rejected alternatives: "Allowing commas to the right" and "Always requiring parentheses" - Minor edits
A very nice set of changes. I'm glad to see the changes to class scopes are gone: that ought to be a separate PEP.
I especially liked your examples of using
A couple of other observations/comments...
You have prohibited using assignment expressions in function defaults:
I don't know how I feel about this, but I recall at least one question of Python-List asking why they can't do this:
It was some years ago and I can't find the post now. But perhaps we might say this is an obscure enough usage that we don't care to support it.
Regarding the Open Questions, I agree with all of the current answers with the possible exception of the last (function defaults) where I'm on the fence.
I've assigned my competing PEP a number (577) and merged it now. PR where I did that: #660
I found the scoping discussion with Tim very helpful, to the point where I became a convert to allowing inline assignment as a variant of augmented assignment, and structured the PEP primarily around allowing the existing augmented assignment operators to be used as expressions. Adding
While I've borrowed much of Tim's scoping proposal, what I have in PEP 577 isn't exactly the same as what you have here:
(Note: now that Guido has pointed me to this PR, I won't post PEP 577 to python-ideas until you're happy with the changes you've made to PEP 572 and have merged them).
I'm one who thinks this should be available where statements are used today. But since the reason to use it there would be to de-emphasize the variable (limit the scope conceptually), making it (literally) a parenthetical comment is fine.
I'm not happy about the number (or even existence) of exceptions/special cases listed, but I think that in practice that will be a problem only for implementors, not users, so ... basically, this comment is a reminder that not everyone is upset by the PEP.