[issue6213] Incremental encoder incompatibility between 2.x and py3k

STINNER Victor added the comment: > I'm not brave enough to commit it to 2.6 > (test_io in 2.6 doesn't use incremental encoders) Oh, I just remembered that I choosed to fix this issue to be able to backport #5006 to 2.6 :-) So r83199 is the incremental encoder fix for 2.6, and r83200 is the

[issue6213] Incremental encoder incompatibility between 2.x and py3k

STINNER Victor added the comment: > The patch looks ok to me Ok, commited to 2.7 (r83198). > (I suppose you have tested it) I ran test_io which does test the incremental encoders. -- I'm not brave enough to commit it to 2.6 (test_io in 2.6 doesn't use incremental encoders). -- res

[issue6213] Incremental encoder incompatibility between 2.x and py3k

Antoine Pitrou added the comment: The patch looks ok to me (I suppose you have tested it). -- versions: -Python 3.2 ___ Python tracker ___ __

[issue6213] Incremental encoder incompatibility between 2.x and py3k

STINNER Victor added the comment: Codecs are inconsistents: utf-32 has working getstate() / setstate() methods, whereas utf-8-sig and utf-16 don't (getstate() always return 0, setstate() does nothing). > Simply moving py3ks getstate/setstate implementation > over to 2.x might do the trick.

[issue6213] Incremental encoder incompatibility between 2.x and py3k

Walter Dörwald added the comment: AFAICR the difference is: 2.x may return any object in getstate(), but py3k must return a (buffered input, integer) tuple. Simply moving py3ks getstate/setstate implementation over to 2.x might do the trick. -- ___ P

[issue6213] Incremental encoder incompatibility between 2.x and py3k

Antoine Pitrou added the comment: Yes, I agree with py3k's behaviour. But it should be backported to 2.x as well. I don't know where the changes must be done so if someone else could do it it would be nice :-) (I'm backporting the py3k IO lib and I had to disable two tests because of this)

[issue6213] Incremental encoder incompatibility between 2.x and py3k

Walter Dörwald added the comment: This was done because the codec state is part of the return value of tell(). To have a reasonable return value (i.e. one with just the position itself) in as many cases as possible it makes sense to design the codec state in such a way, that the most common stat

[issue6213] Incremental encoder incompatibility between 2.x and py3k

New submission from Antoine Pitrou : The behaviour of several incremental encoders is inconsistent between 2.x and py3k. In 2.x: >>> enc = codecs.getincrementalencoder('utf-16')() >>> enc.getstate() 0 >>> enc.setstate(0) >>> enc.encode(u'abc') '\xff\xfea\x00b\x00c\x00' In py3k: >>> enc = codecs