I apologize if this is the wrong place to ask questions about Python C code, but I didn't know where else to turn. I don't think the regular user group will be technical enough to find this, am I wrong? There is no forum for something this in depth. This is not a usage problem, I want to know where in the code this is happening, I understand how to use these signals perfectly and why they are different. Clearly SIGKILL cannot be caught and would never get used even if you did register that handler in Python, while SIGTERM is able to be caught, this is standard Unix signals. The part I am asking about is how python checks ahead of time. If it didn't check (case before python 2.4), then it would get silently ignored because the OS would kill the process without ever letting python even try and handle that signal. I just want to understand the C/Python piece better because I am writing a tutorial on signals and I am using python to demonstrate. I thought it would be fun to show that the SIGKILL is never processed, but instead python errors out. There is something in Python checking the SIGKILL signal handler, while not checking SIGTERM and I can't find the Python C code that handles it. When I am writing something like this, I like to point out the C code, not just cite the documentation (I did find this change in behaviour noted in the Python change log). I will try and find a different list Scott M On Mon, Jul 19, 2010 at 12:27 PM, Oleg Broytman <phd@phd.pp.ru> wrote:

Hello.

We'are sorry but we cannot help you. This mailing list is to work on developing Python (fixing bugs and adding new features to Python itself); if you're having problems using Python, please find another forum. Probably python-list (comp.lang.python) news group/mailing list is the best place. See http://www.python.org/community/ for other lists/news groups/fora. Thank you for understanding.

Regarding SIGKILL - read "man kill" carefully. Or better yet, a Unix programmer guide.

...

All, I have searched everywhere (mostly the code and a little google) and I cannot understand where the SIGKILL signal gets checked when it is set as a handler. I have scoured the Modules/signalmodule.c only to find two instances of the RuntimeError exception, but I cannot understand how

On Mon, Jul 19, 2010 at 12:11:10PM -0400, Scott McCarty wrote: python

...

knows when a handler is set for SIGKILL. I understand that this changed in 2.4 and I am not trying to change it, I just really want to understand where this happens. I used grep to find SIGKILL and SIGTERM to see if I could determine where the critical difference is, but I cannot figure it out.

I have about 2 hours of searching around and I can't figure it out, I assume it has to rely on some default behaviour in Unix, but I have no idea. I don't see a difference between SIGKILL and SIGTERM in the python code, but obviously there is some difference. I understand what the difference is in Unix/Linux, I just want to see it in the python code. Since python is checking at run time to see what signals handlers are added, I know there must be a difference.

Please can someone just point me in the right direction.

Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

  We'are sorry but we cannot help you. This mailing list is to work on developing Python (fixing bugs and adding new features to Python itself); if you're having problems using Python, please find another forum. Probably python-list (comp.lang.python) news group/mailing list is the best place. See http://www.python.org/community/ for other lists/news groups/fora. Thank you for understanding.

  Regarding SIGKILL - read "man kill" carefully. Or better yet, a Unix programmer guide.

Wha? How could this not be the right place? He's not asking about USING python, but asking: WHERE in the PYTHON CODE BASE does the signal get checked? A-bit-miffed-at-the-cold-shoulderly yours, Marcos (wink wink)

On Tue, Jul 20, 2010 at 12:29 AM, Steve Holden <steve@holdenweb.com> wrote:

Another potential developer walks away feeling unwanted?

Let just kill this thread here. SIGKILL can't be caught. :) (I had sort of assumed that Marcos was being ironic). Schiavo Simon

On Mon, Jul 19, 2010 at 04:08:00PM -0600, average wrote:

Wha? How could this not be the right place? He's not asking about USING python, but asking: WHERE in the PYTHON CODE BASE does the signal get checked?

A-bit-miffed-at-the-cold-shoulderly yours,

Marcos (wink wink)

