regarding the speed issue: i looked at python 2.7 - here the interpreter is creating a dictionary for each function frame, now local variables are looked up by name of variable in this dictionary ! (globals have their separate namespace dictionary)

(i made a tracing tool that traces a python program and prints out all accessed variables - it actually makes use of this by-name-lookup-feature http://mosermichael.github.io/cstuff/all/projects/2015/02/24... )

i think that's quite wasteful, fixing variable access so that it is by some internal index and not by name would probably be a big improvement, even without changing the global interpreter lock.

Closures might make this difficult, since a variable might be referenced by name before it's defined in any scope.

Variable access already works by index, not by name. Normally, LOAD_FAST and STORE_FAST are used.

I always found it weird that python functions quite happily tell you that you're missing a colon, but can't 'just run' without it.

Excluding one-liner syntax, why does Python actually need a colon to define a function, given it's goal of being free of unnecessary syntactic elements? I'm only an intermediate pythonista, but I'd be interested to know if there was a particular point to the colon.

It doesn't, it just is easier to scan. There isn't a goal of being completely free of syntactic elements, semicolons went because they were excessive and noisey, colons seem, at least to me (comparing with say, coffeescript) to make it less noisey.

Thanks for the info, all.

It's because there's a rule that every time you are going to start indenting more, there's a colon first. Since whitespace is rather invisible, it's a concession they make to make scoping more clear.

A few "unnecessary" syntactic elements help find errors at "compile time". In Javascript for example, automatic semicolon insertion can lead to very subtle errors.

PyQt I think satisfies "3"? Though it's not builtin.

Don't count out Kivy for a modern UI toolkit, but speed and no requirement to include a runtime for distribution will not come for Python without a different approach to execution.

what's wrong with qt as a modern ui toolkit? python seems to be one the best supported languages as far as qt bindings go.

Have you ever tried to deploy a native looking Python3 qt app on both Mac and Windows? I am not aware of anyone who lived to tell the tale. If you can do without a native look (menus, dock icons, app packaging), i.e. you just want to have some academic lab tool, then qt is good enough, IMHO. But no comparison with native UI development on Win or Mac.

no, linux only. i'll admit that i wasn't taking native look into account, but then again, no default gui toolkit would be likely to have a native l&f anyway - you'd want to use the platform-native bindings for each platform separately, if that was a strong concern.

Nothing per se. However the situation with two competing python bindings and no official out of the box support or blessing of either makes it non-obvious as to what the 'correct' way to write and ship GUI apps in python is.

If I just want to wrap a simple GUI around some functions then going down the qt route is currently far to 'heavy'.