Re: Pypy with Cython

On Thu, 3 Feb 2022 at 23:16, Greg Ewing wrote: > > On 4/02/22 5:07 am, Albert-Jan Roskam wrote: > > On Feb 3, 2022 17:01, Dan Stromberg wrote: > > > > What profiler do you recommend > > If it runs for that long, just measuring execution time should > be enough. Python comes with a "timeit

Re: Pypy with Cython

On 4/02/22 5:07 am, Albert-Jan Roskam wrote: On Feb 3, 2022 17:01, Dan Stromberg wrote: What profiler do you recommend If it runs for that long, just measuring execution time should be enough. Python comes with a "timeit" module to help with that, or you can use whatever your OS provi

Re: Pypy with Cython

On Feb 3, 2022 17:01, Dan Stromberg wrote: > The best answer to "is this slower on > Pypy" is probably to measure. > Sometimes it makes sense to rewrite C > extension modules in pure python for pypy. Hi Dan, thanks. What profiler do you recommend I normally us

Re: Pypy with Cython

The best answer to "is this slower on Pypy" is probably to measure. Sometimes it makes sense to rewrite C extension modules in pure python for pypy. On Thu, Feb 3, 2022 at 7:33 AM Albert-Jan Roskam wrote: >Hi, >I inherited a fairly large codebase that I need to port to Python 3. > Since

Re: [pypy-dev] A quick question for you!

On 18 June 2018 at 22:18, Etienne Robillard wrote: > Hi, > > Quick question: Does anyone of you know what is the effect of enabling > gc.enable() in sitecustomize.py when using PyPy? Can it reduce latency for > long-lived WSGI applications? > gc is enabled by default. you only need to use gc.ena

Re: [pypy-dev] A quick question for you!

Le 2018-06-18 à 22:47, William ML Leslie a écrit : On 18 June 2018 at 22:18, Etienne Robillard wrote: Hi, Quick question: Does anyone of you know what is the effect of enabling gc.enable() in sitecustomize.py when using PyPy? Can it reduce latency for long-lived WSGI applications? gc is en

Re: PyPy support breaking CPython compatibility?

Le 2018-01-31 à 05:21, Ned Batchelder a écrit : On 1/30/18 3:58 PM, Etienne Robillard wrote: Hi Ned, Le 2018-01-30 à 15:14, Ned Batchelder a écrit : I'm curious what you had to change for PyPy? (Unless it's a Py2/Py3 thing as Chris mentions.) Please take a look at the changesets: https:

Re: PyPy support breaking CPython compatibility?

On 1/30/18 3:58 PM, Etienne Robillard wrote: Hi Ned, Le 2018-01-30 à 15:14, Ned Batchelder a écrit : I'm curious what you had to change for PyPy? (Unless it's a Py2/Py3 thing as Chris mentions.) Please take a look at the changesets: https://bitbucket.org/tkadm30/libschevo/commits/745d1aeab

Re: PyPy support breaking CPython compatibility?

On Wed, Jan 31, 2018 at 8:15 PM, Etienne Robillard wrote: > > > Le 2018-01-30 à 16:38, Ned Batchelder a écrit : >>> >>> I'm confused by this: >>> >>> -if os.environ.get('SCHEVO_OPTIMIZE', '1') == '1': >>> +if os.environ.get('SCHEVO_OPTIMIZE', '1') == True: >>> >> I was also curious about this: whe

Re: PyPy support breaking CPython compatibility?

Le 2018-01-30 à 16:38, Ned Batchelder a écrit : I'm confused by this: -if os.environ.get('SCHEVO_OPTIMIZE', '1') == '1': +if os.environ.get('SCHEVO_OPTIMIZE', '1') == True: I was also curious about this: when does os.environ.get return anything but a string? I was probably high when I cod

Re: PyPy support breaking CPython compatibility?

On 1/30/18 4:08 PM, Chris Angelico wrote: On Wed, Jan 31, 2018 at 7:58 AM, Etienne Robillard wrote: Hi Ned, Le 2018-01-30 à 15:14, Ned Batchelder a écrit : I'm curious what you had to change for PyPy? (Unless it's a Py2/Py3 thing as Chris mentions.) Please take a look at the changesets: ht

