Python Converted To JavaScript, Executed In-Browser

lkcl writes "Two independent projects, Skulpt and Pyjamas, are working to bring Python to the web browser (and the JavaScript command-line) the hard way: as JavaScript. Skulpt already has a cool Python prompt demo on its homepage; Pyjamas has a gwtcanvas demo port and a GChart 2.6 demo port. Using the 64-bit version of Google v8 and PyV8, Pyjamas has just recently and successfully run its Python regression tests, converted to JavaScript, at the command-line. (Note: don't try any of the above SVG demos with FF2 or IE6; they will suck.)"

Comments

python sucks

[Anonymous Coward]

To quote Austin Powers: "Why won't you die?"

PHP rulez.

Re:python sucks

[digitalunity]

Fortran is better. You're doing it wrong.

Re:python sucks

[master5o1]

Because it's done like this:
<?php
die(Python);
?>

Re:python sucks

[Anonymous Coward]

To quote Austin Powers: "Why won't you die?" PHP rulez.

To paraphrase Fyodor Mikhailovich Dostoevsky: "Why should such a troll live?"

Oh whatever.

Re:python sucks

[Anonymous Coward]

var mydingaling = document.createElement('select');
mydingaling.setAttribute('multple','multiple');
mydingaling.options.add( document.createElement('option').text = 'i want to play with my dingaling';

Doesn't javascript allow you to the majority of what was set forth as canonical in Lisp?

Re:python sucks

[chrysalis]

Ahaha you're so funny.

Now, GOTO \your_namespace because $this->is_off_topic(TRUE == "FALSE");

Re:python sucks

[Ant P.]

AAAHHHHHHH! It burns!

Re:python sucks

[the_humeister]

I prefer a javascript assembler

Re:python sucks

[Jane_Dozey]

Pfft! Python makes it easy:

import suicide-python

Re:python sucks

[the_humeister]

Found something better: 6502 assembler!

Re:python sucks

[Hurricane78]

Which, according to the "great" auto-conversion of PHP would print the string "Python" before exiting, because it converts unknown constant names to strings. If you put a "define("Python",0xFA1);" in above the die(), it will print the integer "4001" and return it as an errorlevel. If you instead use "define("Python",0xFA1.L);", it will just print "4001L" and not return it as an errorlevel.

That is, why "easier" is not always easier, but sometimes actually harder. The reason why we can't stand Clippy. The reason some can't stand many Microsoft or Apple products at all. (And many other "so easy an idiot could do it (but actually only an idiot still can do it!)" products. It'shalf the reason people have problems with computers nowadays.
And why the resulting idiocy of auto-typecasting is one of the biggest failures in programming language design ever. ^^

P.S.: Haskell FTW! ;)

Re:python sucks

[Blakey Rat]

Jesus Christ, man. It was a joke!

@import sense_of_humor;

And Microsoft removed Clippy like a fucking DECADE ago, get over it already.

Re:python sucks

[Hal_Porter]

It has been first converted to Javascript, then executed.

Cruel and unusual perhaps, but it is certainly dead now.

Re:python sucks

[Anonymous Coward]

Python was created based on the philosophy:
  "Well, the only reason people don't like Lisp is because of all the parenthesis"
and, for good measure:
  "And Lisp-people don't like curly-braces, so let's not use them, either"

Re:python sucks

[bennomatic]

Nice.

Re:python sucks

[John Betonschaar]

That's pretty cool actually :-D

Re:python sucks

[Anonymous Coward]

I saw this... elsewhere.

My god. What a terrible language. It seems like a good idea in principle, but they have made such a mess of their design decisions. Who wouldn't want a functional and object oriented language? But, for some ungodly stupid reason, "join" is a method on the GODDAMN STRING CLASS, instead of the array class. So I get to write god awful ugly crap like

"".join(array)

Similarly, map is a FLIPPIN keyword. It's not even a method. Let alone an function combinator on lists or collections like it is in every other goddamned functional language in the world. lambda is the same way. So I get to write crap like

map(lambda x: DO STUFF to x, array)

Guess what happens if you want to make a string out of a post-processed list and have to combine these:

'; '.join( map( lambda a: a.surname + ", " + a.given_name, self.author.order_by('surname') ))

Jesus christ. I mean, it's not the best form to stick a relatively long lambda in there. But why can't I do this?

self.author.order_by('surname').map(lambda a: a.surname + ", " + a.given_name).join("; ")

You know, so you can READ THE CODE FROM LEFT TO RIGHT. It's like Guido van Rossum never had to iterate over an array and use the result. And the lambda is clear here. There's no superfluous shit next to it to make this confusing. It makes SENSE. You RUN A QUERY ( that is ordered ), AND stick the surname and given name together for each of the results. And then you stick them all together, separated by a "; ". It's not rocket science.

Worse yet, the stupid indentation rules don't let you even write multi-line lambdas. What's the point of a "simple syntax" if the semantics are utter shit? I can use def, of course, but then I'd have to name the function. Pointless. The only really sensible name for that function is "concatenate_surname_and_given_name" or "create_author_name", and it's just as long as the lambda expression.

Even if I did write the function out, it would either end up in the Author model class, so I'd still have to use a lambda, like:

'; '.join( map( lambda a: a.create_author_name, self.author.order_by('surname') ))

Or I'd have to keep it in the scope in which the map happens, like:

class Book:
        def create_author_name(author):
                return author.surname + ", " + author.given_name
        def __unicode__(self):
                '; '.join( map(create_author_name, self.author.order_by('surname') ))

SO I COULD NEVER USE THE FUNCTION OUTSIDE THE BOOK CLASS ANYWAY. It is of NO use as a utility function in the Book class.

I'm using Scheme or Haskell next time, for sure.

Re:python sucks

[Neil Hodges]

This seems outdated: map is a method as of 2.6, and you wouldn't use map anyway since comprehensions are preferred.

The last complaint could be mitigated by writing a regular function, too.

Re:python sucks

[Anonymous Coward]

This seems outdated: map is a method as of 2.6, and you wouldn't use map anyway since comprehensions are preferred.

No, it's not "outdated". Using the keyword is the "officially" recommended way of using map.

http://docs.python.org/tutorial/datastructures.html#functional-programming-tools

As nice as list comprehensions are, they're a bad method of chaining functions, because it is achieved by nesting, at the syntactic level. Something like:

[ (lambda x: x) for x in [ (lambda y: y) for y in list] ]

If I want to apply another function, I get to move that whole list construct into a new one. Or rewrite, but that defeats the purpose of using powerful and expressive tools. We already saw what that would look like if Python was awesome:

list.map(lambda x: x).map(lambda y: y)

Functor composition is expressed by simple concatenation. That's much easier to read, write, and maintain.

The last complaint could be mitigated by writing a regular function, too.

Brilliant. Let's break encapsulation for every single utility function a model might use.

Re:python sucks

[Anonymous Coward]

Get your facts straight, Microsoft didn't remove Clippy, they promoted him to behind-the-scenes CTO.

Re:python sucks

[master5o1]

I thought he was store manager at the first Microsoft store that opened.

Re:python sucks

[Anonymous Coward]

Awesome.

Re:python sucks

[Homburg]

I think the problem here is that you don't know anything about python.

No, it's not "outdated". Using the keyword...

It's not outdated, because it's completely incorrect. map isn't a keyword, and never has been; it's a function.

As nice as list comprehensions are, they're a bad method of chaining functions, because it is achieved by nesting, at the syntactic level. Something like:

[ (lambda x: x) for x in [ (lambda y: y) for y in list] ]

If I want to apply another function, I get to move that whole list construct into a new one.

No, a comprehension looks like:

[f(x) for x in l]

So if you want to apply another function, you write:

[g(f(x)) for x in l]

The function composition occurs the same way it does anywhere else - by applying one function to the result of another.

The last complaint could be mitigated by writing a regular function, too.

Brilliant. Let's break encapsulation for every single utility function a model might use.

I have no idea what this means. Functions created using lambda and functions created using def are exactly the same. What kind of "encapsulation" is "broken" by using a regular function, but somehow isn't broken by using a lambda?

Re:python sucks

[Ragzouken]

"; ".join(["%s, %s" % (a.surname, a.given_name) for a in self.author.order_by('surname')])

Re:python sucks

[Anonymous Coward]

It's not outdated, because it's completely incorrect. map isn't a keyword, and never has been; it's a function.

So is it a reserved word, or not? Does your "point" mitigate my observation that map is essentially a reserved word? Does it change the point that it, and join are poorly designed and actively get in the way of maintainable programming?

No, a comprehension looks like:

[f(x) for x in l]

Which is exactly what I wrote, only I did nesting.

So if you want to apply another function, you write:

Wow, thanks for nothing. And if you want to filter the results of an operation, and then apply an expensive operation to those results, what do you do? What if you want to filter those results?

From the documentation, the first operation would be something like

[ expensive_operation x for x in list if (satisfies_first_predicate x) ]

Which means that if you want to filter these results, using a list comprehension, you need to

[ x for x in [ expensive_operation x for x in list if (satisfies_first_predicate x) ] if (satisfies_second_predicate x) ]

(I didn't see that one coming, when I said nesting is necessary...) What's more readable? That? Or...

list.filter(satisfies_first_predicate).map(expensive_operation).filter(satisfies_second_predicate)
...?
Be honest. Which is easier to maintain?

The fundamental insight is that map, filter (and a few others) are all "functors" on lists.

Haskell has a notion of "monad comprehensions", which let you "pull" elements from arbitrary monads. So a monad comprehension is a generalization of a list comprehension. And they are more useful, since you can use the same programming paradigm on lots of similar data structures (that do not need to be lists, or even collections...)

People typically don't use monad comprehensions very much, despite being far more useful, because they introduce multiple syntactic forms for functor application. If you have a list, you want to do "something" with it. And it is much easier on you when all those "somethings" take on the same syntactic form.

I have no idea what this means. Functions created using lambda and functions created using def are exactly the same.

For one thing, functions are named. Lambdas are not. So they're not "exactly the same". The difference is an important one.

I take it you haven't been doing much professional programming, and probably have trouble with reading comprehension. The rant was pretty clear about why that circumstance was utterly stupid. Using a lambda is fine, when it is clear. Map and join notation make it unclear. Ergo, you must moved to named functions. But named functions live in namespaces or classes. Here is the appropriate part of the rant:

Worse yet, the stupid indentation rules don't let you even write multi-line lambdas. What's the point of a "simple syntax" if the semantics are utter shit? I can use def, of course, but then I'd have to name the function. Pointless. The only really sensible name for that function is "concatenate_surname_and_given_name" or "create_author_name", and it's just as long as the lambda expression.

Even if I did write the function out, it would either end up in the Author model class, so I'd still have to use a lambda, like:

'; '.join( map( lambda a: a.create_author_name, self.author.order_by('surname') ))

Or I'd have to keep it in the scope in which the map happens, like:

class Book:
def create_author_name(author):
return author.surname + ", " + author.given_name
def __unicode__(self):

Re:python sucks

[poopdeville]

That's okay and all, but list comprehensions can require nesting. That's not good for maintainability. In fact, it is very bad. The sorts of things that ought to be thoughtless exercises (adding a hook to filter a list, so that you can pass the hook a function) become non-trivial exercises in themselves.

Consider the idea of taking a list, filtering by some predicate A, applying an expensive operation on the filtered list, and filtering the new list on some predicate B. Using list comprehensions, the "inner" list is:

[ expensive_operation x for x in list if A x ]

If you want to filter, and continue to use the same syntactic form, you have to do

[ x for x in [ expensive operation x for x in list if A x ] if B x ]

The fact that my eye has to go left and right and left and right, to find governing filters, braces, and so on, make it much harder to read to the equivalent (if Python was awesome)

list.filter(A).map(expensive_operation).filter(B)

I can keep that construct up for a few dozen method calls, and it will still be clear. Try nesting even four or five list comprehensions.

And I still think "; ".join is disgusting. I don't mean to be condescending, but do you know what a "join" is? http://en.wikipedia.org/wiki/Join_(mathematics)

Re:python sucks

[poopdeville]

I think the problem here is that you don't know anything about python.

I know enough about python to know that your attitude is typical among Python users.

So why is a list comprehension better than something like

list.filter(A).map(function).filter(B).map(C).filter(D)?

How would you even express something like that? Nasty nesting, I'm sure. Even if you use "map" and "filter", you're screwed. You have to nest, because of Python's idiotic definitions of map and join.

And I'm sure you're not experienced enough to know why my version is significantly better. In effect, it's better because the important parts of every step are ALL RIGHT OF the textual representation of the last operation. So you DON'T need to move your eyes back and forth to keep track of scoping. So if you want to add a step to the computation on a list, you just add it at the end. If you want to add an intermediate step, you find where it goes, and insert it.

Re:python sucks

[Ragzouken]

It doesn't matter what a mathematical join is, python is using join in the sense of attaching multiple things together, the regular English meaning of the word.

You don't need to nest the comprehensions, simply use multiple lines:

result = (item for item in list if predicate(item))
result = (item for item in result if predicate2(item))
result = [expensive(item) for item in result]

Maybe it's not as nice as the method based filter/map, but it shows you don't have to horribly nest comprehensions like that.

Re:python sucks

[Bat Country]

In other news, if you do something completely stupid with a programming language, the language will respond in kind.

second post

[Anonymous Coward]

all you python fanboys can eat out my asshole.

Python=great, SVG=great, better examples soon ?

[Anonymous Coward]

I'll look into it later, maybe donate better examples.

AS IF

[Anonymous Coward]

Using python to GENERATE JavaScript, not python converted

Why, God, why????

[Anonymous Coward]

What a waste of time and energy. The only thing worse than Python is, well, Javascript.

Kudos for turning shit to sludge.

Re:Why, God, why????

[mcvos]

What a waste of time and energy. The only thing worse than Python is, well, Javascript.

That is exactly the whole point that you're so obviously missing here: nobody sane should have to write Javascript, and yet it's the only thing that's supported by browsers. So converting code from other languages to Javascript is the only sensible solution at the moment. (For the longer term, it'd be nice if they replaced Javascript with something halfway sane.)

Re:Why, God, why????

[timeOday]

The only thing worse than Python is, well, Javascript.

I'd be interested to hear what you like better, and why? Personally I'm still sad that Java (not Javascript) didn't win on the Web - a cross-platform, general purpose language that is at least a reasonable choice for most anything. To make programming faster, you can always use higher-level libraries or code-building environments on top of it, or compile some other syntax to java bytecode.

Now instead the Web is a big mish-mash of fundamentally incompatible technologies. And if anybody does pull off the one-runtime-for-anything vision, it looks like it will be Microsoft.

Re:Why, God, why????

[bcboy]

I felt the same way until I watched Douglas Crockford's videos on javascript. If you hate javascript, you're doing it wrong. I now prefer it to the other languages being discussed here.

Re:Why, God, why????

[onefriedrice]

Well, haXe is a Java-like language which compiles to Javascript among other languages. It's definitely general purpose enough to use in the client as well as the back-end, and it has nice libraries which make communication between them easy. It happens to compile to Flash, too. I'd imagine that any reasonably complex project could be built just about entirely in haXe.

Re:Why, God, why????

[FlyingBishop]

Coincidentally, that's exactly why Microsoft has the least secure operating system on the planet.

Re:Why, God, why????

[MobyDisk]

What this tells us is that we didn't need a standard web-language. We needed a standard web virtual machine. I guess, the JRE and Flash really are those things. Javascript really isn't.

Re:Why, God, why????

[robotsrule]

How about Google Web Toolkit?

Re:Why, God, why????

[shutdown -p now]

If you hate javascript, you're doing it wrong.

Prototype-based OO by itself is a pretty neat idea, and it has many strength, but JavaScript isn't a particularly good implementation of it - it's burdened by ugly "Java-like" curly braces syntax, and legacy quirks like brain-dead local variable scoping. There really isn't much to love in there - the same ideas have been implemented much better elsewhere.

Motherfucking snakes in a motherfucking browser?

[Anonymous Coward]

I've had it!

Pointless

[Mystra_x64]

Seems pretty pointless. Either learn a language or drop it.

I'd prefer native Ruby in browser though.

Re:Pointless

[chrysalis]

There is already a Ruby VM that runs in a browser: Hotruby : http://hotruby.yukoba.jp/

John Resig even blogged about it ages ago: http://ejohn.org/blog/ruby-vm-in-javascript/

Also, JS.class, while not a Ruby VM, is pretty cool and actually useful: http://blog.jcoglan.com/2009/06/08/jsclass-21-an-improved-pacakge-manager-proper-hashes-and-lots-of-ruby-19-goodness/ - http://ajaxian.com/archives/jsclass-21-released

Re:Pointless

[Mystra_x64]

I maybe slept under a rock or something... I'll look there, thanks.

Re:Pointless

[Anonymous Coward]

As if browsing wasn't already slow enough.

Re:Pointless

[Mystra_x64]

I don't even turn Javascript on, so it *is* fast. Besides Ruby 1.9 is way faster than 1.8.

Re:Pointless

[NNKK]

Compiling languages to other languages is nothing new. In fact, it's quite fundamental to computer science as we know it.

At the lowest level, assembly is "assembled" into the native language of the target machine, though modern assemblers handle enough syntactic sugar you could reasonably call them simplistic compilers. In either case, one language is effectively converted to another.

Further, it's quite typical for medium- and high-level languages, such as C, to be compiled down to some form of assembly. Sometimes, as in the case of GCC, they even hop through another, compiler-specific intermediate language on the way.

Know how most C++ compilers have worked? They reduce it to C, and then compile *that*.

Indeed, many language implementations have used C as an intermediary. It works pretty well for this purpose, being intended as a standardized, multi-platform assembly, and you immediately gain the invaluable ability to trivially interface with any library that has C bindings.

And that Ruby interpreter you love? The Ruby gets converted to the bytecode of whatever VM it's running on, which was most likely written in C, which was then converted to some intermediate language before going to assembly and machine code.

Ultimately, your logic only holds if you believe everyone should be working directly in machine code.

GWT for Python?

[mcvos]

It's not entirely clear to me what Skulpt is exactly, but Pyjamas is apparently GWT ported to Python, which sounds like a really cool idea. Now if somebody did the same thing with Ruby and Scala, I'd be really happy.

Javascript is just way too stupid to program manually, but currently we're in the odd situation where we're writing server stuff in Ruby, and browser stuff in Java. That's just wrong.

Re:GWT for Python?

[lkcl]

you're looking for RubyJS. sadly, funding has not been forthcoming in order to carry RubyJS forward. the compiler is excellent; the insights into the technical issues behind dynamic language translation were very useful (even to python translator developers) - but martin ran out of time/money/enthusiasm due to the lack of interest shown, so he only got as far as creating HTML and Button for RWT (Ruby Web Toolkit).

Re:GWT for Python?

[Anonymous Coward]

Exactly how is JS "way too stupid" to program manually? JS suffers from the problem that everyone thinks they're a rockstar at it, and that it's a language doomed to onmouseover="this.style.backgroundColor='#FF0000'". It's not, and there is amazingly complex stuff out there written in JS. It has features languages like PHP can't even dream of.
It has been abused for years, and as such ignorant people have the opinion that it's just a toy language, when really it's incredibly powerful. You don't need a framework or a translator to write JS, same as you don't need one to write C. Learn the language, and you'll see it's not hard to program complicated stuff in it.

Look at Ext.js, Processing.js, and YUI, and tell me JS is "just way too stupid to program manually".

Re:GWT for Python?

[loufoque]

Javascript is just way too stupid to program manually

Not more than Ruby or Python.
Don't confuse languages with libraries.

Re:GWT for Python?

[Xtravar]

Eh, a language is only as good as its standard library. I don't like telling people to download/build/install a number of other libraries of specific versions just to run/build my stupid application.

It's just a fact of life. For personal applications (where it's hard enough to get people to use your app anyway) and work applications (where licensing causes multiple headaches on this front).

