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

21–30 of 120 posts

Re: What's New in Python 3.12

#21

Post by pedvide »

BoumTAC wrote: post #20
gnulinux wrote: post #17

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.

In pandas for example that can happen often: `df["count"] == 5` and `df.count == 5` are logically different expressions that will give different answers

Re: What's New in Python 3.12

#22

Post by WorldMaker »

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…

I think what you are looking for as an equivalent to the JS `console.log`/PHP `var_dump` feature set is available in f-string formats.

There's not one perfect format to rule them all but the "=" "self-documenting" debug format such as `f"{some_obj=}"` probably gives you a good starting point for what you are looking for most of the time. Sometimes you still want the `str()` or `repr()` representation specifically and would want something like `f"{some_obj=!s}"` or `f"{some_obj=!r}"` respectively. In some cases objects you want pretty-printed to a console might have custom `__format__()` representations as well and it might be something like `f"{some_obj=:some-custom-format}"`.

It's obviously all still differently useful than JS having a full object browser embedded in most common consoles today, but there is interesting power to explore in f-string formats if you need quick and dirty logs of object states.

https://docs.python.org/3/whatsnew/3.8.html#bpo-36817-whatsn...

Re: What's New in Python 3.12

#23

Post by ketzu »

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…

> 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

Re: What's New in Python 3.12

#24

Post by simonw »

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…

There are a bunch of options for getting user["email"] and user.email to do the same thing:

1. Write a class with custom __getitem__ and __getattr__ methods

2. Use a template system like Django or Jinja that implements this in certain situations

3. Use a library like https://pypi.org/project/python-box/

Re: What's New in Python 3.12

#25

Post by flakes »

https://docs.python.org/3/whatsnew/3.12.html#whatsnew312-pep... "PEP 692: Using TypedDict for more precise *kwargs typing" seems pretty great.

That'll be really helpful for nested method calls which proxy a lot of their arguments along. I can also see that helping out when creating stub libraries.

Re: What's New in Python 3.12

#26

Post by dragonwriter »

gnulinux wrote: post #11

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…

> If a function can realistically raise a "KeyError" the program should be properly written to accept this at some level

By definition, it is, because there is defined behavior for unhandled exceptions.

If you want to—and this is a valid preference—wrap all exceptions thrown at a lower level and present an API where they are part of the return type that must be addressed by code to pass typechecking, then you do that and return actual values of an appropriate type (you can still use exception types, if you wish) instead of raising exceptions.

Exceptions which you force client code to handle to typecheck are not exceptions, they are return values and should be converted to explicitly that, rather than adding checked exceptions.

Re: What's New in Python 3.12

#27

Post by execveat »

BoumTAC wrote: post #20
gnulinux wrote: post #17

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.

No, there is no confusion here at all (for a Python developer). I would consider it a code smell though as the whole problem is completely avoidable by better naming.

By the way, there is a vulnerability (Prototype Pollution) that is only possible due to this behaviour in JS: https://portswigger.net/web-security/prototype-pollution

Re: What's New in Python 3.12

#28

Post by jherskovic »

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…

I will admit to implementing `__getattr__` and `__setattr__` in such a way that they mimic object properties in dictionaries, for specific cases. In general, the threshold for doing so should be IMHO fairly high. In my case, - they are data-heavy classes but not @dataclass classes, and - there's enough attribute access that the `["` and `"]` become visually distracting, and - there are nested structures, so so you can write `x.foo.bar.baz` instead of `x["foo"]["bar"]["baz"]` This is especially useful, in our case, in a system that intakes a lot of JSON with a LOT of nested dictionaries.

Re: What's New in Python 3.12

#29

Post by lozenge »

BoumTAC wrote: post #20
gnulinux wrote: post #17

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.

So how can d.update() coexist with d["update"]? Updating a dictionary vs examining a dictionary that has a key "update"?

Re: What's New in Python 3.12

#30

Post by NoboruWataya »

gnulinux wrote: post #11

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 dynamically typed (and committed to that paradigm) invest so much effort in developing this elaborate but optional typing system.

Post reply on HN