Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > RE: Decorator syntax (was Re: PEP 318 - PyFIT comments)

Reply
Thread Tools

RE: Decorator syntax (was Re: PEP 318 - PyFIT comments)

 
 
Delaney, Timothy C (Timothy)
Guest
Posts: n/a
 
      08-04-2004
Christopher T King wrote:

> On 4 Aug 2004, Nick Vargish wrote:
>
>> I just don't know where else to voice my opinion on this matter, but
>> I absolutely hate the new decorator syntax.

>
> I wish PEPs had a method through which votes could be cast, for or
> against the PEP (or parts of it), not unlike Bugzilla bugs. At least


The last vote was an unmitigated disaster. And there appears to be no
more agreement on the correct syntax for decorators. The difference is
that decorator syntax will have significant benefits for a certain class
of project.

> democratic input. Either way, I really wish he would hold off on
> decorators until there's a consensus on them, rather than forcing
> them in amidst all the disagreements surrounding them.


There are significant projects that will greatly benefit from decorator
syntax - for example, PyObjC.

Personally, I don't overly like the new syntax - I much preferred def
func (args) [decorators] - and I would have preferred not to "waste" @
for them, but I can definitely live with the decision. Some usable
decorator syntax is IMO more important than none.

Besides, @ could possibly be reused for function attributes, meaning
it's less "wasted" - there's also an obvious correlation in that both
decorators and function attributes operate on the function object:

@classmethod
def func (args):
@attr = 1
pass

Tim Delaney
 
Reply With Quote
 
 
 
 
David Eppstein
Guest
Posts: n/a
 
      08-04-2004
In article <(E-Mail Removed)>,
"Delaney, Timothy C (Timothy)" <(E-Mail Removed)> wrote:

> Besides, @ could possibly be reused for function attributes, meaning
> it's less "wasted" - there's also an obvious correlation in that both
> decorators and function attributes operate on the function object:
>
> @classmethod
> def func (args):
> @attr = 1
> pass
>
> Tim Delaney


Hey, an actual reason for the restricted syntax in the current decorator
implementation: it makes it less likely that @decorators will conflict
with potential other @syntaxes such as this @attribute one.

--
David Eppstein
Computer Science Dept., Univ. of California, Irvine
http://www.ics.uci.edu/~eppstein/
 
Reply With Quote
 
 
 
 
Michael Ressler
Guest
Posts: n/a
 
      08-04-2004
On 2004-08-04, Delaney, Timothy C (Timothy) <(E-Mail Removed)> wrote:
> Christopher T King wrote:
>
>> On 4 Aug 2004, Nick Vargish wrote:
>>
>>> I just don't know where else to voice my opinion on this matter, but
>>> I absolutely hate the new decorator syntax.

>
> @classmethod
> def func (args):
> @attr = 1
> pass


I'm just a dumb user of Python - I don't even program for a living, so
there is no reason any of you should listen to me, but this @-syntax
thing makes Python look like Perl. The reason I learned Python was that
Perl looks like line noise to me, and I wanted a scripting language I
could read. Please don't wreck a beautiful, readable language with this
shortcut. Choose a word for it, not a symbol, please.

Mike
 
Reply With Quote
 
Bruce Eckel
Guest
Posts: n/a
 
      08-05-2004
I'll weigh in a little on this one.

This is very similar to attributes/metadata in Java J2SE 5 and in C#.
The thing is, metadata is a little bit weird; it's intentionally
outside of the domain of the 'normal' programming language, because it
expresses things that you can't or shouldn't within the normal
programming language. So you _do_ need an escape mechanism. And it
also takes a little bit of getting used to; it's orthogonal to what
you normally think of as a language feature. But the potential for
metadata features, at least in Java, is very powerful.

I suspect that the influence comes from Java, where they are also
using '@' (I don't recall what C# uses but it's very possibly also
'@'), and this was, I believe, one of the last things put into J2SE
1.5, so (guessing again) I suspect that's why it showed up so late in
Python -- the last thing I saw presented was attributes inside square
braces, and the only question was where they should go.

You can certainly argue that I'm more comfortable with it because I'm
already familiar with and used to the '@' syntax and actually think it
may be an improvement over [] because it may be more flexible -- at
least it is in Java.

I understand that many are uncomfortable with this feature and idea
and syntax, but I think we'll find it has compelling value, and the
fact that it is in both Java and C# (actually, it was invented for C#
by Anders, I believe, and Java is catching up), and that it fills a
need in Java that people were inventing comment syntax for, makes it
worth considering.

