Re: [pypy-dev] python 3

[Dan Stromberg]

On Wed, Aug 17, 2011 at 5:13 PM, Eli Stevens (Gmail)
wrote:

> On Wed, Aug 17, 2011 at 4:01 PM, Yury Selivanov 
> wrote:
> > +1 to the question.  Why can't it be that way?
>
> If by "that way" you mean "leave python 2.x behind post 1.6" I'd like
> to note that IMO pypy has been under-acknowledged by the wider python
> community for a very long time.  That's finally starting to change
> (pypy production releases, cpython devs devoting resources to make
> alternate implementations not second-class citizens, etc.), but by
> abandoning the segment of the language with the largest userbase, the
> project would go back to niche status again.  Yeah, doing so might
> position pypy well to become the default python 3 implementation, but
> I find it hard to imagine that tacking on another N years until pypy
> is a significant percentage of python deployments is going to be good
> for the project.
>

There's a large difference between "Abandoning 2.x" and "Starting the ball
rolling toward 3.x in a timely manner".  If anything, not having a plan for
the move to 3.x is more likely to sideline the PyPy project.

BTW, a lot of sites use software that'll ask you which branches you want to
check each of your changesets into - IOW, click two buttons and your checkin
could go to 2.x and 3.x.  I don't know if there's anything free for
Mercurial like that.
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev

Re: [pypy-dev] python 3

[Eli Stevens (Gmail)]

On Wed, Aug 17, 2011 at 4:01 PM, Yury Selivanov  wrote:
> +1 to the question.  Why can't it be that way?

If by "that way" you mean "leave python 2.x behind post 1.6" I'd like
to note that IMO pypy has been under-acknowledged by the wider python
community for a very long time.  That's finally starting to change
(pypy production releases, cpython devs devoting resources to make
alternate implementations not second-class citizens, etc.), but by
abandoning the segment of the language with the largest userbase, the
project would go back to niche status again.  Yeah, doing so might
position pypy well to become the default python 3 implementation, but
I find it hard to imagine that tacking on another N years until pypy
is a significant percentage of python deployments is going to be good
for the project.

My $0.02,
Eli
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev

Re: [pypy-dev] python 3

[Yury Selivanov]

+1 to the question.  Why can't it be that way?

On 2011-08-17, at 2:30 PM, Miquel Torres wrote:

> @Armin
>> This would remain as a branch for the foreseeable future though,
>> because we still need a Python 2 interpreter, if only to run our own
>> translation toolchain on (and not suffer the 2.5x slow-down of running
>> it on CPython 2.x).
> I don't quite follow. Switching to Python 3 (I am not saying that
> would be a good idea, just clarifying) and release as, let's say, PyPy
> 2.0, doesn't mean that the impending 1.6 release would go away. Python
> 3 users would use PyPy 2.0+, while users of Python 2.7 would use PyPy
> 1.6. You would still be able to compile PyPy and its Python 2.7
> toolchain with PyPy 1.6, thus getting the 2.5x speed up.
> 
> Python 2.7 users would only miss on newer, faster PyPy releases, which
> is not the black and white picture some where describing. The only
> condition needed for this scenario to come about are continued
> availability of PyPy 1.6 packages and important bug fixes.
> 
> That said, 1.6 is probably not the right point for Python 2.x
> end-of-line, but maybe after 1.7 things will look differently...
> 
> Cheers,
> Miquel
> 
> 
> 2011/8/17 Brian Bouterse :
>> I'm assuming it was a joke.
>> A huge amount of people today and likely over the next few years will
>> continue to rely on python 2.x where x (6,7).  Let's not downplay the
>> importance of PyPy supporting those communities.  I agree with you
>> Jean-Paul, Python 2 support in PyPy harms nothing.
>> Brian
>> 
>> On Wed, Aug 17, 2011 at 9:04 AM,  wrote:
>>> 
>>> On 02:54 am, yselivanov...@gmail.com wrote:
 
 Yes, but that is kind of a weak argument, since the situation with python
 3 changes quickly.  More and more libraries are being ported each month.
  Supporting python 2 obviously just harms the python ecosystem, as nobody
 interested in having two languages ;)
