What to do for bytes in 2.6?

I believe the issue of whether and how to backport bytes
(and
bytearray?) from 3.0 to 2.6 has come up before, but I don't
think
we've come to any kind of conclusion. It's quite subtle. In
a private
email, Thomas Wouters and I discussed this:

[Guido]
> > Perhaps the biggest question in my mind is what to
do with bytes in
> > 2.6. Make it an alias for str? Or a new type that
doesn't mix with
> > either str or unicode? But then how do we get
read() calls and the
> > like on binary files or sockets to return bytes
instances? Perhaps a
> > trivial str subclass? Or return bytes when -3 is
specified? I need to
> > bring this up on the list.

[Thomas]
> I don't know yet. I'm not sure yet what to do with
strings and unicode in
> 2.6 in -3 mode (or perhaps through a future-import,
with some hackery.)
> Perhaps a *set* of str-subclasses makes sense: a
will-be-unicode subclass,
> and a will-be-bytes subclass. String literals and
text-mode input would
> produce will-be-unicode, binary input and byte literals
will-be-bytes.
> Switching between -3 and normal mode for that would be
changing a few
> pointers in the core, making all operations return
normal strings in normal
> mode. And the would-be types can produce whatever
warning they wish -- they
> need not worry about speed. But I'm not sure if that'll
work.

-- 
--Guido van Rossum (home page: http://www.python.org/~
guido/)
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

Guido van Rossum schrieb:
> I believe the issue of whether and how to backport
bytes (and
> bytearray?) from 3.0 to 2.6 has come up before, but I
don't think
> we've come to any kind of conclusion. It's quite
subtle. In a private
> email, Thomas Wouters and I discussed this:
> 
> [Guido]
>> > Perhaps the biggest question in my mind is
what to do with bytes in
>> > 2.6. Make it an alias for str? Or a new type
that doesn't mix with
>> > either str or unicode? But then how do we get
read() calls and the
>> > like on binary files or sockets to return
bytes instances? Perhaps a
>> > trivial str subclass? Or return bytes when -3
is specified? I need to
>> > bring this up on the list.
> 
> [Thomas]
>> I don't know yet. I'm not sure yet what to do with
strings and unicode in
>> 2.6 in -3 mode (or perhaps through a future-import,
with some hackery.)
>> Perhaps a *set* of str-subclasses makes sense: a
will-be-unicode subclass,
>> and a will-be-bytes subclass. String literals and
text-mode input would
>> produce will-be-unicode, binary input and byte
literals will-be-bytes.
>> Switching between -3 and normal mode for that would
be changing a few
>> pointers in the core, making all operations return
normal strings in normal
>> mode. And the would-be types can produce whatever
warning they wish -- they
>> need not worry about speed. But I'm not sure if
that'll work.
> 

Is the bytes type required for PEP3118 'Revising the buffer
protocol'?
I just started to work on implementing this PEP for ctypes,
in the
hope that these changes can be merged into trunk.

Thomas

_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

On Jan 17, 2008 11:24 PM, Thomas Heller <thellerctypes.org> wrote:
> Is the bytes type required for PEP3118 'Revising the
buffer protocol'?

I don't think so. I would like to see this PEP backported
(but keep
the old 'buffer' of course for b/w compatibility). Whenever
this PEP
talks about bytes we can just use str/PyString in the
backport.

> I just started to work on implementing this PEP for
ctypes, in the
> hope that these changes can be merged into trunk.

Remember that the trunk ought to remain backwards compatible
with 2.5
-- 2.6 should not break code that worked under 2.5, since we
want as
many users as possible to feel comfortable with upgrading to
2.6.

-- 
--Guido van Rossum (home page: http://www.python.org/~
guido/)
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com