Robert Bradshaw wrote: > If one always wants bytes, one can do b"something." If one always > wants unicode, one can do u"something." There's currently no > (obvious, clean) way to get str.
I get your point, although to me, "get str" smells like there isn't a clean way anyway. Compared to CPython, we actually have the advantage of supporting the 'b' prefix for all Py2 versions. So you can write portable code that is explicit about this prefix. That's certainly not the case for plain Python code if you need to support Python versions before 2.6. What would be the plan for a switch then? I think if we do this now, there will be two kinds of users: those who already changed their code to explicit string semantics to adapt it to Py3, and those who didn't care (yet). I actually think that such a switch would break both kinds of user code. The first one, as it wasn't necessary before to prefix byte strings with 'b', so it most likely wasn't done, and the second one because the existing code is likely not portable anyway (so it won't break more than it already is). The second group has the advantage of not having invested time, and the first (and likely smaller) group will have to fix up their code again. I'm certainly in the first group, but I guess the second group clearly outweighs the first one. Robert and/or Lisandro, would you write up a CEP that sums up and describes the proposed semantics for C strings and unprefixed byte strings? I would want to see a couple of examples in there that show in what cases code will break or not break, what changes will be required to fix broken code up, and what the change will simplify for code migration to Py3. That would make it quite clear how big the advantage actually is. From the top of my head, I can think of docstrings, for example, where this would be helpful, and I already mentioned the keywords example. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
