# Ruby -\> python **URL:** \ **Category:** Ruby\ **Created:** [December 27, 2008, 1:21am UTC](https://www.ruby-forum.com/t/ruby-python/156418 "2008-12-27T01:21:51Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [December 27, 2008, 1:21am UTC](https://www.ruby-forum.com/t/ruby-python/156418/1 "2008-12-27T01:21:51Z")
I was thinking the other day…wouldn’t it be nice to be able to take advantage of some python capabilities from within Ruby, like psyco, for example? i.e. any “bottleneck” inner loops can be converted to Python, run by an optimized psyco compiled Python, and come back out to a familiar Ruby environment. Does anyone know if such a project exists? Any feedback on the idea itself? I’d imagine that most Ruby constructs have their Python equivalent. Thanks! -=r ---
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [December 27, 2008, 1:52am UTC](https://www.ruby-forum.com/t/ruby-python/156418/2 "2008-12-27T01:52:54Z")
Roger P. wrote: > itself? > I’d imagine that most Ruby constructs have their Python equivalent. Why introduce Python, when on many platforms, you have the ability to use inline C, C++ or assembler? IIRC it works on Cygwin, all \*Nix platforms and probably MacOS X as well. > Thanks! > -=r – M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC§, WOM I’ve never met a happy clam. In fact, most of them were pretty steamed. ---
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [December 27, 2008, 4:10am UTC](https://www.ruby-forum.com/t/ruby-python/156418/3 "2008-12-27T04:10:56Z")
On Dec 26, 11:11 pm, Roger P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > shouldn’t be as hard to write as, say, a ruby to c JIT translator [psyco > is a Python-\>bytecode JIT translator, so the work has been done there]. > > Obviously a translator to C would be the best, I just think it would be > pretty hard, and if one could translate to Python, a lot of the > optimization exists. A fit of python envy, you could call it. > Thoughts? > -=r What about \_why experiments on Ruby to Python front (only YARV): [http://hackety.org/2008/05/05/sneakingRubyThroughGoogleAppEngine.html](http://hackety.org/2008/05/05/sneakingRubyThroughGoogleAppEngine.html) I know, is silly, but is bytecode translated 😉 Another option is look at ParseTree for the AST and generate C code from it (ruby2c) ---
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [December 27, 2008, 2:11am UTC](https://www.ruby-forum.com/t/ruby-python/156418/4 "2008-12-27T02:11:44Z")
> > I’d imagine that most Ruby constructs have their Python equivalent. > > Why introduce Python, when on many platforms, you have the ability to > use inline C, C++ or assembler? IIRC it works on Cygwin, all \*Nix > platforms and probably MacOS X as well. Because I don’t want to rewrite my bottlenecks to C–I want to leave them as ruby and have them “automagically translated” Main advantage: Python and Ruby are pretty similar, so a translator shouldn’t be as hard to write as, say, a ruby to c JIT translator [psyco is a Python-\>bytecode JIT translator, so the work has been done there]. Obviously a translator to C would be the best, I just think it would be pretty hard, and if one could translate to Python, a lot of the optimization exists. A fit of python envy, you could call it. Thoughts? -=r ---
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [December 27, 2008, 7:00am UTC](https://www.ruby-forum.com/t/ruby-python/156418/5 "2008-12-27T07:00:01Z")
Luis L. wrote: > On Dec 26, 11:11�pm, Roger P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > shouldn’t be as hard to write as, say, a ruby to c JIT translator [psyco > > is a Python-\>bytecode JIT translator, so the work has been done there]. > > > > Obviously a translator to C would be the best, I just think it would be > > pretty �hard, and if one could translate to Python, a lot of the > > optimization exists. A fit of python envy, you could call it. > > Thoughts? > > -=r > > What about \_why experiments on Ruby to Python front (only YARV): > > [http://hackety.org/2008/05/05/sneakingRubyThroughGoogleAppEngine.html](http://hackety.org/2008/05/05/sneakingRubyThroughGoogleAppEngine.html) > > I know, is silly, but is bytecode translated 😉 Unholy is definitely fascinating. I’m unsure of it’s ability to transfer say a whole class directly into Python 🙂 [ Here’s a funny quote from \_why: “Instead of asking “can unholy run Rails?” try asking “can unholy run 4 plus 7?” And my answer to that is: no, no, no, no, it probably can’t!!” > Another option is look at ParseTree for the AST and generate C code > from it (ruby2c) Yeah I would totally prefer a straight ruby2c conversion but unless you create a run-time class analyzer and rewrite each method depending on the parameters’ classes, it will end up being about the same speed as ludicrous [which is fast, but not significantly faster than 1.9, so…not screaming improvement]. So what you really need is a run-time optimizer, and it seems to me that translating to Python and using psyco is easier than (re)creating a psyco for Ruby. That sounds hard. Thoughts? -=r ---
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [December 30, 2008, 7:40am UTC](https://www.ruby-forum.com/t/ruby-python/156418/6 "2008-12-30T07:40:29Z")
On Sat, Dec 27, 2008 at 02:59:50PM +0900, Roger P. wrote: > Yeah I would totally prefer a straight ruby2c conversion but unless you > create a run-time class analyzer and rewrite each method depending on > the parameters’ classes, it will end up being about the same speed as > ludicrous [which is fast, but not significantly faster than 1.9, > so…not screaming improvement]. So what you really need is a run-time > optimizer, and it seems to me that translating to Python and using psyco > is easier than (re)creating a psyco for Ruby. That sounds hard. > Thoughts? I think that, in the long run, it would be nice to have ruco (or whatever the Ruby equivalent of psyco would be called) anyway – so, if you’re going to go to the effort of writing code intended to lead to runtime optimization, you might want to consider just doing it “right” in the first place. On the other hand, I can see potential benefits of having a (preferably two-way) translator between Ruby and Python for a lot of common-case code, regardless of whether it ever gets used for Ruby psyco support. As such, again, if you’re intent on doing it that way I’d say get involved in a Ruby-Python/Python-Ruby “compiler” and do _that_ right, then eventually use it as the basis for psyco runtime optimization of Ruby code if nobody has gotten around to writing ruco-or-whatever by then. Of course, I’m not really sold on the idea that automating translation between Ruby and Python (especially the Ruby-\>Python part) would be notably easier than compiling Ruby to C. Ruby has capabilities that the Python core developers deliberately eschew, after all, because of the whole “the way we do it is the _right_ way” design aesthetic in Python circles. If you start opening core classes, metaprogramming, or working with complex callbacks (or, God forbid, actual lexical closures) in your Ruby, I think your Ruby-\>Python translator is going to start puking blood all over your ultra-high thread count sheets and simultaneously soil its britches. I suppose I could be mistaken, though. I don’t actually know much about Ruby and Python internals. Note: My signature block is selected randomly by a script I wrote (in Ruby, natch) many moons ago. I did not select it specifically to illustrate any points about the subject at hand. My “random” signature script, on the other hand, very well might have selected it to make a point, for all I know. ---
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [December 30, 2008, 12:50pm UTC](https://www.ruby-forum.com/t/ruby-python/156418/7 "2008-12-30T12:50:52Z")
On Tue, Dec 30, 2008 at 7:39 AM, Chad P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Note: My signature block is selected randomly by a script I wrote (in > Ruby, natch) many moons ago. I did not select it specifically to > illustrate any points about the subject at hand. My “random” signature > script, on the other hand, very well might have selected it to make a > point, for all I know. > What amazes me most however is that it picked your name correctly 😉 > Was this one of the Ruby Q. solutions ? > Cheers > R. > > – > Chad P. [content licensed OWL: [http://owl.apotheon.org](http://owl.apotheon.org) ] > Common Reformulation of Greenspun’s Tenth Rule: Any sufficiently > complicated non-Lisp program contains an ad hoc informally-specified > bug-ridden slow implementation of half of Common Lisp. – Il computer non è una macchina intelligente che aiuta le persone stupide, anzi, è una macchina stupida che funziona solo nelle mani delle persone intelligenti. Computers are not smart to help stupid people, rather they are stupid and will work only if taken care of by smart people. Umberto Eco ---
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [January 2, 2009, 11:45pm UTC](https://www.ruby-forum.com/t/ruby-python/156418/8 "2009-01-02T23:45:21Z")
> I think that, in the long run, it would be nice to have ruco (or > whatever > the Ruby equivalent of psyco would be called) anyway – so, if you’re > going to go to the effort of writing code intended to lead to runtime > optimization, you might want to consider just doing it “right” in the > first place. Yeah–I’m looking for the easiest path here–like from the outside it seems like a “ruco” project is two-fold: one get a working JIT compilation working [arguably non-trivial] and then get it to work with different parameters. Whereas “rupy” seems like one step. Psyco itself has a large download from what appears to be “lots of lines of code”[1], which made me think that “ruco” is hard and “rupy” might be simpler. At least I can write rupy in Ruby theoretically, which seems faster and easier than C. > On the other hand, I can see potential benefits of having a (preferably > two-way) translator between Ruby and Python for a lot of common-case > code, regardless of whether it ever gets used for Ruby psyco support. > What would the benefits be? I suppose that being able to convert to Python might help with the google app engine or what not. > As > such, again, if you’re intent on doing it that way I’d say get involved > in a Ruby-Python/Python-Ruby “compiler” and do _that_ right, then > eventually use it as the basis for psyco runtime optimization of Ruby > code if nobody has gotten around to writing ruco-or-whatever by then. By compiler you mean it translates a .rb file to a .py one? [or like unholy bytecode → bytecode]? > Of course, I’m not really sold on the idea that automating translation > between Ruby and Python (especially the Ruby-\>Python part) would be > notably easier than compiling Ruby to C. Ruby has capabilities that the > Python core developers deliberately eschew, after all, because of the > whole “the way we do it is the _right_ way” design aesthetic in Python > circles. If you start opening core classes, metaprogramming, or working No joke. Just the thought of having to use len(instance) instead of string\_instance.length makes me cringe LOL. My hope was that Python and Ruby would be similar enough to make it easy. In which I’m probably sadly mistaken but…it might still be an interesting project. I think I may well end up just living with 1.9’s [slightly improved] speed 🙂 Thoughts? -=r [1] [http://codespeak.net/svn/psyco/dist/c/](http://codespeak.net/svn/psyco/dist/c/) Psyco v. 1.9 speeds: [http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=psyco&lang2=yarv](http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=psyco&lang2=yarv)