case-sensitivity (was Re: True, False, None)

[Michele Simionato]

Alex Martelli <aleax at aleax.it> wrote in message news:<yRssb.11182$9_.422629 at news1.tin.it>...
> So, when I used to have a factory function (as 'int' was), and change
> it into a type (or class, same thing), I should rename it and break all
> existing programs that would otherwise keep working just fine?  Or
> would you prefer to bloat the built-in namespace (or module namespace
> where such refactoring is going on) by having both 'int' _and 'Int'?

This is one of the reasons why I said "I am not sure if I want to
enforce the capitalization or if I want a code convention".
A code convention would be better for the situation you are talking
about; the situation I had in mind was a class with an (abused)
__new__ method, such that it works as a function (i.e. does not
return instances of the class). Using a lowercase would document
the fact that the class is intended to be used as a function.
But these are very rare cases, so probably I could live with an
enforced capitalization too.

> > I never understood why you advocate case insensitivity. I would expect
> > case insensitivity to be a source of bugs: for instance, identifiers
> > with similar names could be confused (es. myfunction vs. myFunction):
> > one would expect them to be different (at least people coming from
> > case insensitive languages) whereas they would be the same.
> 
> People coming from (an exclusive diet of) case _sensitive_ (not, as you
> say, INsensitive!) 

Oops! You understood, it was a misprint ;)

> But people's expectations when they first meet Python are only a
> part of it.  More relevant is, how usable are the two possibilities?
> Case sensitivity means you must basically memorize several more bits
> to go with each name -- for no good reason whatsoever.  You must
> remember that module FCNTL has an all-uppercase name, htmllib all-lower,
> cStringIO weirdly mixed, mimetypes lower, MimeWriter mixed, etc, etc --
> totally wasted mnemonic effort. 

This is more a problem of inconsistent conventions. It is true that
it will disappear with case insensitivity enforced, but somewhat I
don't feel it a reason strong enough.

> Then you get into the single modules
> for more of the same -- unless you can know what is conceptualized as
> "a class" vs "a type" vs "a function" memorization's your only hope,
> and if you DO know it's still learning by rote, incessantly (ah yes,
> class dispatcher in module asyncore, that's LOWER-case, ah yes, the
> 'error' exception class, that's lowercase in sunaudiodev, it's
> lowercase in socket, and in anydbm, and thread -- it's uppercase Error 
> in sunau, and also in shutil, and multifile, and binhex ... and
> functions are supposed to start lowercase?  Yeah right, look at
> imaplib and weep.  or stat.  or token... And you think your troubles
> are over once you've got the casing of the FIRST letter right?  HA!
> E.g., would the letter 'f' in the word 'file' be uppercased or not
> when it occurs within a composite word?  Take your pick...
> shelve.DbfilenameShelf, zipfile.BadZipfile, zipfile.ZipFile,
> mimify.HeaderFile, ...

You are exaggerating a bit. Yes, you are right in your complaints,
but in my experience I never had headaches due to case sensitivity. 
> 
> > Also, now I can write
> > 
> > ONE=1
> > 
> > and
> > 
> > def one(): return 1
> > 
> > and it is clear that the first name (ONE) refers to a constant
> > whereas the second name (one) refers to something which is not a constant.
> 
> Except that it is, unless your design intention (unlikely though
> possible) is that the user will rebind name 'one' in your module
> to indicate some other function object.  Unless such is your meaning,
> names 'one' and 'ONE' are "constants" in exactly the same sense: you
> do not intend those names to be re-bound to different objects.  One
> of the objects is callable, the other is not, but that's quite another
> issue.  One is technically immutable -- the other one isn't (you can
> set arbitrary attributes on it) but it IS hashable (the attributes
> don't enter into the hash(one) computation) which is more often than
> not the key issue we care about when discussing mutability. 

You are still exaggerating. 99% of times uppercase constants denote
numbers or strings. I don't remember having ever seen an all uppercase
function, even if I am sure you do ;)

> So,
> what IS "a constant" in Python?  If you wanted to bind a name (asking
> implicitly that it never be re-bound) to a "indisputably mutable" (not
> hashable) object, how would you capitalize that?  Python itself does
> not seem to care particularly.  E.g.:
> 
> >>> def f(): pass
>  ...
> >>> f.func_name = 'feep'
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: readonly attribute
> >>> f.func_defaults = ()
> 
> I can rebind f.func_defaults, NOT f.func_name -- but they have exactly
> the same capitalization.  So, no guidance here...

Yeah, having read-only attributes distinguished by some code convention
(underscores or capitalization) would be a possibility, but what if in
a future version of Python the read-only attribute becomes writable? I
am use you had this are argument in the back of you mind. Nevertheless,
notice that this is an argument against a too strict code convention,
not against case insensitivity.
 
> > In a case insensitive language I am sure I would risk to override
> > constants with functions. 
> 
> Why is that any more likely than 'overriding' (e.g.) types (in the old

oops again, I meant "shadowing" instead of 'overriding' but you understood

> convention which makes them lowercase) or "variables" (names _meant_
> to be re-bound, but not necessarily to functions)?  And if you ever use
> one-letter names, is G a class/type, or is it a constant?

I often use lowercase for constants, for instance in mathematical formulas:

a=1
b=2
y=a*x+b

Readability counts more than foolish consistency. Please, remember that
I am not advocating *enforcing* capitalization, even if I would welcome
a more consistent usage of capitalization in the standard library.
What I say is that case sensitivity is convenient, it gives me more 
indentifiers for free.

For instance, I can define a matrix type, overload "*" and write the
multiplication of a matrix "A" times a vector "a" as

b=A*a

Much more readable to me, that something like

b=a_matrix*a

or even

b=c*a # c is a matrix

Mathematical formulas are the first reason why I like case sensitivity.
 
> I consider the desire to draw all of these distinctions by lexical
> conventions quite close to the concepts of "hungarian notation", and
> exactly as misguided as those.

<horrified> Hungarian notation is an abomination you cannot put on 
the same foot with case sensitivity! </horrified>

> Much later I met the concept of "case _preservation_" --
> an identifier is to be spelled with the same case throughout, and
> using a different casing for it is either impossible or causes an
> error -- and THAT one is a concept I might well accept if tools did
> support it well (but I suspect it's more suitable for languages
> where there are declarations, or other ways to single out ONE
> spelling/capitalization of each identifier as the "canonical, mandated" 
> one -- I'm not sure how I'd apply that to Python, for example).
> As long as I could input, e.g., simplexmlrpcserver and have the
> editor (or whatever tool) change it to SimpleXMLRPCServer (or
> whatever other SpelLing they've chOseN) I wouldn't mind as much.

Case preservation is an interesting concept which would solve some
of my objections against case insensitivity, but not all of them. We would
need more letters! 

For example, Scheme and Lisp are case insensitive, but they are richer 
than Python in the character set of their identifiers: so they can 
distinguish a class from an instance writing something like "c" 
for the instance and "c*" or "c#" or "c-" etc. for the class. How would
you do that in Python? "c" for the class and "ac" for the instance? Not
readable at all, IMHO. And think again to mathematical formulae, they
would really suffer from case insensitivity.

> Perhaps it's exactly because the discussion is totally moot, that
> it keeps getting hot each time it's vented (wanna bet...?-).
> 

You won ;)

> Alex

Michele