7 ms·
This is the release that contains the controversial assignment expressions, which sparked the debate that convinced GvR to quit as BDFL. They didn't select my
by metalliqaz 7y ago
This is the release that contains the controversial assignment expressions, which sparked the debate that convinced GvR to quit as BDFL.
They didn't select my preferred syntax, but I'm still looking forward to using assignment expressions for testing my re.match() objects.
I haven't used 3.8.0 yet but I hope its a good one because 2020 is the year that 2.7 dies and there will be a lot of people switching.
- kbd 7y agoI'm stoked about the walrus operator. Ever since I heard it was being added I've grumbled when writing code that would have been clearer with it. Of course I have to ask, what was your preferred syntax?
- mkl 7y agoNot OP, but maybe it's "as": if re.match(pattern, string) as m: #use m Seems a bit more Pythonic, as "as" is already used like this with "with". Either one would be fine with me and useful.
- metalliqaz 7y agoyep, that's the one!
- TremendousJudge 7y agoIt's already used in imports as well! It was the better choice, I don't know which arguments convinced them otherwise
- kbd 7y agoI think I remember seeing something about the "as" syntax. Wish I could find what I read, IIRC some arguments convinced me that the walrus operator was an improvement.
- metalliqaz 7y agoit is discussed in the PEP https://www.python.org/dev/peps/pep-0572/#alternative-spellings https://www.python.org/dev/peps/pep-0572/#alternative-spelli...
- mixmastamyk 7y agoUnfortunately, none of the reasons listed against are very accurate.
- mixmastamyk 7y agoThe arguments were based around also supporting complex multiple assignments and being to be able to do them anywhere, not just if… and while…, list-comps, etc. Of course neither of those things have been seen in the wild or production code since. Some folks complain even the simple case above is less readable. "as" was the Pythonic choice, rather than the C/Pascalic one.
- diminoten 7y agoBecause of the luddites at RedHat, Python2.7 isn't actually dead until 2024. It's infuriating. https://access.redhat.com/solutions/4455511 https://access.redhat.com/solutions/4455511
- mistrial9 7y agothe emotional content outweighs the objective situation here; also humorous since Luddites are commonly misunderstood per https://en.wikipedia.org/wiki/Luddite https://en.wikipedia.org/wiki/Luddite
- diminoten 7y agoNot misunderstood; luddites (lowercase l, or at least the generalized form) means something different than Luddites (capitalized L).
- jimktrains2 7y agoI'm fairly certain the lowercase l version is the same, but the Luddites are remembered as being ant technology, not pro labour.
- diminoten 7y agoA luddite, generally, is one who is anti-technology. A Luddite, specifically, is a member of a 19th century movement to prevent automation from taking their job. It's insanely pedantic to try and point out the difference, given the ease with which one can find the generic definition.
- lidHanteyk 7y agoIt's almost as if the Python Software Foundation isn't capable of killing the Python 2 language unilaterally without the Python community's consent.
- diminoten 7y ago
- Rebelgecko 7y ago>They didn't select my preferred syntax I don't write much python so there's probably something obvious I'm missing, but I don't see why they didn't use "=". Is there some significant difference between assignment expressions and assignment statements that makes it worth having distinct syntax?
- jimktrains2 7y agoYes, there is. If x = 1 Has been the source of many errors in many languages. Forcing assignment to be more than a 1 character difference from the equality operator prevents this.
- jorams 7y agoI may be missing something, but := is still only a 1 character difference, isn't it?
- chungy 7y ago:= is basically the "yes, I really mean it" version, whereas bare = might just be a simple typo.
- chrisshroba 7y agoIt is, but many intro programmers (and non-intro programmers!) often forget to use == instead of = for comparison, because in the real world, = more often implies equality, rather than assignment. So a novice might mistakenly type `if x=1:` but they would be unlikely to accidentally type `if x:=1:`.
- madhadron 7y agoMakes you wonder why we switched from = is equality and := is assignment like it was in the ALGOL family.
- jimktrains2 7y agoI should have said single-character additions or deletions . == And = have a levenstein distance of 1, == and := is 2. You can't simply make a typo and change an equality check to assignment. So, wiki defines levenstein distance as including substitution, but I was taught or at least remember it only being additions and deletions?
- DonaldPShimoda 7y ago> I'm still looking forward to using assignment expressions for testing my re.match() objects. The fact that this is the go-to example that everybody is using in justifying the introduction of the assignment expression convinces me that the real problem lies with the re module's API. (To be clear: I will also be using assignment expressions for this case, but I don't think assignment expressions are really in line with the overall design of Python.)
- fjp 7y agore's API sucks but I'm looking forward to safe dictionary access with assignment as well. No more if my_map.get(key) is not None: // do something with my_map[key]
- DonaldPShimoda 7y agoHere the "better" solution (imo) would be support for pattern matching: match my_map.get(key): case None: // do thing (or nothing, i.e., pass) case Some(val): // do other thing Scala seems to have figured out how to get pattern matching over arbitrary data (i.e., not statically-defined algebraic datatypes). I'd like to see this come to Python. (Normally I'd fight for pattern matching to always provide static type safety guarantees, but in Python it seems completely reasonable to omit such checks.) EDIT: But you're absolutely right that this is a place where assignment expressions will be used regularly, so thank you for pointing that out!