Re: PyPy support breaking CPython compatibility?

On Wed, Jan 31, 2018 at 7:58 AM, Etienne Robillard wrote: > Hi Ned, > > > Le 2018-01-30 à 15:14, Ned Batchelder a écrit : >> >> I'm curious what you had to change for PyPy? (Unless it's a Py2/Py3 thing >> as Chris mentions.) > > > Please take a look at the changesets: > > https://bitbucket.org/tka

Re: PyPy support breaking CPython compatibility?

Hi Ned, Le 2018-01-30 à 15:14, Ned Batchelder a écrit : I'm curious what you had to change for PyPy? (Unless it's a Py2/Py3 thing as Chris mentions.) Please take a look at the changesets: https://bitbucket.org/tkadm30/libschevo/commits/745d1aeab5c6ee0d336790cf13d16f327e10c2f8 https://bitbuc

Re: PyPy support breaking CPython compatibility?

On 1/30/18 2:35 PM, Etienne Robillard wrote: Hi, I managed to patch Schevo and Durus to run under PyPy 5.9. However, I'm afraid the changes is breaking Python 2.7 compatibility. I'm curious what you had to change for PyPy? (Unless it's a Py2/Py3 thing as Chris mentions.) I'm not sure how I

Re: PyPy support breaking CPython compatibility?

Hi Chris, Le 2018-01-30 à 14:53, Chris Angelico a écrit : If you're supporting Python 3, I don't think there's any problem with saying "Python 2.7 support ceases as of Schevo v4.0, so if you need Py 2.7 use Schevo 3.x". (It's not as if the old versions will suddenly cease working or anything.)

Re: PyPy support breaking CPython compatibility?

On Wed, Jan 31, 2018 at 6:35 AM, Etienne Robillard wrote: > Hi, > > I managed to patch Schevo and Durus to run under PyPy 5.9. However, I'm > afraid the changes is breaking Python 2.7 compatibility. > > I'm not sure how I should distribute my changes to the respective projects. > > Since I decided

Re: pypy on windows much slower than linux/mac when using complex number type?

Am 23.09.16 um 21:50 schrieb Irmen de Jong: The problem boiled down to a performance issue in window's 32 bits implementation of the hypot() function (which abs(z) uses when z is a complex number type). The 64 bits windows crt lib version is much faster (on par with what is to be expected fro

Re: pypy on windows much slower than linux/mac when using complex number type?

On 20-9-2016 22:38, Irmen de Jong wrote: > Hi, > > I've stumbled across a peculiar performance issue with Pypy across some > different > platforms. It was very visible in some calculation heavy code that I wrote > that uses > Python's complex number type to calculate the well-known Mandelbrot se

Re: pypy on windows much slower than linux/mac when using complex number type?

On 21-9-2016 1:20, Chris Kaynor wrote: > > Regarding the performance decrease, it may be worthwhile to push the report > to a PyPy specific forum - a PyPy developer will probably see it here, but > you may get a faster response on a forum specific to PyPy. You're right. I don't know the best pl

Re: pypy on windows much slower than linux/mac when using complex number type?

On Tue, Sep 20, 2016 at 3:59 PM, Chris Angelico wrote: > On Wed, Sep 21, 2016 at 8:50 AM, Irmen de Jong > wrote: > >> Dunno if it's the cause or not, but you're running a 32-bit PyPy on a > >> 64-bit Windows. I could well imagine that that has some odd > >> significance. > >> > >> ChrisA > > > >

Re: pypy on windows much slower than linux/mac when using complex number type?

On Wed, Sep 21, 2016 at 8:50 AM, Irmen de Jong wrote: >> Dunno if it's the cause or not, but you're running a 32-bit PyPy on a >> 64-bit Windows. I could well imagine that that has some odd >> significance. >> >> ChrisA > > > Perhaps. Though I can't really imagine what's going on there then. The o

Re: pypy on windows much slower than linux/mac when using complex number type?

