Adding a Par construct to Python?

[Carl Banks]

On May 20, 4:07 pm, Luis Zarrabeitia <ky... at uh.cu> wrote:
> On Wednesday 20 May 2009 06:16:39 pm Aahz wrote:
>
> > >While I agree that the GIL greatly simplifies things for the
> > >interpreter, I don't understand this statement. In practice, you should
> > >lock all critical sections if you expect your code to be used in a
> > >multithreading environment.  That can't be different from what Java, C#
> > >or any other languages do, including C++. Why is that so expensive in
> > >python extensions, that it is used as an argument against removing the
> > >GIL?
>
> > Python is intended to be simple/easy to integrate with random C
> > libraries.  Therefore you have to write explicit code from the C side in
> > order to drop the GIL.
>
> Erm, that doesn't really answers the question. If there were no GIL, the C
> code called from python would be just as unsafe as the C code called from C.
> And if "not thread-safe, you take care of the locking" notices are enough for
> the original libraries (and a lot of other languages, and even python
> constructs), the C extension could always grab the locks.

The designers of Python made a design decision(**) that extension
writers would not have to take care of locking.  They could have made
a different decision, they just didn't.


> There must be another reason (i.e, the refcounts) to argue _for_ the GIL,

Why?


> because this one just seems to be just an attempt to fix unsafe code when
> called from python.

I think you are being unfair in calling it unsafe.

Suppose if I were to call PyList_Append from a C extension.  It's not
necessary for me to guard the list I'm calling it on with a lock,
because only the GIL thread is allowed to call most Python API or
otherwise access objects.  But you seem to be suggesting that since I
didn't guard the list with a lock it is "unsafe", even though the GIL
is sufficient?

No, I totally disagree.  The code is not "unsafe" and the GIL doesn't
"fix" it.  The code is jsut


> And that was my point. Refcounts + interpreter simplicity
> seem to imply the need for a GIL, but to make unsafe code safe without fixing
> said code (or even thinking about it) is a weird goal...

Why?  Do you seriously not see the benefit of simplifying the work of
extention writers and core maintainers?  You don't have to agree that
it's a good trade-off but it's a perfectly reasonable goal.

I highly suspect Aahz here would argue for a GIL even without the
refcount issue, and even though I wouldn't agree, there's nothing
weird or unreasonable about the argument, it's just a different
viewpoint.


> specially if it
> became the only reason for a GIL. After all, one could argue for that goal in
> almost all languages.

"B-B-B-But other languages do it that way!" is not a big factor in
language decisions in Python.


Carl Banks

(**) - To be fair, Python didn't originally support threads, so there
was a lot of code that would have become unsafe had threading been
added without the GIL, and that probably influenced the decision to
use a GIL, but I'm sure that wasn't only reason.  Would Python have a
GIL if threading had been there from the start?  Who knows.