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

[Armin Rigo]

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.

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...

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.

At least that's how I view things :-)


A bientôt,

Armin.