[issue3460] PyUnicode_Join could perhaps be simpler

2008-08-07 Thread Antoine Pitrou
Antoine Pitrou [EMAIL PROTECTED] added the comment: I've committed the patch in r65583. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3460 ___

[issue3460] PyUnicode_Join could perhaps be simpler

2008-07-29 Thread Marc-Andre Lemburg
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

2008-07-29 Thread Antoine Pitrou
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

2008-07-29 Thread Antoine Pitrou
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

2008-07-28 Thread Antoine Pitrou
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