Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's New in Python 3.12

docs.python.org

Post reply on HN
Print view View original

11–20 of 120 posts

Re: What's New in Python 3.12

#11

Post by gnulinux »

PEP 695 is great. I've been using mypy every day at work in last couple years or so with very strict parameters (no any type etc) and I have experience writing real life programs with Rust, Agda, and some Haskell before, so I'm familiar with strict type systems. I'm sure many will disagree with me but these are my very honest opinions as a professional who uses Python types every day:

* Some types are better than no types. I love Python types, and I consider them required. Even if they're not type-checked they're better than no types. If they're type-checked it's even better. If things are typed properly (no any etc) and type-checked that's even better. And so on...

* Having said this, Python's type system as checked by mypy feels like a toy type system. It's very easy to fool it, and you need to be careful so that type-checking actually fails badly formed programs.

* The biggest issue I face are exceptions. Community discussed this many times [1] [2] and the overall consensus is to not check exceptions. I personally disagree as if you have a Python program that's meticulously typed and type-checked exceptions still cause bad states and since Python code uses exceptions liberally, it's pretty easy to accidentally go to a bad state. E.g. in the linked github issue JukkaL (developer) claims checking things like "KeyError" will create too many false positives, I strongly disagree. If a function can realistically raise a "KeyError" the program should be properly written to accept this at some level otherwise something that returns type T but 0.01% of the time raises "KeyError" should actually be typed "Raises[T, KeyError]".

* PEP 695 will help because typing things particularly is very helpful. Often you want to pass bunch of Ts around but since this is impractical some devs resort to passing "dict[str, Any]"s around and thus things type-check but you still get "KeyError" left and right. It's better to have "SomeStructure[T]" types with "T" as your custom data type (whether dataclass, or pydantic, or traditional class) so that type system has more opportunities to reject bad programs.

* Overall, I'm personally very optimistic about the future of types in Python!

[1] https://github.com/python/mypy/issues/1773 [2] https://discuss.python.org/t/extend-type-hints-to-cover-exce...

Re: What's New in Python 3.12

#12

Post by __s »

BoumTAC wrote: post #4

What I would love to see in a future version of python is being able to do `user["email"]` or `user.email` independently of the reason. Sometimes both work, sometimes only one of the two and an error in throw for the other one. I don't care why, I just want it to work, it's such a basic feature. Something even crazier would be to have an equivalent of `console.log` in python. It would be an amazing feature but I thin…

https://docs.python.org/3/library/functions.html#dir

Re: What's New in Python 3.12

#13

Post by gnulinux »

reallymental wrote: post #2

I've been using python for the past 10+ years, and I've got to say that the new Syntactic formalization of f-strings (PEP 701) has got to be one of the most "huh?" changes I've seen in a while. Was this such a big problem? In my experience, the GIL, faster start-up times are so much higher on the totem pole, why this now?

Makes the grammar simpler which makes new implementations to implement tokenizer much faster/cheaper. It's a simple problem with simple solution that has been causing a medium sized issue, so why not fix it?

Re: What's New in Python 3.12

#14

Post by klyrs »

reallymental wrote: post #2

I've been using python for the past 10+ years, and I've got to say that the new Syntactic formalization of f-strings (PEP 701) has got to be one of the most "huh?" changes I've seen in a while. Was this such a big problem? In my experience, the GIL, faster start-up times are so much higher on the totem pole, why this now?

Not everybody needs to work on the biggest problem, that's the "waterfall" approach to project management. If CPython was a single-developer project, that might be a valid criticism, but it's not.

For me that formalization is nice because they've brought f-strings into the PEG parser which can point at the precise location of a syntax error. I'm wary of the implications of arbitrarily nested f-strings for legibility... but oh well.

Re: What's New in Python 3.12

#15

Post by mmebane »

reallymental wrote: post #2

I've been using python for the past 10+ years, and I've got to say that the new Syntactic formalization of f-strings (PEP 701) has got to be one of the most "huh?" changes I've seen in a while. Was this such a big problem? In my experience, the GIL, faster start-up times are so much higher on the totem pole, why this now?

It's a nice quality of life improvement. Most other languages I've used with some form of string interpolation allow quotes in nested expressions to be the same as the quotes on the top-level string, and this has IMO been a weird wart in Python. I'm happy to see it fixed.

Re: What's New in Python 3.12

#16

Post by jwkane »

BoumTAC wrote: post #4

