Slashdot Mirror

ha, at least a nice reply. You are not a butt-hurt loud mouth like one of the above poster. Thank yuo

Oh, you wanted an answer. Honestly, it never crossed my mind that you were doing anything but trolling about a difficult problem lots of smart folks are dilligently working on that have been discussed for years.

My apologies, I thought this was yet another insouciant probe along the lines of "Oh, is Perl object-orented?" or "Gosh, do people use OpenBSD?". Sorry to prompt that wounded tone from you there.

Oh, and for reference, your (indirect) response requires "neckbeard" or a veiled reference to the autism spectrum to be canon. Just as mine requires a "My fault for feeding the trolls"

The attempt to write a Python implementation in Python, PyPy, turned into a death march. The project has been underway since at least 2003 (when they had their first "sprint"), never produced a usable system, and the European Union pulled the plug on funding. But the project limps on. There's a released version. It's slower than CPython. There's supposed to be a "just in time" compiler Real Soon Now. (This is try #2 at a JIT, not counting the schemes for outputting Java bytecode and Javascript.) Six years in on a compiler project, and no product.

The PyPy project is very "agile". They have "sprints". They have "flexibility". They have nightly builds. They have mailing lists and trackers. They support multiple output back-ends. They have about 50 contributors. What they don't have is a usable product.

Meanwhile, one programmer produced Shed Skin, which compiles Python to C++, with a speed gain of 5x to 50x over CPython.

When the problem is dominated by design and architecture, "agile" doesn't help.

And anyone who thinks Java, Ruby, or Python have enough power to write themselves has not looked carefully at them.
Maybe it's you not looking carefully enough?

Currently what you find is that Javascript does not have a good interface to the system, without native javascript APIs for open, read, etc, and without a standard set of hooks into C programs. This is entirely because of javascript starting in the web browser, but what you'll see is people developing these and then ...

I should rest my case here.

But, jsut for nto being so dry, I will write on:

The Syntax: javascript doses use an archaic C syntax - which is nice when you have to closely follow the way the processor is behaving inside so you can have maximum effectiveness and even have a good idea of the machine code generated as you write it. The only good reason this syntax was choosen is that it...resembles C! Python syntax drops some punctuation so that the language resembles the way we do think our algorithms when we address our problems (at least in western Languages like English and Portuguese). As other peopl have noted in this thread: it resembles pseudo-code.

As an example, pick the integer dependent "for" statement - when you can have those in high level. (yes I know there is a "for each" in javascript. I tried to use it once, only to learn it would work only in some browers, so nobody actually uses it)

Finally: Python is there already, it is not "going" anywhere. One of the strrnghts in python is exactly the ease to open and manipulate files - to single method calls and you have the data in memory, ready for manipulation - and you just admited javascript can't read files at all. And if current javascript engines are faster than the standard python implementation's engine, no problem in there as well: python with it is nicer, higher level syntax can be seamlessly translated to javascript and run on javascript backends for at least two different projects (Pypy and pyjamas).

No trolling here: just try a bit of Python - it is much better to write (and read) than the C legacy syntax of Javascript.
And there are a few goodies in the language that javascript don't do, for example: namespaces, and trying to access an as of yet unattributed variable yields an error - it may sound simple, but saves hours on debugging complex incorrect behaviors derived form small typos in variable names.

That said, I agree with you that the javascript VMs are evolving at huge steps with Apple, Google and Mozilla each trying to deliver a faster engine. And I will be running Python (auto-translated to javascript if needed) on those - on client side web pages. Up to there, I will just use native python to do desktop GUI programing, web server apps, network and server management tasks, videogames, scientfic computing, and so on.

A "real" language has been classically defined to mean "a language which can compile itself." Perl, Python, and Ruby cannot do that (to my knowledge).

http://codespeak.net/pypy/dist/pypy/doc/home.html

Python and Perl aren't interpreted, and both can be self-hosting. Ruby could be, I'm sure, but I have no idea since I don't use it.

Within the Python community, interest in Parrot seems completely dead.

Generic VMs are so 2005, the future of Python runtime is PyPy. From a single implementation of Python (written in Python), they can compile Python code to C, JVM, automatically create a customizable JITed VM, etc...