On 20-9-2016 22:43, Chris Angelico wrote: > On Wed, Sep 21, 2016 at 6:38 AM, Irmen de Jong wrote: >> Windows: 64 bits Windows 7, Intel Core 2 Quad 3.4 Ghz >> Linux: 32 bits Mint 18, Virtualbox VM on above windows machine >> Mac mini: OS X 10.11.6, Intel Core 2 Duo 2.53 Ghz >> >> The test code I

Re: pypy on windows much slower than linux/mac when using complex number type?

On Wed, Sep 21, 2016 at 6:38 AM, Irmen de Jong wrote: > Windows: 64 bits Windows 7, Intel Core 2 Quad 3.4 Ghz > Linux: 32 bits Mint 18, Virtualbox VM on above windows machine > Mac mini: OS X 10.11.6, Intel Core 2 Duo 2.53 Ghz > > The test code I've been using is here: > https://gist.github.co

Re: PyPy subprocess

On Mon, Nov 2, 2015 at 8:27 AM, LJ wrote: > Im wondering if there is a way in which I can use PyPy to solve the just > subproblems in parallel, and return to CPython for the overall routines. > You could. What you'd have would be a setup where the subprocess is utterly independent of the parent;

Re: pypy - Gurobi solver library

In a message of Tue, 29 Sep 2015 18:58:19 -0700, LJ writes: >Hi All, > >I use gurobipy to model a large scale optimization problem. Is there a way to >use pypy with the gurobipy library? Has anyone done this? > >Thanks. I don't think so. I think that gurobipy depends on having all of numpy worki

Re: PyPy-STM: first "interesting" release

On 07/08/2014 02:04 AM, Steven D'Aprano wrote: On Tue, 08 Jul 2014 09:48:08 +0100, Mark Lawrence wrote: A GIL-less Python? See http://morepypy.blogspot.co.uk/2014/07/pypy-stm-first-interesting- release.html Both Jython and IronPython are GIL-less, and have been forever. Yeah, but one requi

Re: PyPy-STM: first "interesting" release

On Tue, 08 Jul 2014 09:48:08 +0100, Mark Lawrence wrote: > A GIL-less Python? See > http://morepypy.blogspot.co.uk/2014/07/pypy-stm-first-interesting- release.html Both Jython and IronPython are GIL-less, and have been forever. -- Steven -- https://mail.python.org/mailman/listinfo/python-li

Re: PyPy updated

I tried compiling pandas on pypy 2.3 but it gave error as follows numpy/core/src/multiarray/scalarapi.c:742:16: error: 'PyUnicodeObject' has no member named 'str' uni->str[length] = 0; ^ numpy/core/src/multiarray/scalarapi.c:743:16: error: 'PyUnicodeObject' has no m

Re: pypy and ctypes

On 11/14/2013 03:13 PM, Neil Cerutti wrote: On 2013-11-14, Peter Chant wrote: Or is it that - if I keep the code as simple as possible, PyPy is about as fast as you can get? PyPy profiles your code as it runs and creates, using a just-in-time compiler, highly optimized versions of frequently

Re: pypy and ctypes

On 2013-11-14, Peter Chant wrote: > Or is it that - if I keep the code as simple as possible, PyPy > is about as fast as you can get? PyPy profiles your code as it runs and creates, using a just-in-time compiler, highly optimized versions of frequently run sections. You don't have to declare type

Re: PyPy 2.0 beta 1 released

Maciej Fijalkowski wrote 22.11.2012 12:54: > We're pleased to announce the 2.0 beta 1 release of PyPy. ... > It also supports ARM machines running Linux. ... Is it be possible to use PyPy to develop Apps for Android phones and tablets? Or will it be possible to do so in the future? Regards, Pete

Re: PyPy, is it a 1:1 replacement for CPython?

On 7/20/2012 11:52 PM, Alec Taylor wrote: ask on PyPy's list But yes, it is designed as a 1:1 replacement of CPython It is a replacement for some late 2.x versions but not, at present, for Python 3. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list

