News for hackers. Stuff that matters.
Re:Lesser known parts of Python standard library – Trickster... by sgarland on Thursday September 05, 2024 @09:44AM (#41456558)
Adding `array` [0] to the list. It's generally slower than a list, but massively more memory-efficient. You're limited to a heterogeneous type, of course, but they can be quite useful for some operations.

[0]: https://docs.python.org/3/library/array.html

Re:Lesser known parts of Python standard library – Trickster... by cgopalan on Thursday September 05, 2024 @10:50AM (#41457167)
You mean homogenous instead of heterogenous, right?
Re:Lesser known parts of Python standard library – Trickster... by tomjakubowski on Thursday September 05, 2024 @12:04PM (#41457908)
To add to this, arrays are also restricted to primitive C types. A Python array object is simply a heap allocated `unsigned long *` or what have you.

https://docs.python.org/3/library/array.html

https://github.com/python/cpython/blob/main/Modules/arraymod...

And you can use struct for heterogenous data =) It has a neat DSL for packing/unpacking the data, reminiscent of the "little languages" from classic book The Practice of Programming. Python is actually pretty nice working with binary data.

https://docs.python.org/3/library/struct.html

Re:Lesser known parts of Python standard library – Trickster... by sgarland on Friday September 06, 2024 @07:58AM (#41465337)
> Python is actually pretty nice working with binary data.

It really is! I’ve been working on a project to generate large amounts of synthetic data, and it calls out to C for various shared libraries to do the heavy lifting *. Instead of encoding and decoding back and forth, I can just ship bytes around, and then directly write them out to a file. Saves a lot of time.

*: yes, I should just rewrite it into a faster language entirely. I intend to, but for the time being it’s been “how fast can I make Python without anything but stdlib,” as long as you accept ctypes as being included in that definition.

Re:Lesser known parts of Python standard library – Trickster... by sgarland on Friday September 06, 2024 @07:06AM (#41464995)
Ugh… yes. Thank you.
Re:Lesser known parts of Python standard library – Trickster... by banannaise on Friday September 06, 2024 @10:06AM (#41466349)
It would be very funny to have an iterable type where the items are required to contain incompatible types.
Re:Lesser known parts of Python standard library – Trickster... by Sohcahtoa82 on Friday September 06, 2024 @06:17PM (#41470115)
Somewhere out there, I'm sure someone could come up with a use case.
Re:Lesser known parts of Python standard library – Trickster... by lang4d on Thursday September 05, 2024 @05:09PM (#41460431)
Why is it slower compared to a normal list?
Re:Lesser known parts of Python standard library – Trickster... by sgarland on Friday September 06, 2024 @07:49AM (#41465276)
The simplistic answer is that lists have been heavily optimized over the years, arrays haven’t been touched much.

I’m not positive on why lists are faster to create than lists, though. Retrieval makes sense (lists already store the Python object, arrays have to cast it back), but creation I’m unsure about. I’ll check dis.dis.

EDIT: from a sibling comment above [0], maybe because array reallocs are done much more granularly than lists, so as it grows, it’ll have to do so more frequently compared to lists?

[0]: https://github.com/python/cpython/blob/main/Modules/arraymod...