And no, I don't use Ruby, Python, or Javascript so I can't comment on any of their libraries.

Re:GWT for Python?

[John Betonschaar]

It has been abused for years, and as such ignorant people have the opinion that it's just a toy language, when really it's incredibly powerful.

Maybe the fact that it's so easily abused, used as a toy language out of ignorance, and that the stuff written in it is mostly badly-written crap that doesn't use it's incredibly powerful features already shows why you might say it's way too stupid to program manually.

Re:GWT for Python?

[loufoque]

Eh, a language is only as good as its standard library.

So C and C++, ones of the most used languages in the world, are worse than fuck since their standard library is ridiculously small?

It's not like all the best and more important software is written in those languages... (virtually all operating systems and major applications)

Re:GWT for Python?

[rickkw]

Ur... how is Python any less different? It's one of the most easily abused, badly written language because it is so flexible. There is practically no rule with Python.

Re:GWT for Python?

[Frnknstn]

One of the founding principles of Python is 'There should be one-- and preferably only one --obvious way to do it.'

http://www.python.org/dev/peps/pep-0020/

The python language (circa 2.4) wasn't *flexable*, it was rigid while still being easy to use. As a result, python code written by your average script monkey is more readable.

Re:GWT for Python?

[rickkw]

The principles sound good. In practice, things are done by conventions. Special method and member names for example. There is no access level modifiers, and as a result, every member, whether it is a method or a data in a class is public. Encapsulation is not enforced by the language. In fact, object data, methods, even class meta information is managed by dictionary. Any client who gets hold of a reference of a class can dynamically change it. To me, it *IS* a flexible language, but is often abused by creative python coders. My experience with python is that it is very easy to learn and to write, but hell to read if it is written by others.

Re:GWT for Python?

[Haeleth]

As a result, python code written by your average script monkey is more readable.

Observe, my friends, the complete absence of citations to support this assertion. Observe the vagueness of the claim, and the lack of any reference even to an objective metric by which this alleged "readability" is supposed to be measured.

This is what is technically known as "bullshit". It is founded only on the claimant's personal prejudices, not on anything that could realistically be termed "evidence". The poster truly, genuinely believes that Python is better than Javascript -- but he has absolutely nothing to back up this view other than a religious conviction. So he quotes the sacred texts, instead of searching for a rational argument.

