[pypy-dev] Porting PyPy/rpython to Python 3

Maciej Fijalkowski fijall at gmail.com
Mon Apr 20 10:05:58 CEST 2015


Changing topic a bit.

For what is worth, my pet peeve right now is to make
pypy.tool.gdb_pypy py2/3 compatible, it would be terrific if that can
happen as a first step. This is one place where we NEED TO make this
happen and despite 2 or 3 attempts I completely failed at that. New
GDB ships with python 3 and it breaks the extension (it imports and
then it fails to work). This file is not RPython.

This is one place where we would accept the port without any
complaints (and the file has to stay 2/3 compatible for the forseable
future)

Cheers,
fijal


On Sun, Apr 19, 2015 at 7:49 PM, Ronan Lamy <ronan.lamy at gmail.com> wrote:
> Le 18/04/15 10:02, Armin Rigo a écrit :
>>
>> Hi VanL,
>>
>> On 17 April 2015 at 23:50, VanL <van.lindberg at gmail.com> wrote:
>>>
>>> I am not trying to force you (or anyone) to use Py3. I have been working
>>> on
>>> this in a private branch for a little bit, and I am happy to continue to
>>> do
>>> so. As I said earlier in the thread, I had gotten the impression that
>>> these
>>> changes would not make you or the other PyPy devs happy, so I wasn't
>>> going
>>> to submit them upstream. As I said in another place, just let me know
>>> what
>>> it is that you want; among my goals is to *not bother you all.*
>>>
>>> As for the "restricted style" - well, I don't want that either. My goal
>>> would be to move 100% over to Py3 syntax. The restricted style is just a
>>> stepping stone so that stuff wouldn't stop working during the switch.
>>
>>
>> I would imagine that a better way would be to not care about
>> restricted style at all.  If we really decide to move to Python 3,
>> then maybe we should drop 2.7 altogether and all do one sprint whose
>> goal is to fully switch to Python 3.N (both "default" and the major
>> branches open at the time).  It would be a documented move that occurs
>> at some date --- I imagine this to be in the "far future", say when
>> Python 3 is becoming dominant over Python 2.
>
>
> The "big bang model" is fine for pypy, but I don't think it works for
> rpython. We should not ask our users to upgrade all at the same time.
> Besides, it would be a good idea to let smaller and more experimental
> interpreters iron out the bugs with the transition before doing it to pypy.
> So there has to be a transition period where rpython works on 2 and 3.
>
>> As I said I'm not strictly opposed to such a move: even
>> though I think it brings us little, it might be unavoidable in the
>> long run.  At some point it would even be likely that 3rd-party users
>> of RPython would to complain seriously.
>>
>> What I'm not too sure about is the real point of starting to port some
>> things to mixed 2/3 style now, with core devs continuing to work in 2-only
>> style.  You're making a huge diff from "default", but then continuing
>> changes from us will constantly conflict, which makes maintaining the
>> branch (or fork) a horrible job.  You're likely to give up well before
>> we finally decide to switch, and then it will be easier to restart
>> from scratch anyway...
>
>
> Well, I think that the only sane way to port something as big as RPython is
> to do it incrementally - by getting tests to pass on 3 one subpackage at a
> time. The parts that are ported will have to be written in mixed 2/3 style,
> but having tests will prevent regressions in Python 3 compatibility: I don't
> see why it would be harder than maintaining compatibility with "obscure"
> platforms such as Windows.
>
> Another advantage of working incrementally is that it avoids huge diffs that
> bitrot very quickly. I'd rather see changes that are justified by some
> concrete goal (e.g. "get rpython.foo.bar to import") and touch only one or
> two subdirectories than attempts to blindly fix things everywhere.
>
>> Finally, all these general remarks don't really apply to some style
>> clean-ups you can propose pull requests for.  For example, the "remove
>> all argument tuple unpacking" pull request is fine: even if it
>> wouldn't fix all *future* tuple unpackings we're likely to re-add, it
>> will still reduce a lot the number of them left at the time of the
>> hypothetical big switch.
>
>
> +1. As an exception to what I said above, such changes are fine, provided
> that they're safe and that they could be justified on code quality grounds
> alone.
>
>
>> At least that's how I view things :-)
>>
>>
>> A bientôt,
>>
>> Armin.
>>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev


More information about the pypy-dev mailing list