331–340 of 344 posts
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.
Earlier quoted context omitted.
Yeah I've memorized it by now: for i in range(len(lst) // batch_size + 1): batch = lst[i * batch_size : (i + 1) * batch_size]
You have a minor bug -- when len(lst) is a multiple of batch_size, this will have an extra iteration at the end with an empty batch. The fixed version is `range((len(lst) + batch_size - 1) // batch_size)`, which emulates `ceil(len(lst) / batch_size)`. Yet more proof that this should be part of stdlib :) Personally I think I'd actually write it like this: for i in range(0, len(lst), batch_size): batch = lst[i:i+batch_…
Earlier quoted context omitted.
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
Earlier quoted context omitted.
> be able to actually figure out what data to send libraries without actually reading their source code Just reading this sent a chill down my spine. I have horrible memories of having to read the code to figure out what something was doing (in JavaScript, Python, Ruby, etc), due to the disaster of an anti-feature called dynamic typing having been used.
> disaster of an anti-feature Untyped languages tend to be at the forefront of paradigms, and typed languages come in toward the end when reliability and need for tooling are more important than innovation/discovery. In the 90s a bunch of kids were building websites with LAMP stacks while serious engineers were building aging/about-to-be-irrelevant desktop software in serious, typed languages.
The P in the LAMP stack is still a bit of a mystery to me. It could (one could wish) have been Haskell instead, but oh well.
Earlier quoted context omitted.
Software is always user-upgradable on Linux. Just install it somewhere in your home directory. GNU Stow [0] can be helpful as a very lightweight way to manage the packages. (Of course, then you take on the responsibility of keeping up with patch releases yourself, which is why we use distros. But if it's just a small number of packages on top of a distro-managed base system, it's perhaps not so bad.) [0] https://www.…
Sure and how do you install Python 3.12 on RHEL 8 without compiling it from source?
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…
What are the advantage of Cython over something like C++ with pybind11 or whatever the equivalent in Rustland?
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'm just happy for itertools.batched for chunking iterables: https://docs.python.org/3.12/library/itertools.html#itertool...
Earlier quoted context omitted.
> That's quite the reach. Unexplained claim about what's being reached for. > Morals are more general than that. Yes, obviously. How does this apply to what I said? > This isn't high school debate club. Okay?
Your interpretation of "equivalency" is hard to understand in any context except one which seeks to limit the disagreement to an extremely narrow "debate" that just so happens to validate the ideology implied by your selective defense. My response is to point out that your narrowing of the space of dicussion is not only noticed but acknowledged and explicitly challenged. In a conversation about morals this framing of…
No, it doesn't "just so happen", any more than saying "everyone should be given a fair trial" in a legal system "just so happens" to apply to the guilty and innocent.
> Clear?
Your response is entirely rhetoric, attempting to criticise me rather than my argument. It's clear how you feel; not what you think.
Earlier quoted context omitted.
You will now be able to, in 3.12 run multiple CPython VMs inside the same process w/o having them share state. Previously CPython VM state was spread over a bunch of global variables so you had one GIL per process embedding Python. For your usecase, eventually that ProcessPoolExecutor.map will be GillFreeThreadPoolExecutor.map and all the cross process serialization shenanigans will go away.
But instead of cross-process serialization we get cross-interpreter serialization, so serialization shenanigans don't go away. There is support in the newest pickle protocol for using a shared buffer to transfer data more efficiently, but that would work in multiprocessing [0] just as well as in subinterpreters (and currently isn't implemented in either one). [0] https://github.com/python/cpython/issues/89467
Queues, immutable records, atomic refcounts, a global object heap for shared items. There are lots of way forward here that don't involve a full SERDES round trip.