Python 3.12.0rc1 | Hacker News Reader

Python 3.12.0rc1

python.org

41 pointsgjvc21 comments

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.

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]]

Indeed, there was some controversy about the implementation cost: https://discuss.python.org/t/please-consider-delaying-or-eve...

I think implementation cost is a smaller worry, the main problem is the introduction of complexity for a relatively minor gain.

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/...

* https://discuss.python.org/t/pep-695-type-parameter-syntax/2...

I just read the link you posted and people there seem to be worried about the introduced complexity.

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.

     f" something { my_dict['key'] } something else "

This works in Python already, allowing for nesting is a big QoL improvement

> 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.

The pros and cons of this was extensively discussed: 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.

So in short they are doing this just for it to end up in every coding style ban list?

By having a well-defined syntax, it allows:

* Other Python implementations to correctly and confidently implement f-strings

* CPython to use its regular parser to parse f-strings rather than have a special sub-parser

* Lots of edge-cases with f-string syntax to work consistently

As you could have read in the discussion rather than a bad-faith comment of "they are doing this just for <bad thing>", obviously no one wants to put a lot of effort into something for it to not have any benefit at all.

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.

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++...)

What was the bluetooth api that disappeared? Did it not print out depreaction warnings?

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.

> set up a VM with an ancient python version

Maybe just use virtual environment?

  > Tell me you don't know what's a python virtual environment without telling me you don't know what's a python virtual environment

Of course you know that also that Python virtual environments are used to handle/isolate different python packages and their versions on top of the system-wide python installation, and not different versions of python runtime, so I won't even mention it. Of course in theory you can have as many different python version installed as you want on the same system, but whoever suggests that has never tried having more than 1 intentionally. I'm sure you were only joking with that post. Haha. I get it.

I've got no sympathy, since you keep saying 'random script off the internet'.

When you say datamining, what exactly do you mean? I've never had to datamine a codebase. It's not a database.

Using the wrong terms for stuff generally flags someone for me as having no idea what they're doing. Definitely not a reliable narator so to speak. I can equally hear you say 'I haven't used this car in 6 years and it wont drive now'.

It's also pretty redflagish that you're not actually giving any specifics. Like was a module in the standard library removed, or was this a third party thing. I wonder because you said it was related to bluetooth.

That's not to say early python 3 wasn't a mess. It was, but that's certainly resolved now.

(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?

> that's how semver works in practice. > But now you can't even trust python code to work between minor versions.

Python doesn't use semantic versioning: https://docs.python.org/3/faq/general.html#how-does-the-pyth...

Reply on news.ycombinator.com