Live data from Hacker News

Python 3.12

python.org

191–200 of 344 posts

Re: Python 3.12

#191
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...

Some packages already use those. For previous Python versions, those are available in typing_extensions: https://typing-extensions.readthedocs.io/en/latest/

Re: Python 3.12

#192
post #187

Earlier quoted context omitted.

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++

I know that Fortran is highly used in the numeric world, especially due to widespread libraries such as LAPACK and BLAS, amongst others; in your opinion, what are the characteristics that make such code much more clear when written in Fortran as opposed to C or C++?

Also, do you prefer a specific version of Fortran, or is the latest one fine?

Re: Python 3.12

#193
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...

Modern Python is sure ugly.

Re: Python 3.12

#194
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.

Sad ... I think python need some performance improvement more than the no-gil stuff.

Re: Python 3.12

#195

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.

Show me the evidence for "white flight" it certainly doesn't happen in most European metropolitan areas (the map of the French elections certainly didn't show that any of the areas surrounding the big cities were right leaning, in fact like e.g. Sachsen and Thüringen, the regions in Germany with the highest support for right wing parties, experience lots of people leaving, not moving there). That's one of the reasons why cities have become increasingly unaffordable.

Re: Python 3.12

#196

Earlier quoted context omitted.

IMHO there is nothing "fortunate" about dragging politics into programming, regardless of your or mine views. I would find it fortunate and valuable if at least certain human activites stayed out of political culture wars entirely. If, instead of "my side, your side", there simply wasn't any need to think of a side for a moment. I already deleted my FB and TW account to get rid of incessant political flamewars and I…

I’ve always considered the no-politics at work rule to be a neutral zone in an armistice. It’s been in effect for so long people have forgotten why it existed and see nothing wrong with resuming agitations. The ‘politics is personal’ and ‘bring your whole self to work’ shift is an intentional reinsertion of politics back into work and like the Chesterton’s fence parable I think we’ll rediscover why that rule was ther…

You're both correct, I was too flippant with my reply. It is out of place.

Re: Python 3.12

#197
post #187

Earlier quoted context omitted.

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++

I know that Fortran is highly used in the numeric world, especially due to widespread libraries such as LAPACK and BLAS, amongst others; in your opinion, what are the characteristics that make such code much more clear when written in Fortran as opposed to C or C++? Also, do you prefer a specific version of Fortran, or is the latest one fine?

It is not about the language. Is about the people using it. They are typically not CS people. You cannot expect they program all the languages. They know typically python, matlab, and fortran. Of the 3, the one that would perform better is Fortran.

Re: Python 3.12

#199
post #186

Earlier quoted context omitted.

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…

Preferable for those who would use your code. If it’s just you then it’s your exclusive preference. If you have users, args/kwargs is going to be more opaque than a more explicit option.

For code with many users, creating a few extra minutes of work for one dev is preferable when the alternative would be every dev who uses that code has to spend that same extra work and then some to grok what exactly is going on with the method signatures. Being explicit also creates traceable code, in that you can search a keyword to find everywhere it’s used or passed rather than tracing methods where it might be used.

I can promise very few users would be thankful for the elegance and minimalism of args/kwargs when they’re source-diving trying to figure out how to get some basic functionality to work.

Post reply on HN