[issue15964] SyntaxError in asdl when building 2.7 with system Python 3

Changes by Eli Bendersky : -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker ___ __

[issue19106] Prepare .hgtouch and Tools/hg/hgtouch.py to run on the bots

Eli Bendersky added the comment: I think this issue can be closed, since Martin's touch step runs on the bots successfully, and the ASDL dependencies in .hgtouch were fixed. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed __

[issue3982] support .format for bytes

Augie Fackler added the comment: Is there any chance we could just have it work for bytes, ints, and floats? That'd solve the immediate need, and it'd be obviously correct how to have those behave. Punting this to 3.5 basically means we'll have to either wait for 3.5, or do something awful li

[issue19154] AttributeError: 'NoneType' in http/client.py when using select when file descriptor is closed.

Florent Viard added the comment: Thank you for your reply. But I just realised that in my bug issue, I completely forgot to indicate what is "req" and so this is maybe the root of you telling me that the best is to fix the client code side as the traceback could be confusing. This is how is de

[issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates

Martin v. Löwis added the comment: Marc-Andre: please don't confuse "use in major operating systems" with "major use in operating systems". I agree with Antoine that UTF-16 isn't widely used on Windows, despite notepad and Office supporting it. Most users on Windows using notepad continue to

[issue19142] Cross-compile fails trying to execute foreign pgen on build host

Trevor Bowen added the comment: I thought "make touch" was only for those trying to build from the Mecurial source, as opposed to building from the released tar-ball source. I thought my efforts laid on the other side of the need for that command. If I understood wrong, when would I use it a

[issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates

Serhiy Storchaka added the comment: Here is my idea: http://permalink.gmane.org/gmane.comp.python.ideas/23521. I see that a discussion about how fast UTF-16 codec should be already larger than discussion about patches. Could you please review this not so simple patch instead? Yet one help whi

[issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates

STINNER Victor added the comment: I don't think that performances on a microbenchmark is the good question. The good question is: does Python conform to Unicode? The answer is simple and explicit: no. Encoding lone surrogates may lead to bugs and even security vulnerabilities. Please open a new

[issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates

Marc-Andre Lemburg added the comment: On 08.10.2013 12:30, Antoine Pitrou wrote: > >> UTF-8, UTF-16 and UTF-32 codecs need to be as fast as possible >> in Python to not create performance problems when converting >> between platform Unicode data and the internal formats >> used in Python. > > "

[issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates

Marc-Andre Lemburg added the comment: On 08.10.2013 11:42, Serhiy Storchaka wrote: > > UTF-16 codec still fast enough. Let first make it correct and then will try > optimize it. I have an idea how restore 3.3 performance (if it worth, the > code already complicated enough). That's a good plan

[issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates

Antoine Pitrou added the comment: > UTF-8, UTF-16 and UTF-32 codecs need to be as fast as possible > in Python to not create performance problems when converting > between platform Unicode data and the internal formats > used in Python. "As fast as possible" is a platonic dream. They only need t

[issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates

Serhiy Storchaka added the comment: I repeat myself. Even with the patch, UTF-16 codec is faster than UTF-8 codec (except ASCII-only data). This is fastest Unicode codec in Python (perhaps UTF-32 can be made faster, but this is another issue). > The real question is: Can the UTF-16/32 codecs b

[issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates

Marc-Andre Lemburg added the comment: On 08.10.2013 11:33, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> MS Notepad and MS Office save Unicode text files in UTF-16-LE, >> unless you explicitly specify UTF-8, just like many other Windows >> applications that support Unicode te

[issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates

Serhiy Storchaka added the comment: UTF-16 codec still fast enough. Let first make it correct and then will try optimize it. I have an idea how restore 3.3 performance (if it worth, the code already complicated enough). The converting to/from wchar_t* uses different code. --

[issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates

Antoine Pitrou added the comment: > MS Notepad and MS Office save Unicode text files in UTF-16-LE, > unless you explicitly specify UTF-8, just like many other Windows > applications that support Unicode text files: I'd be curious to know if people actually edit *text files* using Microsoft Word

[issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates

Marc-Andre Lemburg added the comment: On 08.10.2013 11:03, Antoine Pitrou wrote: > >>> utf-16 isn't that widely used, so it's probably fine if it becomes >>> a bit slower. >> >> It's the default encoding for Unicode text files and APIs on Windows, >> so I'd say it *is* widely used :-) > > I've

[issue19142] Cross-compile fails trying to execute foreign pgen on build host

Antoine Pitrou added the comment: Have you tried "make touch" to avoid rebuilding pgen and stuff? -- nosy: +pitrou ___ Python tracker ___

[issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates

Antoine Pitrou added the comment: > On 08.10.2013 10:46, Antoine Pitrou wrote: > > > > utf-16 isn't that widely used, so it's probably fine if it becomes > > a bit slower. > > It's the default encoding for Unicode text files and APIs on Windows, > so I'd say it *is* widely used :-) I've never

[issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates

Marc-Andre Lemburg added the comment: On 08.10.2013 10:46, Antoine Pitrou wrote: > > utf-16 isn't that widely used, so it's probably fine if it becomes a bit > slower. It's the default encoding for Unicode text files and APIs on Windows, so I'd say it *is* widely used :-) http://en.wikipedia.

[issue19190] Improve cross-references in builtins documentation.

Serhiy Storchaka added the comment: Indeed, there are false changes. Thank you Georg. Here is cleaned patch. -- Added file: http://bugs.python.org/file31998/refs.builtins_2.patch ___ Python tracker ___

[issue3982] support .format for bytes

Antoine Pitrou added the comment: > I'd like to put a nudge towards supporting the __mod__ interface on bytes - > for Mercurial this is the single biggest impediment to even getting our > testrunner working, much less starting the porting process. Given a spec hasn't been written (bytes.__mod__

[issue19158] BoundedSemaphore.release() subject to races

Antoine Pitrou added the comment: The implementation is a bit weird. Why take the lock a second time instead of simply reimplementing the release() method? (it's a 5-liner) By the way, Semaphore.acquire could probably use Condition.wait_for. -- nosy: +pitrou __

[issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates

Antoine Pitrou added the comment: utf-16 isn't that widely used, so it's probably fine if it becomes a bit slower. -- nosy: +pitrou ___ Python tracker ___ ___

[issue19186] expat symbols should be namespaced in pyexpat again

Changes by Antoine Pitrou : -- priority: normal -> critical ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue19187] Use a set for interned strings

Antoine Pitrou added the comment: I agree the benefit is likely to be small and very minor. Victor has experience measuring memory consumption of various programs, I would like to know about his measurements. -- ___ Python tracker

[issue19187] Use a set for interned strings

Changes by Raymond Hettinger : Added file: http://bugs.python.org/file31997/set_intern2.diff ___ Python tracker ___ ___ Python-bugs-list maili

[issue19171] pow() improvement on longs

Mark Dickinson added the comment: > It would be crazy to not apply this little fix-up. Crazy? How so? Note that this change, while introducing a performance enhancement in some rather unlikely corner cases, also introduces a performance regression in some other unlikely corner cases: Before

[issue19187] Use a set for interned strings

Changes by Raymond Hettinger : Removed file: http://bugs.python.org/file31996/set_intern1.diff ___ Python tracker ___ ___ Python-bugs-list mai

[issue19171] pow() improvement on longs

Raymond Hettinger added the comment: > I thought 2.7 (and 3.3, for that matter) was in bugfix mode only? It would be crazy to not apply this little fix-up. -- nosy: +rhettinger ___ Python tracker _

[issue19171] pow() improvement on longs

Mark Dickinson added the comment: Hmm. I thought 2.7 (and 3.3, for that matter) was in bugfix mode only? -- ___ Python tracker ___ __

[issue19187] Use a set for interned strings

Changes by Raymond Hettinger : Added file: http://bugs.python.org/file31996/set_intern1.diff ___ Python tracker ___ ___ Python-bugs-list maili

<    1   2