fuzzyman

It's Ruby in RPython, the implementation language of the PyPy VM toolchain. It has nothing to do with integrating with Python. It's an alternative Ruby VM using a proven JIT generator technology that happens to be built with a Python-like language. Hope that helps.

Hey, at least he thinks it's glitzy. That's a plus.

Uhm... utter tripe. How bizarre.

In the process of moving 24 domains.

I don't really know what you mean by supporting numpy on pypy "excludes" scipy (other than in the short term). If you mean you assumed that the pypy team would port all of scipy as well as numpy, that seems like an unrealistic expectation for an initial port!

An initial port seems like the only way forward from the point of view of the pypy team. I think it is unrealistic to expect the pypy team to take on the work of changing numpy so that it is more friendly to alternative implementations. I would certainly expect them to be involved in the discussion though.

The article also seems to miss that there is work ongoing to bring pypy support to Cython.

I missed the specific suggestions on how the pypy guys could improve things - other than "do a lot of work on numpy itself as well so that it better supports multiple implementations" (paraphrase obviously). That really needs to be the side of the equation that the numpy team take hold of.

Shuttleworth is trying... :-)

It doesn't make it more of an issue. Installing any Python package already requires "arbitrary code execution" -- which is the big problem with Python packaging. (And hopefully will be fixed by distutils2 which uses a setup.cfg to install packages rather than relying on executing setup.py.)

This Trojan requires the ability to execute arbitrary code and write to files - so it's not in itself any kind of exploit. It's just malicious Python code.

And whilst we're at it can people stop using "water" as a synonym for "pure water". Mud is water too, it's just not as pure!

Well, you just change to the Python 2 super call form and it works fine. The substitution hardly requires a master programmer...

Because there is no need for locking in the fundamental data-types like hashes.

pypy has quicker start up than CPython and also has a JIT. They're working on interesting memory optimisations too.

IronPython is another GIL free Python implementation.

"Python is hurting from a bad design decision that doesn't let multiple interpreter implementations share components that they could have."

As many others have said, changing syntax is really one of the most trivial parts for alternative implementations to keep up with when moving to new versions. That "hurt" hasn't been fixed because it doesn't really hurt very much...

Bug report triaging is very good now - most reports get responded to within a day.

Nope - not arbitrary, it is because of the indentation scoping rules. Try coming up with a syntax for statement based lambdas that isn't ugly as heck.

Well, normally I would agree - but if its entirely abstracted away in a library (and the library is well written) then it might sort-of-kind-of-maybe be ok.

Python itself does varying degrees of bytecode optimisation depending on which version you're using.

You could almost certainly achieve that with the implementation of blocks provided by this package:

http://pypi.python.org/pypi/withhacks/

And not being Lisp is one of the big reasons for the success of both Python and Ruby. :-)

FLAMEBAIT -> FLAMEBAIT

As a Pythonista I have no idea what the Ruby snippet is doing. Readability depends entirely on context.

The Python 3 version is using a function annotation.

In Python 2 or 3 you could use a context manager (with statement) to similar effect.

Bullsh*t.

And in terms of scaling Ruby is likely to be the cause of your problems rather than the solution...

"method_missing" - do you know about '__getattr__' for Python? (can be a one liner if you want...)

"oh-so-thread-safe-code for an interpreter that serializes around a global interpreter lock" - so Ruby's threading is better??

"The browser is a fantastic platform. You never have to install web apps. You never have to patch web apps."

Fantastic for the developer maybe - not so for the user.

"Remember, dumb terminals were around long before PCs."

Right. How was that for the user ?

As an open-source developer (with Python) who uses Windows, Microsoft and their actions hardly ever seemed to feature in the things I was interested in or that were important to me.

That actually changed when I got a job developing an application with IronPython (an open-source implementation of Python for .NET - funded by Microsoft).

Now I actually use .NET, and I have to admit that it isn't bad. Generally a sane API, and C# is nicer than Java.

Still, when I develop my own projects I use cPython, and Microsoft is now 'slightly; relevant whereas for the last few years they have seemed completely irrelevant.

How many developers of startups do you know who actually use a browser based IDE ?

There are a couple and they only suck a bit, but they don't compare to the desktop ones.

I don't use a browser based text editor when I want to make a quick note. Actually a couple of my friends do with google docs - but not too many.

For the apps I use everyday, the browser sucks. It's not just latency, although this is a big contributor to why web apps feel sucky and clunky, but the browser just isn't a very good platform for rich applciations.

The google integration between their applications is very good, and getting better, but it isn't enough to make me forget that the interface sucks...

I think the death of the desktop is much exaggerated.

AJAX is better than the last generation of web-apps, but the browser still basically sucks as a platform. Latency is a bitch. :-)