[pypy-dev] change of strategy for the py3k branch?

[William ML Leslie]

On 31 May 2012 04:42, Maciej Fijalkowski <fijall at gmail.com> wrote:
> On Wed, May 30, 2012 at 7:24 PM, Martijn Faassen <faassen at startifact.com>
> wrote:
>>
>> Hi there,
>>
>> Just throwing in my little bit: any change that is made that would
>> make it easier to run Python 2 and Python 3 interpretors in the same
>> process would interesting, as I'm still vaguely dreaming (nothing
>> more) of a combined interpreter that can run both Python 2 and Python
>> 3 code.
>>
>> Regards,
>>
>> Martijn
>
>
> Hi Martijn.
>
> Can you describe what sort of semantics you have in mind? Would you like to
> have two copies of builtin modules? How about namespaces? What about objects
> being passed from one interpreter to the another? Would they magically
> change or would they be "py2k dict" and "py3k dict"? If you can describe the
> semantics of a proposed beast I'm willing to answer how likely it is to
> happen

I think we already discussed this at one point, here is what I
remember getting out of it:

* Any such language integration that we do encourages people to write
pypy-only programs.  There was a question as to whether this was a
good idea.  I think someone suggested it could go further than python
2/3 and allow interaction with scheme or prolog or javascript since we
are already there.

* There probably are arguments around semantics, but any solution is
better than no solution.  This is a good topic for further research
imao.

* It is worthwhile considering the effect it has on python 3 uptake
and porting.  If pypy gave people an easy way out, it could have made
quite a mess.  I don't think this is as significant a problem now as
it has been.

And of course if you don't want to do language integration, but just
add eg a command line switch, you're not getting much out of it but
the cost is significant, it means users have to co-ordinate the
upgrades of two languages, it increases translation and testing time,
etc.

----------------------------------------

By the way, I like solution 1;  it's a bit closer to the way pypy/lang
was done.  I get the cases for moving the other languages away, but
python 3 is different because so much of the existing code can be
re-used.

-- 
William Leslie