31–40 of 381 posts
> The typing module incorporates several new features: > A dictionary type with per-key types. Ah, I've been waiting for this. I've been able to use Python's optional types pretty much everywhere except for dictionaries that are used as pseudo-objects, which is a fairly common pattern in Python. This should patch that hole nicely.
IMO A better fix is to use http://attrs.org or dataclasses to replace the dicts entirely.
def f(a, b, /, c, d, *, e, f): Wow: IMHO that is a very ugly syntax to define a fn with 6 parameters, although it looks to be a path dependency on previous decisions (*, and CPython ,/) and clearly there was much discussion of the need for the functionality and the compromises: https://www.python.org/dev/peps/pep-0570/ It amazes me to see how certain features make it into languages via community/committee (octal numb…
I think we're ready for programming languages using some visually good Unicode characters, instead of overloading `[]{}!@#$%^&*()-_/` for everything!
As a developer who has primarily developed applications in Python for his entire professional career, I can't say I'm especially excited about any of the "headlining" features of 3.8. The "walrus operator" will occasionally be useful, but I doubt I will find many effective uses for it. Same with the forced positional/keyword arguments and the "self-documenting" f-string expressions. Even when they have a use, it's us…
I take this as a positive sign of Python's maturity.
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.
Because of the luddites at RedHat, Python2.7 isn't actually dead until 2024. It's infuriating. https://access.redhat.com/solutions/4455511
def f(a, b, /, c, d, *, e, f): Wow: IMHO that is a very ugly syntax to define a fn with 6 parameters, although it looks to be a path dependency on previous decisions (*, and CPython ,/) and clearly there was much discussion of the need for the functionality and the compromises: https://www.python.org/dev/peps/pep-0570/ It amazes me to see how certain features make it into languages via community/committee (octal numb…
It will be a "good problem" to have the skillz to make this useful.
Earlier quoted context omitted.
It's almost as if the Python Software Foundation isn't capable of killing the Python 2 language unilaterally without the Python community's consent.
It's almost as if people were given 12 fucking years (or admittedly fewer, depending on when your favorite library was migrated) to move over, didn't, and are now obstinately standing in the way of forward progress.
As a developer who has primarily developed applications in Python for his entire professional career, I can't say I'm especially excited about any of the "headlining" features of 3.8. The "walrus operator" will occasionally be useful, but I doubt I will find many effective uses for it. Same with the forced positional/keyword arguments and the "self-documenting" f-string expressions. Even when they have a use, it's us…
I take this as a positive sign of Python's maturity.
def f(a, b, /, c, d, *, e, f): Wow: IMHO that is a very ugly syntax to define a fn with 6 parameters, although it looks to be a path dependency on previous decisions (*, and CPython ,/) and clearly there was much discussion of the need for the functionality and the compromises: https://www.python.org/dev/peps/pep-0570/ It amazes me to see how certain features make it into languages via community/committee (octal numb…
As a developer who has primarily developed applications in Python for his entire professional career, I can't say I'm especially excited about any of the "headlining" features of 3.8. The "walrus operator" will occasionally be useful, but I doubt I will find many effective uses for it. Same with the forced positional/keyword arguments and the "self-documenting" f-string expressions. Even when they have a use, it's us…
https://github.com/eveem-org/panoramix
(source code for Eveem.org, which is arguably the best decompiler for Ethereum smart contracts out there. you can see a lot of pattern matching in pano/simplify.py , and I found no way to do it without extending the language/walrus while maintaining the readability)
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.
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?