Re: [Python-Dev] [Python-checkins] r60283 - in python/trunk: Include/longintrepr.h Include/longobject.h Include/unicodeobject.h Misc/NEWS Modules/_fileio.c Objects/longobject.c Objects/unicodeobject.c setup.py
[christian.heimes]
Are you planning to backport bytearrays? I thought we had clearly decided to *not* backport any of the text/bytes model so that the Py2.6 string/unicode model remained pure. Guido proposed a couple of harmless aliases for annotation purposes (to help the 2-to-3 tool do the right thing) and that was it. Your reply was: > Ah, you like to keep it simple. The aliases are easily to implement. > Give me twenty minutes to implement it and write some unit tests. How did we get from two simple aliases to plans for backporting major chucks of the new model? I'm not seeing any limits on Py3.0-->Py2.6 contamination. Raymond
Raymond Hettinger wrote:
Are you planning to backport bytearrays? I thought we had clearly decided to *not* backport any of the text/bytes model so that the Py2.6 string/unicode model remained pure.
The idea raised when I was working on a backport of the io module. The io module requires a mutable byte type. Guido answered a question in my issue http://bugs.python.org/issue1919 Backporting bytearray should be relatively clean since it's a brand new type right? My initial question was: I'm not sure how to proceed with the missing bytearray type: * backport bytearray and the new buffer interface from 3.0 * write a replacement for 2.6 * replace the bytearray code with new code bytearray is a new type that has no equivalent in Python 2.6. Python 3.0's byte type is basically a modified string type. I don't see a problem with bytearray, do you? Christian
On Jan 26, 2008 1:16 AM, Raymond Hettinger <python@rcn.com> wrote:
'bytearray' is a separate issue. It's a brand new type: a *mutable* byte array. Its status as a built-in and completely different API makes it much more convenient than using the old array module. Introducing bytearray is not going to disturb the balance between str/bytes/unicode. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
I'm looking forward to having a native mutable bytes type in Python 2.x. Michael Foord
Raymond Hettinger wrote:
Are you planning to backport bytearrays? I thought we had clearly decided to *not* backport any of the text/bytes model so that the Py2.6 string/unicode model remained pure.
The idea raised when I was working on a backport of the io module. The io module requires a mutable byte type. Guido answered a question in my issue http://bugs.python.org/issue1919 Backporting bytearray should be relatively clean since it's a brand new type right? My initial question was: I'm not sure how to proceed with the missing bytearray type: * backport bytearray and the new buffer interface from 3.0 * write a replacement for 2.6 * replace the bytearray code with new code bytearray is a new type that has no equivalent in Python 2.6. Python 3.0's byte type is basically a modified string type. I don't see a problem with bytearray, do you? Christian
On Jan 26, 2008 1:16 AM, Raymond Hettinger <python@rcn.com> wrote:
'bytearray' is a separate issue. It's a brand new type: a *mutable* byte array. Its status as a built-in and completely different API makes it much more convenient than using the old array module. Introducing bytearray is not going to disturb the balance between str/bytes/unicode. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
I'm looking forward to having a native mutable bytes type in Python 2.x. Michael Foord
participants (4)
-
Christian Heimes -
Guido van Rossum -
Michael Foord -
Raymond Hettinger