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

[Neil Hodgson]

> > > >>> 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, ...)

   So it is a required parameter? In the original problem statement it was
an optional parameter, which is why the name is more prominent. I agree that
the primary subject of a call may sensibly follow a different naming scheme
than a bunch of optional arguments which generally indicate 'flavourings' of
a call.

> If I call it "output", "context" or some such then it's not clear what to
> pass; calling it "canvas" makes it self-documenting.

   Mmm. Fixing up Python's lack of strictly typed parameters ;)

> 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.

   I'm thinking about moving the opposite way (I sometimes currently use
lower case class names for class instances) and starting to write aCanvas
rather than canvas as it doesn't seem much additional verbiage to remove an
opportunity for confusion.

   Neil