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

[Tim Hochberg]

Alex Martelli wrote:
> Michele Simionato wrote:

[SNIP]

>>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
> 
> 
> Please note that here you are suddenly and undocumentedly _switching
> conventions on the fly_ regarding capitalization.  

Non issue, relatively speaking. Context makes this clear.

> One moment ago,
> leading cap had to mean "type" and all caps had to mean "numeric
> constant" (which in turn made a single-caracter capital identifier
> ambiguous already...) -- now suddenly neither of these conventions
> exists any more, since that uppercase A means 'matrix' instead of
> 'vector' (and a _number_, i.e. even lower dimensionality, would be
> indicated *HOW*?  

Number crunching with Python, by which I mean implementing big nasty 
formulas from obscure journals. It's a hard game all the way around. The 
problem is over constrained and making things case insensitive would 
just make things worse.

One would like to keep your formulas as close as possible to their 
sources. This helps both to get the formulate correct, but allows future 
readers of the code to be referred to the relevant journal and have some 
prospect of matching up code to article. This is impossible to do 
exactly of course since python doesn't support arrows and overbars, 
boldface and italic in identifiers. Using case sensitivity can help 
here, although it certainly doesn't solve all problems. The convention 
of capitalizing the matrices, lower-casing the vectors and writing out 
the scalars (see below) is often effective.

> Don't you EVER multiply your matrices by scalars?!

Scalars in my experience are frequently represented using Greek 
characters, so they get written out and are therefore easy to 
distinguish. They also tend to represent only a small portion of the 
typical equation, so that fact that they are written out doesn't have 
that large an effect. When the scalars are not represented using Greek, 
you just do the best you can.

> Or is it so crucial to distinguish matrices from vectors but totally
> irrelevant to distinguish either from scalars?!).

Just because it's difficult to represent formulas well using ASCII is 
not reason to make it more difficult, nor to throw up our hands and not 
try to represent them as best we can.

>>b=a_matrix*a
>>
>>or even
>>
>>b=c*a # c is a matrix
>>
>>Mathematical formulas are the first reason why I like case sensitivity.
> 
> 
> My opinion is that, while _habit_ in mathematical formulas may surely
> make one hanker for such case-sensitivity, the preference just does not
> stand up to critical analysis, as above.  

In theory, there is no difference between theory and practice. In 
practice.... I've tried many ways over the years to represent equations 
legibly using Python and my experience that case sensitivity, while 
certainly no panacea, helps.


> You're trying to overload WAY
> too many different and conflicting "conventions" onto a meager "one bit
> [at most] per character" (about 0.87 bits I believe, in fact) of
> "supplementary information" yielded by case-sensitivity.

I believe it's much closer to 1 full bit for length-1 sequences since 
numbers cannot start an identifier, decreasing relatively quickly to 
0.87 (I'll take your word for the 0.87 being the asymptotic value.)

[SNIP]

> Most paladins of case sensitivity would probably be horrified to see
> that the main point in its "favour" now appears to be that it
> encourages you to use shorter (e.g. 1-letter) identifiers (and thus
> more cryptic ones) because it gives you more of them to choose from...!!!

I find this argument silly. I have all the freedom I need to make my 
code illegible by using short identifiers without exploiting case. I'm 
certain I could rewrite all my code to use two letter lowercase 
identifiers and the lack of mixed case certainly wouldn't make it any 
clearer.

> I disagree -- once you have to spell out e.g. pi, capital-sigma, etc,
> in Ascii letters anyway, having to make sure you do so in letters that
> are unambiguous in terms of capitalization differences is no big loss.

Interestingly all of the math typesetting programs I've seen, including 
LaTex and MathML us Sigma (or SIGMA) and sigma for upper and lower case
sigma respectively. None write it out.

[SNIP]


In the end, this is a tools issue. If people spent half the time working 
on their favorite editor as discussing case-sensitivity, the problem 
would be long solved. SciTe comes pretty close with its auto completion 
stuff, but it doesn't order the completions appropriately. The correct 
order would be to ignore both captitalization and underscores. Or, 
perhaps, just non-leading underscores. I once fixed one of wxPython IDEs 
to do this mostly right, but sadly I've forgotten which one. I suppose 
it's time to dig into SciTe, but it's unfortunately not in Python.

Which brings me to something I can't understand about the great 
capitalization debate. Why is 'runmethod' versus 'runMethod' confusing, 
while 'runmethod' vs 'run_method' is not? To do a full job I'd think 
you'd have to  axe underscores as well. Far better to just improve the 
tools.

-tim