Re:GWT for Python?

[Haeleth]

My experience with python is that it is very easy to learn and to write, but hell to read if it is written by others.

My experience exactly. It is no better, and no worse, than any other language I've ever used. (Except FORTRAN (the old-fashioned sort), which is worse. But that's getting off topic.)

Python advocates often seem to be under the impression that inconsistent indentation is the leading cause of unreadable code. This is simply not true in my experience. I have seen code in some languages that used no indentation at all, and yet was perfectly comprehensible.

The real causes of unreadable code are bad or misleading variable and method names, poor or inaccurate comments, and spaghetti algorithms. And Python does absolutely nothing whatsoever to prevent any of these things. It doesn't even discourage the use of global variables!

Re:GWT for Python?

[Frnknstn]

Observe, too, the response that falsely assumes prejudice, and so reveals its own.

I never stated that Python is a better than Javascript, or any flavor of ECMA script. My claim, once again, is that in the hands of poor programmers, Python code is more readable than Javascript. No more, no less. I find it staggering that you misinterpret such a short message so poorly.

Observe too how quickly this poster hides behind his a veil of agnosticism. /Of course/ I provide not objective measure, we both know none exists. /Of course/ I provide no magical archive of all the shitty scripts ever written, with annotations, as none exists. I assumed that a vaguely competent reader would understand that I have no source but my own experience.

Except, once again, you missed the point entirely: Regardless of what you believe on the readability issue, my post was a rebuttal to an utterly idiotic and barely literate claim that 'There is practically no rule with Python.'

There is indeed rule with Python, and it much so good to in age of language to be part of design successes, like such as 'sacred texts'.

To restate that yet again, and in yet another way, Python was designed from early on to be the opposite of what the GGP posted, and I have a link to an ancient 'sacred text' to prove it. If you trust that document, or have seen evidence for or contrary to its application in daily Python life (and such establishing or denying that trust, again, I left as an exercise for the competent reader) then it follows logically that the GGP statement 'It's one of the most easily abused, badly written language because it is so flexible' is false.

Re:GWT for Python?

[Frnknstn]

There are indeed access level modifiers, even though it is possible for the persistent programmer to gain access to all of the interface.

In my opinion, that is one of the strengths of Python: it gives programmer the benefit of the doubt. In standard OOP dogma, data obfuscation is a requirement; Python recognises that sometimes this conservatism can lead to hideous hacks, and thus trusts the programmer to make up their own mind: use the documented interface, or mess around with the internals to allow yourself even greater programming achievements?

To my mind, this should not affect the legibility of a program. If you see a cowboy who does overstep this boundary, you can easily see his intent.

Re:GWT for Python?

[Frnknstn]

I don't fully understand how the indentation issue applies here. The indentation speaks to the rigidity of the language: if the code looks like it's in a block, it's in a block. There is no reason to not indent the code, so why not enforce the indentation of the code?

I agree wholeheartedly on the naming issue. It is one of my own weaknesses. I have also seen some terrible atrocities performed by others here: code that used for variable names the same words in different (natural) languages within the same scope. *shudder*

Spaghetti code I don't see as a readability issue. If anything, it's robustness issue. It may be due to where I lie on the whole
"goto considered harmful [considered harmful [considered harmful [... ]]]" issue, but I believe that in most cases, the obvious way to express a function is the most understandable way. That is why Python doesn't focus on preventing this: it instead cuts to the root of the problem. Python attempts to keep the understandability and reduce the risk, by using features such as the 'with' statement.

There is also no easy solution to bad comments, but Python /does/ try to improve the situation, with docstrings and by attempting to foster 'self-commenting code'.

And as for global variables, I believe these to also be unfairly maligned: used judiciously, they can reduce complex problems into simple problems. If there is a price to be paid, it is possible in bugs rather than readability.

Re:GWT for Python?

[Frnknstn]

Rereading this post, it is unnecessarily confrontational and derisive. I apologise.

Re:GWT for Python?

[LordVader717]

The difference is that C and C++ applications are generally compiled before they're distributed, wheras Javascript is interpreted directly from source code on the web.

Re:GWT for Python?

[loufoque]

Doesn't change anything.
Just ship the libraries with the application, or "link" them statically with the code.

Nice to have

[Anonymous Coward]

I write python webapps and sometimes there are things I'd love to do in the browser but can't. For example using pypdf or reportlab browser-side would be really useful .

How about a Javascript - to - python convertor?

[ggpauly]

In most ways (no explicit integer type being an exception) Javascript is a remarkable and beautiful language. It has libraries available on a server near you through Dojo, among others. Javascript is one of the best things about browsers.

What browsers need is a workable CSS and DOM interface (although the DOM interface has improved in recent years). But these are not issues with Javascript per se. Cleaning up the browser programming environment is not about getting rid of Javascript.

From TFA: """
anyway, just thought there might be people who would be intrigued (or
horrified enough to care what's being done in the name of computer
science) by either of these projects.
"""

Not horrified, but I wonder if W3C politics is creating unforeseen consequences.

Re:How about a Javascript - to - python convertor?

[Anonymous Coward]

In most ways (no explicit integer type being an exception) Javascript is a remarkable and beautiful language.

Sort of. It actually sucks, just look at the gigantic EMCA specification and all the convoluted crap in Javascript. The semantics are nice though. The thing is, Lua also has these beautiful semantics and is actually quite similar to Javascript. EXCEPT, Lua actually is beautiful. Very tiny, easy to embed, easy to extends, fast, powerful, simple specification. All that and it does practically the same thing as Javascript. Lua is what Javascript should have been.

Re:How about a Javascript - to - python convertor?

[s4m7]

Cleaning up the browser programming environment is not about getting rid of Javascript.

Maybe not, but javascript is not a good language, it's a bad language with some good features. The awful scoping mechanism is evidence of this enough. The intrinsic objects are too limited to be useful, so much so that now there are more than 4 different common framework projects to handle all the inconsistency in implementation and they're all incompatible with each other. anonymous functions are great but they make debugging a giant pain the arse.

i would like to see a viable alternative language to javascript, just for variety's sake. It's just had layers of crap pasted on top of it since 1995 or whatever and it'd be nice to see a new approach that fits what people actually use it for these days.

Re:How about a Javascript - to - python convertor?

[lkcl]

What browsers need is a workable CSS and DOM interface (although the DOM interface has improved in recent years).

yes - it's these DOM interfaces that i used for the pure-python port of pyjamas. the first one (webkit) i literally had to create, myself (it took 8 weeks). the second one, xulrunner, used a component created by the OLPC team, called hulahop; the third one, for windows only, uses python COM (the comtypes library) and python ctypes.

But these are not issues with Javascript per se. Cleaning up the browser programming environment is not about getting rid of Javascript.

From TFA: """
anyway, just thought there might be people who would be intrigued (or
horrified enough to care what's being done in the name of computer
science) by either of these projects.
"""

Not horrified, but I wonder if W3C politics is creating unforeseen consequences.

it has to be said that the attitude of the webkit developers (one in particular who can be easily identified) has been incredibly bad, towards the free software glib/gobject bindings i created for webkit's DOM model. nobody should have to put up with the kind of disrespectful treatment i was subjected to, and other contributors whom i've encouraged and trained to help out have been so intimidated by the webkit developers that they are unwilling to even make themselves known to the webkit team, in case they get treated the same way.

it's a long story, and the webkit team will get burned for it, one way or another.

Re:How about a Javascript - to - python convertor?

[ggpauly]

The link to Douglas Crockford's site in the parent was to an article entitled "The World's Most Misunderstood Programming Language".

The awful scoping mechanism

From the brief survey of Javascript on Crockford's site:
"""
When used inside of a function, var defines variables with function-scope. The vars are not accessible from outside of the function. There is no other granularity of scope in JavaScript. In particular, there is no block-scope.
"""
iow, use the var keyword. Programmers who do not know this ONE RULE (TM) are bitten by mysterious insects. Use a lint program if needed.

Functions are objects in Javascript, so this effectively allows, in either functional or object styles of programming, programmers to freely and simply define their variable scoping.

Procedural programmers used to simple block scoping (Hi COBOL fans!) may need to find a mechanism to cope with this. But I'd suggest using OO techniques if your program is complex enough that this is a problem. Javascript allows simple, non-demanding OO. If you like your OO authoritarian then Google has a Java-to-javascript translator.

intrinsic objects are too limited to be useful, so much so that now there are more than 4 different common framework projects

Python has one official library (and many 'unofficial' modules too), without which Python would be very limited. Javascript has many unofficial libraries. Welcome to the free world.

btw, I use Python, and I get Twisted Python at least to some extent. Twisted's deferred abstraction is mimicked in Dojo Javascript. I use Python on the server and Javascript + Dojo on the browser. Python has less warts and more modules. Javascript has astounding power in simplicity, as in the scoping rule.

Re:How about a Javascript - to - python convertor?

[Anonymous Coward]

This is something i can agree with.

So much of JavaScript is really good, but actually programming it is hellish.
The interfaces between it and HTML/CSS are sub-standard. (IMO)

I wouldn't want an alternative, i would just like it to be fixed.
But getting web browser vendors behind it is the hardest part, especially when it comes to everyone's favorite company, Microsoft. (although admittedly recently they have been pretty decent, which i am really happy about)

I wouldn't mind if it evolved some more functionality present in Java, we are getting closer with things like LocalStorage and newer features which makes me really excited.

Re:How about a Javascript - to - python convertor?

[omuls are tasty]

On the surface, JS is a really nice language, but it really has a fair share of warts which will bite you. And yes, I'm aware that Javascript is neither DOM nor CSS. For those interested, Bob Ippolito (the author of MochiKit) wrote the best "Javascript sucks" article I've ever read.

Re:How about a Javascript - to - python convertor?

[Unoti]

What browsers need is a workable CSS and DOM interface (although the DOM interface has improved in recent years).

Jquery makes working with the DOM incredibly easy. It completely changed and radically simplified nearly all of the Javascript that I write. If you haven't explored it, you should.

Re:How about a Javascript - to - python convertor?

[BitZtream]

i would like to see a viable alternative language to javascript, just for variety's sake. It's just had layers of crap pasted on top of it since 1995 or whatever and it'd be nice to see a new approach that fits what people actually use it for these days.

Why? So in 2025 you can sit around talking about the new language thats fills its roll perfectly but isn't to your liking and wasn't the perfect vision you thought it would be 15 years ago? Javascript has barely changed in the last 15 years. The environment that javascript deals with has changed a lot, but the language, not so much. Any language (or more appropriately put, any environment) that has 15 years of patches for an environment that changes rapidly is going to look and feel the same, regardless of if it starts off with your precious languages or not.

Here is reality for you developers of the world, if you think your language is better than all the rest, or some other language should go away, then you are a shitty programmer. The language does not make the programmer, the programmer does. If you find a language/environment difficult to use, you are the shitty part of the equation. Languages are just that, languages. They describe things. You are the one that has to figure out how to describe what you want, if you can't do that, the language or environment isn't the problem, you are.