>>> 
>>> I don't understand what the wink is for.  Hopefully it means that's just a
>>> joke?  Because that's what it sounds like - support for Python 2 in PyPy
>>> harms nothing.
>>> 
>>> Jean-Paul
>>> ___
>>> pypy-dev mailing list
>>> pypy-dev@python.org
>>> http://mail.python.org/mailman/listinfo/pypy-dev
>> 
>> 
>> 
>> --
>> Brian Bouterse
>> ITng Services
>> 
>> ___
>> pypy-dev mailing list
>> pypy-dev@python.org
>> http://mail.python.org/mailman/listinfo/pypy-dev
>> 
>> 
> ___
> pypy-dev mailing list
> pypy-dev@python.org
> http://mail.python.org/mailman/listinfo/pypy-dev

___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev

Re: [pypy-dev] 1.6 status report

[Gabriel Lavoie]

Hum... It seems it's the end of my FreeBSD buildslave. :( I don't know when
it time the memory requirement jumped to over 4GB (Armin told me it was now
around 4.5GB for 64bits). I've been able to build a JIT enabled pypy binary
using Python and GCC 4.6 but it took over 10 hours. I'm unable to do the
same process using pypy to translate as its only swapping...

Gabriel

2011/8/16 Gabriel Lavoie 

