Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PyPy 1.6 Released - Full Python 2.7.1 Implementation

morepypy.blogspot.com

Post reply on HN
Print view View original

51–57 of 57 posts

Re: PyPy 1.6 Released - Full Python 2.7.1 Implementation

#51

Post by sqrt17 »

nickik wrote: post #49
sqrt17 wrote: post #45

Earlier quoted context omitted.

* Jython is a really nice alternative if you want to use Python-the-language in a Java environment. Its suboptimal speed and the fact that it's really easy to write Java code that can be used from Jython means that you'll probably use it more as a scripting language * The relation between IronPython and .NET is probably very similar * For CPython, people have always wrapped their favorite C library and started using…

Thats the problem all scripting languages have. They start slow, then people want to be faster and start writting C code and that makes it really really hard to have alternativ implementations. The guy implmenting Erjang had the same problem he had to rewrite alot of C functions in Java. I think the python comunity should recognisse what an awesome technolagy pypy is and start making an widespreed effort and discurag…

Rewriting things in C, or Cython, also makes things much, much faster, without the hassle of PyPy. And because you can do your own memory management (in the places where it makes sense), Cython code is quite a lot better for well-defined numerical applications than what you can get out of a GC-based environment.

Realistically, you always want to be able to take advantage of one of the two big ecosystems - namely the C world and the JVM world - because there are so many libraries out there doing nontrivial things you do not have to reimplement. Right now, writing C code that works well with generational garbage collection (or really any kind of garbage collection that moves objects around - i.e. all the well-performing ones) is either very tedious (when you try to take account of objects being moved) or slow and possibly error-prone (if you rely on JNI-style locking and unlocking of object references).

As a result, it may actually be more attractive to build a Java bytecode JIT into PyPy (and be able to have PyPy use Java classes within its more powerful representation scheme) and get mindshare among the people currently using Jython than trying to get the diehard C extension users to switch.

So much for the '"the X community should recognize what an awesome technology Y is" is a surefire recipe for building sucky software' talk. People will do whatever they do, and calling them idiots because they don't do what you think is awesome doesn't lead anybody anywhere. (Though having a decent installer and usable documentation may actually lead to more people discovering the advantages of PyPy).

Re: PyPy 1.6 Released - Full Python 2.7.1 Implementation

#52

Post by ori_b »

lliiffee wrote: post #25

Can I take advantage of this thread to ask the HN crowd a technical question? Some time ago, I implemented an automatic differentiation tool. Using operator overloading on a special "autodouble" type the tool would trace the execution of a block of numerical code. Then, some calculus would automatically happen, and it would output and compile fast c-code that would compute the original function and derivatives in pur…

RPython compiles down to C. Also, do you have an example of the generated code? I'm not sure what sorts of patterns would need it to be hundreds of megabytes.