Stop blaming JS for you being a shitty developer who can only parrot things out in whatever language you learned from your CS professor.

Re:How about a Javascript - to - python convertor?

[s4m7]

yes I know about the var keyword and use it quite religiously. However let me give a specific example of how crappy the JS scope rules are.

I can globally scope a variable in JS, let's call it foo. If I am a sloppy programmer and write a function accessing a variable named foo without var'ing it within that function, it will access the global var unless foo is an argument for my function.

oh crap but it's worse because my functions are objects. So i can have a function foo() and a variable foo as properties of the same class and just have to be careful which one i mean in which context. And then, I can always assign the function foo() to the variable foo, and if i still have it declared globally, i have to make sure and use the right context.

speaking of context, take a look at any of the frameworks that try to make use of JS's OO nature, and the many and various tricks they use to make sure that 'this' actually refers to the parent object and not another unrelated object, or the specific member-function context since objects are functions. Most of it quickly becomes unreadable garbage.

Welcome to the free world.

yes yes, python has libraries too, and they have this fantastic feature called namespace. check it out sometime. If you have two or more third-party libraries loaded in python it's extremely unlikely that they conflict, because of namespaces. in JS, unless you enable compatibility mode with jQuery, you're up a creek, as you're just going to get whichever meaning of whichever function is defined last in parse order. it's insanity.

Re:How about a Javascript - to - python convertor?

[s4m7]

wow, cs rage much?

I am perfectly capable of programming in JS. I've written a number of extremely useful classes in the language and I don't care for your tone.

if you think your language is better than all the rest, or some other language should go away, then you are a shitty programmer.

well, hello mr. strawman. I never declared that I wish javascript would go away, and I don't suggest any "better" language should take its place... I merely asked for an alternative that reflects how it is used in a modern sense more accurately.

Why? [...]Javascript has barely changed in the last 15 years.

Thank you for answering your own question. js wasn't a good language in the first place and 15 years of cobbling have only gone on to expose and underscore its various weaknesses. JS can do quite a bit, and it's undoubtedly useful. that doesn't change the fact that it's fundamentally a poor structure for doing what people do with it now: namely DOM scripting and asynchronous requests. I don't disagree that in 15 years whatever we develop today probably won't be a good fit for what we're doing with it then: this however is no excuse for a complete lack of progress.

If you find a language/environment difficult to use, you are the shitty part of the equation.

well that's an extremely lazy way of looking at things. Yes languages are just that, languages, and since there's no excuse for being a "bad programmer" and expecting your tools and vocabulary to be up to the task you're attempting to address, we should all still be programming in assembler using punchcards by your logic. God forbid we make use of decades worth of brilliant thought on the topic of how programming languages ought to be structured and keep things moving forward.

Re:How about a Javascript - to - python convertor?

[Anonymous Coward]

Python has the same "function-only" scope, and no one calls that broken. The fact that javascript's *default* scope is global is seriously wrong though. Javascript is also not without other nasty warts, but very few languages are free of warts, and the ones in JS are hardly show-stoppers.

My main problem is the platform: all the good JS implementations are still jailed in the browser, with little or no access to useful platform technologies like IPC, serious file I/O, or GUI toolkits. That's really been what keeps me from taking up Javascript -- not everything is a web app. I'm aware of things like Rhino, but v8 and tracemonkey run circles around it. If I'm going to target the JVM, I may as well use Groovy or Clojure.

Re:How about a Javascript - to - python convertor?

[Blakey Rat]

The intrinsic objects are too limited to be useful, so much so that now there are more than 4 different common framework projects to handle all the inconsistency in implementation and they're all incompatible with each other.

Whoa, slow down. Blame where blame is due. That point is DOM's fault, but Javascript's. (Well, ok, DOM's not to blame for the frameworks being incompatible with each other, but the shittiness of DOM is why they exist at all.)

If you implemented Python or Ruby in a browser, it would have the exact same problems with DOM.

Re:How about a Javascript - to - python convertor?

[BikeHelmet]

Javascript used to have a really nice scoping mechanism, called eval(); It was blazing fast too, in every browser. The basic idea was when you create an object, you tell it its name.

var myPlayer = new Player('myPlayer');

Then it uses eval to generate methods that point to itself. This was necessary because all callbacks are global in Javascript. Unfortunately, FF3 disabled this fine use of eval, so now, you have to do weird scoping shit that slows it down.

I like how lax Javascript is. A variable can be both an integer, float, and a string depending on how you use it. It's the same thing that attracted me to asm - where an int can be a value, a pointer, or part of an object like a String. And what's really neat, is you decide how you handle it by opcode. There's none of that typecasting shit. :P

Re:How about a Javascript - to - python convertor?

[smoker2]

Javascript is a SCRIPTING language, not a programming language. Give it the respect it deserves, i.e. not much. Pretty soon HTML is going to be classed as a low level language at this rate. What's next, a scripted interface to VB ? {yeah, I know }

Re:How about a Javascript - to - python convertor?

[Junta]

The scoping mechanism I agree is awful, but it's also one reason I am also frustrated by python for sophisticated applications. I have not found a way to acheive more granularity than Javascript in Python apps (i.e. arbitrary block scope). One may fairly argue that they feel those circumstances should be broken up into functions if it seems required to have a block-scoped variable, but sometimes it just works better to know before a function ends that you will get errors if you accidentally use that variable where you didn't intend and spinning off functions could be awkward.

However, I recognize that Python's vision of a more straightforward paradigm would be compromised by that feature. For python, it's not so bad as it isn't a mandatory standard and usually lives alongside other intepreters with different goals. I do agree that Javascript is a larger problem, since every language that you could implement in a browser must be ultimately executed under Javascript, and thus choosing an alternative if it doesn't suit your needs isn't as viable.

Re:How about a Javascript - to - python convertor?

[Abcd1234]

I can globally scope a variable in JS, let's call it foo. If I am a sloppy programmer and write a function accessing a variable named foo without var'ing it within that function, it will access the global var unless foo is an argument for my function.

Uhh... wtf... that's exactly the way virtually every other language works, as well, include good ol' fashioned C (Perl is another excellent example). I fail to see how this is even remotely surprising.

So i can have a function foo() and a variable foo as properties of the same class and just have to be careful which one i mean in which context. And then, I can always assign the function foo() to the variable foo, and if i still have it declared globally, i have to make sure and use the right context.

So what? Lisp has separate namespaces for various things. So does Perl. Again, this is hardly unique, and it's really not a big deal, IMHO.

yes yes, python has libraries too, and they have this fantastic feature called namespace. check it out sometime. If you have two or more third-party libraries loaded in python it's extremely unlikely that they conflict, because of namespaces. in JS, unless you enable compatibility mode with jQuery, you're up a creek, as you're just going to get whichever meaning of whichever function is defined last in parse order. it's insanity.

Yup, I totally agree... namespaces and modules are both major issues with Javascript. But adding that functionality would be trivial enough... it just hasn't been done yet.

Re:How about a Javascript - to - python convertor?

[multipartmixed]

Please, Oh Wise One, tell us the difference between a script and a program.

Re:How about a Javascript - to - python convertor?

[Razalhague]

Here is reality for you developers of the world, if you think your language is better than all the rest, or some other language should go away, then you are a shitty programmer. The language does not make the programmer, the programmer does. If you find a language/environment difficult to use, you are the shitty part of the equation. Languages are just that, languages. They describe things. You are the one that has to figure out how to describe what you want, if you can't do that, the language or environment isn't the problem, you are.

Riiight. That's politically-correct bullshit. Languages can very easily make things easy or difficult. Languages can be shitty. Environments can be shitty. If you don't believe me, I can come up with a shitty language and environgment just for you. It'll take a couple of days, but I can guarantee it'll be really shitty. Sure, programmers can be shitty too (and that's often the case), but that doesn't mean there aren't differences in quality between languages and environment.

Re:How about a Javascript - to - python convertor?

[shutdown -p now]

iow, use the var keyword. Programmers who do not know this ONE RULE (TM) are bitten by mysterious insects. Use a lint program if needed.

Functions are objects in Javascript, so this effectively allows, in either functional or object styles of programming, programmers to freely and simply define their variable scoping.

Procedural programmers used to simple block scoping (Hi COBOL fans!) may need to find a mechanism to cope with this. But I'd suggest using OO techniques if your program is complex enough that this is a problem. Javascript allows simple, non-demanding OO. If you like your OO authoritarian then Google has a Java-to-javascript translator.

Sorry, but that's just bullshit. Scoping of local variables has nothing to do with OO or lack thereof; in fact, virtually all other OO languages which have explicit variable declarations do block scoping, while COBOL never had it. Nor does this have anything to do with functions as first-class objects.

In fact, I know of one single language that had the same awful local scope rules as JavaScript - it's VB6.

Re:How about a Javascript - to - python convertor?

[shutdown -p now]

Here is reality for you developers of the world, if you think your language is better than all the rest, or some other language should go away, then you are a shitty programmer.

I don't know of any "silver bullet" languages, though I definitely have favorites - and I do not wish all others to go away.

What I do wish, however, is for badly designed languages which don't have any redeeming qualities to go away. And, yes, JS is on that list. Though, admittedly, way below PHP.

On a side note, an example of a badly designed language with a redeeming quality is Common Lisp - it's ugly as hell, but nothing else matches it in terms of sheer power.

Really interesting

[celibate for life]

Specially given it's Python, I'm really sympathetic towards Python. OTOH, all that "rich" content for webpages fetish bothers me a little. I tend to think of webpages as magazines or newspapers, I prefer text and static images only.

Now I've heard everything

[Ancient_Hacker]

Just when you thought things could not get any crazier, there's this story. Let's hope it's an early April Fool.

There's no way one could simulate more than about 12% of Python's complex OO semantics in JavaScript.
Python itself already has a hard and slow slog trying to perform all its tricks.

To add yet another layer of translation or simulation sounds like a lose-lose proposition. Slower and hopelessly inexact.

Not to mention many of the more useful Python modules have a considerable C component, making them completely unusable as JavaScript.

( Yes, I know, in theory JavaScript is Turing-complete, so you can do anything in it, given a universe full of CPU's ).

Re:Now I've heard everything

[lkcl]

Just when you thought things could not get any crazier, there's this story. Let's hope it's an early April Fool.

nope. it's not. and i didn't mention in the article that pyjamas-desktop can run the python as a desktop app, either. including the GWT Canvas ported code, under the MSHTML engine. after all, the IE/MSHTML gwtcanvas is just creating VML nodes, so perhaps it shouldn't come as a surprise that it works, but it's still pretty cool all the same.

There's no way one could simulate more than about 12% of Python's complex OO semantics in JavaScript.

wrong. sorry. javascript is a drastically underestimated language. dreadful to work with if you don't know what you're doing, but incredibly powerful at the same time.

a javascript implementation of "type" - not the 1-arg version but the full 3-arg version - was initially implemented in 85 lines of javascript (it's a bit more, now).

we use that functionality to dynamically create, classes, supporting multiple inheritance and more.

pyjamas has also implemented decorators _and_ properties; kees is currently working on "yield" after skulpt's developers started working on it. not "yield by cheating and using FF built-in support for yield", but "yield" as in doing it the hard way, by analysing the state of the function and adjusting / jumping to the correct point in the function on each loop.

you really should take a look at the regression tests

Python itself already has a hard and slow slog trying to perform all its tricks.

To add yet another layer of translation or simulation sounds like a lose-lose proposition. Slower and hopelessly inexact.

slower, yes - "hopelessly" inexact: no. for GUI purposes, _if_ you've designed the application correctly (i.e. along MVC / client-server lines), then the "-O" option which switches off all the python "strict" compatibility, is perfectly sufficient.

so, "letting things fall through" to javascript, and allowing int(width) + "px" to succeed, and [1,2,3] + [4] to fail, is "good enough for most purposes".

Not to mention many of the more useful Python modules have a considerable C component, making them completely unusable as JavaScript.

wrong again. sorry. two reasons. three.

1) pygtkweb showed that it is perfectly possible to make a seamless / transparent JSONRPC service that ships function call arguments over to a server, for execution server-side, starting from e.g. "import md5"

2) pyjamas' implementations of datetime, md5, urllib, time and a few others is growing as users contribute to them. thus, the pyjamas GUI library fits the *users* needs, on an ongoing basis.

3) if you _really_ can't do without the full semantics of python, but want the benefits of full HTML, CSS, NPAPI plugins etc., use one of the pyjamas-desktop ports. there's MSHTML, XULRunner and PyWebkitGTK to choose from.

Re:Now I've heard everything

[Anonymous Coward]

so, "letting things fall through" to javascript, and allowing int(width) + "px" to succeed, and [1,2,3] + [4] to fail, is "good enough for most purposes".

Have you tried using a separate add() like method in which you can check for Array, int etc? Or does that hurt performance too much? This is an interesting difference between Pyjamas and Skulpt: Skulpt uses special methods like Python's __add__, so it can be more compliant (operator overloading etc.) but it's slower than directly calling JS' add-operator...

Re:Now I've heard everything

[lkcl]

Have you tried using a separate add() like method in which you can check for Array, int etc?

yes, that's in the --strict option. pyjamas actually comprises _two_ compilers, strictly speaking: one is "fast but more like javascript"; the other is "slower but more like python".

Or does that hurt performance too much?

i was surprised to find that it doesn't. (not as much as say creating an anonymous function on-the-fly in order to provide the full and correct semantics of getattr on class member functions)

Re:Now I've heard everything

[querent23]

Rob Knight? Is that you? It's Will!

Slooooooooowwww!

[Anonymous Coward]

Haha.. That was my first thought anyway. I guess it's confirmed:

the initial experiment some months ago, with pyjamas 0.5, produced a python ACcellerator with a 10x performance increase; the latest 0.6~svn pyjamas compiler results in a python DEcellerator with a [finger-in-the-air] 10x performance DEcrease, thanks to the addition of several python strictness features

Of course, this is a 'just to do it' project', so I suppose performance is probably more of a secondary goal. :-)

iPhone application?

[cwike]

I wonder whether this would function correctly on the iPhone, because apple cannot restrict this, it is only JavaScript after all.

Re:iPhone application?

[nneonneo]

I have an iPod touch running iPhone OS 3.1.1, so I tried these two projects out.

Skulpt works, but the console does not (I had to use the quick-links to test code). This is relatively easy to fix by using a textbox instead of using keyboard events. It would be very simple to write a simple webapp which evaluates Python code in the Safari browser. However, as I see it, Skulpt is still quite immature -- it doesn't implement much of the language (e.g. classes work, but can't be instantiated because Skulpt thinks you are trying to call the type object, instead of constructing it), and it doesn't do imports at all.

