PEP318

[Michael J. Fromberger]

Also, it's not in the Zen of Python, but maybe declarative is better
than imperative?

This one comment particularly caught my attention.

I generally agree with your above statement, but I don't think that this
alone really justifies the proposed "decorators" (leaving aside the fact
that they are still a moving target, semantically).

The basic idea behind PEP-318 wasn't too bad, in my opinion -- but I
think in discussion it's been overloaded with a lot of declaration work
that would be better off factored out over other parts of the language
(e.g., type declarations in the parameter list; method transformations
wherever the syntactic dust settles over PEP-318; documentary metadata
preferably left out of the syntax and parsed from comments or doc
strings).

To use the example of list comprehensions, I think we can agree that
declarative constructs have excellent potential. But this is Python,
not Perl, we don't need to make a Swiss Army knife out of this one piece
of syntax. I realize you're not proposing we do so -- but, "declarative
is better than imperative" could be taken too far by others.

-M

 

[Anthony Baxter]

Big f**king deal - all things considered.

When this name is a PyObjC name that might be 70 characters long,
it becomes a big deal.

 

[=?iso-8859-15?Q?Pierre-Fr=E9d=E9ric_Caillaud?=]

Proposal :

Make def an expression (always returns the function):

# this one behaves as usual
def funcname(params):
function body

# this one is new
# it allows us to name a function (func.__name__ ?) and also use it in
expressions
variable = def funcname(params):
function body

# or
variable = def (params):
function body

# or
return def funcname(params):
function body

Now we could write :
funcname = classmethod(
def funcname( params ):
body
)

But it looks lispish and introduces a lot of confusing parentheses...

Now, I propose (oops) a new operator, whatever name it has, which means
"the value of the expression on the next line of code". Let's say this is
a new use for "*" :

a = function1( x,*,z )
function2( f,g,h )

This would be translated by the compiler as

a = function1( x,function2( f,g,h ),z )

So we can have :

funcname = decorator1(*)
decorator2(*, other params)
def funcname( params ):
function body

What do you think ?

Yet another proposition :

execute:
funcname = classmethod( funcname )
after:
def funcname(params):
body

 

[Michael Hudson]

No @, hence tangential relevance to PEP318 (and a point against
pies, before or after the def). Unless you can remember it's on
option-3.

Huh? On *my* mac <wink> @ is shift-2 and # is option-3. And I live
with the latter, and I type it far more often than anyone is ever
going to type @ for decorators...

Now, if someone would like to fix \ in place for the purposes of
LaTeX, then you're really talking!

Cheers,
mwh

 

[Ronald Oussoren]

Huh? On *my* mac <wink> @ is shift-2 and # is option-3. And I live
with the latter, and I type it far more often than anyone is ever
going to type @ for decorators...

Now, if someone would like to fix \ in place for the purposes of
LaTeX, then you're really talking!

Use a real keyboard? On my powerbook @ is shift-2, # is shift-3 and \
is near return and left-shift

Ronald

 

[Sion Arrowsmith]

Huh? On *my* mac <wink> @ is shift-2 and # is option-3.

Er, sorry everyone, yes, I'm talking complete bollocks. Ignore me.

 

[Stefan Eischet]

Huh? On *my* mac <wink> @ is shift-2 and # is option-3. And I live
with the latter, and I type it far more often than anyone is ever
going to type @ for decorators...

My german iBook uses ALT-L for @, which by itself is not a very big
problem. But as an added bonus, the german PC keyboard puts @ at
ALTGR+Q (right alt key), which directly translates into APPLE-Q. You
know, like in "Quit".
Common exclamation: "I just want to type an email address. Where is the
program gone?!"
(This means that if I use my usual PC-worker's keypress to type @, it
should kill IDLE. Considering how I like the decorator syntax, this
might actually be a feature... ;-) )

// (e-mail address removed) //

 

[Donn Cave]

Quoth Michael Hudson <[email protected]>:
....
| Huh? On *my* mac <wink> @ is shift-2 and # is option-3.

What kind of keyboard has a key for <wink> @?

Donn Cave, (e-mail address removed)

 

[Arthur]

When this name is a PyObjC name that might be 70 characters long,
it becomes a big deal.

PyOdjC keeps being mentioned as the poster project for @decorator.

Isn't it fair to note that projects where the naming of functions is
outside the control of the developers are blue moon situations?

The kind of constraint that might be expected to lead to some extra
effort. Which the PyObjC developers seemed to be quite willing and
able to face with some equanimity, in the absence of a native
@decorator facility.

Just a debating point, or at least an effort to neutralize, a bit, a
statement that seems to be little more than a debating point.


Art

 

[Roman Suzi]

PyObjC keeps being mentioned as the poster project for @decorator.

Maybe its better idea to store decorators in resource fork


Sincerely yours, Roman Suzi

 

[Greg Ewing]

Quoth Michael Hudson <[email protected]>:
...
| Huh? On *my* mac <wink> @ is shift-2 and # is option-3.

What kind of keyboard has a key for <wink> @?

Aha! Folks have been calling it a "pie" here, but maybe
the @ in @decorator is secretly meant to represent a
wink? That would explain a lot...