4 ms·

Python 3.12.0rc1

41 points by gjvc 3y ago

sgarland 3y ago
Inlining comprehensions is a very nice change. I also thought I remembered seeing a change to the json library to speed up some operations, but maybe that was deferred to 3.13.
diarrhea 3y ago
A new statement, wow! I wonder if the price is worth the benefit. The new syntax for generic functions and classes is great. Brings it in line with other languages.
- gnulinux 3y ago
  Just to be clear, because it's buried everywhere and it's only in the original PEP page, these are examples of the new statement: # A non-generic type alias type IntOrStr = int | str # A generic type alias type ListOrSet[T] = list[T] | set[T] # A type alias that includes a forward reference type AnimalOrVegetable = Animal | "Vegetable" # A generic self-referential type alias type RecursiveList[T] = T | list[RecursiveList[T]]
- notatallshaw 3y ago
  Indeed, there was some controversy about the implementation cost: https://discuss.python.org/t/please-consider-delaying-or-even-rejecting-pep-695/26408 https://discuss.python.org/t/please-consider-delaying-or-eve...
  - The_Colonel 3y ago
    I think implementation cost is a smaller worry, the main problem is the introduction of complexity for a relatively minor gain.
    - notatallshaw 3y ago
      That's a very under specified criticism, what type of complexity do you think it has introduced and how do you quantify "minor gain"? Some people clearly think it is an appropriate complexity to solve for the gain it gives, hence the detailed proposal and long discussions that have already taken place: * https://mail.python.org/archives/list/typing-sig@python.org/thread/BB2BGYJY2YG5IWESKGTAPUQL3N27ZKVW/ https://mail.python.org/archives/list/typing-sig@python.org/... * https://discuss.python.org/t/pep-695-type-parameter-syntax/21646 https://discuss.python.org/t/pep-695-type-parameter-syntax/2...
      - The_Colonel 3y ago
        I just read the link you posted and people there seem to be worried about the introduced complexity.
WhyNotHugo 3y ago
More flexible f-string parsing sounds like a mistake. The basic use case is fine: f"Hello, {name}, how are you?" But putting entire expressions in there sounds like going too far. So now you can do this: f" something { my_dict["key"] } something else " But why not the simpler approach (this is simper to read for both humans and machines): value = my_dict["key"] f" something {value} something else " Heck, even this monstrosity is allowed: f"{f"{f"{f"{f"{f"{1+1}"}"}"}"}"}" From TFA (emphasis mine): > Expression components inside f-strings can now be any valid Python expression including backslashes, unicode escaped sequences, *multi-line expressions*, comments and strings reusing the same quote as the containing f-string. Edit: I do appreciate that at least the parser will give out detailed error messages when something is wrong in a f-string.
- clappski 3y ago
  f" something { my_dict['key'] } something else " This works in Python already, allowing for nesting is a big QoL improvement
- viraptor 3y ago
  > But why not the simpler approach... Now try that example again, but make the string include 4 different keys from that dict. That's why it's useful. This kind of interpolation has been available in many other languages for years. Sure, you can abuse it if you want to, but I've rarely seen it happen in real code.
- notatallshaw 3y ago
  The pros and cons of this was extensively discussed: https://discuss.python.org/t/pep-701-syntactic-formalization-of-f-strings/22046 https://discuss.python.org/t/pep-701-syntactic-formalization... In summary the winning argument was it's always possible to for users to write unreadable code if they want and generally Python does not implement language level arbitrary restrictions to stop this. So, the benefits of a well-defined f-string syntax that is logically consistent outweigh the possibility some users will choose not to follow best practise.
  - 3y ago