> I'm on 7.4-STABLE. Anyway, as I understand, FreeBSD will never upgrade its
> core GCC version higher than 4.2.2 due to GPL version switch to GPLv3...
> Knowing there is an issue with GCC 4.2, I'll finish my testing with the
> latest GCC available from ports and I'll report. It might be a good idea to
> make a newer GCC version a requirement in your PyPy port. A better idea
> would be to create "officials" PyPy build (probably just with the jit
> default setup, 32bits and 64bits) and make a port that would install the
> binary package instead of translating the source code, since translation has
> a lot of requirements (including hardware) and takes a lot of time.
>
>
> Gabriel
>
> 2011/8/16 David Naylor 
>
>> I was not aware of that.  If you are on FreeBSD-current then clang is
>> also available (and is also in ports).  clang however takes much longer
>> to compile than gcc but can easily be run in parallel whereas gcc
>> used too much memory to allow that.
>>
>> On 16 August 2011 08:10, Gabriel Lavoie  wrote:
>> > Okay! It seems I've hit the GCC 4.2 memory usage bug:
>> > https://bugs.launchpad.net/ubuntu/+source/gcc-4.2/+bug/187391
>> > http://comments.gmane.org/gmane.comp.python.pypy/7634
>> >
>> > I'm now trying to build with GCC 4.6 (a port is available) and I'll
>> report
>> > back.
>> >
>> > Gabriel
>> >
>> > 2011/8/16 David Naylor 
>> >>
>> >> On Tuesday, 16 August 2011 05:50:18 Gabriel Lavoie wrote:
>> >> > Hi David,
>> >> >  I took a look at your port and it looks good! The patch you made
>> >> > for
>> >> > SANDBOX should probably not be needed, with a fix upstream. It seems
>> >> > PyPy
>> >> > still have a few "hardcoded path" issues that need to be looked at
>> for
>> >> > FreeBSD (and probably for Darwin too for tools like Darwin Ports). I
>> >> > felt
>> >> > on one of those issues this morning with "expat.h" and "libexpat.so".
>> >> > The
>> >> > translation process didn't look at /usr/local/include and
>> /usr/local/lib
>> >> > to find them. Actually, there are a few places where the
>> >> > "pypy/translator/platform" module should be use to find include/lib
>> >> > paths.
>> >> > I made the initial "freebsd.py" file in there that contains "general"
>> >> > references to include/lib directories in "/usr/local".
>> >>
>> >> Thanks, sandbox has not been tested as I do not know how to.  An
>> example
>> >> script that makes sandbox behave like a normal python/pypy instance
>> would
>> >> be
>> >> nice...
>> >>
>> >> On the expat issue:
>> >> # ldd `which pypy1.5`
>> >> /usr/local/bin/pypy1.5:
>> >>libm.so.5 => /lib/libm.so.5 (0x801664000)
>> >>libintl.so.9 => /usr/local/lib/libintl.so.9 (0x801885000)
>> >>libssl.so.6 => /usr/lib/libssl.so.6 (0x801a8e000)
>> >>libcrypto.so.6 => /lib/libcrypto.so.6 (0x801ce1000)
>> >>libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x802082000)
>> >>libbz2.so.4 => /usr/lib/libbz2.so.4 (0x8022a5000)
>> >>libz.so.6 => /lib/libz.so.6 (0x8024b5000)
>> >>librt.so.1 => /usr/lib/librt.so.1 (0x8026cb000)
>> >>libutil.so.9 => /lib/libutil.so.9 (0x8028d)
>> >>libffi.so.5 => /usr/local/lib/libffi.so.5 (0x802ae1000)
>> >>libncurses.so.8 => /lib/libncurses.so.8 (0x802ce7000)
>> >>libcrypt.so.5 => /lib/libcrypt.so.5 (0x802f34000)
>> >>libthr.so.3 => /lib/libthr.so.3 (0x803154000)
>> >>libc.so.7 => /lib/libc.so.7 (0x803377000)
>> >>libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x8036bf000)
>> >>
>> >> I also see those error yet it appears expat is picked up somehow, maybe
>> as
>> >> a
>> >> depenendency?
>> >>
>> >> > About my current issue, maybe you've seen it. When I try to build
>> PyPy
>> >> > using CPython, I get a "Broken Pipe" error and the process fails
>> (using
>> >> > the standard "python translate.py -O2" command). Have you seen this
>> >> > problem recently? I'm trying with the latest trunk. It seems the
>> >> > "python"
>> >> > process runs out of memory as I have this in my kernel log:
>> >>
>> >> I have not encountered that problem before (except I suffer from
>> ENOMEM).
>> >>
>> >> > swap_pager_getswapspace(16): failed
>> >> > pid 15107 (cc1), uid 1001, was killed: out of swap space
>> >> > swap_pager: out of swap space
>> >> > swap_pager_getswapspace(2): failed
>> >> > pid 37981 (python), uid 1001, was killed: out of swap space
>> >>
>> >> I have seen this problem before.  FreeBSD hard codes the size of swap
>> it
>> >> can
>> >> access, and does not adapt it based on RAM or active swap.  To fix that
>> >> try
>> >> the following in /bo

Re: [pypy-dev] python 3

[Miquel Torres]

@Armin
> This would remain as a branch for the foreseeable future though,
> because we still need a Python 2 interpreter, if only to run our own
> translation toolchain on (and not suffer the 2.5x slow-down of running
> it on CPython 2.x).
I don't quite follow. Switching to Python 3 (I am not saying that
would be a good idea, just clarifying) and release as, let's say, PyPy
2.0, doesn't mean that the impending 1.6 release would go away. Python
3 users would use PyPy 2.0+, while users of Python 2.7 would use PyPy
1.6. You would still be able to compile PyPy and its Python 2.7
toolchain with PyPy 1.6, thus getting the 2.5x speed up.

Python 2.7 users would only miss on newer, faster PyPy releases, which
is not the black and white picture some where describing. The only
condition needed for this scenario to come about are continued
availability of PyPy 1.6 packages and important bug fixes.

That said, 1.6 is probably not the right point for Python 2.x
end-of-line, but maybe after 1.7 things will look differently...

Cheers,
Miquel


