On Sat, Oct 2, 2021, 10:20 PM Christopher Barker
wrote:
>
> But sure, if we can eliminate inefficiencies in Python standard data
> types, then why not?
>
Because the C implementation becomes hard to maintain.
All of our linear containers could benefit from non-linear implementations
in some
On Sat, Oct 2, 2021, 11:20 PM Christopher Barker
wrote:
[Snip...]
>
> But sure, if we can eliminate inefficiencies in Python standard data
> types, then why not?
>
I agree. If we can eliminate inefficiencies in core Python features, that
would be great.
I don't work with this kind of thing, so
> See the Stackoverflow post I linked to at the start of my post.
>
>
> https://stackoverflow.com/questions/56966429/getting-pairs-of-one-item-and-the-rest-over-a-python-list
I’m confused— that seems to be a SO post related to another ongoing thread…
On Sat, Oct 02, 2021 at 07:57:48AM -0700, Guido van Rossum wrote:
> No, it would also have to increment the reference count of each item (since
> blist owns a reference to each). That's what makes this slow.
Ahaha, of course, I forgot about the ref counting.
> > There are lots of other variants
On Sat, Oct 2, 2021, 10:58 AM Guido van Rossum wrote:
> Are you actually observing that people are doing this with regular lists?
> Don't people working with Big Data usually use Pandas, which is built on
> NumPy arrays and custom data structures?
>
Basically, Guido is right. Big data lives in
On Sat, Oct 2, 2021 at 7:42 AM Steven D'Aprano wrote:
> This half-baked idea is inspired by this thread here:
>
>
> https://mail.python.org/archives/list/python-ideas@python.org/message/5LGWV3YLCNBVSL4QHQKJ7RPNTMWOALQA/
>
> which in turn was inspired by this Stackoverflow post:
>
>
>
