C
Colin J. Williams
J2 C1 C1
Colin W.
Paul McGuire wrote:
[snip]
Colin W.
Paul McGuire wrote:
[snip]
C1 C1 C1
If we are allowed to make negative votes:
-J2 -J2 -J2
I personally find J2 worse than the current pie
syntax. Something that looks odd and does something
odd seems the lesser evil vs something that looks
normal yet does something odd.
Doug said:I don't think so. C1 was the clear community favorite for months and
still has many supporters. And putting the decorator at the top of the
function had many supporters in the poll last week.
J2 is winning because it was actively discussed right here on this
newsgroup this past week. When I did a poll last week, E1 had just been
actively discussed and it gained a lot of support. Next week who knows
what will be the current flavor?
Another six months won't make much difference. The transform
functionality is there now. PEP 318 formalizes things.
Nicolas Fleury said:Proposal 1:
decorate: staticmethod
def foo(a, b):
...
decorate:
accepts(int,int)
returns(float)
def bar(low, high):
...
other possible keywords: predef, from, as, with
Proposal 2:
def foo(a,b):
using staticmethod
...
def bar(low, high):
using accepts(int, int)
using returns(float)
other possible keywords: decorate, transform, with, postdef, as
[snip]
What keywords would you prefer? Do you see any that I have not listed?
Do you think there's an alternative that I should have listed, even
considering what have been ruled out by Guido?
Paul Morrow said:There would be two kinds of decorators. Those that are simply
informative (like __author__ or __version__), and those that have
side-effects (like __metaclass__, __synchronized__, __automethods__,
etc.). Those with side-effects would be implemented as special functions...
def synchronized(func, trueOrFalse):
__decorator__ = True
__author__ = 'Billy Batson'
__version__ = '0.1'
#
# perform the synchronized operation on func...
#
Jess said:How would the parser know the difference between informative function
variables like "__author__" and your special side-affecting function
variables?
......Avner said:I believe putting the decorator list before the function header is
generally a bad design decision. While it may make parsing-related
sense, it violates Python's greatest asset: being executable pseudocode.
The way I see it, the latter quality means being able to look at the
code and see clearly and immediately what requirements from the real
world the code was written the serve. Functions and methods are major
Your expectation list makes sense to me. There is merit in having theAvner said:I believe putting the decorator list before the function header is
generally a bad design decision. While it may make parsing-related
sense, it violates Python's greatest asset: being executable pseudocode.
The way I see it, the latter quality means being able to look at the
code and see clearly and immediately what requirements from the real
world the code was written the serve. Functions and methods are major
code entities that are naturally expected to represent discrete
functional requirements from the code, to this or that level of detail.
I expect to learn from the method name, the class it is in and the list
of arguments it takes, everything I need to know about the functional
requirement it implements. If that is not enough, I will look at the
docstring, if present. Everything else the method has to offer is
conveniently hidden below. Decorators of the type discussed recently -
with the exception of staticmethod and classmethod - are technical
detail of the kind I would like to see hidden below. Putting them on
top, prior to the what the method does (its name etc.) compromises the
design quality of the code, reducing it to yet another
abbreviation-based, self-centered technical scripting language.
The one esception I saw was J2, which, although putting the decorators
before the proper method header, uses indentation to state "this is an
extra piece of technicality which you are free to ignore - the def is
below."
My vote: C2, E4, J2
Avner.
Your expectation list makes sense to me. There is merit in having theAvner said:I believe putting the decorator list before the function header is
generally a bad design decision. While it may make parsing-related
sense, it violates Python's greatest asset: being executable pseudocode.
The way I see it, the latter quality means being able to look at the
code and see clearly and immediately what requirements from the real
world the code was written the serve. Functions and methods are major
code entities that are naturally expected to represent discrete
functional requirements from the code, to this or that level of detail.
I expect to learn from the method name, the class it is in and the list
of arguments it takes, everything I need to know about the functional
requirement it implements. If that is not enough, I will look at the
docstring, if present. Everything else the method has to offer is
conveniently hidden below. Decorators of the type discussed recently -
with the exception of staticmethod and classmethod - are technical
detail of the kind I would like to see hidden below. Putting them on
top, prior to the what the method does (its name etc.) compromises the
design quality of the code, reducing it to yet another
abbreviation-based, self-centered technical scripting language.
The one esception I saw was J2, which, although putting the decorators
before the proper method header, uses indentation to state "this is an
extra piece of technicality which you are free to ignore - the def is
below."
My vote: C2, E4, J2
Avner.
Your expectation list makes sense to me. There is merit in having theAvner said:I believe putting the decorator list before the function header is
generally a bad design decision. While it may make parsing-related
sense, it violates Python's greatest asset: being executable pseudocode.
The way I see it, the latter quality means being able to look at the
code and see clearly and immediately what requirements from the real
world the code was written the serve. Functions and methods are major
code entities that are naturally expected to represent discrete
functional requirements from the code, to this or that level of detail.
I expect to learn from the method name, the class it is in and the list
of arguments it takes, everything I need to know about the functional
requirement it implements. If that is not enough, I will look at the
docstring, if present. Everything else the method has to offer is
conveniently hidden below. Decorators of the type discussed recently -
with the exception of staticmethod and classmethod - are technical
detail of the kind I would like to see hidden below. Putting them on
top, prior to the what the method does (its name etc.) compromises the
design quality of the code, reducing it to yet another
abbreviation-based, self-centered technical scripting language.
The one esception I saw was J2, which, although putting the decorators
before the proper method header, uses indentation to state "this is an
extra piece of technicality which you are free to ignore - the def is
below."
My vote: C2, E4, J2
Avner.
Your expectation list makes sense to me. There is merit in having the
docstring before the 'decorator', i.e. E4
Colin W.
Robin said:>[snip]
except that these wrappers/transformers/decorators are able to do what
they like to the code including turning methods into properties,
changing the argument list etc etc etc.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.