On Fri, Apr 10, 2020 at 11:35 PM Soni L. fakedme+py@gmail.com wrote:
On 2020-04-10 10:15 a.m., Chris Angelico wrote:
On Fri, Apr 10, 2020 at 8:05 PM Greg Ewing greg.ewing@canterbury.ac.nz wrote:
On 10/04/20 8:30 am, Soni L. wrote:
Sometimes, you have an API:
@abc.abstractmethod def get_property_value(self, prop): """Returns the value associated with the given property. Args: prop (DataProperty): The property. Returns: The value associated with the given property. Raises: PropertyError: If the property is not supported by this config source. LookupError: If the property is supported, but isn'tavailable. ValueError: If the property doesn't have exactly one value. """ raise PropertyError
This doesn't really look like a Python API. It's fairly rare in Python for exceptions to be used to indicate anything other than "something unexpected went wrong".
StopIteration wants to say hello :)
and look at what we ended up doing to that one! it now becomes RuntimeError in many places, because it was getting regularly swallowed previously.
if that's not an argument for this proposal, idk what is.
It only becomes a RuntimeError in one place that I'm aware of: escaping from a generator function. And that is ONLY because generators are built on top of iterators but have their own way of signalling a non-return. Everywhere that exceptions are used as a non-exceptional form of control flow, it is because the function could return literally any value, and therefore can't signal a non-return in any other way. For instance, __getattr__ has to raise AttributeError if the attribute doesn't exist, because there is no value that could be returned to indicate "attribute doesn't exist".
How do you propose to resolve that, with this proposal? Massive massive code overhead so you have to request every exception that might occur? Because, quite frankly, your proposed code is *ugly*. In my totally not-opinionated opinion. :)
ChrisA