Re: [Python-Dev] PEP 393 close to pronouncement

2011-10-11 Thread M.-A. Lemburg
Victor Stinner wrote: Given that I've been working on and maintaining the Python Unicode implementation actively or by providing assistance for almost 12 years now, I've also thought about whether it's still worth the effort. Thanks for your huge work on Unicode, Marc-Andre! Thanks. I

Re: [Python-Dev] PEP 393 close to pronouncement

2011-09-28 Thread M.-A. Lemburg
Guido van Rossum wrote: Given the feedback so far, I am happy to pronounce PEP 393 as accepted. Martin, congratulations! Go ahead and mark ity as Accepted. (But please do fix up the small nits that Victor reported in his earlier message.) I've been working on feedback for the last few days,

Re: [Python-Dev] PEP 393 close to pronouncement

2011-09-28 Thread Benjamin Peterson
2011/9/28 M.-A. Lemburg m...@egenix.com: Guido van Rossum wrote: Given the feedback so far, I am happy to pronounce PEP 393 as accepted. Martin, congratulations! Go ahead and mark ity as Accepted. (But please do fix up the small nits that Victor reported in his earlier message.) I've been

Re: [Python-Dev] PEP 393 close to pronouncement

2011-09-28 Thread Martin v. Löwis
Codecs use resizing a lot. Given that PyCompactUnicodeObject does not support resizing, most decoders will have to use PyUnicodeObject and thus not benefit from the memory footprint advantages of e.g. PyASCIIObject. No, codecs have been rewritten to not use resizing. PyASCIIObject has a

Re: [Python-Dev] PEP 393 close to pronouncement

2011-09-28 Thread Victor Stinner
Resizing Codecs use resizing a lot. Given that PyCompactUnicodeObject does not support resizing, most decoders will have to use PyUnicodeObject and thus not benefit from the memory footprint advantages of e.g. PyASCIIObject. Wrong. Even if you create a string using the legacy API

Re: [Python-Dev] PEP 393 close to pronouncement

2011-09-27 Thread Martin v. Löwis
GDB Debugging Hooks It's not done yet. I can do these if need be, but IIRC you (Victor) said on #python-dev that you were already working on them. I already changed it for an earlier version of the PEP. It still needs to sort out the various compact representations. I could do them as well, so

Re: [Python-Dev] PEP 393 close to pronouncement

2011-09-27 Thread Victor Stinner
Le mardi 27 septembre 2011 00:19:02, Victor Stinner a écrit : On Windows, there is just one failure in test_configparser, I didn't investigate it yet Oh, it was a real bug in io.IncrementalNewlineDecoder. It is now fixed. Victor ___ Python-Dev

Re: [Python-Dev] PEP 393 close to pronouncement

2011-09-27 Thread Guido van Rossum
Given the feedback so far, I am happy to pronounce PEP 393 as accepted. Martin, congratulations! Go ahead and mark ity as Accepted. (But please do fix up the small nits that Victor reported in his earlier message.) -- --Guido van Rossum (python.org/~guido)

[Python-Dev] PEP 393 close to pronouncement

2011-09-26 Thread Guido van Rossum
Martin has asked me to pronounce on PEP 393, after he's updated it in response to various feedback (including mine :-). I'm currently looking very favorable on it, but I thought I'd give folks here one more chance to bring up showstoppers. So, if you have the time, please review PEP 393 and/or

Re: [Python-Dev] PEP 393 close to pronouncement

2011-09-26 Thread Victor Stinner
Hi, Le lundi 26 septembre 2011 23:00:06, Guido van Rossum a écrit : So, if you have the time, please review PEP 393 and/or play with the code (the repo is linked from the PEP's References section now). I played with the code. The full test suite pass on Linux, FreeBSD and Windows. On Windows,

Re: [Python-Dev] PEP 393 close to pronouncement

2011-09-26 Thread David Malcolm
On Tue, 2011-09-27 at 00:19 +0200, Victor Stinner wrote: Hi, Le lundi 26 septembre 2011 23:00:06, Guido van Rossum a écrit : So, if you have the time, please review PEP 393 and/or play with the code (the repo is linked from the PEP's References section now). PEP === GDB Debugging