Bruce Eckel


 
Reply With Quote
 
John Roth
Guest
Posts: n/a
 
      08-05-2004

"Bruce Eckel" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I'll weigh in a little on this one.
>
> This is very similar to attributes/metadata in Java J2SE 5 and in C#.
> The thing is, metadata is a little bit weird; it's intentionally
> outside of the domain of the 'normal' programming language, because it
> expresses things that you can't or shouldn't within the normal
> programming language. So you _do_ need an escape mechanism. And it
> also takes a little bit of getting used to; it's orthogonal to what
> you normally think of as a language feature. But the potential for
> metadata features, at least in Java, is very powerful.


I'd be a lot happier if it was, in fact, a general metadata
facility. Unfortunately, it only seems to work on functions
(methods), and for what I'm working on I need metadata
for properties and fields as well, that is, any identifier that you can
bind an object to.

That's not to say I can't use it for something. It looks like
it might be very useful if I ever get around to writing an
interactive fiction system in Python. It solves one significant
problem in such a system - how to put a method into an
instance cleanly.

John Roth
>
> Bruce Eckel
>
>



 
Reply With Quote
 
Istvan Albert
Guest
Posts: n/a
 
      08-05-2004
Bruce Eckel wrote:

> This is very similar to attributes/metadata in Java J2SE 5 and in C#.
> The thing is, metadata is a little bit weird; it's intentionally
> outside of the domain of the 'normal' programming language, because it
> expresses things that you can't or shouldn't within the normal
> programming language. So you _do_ need an escape mechanism.


But the escape mechanism does not have to take the shape of
funny, loaded symbols.

Are these really necessary? Aren't they a just premature
solution (shortcuts) to a problem that may not even exist?
I am most irritated by the requirement of spreading out a function
definition over two lines.

> also takes a little bit of getting used to; it's orthogonal to what
> you normally think of as a language feature. But the potential for
> metadata features, at least in Java, is very powerful.


I always felt that Java was too rigid and that any kind
of loosening feels like a breath of fresh air. That is much less the
case in Python. If anything people sometimes want a little
more "discipline". This is what this PEP was initially about.
Too bad that instead of quickly settling at something really
simple like:

def static foo():
...

the urge to solve all future problems in the most generic manner
possible lead to increasingly hairy syntaxes and made
the decision process so prolonged, fruitless and boring
that GvR just got fed up with everybody.

Istvan.

 
Reply With Quote
 
Michael Hudson
Guest
Posts: n/a
 
      08-05-2004
"John Roth" <(E-Mail Removed)> writes:

> "Bruce Eckel" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > I'll weigh in a little on this one.
> >
> > This is very similar to attributes/metadata in Java J2SE 5 and in C#.
> > The thing is, metadata is a little bit weird; it's intentionally
> > outside of the domain of the 'normal' programming language, because it
> > expresses things that you can't or shouldn't within the normal
> > programming language.


Except, of course, this is Python so there isn't any such thing as
metadata, really. Objects all the way down.

> > So you _do_ need an escape mechanism. And it also takes a little
> > bit of getting used to; it's orthogonal to what you normally think
> > of as a language feature. But the potential for metadata features,
> > at least in Java, is very powerful.

>
> I'd be a lot happier if it was, in fact, a general metadata
> facility. Unfortunately, it only seems to work on functions
> (methods), and for what I'm working on I need metadata for
> properties and fields as well, that is, any identifier that you can
> bind an object to.


Well, that would be because that's impossible Where would you
attach the data in:

class C(object):
@funky
i = 0

?

You can't attach it to 'i' -- that's just a string. '0' is just an
integer. The class doesn't exist at the time the body is executed.

What you can do (today) of course is stuff like:

class C(object):
i = MagicProperty(int, default=0)

or something -- which obviously leaves ample space for metadata in the
argument list -- but that can be painful, I grant.

What kind of metadata do you want?

