[Python-Dev] [Python-3000] dict.items as attributes [Was: The bytes type]

Jim Jewett jimjjewett at gmail.com
Wed Jan 17 18:05:36 CET 2007


On 1/17/07, Thomas Wouters <thomas at python.org> wrote:
> On 1/16/07, Jim Jewett <jimjjewett at gmail.com> 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


More information about the Python-Dev mailing list