Re: PyPy, is it a 1:1 replacement for CPython?

On Fri, Jul 20, 2012 at 8:59 PM, Steven D'Aprano < [email protected]> wrote: > On Sat, 21 Jul 2012 13:35:21 +1000, Simon Cropper wrote: > > > Hi, > > > > Can you use PyPy as a direct replacement for the normal python or is it > > a specialized compiler that can only work with li

Re: PyPy, is it a 1:1 replacement for CPython?

On Sat, 21 Jul 2012 13:35:21 +1000, Simon Cropper wrote: > Hi, > > Can you use PyPy as a direct replacement for the normal python or is it > a specialized compiler that can only work with libraries that are > manipulated to operate within its constraints (if it has any). PyPy should work perfect

Re: PyPy, is it a 1:1 replacement for CPython?

ask on PyPy's list But yes, it is designed as a 1:1 replacement of CPython On Sat, Jul 21, 2012 at 1:35 PM, Simon Cropper wrote: > Hi, > > Can you use PyPy as a direct replacement for the normal python or is it a > specialized compiler that can only work with libraries that are manipulated > to

Re: PyPy and RPython

Well then, wouldn't it make sense for PyPy to use Shedskin and its definition of Restricted Python? I have heard repeatedly that PyPy RPython is very difficult to use. Then why isn't PyPy using Shedskin to compile its PyPy-Jit? Sarvi On Sep 2, 11:59 pm, John Nagle wrote: > On 9/2/2010 10:30 PM,

Re: PyPy and RPython

On 9/2/2010 10:30 PM, sarvi wrote: On Sep 2, 2:19 pm, John Nagle wrote: On 9/2/2010 1:29 AM, sarvi wrote: When I think about it these restrictions below seem a very reasonable tradeoff for performance. Yes. And I can use this for just the modules/sections that are performance critica

Re: PyPy and RPython

sarvi, 03.09.2010 07:30: It should technically be possible to allow Python to call a module written in RPython? What's "Python" here? CPython? Then likely yes. I don't see a benefit, though. It should also compile RPython to a python module.so right? Why (and how) would CPython do that? I

Re: PyPy and RPython

On Sep 2, 2:19 pm, John Nagle wrote: > On 9/2/2010 1:29 AM, sarvi wrote: > > > When I think about it these restrictions below seem a very reasonable > > tradeoff for performance. > >     Yes. > > > And I can use this for just the modules/sections that are performance > > critical. > >     Not quit

Re: PyPy and RPython

On 9/2/2010 1:29 AM, sarvi wrote: When I think about it these restrictions below seem a very reasonable tradeoff for performance. Yes. And I can use this for just the modules/sections that are performance critical. Not quite. Neither Shed Skin nor RPython let you call from restricted

Re: PyPy and RPython

When I think about it these restrictions below seem a very reasonable tradeoff for performance. And I can use this for just the modules/sections that are performance critical. Essentially, the PyPy interpreter can have a restricted mode that enforces these restriction. This will help write such RP

Re: PyPy and RPython

On 9/1/2010 10:49 AM, sarvi wrote: Is there a plan to adopt PyPy and RPython under the python foundation in attempt to standardize both. I have been watching PyPy and RPython evolve over the years. PyPy seems to have momentum and is rapidly gaining followers and performance. PyPy JIT and perf

Re: PyPy and RPython

sarvi, 02.09.2010 07:06: Look at all the alternatives we have. Cython? Shedskin? I'll take PyPy anyday instead of them Fell free to do so, but don't forget that the choice of a language always depends on the specific requirements at hand. Cython has proven its applicability in a couple of lar

Re: PyPy and RPython

On Sep 1, 6:49 pm, Benjamin Peterson wrote: > sarvi gmail.com> writes: > > Secondly I have always fantasized of never having to write C code yet > > get its compiled performance. > > With RPython(a strict subset of Python), I can actually compile it to > > C/Machine code > > RPython is not suppo

Re: PyPy and RPython

