mixed solution: unicase (unique allowed case) (was: Re:

[Tim Rowe]

In article <BXh_4.4616$Hz.35258 at news-server.bigpond.net.au>, 
neilh at scintilla.org (Neil Hodgson) wrote:

> > >>> class Foo:
> > ...    pass
> > ...
> > >>> def bar(foo = None,
> > ...    # /lots/ of other optional parameters
> > ...    ):
> > ...    # some implementation
> > ...
> > >>> baz = Foo()
> > >>> bar(foo = baz)
> 
>    Wouldn't 'foo' be better used to describe its role rather than its 
> type.
> 
>    bar(output = baz)

Depends. For instance, I'm working on something at the moment that uses a 
flyweight character class, and being a flyweight the context is separated 
from the class itself. So, for instance, the method that renders needs to 
be passed a Tkinter.Canvas on which to render. It makes sense to me to 
define the method as:
	def render(canvas, ...)
If I call it "output", "context" or some such then it's not clear what to 
pass; calling it "canvas" makes it self-documenting. Using "output_canvas" 
or some such is more verbose and IMHO adds nothing at all to clarity -- if 
anything the verbosity detracts from the clarity. I /used/ to use the 
convention "a_canvas", but I found it to be nowhere near as clear & 
maintainable.