On Tue, Aug 30, 2011 at 7:18 AM, Barry Warsaw <ba...@python.org> wrote: > Okay, so here's what's still outstanding for me: > > * Should we eliminate FileSystemError? (probably "yes")
I've also been persuaded that this isn't a generally meaningful categorisation, so +1 for dropping it. ConnectionError is worth keeping, though. > * Should we ensure one errno == one exception? > - i.e. separate EACCES and EPERM > - i.e. separate EPIPE and ESHUTDOWN I think the concept of a 1:1 mapping is a complete non-starter, since "OSError" is always going to map to multiple errnos (i.e. everything that hasn't been assigned to a specific subclass). Maintaining the class categorisation down to a certain level for ease of separate handling is worthwhile, but below that point it's better to let people realise that they need to understand the subtleties of the different errno values. > * Should the str of the new exception subclasses be improved (e.g. to include > the symbolic name instead of the errno first)? I'd say that's a distinct RFE on the tracker (since it applies regardless of the acceptance or rejection of PEP 3151). Good idea in principle, though. > * Is the OSError.__new__() hackery a good idea? I agree it's a little magical, but I also think the PEP becomes pretty useless without it. If OSError.__new__ handles the mapping, then most code (including C code) doesn't need to change - it will raise the new subclasses automatically. If we demand that all exception *raising* code be changed, then exception *catching* code will have a hard time assuming that the new subclasses are going to be raised correctly instead of a top level OSError. To make that transition feasible, I think we *need* to make it as hard as we can (if not impossible) to raise OSError instances with defined errno values that *don't* conform to the new hierarchy so that 3.3+ exception catching code doesn't need to worry about things like ENOENT being raised as OSError instead of FileNotFoundError. Only code that also supports earlier versions should need to resort to inspecting the errno values for the coarse distinctions that the PEP provides via the new class hierarchy. > * Should the PEP define the signature of the new exceptions (e.g. to prohibit > passing in an incorrect errno to an OSError subclass)? Unfortunately, I think the variations in errno details across platforms mean that being too restrictive in this space would cause more problems than it solves. So it may be wiser to technically allow people to do silly things like "raise FileNotFoundError(errno.EPIPE)" with the admonition not to actually do that because it is obscure and confusing. "Consenting adults", etc. > * Can we add ECHILD and ESRCH, and if so, what names should we use? +1 for ChildProcessError and ProcessLookupError (as peer exceptions on the tier directly below OSError) > * Where can we capture the idea of putting the symbolic names on OSError class > attributes, or is it a dumb idea that should be ditched? "Tracker RFE" for the former and "maybe" for the latter. With this PEP, the need for direct inspection of errno values should be significantly reduced in most code, so importing errno shouldn't be necessary. > * How long should we wait for other Python implementations to chime in? "Until Antoine gets back from his holiday" sounds reasonable to me. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
