Re: new syntax for wrapping (PEP 318)
Hello python-dev people: Just joined, intro below :) Barry Warsaw wrote:
I've rewritten some of my code to use both the [] and the 'as' syntax. Neither is ideal, primarily because the interesting information tends to get pushed way off to the right, where I think the eye is lazier because of the more ragged nature of "code right".
Putting the decorator between the def and the method name actually doesn't look so bad to me, e.g.:
def [classmethod] func(a, b, c):
but I think with a longer decorator list, it might be problematic. I think that one element decorator lists will be the most common use and in that case, I like this syntax because it almost reads like English.
I completely agree. This is the second-most elegant syntax, the most-elegant being: def classmethod func(a, b, c): Has this been completely rejected? The pep's argument is it becomes cluttered and obscure when the decorator is a function call: def synchronized(lock) classmethod func(a): Can we also require that decorators be identifiers only (no expressions allowed), forcing clean looking definitions? The above would be rewritten as: sync = synchronized(lock) def sync classmethod func(a): In fact sync would probably be reused throughout the class body. This keeps simple things simple, and complex things possible. In addition it encourages using few decorators, keeping the def line short. And did I mention no new keywords? The alternatives - using [], (), <> and/or expressions - only make it more cluttered, leaving the simple (and IMO most common) cases hard to read and write. They do provide power that is useful for specific domains, but unnecessary for general purpose programming. Which would be ok (since when is power a bad thing?) if it wasn't at the cost of readability. Cheers, Shalabh Chaturvedi PS: I am a software consultant and have been using Python for four years (which includes two years of full time development :-). Needless to say, it is my first choice for solving problems. Recently I have become more interested in development and promotion of Python.
On Thursday 26 February 2004 01:58 am, Shalabh Chaturvedi wrote:
Putting the decorator between the def and the method name actually doesn't look so bad to me, e.g.:
def [classmethod] func(a, b, c):
but I think with a longer decorator list, it might be problematic. I think that one element decorator lists will be the most common use and in that case, I like this syntax because it almost reads like English.
I completely agree. This is the second-most elegant syntax, the most-elegant being:
def classmethod func(a, b, c):
I also much prefer this syntax to any other suggested syntax. Perhaps it's because I'm used to C (or practically any other language with type declarations), which puts type declarations ("restraints") before the defined function rather than after.
Has this been completely rejected? The pep's argument is it becomes cluttered and obscure when the decorator is a function call:
def synchronized(lock) classmethod func(a):
Can we also require that decorators be identifiers only (no expressions allowed), forcing clean looking definitions?
This would be fine with me. I would sacrifice the slight inconvenience of having to write give something a name in order to have what I believe to be significantly more readable code (much like I do with lambdas: I sacrifice the convenience of having an unnamed function on one line of code in order to maintain readability).
sync = synchronized(lock) def sync classmethod func(a):
This is much more readable, IMO, than: def func(a) [synchronized(lock), classmethod]: Jeremy
On Thu, 2004-02-26 at 08:31, Jeremy Fincher wrote:
sync = synchronized(lock) def sync classmethod func(a):
This is much more readable, IMO, than:
def func(a) [synchronized(lock), classmethod]:
Odd - I feel the exact opposite. The first form looks like "def blah blah blah" to me - there's nothing obvious to say *what* is being defined. By contrast the second form clearly defines "func" and gives some extra information about it. The name and parameters are more important than the additional information, so they ought to come first. Mark Russell
Here's what C# does: [System.Xml.Serialization.XmlRootAttribute("bookstore", Namespace="", IsNullable=false)] public class bookstoreType { .... [System.Xml.Serialization.XmlElementAttribute("book")] public bookType[] book; } One thing to note is that C# allows the wrapping of attributes, not just functions and classes. In Python this could be accomplished if we used delimiters that didn't look like lists (e.g. <> or [! !]). C# distinguishes between bareword declarations like "public" and "int" and metadata attachments like XML serialization information. I feel like there is a similar distinction lurking in the Python world. "staticmethod" says that the thing _is_ a static method. It changes the calling convention for that function. Whereas a "public" or "ZopePublish" attribute is pure metadata. It doesn't change the way you call the function, just who can call it. We could combine the C# idea with the bareword idea like so: <synchronized(lock), ZopePublish, protected, SparkGrammar("x := y z"), win32com_return_type(int), win32com_public> def staticmethod x(): ... Statements cannot start with "<" so there is no ambiguity about the meaning of the character in this context. Paul Prescod
On Thu, 2004-02-26 at 03:31, Jeremy Fincher wrote:
efer this syntax to any other suggested syntax. Perhaps it's because I'm used to C (or practically any other language with type declarations), which puts type declarations ("restraints") before the defined function rather than after.
I think I still like the pre--function-name-bracket-bracketed-decorator syntax because of the English-like parsing combined with the visual (parenthetical) distinction. -Barry
On Thu, Feb 26, 2004, Barry Warsaw wrote:
On Thu, 2004-02-26 at 03:31, Jeremy Fincher wrote:
efer this syntax to any other suggested syntax. Perhaps it's because I'm used to C (or practically any other language with type declarations), which puts type declarations ("restraints") before the defined function rather than after.
I think I still like the pre--function-name-bracket-bracketed-decorator syntax because of the English-like parsing combined with the visual (parenthetical) distinction.
Eh? I can't parse that. ;-) -- 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
On Thu, 2004-02-26 at 09:40, Aahz wrote:
On Thu, Feb 26, 2004, Barry Warsaw wrote:
I think I still like the pre--function-name-bracket-bracketed-decorator syntax because of the English-like parsing combined with the visual (parenthetical) distinction.
Eh? I can't parse that. ;-)
:) def [classmethod] makeNewbie(a, b, c): pass -Barry
Shalabh Chaturvedi wrote:
...
sync = synchronized(lock) def sync classmethod func(a):
In fact sync would probably be reused throughout the class body.
In this case yes. But there are other usecases where it isn't as hot (pseudo Spark): grammar_rule = grammar("x := y z?") def grammar_rule func1(a): pass grammar_rule = grammar("y := y1 y2?") def grammar_rule func2(a): pass grammar_rule = grammar("z := z2? z1") def grammar_rule func3(a): pass But it isn't terrible. It just means you need to create meaningless temporaries. It also makes life a little harder for tools trying to read the code and figure out what is going on. This is an easy pattern to look for: def sync func(a)[synchronized(lock)]: For instance an IDE could make a tooltip wherever "func" is used to indicate that it is synchronized with a particular lock. That gets much harder if there are usually arbitrary amounts of Turing complete code between the function declaration and the decorator declaration. Another concern: It arguably HURTS readability if deciphering a function declaration requires scanning backwards looking for definitions like the one for "sync". I certainly see the strength of your proposal from a readability point of view. Paul Prescod
"Shalabh Chaturvedi" <shalabh@cafepy.com> writes:
I completely agree. This is the second-most elegant syntax, the most-elegant being:
def classmethod func(a, b, c):
Has this been completely rejected?
I think it would be pretty hard to implement, parsing wise. Also, I think it risks being NAME soup. Punctuation isn't in-and-of- itself a bad thing! Cheers, mwh -- : exploding like a turd Never had that happen to me, I have to admit. They do that often in your world? -- Eric The Read & Dave Brown, asr
participants (7)
-
Aahz -
Barry Warsaw -
Jeremy Fincher -
Mark Russell -
Michael Hudson -
Paul Prescod -
Shalabh Chaturvedi