Re: [Python-Dev] Re: new syntax for wrapping (PEP 318)
From: Greg Ewing
"Jewett, Jim J"
:
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
"Jewett, Jim J"
I would have assumed that I have to make a (possibly implicit) similar declaration about every function
Perhaps our brains work in different ways here, but I think I would be more likely to assume that, since the vast majority of Python function declarations I see have no such annotations, that it's something optional that's only rarely used. I take your point about having something to look up in the docs. In the case of the built-in decorators (classmethod, etc.) looking up the name of the decorator itself should provide an adequate starting point, if the docs are written properly. But that wouldn't help someone whose first introduction to decorators was by coming across a user-defined one. I still can't bring myself to like any of the keywords I've thought of or seen suggested. To serve the function of being up-lookable, it really needs to be a new keyword, specific to this use, rather than re-using a generic one like "as" or "is". But I can't think of one that doesn't put undue emphasis on the mechanism, which I don't think would be helpful to either newbies or experienced users. Newbies don't want to be swamped with getting their brains around all the subtleties of how it works, and experienced users don't want to have to think about it all the time. Moreover, the mechanism is so general, and can be used to achieve such a wide variety of effects, that the mechanism itself is really all they have in common. So I don't think its' going to be *possible* to find a single distinctive non-mechanism-related keyword that is truly apt for all its uses. By the way, there are already instances of syntax that people frequently find difficult to look up, such as the * and ** arguments. Maybe we could do with some kind of "explain" tool that you could feed a snippet of code to and it would provide manual references to all the syntactic features it contained? E.g. % pyexplain Welcome to the Python Syntax Explainer! What piece of code is puzzling you?
def marmalade(self, x) [classmethod]:
This is a Function Definition (see Python Language Reference section 7.5). The items enclosed in [...] are Function Decorators (see Python Language Reference section ?.?).
Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
On Tue, Feb 24, 2004, Greg Ewing wrote:
To serve the function of being up-lookable, it really needs to be a new keyword, specific to this use, rather than re-using a generic one like "as" or "is". But I can't think of one that doesn't put undue emphasis on the mechanism, which I don't think would be helpful to either newbies or experienced users. Newbies don't want to be swamped with getting their brains around all the subtleties of how it works, and experienced users don't want to have to think about it all the time.
By the way, there are already instances of syntax that people frequently find difficult to look up, such as the * and ** arguments. Maybe we could do with some kind of "explain" tool that you could feed a snippet of code to and it would provide manual references to all the syntactic features it contained?
What's really needed is a formal reference containing informal writing. IOW, someone looking up ``def`` ought to find the information zie needs, but more colloquially than is used in the Lang Reg. Making a start on that has been on my plate for many moons, but I've never gotten enough tuits.... -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Do not taunt happy fun for loops. Do not change lists you are looping over." --Remco Gerlich, comp.lang.python
participants (3)
-
Aahz
-
Greg Ewing
-
Jewett, Jim J