(I have to admit I read your first post on this thread a bit like
"this hammer doesn't do a very good job of screwing in screws"

Cheers,
mwh

--
It is time-consuming to produce high-quality software. However,
that should not alone be a reason to give up the high standards
of Python development. -- Martin von Loewis, python-dev
 
Reply With Quote
 
John Roth
Guest
Posts: n/a
 
      08-05-2004

"Michael Hudson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "John Roth" <(E-Mail Removed)> writes:
>
> > "Bruce Eckel" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > I'll weigh in a little on this one.
> > >
> > > This is very similar to attributes/metadata in Java J2SE 5 and in C#.
> > > The thing is, metadata is a little bit weird; it's intentionally
> > > outside of the domain of the 'normal' programming language, because it
> > > expresses things that you can't or shouldn't within the normal
> > > programming language.

>
> Except, of course, this is Python so there isn't any such thing as
> metadata, really. Objects all the way down.
>
> > > So you _do_ need an escape mechanism. And it also takes a little
> > > bit of getting used to; it's orthogonal to what you normally think
> > > of as a language feature. But the potential for metadata features,
> > > at least in Java, is very powerful.

> >
> > I'd be a lot happier if it was, in fact, a general metadata
> > facility. Unfortunately, it only seems to work on functions
> > (methods), and for what I'm working on I need metadata for
> > properties and fields as well, that is, any identifier that you can
> > bind an object to.

>
> Well, that would be because that's impossible


I wish you'd have told me that before I did it. As I said in
a prior post, I had to put a general metadata facility into
PyFIT, and it's working quite nicely, thank you.

What I did was put a dictionary with a known name (_typeDict)
into the class, and stick the metadata in there. It's nowhere near
as convenient as being able to directly associate it with the
needed bindings, but it does serve my needs in that particular
package.

> Where would you
> attach the data in:
>
> class C(object):
> @funky
> i = 0
>
> ?
>
> You can't attach it to 'i' -- that's just a string. '0' is just an
> integer. The class doesn't exist at the time the body is executed.


Two of which are exactly the points I mentioned. The third
is piffle. If the implementer wanted to do it, there is no reason
why it couldn't be done.

>
> What you can do (today) of course is stuff like:
>
> class C(object):
> i = MagicProperty(int, default=0)
>
> or something -- which obviously leaves ample space for metadata in the
> argument list -- but that can be painful, I grant.
>
> What kind of metadata do you want?


Type and other declaration information for any identifiers
that will be referenced in the FIT tests. Other information
includes things like precision for floating point numbers,
strings that are accepted as "true" or "false" for booleans,
the subtype for lists and tuples, references to custom
type adapters and other stuff.

> (I have to admit I read your first post on this thread a bit like
> "this hammer doesn't do a very good job of screwing in screws"


Well, that's basically what it said, after all. I was trying to find
something I could use the facility for. I can always dream up
ways someone else could use it, but I've found out after long
and painful experiance that if I'm not the developer in question,
at best it's a futile exercise.

That was basically my comment about ctypes. AMK's
blog entry referenced the ctype's documentation page,
which didn't tell me anything about what Thomas Heller
would do with it in the context of that package, and I'm
not enough of an expert on ctypes to see it myself.

John Roth
>
> Cheers,
> mwh
>
> --
> It is time-consuming to produce high-quality software. However,
> that should not alone be a reason to give up the high standards
> of Python development. -- Martin von Loewis, python-dev



 
Reply With Quote
 
A.M. Kuchling
Guest
Posts: n/a
 
      08-05-2004
On Thu, 5 Aug 2004 09:06:01 -0400,
John Roth <(E-Mail Removed)> wrote:
> That was basically my comment about ctypes. AMK's
> blog entry referenced the ctype's documentation page,


Heller's post (at
http://mail.python.org/pipermail/pyt...ne/045139.html) wasn't
very informative, either; I assume ctypes needs to do 'func =
something_or_other(func)' as PyObjC does currently.

--amk
 
Reply With Quote
 
Michele Simionato
Guest
Posts: n/a
 
      08-05-2004
"Delaney, Timothy C (Timothy)" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> Personally, I don't overly like the new syntax - I much preferred def
> func (args) [decorators] - and I would have preferred not to "waste" @
> for them, but I can definitely live with the decision. Some usable
> decorator syntax is IMO more important than none.


This also my opinion, more or less. It is just the "@" which is ugly.
Why not to overload (once more) the colon and write:

:classmethod
def func (cls, *args, **kw):
pass

? Only half serious ...


Michele Simionato
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
pep-318 questions Hallvard B Furuseth Python 3 08-28-2004 04:42 PM
PEP 318 decorators are not Decorators Arien Malec Python 11 08-16-2004 06:38 PM
PEP-318, billion-and-first syntax proposal Tim Hochberg Python 0 08-10-2004 07:38 PM
Confused about pep 318 Edward K. Ream Python 45 08-06-2004 10:41 PM
PEP 318 - PyFIT comments John Roth Python 7 08-06-2004 02:04 PM



Advertisments