decorators vs GIL

[mudd at vex.net]

> On Sat, 7 Aug 2004 22:20:31 +0200,
> 	Miklós <nospam at nowhere.hu> wrote:
>> Yes, this was exactly my point. Performance and GIL. Those are problems.
>> And problems must be solved.
>
> Problems for who?

Me, for one.

Yes, I can code around the GIL.  I do that routinely.  It's a pain to keep
working around the GIL.  Especially knowing that it's not necessary in
other languages, but it can be done.  Sigh.

What really hurts is that I can't honestly tell Java programmers that
Python  is a slam dunk compared to Java & the JVM.  Java has no GIL,
Python does.  Once I admit this, nobody listens to what Python does well. 
It's a shame.

> I have no problems with Python's performance in my
> applications.  I avoid threads because they're error-prone,

Isn't that like saying, I avoid programming in general because it's
error-prone?  I don't follow.

I agree that threads do introduce an additional level of complexity.  But
so does programming multi-user applications versus single-user apps.  But
I've never heard programmers routinely say that they avoid multi-user apps
because they're "error-prone".

But isn't the GIL on the way out already?  Jython offers access to the
non-GIL threads of the JVM.  I always use Java threads when working with
Jython.  That's great!  I suppose Iron Python will do the same with CLR. 
And one of the main reasons for the Prothon project (the mythical "Python
fork"?) is the elimination of the GIL.  It sound like alternatives are on
the way.  But what's the future of Python?

> so the GIL
> doesn't affect me.

but, but... no programmer is an island?

>
> Free software projects are run by the people who actually contribute code.
> If sorted() and reversed() were added, it's because Raymond Hettinger
> actually wrote code to implement them, and GvR didn't dislike them.  If
> people who want decorators are willing to expend effort to implement them,
> test them, conform to the coding standard, then they can be considered for
> inclusion.  So, if you want to see the GIL fixed, or performance
> improvements made, you have to work on these problems.

I'm guessing the GIL is beyond any of us.  If it was easy, or even
possible, someone would have already eliminated it.


>
> --amk
>
>