Home Original page

Yet Another Case Question

Alex Martelli aleax at aleax.it
Mon Feb 24 13:36:16 EST 2003 
rzed wrote:
   ...
> I didn't mean that it was only possible to honor the convention. I

Yet that's what it means to say "the convention is enforced", which
is what you did.  If it can easily be broken, it's not enforced, by
definition of the verb "to enforce".

> meant that a constant defined in all caps would have to be referred to
> in all caps in a case-sensitive language. It is only a *convention*
> that constants be named with all-cap names, not a law. My point was

If you don't care whether it's enforced, that's fine with me, but
it's still false to say it IS enforced.

> that if BAZ is a constant meaning 'frobbish', then trying to refer to
> it as baz would fail now; but it would succeed perfectly well in a
> case-insensitive language, which suggests to me that I would be likely
> to find it typed both ways in various people's code. I don't consider

Exactly as you are now -- math.pi in lowercase, and so on.

> that a benefit, really. Others might.

Unless you go whole hog, Haskell-like, and DO enforce the convention
(then it DOES become a law), you'll always find constants spelled
not-all-uppercase and the like.  It's neither a benefit nor a loss,
it's simply the reality -- how things are NOW in the standard Python
library and how they will presumably be forevermore.

IF Python was case-insensitive, you might freely PRETEND the
convention was universally applied, spelling that particular
constant as math.PI in your code for example.  As things stand
(and will keep standing, alas), you cannot even pretend: you
must inherently acknowledge every time you use something as
fundamental as standard module math that the convention is in
fact broken all over the place.  Quite a way from "enforcing"!!! 


> I don't see that it's a lot harder to remember that spelling than it
> would be if case didn't matter, and in actuality, I don't see it as
> any harder to remember. If it's something I use a lot, I'll learn the
> case pretty quickly. If I seldom use it, I maybe won't, but I won't
> necessarily learn the name, either. (Okay, I can handle 'pi' but I'm
> speaking of the generality here.) It's the same with parameter

Take audiodev then, since you're "speaking of the generality".

When a module named foo has a main feature named in the same way,
foo, quite a frequent case, I must memorize "1 + epsilon" things:
the name itself, plus the fact that this is one of the many
modules whose main feature has the same name,

But for audiodev I must ALSO memorize TWO capitalizations for
the SAME word, applied once to a module, once to a function:
it MUST be spelled all lowercase when I mention the module, it
MUST be spelled with a capital A and D when I mention the
function within the module.

Are you claiming it's NOT harder to remember all of these silly,
fussy, finicky and useless details?!  That Python would be a
WORSE language if I *COULD* just apply the convention, and call
the function within the module by all-lowercase spelling,
audiodev.audiodev, REDUCING the sheer, silly memorization load
on myself?

Case sensitivity combines with human nature to force me to
memorize "audiodev.AudioDev" *EXACTLY*.  I claim this gives
NO added value wrt letting me spell this "audiodev.audiodev"
as a case-insensitive language would do.  HOW MUCH memorization
load is added by the extra task of memorizing that THIS module
has a lowercase name but a MixedCase main function, that OTHER
module lowercases both, that THIRD module MixedCases both, etc,
etc, may presumably differ by-person, but, it IS quantifiable
somewhat objectively in terms of bits.  And each and every one
of these extra bits I'm forced to memorize is useless -- sheer
makework imposed on me by case-sensitivity, without ANY
enforcement of any convention whatsoever.

> understand your point about case, really. It's just that case
> conventions *are* useful to those of us who use them, and the one I

Explain to me how it's USEFUL to you to have to memorize which
modules, classes, functions and constants in the standard Python
libraries use which peculiar capitalization.  How does it
enhance the productivity of your usage of Python?  I hope the
way in which such useless memorization tasks REDUCES (by a lot
or a little) MY OWN productivity, as well as that of every
person or bot whose memory bits have any positive cost no
matter how small, is obvious -- wasted bits.  I'm curious to
understand the mechanisms in which loading some memory bits
with irrelevant, arbitrary information might be "good" for you.

Please don't bother explaining how "discipline is good for you"
in the general sense, otherwise you'd also be arguing for Python
to impose a lot of other things it now doesn't -- e.g., as I have
already repeatedly pointed out (and haven't seen any answer to),
if discipline is so good for its own sake then
a+b
a + b
shouldn't be accepted as equivalent, should they?  So sloppy...

I don't accept the general argument of "discipline is good for
you", or I wouldn't be using Python -- there is a huge number
of languages imposing far more silly, arbitrary, useless rules
that must be followed blindly.

> describe *are* common. Take case recognition away and you have to
> replace case difference with name difference. People are quite

That's in the specific case when you WANT a module to _expose_
two names that ONLY differ by case.  How many examples of that
can you find in the Python standard library?  I'd bet there must
be some but none comes to mind offhand, while violations of
whatever conventions you might like to claim as "enforced" are
a dime a dozen.  For LOCAL names, NOT exposed outside of the
module, who cares, really -- the importance of such details of
implementation is just orders of magnitude lower than the
importance of *INTERFACES*.


> Dealing with other people's code is never automatic, and
> case-insensitivity is not a silver bullet that will fix that
> situation. Ultimately, it all comes down to, as you say, compulsive

The fact that there is no silver bullet is no argument for
deliberately wetting your powder too.  Wearing good and
appropriate shoes is far from _sufficient_ to run a decent
marathon, but that's no argument for running a marathon
with spike-heeled shoes.  No matter how _relatively_ small
in importance shoe choice may be, compared with the MANY
other factors needed to prepare yourself for running a good
marathon, this STILL doesn't argue for saddling yourself
with silly extra obstacles due to choosing the wrong shoes.


Alex
More information about the Python-list mailing list