(original) (raw)

Sorry, I may have missed some earlier relevant parts of this discussion.
But you appear to be saying that you don't want to optimize something because it would be hard to explain why it performed better.
Eh?? Have I misunderstood?
Rob Cliffe

On 05/10/2013 23:35, Raymond Hettinger wrote:

On Oct 5, 2013, at 12:42 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:

Please remember me, what was common decision about CPython-only optimizations which change computation complexity?

IIRC, it is okay optimize C code for just about anything, but we don't

want to alter the pure python code after from idiomatic solutions that

work on all of the implementations.

For example, there is a string concatenation optimization

in the C code, but we still use and advocate str.join()

and try not to write code that relies on the optimization.

That said, it is nice that less informed users are sometimes

saved from an accidental performance trap.

Making bytearray's efficiently pop from the left side is dubious.

This isn't a common idiom, nor should it be. Even if all the

other implementations could model this behavior, it wouldn't

be a good idea to have bytearrays have different performance

characteristics than strings. Right now, it is not too hard to

roughly explain the performance characteristics of the various

container objects, but that would be imperiled a bit by having

bytearrays differing from strings in ways other than their size.

Raymond
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
Python-Dev mailing list  
Python-Dev@python.org  
https://mail.python.org/mailman/listinfo/python-dev  
Unsubscribe: https://mail.python.org/mailman/options/python-dev/rob.cliffe%40btinternet.com  
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2242 / Virus Database: 3222/6225 - Release Date: 10/05/13