Hi Lisandro,
Lisandro Dalcin wrote:
> Why then cannot I have an option or compiler directive (or perhaps
> just a global option) that will make bare "abc" string literals become
> PyString in Py2 and PyUnicode in Py3?
>
> Stefan, Can you imagine any potential problem with this?
I'm still convinced that this will do more harm than good, as it will break
user code in the same way that Python 3 breaks user code. Your argument is
that a compiler directive would solve this, but that's because you know how
to handle these things and want a way to do that. Unicode is something you
have to care about to get it right, and many people do not care until they
notice they have a problem.
> Supose you construct a dict with string keys on Cython code, and that
> dict is intended to be used as a **kargs for calling some function.
> Moreover, supose you construct such dict as a literal, and the keys
> are also string literals... How can I write that in such a way that
> works both in Py2 and Py3 without duplicating code?
So far, the use case you present is the only real use case that I can see.
Risking user code breakage just for this one case sounds like a rather
large drawback.
One way to achieve what you want in current Cython (or at least a common
incarnation of this problem) is this:
kwargs = dict(argument1 = some_value, arg2 = u"test")
This will create a dict with identifiers as keys, i.e. strings that are
byte strings in Py2 and unicode strings in Py3. It will also do this
efficiently as it is transformed into a literal dict construction.
The more general case, where you build a dict step by step or add keywords
to it, is not currently efficient, but you can always do the above and then
use the resulting dict to update another dict. Given that keyword arguments
are a lot slower than positional arguments, and that dynamically
constructed sets of keyword arguments are rather rare, I doubt that this
use case is performance critical enough to change the string semantics just
to achieve a performance improvement here.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
