On 2011-08-16, at 8:25 PM, Alex Gaynor wrote:
> Personally I think #3 is the only sane path. We *need* a Python 2 VM for the
> forseeable future. We're pretty lucky in that the JIT, GC, and all the
> honest to god complex code is totally seperate from the VM, so just
> supporting 2 Python VMs
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 ;) And pypy could be a very strong
arg
2011/8/16 Yury Selivanov :
> Re option #1, just trying to start a discussion:
>
> I know it's a hard topic, but why not to adapt python 3? Python 3 is the
> future, everybody understands and accepts that. Pypy doesn't have
> substantially good support of c-extenstions, so, let's say, numpy has
Re option #1, just trying to start a discussion:
I know it's a hard topic, but why not to adapt python 3? Python 3 is the
future, everybody understands and accepts that. Pypy doesn't have
substantially good support of c-extenstions, so, let's say, numpy has to be
rewritten anyways. RDB drive
On Tue, Aug 16, 2011 at 5:39 PM, Benjamin Peterson wrote:
> 2011/8/16 Yury Selivanov :
> > Is it possible for pypy core developers to create a high-level roadmap
> with what needs to be done and where? Should python3 be another translation
> target? Will it be required to touch rpython spec? Wh
strange, my pypy build was also done on uname -r == 3.0.0-8-generic
and i have 'linux2' as sys.platform
cpython is from distribution (ubuntu) and probably could be build with
kernel earlier than 3.0.0
2011/8/17 David Edelsohn :
> On Tue, Aug 16, 2011 at 4:20 PM, Leonardo Santagada
> wrote:
>> O
On Tue, Aug 16, 2011 at 4:20 PM, Leonardo Santagada wrote:
> On Tue, Aug 16, 2011 at 3:36 PM, Amaury Forgeot d'Arc
> wrote:
>> 2011/8/16 Reiner | chocri
>>>
>>> $ python -c 'import sys; print sys.platform'
>>> linux2
>>> $ uname -r
>>> 3.0.0-1-686-pae
>>
>> So, where is the issue?
Did you *buil
2011/8/16 Yury Selivanov :
> Is it possible for pypy core developers to create a high-level roadmap with
> what needs to be done and where? Should python3 be another translation
> target? Will it be required to touch rpython spec? What data structures
> need to be introduced? etc. I don't t
On Tue, Aug 16, 2011 at 3:36 PM, Amaury Forgeot d'Arc
wrote:
> 2011/8/16 Reiner | chocri
>>
>> $ python -c 'import sys; print sys.platform'
>> linux2
>> $ uname -r
>> 3.0.0-1-686-pae
>
> So, where is the issue?
I saw that some distros are putting in place patches to make linux 3.0
to appear to b
Is it possible for pypy core developers to create a high-level roadmap with
what needs to be done and where? Should python3 be another translation target?
Will it be required to touch rpython spec? What data structures need to be
introduced? etc. I don't think this planning will take weeks
2011/8/16 Reiner | chocri
> $ python -c 'import sys; print sys.platform'
> linux2
>
> $ uname -r
> 3.0.0-1-686-pae
>
So, where is the issue?
--
Amaury Forgeot d'Arc
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo
2011/8/16 Timur Tkachev :
> Hello,
> Guys, maybe my question had been asked numerous times, but I couldn't google
> even a remote answer to it. What are the plans of python 3 support? Please
> shed some light on this topic. Last poll in your blog regarding what's
> holding off the pypy usage & a
I'm inclined to agree: Python 3.x is important for PyPy's future.
On Tue, Aug 16, 2011 at 7:19 AM, Timur Tkachev wrote:
> Hello,
>
> Guys, maybe my question had been asked numerous times, but I couldn't
> google even a remote answer to it. What are the plans of python 3 support?
> Please shed s
Thanks Anto! Or I should say molti grazie!
I feel a little stupid. I saw that line in the documentation but I the "curl
-O' confused me. I'm an old Windows programmer so when I see a bunch of
Linux install instructions I tend to skim over them looking for something
that makes sense. In this case
2011/8/16 David Edelsohn
> It appears that the tests for 'linux2' in Python and PyPy libraries
> are broken by the appearance of Linux 3.0 kernels.
>
Yes, PyPy is consistent with CPython2.7 in this aspect :-)
By the way, does CPython work at all on linux 3.0?
what do you get with this command?
In a message of Tue, 16 Aug 2011 11:39:35 EDT, David Edelsohn writes:
>It appears that the tests for 'linux2' in Python and PyPy libraries
>are broken by the appearance of Linux 3.0 kernels.
>
>- David
Can you make a bug report about this? Things sent to the mailing list
tend to get forgotten.
L
It appears that the tests for 'linux2' in Python and PyPy libraries
are broken by the appearance of Linux 3.0 kernels.
- David
___
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
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
mak
Hello,
Guys, maybe my question had been asked numerous times, but I couldn't google
even a remote answer to it. What are the plans of python 3 support? Please
shed some light on this topic. Last poll in your blog regarding what's
holding off the pypy usage & acceptance showed that people do hav
Hi Michael,
On Tue, Aug 16, 2011 at 2:06 PM, Michael Foord wrote:
> I assume the difference is that int has an __init__ method on pypy.
No, it doesn't; the issue is that the call int.__init__("12") is not
strictly equivalent to object.__init__("12"). It is on CPython, but
that's a bit by chance
Hi David,
On Mon, Aug 15, 2011 at 6:20 PM, David Naylor wrote:
> For me the performance of datetime object's hashing is sufficient but I think
> the python code could use some performance improvements. Is my approach using
> a direct computation to type long acceptable (in principle). If so I c
On 16 August 2011 12:32, Massa, Harald Armin wrote:
> On Tue, Aug 16, 2011 at 11:59 AM, Massa, Harald Armin
>> wrote:
>> class fisch(int):
>> > ... def __init__(self, value):
>> > ... int.__init__(value)
>>
>> You probably mean "int.__init__(self, value)" here. Your code is bug
On 08/15/2011 07:12 PM, David Edelsohn wrote:
Attached is the next patch for the PPC JIT backend.
The patch adds shift-left simplified mnemonic (sldi) and a load
doubleword (load_dword) function that uses it.
I also discovered some typos in my previous patch to ppc_field.py.
Currently every PP
>
> On Tue, Aug 16, 2011 at 11:59 AM, Massa, Harald Armin
> wrote:
> class fisch(int):
> > ... def __init__(self, value):
> > ... int.__init__(value)
>
> You probably mean "int.__init__(self, value)" here. Your code is buggy :-)
>
just submitted the fix to the pyPdf author :) m
Hi,
On Tue, Aug 16, 2011 at 8:43 AM, Maciej Fijalkowski wrote:
>> Is this something I should investigate on jit-short_from_state, or
>> could we consider it a separate problem and merge jit-short_from_state
>> anyway?
>
> Personally I would consider this a separate problem.
I agree. You can mer
Hi,
On Tue, Aug 16, 2011 at 11:59 AM, Massa, Harald Armin wrote:
class fisch(int):
> ... def __init__(self, value):
> ... int.__init__(value)
You probably mean "int.__init__(self, value)" here. Your code is buggy :-)
It works on CPython anyway, which is a bit strange in my opi
cPython 2.6.6 is able to initialize subclassed int-objects from strings:
Python 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit (Intel)]
on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class fisch(int):
... def __init__(self, value):
...
27 matches
Mail list logo
