Re: [Python-Dev] Comments of the PEP 3151
On Mon, 25 Jul 2011 15:28:47 +1000 Nick Coghlan wrote: > > > If we add EINTR, I don't know if it's better to add it to > > BlockingIOError or to create a new exception (InterruptError?). > > InterruptedError seems like a reasonable candidate for addition to me > - catch and retry in that case is something developers are likely to > want to do. Ok, let's call it InterruptError then. InterruptedError sounds like the error was interrupted ;) > Perhaps EPIPE should map to FileDescriptorError along with EBADF, with > different messages based on the exact error code? Potentially renamed > to DescriptorStateError? I'd rather have a separate BrokenPipeError for EPIPE. EBADF and EPIPE are really quite different; EPIPE indicates that the other end of the pipe closed it, while EBADF generally points to a programming error (you are giving an invalid file descriptor to a system routine). > To be honest though, what's the use case for *catching* > FileDescriptorError without catching IOError in general? Perhaps this > one should be dropped entirely, to be handled by broadly catching > IOError? Good point indeed. > > I'm in favor of adding a note in the documentation of all legacy > > exceptions to advice to use IOError or specific exceptions instead. I > > suppose that these notes will have to indicate a Python version. > > +1 for grandfathering in the old exception names, but documenting the > recommended alternatives as of 3.3. Ok. > It may also be reasonable to return a new DeviceNotAvailableError for > ENODEV and EBUSY (as a new FileSystemError subclass). EBUSY is really quite different from these other errors. It is triggered by runtime protections in the OS (can't destroy some object that is in use, see for example in pthread_cond_destroy: http://pubs.opengroup.org/onlinepubs/009604499/functions/pthread_cond_destroy.html), rather than indication some misassumption about the filesystem layout. As for ENODEV, I'll have to take a look. > There may be some error codes that we choose to map to these generic > errors, even if we don't give them their own exception types at this > point (e.g. ECONSHUTDOWN could map directly to ConnectionError). Good point as well. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Comments of the PEP 3151
On 7/25/2011 3:43 AM, Antoine Pitrou wrote: On Mon, 25 Jul 2011 15:28:47 +1000 Nick Coghlan wrote: > > > If we add EINTR, I don't know if it's better to add it to > > BlockingIOError or to create a new exception (InterruptError?). > > InterruptedError seems like a reasonable candidate for addition to me > - catch and retry in that case is something developers are likely to > want to do. Ok, let's call it InterruptError then. InterruptedError sounds like the error was interrupted;) Sorry, no. "InterruptError" sounds too much like a CPU interrupt signal, which the error is not. "InterruptedError" is OK by me, I don't see the confusion you do. But maybe "InterruptedOperationError" would be the most clear. Way too long, of course, so maybe "InterruptedAPIError" or "InterruptedOpError" or "EINTRError" in my order of preference. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Comments of the PEP 3151
On 25/07/2011 02:24, Antoine Pitrou wrote: Hello, By the way, is it faster to not handle and than re-raise unwanted exceptions? You mean "is it faster to not handle than re-raise unwanted exceptions?". It probably is, yes. I asked if: try: ... except FileNotFound: pass is faster than: try: ... except IOError as err: if err.errno != errno.ENOENT: raise else: pass f an IOError with errno != ENOENT is raised. I don't understand how Antoine decided which errno should have an exception or not. Mostly experience with the stdlib combined with intuition. The list is not cast in stone. "The list is not cast in stone." : ok :-) If we add EINTR, I don't know if it's better to add it to BlockingIOError or to create a new exception (InterruptError?). EINTR is not related to non-blocking I/O, so it shouldn't map to BlockingIOError. Ok, so let add InterruptError. Would it be possible to have an (exhaustive?) list of errno with their popularity? At least, their popularity in the Python standard library? How do you suggest to do that? Use the list of all errno from the Appendix A, and then count the number of occurence in the Python source code (excluding the test suite). You can for example using a shell for that: $ grep -h -c EINVAL $(find -name "*.py"|grep -v Lib/test)|grep -v '^0$' 1 1 2 These numbers give an approximation of the popularity of the different errno. Does raising a specific error (e.g. raise FileNotFound()) set errno and message attributes (to something different than None)? No, ... As for the message, like with every other exception it should be supplied by the developer. Ok, I agree. Do specific errors slows down raising exceptions? Do raising an IOError (or a "legacy" error) use a O(1) lookup to choose the exception class? It uses a dict. You could run some benchmarks if you want, but I doubt it makes much sense to worry about that. Ok, a dict should be fast. EACCES and EPERM have a different meaning. Even that they are very similar, we might provide two different exceptions. EPERM is only used once in the Python stdlib, so we might only provide AccesError. On Linux, EPERM usually indicates an operation requiring root priviledge. EACCES can be related to filesystem permissions (read-only, user is not allowed to write, etc.) or can be an mmap error. I'd have to research that a bit more. Perhaps EACCES can be mapped to AccessError and EPERM to PermissionError, but I think the proximity of the two concepts will make things confusing, for little benefit. You are probable right. WindowsError and winerror attribute --- I don't like the idea of having a winerror attribute platforms other than Windows. Well, there isn't, as you can see in the tests Oh, it's not clear in the PEP. Should FileNotFound handle ENODEV? (see test_ossaudiodev) That's not really the same thing. Ok. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Comments of the PEP 3151
Glenn Linderman wrote: On 7/25/2011 3:43 AM, Antoine Pitrou wrote: On Mon, 25 Jul 2011 15:28:47 +1000 Nick Coghlan wrote: > > > If we add EINTR, I don't know if it's better to add it to > > BlockingIOError or to create a new exception (InterruptError?). > > InterruptedError seems like a reasonable candidate for addition to me > - catch and retry in that case is something developers are likely to > want to do. Ok, let's call it InterruptError then. InterruptedError sounds like the error was interrupted ;) Sorry, no. "InterruptError" sounds too much like a CPU interrupt signal, which the error is not. It does, a bit -- but is that something we need to worry about at the Python level? Seems to me we should have the names make sense for Python, and not worry about what assembly, C, Pascal, Perl, or language X here> names might mean for them. "InterruptedError" is OK by me, I don't see the confusion you do. But maybe "InterruptedOperationError" would be the most clear. Way too long, of course, so maybe "InterruptedAPIError" or "InterruptedOpError" or "EINTRError" in my order of preference. Please not that last one! ;) I prefer InterruptedError or InterruptError. ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Convention on functions that shadow existing stdlib functions
On Sat, Jul 23, 2011 at 20:35, Eli Bendersky wrote: > Some background: I'm working (on and off) on issue 11015 - documenting > the public functions in test.support > > Some of the functions in test.support (for example unlink, rmtree) > simply shadow existing & popular stdlib functions, with the aim of > swallowing the exceptions these may throw. This is confusing, IMHO. > For example, grepping 'unlink' on Lib/test/test_*.py files doesn't say > much about which unlink is being used. > > A couple of options to handle this are: > > 1. Remove these functions altogether, trying to use existing > constructs (such as the ignore_errors parameter in rmtree). > 2. Adapt a naming convention for such functions, for instance > rmtree_silent and unlink_silent (or a similar convention, if one > exists) > > Opinions? > The mere fact that these functions exist in a different module suggests different semantics from those found in other places in the stdlib. I don't think they should be renamed simply because some code imports the functions directly instead of the module itself (suggesting they should be doing the latter over the former). Now if the functions are redundant that's something else entirely and removal should be fine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Comments of the PEP 3151
On Tue, Jul 26, 2011 at 4:44 AM, Ethan Furman wrote: > Glenn Linderman wrote: >> >> On 7/25/2011 3:43 AM, Antoine Pitrou wrote: >>> Ok, let's call it InterruptError then. InterruptedError sounds like the >>> error was interrupted ;) >>> >> >> Sorry, no. "InterruptError" sounds too much like a CPU interrupt signal, >> which the error is not. > > It does, a bit -- but is that something we need to worry about at the Python > level? Seems to me we should have the names make sense for Python, and not > worry about what assembly, C, Pascal, Perl, or > names might mean for them. Like Glenn, I believe "InterruptError" sounds wrong - the event being reported is that a system call was interrupted for some unknown reason, not necessarily that the process received an interrupt. 'Interrupt' in computer science requires context to distinguish between the verb and noun forms, and an exception name doesn't provide that context. 'Interrupted' forces interpretation as the past tense of the verb form, which is the meaning we want. If the subject of the verb feels too ambiguous then I'd prefer to switch to the explicit adjective form 'InterruptedCallError' rather than allowing the verb/noun ambiguity. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Comments of the PEP 3151
Ethan Furman wrote: > > […] or "EINTRError" in my order of preference. > > Please not that last one! ;) Why not, exactly? When EINTR happens it's frequently a surprise, but programmers new to the concept can always search the web for advice on what causes it and how to deal with it (and after several attempts at dealing with it they may even get it right). Searching Google for “InterruptedError” isn't going to find anything helpful today, and eventually what I expect it would find is a bunch of pages saying “Look up EINTR.” How about we just cut out that middle step and call it what the rest of the world calls it? If “InterruptedError” were going to be used for anything other than EINTR then I could see an argument for abstracting the concept behind a platform-independent name. But I think it would be a mistake to treat anything else as being the same as EINTR. -Andrew. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Comments of the PEP 3151
On Tue, Jul 26, 2011 at 10:26 AM, Andrew Bennetts wrote: > When EINTR happens it's frequently a surprise, but programmers new to > the concept can always search the web for advice on what causes it and > how to deal with it (and after several attempts at dealing with it they > may even get it right). Searching Google for “InterruptedError” isn't > going to find anything helpful today, and eventually what I expect it > would find is a bunch of pages saying “Look up EINTR.” How about we > just cut out that middle step and call it what the rest of the world > calls it? > > If “InterruptedError” were going to be used for anything other than > EINTR then I could see an argument for abstracting the concept behind a > platform-independent name. But I think it would be a mistake to treat > anything else as being the same as EINTR. The whole point of PEP 3151 is so that Python programmers can perform key tasks without needing to worry about the existence of error numbers under the hood. Including the cryptic errno abbreviations in the interrupt names would completely miss the point. However, the docs will point to appropriate information in the errno module (and the exception details and docstrings may also mention the errno codes). Abstractions do leak, after all, but that doesn't mean we need to go punching holes in them with an icepick. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Comments of the PEP 3151
Andrew Bennetts wrote: Ethan Furman wrote: […] or "EINTRError" in my order of preference. >> Please not that last one! ;) Why not, exactly? Because this is Python, and readability counts. Yes, it does take some getting used to (I finally stopped typing 'enum' a couple months ago ;) , but it is a worthwhile goal -- a goal we take a step back from with names like EINTRError instead of InterruptedError. ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Comments of the PEP 3151
Glenn Linderman writes: > Sorry, no. "InterruptError" sounds too much like a CPU interrupt > signal, which the error is not. "InterruptedError" is OK by me, I don't > see the confusion you do. But maybe "InterruptedOperationError" would > be the most clear. Way too long, of course, so maybe > "InterruptedAPIError" or "InterruptedOpError" or "EINTRError" in my > order of preference. Eh, doesn't it bother anybody that it's not an error, but a user action? If it needs a separate name, something like InterruptException seems most accurate to me. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Comments of the PEP 3151
On Tue, Jul 26, 2011 at 1:47 PM, Stephen J. Turnbull wrote: > Eh, doesn't it bother anybody that it's not an error, but a user > action? Nope, doesn't bother me in the slightest. It's an error number code, just like all the others. Several other error numbers may or may not be errors too, depending on context. Rather than quibbling about that part of the naming scheme it's easier to say that the call failing to complete successfully is an error by default, but an application may choose to interpret some cases as not really being errors, since there's a defined response (most obvious case: a file or directory already existing or not existing often isn't an error from the application's point of view, it's just the application ensuring that a particular configuration exists on the file system in an idempotent fashion). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