What I would love to see in a future version of python is being able to do `user["email"]` or `user.email` independently of the reason. Sometimes both work, sometimes only one of the two and an error in throw for the other one. I don't care why, I just want it to work, it's such a basic feature. Something even crazier would be to have an equivalent of `console.log` in python. It would be an amazing feature but I thin…

If you want to write javascript, use javascript. There are ways to get what you're asking for depending on your use case. types.SimpleNamespace in the standard library provides one approach.

"There should be one-- and preferably only one --obvious way to do it." (zen of python)

I do agree that python logging is a weak point. It is too easy to do it wrong -- particularly when you are a few modules deep.

Re: What's New in Python 3.12

#17

Post by gnulinux »

BoumTAC wrote: post #4

What I would love to see in a future version of python is being able to do `user["email"]` or `user.email` independently of the reason. Sometimes both work, sometimes only one of the two and an error in throw for the other one. I don't care why, I just want it to work, it's such a basic feature. Something even crazier would be to have an equivalent of `console.log` in python. It would be an amazing feature but I thin…

In terms of programming language construction making `x.y` and `x["y"]` equivalent looks appealing and, admittedly, cute but there are some problems:

* For new languages: It's not generic enough since there is no equivalent of `x[t]` if t is of a non-string type. E.g. there is no way to express `x[(1,2,3)]` or `x[3]` or `x[frozenset({1, 2, "foo"})]` this way.

* For existing languages like Python: this would be a breaking change since things that can do `x.y` and `x[t]` are structurally different in Python so they're typed differently. One are called "mappings" and the other are "objects", they're completely different things. Hence, you'll get cases where `x["foo"] == 5` but `x.foo == 4` so this will for sure break some programs. Too much pain for no gain.

Re: What's New in Python 3.12

#18

Post by BoumTAC »

jwkane wrote: post #16
BoumTAC wrote: post #4

What I would love to see in a future version of python is being able to do `user["email"]` or `user.email` independently of the reason. Sometimes both work, sometimes only one of the two and an error in throw for the other one. I don't care why, I just want it to work, it's such a basic feature. Something even crazier would be to have an equivalent of `console.log` in python. It would be an amazing feature but I thin…

If you want to write javascript, use javascript. There are ways to get what you're asking for depending on your use case. types.SimpleNamespace in the standard library provides one approach. "There should be one-- and preferably only one --obvious way to do it." (zen of python) I do agree that python logging is a weak point. It is too easy to do it wrong -- particularly when you are a few modules deep.

I really like Python and I love using it. But I think some improvements could be done on such "basic feature".

> "There should be one-- and preferably only one --obvious way to do it." (zen of python)

Look at all the other possibilities to do `f"hello {name}`. That are more than one obvious way to do it.

Re: What's New in Python 3.12

#19

Post by thrdbndndn »

makr17 wrote: post #10
reallymental wrote: post #2

I've been using python for the past 10+ years, and I've got to say that the new Syntactic formalization of f-strings (PEP 701) has got to be one of the most "huh?" changes I've seen in a while. Was this such a big problem? In my experience, the GIL, faster start-up times are so much higher on the totem pole, why this now?

"Due to the changes in PEP 701, producing tokens via the tokenize module is up to 64% faster."

Performance improvement is obviously nice but I personally don't even care about it.

Being able to just use any quotes in f-strings is just godsend QOL change and probably would be the biggest reason I upgrade to 3.12 (for my pet project).

Re: What's New in Python 3.12

#20

Post by BoumTAC »

gnulinux wrote: post #17
BoumTAC wrote: post #4

What I would love to see in a future version of python is being able to do `user["email"]` or `user.email` independently of the reason. Sometimes both work, sometimes only one of the two and an error in throw for the other one. I don't care why, I just want it to work, it's such a basic feature. Something even crazier would be to have an equivalent of `console.log` in python. It would be an amazing feature but I thin…

In terms of programming language construction making `x.y` and `x["y"]` equivalent looks appealing and, admittedly, cute but there are some problems: * For new languages: It's not generic enough since there is no equivalent of `x[t]` if t is of a non-string type. E.g. there is no way to express `x[(1,2,3)]` or `x[3]` or `x[frozenset({1, 2, "foo"})]` this way. * For existing languages like Python: this would be a brea…

Don't you think `x["foo"] == 5` but `x.foo == 4` is a hell of a lot confusing ?

Don't you think it should not be possible to have such a thing ? To me it's so prone to error and there is absolutely too much gain to fix this.

Post reply on HN