total idiot question: +=, .=, etc...

[Alexander Williams]

On 24 Jun 1999 21:09:19 -0500, Neel Krishnaswami <neelk at brick.cswv.com> wrote:
>IMO, it's bad style to set properties that should belong to the type
>in the instance initializer -- for example, the sort order is
>something that's a property of the class, rather than the instances.

Here's the crux of the problem, a sense of asthetics at variance with
the usefullness of your code.  Allow me to present a dissenting view:

Setting properties which can vary dynamically over the life of an
instance should be set on the instance itself, since the Class itself
may have multiple instantiations in a multithreaded or
multi-persistance environment.  Ultimately, it becomes easier to note
and manage varying fields on instances as they are easily seen in the
__init__ function (and so satisfy lexical locality in finding them for
maintainance) as well as cuts back on strange circumlocutions in
dealing with them syntactically.

>    sortorder = 'date' # can be anything in Article.comparators.keys()

Let's assume you set this in the __init__:

def __init__(me):
    me.sortorder = 'date'

>    def __cmp__(self, other):
>        return self.__class__.comparators[self.__class__.sortorder](self,
>                                                                    other)

.... then this becomes:

def __cmp__(me, them):
    return me.comparators[me.sortorder](me, them)

Note that comparators is set on the instance by inheritance, so we
don't need to obscure that with a specialized __class__ reference, and
with sortorder being an instance variable, there's no need for
obscuration /there/, either.

>I want the user to be able to determine how a list of Article's can be
>sorted by setting the class's sortorder member. So a statement like
>
>>>> Article.sortorder = 'author'
>
>would change how lists of articles are sorted. This is definitely 
>something that's shouldn't be an instance attribute, imo; it would
>defeat the purpose if each article could compare differently than
>any other. (Oppose standardized testing! :])

In this case, the order in which articles are sorted shouldn't be on
the Article object at all, then!  Remember, encapsulation,
encapsulation.  Sort-order storage should be on the object that you
use to contain references to Article-objects, and thus only needs to
be changed in one place at one time (but still should be an instance
variable, since it does change dynamically and shouldn't be inherited
by all children of ArticleStore, since each may want to be sorted in a
different way, providing different views into the same data).

>It's perfectly reasonable for someone else to subclass Article and
>override the Article.comparators attribute. (Say to add an ordering to
>put Tim Peter's posts at the top of the list, or to use something
>faster than my lambdas.) With the clear way of writing it, the
>NewArticle class would mysteriously fail to do the right thing,
>because the __cmp__ method would look in the Article class dictionary
>without bothering to check NewArticle's.

See above; note that calling me.comparators will /always/ work with
inheritance. 

>This is an unusual glitch in Python; usually the readable way of doing
>something is the right way of doing it. 

Ah, but it /is/ the right way, you're just insisting on the wrong way
out of a twisted sense of asthetics.  :)

-- 
Alexander Williams (thantos at gw.total-web.net)
"In the end ... Oblivion Always Wins."