Case sensitivity

[Martijn Faassen]

Alex Martelli <aleax at aleax.it> wrote:
> Martijn Faassen wrote:
> 
>> Alex Martelli <aleax at aleax.it> wrote:
>>> Martijn Faassen wrote:
>>>   ...
>>> 
>>>> fooBarism = FooBarism()
>>>> 
>>>> could be easily repaired, but is this *idiotic*? May be misguided, but
>>> 
>>> I apologize for being politically incorrect here in my choice of
>>> terms.  If you'll accept, say, three months with biweekly long
>>> distance phone meetings of one hour each where you have to discuss
>>> this subtle and elegant design,
>> 
>> It's not a subtle and elegant design. It's a straightforward
>> design. Luckily with straightforward designs, you don't have
>> to have three months with biweekly long distance phone meetings. That's
>> the point of straightforward designs.
> 
> Hard to say whether you missed the point, or are just breezing
> over it in the guise of humor, but, I'll play the straight man
> here, rather than risk the point being lost:

I had no clue what you were on about. I now realize you are worried
about having to pronounce these names frequently in repeated
phone conversations.

> 1. no matter how "straightforward" your module's design is, if that
> module is heavily used as a part of a large system on which many
> people work, there will be discussions in which the names that
> your module exposes will need to be mentioned;

Sure, though most modules are not heavily used in this way, even in large
systems on which many people work.

> 2. being able to pronounce names is good, when the names need to
> be discussed; having to spell out a name, or qualify "the big-f
> foobarism" vs "the small-f foobarism", each time you're talking
> about them, is a small but non-negligible bother, and reduces the
> group's productivity during each such discussion;

Agreed, some overhead.

> 3. voice is a frequently used medium to discuss code -- even between
> people who are face-to-face, but in this case it can sometimes
> more easily be supplemented by writing on paper or whiteboards,
> or point-and-grunt with a screen; on the phone, there are fewer
> practical aids.

I don't find myself doing that over the phone on that level of detail
very often (and yes, I work with developers scattered across several
countries). Email is more frequent. But yes, there would be some
overhead and this overhead exists even in face to face conversations.
I'm not sure how much it weighs in compared to the rest of the overhead
one has when speaking about code. One has to be really clear about
the Foo instance and the Foo class and perhaps the foo module anyway, 
for example..

> In other words, I was not proposing long boring discussions about
> the capitalization choice, but rather that you consider the
> possible need to discuss, by voice, aspects of your module's
> public interface that might differ only by capitalization.  And
> I suspect that, if one had first-hand experience of such needs,
> one would be perhaps less than charmed by "capitalization-only" 
> distinctions along such public interfaces.

I wasn't maintaining I was charmed by it; it's not like my modules export
this kind of thing commonly. I can't think of an instance; the Formulator
case I thought it happened in I actually did use a different name for
the instance as opposed to the class. But I'm pretty sure I must've
used this pattern at some point in fairly throwaway code.

In larger projects I tend to rely more and more on 
interfaces (Zope's model) as well as published standards. An interface
which exposes two method names with different capitalization I would
tend to consider broken, likewise a standard which did this. :)

Perhaps there was a mismatch in the scale in which we were thinking. I work on
both larger and smaller Python projects. For the smaller projects I tend
to be somewhat less worried about these matters than in the larger ones.
Of course if a small project grows larger I grow progressively more
worried and work on keeping things manageable.

Anyway, Python is not only a large scale programming language with
multinationally managed projects (though you'll find me use it as such
too), but also a quick scripting language. In the latter context I don't
think exposing some stuff differing by capitalization is a big deal. That
said, of course smaller projects often consist of only one or two
modules, so I'll just give up my argument now. :)

>> Though I'd be happy to rewrite it so either the instances or the
>> classes are named something else. :) I see in some code I wrote
>> where I thought I followed this pattern I actually called the instances
>> 'FooInstance' explicitly.
> 
> Oh good.  Then I don't see why you said in your previous post
> you'd MISS the feature -- as now you say that sometimes you
> choose more explicit distinctions anyway, and that you'd be
> happy to do that systematically.

Did I really say I'd miss that feature? What I'd miss is the local scope
feature, but you already described a way to solve that issue by simply
not worrying about that scope. Things like this:

class Foo:
   ...

def something():
   foo = Foo()

def somethingElse(foo):
   ...

for very simple 'script' modules where everything happens in the top level
namespaces as well as for the interactive prompt I'd miss the feature more,
but I can avoid such scripts easily by just adding a main function and 
indenting (and I do such anyway as it's good practice for a number of
reasons). The hardest thing would be the interactive mode, where to play
around one might do stuff like:

>>> from module import Foo
>>> foo = Foo()

and you wouldn't be allowed to do so anymore, unless this is treated as a
kind of local scope and not as top level.

> Assuming you've actually changed your mind (a rare event on
> Usenet), then maybe my pessimism about this thread was undue.

I was perhaps unclear in expressing what I would miss. For the top level
it sounds fine to raise a SyntaxError if a user does this. Though of course
with sufficient trickery a user could still make modules misbehave. :)

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?