On Sep 2, 3:49 am, sarvi wrote: > Yet I see this forum relatively quite on PyPy or Rpython ?  Any > reasons??? For me, it's two major ones: 1. PyPy only recently hit a stability/performance point that makes it worth checking out, 2. Using non-pure-python modules wasn't straightforward (at least

Re: PyPy and RPython

sarvi gmail.com> writes: > > > Is there a plan to adopt PyPy and RPython under the python foundation > in attempt to standardize both. There is not. > > Secondly I have always fantasized of never having to write C code yet > get its compiled performance. > With RPython(a strict subset of Pyt

Re: pypy

> Just curious if anyone had the chance to build pypy on a 64bit > environment and to see if it really makes a huge difference in > performance. Would like to hear some thoughts (or alternatives). I'd recommend asking about this on the pypy mailing list or looking at their documentation first; see

Re: PyPy Progress (and Psyco)

Everything starts out small. I am sure that things will grow if there is a demand for it... On Mon, Mar 16, 2009 at 5:55 AM, JanC wrote: > andrew cooke wrote: > > > Fuzzyman wrote: > >> On Mar 15, 3:46 pm, Gerhard Häring wrote: > > [...] > >>> Me too. I doubt it, though. From an outside view, t

Re: PyPy Progress (and Psyco)

andrew cooke wrote: > Fuzzyman wrote: >> On Mar 15, 3:46 pm, Gerhard Häring wrote: > [...] >>> Me too. I doubt it, though. From an outside view, the project seems to >>> lack focus. To me, it looks like a research platform, and producing a >>> successor to CPython seems to be just one out of a do

Re: PyPy Progress (and Psyco)

Fuzzyman wrote: > On Mar 15, 3:46 pm, Gerhard Häring wrote: [...] >> Me too. I doubt it, though. From an outside view, the project seems to >> lack focus. To me, it looks like a research platform, and producing a >> successor to CPython seems to be just one out of a dozen projects. [...] > Well, I

Re: PyPy Progress (and Psyco)

On Mar 15, 3:46 pm, Gerhard Häring wrote: > andrew cooke wrote: > > This looks very promising - > >http://www.voidspace.org.uk/python/weblog/arch_d7_2009_03_14.shtml#e1063 > > > I am really looking forwards to PyPy having a final release.  I hope it > > happens. > > Me too. I doubt it, though. Fro

Re: PyPy Progress (and Psyco)

andrew cooke wrote: This looks very promising - http://www.voidspace.org.uk/python/weblog/arch_d7_2009_03_14.shtml#e1063 I am really looking forwards to PyPy having a final release. I hope it happens. Me too. I doubt it, though. From an outside view, the project seems to lack focus. To me, i

Re: PyPy questions

Allen schrieb: > I read the website of some information about PyPy, and how a translator > translates the RPython code to C/CLI/Java/etc to be compiled to a native > executable or something like that. Would it be possible, in PyPy, to > write such an extension that could easily be compiled to nati

Re: PyPy questions

On 1 Jul, 04:09, Allen <[EMAIL PROTECTED]> wrote: > I read the website of some information about PyPy, and how a translator > translates the RPython code to C/CLI/Java/etc to be compiled to a native > executable or something like that.  Would it be possible, in PyPy, to > write such an extension th

Re: PyPy for dummies

Cameron Laird schrieb: > In article <[EMAIL PROTECTED]>, > Paddy <[EMAIL PROTECTED]> wrote: > . > . > . >>It is also European funding for an open source project with sprints. >>I'm sure some eurocrat will be dissecting the project to

Re: PyPy 1.0: JIT compilers for free and more

In article <[EMAIL PROTECTED]>, Jarek Zgoda <[EMAIL PROTECTED]> wrote: >Carl Friedrich Bolz napisa³(a): > >> Welcome to the PyPy 1.0 release - a milestone integrating the results >> of four years of research, engineering, management and sprinting >> efforts, concluding the 28 months phase of EU co

Re: PyPy for dummies

In article <[EMAIL PROTECTED]>, Paddy <[EMAIL PROTECTED]> wrote: . . . >It is also European funding for an open source project with sprints. >I'm sure some eurocrat will be dissecting the project to see if it is >aa good way to

Re: PyPy for dummies

On Mar 30, 1:10 am, Damjan <[EMAIL PROTECTED]> wrote: > .. like me. > > Ok, this is what I understood why PyPy is important. > > Writing programing languages and implementations (compilers, interpreters, > JITs, etc) is hard. Not many people can do it from scratch and create > something comparable

Re: PyPy 1.0: JIT compilers for free and more

On Mar 28, 5:36 pm, Jarek Zgoda <[EMAIL PROTECTED]> wrote: > Carl Friedrich Bolz napisa³(a): > > > Welcome to the PyPy 1.0 release - a milestone integrating the results > > of four years of research, engineering, management and sprinting > > efforts, concluding the 28 months phase of EU co-funding!

Re: PyPy 1.0: JIT compilers for free and more

Duncan Booth wrote: > Robin Becker <[EMAIL PROTECTED]> wrote: > >> I am hugely encouraged by this >> >> C:\Python\devel\pypy-1.0.0>\python24\python \python\lib\test > \pystone.py >> Pystone(1.1) time for 5 passes = 1.49586 >> This machine benchmarks at 33425.6 pystones/second >> >> C:\Python\d

Re: PyPy 1.0: JIT compilers for free and more

On 28 mar, 23:36, Jarek Zgoda <[EMAIL PROTECTED]> wrote: > Carl Friedrich Bolz napisa³(a): > > > Welcome to the PyPy 1.0 release - a milestone integrating the results > > of four years of research, engineering, management and sprinting > > efforts, concluding the 28 months phase of EU co-funding! >

Re: PyPy 1.0: JIT compilers for free and more

Robin Becker <[EMAIL PROTECTED]> wrote: > I am hugely encouraged by this > > C:\Python\devel\pypy-1.0.0>\python24\python \python\lib\test \pystone.py > Pystone(1.1) time for 5 passes = 1.49586 > This machine benchmarks at 33425.6 pystones/second > > C:\Python\devel\pypy-1.0.0>.\pypy-c.exe \p

Re: PyPy 1.0: JIT compilers for free and more

Christian Tismer wrote: ... >> something >> special, I am unable to dream of? Or is it purely academic project to >> create Python VM in Python? > > It will eventually give you a GIL-free VM, and it already gives you > a lot more than you have dreamt of. > > There is one feature missing that

Re: PyPy 1.0: JIT compilers for free and more

On 28.03.2007, at 23:36, Jarek Zgoda wrote: > Carl Friedrich Bolz napisał(a): > >> Welcome to the PyPy 1.0 release - a milestone integrating the results >> of four years of research, engineering, management and sprinting >> efforts, concluding the 28 months phase of EU co-funding! > > So it took

Re: PyPy 1.0: JIT compilers for free and more

Kay Schluehr wrote: > Nice to read that things are going on. I've still a PyPy 0.7 version > on my notebook. I guess I will upgrade :) > > A somewhat unrelated question. With Py3K Python gets optional type > annotations. Are you already architecting an annotation handler that > can process th

Re: PyPy 1.0: JIT compilers for free and more

Carl Friedrich Bolz napisał(a): > Welcome to the PyPy 1.0 release - a milestone integrating the results > of four years of research, engineering, management and sprinting > efforts, concluding the 28 months phase of EU co-funding! So it took 4 yars of work and over 2 yaers of consumption of EU fu

Re: PyPy 1.0: JIT compilers for free and more

Hi! dmitrey wrote: > Hi! > Suppose I have a py-written module. > Is it possible somehow run PyPy on the whole module? > I didn't find it in documentation. > And if yes (or if just run in every module func) what will be after > computer restart? > Should I restart PyPy on the module once again? >

Re: PyPy 1.0: JIT compilers for free and more

Hi! Suppose I have a py-written module. Is it possible somehow run PyPy on the whole module? I didn't find it in documentation. And if yes (or if just run in every module func) what will be after computer restart? Should I restart PyPy on the module once again? And are there any chances/intends fo

Re: PyPy 1.0: JIT compilers for free and more

Kay Schluehr: > RPython is heuristically defined as a subset of Python "static enough > to be translatable to C". So it is actually static analysis that is > done here, not on a local scale but on a simpler sublanguage. It is > not clear to me whether for a sufficiently annotated Py3K program the >

Re: PyPy 1.0: JIT compilers for free and more

On Mar 28, 4:34 pm, Paul Rubin wrote: > "Kay Schluehr" <[EMAIL PROTECTED]> writes: > > A somewhat unrelated question. With Py3K Python gets optional type > > annotations. Are you already architecting an annotation handler that > > can process these annotations? This featu

Re: PyPy 1.0: JIT compilers for free and more

Hi Christian! Christian Tismer wrote: > On 28.03.2007, at 10:38, Carl Friedrich Bolz wrote: > >> Brain error on our side: the gc_pypy.dll is the dll of the Boehm >> garbage >> collector, which you would need to compile yourself (which makes >> precompiled binaries a bit useless :-) ). We update

Re: PyPy 1.0: JIT compilers for free and more

On Mar 28, 2:54 pm, "Paul Boddie" <[EMAIL PROTECTED]> wrote: > On 28 Mar, 14:12, "Kay Schluehr" <[EMAIL PROTECTED]> wrote: > > > > > A somewhat unrelated question. With Py3K Python gets optional type > > annotations. > > No, I believe the consensus is that Python 3000 gets optional > annotations wh

Re: PyPy 1.0: JIT compilers for free and more

On 28.03.2007, at 10:38, Carl Friedrich Bolz wrote: > Brain error on our side: the gc_pypy.dll is the dll of the Boehm > garbage > collector, which you would need to compile yourself (which makes > precompiled binaries a bit useless :-) ). We updated the zip file, > would > you mind checking

