On May 16, 2008, at 2:41 AM, Stefan Behnel wrote: > 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.
I would rather that string literals be interpreted according to the C library they're linked against. I'm also thinking about code that, say, returns string literals. I would much rather it returns str in Py2 and unicode in Py3. Note, this is not something that needs to be done to get ready for Py3--it's an assumption that unqualified string literals are the same type as python identifiers. The latter must be dependent on the version it is linked against. I was doing some playing around with str and unicode in Python, and I noticed that it will automatically convert between the two (no explicit encoding needed) as long as the data in question is pure ASCII. Is this a case for allowing string <-> char* conversions as long as the data in question is pure ASCII? - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