Pyjamas works extremely well, though it is compiled as pure JS and thus lacks (AFAIK) an "exec" method to run arbitrary Python code.

Given that Skulpt features a decent Python parser but lacks much of the core functionality, and Pyjamas implements a lot of functionality but lacks a parser built in JS, I think the projects would be mutually beneficial.

Re:iPhone application?

[lkcl]

Pyjamas works extremely well, though it is compiled as pure JS and thus lacks (AFAIK) an "exec" method to run arbitrary Python code.

i'm working on it. last week i back-ported skulpt's parser and AST code from javascript to python, and regression-tested it; now it's a matter of improving the pyjamas compiler to be able to successfully compile that python into javascript, and we're bootstrapped.

Re:iPhone application?

[ceoyoyo]

Thanks, Pyjamas looks like a great project. I've always wanted to be able to code client side web stuff in Python.

Re:iPhone application?

[lkcl]

there are a ton of different ways, now: i've been maintaining a list on the python wiki, WebBrowserProgramming page. pypy used to have a -to-javascript back-end (now abandoned); there's titanium appcelerator (which supports IronRuby and IronPython); there's PyXPCOMExt and a few more besides.

Re:iPhone application?

[bcrowell]

Cool project! I use python for education (in my physics class), and would love to be able to tell my students just to go to skulpt.org rather than having them download and install a full python implementation (which they can't do in school computer labs). The big missing feature from my point of view is "import math." Support for cut and paste in the demo terminal would also be a big help.

A practical use

[slthytove]

As a high school computer science teacher, I can see a practical application of this. Currently, I think Python is one of the best languages to learn basic programming concepts with, in that it is relatively straightforward, powerful, and there's not much "voodoo" to prevent students from diving right into programming. It's possible to do some really cool things in Python with not much code.

However, one of the problems is that it can be difficult to give students a way to show off their code. Since it's an interpreted language, they can't just give an .exe or a .app file to someone else to show it off - they need to say, "Oh, go and install Python, and these libraries, etc." Yes, there are solutions such as py2exe and py2app, but getting these set up can be quite a task in itself. By running Python inside JavaScript, you basically open up the whole web-connected world as a potential audience to these budding programmers. It's much easier to say, "Hey, check out this link!" than "Hey, download Python (but get the right version) and this graphics library, then download my .py file, and open up a command prompt and type python blahblah.py!"

Re:A practical use

[ceoyoyo]

Actually, if you use pyobjc or whatever the Windows python packager/comiler is these days (py2exe?) you can do just that. They'll make you a self contained .app or .exe that you can just give to someone.

The web thing is pretty cool as well though.

Re:A practical use

[maxume]

They are still going to run into the problem that a lot of 'cool' stuff (graphics and whatnot) in Python depends on some C code.

Re:A practical use

[lkcl]

that's exactly why i posted links to the GWTCanvas and the GChart demos, as they show that it is in fact possible to do "graphics" using DOM manipulation. also, with WebGL coming in HTML5 to both webkit and firefox, it will be a simple matter of having a framework that creates the relevant DOM elements.

voila - instant control over 3D graphics code (written in c), from python or javascript.

Re:A practical use

[maxume]

He mentions py2app and py2exe, noting that getting them going can take quite a bit of effort.

Re:A practical use

[ceoyoyo]

You're right. Not sure how I managed to skip that whole sentence.

The setup for py2app and py2exe isn't that bad. Py2app comes preinstalled in Leopard and Snow Leopard after all.

You'd probably want to write some boiler plate to make it easy for the kids to get some instant gratification but you'd want to do the same thing with Pyjamas.

Re:A practical use

[ggpauly]

Why not teach Javascript itself?

It's a simple but powerful general-purpose object-oriented language. It's also a functional programming language with C-like syntax, closures, and lambdas.

A browser is the interpreter.

    **** Please read http://javascript.crockford.com/javascript.html before modding this down. ****

Re:A practical use

[BZ]

Javascript is not object-oriented in any of the traditional senses of the word. It provides features you can build an OO-like system on top of, but so does any language with closures and first-class functions...

Re:A practical use

[slthytove]

JavaScript has a lot going for it, but it also has quite a few downsides. Just off the top of my head:

• A very obscure sense of "type." While Python is looser than many languages in this regard, Python throws the concept of type out the window. The prototype system, while incredibly flexible, is best used by people who already understand object-oriented programming. It's difficult to start with that.
• No strong set of coding rules/guidelines. Semicolons are semi-optional, variables can be declared but don't have to be, functions can be defined using multiple syntaxes... Many beginning (high school-aged) programmers are used to a system where there is One Right Answer. Programming introduces the idea that there is more than one way to solve the same problem. To throw JavaScript's notion that there is more than one way to express the same answer into the mix seems like too much.
• It's great that JavaScript can be used from within a web browser. However, doing anything meaningful using JavaScript with a web browser requires at least a working knowledge of HTML and the DOM. I'd rather focus on the basics of programming separate from that first.
• Speaking of web browsers, JavaScript implementations from browser-to-browser have nontrivial differences. Again, I'd prefer to focus on the bigger concepts without getting bogged down in implementation details.

Re:A practical use

[Anonymous Coward]

You saw "they can't just give an .exe or a .app file to someone else" and skipped the rest so you could go NUH UH!! :P

Re:A practical use

[weston]

It's great that JavaScript can be used from within a web browser. However, doing anything meaningful using JavaScript with a web browser requires at least a working knowledge of HTML and the DOM. I'd rather focus on the basics of programming separate from that first.

Not necessarily. You can get a instant simple read-eval-print loop by pointing your browser here: http://www.squarefree.com/shell/

Or, if you've got a JRE (and there's not many machines that can't have one), you can download Rhino (http://www.mozilla.org/rhino/ ) and have an interpreter (with access to all the Java libraries) that you can run interactively or on files.

(You can also build Mozilla's SpiderMonkey or Google's V8 standalone to similar effect, but it's a bit more involved.)

Re:A practical use

[weston]

Javascript is not object-oriented in any of the traditional senses of the word.

It's quite object-oriented, just not class oriented, and easy enough to use as if it's class-oriented if that's what you want, even without libraries. The prototype-based object system features add object orientation beyond what's offered via closures.

Re:A practical use

[slthytove]

Exactly why I hope to work on getting (or see someone else work on getting) the new turtle module ported to work with Canvas objects. It has a couple very straightforward interfaces, and would be awesome for creating animations - and it has the added bonus of probably not being that hard to port.

Obviously a port of SDL (and thus all the libraries/modules that depend upon it, such as pygame) or pyglet is not likely to happen, but it seems like there will be quite a few simpler options. And this also opens the doors for other, web-Python specific libraries that use HTML/Canvas as their primary means of output...

Re:A practical use

[Cato]

Perl has a nice way to generate .exe's from Perl scripts, involving:

cpan -i PAR::Packer

pp -o myprog.exe myprog.pl

The end result is a .exe that can be run directly, no need to install (it unpacks itself then runs). Includes all CPAN libraries that you might use in the script.

See http://search.cpan.org/dist/PAR-Packer/lib/pp.pm - on Windows, install Strawberry Perl, and everything above will 'just work'.

Re:A practical use

[Anonymous Coward]

Here's an idea, inspire your students improve py2exe and py2app instead of bitching about it. Maybe they should put together a proposal for a Google Summer of Code project, then they can even get paid to do it and have a great item for their resume.

Google Translate Extended

[aoheno]

Announcing onelanguage dot com, an extension of Google Translate, ushering in an era where programmers need only learn one language and have it converted to another language of choice.

FAQ:

Q. How accurate is it?
A. Same as Google Translate. You have to learn the output language to know which parts of the language you already know result in garbage-out. We suggest you use our new Pidgin versions of Python, PHP, Java, and Ruby.

Re:Google Translate Extended

[lkcl]

i know you're joking, but there really _is_ a Visual Studio "universal translator" plugin available - i've seen it demo'd, converting c++ to java, to B, to ruby, to c#. it all used CLR as the intermediary. i heard that activestate were commissioned to add python to the mix, but, weirdly, it wasn't included in the release of the translator i saw.

In related news....

[mrops]

...they used a Perl script to convert Python to Javascript.

Re:In related news....

[tonique]

Yes, and it's a one-liner.

Antigravity

[Anonymous Coward]

I can finally make my browser fly!

Why don't browsers just support it?

[Blakey Rat]

[script type="text/python"][/script]. Let one of the major browsers implement it, and see if the others follow... there's probably already DOM-access libraries in Python, yes?

Seems to make a hell of a lot more sense than this translation stuff.

Re:Why don't browsers just support it?

[redhog]

That'd be damn hard. Python isn't made for sandboxing (google python and sandboxing, or restricted execution, and you'll see). If you did the script language=python implementation the "obvbious" way and just linked in the python interpreter into mozilla, you'd have a security hole big enough for a supertanker. There is Python support for extensions though - google PyXPCOM.

Re:Why don't browsers just support it?

[Blakey Rat]

Well, that's a point. I still think this whole concept is a little daft, considering that web scripting has been designed to be language-independent from day one. I mean, IE has been the only browser to really embrace it, but still-- no reason other browsers can't.

Re:Why don't browsers just support it?

[lkcl]

[script type="text/python"][/script]. Let one of the major browsers implement it, and see if the others follow... there's probably already DOM-access libraries in Python, yes?

Seems to make a hell of a lot more sense than this translation stuff.

there's two main ways in which this can be achieved:

1) pyxpcomext

2) appcelerator / titanium, with IronPython, via Silverlight/Moonlight.

the problem is - one that both skulpt and pyjamas avoid - you need browser plugins, in each case, to achieve the goal. the pyxpcomext plugin is a whopping TEN MEGABYTES because it literally contains the entire python runtime.

Re:Why don't browsers just support it?

[Blakey Rat]

I didn't realize Python was so large... 10 MB for the runtime? Ouch.

Either way, my point is that if you want Python supported in the web world, do it the proper front-door method, rather than this goofy language translation stuff. (Obviously, it would need to be implemented a plug-in until all browsers supported it) I still agree with that sentiment, 10 MB or not.

Just learn it.

[Anonymous Coward]

Seriously guys. What the hell. We've reached some bizarro meta level of abstraction now. With things like this and GWT, we're just making things worse. I used to absolutely loathe javascript. Then, I took the time to sit down and actually _learn_ the language and it quickly became one of my favorites. It really can be a lot of fun.

Go watch Doug Crockford's presentations on javascript. He makes some excellent points about just how misunderstood the language is. Yes, it has some nastiness in it, but you don't have to and shouldn't use those parts. The vast majority of javascript books, tutorials, and web resources are just terrible. There's a lot of chaff out there to winnow before you find the wheat.

Download some of the better javascript libraries. Use them. Take them apart. Learn how they did things. Just start playing... seriously, it's fun.
I highly recommend MooTools, jQuery, Prototype, and their ilk. Rip those suckers apart and bend the browser to your will. Muhahah!

I propose a new contest:

[Hurricane78]

Who can string together the largest number of platform layers over each other, and still have it running.

The first league will start in the 2 GB core memory and 2* 2 GHz (dual-core) CPU range with no other processor (like GPU) or storage (like HDD) usage.
Every type of platform is only allowed once.

Here is a list of platforms, to get you started:
- Emacs
- the CPU itself
- Virtual machine (e.g. VirtualBox/VMware)
- Browser(s)
- C/C++
- JavaScript
- interpreted Piet
- Python
- LOLCode
- Malbolge

Bonus points for achieving a circle jer^H^H^Hof platforms, so that no actual real program is ever executed.

Re:I propose a new contest:

[Hurricane78]

Oh, I forgot some very important ones:
- PHP
- Typo3's Smarty & others
- Wiki syntax (if possible)
- XSLT

Re:I propose a new contest:

[Pulzar]

For bonus points, make it all run on non-jailbroken iPhone ;).

