[Python-Dev] PEP 393: Flexible String Representation

["Martin v. Löwis"]

> I agree. After all, CPython is lucky to have it available. It wouldn't
> be the first time that we duplicate looping code based on the input
> type. However, like the looping code, it will also complicate all
> indexing code at runtime as it always needs to test which of the
> representations is current before it can read a character. Currently,
> all of this is a compile time decision. This will necessarily have a
> performance impact.

That's most certainly the case. That's one of the reasons to discuss
this through a PEP, rather than just coming up with a patch: if people
object to it too much because of the impact on execution speed, it may
get rejected. Of course, that would make those unhappy who complain
about the memory consumption.

This is a classical time-space-tradeoff, favoring space reduction
over time reduction.

I fully understand that the actual impact can only be observed when
an implementation is available, and applications have made a reasonable
effort to work with the implementation efficiently (or perhaps not,
which would show the impact on unmodified implementations).

This is something that works much better in PyPy: the actual string
operations are written in RPython, and the tracing JIT would generate
all versions of the code that are relevant for the different
representations (IIUC, this approach is only planned for PyPy, yet).

I hope that C macros can help reduce the maintenance burden.

Regards,
Martin