On Tue, Apr 17, 2018 at 7:55 AM, Steve Dower steve.dower@python.org wrote:
Agree with Paul. The PEP is well thought out and well presented, but I really don’t think we need this in Python (and I say this as someone who uses it regularly in C/C#).
-1 on the idea; no disrespect intended toward to people who did a lot of work on it.
Same here. I'm more interested in having anonymous blocks (i.e. scopes), along the lines of PEP 3150, though it's currently #2 on my wish list. :)
-eric
On Tue, 17 Apr 2018 at 14:53 Eric Snow ericsnowcurrently@gmail.com wrote:
On Tue, Apr 17, 2018 at 7:55 AM, Steve Dower steve.dower@python.org wrote:
Agree with Paul. The PEP is well thought out and well presented, but I really don’t think we need this in Python (and I say this as someone who uses it regularly in C/C#).
-1 on the idea; no disrespect intended toward to people who did a lot of work on it.
Same here. I'm more interested in having anonymous blocks (i.e. scopes), along the lines of PEP 3150, though it's currently #2 on my wish list. :)
I'm also -1.
I understand the usefulness of the construct in languages where block scopes make having this kind of expression assignment in e.g. an 'if' guard useful. But for Python and it's LGB scoping -- although I think we need to add an "N" for "non-local" :) -- this is syntactic sugar and I don't see enough wide benefit on top of the potential ugliness/misuse of it to warrant the cognitive overhead of adding it.
Although, as usual, Chris, great PEP! :)
On 19 April 2018 at 02:38, Brett Cannon brett@python.org wrote:
I'm also -1.
I understand the usefulness of the construct in languages where block scopes make having this kind of expression assignment in e.g. an 'if' guard useful. But for Python and it's LGB scoping -- although I think we need to add an "N" for "non-local" :) -- this is syntactic sugar and I don't see enough wide benefit on top of the potential ugliness/misuse of it to warrant the cognitive overhead of adding it.
Although, as usual, Chris, great PEP! :)
Aye, tremendous work on the PEP Chris - assignment expressions are an idea that has come up many, many times on python-ideas, and it's great to finally have a consolidated proposal that attempts to make the best case it can for the idea.
Unfortunately, I still have to admit that even I'm -0 on the idea of actually adding it to the language (despite helping it to reach a plausibly acceptable state), primarily on "more than one way to do it" grounds:
- assignment statements and top-level assignment expressions would be syntactically distinct, but semantically identical
- for the if statement use case, pre-assignment of the re-used part of the condition expression already works fine
- for the while loop use case, I think my discussion with Tim about tuple unpacking shows that the loop-and-a-half construct won't be going anywhere, so users would still end up needing to learn both forms (even for new code)
The comprehension/genexp use case still seems like the most promising candidate for a reasonable justification for the extra complexity, but there's also a solid argument that if a comprehension is complex enough that the lack of assignment expressions is causing problems, then it's also complex enough that it's reasonable to require extracting the algorithm into a named generator function in order to access assignment statements.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Thu, Apr 19, 2018 at 5:45 AM, Nick Coghlan ncoghlan@gmail.com wrote:
- for the while loop use case, I think my discussion with Tim about tuple unpacking shows that the loop-and-a-half construct won't be going anywhere, so users would still end up needing to learn both forms (even for new code)
well, yes, but I've always found while awkward in the common case -- and wanted a better way (maybe an until?).
using:
while True: ...
for a loop with a clear testable termination criteria always felt clunky.
Anyone recall the "canonical" way to loop through the lines of a file before we had the file iterator?
while True: line = fp.readline() if not line: break do_stuff_with(line)
This is in fact, the only compeling use case for this to me -- maybe we could make a way to do an assign and test in a while loop enhancement just for that?
And no, I have no idea what that would look like -- I'm mostly joking.
So -1 on this -- though I agree -- great PEP Chris!
And -1, not -0 because I think this really would add one more complication to a language that used to be so simple, and still is (and should be) used a first programming language. I teach a lot of newbies, and I'm realy not l;ooking forward to one more way to do assignement. It starts simpel enough:
x = something
binds the name, "x" the the object, 'something' is bound to (or a literal)
Then we get into:
- multiple assignment
- tuple unpacking (oops, sequence unpacking),
- augmented assignment
- oh, that works different depending on whether the object is mutable
We don't need any more.
-CHB
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
-
Brett Cannon -
Chris Barker -
Eric Snow -
Nick Coghlan