Will python ever have signalhandlers in threads?
apardon at forel.vub.ac.be
Mon Nov 22 09:06:34 CET 2004
Op 2004-11-21, Tim Peters schreef <tim.peters at gmail.com>:
> [Antoon Pardon]
>> I'm talking about PyThreadState_SetAsyncExc only as a throw in
>> response to your previous remark. The main subject is signals.
>> Well wether the work is done or not hardly seems to matter. The
>> documentation as worded now seems to make it clear, this isn't
>> going get into the language.
> But you're still talking about PyThreadState_SetAsyncExc here, right?
> Explained last time that it can't possibly "get into the language" in
> the state it's in now.
And my response to that is that the documentation suggests that
that is not the main reason why it is not in the langauage.
> The people who orginally did the work got
> everything they wanted at the time: the C API function, and the
> then-new thread.interrupt_main() function in Python. They didn't ask
> for more than that, and they didn't work on more than that.
> Doing more work is a necessary prerequisite if people want more than
> that in the language. Making the case that it should be in the
> language is part of that work, but, if you haven't noticed, PEPs that
> have working implementations fare much better than PEPs that don't.
> Indeed, no PEP without an implementation has ever been released
Look the documentation states this:
To prevent naive misuse, you must write your own C extension to call
IMO this says the reason for not having it in the language has
nothing to do with lack of implementation. In this case it seems
lack of implementation is the consequence of Guido and others
finding it to be too dangerous too be in the language. Not that
a lack of implementation is the reason it didn't make the language
>> As I understand the doc, one doesn't plan to begin working on a
>> Python-level feature and even if someone else implements it, it
>> has no chance of getting in the language.
> Sorry, couldn't make sense of that sentence.
That raising an exception from one thread in an other thread doesn't
made the language is a so by design not by lack of implementation.
As the documentation is now worded it suggest very strongly that if
someone does implement it tomorrow it will simply rejected because
they want to prevent naive missuse.
>> As I read the docs it is not so much a question of the feature not
>> being ready for the langauge, but a question of Guido not wanting the
>> feature to be in the language.
> You're still talking about PyThreadState_SetAsyncExc?
> I haven't asked
> Guido about it, and I can't find any design discussion of that
> function anywhere.
Wel that sentence came in the documentation, I don't know, but
something like: "To prevent ..." does sound like a design decision
> I think it got added during a European sprint. If
> you want to know what he thinks, ask him. If you want a definitive
> ruling, write a PEP.
That seems a bit idiot to me. The information seems to be available
in the documentation. So why should I ask?
>> This just to show that having someone implement it, is not
>> the biggest hurdle as your prevous remark seemed to suggest
>> to me.
> An implementation is prerequisite to release, but isn't necessarily
> sufficient. I explained in detail last time why the current C code
> has no claim to being "an implementation" of a *Python*-level spelling
> of this functionality, so neither a suitable implementation nor the
> necessary design discusiion have been done in this case.
> If this is something you want, but you also want guaranteed acceptance
> in advance of doing more than writing about it, that won't work. If
> you ask Guido, and he can make time to answer, you may get guaranteed
> rejection in advance -- or you may not. A PEP would be a good thing
> to have in *either* case.
I don't want guaranteed acceptance in advance. But if I have the
impression that there is rejection in advance then there seems to
be no point in starting. The documentation as worded now seems to
imply such a rejection in advance.
So for the sake of argument even if I wanted this, I would be reluctant
to spend time in it, because I only have limited amounts of it and
this battle seems to be lost from the beginning. I would think my
time would be better spend fighting other battles.
More information about the Python-list