Check them out: they are doing some seriously cool stuff and they can use a bit of help.

Even if CPAN was the only argument for using perl (which it isn't), it would still be one hell of an argument.

Not when the opposition has an equivalent tool/repository, at which point it's just par for the course. See PyPi and EasyInstall/Setuptools.

(As for good high-level Python XML toolkits, I'm personally fond of lxml, but there are plenty 'round; if you couldn't find one, it's because you didn't know where to look).

http://psyco.sourceforge.net/

The really neat thing about it is that you can just load the module and call some functions, and it'll start JIT compiling your Python code for some moderate speedups (particularly string and number crunching). It doesn't need a special version of CPython or anything.

The original author is no longer developing it though -- he's working on PyPy, the Python interpreter/JIT written in Python. I think they're up to about half the speed of CPython, which is pretty impressive considering how slow Python is.

When you have a language like Python, which is defined by a single (very slow) implementation

Which of C Python, PyPy, Jython, or IronPython is the only implementation?

Well, there's pyjamas, which does the same thing that Google Web Toolkit does, only with Python.

There's also a demo around somewhere of someone using PyPy to compile the Bubble Bobble game to Javascript from Python.

Also worth mentioning that PyPy allows you to run Python as Javascript, inside a browser. Like all of these things, it isn't 100% mature, but pretty cool nonetheless.

I've got my money on Python running as JavaScript winning the performance crown. :-)

Or PyPy the most interesting one of them all. A python interpreter run on top of python, all kinds of laguage parsing / compiling / optimizing stuff that I have a hard time understanding ;) A real brainfuck in the postive sense!

http://codespeak.net/pypy/

All I have to think of is the current progress of the pypy interpreter. They have the ability to take something that is written in RPython and translate it into any backend to the annotator. This currently supports JS among other things. Check out http://codespeak.net/pypy/dist/pypy/doc/news.html

http://codespeak.net/pypy/dist/pypy/doc/news.html
http://mark.dufour.googlepages.com/

are also among the many python->machine code projects.

...and it need not be said.

Between Pyrex and Psyco, there's really very, very few applications that a language like Python isn't appropriate for. Premature optimization is the far more common programmer sin these days than choosing a language that's "too slow." Except for a few, specific application domains (that only a minority of coders are writing) dynamic languages like python are an excellent choice on today's hardware. And if you need it to be faster, just profile, find the couple of spots that matter, and pull out Pyrex.. or even the C/Python API if it makes you feel manlier. :-)

Plus, with things like PyPy + LLVM, Parrot, and IronPython emerging, things are only going to get better.. don't be the last one on the dynamic boat!

Tip #1: I highly recommend adding pyrepl to your Python environment. It enhances functionality of the interactive interpreter such that you can easily edit multi-line code snippets. Forward and back (control-n, control-p) through history. Control-r (then start typing) to find something back in history. Very useful. http://codespeak.net/pyrepl/

Tip #2: Avail yourself of the help() function in the interpreter. help(SomeObjectOrFunction) i.e. help(open) will return the docstrings associated; help(SomeModule) i.e. import sha; help(sha) will return the module docs.

As far as I'm concenrned Sun is playing catch-up with Microsoft, and this is no more than a half assed response to MS releasing IronPython

"Underlying technology: PyPy"

I could see this Python > C++ > Machine code project being something PyPy was built on top of, but not the other way around? Please explain...

PyPy

... and you can write a c compiler in c, and an assembler in assembler. If you look at the pages, you'll see that while it might be written in python, it still ends up having to generate code in another language - either native code such as c or an interpreted language such as javascript, that needs a runtime written in native code:
http://codespeak.net/pypy/dist/pypy/doc/architectu re.html

# the code generator which translates the resulting flow graph into another language, currently C, LLVM, Javascript (experimental).

Last I heard, c wasn't on the list of managed / non-native languages, the llvm back-end emits c code, and javascript requires an interpreter.

Ultimately, there's native code at the base of every program running on your computer. The cpu can't run anything else.

Why wouldn't it be? JIT compilation is merely a rather advanced kind of interpreter. AFAIK Python already has one (even though dev on it has more or less stopped) and PyPy will supposedly include one out of the box, and I think Matz would like Ruby2 to have a JIT compiler.

