[Python-Dev] r62342 - python/branches/py3k/Objects/bytesobject.c

[Stefan Behnel]

Neal Norwitz wrote:
> Iteration with the dict methods (e.g., keys -> iterkeys()),
> map/zip/filter returning iterator rather than list.

That's only an optimisation, it's not functionally required. A list behaves
like an iterator in most use cases, so it's rather unlikely that Py3 code will
break in the backport because of this (and it's very unlikely that static
analysis can catch the cases where it breaks). There should be a rule to
optimise "list(map(...))" into "map(...)" and "list(x.keys())" into plain
"x.keys()" etc., but I don't think there is much more to do here.


> int -> (int, long)

Is there any case where this might be required? I don't see any reason why
back-converted Py3 code should break here. What would "long()" be needed for
in working Py3 code that "int()" doesn't provide in Py2?

Although you might have been referring to "isinstance(x, int)" in Py3?


> str -> basestring or (str, unicode)

This is an issue, although I think that Py3 is explicit enough here to make
this easy to handle by static renaming (and maybe optimising "isinstance(s,
(str, bytes))" into "..., basestring))").


> __bool__ -> __nonzero__
> exec/execfile
> input -> rawinput

Also valid issues that can be handled through renaming and static syntactic
adjustments.


> Most things that have a fixer in 2to3 would also require one in 3to2.

I think the more explicit syntax in Py3 will actually make it easier to
back-convert the code statically from 3to2 than to migrate it from 2to3.

Stefan