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

321–330 of 344 posts

Re: Python 3.12

#321

Post by dagmx »

benkuykendall wrote: post #296
dagmx wrote: post #209

Earlier quoted context omitted.

Basically I was hoping to use it for functions that wrap others. E.g setup something and then pass the kwargs through to the other function.

If I understand you correctly, I think ParamSpec (since 3.10) is what you are looking for, especially if you want to be generic over the type of the inner function. The example from the docs ( https://docs.python.org/3/library/typing.html#typing.ParamSp... ): from collections.abc import Callable from typing import TypeVar, ParamSpec import logging T = TypeVar('T') P = ParamSpec('P') def add_logging(f: Callable[P, T])…

Hmm thanks. I think that might be slightly different but I’ll try it out and see.

Re: Python 3.12

#322

Post by schrodingerscow »

winter_blue wrote: post #255
goatlover wrote: post #210

Earlier quoted context omitted.

It's not an anti-feature. Those languages gained popularity in part because they were dynamically typed. But this debate is decades old and people always dogmatically choose one side, so not really any point in trying to convince you. Alan Kay made the argument back in the 1970s that type systems were always too limiting, therefore classes and late binding were the answer for him.

I’m speaking from my real-life lived experience with dynamic typing. I feel that dynamic typing is truly harmful for any project that involves involving complex logic, needs collaboration / where there’s more than 1 person working on it, or even for any large project (even if only 1 person is working on it). It was a massive waste of time to have to read piles of code code, use a debugger and inspect object structure…

Ha you sound exactly like my own consciousness. There are few things in life I feel as resolute about than this one. Dynamic types were a mistake. Let’s learn and move on. I often joke that if null pointer references were the billion dollar mistake (or whatever it’s called), dynamic typing was the 100 billion dollar mistake. And we’re still living with it but thank god for typescript etc for saving us finally

Re: Python 3.12

#323

Post by syndicatedjelly »

throw1234651234 wrote: post #319
syndicatedjelly wrote: post #303

Earlier quoted context omitted.

I recently took part A of Dan Grossman's Programming Languages' course, and he focus on Standard ML which is strongly-typed. It was enlightening to learn about, and after completing Part A, I too felt that any language that lacks type safety can't be a serious language. I recently started using Python again for a side project, and I had forgotten how good of a dev experience Python offers. I wish I could explain bett…

I appreciate the thoughtful response, despite my comment being less then that. With that said, I am using Python in production for a line business app for a 2 billion dollar company now. I can't imagine why anyone would use this for a multi-team project outside of areas where it's the language with the most libraries(IoT, ML). Not only is there the type safety issue, the standard testing and ORM libraries are way beh…

I heard somewhere that Python is rarely the best language for any given application, but it's usually the second-best language for many applications.

Re: Python 3.12

#324

Post by ehsankia »

georgehotelling wrote: post #150

I'm just happy for itertools.batched for chunking iterables: https://docs.python.org/3.12/library/itertools.html#itertool...

99% of my more_itertools imports are exactly for this.

there's 1-2 other stuff from more_itertools that I think should make it to itertools. I'd actually like to see statistics from huge monorepos/opensource about usage stats of various more_itertools functions.

Re: Python 3.12

#325

Post by memco »

appplication wrote: post #199
memco wrote: post #186

Earlier quoted context omitted.

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

I haven't often been the designer of code others have used, but I have used someone else's wrappers for libraries that we use in many parts of our code. My experience of trying to use their wrappers has been a guessing game of how they decided to arbitrarily rename an argument and finding places where they don't support arguments that I need. I get that kwargs is a bag of mystery and that there is benefit to being explicit, but it comes with tradeoffs. I don't like really like kwargs, but sometimes the use of kwargs better serves the purpose than the alternatives. I've looked for solutions, but haven't found anything that avoids the above issues. If anyone has tools or techniques that eliminate these pain points please share. The typedDict is promising, but I'm not sure how composable they are. Time will tell.

Re: Python 3.12

#326

Post by CogitoCogito »

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.

If you'd like to see another viewpoint (or no viewpoint) espoused, volunteer to help Python with their releases and you'll have a chance to provide input to their release process.

Re: Python 3.12

#327

Post by om26er »

I most curious to know what happened to the faster-python project progress. I see there were some changes contributed by Mark Shannon and Eric Snow but the performance "upto 5x in 4 releases" doesn't look like happening. I guess the biggest question is is JIT still being pursued?

Re: Python 3.12

#328

Post by extasia »

kuratkull wrote: post #226
tandav wrote: post #217

I wish they make it possible to use any, callable builtins for type annotations

You can. def foobar(things: list[tuple[int, Floob | None]]) -> dict[int, int]): Possible since 3.11 I think, maybe even 3.10.

I think they mean the literal builtins `any` and `callable` instead of typing.Any and typing.Callable.

Re: Python 3.12

#329

Post by IshKebab »

H8crilA wrote: post #309
IshKebab wrote: post #229

Earlier quoted context omitted.

It's a less complicated version of multiprocessing because you don't have to deal with multiple processes and all the complexity that that entails. It's basically web workers / isolates for Python.

It looks more complicated. You get the same cumbersome communication primitive (channels), except now native code can easily get messed up. And it requires more care when developing the interpreter itself. Using multiprocessing was actually pretty easy (apart from the communication primitives, which obviously suck).

Multiprocessing means you need to deal with signals (which are ancient and powerful footguns), handle processes being killed, platform differences (fork vs spawn), etc. It really is a bad solution. Isolates are much much better.

> You get the same cumbersome communication primitive (channels), except now native code can easily get messed up.

I'm not sure what you mean by that. Native code has to be thread safe sure, but now it also can be thread safe! You can have native code that is actually properly multithreaded. A big win.

> And it requires more care when developing the interpreter itself.

Maybe. Not really an issue for the user though.

Re: Python 3.12

#330

Post by TheFlyingFish »

systemvoltage wrote: post #202

I don't know much about the internals of python (or compiler theory stuff), but it would be cool to productionize a script with types and make a static binary out of it. pypy/mypy and other projects are fine but they don't support latest python versions and libraries. I want the ease of python but fast once you lock down the dynamic programming features.

You may be interested in Mojo: https://modular.com/Mojo

Kind of a crazy project but the "just go ahead and import any Python module and we'll embed the VM in your binary" approach is interesting, at least.

Post reply on HN