On 1/17/07, Thomas Wouters
On 1/16/07, Jim Jewett
wrote: Other than dict.items (and .keys and .values) returning a non-list, are there any other cases where the Py3K idiom can't already be used in (or at least backported to) Py 2.x?
The aim for 2.6 should be to have all the new features that 3.0 has, as well as full backward compatibility ...
And I'm asking if there are any real barriers to this. Some people have suggested that they'll have to maintain separate code bases. So far, the closest I've seen[1] to something that can't use common-subset is wanting an iterator over a mapping.
Well, there is that bit where strings are all unicode, including all string literals and attribute names and all that.
(But note that attribute names will still be limited to ASCII.) I don't see any problems for python code there, unless you're going out of your way to care which stringlike type you get. I do see that C extensions could be trickier, though I haven't yet see anything that couldn't be handled with some relatively simple conditionally-defined macros.
And the bit where open() will be different,
This I couldn't find, unless it was the security abilities. These wouldn't bother conservative code, and could probably be backported to 2.6, or at least 2.7.
The biggest hurdle will be the unicode/string unification and the I/O system (much bigger than the dict keys/values/items change), but since those haven't been implemented yet, it's rather pointless to talk about how to handle them in 2.6.
Fair enough. [1] I did miss some introspection names, but that can be handled in python, and anyone using, rather than reinventing, inspect should be fine. -jJ