Live data from Hacker News

Python 3.12

python.org

181–190 of 344 posts

Re: Python 3.12

#181

Earlier quoted context omitted.

> Maybe now I'll be able to actually figure out what data to send libraries without actually reading their source code. One could hope, but any library abusing kwargs in all their methods is showing they’re willing to go through the absolute minimum to make their code usable, let alone readable and self-documenting.

It feels like we're going in cycles. C was somewhat lax with type checking, thus C++ and Java were both made more strict. Looking to escape the tyranny of static typing, the rise of Python, Ruby, or JavaScript instead left us with a desire that Rust, Go, and TypeScript now fulfill. I wonder what's the next step? LLMs are extremely broad in what they accept, but don't exactly fill the same niches.

I always saw C++ and Java addressing other issues, like low level memory management, and higher level abstractions like objects. Not so much type policy. Anyways I see a strong tendency in lots of programmers dismissing anything that is not type static-strict-safe, and others advocating for a more relaxed system.

Re: Python 3.12

#182
post #149

Earlier quoted context omitted.

It feels like we're going in cycles. C was somewhat lax with type checking, thus C++ and Java were both made more strict. Looking to escape the tyranny of static typing, the rise of Python, Ruby, or JavaScript instead left us with a desire that Rust, Go, and TypeScript now fulfill. I wonder what's the next step? LLMs are extremely broad in what they accept, but don't exactly fill the same niches.

I'm holding out hope for a Fortran resurgence. It's a tiny hope. But a hope nonetheless. Fortran is fun.

I would really like to see more fortran.

Re: Python 3.12

#183

What's new: https://docs.python.org/dev/whatsnew/3.12.html Summary, sorry for poor formatting, I'm not sure HN can do a list of any kind? New features More flexible f-string parsing, allowing many things previously disallowed (PEP 701). Support for the buffer protocol in Python code (PEP 688). A new debugging/profiling API (PEP 669). Support for isolated subinterpreters with separate Global Interpreter Locks (PEP 684…

Isolated subinterpreters (PEP 684): Just how isolated are those? Is it simply a more complicated version of multiprocessing, with all the same drawbacks (communication via pipes/socket/some-other-stream)?

Re: Python 3.12

#184

Earlier quoted context omitted.

> Maybe now I'll be able to actually figure out what data to send libraries without actually reading their source code. One could hope, but any library abusing kwargs in all their methods is showing they’re willing to go through the absolute minimum to make their code usable, let alone readable and self-documenting.

It’s like pointer chasing, except the docs having you chase around kwargs are incomplete and there’s gaps. You have to read source code. The Azure SDK is full of them, making liberal use of kwargs.pop. What a nightmare.

The Azure SDK generally have a lot of silliness in the Python implementation. Functions that take string as inputs, except of course they don't, they take two or three very specific string values and use them to control functionality. What those values are... Well, you should take a look at the ENUM in the C# implementation to figure that part out.

Re: Python 3.12

#185

Earlier quoted context omitted.

I don't think political advocacy belongs in an announcement of a Python version.

I think something run by an organisation with its own rules and guidelines, can be run any way that organization sees fit.

[dead]

Re: Python 3.12

#186

Earlier quoted context omitted.

A big use case for kwargs is not breaking compatibility and not having to copy/paste a ton of parameters when just forwarding them. But that's exactly the case which is difficult to type correctly.

Either copy/paste or rolling them into config objects and passing those down is generally preferable. Copy paste doesn’t always feel great for pass through arguments but it’s perfectly interpretable. Naked kwargs is so difficult to work with that I hesitate to think of a use case where it wouldn’t be an anti pattern.

> Either copy/paste or rolling them into config objects and passing those down is generally preferable

Preferable for whom? I do not prefer it. I much prefer to avoid the extra work it creates for me vs. the simplicity of kwargs. I use explicit args for the function I made and then add *kwargs on the end and then I don't have to write bespoke config objects or copy and paste a bunch of stuff that might be obsolete by a future update to some library and also pollute my function's signature. I would very much welcome a way to tell callers where kwargs is going without having to do extra work.

Re: Python 3.12

#187
post #149

Earlier quoted context omitted.

I'm holding out hope for a Fortran resurgence. It's a tiny hope. But a hope nonetheless. Fortran is fun.

I'm curious - what do you particularly like about Fortran that isn't otherwise broadly available? Is it a matter of cultural idioms, a unique composition of features, or something else entirely?

Not OP, but I know a good use case: where I work we do lots of math and signal processing. It is done in matlab, which is great, but then we need to run it in some embedded processor. Using the C++ generated by matlab is beyond any hope. Had the code be written in Fortran (which is very possible, and would make the code clearer) it would run very fast. Now we had a team of people translating matlab to C++

Re: Python 3.12

#188
post #74

Ooh, seems there is a new syntax for declaring the types of kwargs [1]: from typing import TypedDict, Unpack class Movie(TypedDict): name: str year: int def foo(*kwargs: Unpack[Movie]): ... Maybe now I'll be able to actually figure out what data to send libraries without actually reading their source code. 1. https://docs.python.org/3.12/whatsnew/3.12.html#pep-692-usin...

Finally! I've been waiting for this for years.

Now I just have to wait 5 more years until 3.12 is sufficiently old that work lets me use it.

Bets on user-upgradable Python on Linux by 2030?

Re: Python 3.12

#189

Earlier quoted context omitted.

That seems to misrepresent reality. Generally speaking in all elections that I am aware off, rural regions are leaning right while urban regions are leaning left. In fact in general it seems anti-immigration/foreigner stances are almost anti-proportional to the number of immigrants/foreigners a person might encounter during their day. Just 2 counter examples (anecdotes but I'm sure a bit of searching will reveal numb…

"In fact in general it seems anti-immigration/foreigner stances are almost anti-proportional to the number of immigrants/foreigners a person might encounter during their day." That is an egg-and-chicken question. "White flight" is a thing and people who moved away from ghettoizing cities/neigbourhoods into the surrounding suburbia will likely vote against further immigration.

But that's typically not happening either. I fact usually the opposite happens, the urban areas with lots of immigrants get gentrified, because everyone wants to live there.

On top of that, we are now seeing that outer suburbs which were guaranteed winning electorates for right parties are now becoming more and more left leaning because young urban dwellers are moving there because they can't afford the cities.

Re: Python 3.12

#190
post #119

Earlier quoted context omitted.

I dislike it because it's kinda hard to understand (can't really say I did) specially without any context, and programming language release notes are something people should read even a hundred years afterwards.

I'm curious about the circumstance leading to reading Python 3.12 release notes in 2123.

Multiplanetary species that has merged with AI thanks to neuralink-esque tech discovers a bug in the brains of 5% of the population. Turns out the bug is due to Python 3.12 which was used to write the natural language understanding (NLU) engine of the brain chips.
Post reply on HN