Silverlight does this too

[zokier]

I know everyone hates Microsoft and its eeevil proprietary technologies but still, it can achieve nice things. A javascript library which parses python script-tags via Silverlight. Check it out: http://visitmix.com/labs/gestalt/

What browsers need...

[master_p]

...is to be buried deep down under ground and never see the face of the Earth again.

What I mean is that we don't need browsers, we need a code/data distribution system that lazily downloads application components/data.

Python implementations still suck

[Animats]

Python is quite a good language, but the implementations suck. This is holding back widespread use of Python. It's too slow, typically 10x to 30x slower than C. That's far worse than Java.

There have been several attempts at other implementations. But because Guido Rossum fights formal standardization of the language, treating his CPython implementation as a de-facto standard, everyone else has a moving target to hit.

Google (who hired Guido) likes Python, but they don't like the low performance. CPython is a "naive interpreter" (very little optimization). Worse, with the rather lame implementation the Global Interpreter Lock, not only can't it use a multi-core CPU effectively, multi-thread programs run slower on multi-core CPUs. (The threads fight over the lock in an embarrassingly inefficient way.)

Google is doing "Unladen Swallow", which is an attempt to bolt CPython to a just-in-time compiler to a virtual machine. It's not clear how well that will work out, but the end result will have more layers than seems to be indicated. The goal is 5x faster than CPython, which won't beat Java, let alone C/C++.

It's cute that Python to JavaScript translation is possible, but it's not going to help much on the performance front.

For a few years, the great hope of the Python community was PyPy, but that had too many goals, was being developed in "sprints", and after five years, the European Union pulled the plug on funding after it was slower than CPython.

Shed Skin, which is a Python to C++ hard-code compiler, is currently the lead in Python performance, but it doesn't yet implement the whole language. Still, with about two people working on it, Shed Skin is doing better than most of the bigger projects. Shed Skin does automatic type inference. Python doesn't have declarations, but with enough analysis, the compiler can figure out what types each variable can hold and generate hard types, which makes for much faster code.

Re:Python implementations still suck

[Hohlraum]

Why is it ok for Java to be slower than everything that came before it? Because supposedly its easier to use and hardware is always getting cheaper. Why is it ok for Python to be slower than Java? Because it IS easier to use and hardware is always getting cheaper.

Re:Python implementations still suck

[jellomizer]

It really wasn't OK for Java to be slower then languages that came before it. Its success is rather limited. (now I opened the door to all the JavaDevelopers and IBM Trolls) Java was meant to be a replacement for for all those apps that are out there. But it has done little in terms of front end applications, where it was hoping to succeed the most. Why because of its poor performance, on standard PC and especially with GUI's Even using a fast PC you know when you are running a Java App. That is why Microsoft Visual Studios even with the abomination of .NET virtual machine garbage, has made it more popular for front end development then with Java. Because it performs better.

Saying that is bad because it is slower then Java means that Java is really slow and people are not happy with that so anything slower will make us more unhappy.

Re:Python implementations still suck

[BitZtream]

It's cute that Python to JavaScript translation is possible, but it's not going to help much on the performance front.

I agree, its very cute that some people are doing it.

But this better be a school project or something, otherwise its just a waste of resources, these guys are obviously talented. If they are still learning or this is just a side project for the hell of it, fine. But please, put the effort into some more useful projects if possible.

Re:Python implementations still suck

[OrangeTide]

Saying that is bad because it is slower then Java means that Java is really slow and people are not happy with that so anything slower will make us more unhappy.

What?

Re:Python implementations still suck

[Joe Tie.]

Personally, I don't see what's wrong with coding for the fun of doing something unique and fun. Seems like looking at art and saying "But what's it DO?"

Re:Python implementations still suck

[Anonymous Coward]

PyPy, but that had too many goals, was being developed in "sprints", and after five years, the European Union pulled the plug on funding after it was slower than CPython.

PyPy funding ended because EU projects run for a set amount of time regardless of success or failure. The EU doesn't usually pull the plug on failing projects, and PyPy was actually quite successful by the low EU standards--it produced working code and other people were using it.

Re:Python implementations still suck

[speedtux]

That is why Microsoft Visual Studios even with the abomination of .NET virtual machine garbage

I actully prefer the .NET virtual machine garbage to the Java virtual machine garbage, not because it's faster, but because it has features like pointers, structure return, and working templates.

Re:Python implementations still suck

[lkcl]

Google is doing "Unladen Swallow", which is an attempt to bolt CPython to a just-in-time compiler to a virtual machine.

It's cute that Python to JavaScript translation is possible, but it's not going to help much on the performance front.

thanks for posting this - it's interesting to see peoples' insights.

i'm aware of the unladen/swallow effort: they're replacing the FORTH-based bytecode engine with LLVM JIT compilation.

on their roadmap is "unboxing" of the http://python.org/ c code types (Object/longobject.c, Object/intobject.c, Object/stringobject.c etc.)

basically the plan is (i believe!) to provide reimplementations of intobject.c's __add__, __mul__ etc. to call LLVM routines instead of straight c code. in this way, they intend to keep python "c code" module interoperability, as long as you replace the libpython2.6.so with an unladen/swallow one.

_as long as_ the speed was still there, i would like, at some point to do the same trick - but with Google V8 javascript engine, instead (and, for fits and giggles, throw in spidermonkey as an option as well). basically, the implementation of intobject.c's __int__ would have a pointer to a javascript object, in which there would be an __int__ function; a call in python from a standard python c-based module to create an int would result in the creation of a javascript object representing the integer, and the intobject.c code would simply "look after it". in this way, you would have interoperability between python that was converted to javascript, and python c-based modules.

the thing is: the performance of the pyjamas LoopTest was a bit lower than i was expecting, so i double-checked things, especially that the original experiment showed conversion of python to javascript executed under V8 having a whopping 10x performance increase (over standard python).

pyv8run running the fibonacci algorithm, it's confirmed: when you set -O (optimisation mode in pyjamas) we have a 2.5x performance INCREASE over standard python, WITHOUT having made any special effort or analysed what is going on and without having profiled things to find out if it can be done any better.

also confirmed: when you switch on "--strict", the object-accessing test comes down to 10% the performance of python, which is truly dreadful, but hey, it's "safe", what do you expect? :)

also confirmed: a simple object-accessing test is 50% (HALF) the performance of python - again, with no investigation as to why that is.

Re:Python implementations still suck

[ceoyoyo]

"Google (who hired Guido) likes Python, but they don't like the low performance. CPython is a "naive interpreter" (very little optimization). Worse, with the rather lame implementation the Global Interpreter Lock, not only can't it use a multi-core CPU effectively, multi-thread programs run slower on multi-core CPUs. (The threads fight over the lock in an embarrassingly inefficient way.)"

