On Wed, 15 Feb 2006 15:20:16 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>I'm actually assuming to put this off until 2.6 anyway.
>
>On 2/15/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> Thomas Wouters wrote:
>>
>> > > After reading some of the discussion, and seen some of the arguments,
>> > > I'm beginning to feel that we need working code to get this right.
>> > >
>> > > It would be nice if we could get a bytes() type into the first alpha, so
>> > > the design can get some real-world exposure in real-world apps/libs be-
>> > > fore 2.5 final.
>> >
>> > I agree that working code would be nice, but I don't see why it should be
>> > in
>> > an alpha release. IMHO it shouldn't be in an alpha release until it at
>> > least
>> > looks good enough for the developers, and good enough to put in a PEP.
>>
>> I'm not convinced that the PEP will be good enough without experience
>> from using a bytes type in *real-world* (i.e. *existing*) byte-crunching
>> applications.
>>
>> if we put it in an early alpha, we can use it with real code, fix any issues
>> that arises, and even remove it if necessary, before 2.5 final. if it goes
>> in
>> late, we'll be stuck with whatever the PEP says.
>>
>> </F>
>>
I could hardly keep up with reading, never mind trying some things
and writing coherently, so if others had that experience, 2.6 sounds +1.
I agree with Fredrik that an implementation to try in real-world use cases
would probably yield valuable information.
As a step in that direction, could we have a sub-thread on what methods
to implement for bytes?
I.e., which str methods make sense, which special methods? How many methods
from list make sense, given that bytes will be mutable? How much of
array.array('B')
should be emulated? (a protype hack could just wrap array.array for storage).
Should the type really be a subclass of int? I think that might be hard for
prototyping, since builtin types as bases seem to get priority subclass bypass
access from some builtin functions. At least I've had some frustrations with
that.
If it were a kind of int, would it be an int-string, where int(bytes([65]))
would work
like ord does with non-length-1? BTW bytes([1,2])[1] by analogy to str should
then return bytes([2]), shouldn't it? I have a feeling a lot of str-like methods
will bomb if that's not so.
>>> int(bytes([1,2])) # faked ;-)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: int() expected a byte, but bytes of length 2 found
I've hacked a few pieces, but I think further discussion either in this thread
or maybe a bytes prototype spec thread would be fruitful.
By the time a prototype spec takes shape, someone will probably have beaten me
to something workable, but that's ok ;-)
Then a PEP will mostly be writing and collecting rationale references etc.
That's really not my favorite kind of work, frankly. But I like thinking and
programming.
Regards,
Bengt Richter
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
