Live data from Hacker News

What's New in Python 3.12

docs.python.org

31–40 of 120 posts

Re: What's New in Python 3.12

#31
post #20

Earlier quoted context omitted.

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.

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

No, having used lots of OO languages before JS and its “objects are dictionaries are arrays and member access and string indexing and integer indexing are all equivalent and can be used interchangeably, except you can't use member access where the key isn't a valid identifier” approach, which I find more confusing and error prone (though I’ve since had to use JS enough to be proficient in that, too.)

Indexing an object as an indexable collection and accessing a member (field, property, or method) of the object are fundamentally different things, and having a collection item with a particular string index isn’t the same thing as an object member with a similar identifier name.

This use of objects as also quasi-associative-arrays is so broken that JS’s actual associative-array type (Map) can’t use indexing notation because of it, and has to use .get() and .set() instead, unlike the associative array types of most other dynamic languages (and several statically-typed OO languages).

The JS way is less bad as a type-specific behavior (e.g., Ruby ActiveSupport’s HashWithIndifferentAccess), though.

Re: What's New in Python 3.12

#33
post #20

Earlier quoted context omitted.

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.

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

No. They're different notations; one means `x.__getitem__('foo')` and the other means `x.__getattribute__('foo')`. Why should they be the same? It isn't confusing that `5-4 == 1` but `5+4 == 9`, after all.

If we assume that the dict class was enhanced with your proposed equivalence, would you want `d['items']` to be the function `d.items`? Would that not make 'items' a forbidden key?

Re: What's New in Python 3.12

#34
I suspect people will use these comments to share their wishlist of Python features, so let me add that I really wish Python had a safe navigation operator, for when you are dealing with nested objects that could be None. I have been trying to parse a lot of XML and JSON in Python lately and a feature like that could really help reduce boilerplate checks.

https://en.wikipedia.org/wiki/Safe_navigation_operator

Re: What's New in Python 3.12

#35
post #23
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…

> PHP also has `var_dump`. But we don't have any equivalent in python. Maybe pprint is for you: from pprint import pprint # usage, but can do more as well and has more config stuff if needed pprint({'a':'b'}) https://docs.python.org/3/library/pprint.html

`vars` as well: https://docs.python.org/3/library/functions.html#vars

Although it'd be nice if it worked with slotted classes instead of just blowing up.

Dataclasses have asdict which work on both, but it's annoying there's nothing for regular classes.

Re: What's New in Python 3.12

#36

I suspect people will use these comments to share their wishlist of Python features, so let me add that I really wish Python had a safe navigation operator, for when you are dealing with nested objects that could be None. I have been trying to parse a lot of XML and JSON in Python lately and a feature like that could really help reduce boilerplate checks. https://en.wikipedia.org/wiki/Safe_navigation_operator

While not as short as a proper operator .get("key", {}) does work.

Re: What's New in Python 3.12

#37
Shameless self-plug but with my project Willow[0] we have a management server implementation to deal with multiple devices, etc. We have a new feature called "Willow One Wake" that takes the incoming audio amplitude when wake word is detected and uses our Willow Application Server (python) to only activate wake on the device closest to the person speaking. Old and tired compared to the commercial stuff but a first in the open source space.

The asyncio improvements in Python 3.12 especially (plus perf generally) have been instrumental in enabling real world use of this. With Python 3.12 asyncio, uvloop, and FastAPI it works remarkably well[1]. As the demo video shows not only does it not delay responsiveness, it has granularity down to inches.

[0] - https://heywillow.io/

[1] - https://youtu.be/qlhSEeWJ4gs

Re: What's New in Python 3.12

#38
post #20

Earlier quoted context omitted.

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.

Try This:

  x = {"users": [12,21,54], "items": [1,2,3]}  # group owned items
  >>> x["items"]
  [1,2,3]
  >>> x.items
  

Re: What's New in Python 3.12

#39

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?

A few releases back they replaced the python parser with a more capable PEG parser. At the time nothing really changed, but it was done to enable this kind of improvement and make it practical to evolve the syntax over time.

This change isn't so much done for the sake of being able to next quotes in f-strings, it's done because there was a dedicated extra parser for the python syntax inside f-strings, but with the new parser this can be parsed without this special case extra parser.

It's all to manage technical debt.

Re: What's New in Python 3.12

#40

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…

Are there any other languages where typing is purely optional and yet so much effort is going into developing the typing system? I started experimenting with Kotlin just when Python was starting to get type hints and after my experience with Kotlin I am totally sold on the benefits of typing. So to me it's great to see these recent developments. It just feels weird to me to have a language that is fundamentally dynam…

Uh. JavaScript?
Post reply on HN