A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2012-May/119221.html below:

[Python-Dev] [Python-checkins] cpython: Issue #14687: str%tuple now uses an optimistic "unicode writer" instead of an

[Python-Dev] [Python-checkins] cpython: Issue #14687: str%tuple now uses an optimistic "unicode writer" instead of an [Python-Dev] [Python-checkins] cpython: Issue #14687: str%tuple now uses an optimistic "unicode writer" instead of anVictor Stinner victor.stinner at gmail.com
Fri May 4 00:12:06 CEST 2012
>> http://hg.python.org/cpython/rev/f1db931b93d3
>> changeset:   76730:f1db931b93d3
>> user:        Victor Stinner<victor.stinner at gmail.com>
>> date:        Thu May 03 13:10:40 2012 +0200
>> summary:
>>   Issue #14687: str%tuple now uses an optimistic "unicode writer" instead
>> of an
>> accumulator. Directly write characters into the output (don't use a
>> temporary
>> list): resize and widen the string on demand.
>
> I am curious whether these optimizations for str % tuple get applied to
> equivalent str.format(*tuple) calls or if you plan to make them do so. It
> seems to me that there could be one internal function that does the
> concatenation, with lengthening and resizing, of literal and formatted
> substrings, for both interfaces.

I just wrote a patch for str.format().
http://bugs.python.org/issue14716

The speed up is between 0% and 27%.

Victor
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4