stylistic question -- optional return value

[Erik Max Francis]

Stefan Schwarzer wrote:

> How do you know that you really got a dictionary and not some object
> of a class
> that looks like a dictionary at first sight? IMHO, you have to define
> the interface
> anyway.

If it has a mapping interface and it looks like a dictionary even though
it really isn't one, that's fine too.  If I do a repr and see {...}, I
have a good idea what to do with it.  If I see <DummyClass instance
0x7395473>, it's not at all clear that it's really just a dummy "struct"
(in the C sense, not the Python module sense) and I'm supposed to access
its members named such and so.  If it's a dictionary, or a
dictionary-like mapping object, then it's much clearer.

> I think that depends on the circumstances. As a guideline, I would use
> a custom
> class if the return value has an abstract meaning that should be
> covered by a class.

As I mentioned in another article, if the return value is really going
to be a proxy that's going to do be used to do some complicated
behavior, then it makes sense to return a full-fldged class instance
with well-defined methods.  The example I used was a statement parsing
function that returned a Command instance that you'd call the .execute
method of to engage the command.  In that case you are talking about a
full-fldged instance, rather than just an aggregate object.

-- 
 Erik Max Francis / max at alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/  \ There is nothing so subject to the inconstancy of fortune as war.
\__/ Miguel de Cervantes
    Church / http://www.alcyone.com/pyos/church/
 A lambda calculus explorer in Python.