Re: PyPy 1.0: JIT compilers for free and more

"Kay Schluehr" <[EMAIL PROTECTED]> writes: > A somewhat unrelated question. With Py3K Python gets optional type > annotations. Are you already architecting an annotation handler that > can process these annotations? This feature is somewhat competitive to > all the complicated type inference and ji

Re: PyPy 1.0: JIT compilers for free and more

On 28 Mar, 14:12, "Kay Schluehr" <[EMAIL PROTECTED]> wrote: > > A somewhat unrelated question. With Py3K Python gets optional type > annotations. No, I believe the consensus is that Python 3000 gets optional annotations which aren't specifically for type information... nudge nudge, wink wink! That

Re: PyPy 1.0: JIT compilers for free and more

On 28 Mar, 14:12, "Kay Schluehr" <[EMAIL PROTECTED]> wrote: > > A somewhat unrelated question. With Py3K Python gets optional type > annotations. No, I believe the consensus is that Python 3000 gets optional annotations which aren't specifically for type information... nudge nudge, wink wink! That

Re: PyPy 1.0: JIT compilers for free and more

On Mar 27, 11:48 pm, Carl Friedrich Bolz <[EMAIL PROTECTED]> wrote: > == > PyPy 1.0: JIT compilers for free and more > == > > Welcome to the PyPy 1.0 release - a milestone integrating the results > of four years of rese