not_your_vase 3y ago
Unpopular opinion: python is getting worse and worse with every release. Back then you couldn't run scripts that were written with python2 - sure, they made a major version bump, that's how semver works in practice. But now you can't even trust python code to work between minor versions. There was a python3 script that read out bluetooth details (like battery level) that I used a few years ago. Some months ago I found it again, but it stopped working due to some dropped api. I see that this version removes some apis also (the "deprecation" section should be actually "breaking incompatibilities with previous versions") - whatever you wrote with python 3.11 (or earlier) using these apis, all of those programs are broken now. Whatever you write in python runs today - but no one promises that it will run tomorrow also. (And I won't even get ranting about the overall direction, that makes it resemble more to C++...)
- gjvc 3y ago
  (And I won't even get ranting about the overall direction, that makes it resemble more to C++...) Could you give some examples of this?
- ehutch79 3y ago
  What was the bluetooth api that disappeared? Did it not print out depreaction warnings?
  - not_your_vase 3y ago
    I'm sure it was printing out some warnings in that 6 years when I was not using it. It wasn't my script. It's somewhere on the internet in a random github repo, created by a random internet guy many years ago. All I remember that I wanted to use it again a few months ago, and it took like an hour of datamining by the time I figured out why it doesn't work anymore. Something got removed between Python 3.2 and 3.9, that was essential for this script. Of course this is not the only example. It bites me at least once a month: I try to use some random python project from the internet only to find out that I'm using too new python. If I really badly need it, then it is time to set up a VM with an ancient python version. But usually I just give up, and look for a non-python solution. If it has never ever happened to anyone, then I guess I might be the only person using python in this world regularly. But this is pretty much my point. Python3 scripts die if you try to use them with Python3 - today's python3 doesn't give a damn about yesterday's python3. Python3 scripts rot faster than milk on the sun.

41 points by gjvc 3y ago

Inlining comprehensions is a very nice change. I also thought I remembered seeing a change to the json library to speed up some operations, but maybe that was deferred to 3.13.

diarrhea 3y ago

A new statement, wow! I wonder if the price is worth the benefit. The new syntax for generic functions and classes is great. Brings it in line with other languages.

gnulinux 3y ago
Just to be clear, because it's buried everywhere and it's only in the original PEP page, these are examples of the new statement: # A non-generic type alias type IntOrStr = int | str # A generic type alias type ListOrSet[T] = list[T] | set[T] # A type alias that includes a forward reference type AnimalOrVegetable = Animal | "Vegetable" # A generic self-referential type alias type RecursiveList[T] = T | list[RecursiveList[T]]
notatallshaw 3y ago
Indeed, there was some controversy about the implementation cost: https://discuss.python.org/t/please-consider-delaying-or-even-rejecting-pep-695/26408 https://discuss.python.org/t/please-consider-delaying-or-eve...
- The_Colonel 3y ago
  I think implementation cost is a smaller worry, the main problem is the introduction of complexity for a relatively minor gain.
  - notatallshaw 3y ago
    That's a very under specified criticism, what type of complexity do you think it has introduced and how do you quantify "minor gain"? Some people clearly think it is an appropriate complexity to solve for the gain it gives, hence the detailed proposal and long discussions that have already taken place: * https://mail.python.org/archives/list/typing-sig@python.org/thread/BB2BGYJY2YG5IWESKGTAPUQL3N27ZKVW/ https://mail.python.org/archives/list/typing-sig@python.org/... * https://discuss.python.org/t/pep-695-type-parameter-syntax/21646 https://discuss.python.org/t/pep-695-type-parameter-syntax/2...
    - The_Colonel 3y ago
      I just read the link you posted and people there seem to be worried about the introduced complexity.

WhyNotHugo 3y ago

More flexible f-string parsing sounds like a mistake. The basic use case is fine: f"Hello, {name}, how are you?" But putting entire expressions in there sounds like going too far. So now you can do this: f" something { my_dict["key"] } something else " But why not the simpler approach (this is simper to read for both humans and machines): value = my_dict["key"] f" something {value} something else " Heck, even this monstrosity is allowed: f"{f"{f"{f"{f"{f"{1+1}"}"}"}"}"}" From TFA (emphasis mine): > Expression components inside f-strings can now be any valid Python expression including backslashes, unicode escaped sequences, *multi-line expressions*, comments and strings reusing the same quote as the containing f-string. Edit: I do appreciate that at least the parser will give out detailed error messages when something is wrong in a f-string.

clappski 3y ago
f" something { my_dict['key'] } something else " This works in Python already, allowing for nesting is a big QoL improvement
viraptor 3y ago
> But why not the simpler approach... Now try that example again, but make the string include 4 different keys from that dict. That's why it's useful. This kind of interpolation has been available in many other languages for years. Sure, you can abuse it if you want to, but I've rarely seen it happen in real code.
notatallshaw 3y ago
The pros and cons of this was extensively discussed: https://discuss.python.org/t/pep-701-syntactic-formalization-of-f-strings/22046 https://discuss.python.org/t/pep-701-syntactic-formalization... In summary the winning argument was it's always possible to for users to write unreadable code if they want and generally Python does not implement language level arbitrary restrictions to stop this. So, the benefits of a well-defined f-string syntax that is logically consistent outweigh the possibility some users will choose not to follow best practise.
- 3y ago

not_your_vase 3y ago

Unpopular opinion: python is getting worse and worse with every release. Back then you couldn't run scripts that were written with python2 - sure, they made a major version bump, that's how semver works in practice. But now you can't even trust python code to work between minor versions. There was a python3 script that read out bluetooth details (like battery level) that I used a few years ago. Some months ago I found it again, but it stopped working due to some dropped api. I see that this version removes some apis also (the "deprecation" section should be actually "breaking incompatibilities with previous versions") - whatever you wrote with python 3.11 (or earlier) using these apis, all of those programs are broken now. Whatever you write in python runs today - but no one promises that it will run tomorrow also. (And I won't even get ranting about the overall direction, that makes it resemble more to C++...)

gjvc 3y ago
(And I won't even get ranting about the overall direction, that makes it resemble more to C++...) Could you give some examples of this?
ehutch79 3y ago
What was the bluetooth api that disappeared? Did it not print out depreaction warnings?
- not_your_vase 3y ago
  I'm sure it was printing out some warnings in that 6 years when I was not using it. It wasn't my script. It's somewhere on the internet in a random github repo, created by a random internet guy many years ago. All I remember that I wanted to use it again a few months ago, and it took like an hour of datamining by the time I figured out why it doesn't work anymore. Something got removed between Python 3.2 and 3.9, that was essential for this script. Of course this is not the only example. It bites me at least once a month: I try to use some random python project from the internet only to find out that I'm using too new python. If I really badly need it, then it is time to set up a VM with an ancient python version. But usually I just give up, and look for a non-python solution. If it has never ever happened to anyone, then I guess I might be the only person using python in this world regularly. But this is pretty much my point. Python3 scripts die if you try to use them with Python3 - today's python3 doesn't give a damn about yesterday's python3. Python3 scripts rot faster than milk on the sun.