Le 18/04/15 10:02, Armin Rigo a écrit :
Hi VanL,
On 17 April 2015 at 23:50, VanL <van.lindb...@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@python.org
https://mail.python.org/mailman/listinfo/pypy-dev
