Case sensitivity

[Alex Martelli]

Greg Ewing (using news.cis.dfn.de) wrote:

> Alex Martelli wrote:
>> So introduce a beginner to the excellent and very useful
>> module mx.DateTime and explain to him, or her, how and
>> why he or she needs to memorize (or continuosly check or
>> try) that the functions named (e.g.) 'today', 'localtime',
>> or 'add_century' MUST be lowercase, while (e.g.) functions
>> 'TimeFrom' and 'Age' and 'Time' MUST be mixed-case.  Pah.
> 
> That's a problem with the design of the mx.DateTime module,
> not with the concept of case-sensitivity.

If you think so, then I believe you should reply to Marc
Andre Lemburg's explanation of the rationale for that design
in his followup to my post.  I happen to agree with Marc
Andre that the rationale is sound -- and the implication
that there will ALWAYS be murky cases, "thanks" to case
sensitivity, requiring sheer memorization.  mx.DateTime is
SO deservedly popular that I don't think you should diss
its design choices just to try to make a point: difficulties
it unearths are likely to be inherent in the language.

Think of the issue more generally.  Classes by convention
should have capitalized names, while functions have names
that are lowercase.  So what we do for factory functions,
which are, yes, functions, but also "constructors" for
class instances?  Say that I want Foo(xxx) to construct a
Foo instance normally, but a Bar instance in some cases.

In Python 2.2 I can overload Foo.__new__ for the purpose.
But to support earlier versions (and the author of a very
popular module will want to, won't he?) then Foo should in
fact be a function -- a "factory function", as it's usually
called.  Do I _have_ to expose that implementation choice
by renaming Foo to foo, showing it's a function and not a
class?  If my implementation makes Foo a class in 2.2 but
a function in 2.1, do I have to use different capitalization
and thus make the two versions of my package incompatible?
As if these design problems weren't interesting and
challenging enough, case sensitivity makes them dramatic...

Point is, distinguishing between functions and classes is
NOT necessarily what I want, if and when I want them to
be used interchangeably, polymorphically, e.g. as factories
for class instances.  So it's quite reasonable to have SOME
functions -- the factories -- follow the capitalization
convention for classes... but then where do you draw the
line, WHICH functions must be all-lowercase instead?  Any
decision will have some arbitrary cut-off point where no
clear reason one way or another can be given, so it boils
down to sheer memorization.  And people who still have not
entirely memorized the exact capitalization of every name
exported by the module will get runtime errors, with some
slight but negative effect on their productivity.

And I definitely don't think it's Marc Andre's fault.  But
as I said, if you want to make a case that it is, I think
you should make it in following up to HIM, not to ME...


Alex