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 <storch...@gmail.com
<mailto:storch...@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 <http://www.avg.com>
Version: 2012.0.2242 / Virus Database: 3222/6225 - Release Date: 10/05/13
_______________________________________________
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/archive%40mail-archive.com