I know, the task of sending answers like I've sent is quite unappreciated. I know, the meaning of my answer is rude because, in short, it's simply "Please, go away", and however I stress the "please" part it's still "go away". If I were a help seeker it'd be quite a hard blow for me to receive such an answer. Yes, I know. Still, two other alternatives are even worse. The first alternative is to not answer "using" questions at all; quite rude. The second is answer all questions and make the developers quit the list and found a new quiet one. I don't see any other alternative, do you? Of those three - which one do you prefer? The original question was about using python, that's my understanding. Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

No, the reply is fine as far as it goes, and I am sure the poster did get a reply from c.l.py, but his question revealed a thirst for knowledge not usually evidenced in non-dev inquiries.

Unfortunately (?) the question also revealed a lack of understanding of a fairly basic concept. IIUC, he wanted to know how Python handles SIGKILL, when the hole point of SIGKILL is that you cannot handle it. So he shouldn't have been surprised that he couldn't find a place in Python where it's handled. Regards, Martin

On 21/07/10 23:43, "Martin v. Löwis" wrote:

IIUC, he wanted to know how Python handles SIGKILL, when the hole point of SIGKILL is that you cannot handle it.

No, I think he wanted to know how Python disallows attempting to set a handler for SIGKILL, when he couldn't find any code that special-cases SIGKILL in the implementation of signal(). Although he didn't express the question all that clearly, so it's hard to tell. -- Greg

On 7/20/2010 6:59 AM, Oleg Broytman wrote:

I know, the task of sending answers like I've sent is quite unappreciated.

*I* appreciate it. I mostly do not respond to such because I expect you or Aahz will.

I know, the meaning of my answer is rude because, in short, it's simply "Please, go away", and however I stress the "please" part it's still "go away". If I were a help seeker it'd be quite a hard blow for me to receive such an answer. Yes, I know.

1. I suggested one improvement to the canned response in my previous post: expand 'using' to 'using or understanding'. 2. Here is another: mention that Python developers who are willing to answer non-development questions already participate on python-list/gmane.comp.python.general to answer such questions there. 3. That brings up: also mention gmane.comp.python.general, for those like me who prefer the newsgroup interface. 4. Alexander Belopolsky wrote: "People dislike canned responses no matter how friendly and polite they sound. I believe python-dev tradition is to redirect the poster to python-list but still include at least a hint to what the answer to his or her question is." I believe you *did* do that, but it was easily missed. So: end the boilerplate with ------------------------------------------------------------- and put hints here so they stand out.

Still, two other alternatives are even worse. The first alternative is to not answer "using" questions at all; quite rude. The second is answer all questions and make the developers quit the list and found a new quiet one.

I brought up that same possibility.

I don't see any other alternative, do you? Of those three - which one do you prefer? The original question was about using python, that's my understanding.

I agree that it appeared to be, but it was phrased in terms of understanding its operation, hence the claim that it was not, and hence suggestion 1) above. -- Terry Jan Reedy

...

1. I suggested one improvement to the canned response in my previous post: expand 'using' to 'using or understanding'.

  I changed wording to "if you're having problems learning, understanding or using Python"

I think it's critical to disambiguate between questions about "using and programming with the Python language" versus working with the actual code base that makes Python. Your boilerplate is appropriate for the former, but completely confusing for the latter. As to your question of how best to handle inquiries from the blue or "noisy questions", I personally prefer the following (only slightly tongue-in-cheek): ...After a sufficient period of waiting, say a day or two with no response: "busy busy busy, the gnomes must be hard at work. You've no answer. That means that your question(s) either isn't interesting enough in an obvious way, or it's simply off-topic. If you feel you been unfairly ignored, you might try rewording the question, doing some research to show that you've checked the obvious, or try the following venues: comp.lang.python, for blah blah blah python-ideas,for pitching your new lambda form, to etc, etc" In any case, Mr Crute gave a quite perfect answer, not that such detail should be exptected. Cheers, Marcos

Oleg Broytman writes:

On Wed, Jul 21, 2010 at 07:28:24PM -0600, average wrote:

...

As to your question of how best to handle inquiries from the blue or "noisy questions", I personally prefer the following (only slightly tongue-in-cheek):

