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

Python 3.12

python.org

Post reply on HN
Print view View original

161–170 of 344 posts

Re: Python 3.12

#161

Post by haneefmubarak »

tomrod wrote: post #149
rollcat wrote: post #117

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'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?

Re: Python 3.12

#162

Post by [deleted] »

rollcat wrote: post #117
appplication wrote: post #96

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.

[deleted]

Re: Python 3.12

#163

Post by moduspol »

IKantRead wrote: post #110
moduspol wrote: post #102

Earlier quoted context omitted.

One can be supportive of mutual aid and international, cross-cultural cooperation while also acknowledging that a nation doesn't exist without borders, sovereignty matters, and that unchecked migration is not universally good. When you include the contemporary context of illegal US border crossings at record numbers [1], it's clearly making a political statement. Pretending the development of a programming language i…

Could you point out where they are supporting "unchecked migration"? The statement there only reads to me as a call to have compassion for those caught up in what will be a perpetually escalating migration crisis (and will likely soon make migrants of those who are currently protecting their borders). > Pretending the development of a programming language is inexorably linked to unchecked immigration is disingenuous.…

Putting aside the fairly explicit lines in the poem: it's the context. It is not the case that the western world currently has no immigration and the poem makes the case to allow at least some.

More immigrants than ever are pouring over the US / Mexico border. The mayor of NYC (a self-proclaimed "sanctuary city") is now warning of the city's destruction as a result of the overwhelming influx [1]. This mayor is politically aligned with the party of our President, who presumably has no political interest in embarrassments like this, yet it's still happening.

"Unchecked migration" is essentially what is already happening, at least in the US. A cutesy poem in the release notes of software (??) that paints the side opposing it as mouth-breathing bigots and the supportive side as empathetic truth-tellers is unnecessary at best.

[1] https://cbs4local.com/news/local/nyc-mayor-warns-of-citys-de...

Re: Python 3.12

#165

Post by notatallshaw »

liquidpele wrote: post #107
bloopernova wrote: post #2

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…

Tbh the f-string stuff sounds pretty in-pythonic to me… like it would make it much harder to read and abuse.

What is or isn't "pythonic" is largely determined by the community not the language. Nothing is stopping the Python community from monkey patching everything like the Ruby community does.

The f-string changes arrived because there was a need to formalize the syntax, so other Python parsers, for CPython to move off having a special sub-parser just for f-strings, and to be able decide whether weird edge cases were bugs or features.

Once formalized it was decided not to put arbitrary limits on it just because people can write badly formatted code, people are can already do that and it's up to the Python community to choose what is or isn't "Pythonic".

FYI, one of the things I'm really looking forward to is being able to write: f"Rows: {'\n'.join(rows)}\n Done!"

Which in Python 3.11 is illegal syntax.

Re: Python 3.12

#167

Post by inglor_cz »

cycomanic wrote: post #158
inglor_cz wrote: post #63

Earlier quoted context omitted.

There certainly is an equivalent of NIMBY in Western asylum politics. A lot of Green/Progressive voters in Western Europe live in affluent neighbourhoods where practical effects of current migration waves are very limited, and often positive (e.g. cheap workforce for your household, but your kids' school does not suffer from any gang activity). Voting patterns across income groups tend to reflect that discrepancy.

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.

Re: Python 3.12

#168

Post by squeaky-clean »

dagmx wrote: post #116
dandiep wrote: 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...

I wonder if Unpack works on a function? I assume it’s any callable.

The type that gets Unpack[]'d needs to inherit from TypeDict, unless I'm misunderstanding what you mean.

Re: Python 3.12

#169

Post by veber-alex »

ynik wrote: post #66
ptx wrote: post #49

Earlier quoted context omitted.

Since it currently lacks any way to transfer objects between interpreters other than pickling, does it offer any advantage over the multiprocessing module?

Not for pure python code; but there's massive advantages for mixed C(++) and Python: I can now have multiple sub interpreters running concurrently and accessing the same shared state in a thread-safe C++ library. Previously this required rewriting the whole C++ library to support either pickling (multiplying the total memory consumption by the number of cores), or support allocating everything in shared memory (which…

But why?

There is no GIL in C/C++/Rust/Zig/Whatever, just use threads.

Re: Python 3.12

#170

Post by notatallshaw »

vb-8448 wrote: post #92

Benchmarks aren't too promising[0]. I wonder if the original 500% improvement they targeted at the start of the `faster cpython` project is still a realistic target. [0] https://github.com/faster-cpython/benchmarking-public

My understanding is most low hanging fruit were picked for Python 3.11. And the faster CPython team have been looking at more mid to long term goals with the addition of a JIT and other accompanying infrastructure around for 3.13 and 3.14.

However, the recent no-GIL decision I think has sent a few things back to the drawing board to see what can and cannot be salvaged from their progress and plans so far.

Post reply on HN