On Thu, Apr 16, 2015 at 12:40 PM, Amaury Forgeot d'Arc <amaur...@gmail.com> wrote: > > 2015-04-16 10:48 GMT+02:00 Maciej Fijalkowski <fij...@gmail.com>: >> >> > >> > 2. I am initially doing this work in a way that maintains 2/3 >> > compatibility >> > - my check before each major commit is whether I can still build pypy >> > using >> > pypy2. Would the pypy devs be willing to make building pypy be 2.7+ >> > only? >> > That way I could use __future__ imports to ease some of the porting. >> >> Generally speaking the small changes are mostly a no-brainer for us. >> RPython is already 2.7 only. However, we generally want to avoid being >> Python 3 compatible as a major barrier, so things that complicate >> stuff need to be discussed first. One thing that we need to discuss is >> how to support unicode in RPython. Unicode-everywhere is definitely a >> model we would not like to pursue, you *have to* be able to use bytes >> efficiently and all over the place in RPython. Right now unicode >> support is a bit rudimentary and I would welcome a way to structure it >> better. I'm happy to discuss this (note that automatic conversion >> between unicode and bytes in rpython is illegal anyway) > > > I think *some* conversion should be allowed, for example when the unicode is > a constant. > (maybe with a SomeAsciiString annotation) > Otherwise, do we need to rewrite all calls like `space.call_method(w_x, > "split")`? > > Another issue will be the int/long distinction.
Wait, what? You're messing two things. If you want to convert, you can always call encode/decode _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