My primary reason for choosing Python is that it "stays the hell out of my way" better than other languages - it just seems that it doesn't demand so much from me to accomplish common tasks. As others have said, it seems to fit my brain a lot better than any other programming language I've ever tried.

That said, I get uneasy about the "peformance and speed" hopes people are starting to pile on PyPy. If you look at their mission statement, speed/performance isn't in there. Yes, the PyPy folks are a sharp group of people, and they may come up with some fantastic performance improvements, but that doesn't appear to be high on the list of priorities.

I like weave but I am waiting to see what will come out of the PyPy project - the author is the one who wrote Psyco (the JIT compiler for Python).

Then there is Pyrex where Python can manipulate C data with language extensions, as opposed to weave where C code is inlined into the python code and Python data is manipulated in C.

It is true that as a scripting language Python is slower than (byte)compiled languages. But it is slower by a constant factor. In other words people would say "Your Python solution is 4x slower than my Java solution!". What this means though is that just by upgrading the hardware that Python runs on, one can reach the speed of execution of the compiled program. In other words Python on an Athlon 64 fx 57 might run faster than java bytecode on a 1Ghz Athlon, or might even run faster than C on a 100Mhz machine (I am just making these numbers up, maybe someone knows of some benchmarks?). The point is that application that required C 15-20 years ago can probably be re-written in Python now.

What are some examples? I can easily think of a high level language generating a lower-level like gcc transforming your C++ into machine language, or java being compiled into bytecode instructions.

As for a HLL->HLL translation take a look at the PyPy project (which among other things is attempting to write a Python interpreter in Python). here The goal is to generate low level description of the python code that interprets the python code (go figure!). That is what they claim at least...

Python has moderately fast bytecode (google stuff could improve a lot here)

A very interesting project that aims to create a faster Python implementation is PyPy, funded by the EU, by google (with Summer of Code) and by a lot of programmers that donate their own time.

Even the Psyco guys say that the future is in PyPy!

Python is a dynamically typed language.

This was the answer I was expecting, which is why I specifically stated "as compared to Ruby". An interesting language for this is Boo, a Python-like .NET language which has a static typesystem.

Another issue that I have personally encountered concerns reference counts. Python extension modules are written in C.

