Robert Bradshaw, 25.11.2009 23:37: > On Nov 25, 2009, at 12:19 PM, Stefan Behnel wrote: >> Robert Bradshaw, 25.11.2009 19:54: >>> You can still use str in Python 3, it's >>> just that str -> char* will not happen automatically. >> Slight clarification: "str -> char* will not happen automatically" >> is also >> true for Py2. 'bytes' is the only type that automatically coerces >> from and to char*. > > So, short of a bunch of encoding code (can it be written Pyrex and > Cython compatible) there's no way to support this?
It's easy to write encoding code that works in Python, Pyrex and Cython, and if you encode your strings, it will also easily work in Py2.x and Py3. If you don't, then your code will not work well in both Py3 *and* Py2. > I'd rather this is allowed with a (runtime) TypeError in Py3 and > possibly a compile time warning than disallowed altogether. Well, I prefer disallowing it all together, because it helps users in writing correct code, even if they don't care about Py3 compatibility for now. Don't forget that typing variables as "str" doesn't magically solve all problems. Not in all cases in Py3, but certainly not in Py2. It is important to /not/ type your variables as long as you don't need to, especially for function parameters that may receive both str and unicode in Py2. Then, if you mean "bytes" in your code, write "bytes" and if you mean "unicode", write "unicode" - but don't write "str" just because you think it's text. "str" is just there so users can work with Python text strings in both Py2 and Py3 without too much hassle (so it's actually for people who care about Py3 compatibility), although the hassle is big enough already in Py2 as it requires users to deal with both "str" and "unicode" for essentially the same thing. This is much easier in Py3. Whenever you want to pass strings into C (which is the only case where this restriction /really/ matters IMHO), you have to care about the content of the string anyway, so "str" will simply not work as it is underdefined from a C level perspective. Ignoring the semantics of data will necessarily make you write fragile code. Supporting that should not be a design goal of the Cython language. I'm actually getting tired of rediscussing these things over and over again. Please come up with a valid use case where a currently unsupported automatic conversion between different string types clearly helps in writing simple and correct code. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
