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

71–80 of 120 posts

Re: What's New in Python 3.12

#71

Post by ziml77 »

NoboruWataya wrote: post #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

That's something I've wished for a long time that it had. I know you can use exceptions to get similar behavior but it's really ugly and I just generally don't like raising exceptions for cases that aren't actually exceptional (even though I know Python uses exceptions for normal flow with StopIteration).

What's actually a bit odd about Python missing that operator is that its `or` operator acts as a rough equivalent of C#'s null-coalescing (`??`) operator. To me the safe navigation operator goes hand-in-hand with that.

Re: What's New in Python 3.12

#73

Post by penguin_booze »

xxpor wrote: post #70
vitorsr wrote: post #67

I find the feature-happy kitchen sink product philosophy in programming languages quite insufferable. It has become an unpleasant chore to keep up with PEP squabbles and accepted changes.

Why do you have to keep up with them?

On the principle that it works best when you know your tools. The lament is about the features piling up at such fast pace--and of questionable utility, too--that it's exhausting to keep up/master over. You go for a vaccation, and the language you once knew, mastered, and loved, has left you behind.

On the utility of features, the arbitraty nesting of f-strings stands out. Why in tarnation would anyone need such nesting? Isn't it simpler and readable to keep non-trivial expressions out of the f-string itself?

Re: What's New in Python 3.12

#74

Post by pjmlp »

9967d2cad_askhn wrote: post #72

So many breaking changes promulgated with covert version numbers—an unfortunate truth for Python and why the writing on the wall is clear—Python is not dependable—Go is the safer choice for business applications and services.

Java and C# are much safer options, with almost 30 years of deployment production, and an ecosystem of programming languages across the JVM/ART and CLR, that aren't afraid to let programmers express themselves.

Re: What's New in Python 3.12

#75

Post by 9967d2cad_askhn »

martinky24 wrote: post #9
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 an open source project. If a developer wants to go out of their way to make a really cool improvement, goes through the approval process, has a clean implementation that doesn't add any backwards incompatibilities, why do you care? This isn't some private company where management tells people what to do and they have to do it. People are so out of touch with how OSS, and the volunteer maintainers that operate it…

No. You’re missing one constituent part of a for-profit corporate-backed language platform. You cannot just step in the ring with Ali because you think you can box.

Politics, other forces, compellation will emerge as a stronghold barrier to your meritocratical hopes and dreams.

Re: What's New in Python 3.12

#76

Post by klibertp »

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.

You can't confuse keys in a hash table with properties of objects. It's not confusing, it's a useful distinction.

Most languages that have both objects and associative arrays (so not Lua or JavaScript) make this distinction.

It's not particularly error prone. You're simply refusing ("don't care why") to learn how to use the tool you're given.

Re: What's New in Python 3.12

#77

Post by movpasd »

NoboruWataya wrote: post #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

It's been stuck in discussions for a long time, unfortunately. The main reason that I remember gleaning from discussions is it's unclear just how "special" None should be treated as, and whether having special syntax for it is excessively "special".

I saw some suggestions for overridable behaviour in the data model for None-like objects, but didn't scrutinise them closely. Either way, it seems controversial. On the one hand, the ability to override operators is really key to Python's design, but on the other it could lead to rather surprising behaviour from overeager overriding. (But to be fair, this is true of other, more common operators too.)

So, for now we're stuck with `if _ is not None else`, I suppose!

Re: What's New in Python 3.12

#78

Post by [deleted] »

pjmlp wrote: post #74
9967d2cad_askhn wrote: post #72

So many breaking changes promulgated with covert version numbers—an unfortunate truth for Python and why the writing on the wall is clear—Python is not dependable—Go is the safer choice for business applications and services.

Java and C# are much safer options, with almost 30 years of deployment production, and an ecosystem of programming languages across the JVM/ART and CLR, that aren't afraid to let programmers express themselves.

[deleted]

Re: What's New in Python 3.12

#79

Post by BoumTAC »

klibertp wrote: post #76
BoumTAC wrote: post #20

Earlier quoted context omitted.

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.

You can't confuse keys in a hash table with properties of objects. It's not confusing, it's a useful distinction. Most languages that have both objects and associative arrays (so not Lua or JavaScript) make this distinction. It's not particularly error prone. You're simply refusing ("don't care why") to learn how to use the tool you're given.

user dictionnary => user["email"]

user instance from a django model => user.email

It is error prone. You're simply refusing to see an aberration.

That's how the language works, but it doesn't mean it's intuitive and easy to understand especially for a language known for being easy to use and understand.

Re: What's New in Python 3.12

#80

Post by gnulinux »

dragonwriter wrote: post #26
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…

I think that this is a hard problem and you're right that spamming KeyError everywhere is against the exceptionality of exceptions. But the current completely unchecked model is also misleading. I don't have such a great solution in mind but I think mypy should be able to verify each exception type is handled at some point in the stack. I know that it sounds vague, but these are my current unorganized thoughts.
Post reply on HN