To be completely fair, just writing in C presents this. However, just because extension modules can be written in C, does not mean they have to be. It is quite dangerous, but most langauges (Java, C#, I assume Ruby, Haskell through GHC, etc.) allow linking into unsafe code in some way or another. It just seems a pity that the reference implementation of Python is written so largely in C (although some would argue this is a matter of practicality). I like the look of the PyPy project, which is implementing Python in Python, in order to get around these problems though.

Starting a Python program may take a few seconds at 100% CPU, because the interpreter needs to process all imported modules. This also disqualifies it for some purposes.

...but not many, to be fair — JIT compilation of any kind carries similar problems though. I believe it may be more pronounced in Python, but I'm really not sure.

Dynamically typed languages like Python can be really useful for scripting and prototyping, but I wouldn't rely on them for mission-critical applications. You can quickly create a simple program but it is hard to be sure that it is really stable.

I essentially agree with this — in particular, it does always feel unsafe to me to program in such a language. There is a great many automated checks one can do without a typechecker though, which can greatly improve the reliability of a system. Another point is that with the sort of applications that Python and Ruby are used for, reliability is not always priority number one, particularly when the systems are built on top of a proven framework.

(By the way did I mention that with some special modules like weave it already is pretty simple to inline C/C++ code in Python and I am experimenting with that for scientific computing and so far I am pretty impressed, it surely beats Java in my benchmarks.)

If you like weightless threads, you'll love greenlets (a standalone spinoff module of Stackless). Unlike generator-based coroutines, greenlets can be nested and switched to any other routine without the use of 'yield'. Also, any function can be turned into a greenlet - very little rewriting needed. There's hardly any overhead either since it's just an extension module written in C for the unmodified Python interpreter.

It's interesting to note that there are several re-implementation of Python, at various levels of maturity (Jython,stackless Python,PyPy, and IronPython)

Anyway, you don't need Java to handle these issues.

If it's really a problem, there are a myriad of solutions -- Numeric and numarray for lots of numbers, psyco for JIT optimizations, Pyrex for a Python-like syntax that compiles to C (and can be as fast as C if you use it correctly), and lots of other new options as well -- IronPython is supposed to be faster than CPython (the standard implementation), there's quite a bit of work on type inference, PyPy is working hard at compiling Python to fast C, Boost can inline C++ code... there's a huge number of options.

I've never encountered someone who had to throw a project away because of performance issues in Python. Sometimes they have to change the design, move some small parts of C, make better use of other people's libraries, and always of course driven by profiling -- but that's the kind of refactoring that always happens in development. And for a very large number of applications it simply is never a problem.

You're looking for Python and Ruby. Both are so easy to learn that the correct answer to which one is "both"; try the tutorials for both and you'll probably know pretty quickly. The thing to look for is which philosophy suits you better.

The only thing out of that list you might think is missing is "generic programming", but in general that's because both languages support it so naturally that it isn't even a seperate paradigm. I know Python has libraries for people who insist on the trappings of generic languages, or who really, really need completely seperate functions for the various combinations of args, but I don't know much about them because while I've looked at such things, I've never encountered a situation where the "correct" answer wasn't a slighty more careful API, YMMV.

Unless you're doing intensive numerical calculations that can not be expressed in terms of the various libraries for numerical calculation, or are really focused on embedded programming, both are plenty fast for normal programming.

(I don't know about Ruby but there is a lot of progress towards optimizing Python being made, although I don't know if we'll ever quite get to compilation to pure native code. See PyPy, for instance, which has recently been funded so it ought to stick around and produce something. I expect that within another couple of years, through one avenue or another, the speed penalties of Python will be gone for all practical purposes.)

Granted, neither of these may currently perfect... but holy cow, are they better than C++. Unbelievably better, for the vast majority of uses.

I was investigating whether to start from an existing compiler and extend it. The compiler will be based on yacc, or bison.

Perl also has the right license (GPL). Is Python out of the question for such a project, since it's not GPL?

Surely we do not have everything in Zope, but many things are not there, because people jsut did not need it. Just because 1-2 people ask for SOAP does not mean it is a widely needed protocol. Here are some comments:

- transactional control: We have this.

- Object relational layer: There are several Zope 2 solutions for this and for Zope X3 there is the really cool sqlos framework (http://codespeak.net/z3/sqlos/).

- SOAP: People request it, but noone has needed it badly enough to write an implementation.

- Cross Container communications: I have no clue what you are talking about.

I hope that helps.

Zope X3 will become Zope 3. The reason it is currently not called Zope 3 is because we have no answer for people migrating their sites from Zope 2 to the new code base. However, Zope X3 is very usable and you should use it, if you develop a new application. Also note that there is the Five project (http://codespeak.net/z3/five/) that allows you to run Zope X3 inside Zope 2. Thia has become a favorite choice for many existing Zope developers already, which have a large code base in Zope 2.

you thought you were joking....

And don't forget PyPy, of which the author of psyco is also a member. If any of these three projects will bear the fruit of a python-machine code compiler, it's PyPy.

implement it in itself: Not sure what your point is, but you can certainly implement the Python VM in itself. The Python VM is actually quite portable as is demonstrated by the excellent Java based implementation found in Jython.

Too dog slow? Uh, no. See the Twisted project for an example of an "internet event server" whose web server implementation is faster-- and more flexible-- than apache.

Twisted Web is "fast enough", and nobody seems seriously interested in optimizing it, but I would hesitate to boldly claim it's "faster than" something else if it doesn't have a clear advantage. I'd have no problem if you said it was faster than Jigsaw, for example: if you want to talk about dog-slow systems, that's a good example.

With a real production webserver like Apache, though, there are a lot of variables to tune. There are obscure interactions to be taken into account. Twisted will surely be slower than well-configured Apache on an SMP system, for example, unless you've got 2 processes working in parallel behind a proxy... and of course, then there's dynamic content, which is an entirely different set of measurements.

The issues are complex, and it doesn't help to advocate the project by oversimplifying them.

The announcement was only made 4 days ago. It's available on comp.lang.python.announce: link here

There isn't much yet beyond a mailing list (here) and a lot of discussion on c.l.p, but the folks involved are notable Python contributors. I have no doubt the project will be successful.