Hello!
I've successfully back ported the bytearray type and the io module from 3.0 to 2.6. The code is available in the branch trunk-bytearray [1]. I'm down to four failing byte tests and one failing io test. The failing byte tests are all related to pickling and subclassing.
I like to get the remaining tests fixed for the upcoming release in a week. Please checkout the branch and help me figure out the remaining issues.
Christian
[1] svn+ssh://pythondev@svn.python.org/python/branches/trunk-bytearray
Christian Heimes schrieb:
Hello!
I've successfully back ported the bytearray type and the io module from 3.0 to 2.6. The code is available in the branch trunk-bytearray [1]. I'm down to four failing byte tests and one failing io test. The failing byte tests are all related to pickling and subclassing.
I like to get the remaining tests fixed for the upcoming release in a week. Please checkout the branch and help me figure out the remaining issues.
Follow up:
All failing bytearray tests were caused by subclasses of bytearray. I've removed the Py_TPFLAGS_BASETYPE flag for now. Are you fine with the inclusion of bytearray although it can't be subclassed?
I'm going to fix the last io bug now. I like to merge the backport of bytearray and io before the next alpha gets shipped out.
Christian
I'm okay with bytearray not being subclassable in 2.6 as a temporary measure. I wouldn't want that to leak into 3.0 though, and I'd rather have it subclassable in 2.6 as well. I wonder why it doesn't work in 2.6 but does work in 3.0?
On Tue, Mar 25, 2008 at 5:05 PM, Christian Heimes lists@cheimes.de wrote:
Christian Heimes schrieb:
Hello!
I've successfully back ported the bytearray type and the io module from 3.0 to 2.6. The code is available in the branch trunk-bytearray [1]. I'm down to four failing byte tests and one failing io test. The failing byte tests are all related to pickling and subclassing.
I like to get the remaining tests fixed for the upcoming release in a week. Please checkout the branch and help me figure out the remaining issues.
Follow up:
All failing bytearray tests were caused by subclasses of bytearray. I've removed the Py_TPFLAGS_BASETYPE flag for now. Are you fine with the inclusion of bytearray although it can't be subclassed?
I'm going to fix the last io bug now. I like to merge the backport of bytearray and io before the next alpha gets shipped out.
Christian
Guido van Rossum schrieb:
I'm okay with bytearray not being subclassable in 2.6 as a temporary measure. I wouldn't want that to leak into 3.0 though, and I'd rather have it subclassable in 2.6 as well. I wonder why it doesn't work in 2.6 but does work in 3.0?
It *seems* like the comparison ops don't work correctly for subclasses. In general subclassing works but comparison of subclasses result in wrong results.
It's probably easy to fix but I haven't figured it out yet.
Christian
Guido van Rossum schrieb:
I'm okay with bytearray not being subclassable in 2.6 as a temporary measure. I wouldn't want that to leak into 3.0 though, and I'd rather have it subclassable in 2.6 as well. I wonder why it doesn't work in 2.6 but does work in 3.0?
This fix for the issue was easy once I noticed the cause of the problem
Modified: python/branches/trunk-bytearray/Objects/typeobject.c ============================================================================== --- python/branches/trunk-bytearray/Objects/typeobject.c (original) +++ python/branches/trunk-bytearray/Objects/typeobject.c Wed Mar 26 13:20:46 2008 @@ -3762,6 +3762,8 @@ COPYBUF(bf_getwritebuffer); COPYBUF(bf_getsegcount); COPYBUF(bf_getcharbuffer); + COPYBUF(bf_getbuffer); + COPYBUF(bf_releasebuffer); }
basebase = base->tp_base;
Christian
2008/3/26, Christian Heimes lists@cheimes.de:
I'm okay with bytearray not being subclassable in 2.6 as a temporary measure. I wouldn't want that to leak into 3.0 though, and I'd rather have it subclassable in 2.6 as well. I wonder why it doesn't work in 2.6 but does work in 3.0?
This fix for the issue was easy once I noticed the cause of the problem
Modified: python/branches/trunk-bytearray/Objects/typeobject.c
So, now the byte object behaves equal in 2.6 and 3.0, right?
Thanks!
2008/3/26, Christian Heimes lists@cheimes.de:
Correct!
The bytearray type and the new IO system are now backported to Python 2.6.
Thank you very much for this effort!
Regards,
Yay indeed! Of course the new I/O module will undergo changes (Ping is working on it still I believe). Try to keep an eye on it so the improvements can be backported.
On Wed, Mar 26, 2008 at 6:00 AM, Facundo Batista facundobatista@gmail.com wrote:
2008/3/26, Christian Heimes lists@cheimes.de:
Correct!
The bytearray type and the new IO system are now backported to Python 2.6.
Thank you very much for this effort!
Regards,
-- . Facundo
Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
Guido van Rossum schrieb:
Yay indeed! Of course the new I/O module will undergo changes (Ping is working on it still I believe). Try to keep an eye on it so the improvements can be backported.
Could somebody (perhaps me *g*) create a 3to2 fixer that removes the function annotations? IIRC I only had to remove the annotations from the io module and add a "from __future__ import print_function" to get it working correctly.
Christian
On Wed, Mar 26, 2008 at 11:58 AM, Guido van Rossum guido@python.org wrote:
Yay indeed! Of course the new I/O module will undergo changes (Ping is working on it still I believe). Try to keep an eye on it so the improvements can be backported.
So improvements to backported features will be merged into 2.6?
On Wed, Mar 26, 2008 at 6:00 AM, Facundo Batista facundobatista@gmail.com wrote:
2008/3/26, Christian Heimes lists@cheimes.de:
Correct!
The bytearray type and the new IO system are now backported to
Python 2.6.
Thank you very much for this effort!
Regards,
-- . Facundo
Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/
-- --Guido van Rossum (home page: http://www.python.org/%7Eguido/http://www.python.org/%7Eguido/ ) _______________________________________________ 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/musiccomposition%40gmail.c...
-
Benjamin Peterson -
Christian Heimes -
Facundo Batista -
Guido van Rossum