[Python-Dev] PEP 292: method names

[Brett C.]

Erik Heneryd wrote:
> Barry Warsaw wrote:
> 
>> On Sat, 2004-09-11 at 07:54, Erik Heneryd wrote:
>>
>>
>>> * Too long
>>> 10/15 character names for something so simple it up until now just 
>>> needed a %?  Programs using templates will probably use them 
>>> frequently...  I'd prefer sub instead of substitute.
>>
>>
>>
>> Noted, thanks.  In general I'm not a fan of abbreviations in APIs
>> though.  Also note that it is trivial for applications to derive and
>> override __mod__(), aliasing it to whichever version of substitute()
>> they want.  For example, I plan on multiply inheriting Template and
>> unicode, and aliasing __mod__() to safe_substitute().
> 
> 
> -1
> 
> Well, even if it's trivial, I still think the out-of-the-box API 
> shouldn't be hostile against frequent use.  Subclassing just to get a 
> decent name/operator feels stupid.  Why not __mod__ = safe_substitute 
> per default then?
> 

I'm with Barry on this.  Verbosity is going to overtake practicality here.  And 
I think this is a good thing the last thing the stdlib should start doing is 
trying to force people to use some shorthand that we come up with that won't 
necessarily be intuitive to other people ('sub' just doesn't seem right here; 
and don't ask for justification since this is a gut feeling).  I am sure the 
way I tend to abbreviate things is not how anyone else would.  So why would the 
stdlib try to?  We have tried to come up with good names and this is the best 
we came up with.

And as Barry said, you can add __mod__ to your own subclass.  And another 
option entirely is to just assign the method to a shorter name in your code.

And if you *really* want to argue the length thing, you can take into account 
that "substitute" has a decent amount of hand alternation on QWERTY to allow 
for pretty good typing speed.

-Brett