...After a sufficient period of waiting, say a day or two with no response:

Ok, I'll wait a bit longer.

I don't think that's a good idea. It just encourages people to give a response on python-dev plus follow-ups, and if they give an answer without saying "you'd better ask this on comp.lang.python", when you do, you look like a netcop rather than being helpful. The mail you originally sent was sufficiently polite and clear IMO, but anything can be improved and I'm glad you took up the suggestions on the wording. OTOH I think as quick as possible an answer is a good idea here. It saves the intended audience the thought about whether to reply or not, and an instant, constructive answer says that somebody cares. The message should be "The people who will answer your question on python-dev are also on comp.lang.python, as well as many more (you may get a faster, and probably more complete, answer on comp.lang.python). The people on python-dev don't need to see the answer (they already know it), but the people on comp.lang.python are likely to be happy to learn it."

On Thu, 22 Jul 2010 07:02:33 pm Stephen J. Turnbull wrote:

OTOH I think as quick as possible an answer is a good idea here. It saves the intended audience the thought about whether to reply or not, and an instant, constructive answer says that somebody cares.

+1 I think that waiting "a day or two" as suggested by Average does nobody any good. It doesn't help the poster, who will almost certainly have given up by then, and may have concluded that we're stuck-up and rude for not answering a polite question. It doesn't help those who choose to reply, because we're sitting around wondering if we've waiting long enough. If you consider posting a question to a list without making any effort to determine whether it is on-topic or not to be a social faux pas, and therefore worthy of a mild rebuke, the longer you wait the less effective the negative reinforcement is. Even if you don't see it like that, and just want to point the poster in the right direction, there's still no advantage in waiting. But frankly, I think we're worrying too much. What exactly are we worried about? As I see it, the worst that can happen is a false negative, somebody will say "You've posted to the wrong list" and will be corrected by somebody else who says "No, you've misunderstood the question, this is the right list". No harm done.

The message should be "The people who will answer your question on python-dev are also on comp.lang.python, as well as many more (you may get a faster, and probably more complete, answer on comp.lang.python). The people on python-dev don't need to see the answer (they already know it), but the people on comp.lang.python are likely to be happy to learn it."

We don't need to make excuses for why we don't give the answer here. It's enough to give the reason -- it's off-topic for this list, which is about the development of Python. That and a pointer to the right list is, in my opinion, all we need to say. We don't need to sugar coat it -- we're all adults here. -- Steven D'Aprano

On 22/07/2010 23:25, Terry Reedy wrote:

On 7/22/2010 8:22 AM, Steven D'Aprano wrote:

...

On Thu, 22 Jul 2010 07:02:33 pm Stephen J. Turnbull wrote:

...

OTOH I think as quick as possible an answer is a good idea here. It saves the intended audience the thought about whether to reply or not, and an instant, constructive answer says that somebody cares.

+1

Ditto. The sooner a person redirects a question to python-list, the sooner I will answer if I have an answer. And I do answer a lot of questions on Py-list, especially those that have sat a few hours without an answer.

...

I think that waiting "a day or two" as suggested by Average does nobody any good.

The only 'waiting' by anyone should be a few days by someone who posts on pylist *before* they try here for other expers.

If only the same principal applied on the issue tracker. Anyone fancy taking on a few orphans, allowing for the fact that you might get told off for creating noise or for offending devs who don't like being reminded of outstanding issues? Still, what's nine years to someone who's waiting for a bug fix? Kindest regards. Mark Lawrence.

On Fri, 23 Jul 2010 10:59:32 am Ben Finney wrote:

Steven D'Aprano <steve@pearwood.info> writes:

...

We don't need to make excuses for why we don't give the answer here. It's enough to give the reason -- it's off-topic for this list, which is about the development of Python. That and a pointer to the right list is, in my opinion, all we need to say. We don't need to sugar coat it -- we're all adults here.

