True, False, None

[Andrew Dalke]

Dave Benjamin:
> I thought the old rule of thumb was that if its main purpose was to expose
a
> class, name it after that class (and capitalize), otherwise, name it after
> the concept it represents, in lower case.

For the most part, yes.  But consider 'cStringIO'.  And why is
'gzip' not named GzipFile?  (Or both named 'Gzip'?)

> If you were to use a module as a singleton value or namespace, would you
> capitalize it?
>
> Just curious,

I'm trying to think of a time when I've used a module as anything
other than a module, that is, where the normal module naming
guidelines applied.  I can't think of one.

I have used a class as a singleton, eg, if I really need
to know if one argument was passed in or two.  (This
is rarely needed and should almost never be used in
real code.)

class _default:
  pass

def f(a, b = _default):
  if b is _default:
    print "One parameter"
  else:
    print "Two parameters"

Here I used lower-case. I think that's what I normally do.
However, I'm one who would have had that 'True' and
'False' be in lower-case.  My comment about how the
singleton nature affects the capitalization was conjecture.

I've not seen that conjecture presented before.  I'm now
wondering if it doesn't actually make some decent sense,
so that my own singletons -- where there is a fundamental
expectation for singleton-ness in the object model and
not just an aspect of the implementation -- will get a
leading capitalization.

To make things even more complicated, it wasn't until
the MOP that it was possible to have a true user-defined
singleton instance.

(Hmm.  If I have an Atom class with a reference to
an Element then the Element should be a singleton and
will be named Tungston or Scandium or Helium ... or
maybe W, Sc, He.  In any case, leading upper case.)

                    Andrew
                    dalke at dalkescientific.com