Re: PyPy 1.0: JIT compilers for free and more

Hi Luis! Luis M. González wrote: > Carl Friedrich Bolz wrote: >> == >> PyPy 1.0: JIT compilers for free and more >> == [snip] > > > Congratulations! Thanks :-) > I just have a couple of questions: > > Attem

Re: PyPy 1.0: JIT compilers for free and more

Carl Friedrich Bolz a écrit : > == > PyPy 1.0: JIT compilers for free and more > == > > Welcome to the PyPy 1.0 release - a milestone integrating the results > of four years of research, engineering, management and spr

Re: PyPy 1.0: JIT compilers for free and more

Carl Friedrich Bolz <[EMAIL PROTECTED]> writes: > == > PyPy 1.0: JIT compilers for free and more > == > > Welcome to the PyPy 1.0 release - a milestone integrating the > results of four years of research, engineering,

Re: PyPy 1.0: JIT compilers for free and more

Carl Friedrich Bolz wrote: > == > PyPy 1.0: JIT compilers for free and more > == > > Welcome to the PyPy 1.0 release - a milestone integrating the results > of four years of research, engineering, management and sprint

Re: PyPy 1.0: JIT compilers for free and more

Carl> Welcome to the PyPy 1.0 release... ... Carl> - A **Just-In-Time Compiler generator** able to **automatically** Carl> enhance the low level versions of our Python interpreter, Carl> leading to run-time machine code that runs algorithmic examples Carl> at speeds t

