[issue3460] PyUnicode_Join could perhaps be simpler

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: I've committed the patch in r65583. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3460] PyUnicode_Join could perhaps be simpler

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Here is a patch. On my measurements it makes str.join() 30% to 50% faster on non-trivial input. -- keywords: +patch Added file: http://bugs.python.org/file11004/strjoin3k.patch ___ Python tracker <

[issue3460] PyUnicode_Join could perhaps be simpler

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Well the potentially dangerous function would have been PyUnicode_FromObject, but in py3k it only accepts unicode instances (either exact or subclasses), and since we are only interested in the underlying buffer we can replace those calls with

[issue3460] PyUnicode_Join could perhaps be simpler

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: The comment gives a wrong impression: The problem is not (only) that a codec might by evil, it's the fact that a codec may well execute Python code and thus allow the list to be changed by other threads during the operation. Now, since in

[issue3460] PyUnicode_Join could perhaps be simpler

New submission from Antoine Pitrou <[EMAIL PROTECTED]>: In py3k, PyUnicode_Join inherits some complexity from the 2.x days. However, it seems some of the precautions taken there may not be needed anymore. Witness the following comment: /* G. A codec may be invoked to convert str objects