I used to be a fan of Python but almost all the stuff here seems weirdly tacked on. Added with good intentions for sure but a lot of it seems short-sighted, implemented in the least-effort way.
f strings are like u strings in Python 2: a compatibility hack to make old code not go bust. Maybe these should’ve been just regular strings in Python 3, but over the entire lifespan format strings were not necessary but we need them mid-way in Python 3? Odd.
Pathlib uses the division operator in a weird way. I guess maybe this is similar to how + concatenates strings but seems to be overly cute for cuteness sake. Granted, this is a minor point.
Type hinting. I guess it is nice. Doesn’t seem fully formed, since that was introduced in 3.0 but had no guidelines on how to use it. I’m not necessarily a fan of adding features without a clear idea how to use it but okay, we seem to be getting to some point now.
Enumerations look like a weird hack, not a language feature. Without matching/dispatching on Enums these don’t feel all that useful. This is like ADTs but without the good parts.
Data classes or as we in ML call it, records. Useful feature, again as a decorator hack. But I can certainly see it being helpful. Again, no destructuring on them, which would make them much more useful.
Implicit Package Namespaces. Could you make Python packages more obscure with more special rules? Turns out you can.
Why do you feel that Py3’s f strings are like Py2’s u strings? The f stands for “format”, meaning you can avoid the .format() method. The u stands for “unicode”, and is something else entirely. I don’t see how the two compare, would you care to elaborate?
The division operator used in pathlib merely mimics the directory separator in unices. If we have p = pathlib.Path('/path'), then p / 'to' / 'file' is the same as /path/to/file. Pretty easy and convenient, if you ask me.
Why do you feel that Py3’s f strings are like Py2’s u strings?
Because both are what strings should’ve been by default. But one couldn’t change Python 2 in a compatible way so Python 3 strings are what were u strings in Python 2. Similarly with f strings, in languages that do format strings this way (Ruby, Shell, PHP come to mind) this is a default behaviour, with a way to opt-out. But that can’t be added in Python 3 because all existing code that might contain formatting characters would start doing unexpected things, so f strings had to be created. A hypothetical Python 4 would probably use f strings as default.
My complaint here is if there is a new formatting syntax introduced, why was it added now and not in a clean syntactic way when Python 3.0 was introduced?
The division operator used in pathlib merely mimics the directory separator in unices.
I understand that it is for that purpose, but it is a “cutesy” misuse of division. The reverse operation of division would be multiplication, but what would multiplication on a path even mean? But as said, this is a minor complaint since Python already has + on strings, with no symmetrical - operation.
Fun fact, Elixir has + on lists and also - on lists. What does it do? I’m leaving this as an exercise to the reader.
I kind-of agree. It seems like a lot of recent changes make Python more complicated for not much gain. The language is starting to feel bloated instead of elegant and focused, to me at least. Thankfully they’re almost all opt-in features, so I can continue using Python as I like it, and only pick the new “features” which I genuinely get some benefit from.
Data classes implementation is so much nastier than namedtuple, and given the fact that it’s yet-another-decorator-hack, I don’t understand why it has a pep and is in the standard lib.
Type hinting, asyncio (or twisted), fstrings (an abomination)…no wonder Guido bounced. The whole place is going crazy! What happened to the Zen of python? All of the aforementioned seem direct contradictions.
Implicit Package Namespaces. Could you make Python packages more obscure with more special rules? Turns out you can.
The article is wrong, you should not use this feature as it suggests. It does solve a real problem — packages like zope that are broken into multiple distributions on PyPI — see PEP 420. In this advanced use case it replaces a disgusting setuptools hack so I’d count it as progress.
I really wish that instead of data classes, which force me to invent types for my data, we’d get a nice built-in syntax for named tuples that wouldn’t require importing a module and repeating the record name twice.
I really wish that instead of data classes, which force me to invent types for my data, we’d get a nice built-in syntax for named tuples that wouldn’t require importing a module and repeating the record name twice.
Well, you still have to specify the types of your data and do an import, but there is a nice alternative syntax for named tuples if you want to avoid repeating the record name:
class Component(NamedTuple):
part_number: int
weight: float
description: Optional[str] = None
The syntax used for annotating function/method arguments and return values was introduced in 3.0, not 3.5. And the syntax for annotating variables was introduced in 3.6.
The thing that was introduced in Python 3.5 was the typing module in the standard library (and it was also made available as a standalone installable package for previous versions), which provides some helpers for annotating things like generics. That’s also when the annotation feature officially was declared to be “don’t use this for purposes other than type hints”, but previously that’s like 99% of what people used it for anyway.
(also it’s still not nearly as useful as it could or should be, due to design choices made earlier, and I’m not completely convinced that it can be rescued at this point)
I used to be a fan of Python but almost all the stuff here seems weirdly tacked on. Added with good intentions for sure but a lot of it seems short-sighted, implemented in the least-effort way.
fstrings are likeustrings in Python 2: a compatibility hack to make old code not go bust. Maybe these should’ve been just regular strings in Python 3, but over the entire lifespan format strings were not necessary but we need them mid-way in Python 3? Odd.Pathlibuses the division operator in a weird way. I guess maybe this is similar to how+concatenates strings but seems to be overly cute for cuteness sake. Granted, this is a minor point.records. Useful feature, again as a decorator hack. But I can certainly see it being helpful. Again, no destructuring on them, which would make them much more useful.Why do you feel that Py3’s f strings are like Py2’s u strings? The f stands for “format”, meaning you can avoid the .format() method. The u stands for “unicode”, and is something else entirely. I don’t see how the two compare, would you care to elaborate?
The division operator used in pathlib merely mimics the directory separator in unices. If we have
p = pathlib.Path('/path'), thenp / 'to' / 'file'is the same as/path/to/file. Pretty easy and convenient, if you ask me.Because both are what strings should’ve been by default. But one couldn’t change Python 2 in a compatible way so Python 3 strings are what were
ustrings in Python 2. Similarly withfstrings, in languages that do format strings this way (Ruby, Shell, PHP come to mind) this is a default behaviour, with a way to opt-out. But that can’t be added in Python 3 because all existing code that might contain formatting characters would start doing unexpected things, sofstrings had to be created. A hypothetical Python 4 would probably usefstrings as default.My complaint here is if there is a new formatting syntax introduced, why was it added now and not in a clean syntactic way when Python 3.0 was introduced?
I understand that it is for that purpose, but it is a “cutesy” misuse of division. The reverse operation of division would be multiplication, but what would multiplication on a path even mean? But as said, this is a minor complaint since Python already has
+on strings, with no symmetrical-operation.Fun fact, Elixir has
+on lists and also-on lists. What does it do? I’m leaving this as an exercise to the reader.Thanks, I understand what you’re getting at.
Operator overloads, yeah, brilliant. Let’s bless this kind of crap so we can be surprised by more un-obvious, difficult-to-introspect garbage.
I kind-of agree. It seems like a lot of recent changes make Python more complicated for not much gain. The language is starting to feel bloated instead of elegant and focused, to me at least. Thankfully they’re almost all opt-in features, so I can continue using Python as I like it, and only pick the new “features” which I genuinely get some benefit from.
Data classes implementation is so much nastier than namedtuple, and given the fact that it’s yet-another-decorator-hack, I don’t understand why it has a pep and is in the standard lib.
Type hinting, asyncio (or twisted), fstrings (an abomination)…no wonder Guido bounced. The whole place is going crazy! What happened to the Zen of python? All of the aforementioned seem direct contradictions.
Fuck. I’ll be writing c and Lua if you need me.
The article is wrong, you should not use this feature as it suggests. It does solve a real problem — packages like
zopethat are broken into multiple distributions on PyPI — see PEP 420. In this advanced use case it replaces a disgusting setuptools hack so I’d count it as progress.I was going by saying “Used that. Used that. …” but then I learned about
Both of which are very useful.
Recently I had to go and write some Python 2 code. I did it, but I am so happy that most of the stuff I do, I can use Python 3.7+
I really wish that instead of data classes, which force me to invent types for my data, we’d get a nice built-in syntax for named tuples that wouldn’t require importing a module and repeating the record name twice.
Well, you still have to specify the types of your data and do an import, but there is a nice alternative syntax for named tuples if you want to avoid repeating the record name:
Thanks, I didn’t know about the capitalized
NamedTuple.I agree, the types seem like an unnecessary complication.
The syntax used for annotating function/method arguments and return values was introduced in 3.0, not 3.5. And the syntax for annotating variables was introduced in 3.6.
The thing that was introduced in Python 3.5 was the
typingmodule in the standard library (and it was also made available as a standalone installable package for previous versions), which provides some helpers for annotating things like generics. That’s also when the annotation feature officially was declared to be “don’t use this for purposes other than type hints”, but previously that’s like 99% of what people used it for anyway.(also it’s still not nearly as useful as it could or should be, due to design choices made earlier, and I’m not completely convinced that it can be rescued at this point)
I actually had tried using f-strings and got really annoyed they don’t nest like template literals and tagged templates in javascript. Such a waste.