How to organize the py3k branch (was: [pypy-commit] pypy py3k: Remove print statement)
Hi Amaury, hi all, On 12/10/11 22:23, amauryfa wrote:
Author: Amaury Forgeot d'Arc<amauryfa@gmail.com> Branch: py3k Changeset: r47978:36b998dd9966 Date: 2011-10-12 01:52 +0200 http://bitbucket.org/pypy/pypy/changeset/36b998dd9966/
Log: Remove print statement
uhm... I thought that the idea was to have support for python 2 and 3 from the same codebase, while from your commits it seems that your are actually destryoing support for python 2. I think that there are several possible ways to organize the source code, each one with pros and cons. Maybe we should organize an IRC meeting with the interested people to decide which direction to follow? I.e., a list of possibilities (everyone feels free to add more): - have a branch where we have *only* python3, and rely on hg merge to get the improvements to the translator (which is what you are doing right now, I think). It's easier to write, but then it might be hard to keep in sync with the default branch - support for py2 and py3 in the same branch, with minimal duplication of code. This would mean that e.g. in ast.py you would have tons of "if py2: enable_print_stmt()", etc. Personally, I think that the codebase would become too cluttered. - support for py2 and py3 in the same branch, with some duplication of code; e.g., we could copy the existing interpreter/ into interpreter/py3k and modify it there. While we are at it, we should try hard to minimize the code duplication, but then it's up to us to decide when it's better to duplicate or when it's better to share the code between the twos. - other? ciao, Anto
Hi Amaury,
r47983 be8493f31b60 py3k | amauryfa | 2011-10-12 22:19 +0200
pypy/module/sys/system.py pypy/module/sys/version.py pypy/module/sys/vm.py
Fix some metaclasses, and the sys module can now be imported
Please wait a second before doing all these changes. You are changing the RPython code to be Python 3. Doing so is Yet Another option that we never really discussed so far: moving RPython to be "RPython 3". I suppose that, by now, we should really consider this as another possible option too; but we must definitely consider what it implies. It seems to imply changing the whole of PyPy (including the whole translation toolchain) to be Python 3. But we cannot drop the Python 2 version. So it seems to me that we'll end up with two versions of the whole translation toolchain (and I'll leave you the merging pains). That sounds bad. A bientôt, Armin.
Re-Hi, On Thu, Oct 13, 2011 at 11:43, Armin Rigo <arigo@tunes.org> wrote:
Please wait a second before doing all these changes. You are changing the RPython code to be Python 3.
Ah, sorry. Carl Friedrich pointed out that it also works in Python 2.7. Are you actually fixing the RPython code of the PyPy interpreter to work both on Python 2.7 and in Python 3.x? (Looks like a pain too, but a more bearable one.) A bientôt, Armin.
2011/10/13 Armin Rigo <arigo@tunes.org>:
r47983 be8493f31b60 py3k | amauryfa | 2011-10-12 22:19 +0200
pypy/module/sys/system.py pypy/module/sys/version.py pypy/module/sys/vm.py
Fix some metaclasses, and the sys module can now be imported
Please wait a second before doing all these changes. You are changing the RPython code to be Python 3. Doing so is Yet Another option that we never really discussed so far: moving RPython to be "RPython 3". I suppose that, by now, we should really consider this as another possible option too; but we must definitely consider what it implies.
All these changes occur in strings that start with app = gateway.applevel(''' "NOT_RPYTHON" This code is not RPython, and is processed by the new compiler. Normally, the host python should not see this code. Anyway, I run cpython2.6 for my tests, which does not allow this new metaclass syntax. I agree that RPython should stay at version 2.x for the near future. For example, space.wrap("hello") takes a 8bit string and produces a W_Unicode... Thanks for looking at all this! -- Amaury Forgeot d'Arc
Hi Amaury, On 13/10/11 16:37, Amaury Forgeot d'Arc wrote:
All these changes occur in strings that start with app = gateway.applevel(''' "NOT_RPYTHON"
This code is not RPython, and is processed by the new compiler. Normally, the host python should not see this code.
Anyway, I run cpython2.6 for my tests, which does not allow this new metaclass syntax.
I agree that RPython should stay at version 2.x for the near future. For example, space.wrap("hello") takes a 8bit string and produces a W_Unicode...
Thanks for looking at all this!
that's true, but from the commits I saw it seems that you are destroying support for the Python 2 interpreter anyway. Is it correct? I renew my suggestion of having a meeting where to decide which strategy to follow. Who would like to participate at the meeting? ciao, Anto
Hi, 2011/10/14 Antonio Cuni <anto.cuni@gmail.com>
that's true, but from the commits I saw it seems that you are destroying support for the Python 2 interpreter anyway. Is it correct?
Yes, that's true. It seemed to me that supporting both versions in the same files would be too much of a hassle. I'd prefer regularly merge branches, conflicts should be limited since the 2.7 version won't grow new Python features. But we could revisit this, I just would like to avoid tons of #ifdef around the changes...
I renew my suggestion of having a meeting where to decide which strategy to follow.
Unfortunately I'm travelling early this afternoon, and I'm not sure to have a connection during the week-end. It will be easier next week, for example around 17:00 CEST. -- Amaury Forgeot d'Arc
Hi, On 14/10/11 14:07, Amaury Forgeot d'Arc wrote:
Yes, that's true. It seemed to me that supporting both versions in the same files would be too much of a hassle. I'd prefer regularly merge branches, conflicts should be limited since the 2.7 version won't grow new Python features.
yes, I see the point. I'm not saying that this is the wrong approach, just that it's probably better to think a bit about it and decide which direction to follow.
But we could revisit this, I just would like to avoid tons of #ifdef around the changes...
I agree with you that having tons of #ifdef should be avoided.
Unfortunately I'm travelling early this afternoon, and I'm not sure to have a connection during the week-end. It will be easier next week, for example around 17:00 CEST.
what about monday at 17:00 CEST?
On Fri, Oct 14, 2011 at 4:54 PM, Antonio Cuni <anto.cuni@gmail.com> wrote:
Hi,
On 14/10/11 14:07, Amaury Forgeot d'Arc wrote:
Yes, that's true. It seemed to me that supporting both versions in the same files would be too much of a hassle. I'd prefer regularly merge branches, conflicts should be limited since the 2.7 version won't grow new Python features.
yes, I see the point. I'm not saying that this is the wrong approach, just that it's probably better to think a bit about it and decide which direction to follow.
But we could revisit this, I just would like to avoid tons of #ifdef around the changes...
I agree with you that having tons of #ifdef should be avoided.
Unfortunately I'm travelling early this afternoon, and I'm not sure to have a connection during the week-end. It will be easier next week, for example around 17:00 CEST.
what about monday at 17:00 CEST?
If you want me there it has to be later (preferably after 7pm)
_______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
On 13 October 2011 19:55, Antonio Cuni <anto.cuni@gmail.com> wrote:
- support for py2 and py3 in the same branch, with minimal duplication of code. This would mean that e.g. in ast.py you would have tons of "if py2: enable_print_stmt()", etc. Personally, I think that the codebase would become too cluttered.
In order to support __future__.print_function, you already need this case. Do we have a good idea of where we expect the biggest divergence? Is it things that now return iterables or views, or is it IO? Is it new-style defaults, or unicode field names?
- support for py2 and py3 in the same branch, with some duplication of code; e.g., we could copy the existing interpreter/ into interpreter/py3k and modify it there. While we are at it, we should try hard to minimize the code duplication, but then it's up to us to decide when it's better to duplicate or when it's better to share the code between the twos.
An adaptive approach sounds very sensible. -- William Leslie
participants (5)
-
Amaury Forgeot d'Arc -
Antonio Cuni -
Armin Rigo -
Maciej Fijalkowski -
William ML Leslie