That's fine for people who already feel they are part of this particular community. The concern, as I understand it from earlier in the thread, is the regular only-one-opportunity-at-a-first-impression response given to someone *new to* this community, who clearly doesn't yet know the mores and expectations.

I'm not suggesting that we need to be rude. But we can give them the respect of starting off by treating them according to the mores and expectations of our community, rather than by assuming that they will immediately take offence or be frightened off, or by immediately getting defensive about the fact that this isn't a beginner's list. We have nothing to be ashamed of for wanting to keep this list for dev related issues, why make excuses for it? In other words, keep doing what we've been doing for as long as I've been subscribed to this list: answer politely but firmly that this is the wrong list, point them to the correct place, and, if the mood strikes you, give a brief answer to the question that doesn't invite a long discussion. I think that's fair and respectful. -- Steven D'Aprano

On 7/22/2010 3:29 PM, average wrote: Speacking of etiquette, it is traditional to use real names in the from field on pydev. It will get you more attention and respect.

A reference or link to ESR's "How to Ask Questions The Smart Way" (http://catb.org/esr/faqs/smart-questions.html) is a pretty good inclusion also. For those who may have never heard of it, it's pretty much the authority on developer list etiquette.

I agree

Marcos

Well, that is a start ;-) -- Terry Jan Reedy

Greg Ewing writes:

Scott McCarty wrote:

...

All, I have searched everywhere (mostly the code and a little google) and I cannot understand where the SIGKILL signal gets checked when it is set as a handler.

Possibly it's not being checked at all by Python, but is being rejected by the system call. The Darwin man page says this about signal(3) in the ERRORS section:

[EINVAL] An attempt is made to ignore or supply a handler for SIGKILL or SIGSTOP.

The Linux signal(2) manpage just says EINVAL signum is invalid. But I suppose that could be stretched to cover "SIGKILL, SIGSTOP, or not a signal number known to the kernel".

Not sure why it gets reported as a RuntimeError rather than an OSError, though.

My understanding of OSError is that the OS is saying "sorry, what you tried to do is perfectly reasonable under some circumstances, but you can't do that now." ENOMEM, EPERM, ENOENT etc fit this model. RuntimeError OTOH is basically saying "You should know better than to try that!" EINVAL fits this model.

Glyph Lefkowitz wrote:

The selection of RuntimeError in this particular case seems somewhat random and ad-hoc,

Indeed -- usually a RuntimeError indicates that something concerning the internals of Python itself is screwed up, e.g. attempting to execute invalid bytecode. The fact that it turns up here may be a historical accident. I can imagine that the signal module dates back to the very early days of Python, when the conventions for error reporting were not so well formed. Maybe this is something that could be considered in the exception hierarchy revamp proposal that was posted recently? -- Greg

On Thu, 22 Jul 2010 17:50:00 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote:

Greg Ewing writes:

...

Glyph Lefkowitz wrote:

...

The selection of RuntimeError in this particular case seems somewhat random and ad-hoc,

Well, I guess we'd have to catch the person who wrote the code and ask.

...

Maybe this is something that could be considered in the exception hierarchy revamp proposal that was posted recently?

I think that's Antoine's PEP 3151. Interestingly, he doesn't mention EINVAL at all.

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

That's right. It is based on a survey of existing exception-catching code in the stdlib. There's only one match in the whole Lib/ subtree: $ grep -r EINVAL Lib/ Lib/plat-sunos5/STROPTS.py:968:EINVAL = 22 I guess EINVAL would most often indicate a programming error, which is why it doesn't get handled specifically in except clauses. Semantically, EINVAL seems close to ValueError. If I search inside the man pages here, I get excerpts such as: - wait(2): EINVAL The options argument was invalid. - gettimeofday(2): EINVAL Timezone (or something else) is invalid. - socket(2): EINVAL Unknown protocol, or protocol family not available. EINVAL Invalid flags in type. - rename(2): EINVAL The new pathname contained a path prefix of the old, or, more generally, an attempt was made to make a directory a subdirectory of itself. Regards Antoine.