Lisandro Dalcin, 26.08.2010 15:30: > On 26 August 2010 00:55, Stefan Behnel wrote: >> Lisandro Dalcin, 25.08.2010 22:26: >>> On 25 August 2010 17:09, Stefan Behnel wrote: >>>> Having it work >>>> on .pyx files is IMHO a nice feature that allows users to write their >>>> Cython code with the simpler Py3 syntax and semantics, but I doubt that it >>>> will be interesting for existing code, so the above can't currently break >>>> anything. >>> >>> What about people wanting to use Py3 syntax and semantics for pyx >>> files, but still need to support Python 2 runtimes? >> >> Are we talking about concrete problems here? > > My concrete problem is that many API's out there do accept 'str', but > fail to accept 'unicode'. The 'array' module is an instance of such > API's.
Well, too bad. Then don't use unicode strings in your code when talking to them, or don't use the -3 option. > I still think that we should provide a mechanism (likely a compiler > directive, off by default) to run -3 but use the behavior of -2 for > byte/str/unicode handling (that is, the 'str' type and bare "abc" > string literals are PyString in Py2 and PyUnicode in Py3)... As it was > suggested, we could even restrict this feature to string literals in > the ASCII range. I keep reading "give me a compiler option, off by default" for string proposals over and over. "off by default" is not an excuse for bad design, or for blowing up the size of the language. Cython is not Perl. There *are* incompatibilities between Python 2 and Python 3 that Cython cannot hide. Accept that. It's not always easy to write portable code. If you write a literal in your code, Cython should interpret it in an easy to predict way. Adding options all over the place will make source code harder to read. How many options do you need to create the language "Python 3, except for feature A,B,C"? If you put a couple of compiler directives on the top of your file in order to tweak the language into your language, you have to remember them at any place in the file in order to understand that language. Cython is not C either. Preprocessors and global state are evil, not only for programs, but also for their human readers. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
