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

171–180 of 344 posts

Re: Python 3.12

#171

Post by appplication »

masklinn wrote: post #151
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.

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.

Re: Python 3.12

#172

Post by squeaky-clean »

circuit10 wrote: post #73
rmbyrro wrote: post #48

Earlier quoted context omitted.

I don't think this is a political advocacy. It's just a personal expression about a social issue. I found the way it was written quite thoughtful, actually, which I respect (though I don't like in its entirety). But I upvoted your comment because I don't think there's a reason for people to downvote your comment. It's absolutely acceptable that someone dislikes the poem and wants to express it here. People confuse th…

If an upvote is for agreement, does downvoting for disagreement not make sense? Or are upvotes meant for something else?

I downvoted it because it just leads to 2/3s of the thread being an off topic flame-war.

Also like others have said, upvotes are not for agreeing. They are for rewarding higher quality discussion, on topic discussion, etc.

Re: Python 3.12

#173

Post by robertlagrant »

uoaei wrote: post #156
robertlagrant wrote: post #20

Earlier quoted context omitted.

People are allowed to think things, and say what they think. Just as you did.

So then we're making this about freedom as the central moral aspect. Then what about the freedom of the Python maintainers to post what they want? Why the selective defense?

False equivalency. The equivalent would be someone commenting saying they shouldn't publish release notes because of Reasons, and I would defend their right to publish release notes.

Re: Python 3.12

#175

Post by beepbooptheory »

Bostonian wrote: post #15
Alosra wrote: post #5

Everything aside, I enjoyed the "And now for something completely different" part.

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

Those weathered by enough time and strife in this forum could predict this comment and ensuing thread a mile away after reading the announcement. After enough iterations, it all feels like a dance or ritual. Like watching birds mingle and bicker out your window. Just another day, the universe humming along. Things are as they should be :)

Re: Python 3.12

#176

Post by tarheels100 »

Alosra wrote: post #5

Everything aside, I enjoyed the "And now for something completely different" part.

It's a poem advocating empathy, people, not an edict on border control policy. Are people really so sensitive that they can't handle being reminded that other people may think differently than them?

Re: Python 3.12

#177

Post by vb-8448 »

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

Would those benchmarks capture the performance improvements listed in the change log? From what I read, there were two big ones: - Inlined list and set comprehensions. - Reduced data copying in asyncio.

They use the `pyperformance` package[0] that, according to the readme, use real world scenarios. So I expect it to capture every significant improvement.

[0]https://github.com/python/pyperformance

Re: Python 3.12

#178

Post by Ancapistani »

paulddraper wrote: post #147
lvass wrote: 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.

Isn't it obvious? Someone's "temporary hack" stopped working, and even though it's not been important enough to refactor for the past 100 years it's important enough to drop everything right now to fix when it breaks.

Re: Python 3.12

#179

Post by lvass »

paulddraper wrote: post #147
lvass wrote: 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.

PL research and reverse engineering or just fixing compatibility. Say you want a program from 3.6 era but the 107 year old interpreter doesn't quite suit you and the newest one broke something, and you bisect interpreter versions to find 3.11 to 3.12 broke it.

Re: Python 3.12

#180

Post by za3faran »

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.

golang isn't in the same league as the other languages mentioned. And Java and C# have come a long way since to be expressive as well as lesser syntax heavy (type inference, records, pattern matching, string templates, etc.)
Post reply on HN