Hi,
Robert Bradshaw wrote:
> The behavior of the module should depend mostly on the
> Cython compilation environment/flags. However, for (unmarked) string
> literals I think we should decide based on the C compilation stage.
> This makes things like hasattr much more compatible, as well as
> accepting/returning string literals objects.
The thing is that if you write
getattr(o, u"attr")
in Cython, it will work in both Py2 and Py3. However,
getattr(o, "attr")
will only work in Py2, unless you do the future import. I don't mind requiring
some effort from users to get their code ready for Py3, especially if it's
broken because of (now) wrong assumptions about byte strings and Unicode.
>>> Having Cython output Python 3 compileable C code
>>> (from current Cython/Python 2) is however a great way of enabling
>>> people
>>> to write Python 3-specific Cython code before we get to the stage
>>> where
>>> there is Python 3 syntax support in Cython itself.
>> Indeed. Furthermore, IMHO Cython support for Python 3 syntax could be
>> even extended. Python 3 does not let you to do u"abc" for an unicode
>> literal. Should we really have this restriction in Cython? Unless
>> there is a good reason, I would ask this for being accepted.
>
> +1
Yes, I wouldn't mind accepting u"abc, b"abc" and "abc" at the same time. The
meaning of the latter would depend on the future import.
>>> (BTW, can we find some standard terminology for talking about this?
>>> Something like "Cython": pyx -> c stage; then it is a c-file and not
>>> Cython, and then "C compilation": c -> executable stage.)
>> Agreed, Let's use "Cython compilation" for the pyx -> c stage, and "C
>> compilation" for the c -> so stage (or whatever extension extension
>> modules have)
>
> Works for me.
Sure.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
