Brett Cannon wrote:
> +1 from me.
Looks good to me too: +1
I wouldn't mind seeing some iteration-in-C bit-bashing operations in
there eventually, but they aren't needed on the first pass, and even
being able to do things like the following will be a decent improvement
over the status quo for l
Yes, you are completely right. I ended up realizing that a change like
this would break almost all third-party extension.
But... What about of doing this for Py3K? Third-party extension have
to be fixed anyway.
On 10/1/07, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Martin,
>
> On Fri, Sep 28, 20
Nick> I wouldn't mind seeing some iteration-in-C bit-bashing operations
Nick> in there eventually...
Nick>data = bytes([x & 0x1F for x in orig_data])
This begins to make it look what you want is array.array or nump.array.
Python's arrays don't support bitwise operations either, b
[EMAIL PROTECTED] wrote:
> Nick> I wouldn't mind seeing some iteration-in-C bit-bashing operations
> Nick> in there eventually...
>
> Nick>data = bytes([x & 0x1F for x in orig_data])
>
> This begins to make it look what you want is array.array or nump.array.
> Python's arrays don'
Nick Coghlan wrote:
> numpy would be a big dependency to bring in just to
> get more efficient bit-oriented operations on a byte sequence
Random thought - if long integers were to use byte
sequences internally to hold their data, it might
be possible to get this more or less for free in
terms of
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Brett Cannon wrote:
| > +1 from me.
|
| Looks good to me too: +1
|
| I wouldn't mind seeing some iteration-in-C bit-bashing operations in
| there eventually, but they aren't needed on the first pass, and even
| being abl