The semi-new multiprocessing module is pretty cool. For the most part it duplicates the thread api interface, but it uses processes each running their own interpreter on the back end. True multiprocessing, and some care has been taken to provide decent interprocess communication, scheduling, etc.

Re:Python implementations still suck

[bill_kress]

Strange assumption...

Why on earth would you say Java was slower than everything that came before it?

It's faster than everything but C, and even ties C in some cases.

I believe the Language Shootout includes specs for Fortran and Basic (which were before Java), I'm also pretty sure it was faster than Pascal, Ada (Can't swear to that one, don't think it's on the shootout, but I don't remember it being specifically quick), heck hundreds of languages.

I still don't know why Java gets crap about performance when it is the only language that seems to perform like C.

Honestly the only thing I can think of is that like Visual Basic, it made programming possible for a LOT more people--people who didn't really know how to program and only wanted to implement a solution to a problem. They made good ideas into decent programs with very bad performance.

I'm pretty sure that if Python ever becomes known as the language that is an "Easy" way to solve some problem, it'll have the same kind of issues.

I've also seen some pretty crappy Ruby on Rails websites...

Re:Python implementations still suck

[m50d]

The much-maligned GIL was a performance solution to the time - it made the interpreter run faster on uniprocessors than individual locks around each part. When the average python-running machine has >2 cores I suspect we'll see the back of it - but that won't be for a while yet.

Re:Python implementations still suck

[m50d]

This is an immensely useful project - it makes it possible to write the client-side code for web apps in python, increasing the efficiency of doing so massively, and so helps make the web better for everyone.

Re:Python implementations still suck

[lkcl]

the story is that i got into HTML/CSS Hell trying to do a cross-browser "centre" layout, vertically and horizontally. after two weeks and only 150 words on the page, i still wasn't done. pyjamas 0.3 i achieved what i wanted in under 40 minutes, learning pyjamas from scratch.

now i do all my web development in pyjamas, and flatly refuse to do HTML-based server-side web sites.

give me pyjamas plus JSONRPC or give me death :)

Re:Python implementations still suck

[MostAwesomeDude]

Don't use threads. Use multiprocessing for concurrency and Twisted for asynchronous I/O.

If you're going to complain about the GIL, perhaps you should go read up on why it's necessary, and perhaps share some of your amazing insights on a better, more performant way to do threading.

PyPy is far from dead. They've got a JIT working for x86 assembly that matches NumPy in some tests.

Re:Python implementations still suck

[Sam Douglas]

I used to have the idea that Java was inherently slow. It is not. Some implementations of the Java libraries are slow, Swing is a bit sluggish on some platforms (it is largely coded in Java rather than using native toolkit functionality) but the Java language itself is quite fast. If coded well, you can get performance comparable to C, but that is also quite dependent on how well your virtual machine JIT compiles the code (or, if it does).

I'm sure a lot of people base their preconceptions of Java being slow on programs like Azureus and Eclipse. These programs are slow because they are big and bloated, not just because they are coded in Java. On GNU/Linux systems especially (older Ubuntu releases were bad for this), the packages distributed in the repository would run use GCJ even when the much more efficient Sun runtime was installed.

I'm not a Java fanatic, nor an IBM troll. /p.

Re:Python implementations still suck

[dkf]

If you're going to complain about the GIL, perhaps you should go read up on why it's necessary, and perhaps share some of your amazing insights on a better, more performant way to do threading.

Their big problem is that they're using a single space of resources that are shared across all threads. That in turn means that they have a lock guarding access to that resource space (the GIL) and so that's where there's massive contention, especially with CPU-bound threads. Drop the general sharing (sharing specific objects is OK if you add the right fine-grained locks) and the code will be much faster. This is very similar to using multiprocessing though, so much so that it makes scaling to a multiprocessing system pretty trivial (you only have to worry about shared objects and inter-thread messaging, but people have worked on those for years).

The big issue is that this model is not compatible with most existing threaded Python code. The single resource-space assumption is pretty deeply embedded...

Re:Python implementations still suck

[Animats]

The big issue is that this model is not compatible with most existing threaded Python code. The single resource-space assumption is pretty deeply embedded...

It's not quite that bad. Python guarantees memory safety, and the atomicity of some sequence operations, like "append". But it's not a run-to-completion thread system. Fine-grained locks wouldn't break many pure Python applications.

