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

[Jewett, Jim J]

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() wrapped_by [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