[Python-Dev] PEP 292: method names (original) (raw)

Brett C. bac at OCF.Berkeley.EDU
Mon Sep 13 19:41:08 CEST 2004

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 safesubstitute(). -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 = safesubstitute 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

More information about the Python-Dev mailing list