[Python-Dev] Re: new syntax for wrapping (PEP 318) (original) (raw)

Jewett, Jim J jim.jewett at eds.com
Mon Feb 23 12:01:30 EST 2004

From: Greg Ewing <greg at cosc.canterbury.ac.nz>

"Jewett, Jim J" <jim.jewett at eds.com>:

With the current syntax, I think the cost is too high for the benefit. It might help to add a keyword, like

def foo() wrappedby [sugary, syntax, list]:

Some keyword might help, but I don't like that particular choice, as it draws too much attention to the mechanism,

I'm certainly not wedded to that specific word; how about "providing" "also_providing", "including", "extended_by", or "acting_as"? ("as" is better than nothing, but does suggest an alias more than a wrapper.)

I think it ought to be very readable without any keyword, provided the names of the wrapper functions are chosen appropriately.

By someone with similar background.

Can you honestly say that, as a Python newbie, if you had come across

def marmalade(self) [classmethod]: ...

you wouldn't have been able to guess the intent, if not the mechanism being used to achieve it?

The problem isn't that this function would be too mysterious; the problem is that it adds mystery to the rest of the language.

I would have assumed that I have to make a (possibly implicit) similar declaration about every function, and that the declarations come from a (hopefully) small set, such as {public, private, static, synchronized, final, abstract}

The fact that I would have to learn this set (and rules about which went together) would be a barrier to entry.
The fact that I couldn't quickly find the exhaustive list (since no such declaration is actually required) would make me nervous.

If I saw example code not using the [] declaration, I would assume that the defaults were mostly reasonable, but not always, and it would bother me that I couldn't find the information about when I needed to override it.

My newbieness is still recent enough that this objection isn't theoretical; "how long before I can spend more time coding than searching through the manual" and "how long before surprises -- even in other people's code -- are at least immediately recognizable instead of deep bugs" were among the main reasons to choose python over Perl or Ruby.

def marmalade(self) [classmethod]:

looks basic enough that I assume I have to understand it before I can write even a simple program - particularly since [] characters are pretty common in the rest of the language.

The huge difference between (legal) definitions

def marmalade(self): [classmethod]

and def marmalade(self) [classmethod]:

in a language that supposedly uses whitespace instead of syntax characters would make me assume that the language really does use all sorts of obsure syntax, but just hides it in ways that I can't easily recognize.

def marmalade(self) unusual_modifiers[x,y,z]:

at least tells me that this is an unusual case, and that [x, y, z] has its normal meaning, with any unexpected behavior attributable to the "unusual_modifiers" that calls/uses them.

In this case, there would be only one possible unusual modifier, and it would be listed in the appropriate part of the documentation, and it would then be clear that I didn't need to worry about it for most of my own programs.
(Note that "unusual_modifiers" doesn't even have to be self-documenting to get this benefit, so long as it is clearly optional and clearly not applicable to all definitions. "extended_format1" would already be useful.)

I also suspect that this won't be the last extension to definition syntax. Adding a keyword to describe the extension means that someone who doesn't often use that particular extension can still skim the code without a manual handy. Adding new anonymous syntax is already a bit confusing, and would be unworkable by the fourth or fifth extension.

-jJ

More information about the Python-Dev mailing list