The big issue is "who owns what" for locking purposes. I discussed some ways to deal with that issue on the Usenet Python group a few weeks ago. If you're willing to introduce "synchronized objects" (like Java) and require that all other mutable objects be linked to either by one thread or one synchronized object at a time, it can all be made to work without extensive programmer effort. Immutable objects don't have sharing problems, except for memory allocation purposes. (That's what concurrent garbage collection is for.)

Or you can punt and use large numbers of individual processes, but that eats memory. I have an application which works that way. It works fine, but each process takes 10MB or so, while a thread to do the same job would need only 100K.

In an era where the typical new server has 8 processors, this really needs to be solved.

Re:Python implementations still suck

[Anonymous Coward]

If you just look at the right benchmarks you may think Java performs like C.... however, thanks to the increased memory footprint of the interpreter, the fact that generally speaking you'll be doing a lot more memory allocations in Java (everything needs to be an object), not to mention that they just recently got GC right in 1.6... and you'll find that Java basically sucks the high hard one for performance compared to well written C *in the real world*.

Re:Python implementations still suck

[Anonymous Coward]

If Java is so fast, why does it need to use native libraries? Shouldn't the JIT make that unimportant? Seriously, if it's so comparable to C, why does it need to call C/C++ native libraries to get speed?

I think, as a group, we often repeat what we are told, without proof. It's one of my least favorite thing about programming. The other is all the fads (languages and methodologies).

Re:Python implementations still suck

[shutdown -p now]

Python is quite a good language, but the implementations suck. This is holding back widespread use of Python. It's too slow, typically 10x to 30x slower than C. That's far worse than Java.

Frankly, there's only so much you can do. The language semantics itself presents some obstacles to performance. I mean, the language reference explicitly defines member lookup as string lookup in a dictionary associated with an object! This is going to be an order of magnitude slower than vtable dispatch in a statically typed language, there's no way around it. At best you can try to mitigate this by using some caching scheme to avoid repeated lookups (Microsoft's DLR does precisely that), but this only helps so much. And no kinds of faster VMs, or JIT or AOT compilation to native code, will change that.

The same goes for JavaScript, by the way. It cannot match the performance of C++, ever - or even come anywhere close - because the way it is defined precludes that. Java, on the other hand, has a fairly good chance (and the progress can be seen).

Re:Python implementations still suck

[shutdown -p now]

If you're going to complain about the GIL, perhaps you should go read up on why it's necessary, and perhaps share some of your amazing insights on a better, more performant way to do threading.

Some insights might come from the fact that neither Jython nor IronPython have GIL (and yet fully support multithreading)...

Re:Python implementations still suck

[Anonymous Coward]

For a few years, the great hope of the Python community was PyPy, but that had too many goals, was being developed in "sprints", and after five years, the European Union pulled the plug on funding after it was slower than CPython.

This is utter nonsense. The EU did not "pull the plug". The funding period was predetermined. PyPy is a very large and complex project, that is true, but it is still one of the most promising implementations of Python.

Re:Python implementations still suck

[MostAwesomeDude]

Note how they're also both slower than CPython.

Jython does it by using JVM for threading, IronPython uses one of the many GIL-less patchsets which degrade performance but still permit threading.

Re:Python implementations still suck

[shutdown -p now]

Note how they're also both slower than CPython.

Reference?

Jython does it by using JVM for threading, IronPython uses one of the many GIL-less patchsets which degrade performance but still permit threading.

Actually, IronPython also does it by using CLR for threading; it's not based on CPython code, so I'm not sure what "GIL-less patchset" you're even talking about.

Now can you please explain how Java or CLR threads are different from native threads, and why using the former does not require GIL, but using the latter does?

Re:Python implementations still suck

[dkf]

The big issue is "who owns what" for locking purposes. I discussed some ways to deal with that issue on the Usenet Python group a few weeks ago. If you're willing to introduce "synchronized objects" (like Java) and require that all other mutable objects be linked to either by one thread or one synchronized object at a time, it can all be made to work without extensive programmer effort.
Immutable objects don't have sharing problems, except for memory allocation purposes. (That's what concurrent garbage collection is for.)

In Tcl (where I know what's going on in quite a lot of detail) each thread has a separate memory pool for small allocations (large allocs - I forget what qualifies as large - come from the global pool, but are also relatively rare) so that there is very little need for holding locks with high levels of contention. This is facilitated by the fact that Tcl uses an apartment threading model: threads are strongly isolated from one another except for explicitly shared resources (where yes, there's a per-resource lock and no GC at all) and asynchronous messages sent between threads. The net effect is that scaling Tcl programs on multi-core hardware is pretty trivial in practice (e.g., by increasing the size of thread pools used); you have to really work to hit a nasty locking case...

The shared resource model (memory's just a resource, though an important one) just gets into so much trouble when there's more than one core. Increasing the level of isolation and using messaging just seems to work and scale better. But it's a completely different way of doing things; you're probably better off starting from the perspective of pretending you're single-threaded and using different processes (that just happen to be in the same process/address space). That is, code that is designed to work efficiently across a cluster will do fairly well when scaled down to mere 8-core servers.

If you do the transition of parallel processing models, it won't be painless. A lot of existing code will be broken by it. All I can do is point out that it does work and does avoid the GIL.

Re:Python implementations still suck

[Animats]

I mean, the language reference explicitly defines member lookup as string lookup in a dictionary associated with an object! This is going to be an order of magnitude slower than vtable dispatch in a statically typed language, there's no way around it.

Sure there is. See Shed Skin. You have to do global analysis.

It helps if you apply some restrictions. For example, it's reasonable to require that you can't add a new member to a class dynamically unless the module defining the class does so, in at least one place. So class member functions can self-modify, but must do so visibly. (You can still subclass from another module if you really need to override something.) Then you can define "slots" for all the fields, and for many of them, determine their static type.

The real problem for optimization is "hidden dynamism" - places where the dynamic binding features are invoked, but that's not obvious from the source code. "Hidden dynamism" is rare - if you eval a string, it's not usually because you want to load a new function definition that replaces an existing one. (And if the string does that, the odds are that it's a security problem comparable to an SQL injection attack.) All I'd ask is that if you're going to have hidden dynamism, you must also have some explicit dynamism for the same member. (You might have to write something like "self.fn = self.fn", so the optimizer picks up on the concept that ".fn" is subject to being redefined. But such requirements should be rare. I'm not proposing to add declarations to the language. Not even via "decorators".)

Good implicit typing requires program-wide analysis, because you need to see all the calls to a function to find out what types are used in the calls. If parameter 1 is always an integer, and parameter 2 is always a string, then considerable optimization becomes possible.

It's also useful to determine at compile time which functions "keep" references to their arguments. If an argument comes in, and nothing in the function ever keeps a reference to it beyond function exit, then you don't need to update reference counts for that argument, because the function can't extend its life.

There are lots of other potential optimizations for Python. For example, if the compiler determines that an argument is always a small immutable (int, float, a small object like a complex number or a 3D point) and is never "kept", it may be cheaper to pass it by value. This is a generalization of "unboxing".

The compiler has to recognize the 0.01% of the time that something funny is going on and generate the inefficient code for the general dynamic case. The rest of the time, more static code can be used.

If you really like JIT systems, you can even fix it so that when the inefficient case comes up unexpectedly, it's properly handled, by recompiling the relevant code on the fly. I think the Unladen Swallow people are headed in that direction, and the Javascript JIT people definitely are. (The Javascript people have a much worse legacy code problem than the Python people, though. Python code is generally part of coherent programs, which are maintained as a unit. Javascript code is a collection of snippets of dubious provenance spread all over the Web.)

Re:Python implementations still suck

[idlemachine]

Ah yes, the standard tired "why Python sucks" tropes, as usual coming from someone who has made no attempt to improve the situation and barely understand the issues but feels they have the right to condemn those who are actually doing the work.

If you want C speed, use C. If you want C speed in Python, profile the bottlenecks and write them in C, the easy bridging of the two is one of Python's great strengths. Hell, Cython allows you to code pretty much pure python with type declaratives, which will run both as Python _and compile to C_.

There are more than enough solutions to the speed issues in Python. Unfortunately for you, they _do_ require you to do something other than whine about it.

Re:Python implementations still suck

[shutdown -p now]

The real problem for optimization is "hidden dynamism" - places where the dynamic binding features are invoked, but that's not obvious from the source code. "Hidden dynamism" is rare - if you eval a string, it's not usually because you want to load a new function definition that replaces an existing one. (And if the string does that, the odds are that it's a security problem comparable to an SQL injection attack.) All I'd ask is that if you're going to have hidden dynamism, you must also have some explicit dynamism for the same member. (You might have to write something like "self.fn = self.fn", so the optimizer picks up on the concept that ".fn" is subject to being redefined. But such requirements should be rare. I'm not proposing to add declarations to the language. Not even via "decorators".)

I might be missing something, but how would it work in the presence of __getattr__ and other such things - which are by no means rare in Python code? Heck, I see an occasional __dict__ assigning hack every now and then...

It's also useful to determine at compile time which functions "keep" references to their arguments. If an argument comes in, and nothing in the function ever keeps a reference to it beyond function exit, then you don't need to update reference counts for that argument, because the function can't extend its life.

Or just use a tracing GC, which consistently beats any thread-safe reference counting scheme on large object graphs. Python language reference specifically defines tracing non-deterministic GC as a valid conformant implementation (mostly for the sake of Jython and IronPython), so it is definitely an option.

There are lots of other potential optimizations for Python. For example, if the compiler determines that an argument is always a small immutable (int, float, a small object like a complex number or a 3D point) and is never "kept", it may be cheaper to pass it by value.

My impression that Python already passes ints by value, precisely because they're immutable (and so are floats), so there's no need to do reference counting, or, in general, copy references for those things, ever - since referential identity for them is meaningless.

Anyway, you did give a few very interesting references to look at, but even with all those optimizations, what is the difference between something like Python (let's take that as a more structured and generally easier to optimize language) compared to C++ or even Java?

Re:Python implementations still suck

[bill_mcgonigle]

The goal is 5x faster than CPython, which won't beat Java, let alone C/C++.

People tell me that Python is functionally a dialect of LISP.

People tell me that LISP's can all be trivially converted to each other, correctly.

People tell me that there are LISP machines that run better than 3x slower than native C code.

So, that seems like the obvious solution, but I must be missing something. I ask about once a year, and nobody has been able to tell me which of those statements is incorrect (I have to assume at least one is).

OpenSource Web Browsers written in Python?

[marciot]

Are there any open source web browsers written in Python? If so, I would like to run it in these JavaScript python interpreters so I can browse the web.

Re:OpenSource Web Browsers written in Python?

[lkcl]

yes - paul bonser's pybrowser is the beginnings of an implementation of a web browser in python. he uses python-cairo and pygame for the graphics and the event handling. a combination of flier liu's PyV8 or python-spidermonkey would bring javascript execution to this effort, completing the loop.

also i just accidentally encountered this which is confusingly also called pybrowser: it uses python-gtkhtml2 (which is considered deprecated since this project named pybrowser was written, in 2005).

lipstick, dogs

[speedtux]

Compiling Python to JavaScript running in a browser really is like putting lipstick on a dog.

Speed matters. Datacenters cost money.

[Animats]

Because it IS easier to use and hardware is always getting cheaper.

On the server side, 10x to 30x slower means building entire buildings full of servers. Or more expensive hardware in the cell phone. Or using another language.

Python is actually a good general-purpose programming language, not just a "scripting language". The big problem is slow execution.

The basic problem with CPython is that, being a naive interpreter, it has to check for the hard cases every time. "n = n + 1" ought to be a few machine instructions, maybe only one. But Python has to check for n being a float, n being a string, n being an object, etc., every time. Shed Skin, with a type inference systems, does analysis at compile time and determines that n is always an integer, then generates code for integer arithmetic only.

There are all sorts of dynamic things one can do to a Python program while it's running. You can add a function to an object. You can replace existing functions. You can load new modules on the fly. But most of the time, for most of the objects, you don't do that. An efficient implementation needs to separate out the cases where something unusual might occur, and the far more common cases when the program is doing routine stuff that needs to go fast. The common cases can then be handled with much simpler, and faster, code.

Re:Speed matters. Datacenters cost money.

[cyberthanasis12]

The basic problem with CPython is that, being a naive interpreter, it has to check for the hard cases every time. "n = n + 1" ought to be a few machine instructions, maybe only one. But Python has to check for n being a float, n being a string, n being an object

This is actually a feature. It is called polymorphism - everywhere. It is far simpler than the alternatives (C++ i.e. polymorphism - on condition), and in my opinion it is worth the sacrifice in speed.

Python is actually a good general-purpose programming language, not just a "scripting language". The big problem is slow execution.

I don't think it is, in the majority of cases. 0.01 sec to 0.7 sec is 70 times faster, but to a human being it is almost the same. And actually the difference is not so big in real applications. It is more likely 1 to 3 taking IO into account.
Python gives a huge advantage in code readability and developing time.

Re:Speed matters. Datacenters cost money.

[dkf]

On the server side, 10x to 30x slower means building entire buildings full of servers. Or more expensive hardware in the cell phone. Or using another language.

You say that like there's something shameful in using more than one language for an application. Here's a little secret. It's not true. Using several languages, each for what it is good at, is like using several tools when doing woodworking. Any good woodworker will tell you that you can't do everything with one tool, even on a simple job. So why restrict yourself when programming?

Re:Speed matters. Datacenters cost money.

[lennier]

"Any good woodworker will tell you that you can't do everything with one tool, even on a simple job. So why restrict yourself when programming"

Because programming *isn't* woodworking.

More specifically, because the power of any software system comes as much (or more) from the integration of its components as from the components themselves. It's the connections that hold the intelligence.

Using multiple languages prevents integration - or at least dampens it way down, due to impedance mismatches between calling conventions, ABIs, data format representations, etc. If I have a component written in language X which expects parameters in format X1, and I have another component in language Y which expects parameters in format Y1 - how am I going to get them to integrate?

The answer is either 'you just can't do that, so rewrite the entirety of component Y in language X' -- hello Linux -- or 'write language/convention Z as a buffer/converter'.

What usually happens in that case is that language Z isn't written as a proper language because it's just a hack to get X and Y to communicate, so it's missing all sorts of features which then have to be added ad-hoc, without integrity checking, and become a huge source of bugs. This is how we got COM, CORBA, the C ABI, the abominations which are the multiple C++ ABIS, CGI, DCOM, COM+, D-BUS... and then how do you get Java talking to JavaScript? .NET to Javascript? .NET to Java? PHP to Python? Common Lisp to Bash script?

Oh, you can't connect those two and you don't know why anyone would want to? Too bad, you just lost a chunk of expressiveness, and you *can't* 'use the right language tool for the job' in that case, because there's no way to launch that program / import the data / finesse the difference between an int32 and an Integer and a Variant and a text file and a registry key...

Remember, for every pair of languages X,Y there either has to be a new mapping created, maintained and debugged... or else a Z needs to be standardised.

Eventually, you come to the realisation that things are only maintainable if we standardise on ONE Z.

If we wait a very long time eventually we come to the next revelation that we could make Z an *actual Turing-complete language* with a fully standardised VM and ABI...

Or we could do that right up front, and spend the rest of our lives actually coding solutions instead of hacks around our multi-language Babel.

Smalltalk in Javascript

[Jecel Assumpcao Jr]

There are also a few implementations of Smalltalk using Javascript:

http://gwt-smalltalk.appspot.com/

http://clamato.net/

http://tinlizzie.org/ometa/ometa-js-old/

Re:Smalltalk in Javascript

[radarsat1]

Scheme too!

http://www.bluishcoder.co.nz/2006/05/scheme-implementation-in-javascript.html

Sup Dawg!

[oldhack]

We heard you like converting, so...

I can still writing in it...

[Junta]

I know it is very capable, flexible, and many frameworks exist to shortcut many common sequences of javascript used in sophisticated application development. I can respect a Javascript developer and not doubt for a minute they can code up fully capable stuff (particularly in conjution with HTML5 features including canvas). I won't claim that Javascript doesn't have a decent debugging strategy (i.e. firebug). I even appreciate the fact that sometimes, the community is better of just picking *something* and sticking with it in the name of standardization even if something universally more popular yet not much more featureful comes along.

However, while I recognize that what I can do isn't so different from what I can do in other languages, it is how I have to do it. I find the syntax to share too many of the characteristics I find distasteful about Java, namely typically tedious steps to do most of what I want. Some of it is the language itself, some of it is the relative complexity of manipulating HTML DOM elements and CSS compared to most modern desktop APIs, and some more of it is the network access model being a bit more limited than arbitrary sockets for certain tasks. Writing a Perl GTK program or a WxWidgets in Python (though I'm less fond of Wx) is, to me, just a lot easier than Javascript/HTML/CSS environments.

Why the future tense

[Anonymous Coward]

(Note: don't try any of the above SVG demos with FF2 or IE6; they will suck.)

IE6 sucks now. It will continue to suck tomorrow. It sucked yesterday. There was no day when ie6 did not suck.

So there is an easy way??

[iwein]

... the hard way ...

I might be daft, but I don't think there is an easier way to run python in a browser. Please enlighten me.

Re:So there is an easy way??

[DragonWriter]

I might be daft, but I don't think there is an easier way to run python in a browser.

I see three obvious ways to run Python (or, really, any language that isn't currently supported for scripting in the browser) in a browser as an equal to JavaScript:

1) implement a full interpreter environment for the language in JavaScript,
2) embed an existing embeddable interpreter for the language into the browser, and add code to bridge the browser features (DOM, etc.) you want to expose,
3) modify an existing non-embedded interpreter to run in a subprocess controlled by the browser, adding code to both sides to set up browser-to-scripting-environment communication.

#1 is probably the hardest for most languages (since you have to implement an interpreter, not just glue between an existing interpreter and the browser), but its also the only one of those that works with existing browsers without changing the browser code.