(Also, if Pypy's compilation time is any guide, it takes massive amounts of time to compile rpython)

Re: PyPy 1.6 Released - Full Python 2.7.1 Implementation

#53

Post by headius »

stephenjudkins wrote: post #18
irahul wrote: post #9

Earlier quoted context omitted.

> but PyPy is one of the few things I envy Python developers for. Depending on your needs, there are others - numpy, scipy, matplotlib, nltk, gevent. > I wish something similar could be developed for Ruby. Isn't http://rubini.us/ supposed to be the PyPy for Ruby? It's not complete, but then neither is PyPy.

Rubinius and PyPy take quite different approaches to solving the same general problem. It's inaccurate to analogize them. Rubinius specifies a bytecode (see http://rubini.us/doc/en/virtual-machine/instructions/ ) and implements a VM that executes this bytecode. The VM is written in C++. The main difference between Rubinius and other Ruby implementations is that nearly everything else is written in Ruby. The lexer, pa…

Rubinius's parser is C/++ code derived from the same Bison grammar as regular Ruby. That's not to say it couldn't be pure Ruby, but it isn't right now.

Re: PyPy 1.6 Released - Full Python 2.7.1 Implementation

#54

Post by luismgz »

irahul wrote: post #9
kristofferR wrote: post #4

In general I'm very happy with my choice of Ruby/Rails instead of Python/Django, but PyPy is one of the few things I envy Python developers for. I wish something similar could be developed for Ruby.

> but PyPy is one of the few things I envy Python developers for. Depending on your needs, there are others - numpy, scipy, matplotlib, nltk, gevent. > I wish something similar could be developed for Ruby. Isn't http://rubini.us/ supposed to be the PyPy for Ruby? It's not complete, but then neither is PyPy.

> I wish something similar could be developed for Ruby.

There's something like Pypy for Ruby already: It is Pypy itself. Pypy is a framework for implementing jitted dynamic languages (any language, not just python). You can generate interpreters for any language you want, as long as you write them in Rpython (restricted python). So, if you want a pypy for Ruby, just write a ruby interpreter in Rpython, and then use the pypy translation toolchain to compile it down to C, while automatically generating a just in time compiler for free.

Re: PyPy 1.6 Released - Full Python 2.7.1 Implementation

#55

Post by nevir »

stephenjudkins wrote: post #18
irahul wrote: post #9

Earlier quoted context omitted.

> but PyPy is one of the few things I envy Python developers for. Depending on your needs, there are others - numpy, scipy, matplotlib, nltk, gevent. > I wish something similar could be developed for Ruby. Isn't http://rubini.us/ supposed to be the PyPy for Ruby? It's not complete, but then neither is PyPy.

Rubinius and PyPy take quite different approaches to solving the same general problem. It's inaccurate to analogize them. Rubinius specifies a bytecode (see http://rubini.us/doc/en/virtual-machine/instructions/ ) and implements a VM that executes this bytecode. The VM is written in C++. The main difference between Rubinius and other Ruby implementations is that nearly everything else is written in Ruby. The lexer, pa…

This is a great overview about the two interpreters! However, I think you're being a bit inaccurate about how flexible the Rubinius VM is. It is certainly more than flexible enough to support a wide variety of non-Ruby languages.

The core Rubinius team bas been working towards a language-agnostic core, and toolchains for building your own language on top of the Rubinius VM. See http://rubini.us/2011/02/17/rubinius-what-s-next/#multi-lang... and http://rubini.us/2011/02/23/introduction-to-fancy/

There are already a good number of language projects that build upon it: http://rubini.us/projects/ Fancy is one of the more mature languages built on it (and it's self-hosted): https://github.com/bakkdoor/fancy. There's even an (immature) Python that runs on top of it: https://github.com/vic/typhon.

Re: PyPy 1.6 Released - Full Python 2.7.1 Implementation

#56

Post by nevir »

stephenjudkins wrote: post #18
irahul wrote: post #9

Earlier quoted context omitted.

> but PyPy is one of the few things I envy Python developers for. Depending on your needs, there are others - numpy, scipy, matplotlib, nltk, gevent. > I wish something similar could be developed for Ruby. Isn't http://rubini.us/ supposed to be the PyPy for Ruby? It's not complete, but then neither is PyPy.

Rubinius and PyPy take quite different approaches to solving the same general problem. It's inaccurate to analogize them. Rubinius specifies a bytecode (see http://rubini.us/doc/en/virtual-machine/instructions/ ) and implements a VM that executes this bytecode. The VM is written in C++. The main difference between Rubinius and other Ruby implementations is that nearly everything else is written in Ruby. The lexer, pa…

This is a great overview about the two interpreters! However, I think you're being a bit inaccurate about how flexible the Rubinius VM is. It is certainly more than flexible enough to support a wide variety of non-Ruby languages.

The core Rubinius team bas been working towards a language-agnostic core, and toolchains for building your own language on top of the Rubinius VM. See http://rubini.us/2011/02/17/rubinius-what-s-next/#multi-lang... and http://rubini.us/2011/02/23/introduction-to-fancy/

There are already a good number of language projects that build upon it: http://rubini.us/projects/ Fancy is one of the more mature languages built on it (and it's self-hosted): https://github.com/bakkdoor/fancy. Note that Fancy was originally written as an interpreter in C++ - they ported it to the Rubinius VM at a later point.

There's even an (immature) Python that runs on top of it: https://github.com/vic/typhon.

Re: PyPy 1.6 Released - Full Python 2.7.1 Implementation

#57

Post by stephenjudkins »

headius wrote: post #53
stephenjudkins wrote: post #18

Earlier quoted context omitted.

Rubinius and PyPy take quite different approaches to solving the same general problem. It's inaccurate to analogize them. Rubinius specifies a bytecode (see http://rubini.us/doc/en/virtual-machine/instructions/ ) and implements a VM that executes this bytecode. The VM is written in C++. The main difference between Rubinius and other Ruby implementations is that nearly everything else is written in Ruby. The lexer, pa…

Rubinius's parser is C/++ code derived from the same Bison grammar as regular Ruby. That's not to say it couldn't be pure Ruby, but it isn't right now.

I stand corrected. Thanks.
Post reply on HN