[Python-ideas] PEP-3151 pattern-matching

M.-A. Lemburg mal at egenix.com
Fri Apr 8 11:53:42 CEST 2011


Nick Coghlan wrote:
> On Fri, Apr 8, 2011 at 6:59 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>> Their use may be inconsistent in a few places, but those cases
>> are still well-defined by the implementation, so code relying
>> on that well-defined behavior will break in subtle ways.
> 
> The phrases "defined by the implementation" and "well-defined" do not
> belong in the same sentence.

I agree that exceptions being raised by certain APIs
should probably be documented, but in the absence of such documentation,
the implementation is still the ultimate source of wisdom and
given that it's written down in C and not some legal code, I
think "well-defined" is an appropriate term ;-)

>> Example:
>>
>> If code catches select.error (which is only raised for select.select()
>> and poll_object.poll() calls), because the try...except is expecting
>> a possible error from the select call used in the try...except
>> block, it will most likely do the wrong thing for some IOError
>> raised by a logging file I/O call in that same block.
> 
> A deprecation period for the merged exceptions would be advisable.
> That's an argument in favouring of figuring out how to implement
> correct deprecation warnings for the merges, not an argument in favour
> of not doing them.

Indeed, getting deprecations right is yet another aspect to consider,
but not the one the example was supposed to explain.

I don't think that such major changes in class hierarchy can be
implemented in a minor Python release.

Note that select.error currently does not inherit from IOError,
so "except IOError" won't catch select errors.

Renaming the exceptions would be something we could do for a
minor release and then have deprecations hint the user to
the naming change.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 08 2011)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/



More information about the Python-ideas mailing list