>Chris Torek wrote: >> I can then check the now-valid >> pid via os.kill(). However, it turns out that one form of "trash" >> is a pid that does not fit within sys.maxint. This was a surprise >> that turned up only in testing, and even then, only because I >> happened to try a ridiculously large value as one of my test cases.
In article <96itucfad...@mid.individual.net> Gregory Ewing <greg.ew...@canterbury.ac.nz> wrote: >It appears that this situation is not unique to os.kill(), >for example, > > >>> import os > >>> os.read(999999999999999999999999, 42) >Traceback (most recent call last): > File "<stdin>", line 1, in <module> >OverflowError: Python int too large to convert to C long > >In fact I'd expect it to happen any time you pass a >very large int to something that's wrapping a C function. > >You can't really blame the wrappers for this -- it's not >reasonable to expect all of them to catch out-of-range ints >and do whatever the underlying function would have done if >it were given an invalid argument. > >I think the lesson to take from this is that you should >probably add OverflowError to the list of things to catch >whenever you're calling a function with input that's not >fully validated. Indeed. (Provided that your call is the point at which the validation should occur -- otherwise, let the exception flow upwards as usual.) But again, this is why I would like to have the ability to use some sort of automated tool, where one can point at any given line of code and ask: "what exceptions do you, my faithful tool, believe can be raised as a consequence of this line of code?" If you point it at the call to main(): if __name__ == '__main__': main() then you are likely to get a useless answer ("why, any exception at all"); but if you point it at a call to os.read(), then you get one that is useful -- and tells you (or me) about the OverflowError. If you point it at a call to len(x), then the tool tells you what it knows about type(x) and x.__len__. (This last may well be "nothing": some tools have only limited application. However, if the call to len(x) is preceded by an "assert isinstance(x, (some,fixed,set,of,types)) for instance, or if all calls to the function that in turn calls len(x) are visible and the type of x can be proven, the tool might tell you something useful agin.) It is clear at this point that a simple list (or tuple) of "possible exceptions" is insufficient -- the tool has to learn, somehow, that len() raises TypeError itself, but also raises whatever x.__len__ raises (where x is the parameter to len()). If I ever get around to attempting this in pylint (in my Copious Spare Time no doubt :-) ), I will have to start with an external mapping from "built in function F" to "exceptions that F raises" and figure out an appropriate format for the table's entries. That is about half the point of this discussion (to provoke thought about how one might express this); the other half is to note that the documentation could probably be improved (as someone else already noted elsethread). Note that, if nothing else, the tool -- even in limited form, without the kind of type inference that pylint attempts -- gives you the ability to automate part of the documentation process. -- In-Real-Life: Chris Torek, Wind River Systems Intel require I note that my opinions are not those of WRS or Intel Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603 email: gmail (figure it out) http://web.torek.net/torek/index.html
-- http://mail.python.org/mailman/listinfo/python-list