[Python-ideas] why not try without except?

[Georg Brandl]

spir schrieb:
> Le Sun, 26 Apr 2009 11:05:56 +1000, Steven D'Aprano <steve at pearwood.info> 
> s'exprima ainsi:
> 
>> On Sat, 25 Apr 2009 11:32:39 pm Georg Brandl wrote:
>> 
>>> And while we're at it, let's introduce
>>> 
>>> on error resume next: foo() bar() baz()
>> 
>> Is that meant to be a serious suggestion or a sarcastic rejoinder?
> 
> It is certainly sarcastic -- never mind -;) Georg could have saved some 
> typing by reading comments and examples...
> 
> What I had in mind (and commented), is precisely not a syntactic construct 
> able to catch any exception for a whole block of statements.

It certainly sounded that way in the original post.

> E.g. an example like option self.fill(self.fillColor) can only catch 
> AttributeError for 'fillColor' or for 'fill'.

Or AttributeErrors raised inside of fill().

> Now I realise that what I miss is a kind of handy, clear, and not misuseable
>  idiom for coping with undefined variables/attributes/parameters. Otherwise 
> one needs to fall back to the reflexive-check-instead-of-try idiom: if 
> hasattr(self,'fillColor'): self.fill(self.fillColor) or use try... except ...
>  pass.

That depends.  Usually you would always make "fillColor" an attribute of the
object, and either let fill() accept None or not call it if fillColor is None.

> 'None' is also often (mis)used for this. People aware of the issues with None
> will rather have a custom undef-meaning object instead. Right? UNDEF =
> object()

No.  None is exactly meant to indicate the absence of a meaningful value.

> This is rather close to the use of Haskell's optional type (I guess it's 
> called 'Maybe' -- checked, see e.g. 
> http://en.wikibooks.org/wiki/Haskell/Hierarchical_libraries/Maybe). And I 
> think Scala has something similar, too. But these special types fit well the
>  semantics of statically-typed and compile-time-checked languages.

And in Python, None fills the role of Haskell's "Nothing" constructor.  There
is no need for a "Just" constructor, since we don't have static types.

> One issue with None is that it can be used as a valid value.

Of course.  Every object is a "valid value".

> A workaround may be a user-unsettable undef-meaning builtin value. Or a
> builtin isDef() function.

It seems you should make sure you know how Python handles namespaces.

> Still, both of these methods require checking. While the 'option' (or '?')
> proposal allows trying-instead-of-checking. Why not restrict it to a set of
> sensible exception types? for instance (this is what I would like):
> 
> option foo or ? foo <==> try: foo except (NameError, AttributeError): pass

It is almost always an error if a local name is not defined.  I've already
covered the case of AttributeErrors above.

> Moreover: Haskell's Maybe type can be used for return values. I really wonder
>  about python action-functions (that do not produce a result) returning None
>  instead of nothing at all.

Functions implicitly returning None is just a convention.  If you don't like
the ambiguity between "procedures" returning None and "functions" returning
None, define your own "not-valid" value and return it from functions.  It won't
result in code that is easier to read though.

> This is another story, indeed, but I see it 
> closely related at the meaning level.
>     searched = seq.find(....)	# may not return anything, not even None

What is "searched" supposed to be, then?  "Not anything" is not an option.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.