2011/8/17 Brian Bouterse :
> I'm assuming it was a joke.
> A huge amount of people today and likely over the next few years will
> continue to rely on python 2.x where x (6,7).  Let's not downplay the
> importance of PyPy supporting those communities.  I agree with you
> Jean-Paul, Python 2 support in PyPy harms nothing.
> Brian
>
> On Wed, Aug 17, 2011 at 9:04 AM,  wrote:
>>
>> On 02:54 am, yselivanov...@gmail.com wrote:
>>>
>>> Yes, but that is kind of a weak argument, since the situation with python
>>> 3 changes quickly.  More and more libraries are being ported each month.
>>>  Supporting python 2 obviously just harms the python ecosystem, as nobody
>>> interested in having two languages ;)
>>
>> I don't understand what the wink is for.  Hopefully it means that's just a
>> joke?  Because that's what it sounds like - support for Python 2 in PyPy
>> harms nothing.
>>
>> Jean-Paul
>> ___
>> pypy-dev mailing list
>> pypy-dev@python.org
>> http://mail.python.org/mailman/listinfo/pypy-dev
>
>
>
> --
> Brian Bouterse
> ITng Services
>
> ___
> pypy-dev mailing list
> pypy-dev@python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>
>
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev

Re: [pypy-dev] python 3

[Brian Bouterse]

I'm assuming it was a joke.

A huge amount of people today and likely over the next few years will
continue to rely on python 2.x where x (6,7).  Let's not downplay the
importance of PyPy supporting those communities.  I agree with you
Jean-Paul, Python 2 support in PyPy harms nothing.

Brian

On Wed, Aug 17, 2011 at 9:04 AM,  wrote:

> On 02:54 am, yselivanov...@gmail.com wrote:
>
>> Yes, but that is kind of a weak argument, since the situation with python
>> 3 changes quickly.  More and more libraries are being ported each month.
>>  Supporting python 2 obviously just harms the python ecosystem, as nobody
>> interested in having two languages ;)
>>
>
> I don't understand what the wink is for.  Hopefully it means that's just a
> joke?  Because that's what it sounds like - support for Python 2 in PyPy
> harms nothing.
>
> Jean-Paul
>
> __**_
> pypy-dev mailing list
> pypy-dev@python.org
> http://mail.python.org/**mailman/listinfo/pypy-dev
>



-- 
Brian Bouterse
ITng Services
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev

Re: [pypy-dev] python 3

[exarkun]

On 02:54 am, yselivanov...@gmail.com wrote:
Yes, but that is kind of a weak argument, since the situation with 
python 3 changes quickly.  More and more libraries are being ported 
each month.  Supporting python 2 obviously just harms the python 
ecosystem, as nobody interested in having two languages ;)


I don't understand what the wink is for.  Hopefully it means that's just 
a joke?  Because that's what it sounds like - support for Python 2 in 
PyPy harms nothing.


Jean-Paul
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev

Re: [pypy-dev] python 3

[Armin Rigo]

Hi Yury,

On Wed, Aug 17, 2011 at 5:01 AM, Yury Selivanov  wrote:
> Well, if everybody agrees on the 3rd option, then can we have at least the 
> process of porting outlined and reviewed by core devs?  No need for a 
> super-detailed PEP, though.  A simple guideline would help a lot.

Yes, I think it's the only workable solution.  I suppose that what
will happen is that some sub-group of people starts the python3 branch
and keeps working on making a Python 3 interpreter (written in Python
2.x, for x in (6, 7)).  With regular merges from the trunk it should
be doable.  It is exactly how the 2.7 branch was done, at a time where
we supported only 2.5.

This would remain as a branch for the foreseeable future though,
because we still need a Python 2 interpreter, if only to run our own
translation toolchain on (and not suffer the 2.5x slow-down of running
it on CPython 2.x).  But at some later point we can think about
switching the whole code base of the translation toolchain to Python
3, which I also regard as quite some work --- but it will likely have
to be done some day.  Once this is done we can drop Python 2 entirely
and use the Python 3 branch as trunk.


A bientôt,

Armin.
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev