PEP 318 - PyFIT comments

[John Roth]

Decorator syntax seems to have been checked into 2.4b2.
I'm not going to comment on the syntax other than to say
that, when there isn't a real obvious syntax, someone has
to make a decision, and this one should work.

I was originally against it, on the basis that the only
use cases I saw were the elimination of the staticmethod()
and classmethod() builtin functions. I've used them, and
they're not ideal, but something like decorators for that
one use case seems to be going after a fly with a
howitzer.

Andrew Kuchling's comments here:
http://www.amk.ca/diary/archives/cat_python.html#003255
and especially the comments he quotes from Jim Hugunin
got me to thinking again about it. I can't quite see what
Thomas Heller is getting at with ctypes, though.

My current interest is in PyFIT. It's a Python
port of Ward Cunningham's FIT acceptance
testing program (fit.c2.com). I had to add a general
metadata mechanism to it to make it work cleanly
(the original port by Simon Michael tried to use
RExec, which obviously no longer works as well
as having major ambiguity problems.) There's an
early release in the download section at

http://www.xprogramming.com/software.htm

The current releases are in the files section of the
Extremeprogramming and the Fitnesse Yahoo mailing
lists.

When I looked at the metadata problem, I really
wanted a mechanism that would allow me to attach
metadata to any object in the class object. I can
do that to function objects, but I also need to do
it to properties and more general objects (such
as strings and integers.)

This doesn't, unfortunately, allow me to do that.

John Roth

[Ville Vainio]

>>>>> "John" == John Roth <ne********@jhrothjr.com> writes:

John> Decorator syntax seems to have been checked into 2.4b2. I'm
John> not going to comment on the syntax other than to say that,
John> when there isn't a real obvious syntax, someone has to make
John> a decision, and this one should work.

Yes, it should work. It's also a terrible waste of @ punctuation,
which should IMO be reserved for some more worthwhile purpose. I was
eagerly waiting for the introduction of decorators (and worried that
the proposed syntaxes would cause the feature to be thrown out), but
this choice of syntax leaves a bad taste in my mouth, and makes me
want to see the intro of decorators to be postponed or scrapped
altogether.

This syntax is out there with backticks and print>>. And I'm one of
those who voted *for* ternary operator, and generally embrace new
features with enthusiasm.

--
Ville Vainio http://tinyurl.com/2prnb

[Michael Ekstrand]

On Wednesday 04 August 2004 14:11, Ville Vainio wrote:

Yes, it should work. It's also a terrible waste of @ punctuation,
which should IMO be reserved for some more worthwhile purpose.

I'd concur with that... I saw the decorator syntax and thought "what is
this thing? and why is it in Python?"

When I read about decorators in the What's New guide, the first syntax
that jumped to my mind was:

def(staticmethod) somemethod(self, args):
some code

This was before reading the PEP or seeing any other recommendations for
syntax (except the nested-block syntax mentioned in another thread,
which I don't like either; it seems to not fit the nature of
decorations very well).

-Michael

[Nick Vargish]

Ville Vainio <vi***@spammers.com> writes:

This syntax is out there with backticks and print>>.

I agree.

I just don't know where else to voice my opinion on this matter, but I
absolutely hate the new decorator syntax. Sorry, I just had to get
that off my chest.

Nick

--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?')

[Christopher T King]

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 then we'd
have an easier and more organized way to give the BDFL some 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.

[Ronald Oussoren]

On 4-aug-04, at 21:35, Nick Vargish wrote:

Ville Vainio <vi***@spammers.com> writes:

This syntax is out there with backticks and print>>.

I agree.

I just don't know where else to voice my opinion on this matter, but I
absolutely hate the new decorator syntax. Sorry, I just had to get
that off my chest.

Why do you dislike it?

Ronald

[David Fraser]

Ronald Oussoren wrote:

On 4-aug-04, at 21:35, Nick Vargish wrote:

Ville Vainio <vi***@spammers.com> writes:

This syntax is out there with backticks and print>>.

I agree.

I just don't know where else to voice my opinion on this matter, but I
absolutely hate the new decorator syntax. Sorry, I just had to get
that off my chest.

Why do you dislike it?

Ronald

I think for the same reason as me!

I dislike it because it introduces a new punctuation character as an
operator for a relatively esoteric task. At least using a keyword
instead of @ would be a good idea.

Readability counts.

David

[Nick Vargish]

Ronald Oussoren <ro************@mac.com> writes:

Why do you dislike it?

It has a negative impact on readability.

It's ugly.

It modifies a declaration outside the declaration.

It feels unpythonic.

Of course these are subjective responses, and my weighting of the
importance of these complaints may not match yours. From the comments
in this newsgroup, I don't have the feeling that I'm alone in some or
all of these criticisms.

Nick

--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?')