Re: PyPy with a smaller PVM for the full Python?

Casey Hawthorne wrote: > Currently PyPy is working toward compiling to C a restricted subset of > Python, called RPython. > > Would it be possible for PyPy to "compile" the full subset of Python > by also using a lot smaller version of the PVM (Python Virtual > Machine) to go with the "compiled" c

Re: PyPy with a smaller PVM for the full Python?

In <[EMAIL PROTECTED]>, Casey Hawthorne wrote: > Similarly, for JPython (which is at Python 2.2?), could one also use a > lot smaller accompanying PVM with the JPython source code and JVM to > use Python 2.5 in its entirety? Could you define "small"? I think the PVM is already quite small. Ciao

Re: PyPy and constraints

Paddy wrote: > Ziga Seilnacht wrote: > > Paddy wrote: > > > I followed the recent anouncement of version 0.9 of PyPi and found out > > > that there was work included on adding constraint satisfaction solvers > > > to PyPy: > > > http://codespeak.net/pypy/dist/pypy/doc/howto-logicobjspace-0.9.htm

Re: PyPy and constraints

Ziga Seilnacht wrote: > Paddy wrote: > > I followed the recent anouncement of version 0.9 of PyPi and found out > > that there was work included on adding constraint satisfaction solvers > > to PyPy: > > http://codespeak.net/pypy/dist/pypy/doc/howto-logicobjspace-0.9.html > > > > I was wondering

Re: PyPy and constraints

Paddy wrote: > I followed the recent anouncement of version 0.9 of PyPi and found out > that there was work included on adding constraint satisfaction solvers > to PyPy: > http://codespeak.net/pypy/dist/pypy/doc/howto-logicobjspace-0.9.html > > I was wondering if this was a possibiity for "mainst

Re: pypy-0.9.0: stackless, new extension compiler

Hi all! Michael Hudson wrote: > The PyPy development team has been busy working and we've now packaged > our latest improvements, completed work and new experiments as > version 0.9.0, our fourth public release. Unfortunately the download links for the release tarballs did not work until very

Re: pypy-0.9.0: stackless, new extension compiler

Hi all! Michael Hudson wrote: > The PyPy development team has been busy working and we've now packaged > our latest improvements, completed work and new experiments as > version 0.9.0, our fourth public release. Unfortunately the download links for the release tarballs did not work until very rec

Re: pypy-0.9.0: stackless, new extension compiler

I've been away from Usenet for a while but this is the most interesting stuff I've seen here in ages. Way cool. -- http://mail.python.org/mailman/listinfo/python-list

Re: Pypy - Which C modules still need converting to py?

Hi Caleb, On Tue, Feb 08, 2005 at 22:32 -0500, Caleb Hattingh wrote: > I saw it on a webpage a few days ago, can't seem to find it again. Tried > a google search for > > "pypy needed translate C modules" > > but that didn't turn up what I was looking for. Anyone have that page > ref hand

Re: Pypy - Which C modules still need converting to py?

Also you can browse the Pypy-Dev archives here: http://codespeak.net/pipermail/pypy-dev/ and post messages here: [email protected] regards, Luis -- http://mail.python.org/mailman/listinfo/python-list

Re: Pypy - Which C modules still need converting to py?

Caleb Hattingh wrote: Anyone have that page ref handy listing the C modules that the pypy team need translated into python? http://codespeak.net/pypy/index.cgi?doc/cmodules.html Regards, Jan -- http://mail.python.org/mailman/listinfo/python-list