Hey,
On 12/08/2011 11:35 AM, Alex Gaynor wrote:
I don't think it can, or should be done, here's why: Say you have a
Python 2 dictionary {"a": 3}, and you pass this over to py3k land, what
does it become? Logically it becomes a {b"a": 3}, two problems: a) it
now has bytes for keys, which means you can't use it as a **kwargs, b)
internally ints have a totally different representation, since there's
now only a unified long type (this one doesn't apply to pypy as much,
just throwing it out there for completeness). Python 2 fundamentally
does the string type wrong, it's both the general string type for
everythign, as well as the byte sequence, the result is no program has
enough semantic knowledge to know what you mean by a string when you
pass it over hte py3k boundary.
You could come up with a rule for that amended by some annotations. If
you get a Python 2 string type, that'd be bytes in Python 3. Unless
there's some form of annotation somewhere (handwave) that says otherwise
to the proxying layer.
Many Python 2 APIs do unicode fairly well actually. There is still a
problematic situation if the API returns a str type if the content is
plain ascii: elementtree does this for instance, but no problem passing
in unicode objects from Python 3. In that case I guess the only hope is
some kind of annotation system. It'd be like a native language binding
problem: the problem would probably be less big than usual given that
the languages are very similar.
Regards,
Martijn
_______________________________________________
pypy-dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/pypy-dev
