Mailing List Archive: Python: Python

Decorators: an outsider's perspective

1 2

View All

Index | Next | Previous | View Threaded

cemerick at snowtide

Aug 13, 2004, 10:05 PM

Post #1 of 35 (1056 views)
Permalink

Decorators: an outsider's perspective

I thought I'd finally break my lurker status here by passing along a
comment I made in connection with this weblog post
<http://zephyrfalcon.org/weblog2/arch_e10_00610.html#e610>, one of many
deriding the controversial feature of @decorators. Feel free to flame
away, especially if the regulars here think I'm beating a dead horse
:-):

By no means am I an expert in Python (I get paid for writing Java,
although my hobby projects have been in Lisp over the past few years),
but this @decorator flap has made no sense to me at all.

The best argument against the new syntax is that it will impede noobs
(like myself, I suppose) from picking up the language. I think nothing
could be further from the truth, for one reason: action-at-a-distance
is *always* bad.

The first time I saw this, I almost fell out of my chair:

def blah (args):
....[insert 50/100/200 lines here]
blah = staticmethod(blah)

That's BAD. That, my friends, is tough to wrap one's mind around, for
the exact reason that, unless one reads through an entire module, the
critical staticmethod call might not even be seen. That's a pretty
devestating blow to the ability of a noob (or hell, anyone for that
matter) to learn what's going on in some code.

So, when I see:

@staticmethod
def blah (args):
....[insert 100 lines]

I say, YES! Sure, decorators can get complicated, as exemplified by
some of the examples provided in the post. However, just because
something is complicated, or even not the greatest approach in some
cases, doesn't invalidate it. Take recursion: a concept and practice
that noobs trip over almost as a rule, and an approach that is
constantly abused and overused in inappropriate situations. However,
that surely doesn't mean that recursion should be disallowed, or
scorned even. It means it should be respected, taught well, and used
when appropriate. Decorators surely fall into the same category.

Regards,

Chas Emerick

--
http://mail.python.org/mailman/listinfo/python-list

pm_mon at yahoo

Aug 14, 2004, 6:35 AM

Post #2 of 35 (1025 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

Chas Emerick wrote:

[...snip...]
>
> The first time I saw this, I almost fell out of my chair:
>
> def blah (args):
> ....[insert 50/100/200 lines here]
> blah = staticmethod(blah)
>

me too.

[...snip...]
>
> So, when I see:
>
> @staticmethod
> def blah (args):
> ....[insert 100 lines]
>
> I say, YES!
[...snip...]

I say, NO! And I wonder why we feel a need to explicitly (and
superflously) 'declare' something that is already clearly evident in the
code (when recommended coding practices are followed).

class Foo:
def blah(a, b): # this is clearly a static method
pass

def blah(self, a, b): # this is clearly an instance method
pass

def blah(klass, a, b): # this is clearly a class method
pass

Python was built (successfully) on the assumption that obvious
interpretations of the code obviate the need for declarations. Why
wouldn't we continue with that mindset?

Paul

--
http://mail.python.org/mailman/listinfo/python-list

chris.cavalaria at free

Aug 14, 2004, 6:48 AM

Post #3 of 35 (1024 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

Paul Morrow wrote:

> Chas Emerick wrote:
>
> [...snip...]
>>
>> The first time I saw this, I almost fell out of my chair:
>>
>> def blah (args):
>> ....[insert 50/100/200 lines here]
>> blah = staticmethod(blah)
>>
>
> me too.
>
> [...snip...]
>>
>> So, when I see:
>>
>> @staticmethod
>> def blah (args):
>> ....[insert 100 lines]
>>
>> I say, YES!
> [...snip...]
>
> I say, NO! And I wonder why we feel a need to explicitly (and
> superflously) 'declare' something that is already clearly evident in the
> code (when recommended coding practices are followed).
>
> class Foo:
> def blah(a, b): # this is clearly a static method
> pass
>
> def blah(self, a, b): # this is clearly an instance method
> pass
>
> def blah(klass, a, b): # this is clearly a class method
> pass
>
> Python was built (successfully) on the assumption that obvious
> interpretations of the code obviate the need for declarations. Why
> wouldn't we continue with that mindset?
>
> Paul

That remark is orthogonal to the problem at hand. staticmethod isn't the
only use for decorators although it's currently the most common example.
You are guilty of attacking the specific example instead of the general
idea behind it.

Of course, it doesn't mean that I don't like your idea. In fact, it find it
elegant except the the "klass" word which is ugly.

--
http://mail.python.org/mailman/listinfo/python-list

pm_mon at yahoo

Aug 14, 2004, 7:21 AM

Post #4 of 35 (1023 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

Christophe Cavalaria wrote:

> You are guilty of attacking the specific example instead of the general
> idea behind it.
>

Yes, sorry, but I'm in a pickle here. I want (we need) the general idea
of decorators --- the realm of problems that decorators try to solve ---
to be made smaller. They should not be used to declare a method's type
(static|instance|class). Decorators may have some valid purpose, but
this is not one of them.

> Of course, it doesn't mean that I don't like your idea. In fact, it find it
> elegant except the the "klass" word which is ugly.
>

Thanks, but it's not my idea (well, a tiny part maybe). The idea of
inferring a method's type from the name of its first formal parameter
was suggested by Stefan Eischet in another thread.

--
http://mail.python.org/mailman/listinfo/python-list

hans at zephyrfalcon

Aug 14, 2004, 10:57 AM

Post #5 of 35 (1043 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

Chas Emerick wrote:
> I thought I'd finally break my lurker status here by passing along a
> comment I made in connection with this weblog post
> <http://zephyrfalcon.org/weblog2/arch_e10_00610.html#e610>, one of many
> deriding the controversial feature of @decorators.

This post wasn't deriding decorators; rather, it explains them, and provides
some examples of how to use them. I do question their usefulness, but I'm not
deriding them, nor the "@" syntax.

--
Hans Nowak (hans [at] zephyrfalcon)
http://zephyrfalcon.org/

--
http://mail.python.org/mailman/listinfo/python-list

eurleif at ecritters

Aug 14, 2004, 1:58 PM

Post #6 of 35 (1026 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

Paul Morrow wrote:
> <says that classmethods should be done based on argument names>
> Python was built (successfully) on the assumption that obvious
> interpretations of the code obviate the need for declarations. Why
> wouldn't we continue with that mindset?

One of the principles of Python is also "explicit is better than
implicit". Your idea, though interesting, doesn't really seem to fit in
with that.
--
http://mail.python.org/mailman/listinfo/python-list

pm_mon at yahoo

Aug 14, 2004, 2:56 PM

Post #7 of 35 (1023 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

Leif K-Brooks wrote:

> Paul Morrow wrote:
>
>> <says that classmethods should be done based on argument names>
>> Python was built (successfully) on the assumption that obvious
>> interpretations of the code obviate the need for declarations. Why
>> wouldn't we continue with that mindset?
>
>
> One of the principles of Python is also "explicit is better than
> implicit". Your idea, though interesting, doesn't really seem to fit in
> with that.

I'm really not sure that those 'Zen' items were intended to be absolute
guiding principles. For example, we don't (explicitly) declare
variables. And I think that the way we indicate blocks of code (via
indentation) has a somewhat implicit flavor to it as well (it might be
arguably more explicit if we used curly braces or some such).

I think that a more appropriate principle here would be something like
'clear is better than ambiguous'. Ideally, any given Python statement
should have only one interpretation, shared by the Python system, the
statement author, and anyone else who might someday read the statement.
Unfortunately, because we have recommended practices that are widely
used yet *not enforced by the Python system*, code that strays from the
recommended style can confuse --- or even worse, mislead --- the reader.

For example, if an experienced Python developer was reading someone's
code and saw the following method...

class Foo:
def setX(self, x):
self.x = x

... I doubt that they would consider the possibility that setX might be
something other than an instance method of class Foo. Instead, I
believe that they would most likely *assume* that the author followed
the recommended coding conventions.

But setX could be a static method or a class method, if the class later
declared it as such. That's wonderfully flexible I know. But I think
that we'd all be better off if we didn't have that particular freedom.

--
http://mail.python.org/mailman/listinfo/python-list

porky_pig_jr at my-deja

Aug 14, 2004, 3:04 PM

Post #8 of 35 (1023 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

Paul Morrow <pm_mon [at] yahoo> wrote in message > class Foo:
> def blah(a, b): # this is clearly a static method
> pass
>
> def blah(self, a, b): # this is clearly an instance method
> pass
>
> def blah(klass, a, b): # this is clearly a class method
> pass
>
> Python was built (successfully) on the assumption that obvious
> interpretations of the code obviate the need for declarations. Why
> wouldn't we continue with that mindset?
>
> Paul

I don't think it's a good example. 'self' is a convention, not the
reserved word. Nothing can prevent anyone from using some other word.
Strictly speaking, the fact that the first parameter is called 'self'
does not imply anything. Ditto for 'klass' (or rather 'cls' which is
used by the number of references). Again, it's not a reserved word.
What if I've decided to use parameter name 'cls' in static function?
What if I've decided to use 'this' instead of 'self'? So - either we
need some mechanism to enforce the keywords 'self', 'cls', or -- we
back to square one: we need decorators.
--
http://mail.python.org/mailman/listinfo/python-list

pm_mon at yahoo

Aug 14, 2004, 3:16 PM

Post #9 of 35 (1027 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

Porky Pig Jr wrote:
> Paul Morrow <pm_mon [at] yahoo> wrote in message > class Foo:
>
>> def blah(a, b): # this is clearly a static method
>> pass
>>
>> def blah(self, a, b): # this is clearly an instance method
>> pass
>>
>> def blah(klass, a, b): # this is clearly a class method
>> pass
>>
>>Python was built (successfully) on the assumption that obvious
>>interpretations of the code obviate the need for declarations. Why
>>wouldn't we continue with that mindset?
>>
>>Paul
>
>
> I don't think it's a good example. 'self' is a convention, not the
> reserved word. Nothing can prevent anyone from using some other word.
> Strictly speaking, the fact that the first parameter is called 'self'
> does not imply anything. Ditto for 'klass' (or rather 'cls' which is
> used by the number of references). Again, it's not a reserved word.
> What if I've decided to use parameter name 'cls' in static function?
> What if I've decided to use 'this' instead of 'self'? So - either we
> need some mechanism to enforce the keywords 'self', 'cls', or -- we
> back to square one: we need decorators.

Not for this kind of thing we don't. The system could enforce the
convention. Or the 'object' class could. See the thread here entitled
antiDecorator metaclass for a demonstration of how this could be done.

--
http://mail.python.org/mailman/listinfo/python-list

pm_mon at yahoo

Aug 14, 2004, 8:04 PM

Post #10 of 35 (1029 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

>
> class Foo:
> def setX(self, x):
> self.x = x
>

The indentation was messed-up on that example. It should have been...

class Foo:
def setX(self, x):
self.x = x

--
http://mail.python.org/mailman/listinfo/python-list

johnfkeeling at yahoo

Aug 14, 2004, 9:32 PM

Post #11 of 35 (1023 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

Chas,
> action-at-a-distance is *always* bad.

I agree, but the culprit is the poor style of writing a
function/method implementation that spreads over numerous pages. If a
function is large, it is good style to break it up.
So, to my mind, the action-at-a-distance problem doesn't really exist
... it is just poor coding style of very large functions that creates
action-at-a-distance here:

> def blah (args):
> ....[insert 50/100/200 lines here]
> blah = staticmethod(blah)

I say, if function/method blah is over a page long, then it should be
broken up into smaller component functions, thus removing the
action-at-a-distance complaint.
So, with due respect for all honourable python devs who have given us
IMO the best programming language available, decorators, to my mind,
are a totally superfluous feature ... and this turns out to be a
negative because they are unnecessary (and divisive).
My opinion: please remove decorators forever, or at least until there
is some concensus as to how they should be used.
John
--
http://mail.python.org/mailman/listinfo/python-list

ben at benlast

Aug 15, 2004, 1:10 AM

Post #12 of 35 (1025 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

Hans (Hans Nowak (hans [at] zephyrfalcon)) wrote:
>This post wasn't deriding decorators; rather, it explains them,
>and provides some examples of how to use them. I do question
>their usefulness, but I'm not deriding them, nor the "@" syntax.
Just to be contrary, *this* post isn't questioning the usefulness of
decorators (though I've yet to see a case that really makes me feel they're
a killer feature), but *is* questioning the syntax (not deriding - I don't
do derision!)

The "@" notation feels a little bit Perl-esque to me, in a "let's overload
another symbol" type of way. It doesn't seem to follow the general
Python-zen model of using explicit words for extra functionality, such as
"staticmethod". I appreciate it's just syntactic sugar, but one could make
that same case for, say, the $_ variable in Perl.

Given (for the sake of argument), that decorators are useful (and here I'm
admitting that I may well be in ignorance of the finer points of their
requirements), do they *really* require a dedicated extension to the
language? Surely; those who are aware of the need for decorators will also
tend to be competent to build them using the language features that already
exist, obviating the need for special syntax? Although I concede the edge
case of experienced developers in another language who come to Python and
want to use such power-user features from day one.

This comment offered in all humility, as a first post :)

Ben

PS: Paul (Morrow): when I read your statement "I'm really not sure that
those 'Zen' items were intended to be absolute guiding principles", I
couldn't help but remember Captain Barbossa in Pirates Of The Caribbean -
"the [Pirate] code's more what you would call guidelines than actual
rules..." :)

--
http://mail.python.org/mailman/listinfo/python-list

cemerick at snowtide

Aug 15, 2004, 6:34 AM

Post #13 of 35 (1025 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

On August 14, 2004 9:35:48 AM EDT, Paul Morrow wrote:

> def blah(a, b): # this is clearly a static method
> pass
>
> def blah(self, a, b): # this is clearly an instance method
> pass

Ouch. Sorry, the arguments going into a function shouldn't have
**anything** to do with the nature of that function. Overloading their
existence, lack thereof, or their names as a way of describing the
function they are hung off of seems like a horrible way to go. (Not to
mention the fact that, at least conceptually, it is also violating that
action-at-a-distance guideline...)

On Aug 14, 2004, at 11:35 AM, Paul Morrow wrote:

> Yes, sorry, but I'm in a pickle here. I want (we need) the general
> idea of decorators --- the realm of problems that decorators try to
> solve --- to be made smaller. They should not be used to declare a
> method's type (static|instance|class). Decorators may have some valid
> purpose, but this is not one of them.

I would almost agree with you anywhere else. However, since GvM has
explicitly overruled the idea of something like:

def static blah (args):
pass

we're left to find other routes by which to specify method types.
Decorators neatly provide a generalized way to modify functions, so
that's where static|instance|class modifications land. I agree that
that's slightly unfortunate at the moment, but it's probably
necessitated by the history of using the horrible foo=staticmethod(foo)
idiom.

I say 'at the moment', because I can imagine quite a few decorators
that definitely touch on the notion of a function's type. Consider:

@remote([remoteFuncName], [accessRestrictions], ...)
def static blah (args):
pass

That might make blah available over xmlrpc, for example, though some
route predefined in whatever xmlrpc library one happens to be using.
Again, I'm no expert in python, so perhaps there's already similarly
easy ways to configure such things with the libraries that already
exist, but I think I got my point out there.

On , Hans Nowak wrote:

> This post wasn't deriding decorators; rather, it explains them, and
> provides some examples of how to use them. I do question their
> usefulness, but I'm not deriding them, nor the "@" syntax.

Sorry if I mischaracterized your intent...I meant no harm. :-)

- Chas Emerick

--
http://mail.python.org/mailman/listinfo/python-list

pm_mon at yahoo

Aug 15, 2004, 8:35 AM

Post #14 of 35 (1023 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

Chas Emerick wrote:

> On August 14, 2004 9:35:48 AM EDT, Paul Morrow wrote:
>
>> def blah(a, b): # this is clearly a static method
>> pass
>>
>> def blah(self, a, b): # this is clearly an instance method
>> pass
>
>
> Ouch. Sorry, the arguments going into a function shouldn't have
> **anything** to do with the nature of that function. Overloading their
> existence, lack thereof, or their names as a way of describing the
> function they are hung off of seems like a horrible way to go. (Not to
> mention the fact that, at least conceptually, it is also violating that
> action-at-a-distance guideline...)
>

That reminds me of how I once thought about using indentation as a means
of denoting code blocks. How idiotic I thought that was. Now I realize
the elegance, beauty, 'genius' in that.

Because of the conventions widely used (in Python) today, the name of a
method's first formal parameter *does* indicate the type of method. If
you use 'self' as the name of your first parameter, the majority of us
will assume that that this is an instance method. If you don't use
'self', we will assume that it is not an instance method (unless you use
'this', and we happen to be familiar with languages where that stands
for the instance at hand, but then that is not the recommended
practice). So you see, when you write a method, you are telling us
something about it's type (or what type it isn't). You are overloading
the semantics of the first parameter.

Why don't we all just acknowledge that we are doing this? Why don't we
all just admit that a well written instance method uses 'self' as its
first argument. And well written static or class methods (as well as
plain ol' functions) don't use 'self'.

If we strive for well written (clear) code, we follow these conventions.
These conventions convey meaning as to the type of method. Therefore,
explicitly stating the type of method is both superfluous and a
potential source of confusion.

I believe that the problem many of us have with ideas like this is that
no other even semi-popular languages do this. But does that make it
wrong? Is our use of indentation wrong?

--
http://mail.python.org/mailman/listinfo/python-list

ialbert at mailblocks

Aug 15, 2004, 9:06 AM

Post #15 of 35 (1028 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

Paul Morrow wrote:

> That reminds me of how I once thought about using indentation as a means
> of denoting code blocks. How idiotic I thought that was. Now I realize
> the elegance, beauty, 'genius' in that.

I disagree. In C (Perl, Java etc) we would do three things,
write braces, indent and put the semi-colon. In python we replaced
these three, with a single (the most obvious) one the indentation.

> Why don't we all just acknowledge that we are doing this? Why don't we
> all just admit that a well written instance method uses 'self' as its
> first argument. And well written static or class methods (as well as

If so then, the logically equivalent solution would be to pass self
as an implicit parameter, say a named parameter self with a default
reference to itself. I'm not suggesting this behavior, I only point out
what I think follows from the first example. The end goal is to
simplify the behavior not overload it and thus add
further meaning to it.

I do agree with Chas Emerick in that encoding special behavior in
variable names is a fragile solution.

Istvan.

--
http://mail.python.org/mailman/listinfo/python-list

pm_mon at yahoo

Aug 15, 2004, 10:43 AM

Post #16 of 35 (1024 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

Istvan Albert wrote:

> Paul Morrow wrote:
>
>
>> That reminds me of how I once thought about using indentation as a
>> means of denoting code blocks. How idiotic I thought that was. Now I
>> realize the elegance, beauty, 'genius' in that.
>
>
> I disagree. In C (Perl, Java etc) we would do three things,
> write braces, indent and put the semi-colon. In python we replaced
> these three, with a single (the most obvious) one the indentation.
>

And that's the genius there. Guido (I believe he's the one that came up
with it) realized that those other symbols were unnecessary. The
identation was enough to convey the author's intention. Now of course
this wouldn't have been a very good idea if we (developers as a whole)
used wildly different indentation styles. But we didn't/don't. There's
a conventional way of showing program structure thru indentation that
the majority of us have always used (subordinate code gets indented).

As Python developers, we have a convention on how we name the first
formal parameter of instance methods too. If you write a method that
follows that convention (uses 'self' as the name of its first parm),
then you don't need to do anything further to inform your readers that
it's an instance method.

>> Why don't we all just acknowledge that we are doing this? Why don't
>> we all just admit that a well written instance method uses 'self' as
>> its first argument. And well written static or class methods (as well as
>
>
> If so then, the logically equivalent solution would be to pass self
> as an implicit parameter, say a named parameter self with a default
> reference to itself. I'm not suggesting this behavior, I only point out
> what I think follows from the first example. The end goal is to
> simplify the behavior not overload it and thus add
> further meaning to it.
>

No, if self was passed implicitly, then you'ld be back in the situation
of having to specify (with additional syntax) which methods are instance
methods. Less is more. Python proves that.

> I do agree with Chas Emerick in that encoding special behavior in
> variable names is a fragile solution.
>

Define fragile. If you mean, easy to break, I don't see it. There
would be only one way to define an instance method: name its first
parameter 'self'. There would be only one way to define a class method:
name its first parameter 'klass' or 'cls' (or some other synoynm that we
can all vote on). All other methods would be static methods.

How is that fragile?

--
http://mail.python.org/mailman/listinfo/python-list

bokr at oz

Aug 15, 2004, 11:51 AM

Post #17 of 35 (1024 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

On Sun, 15 Aug 2004 13:43:30 -0400, Paul Morrow <pm_mon [at] yahoo> wrote:

>Istvan Albert wrote:
>
>> Paul Morrow wrote:
>>
>>
>>> That reminds me of how I once thought about using indentation as a
>>> means of denoting code blocks. How idiotic I thought that was. Now I
>>> realize the elegance, beauty, 'genius' in that.
>>
>>
>> I disagree. In C (Perl, Java etc) we would do three things,
>> write braces, indent and put the semi-colon. In python we replaced
>> these three, with a single (the most obvious) one the indentation.
>>
>
>And that's the genius there. Guido (I believe he's the one that came up
>with it) realized that those other symbols were unnecessary. The
>identation was enough to convey the author's intention. Now of course
>this wouldn't have been a very good idea if we (developers as a whole)
>used wildly different indentation styles. But we didn't/don't. There's
>a conventional way of showing program structure thru indentation that
>the majority of us have always used (subordinate code gets indented).
>
>As Python developers, we have a convention on how we name the first
>formal parameter of instance methods too. If you write a method that
>follows that convention (uses 'self' as the name of its first parm),
>then you don't need to do anything further to inform your readers that
>it's an instance method.
>
>
>>> Why don't we all just acknowledge that we are doing this? Why don't
>>> we all just admit that a well written instance method uses 'self' as
>>> its first argument. And well written static or class methods (as well as
>>
>>
>> If so then, the logically equivalent solution would be to pass self
>> as an implicit parameter, say a named parameter self with a default
>> reference to itself. I'm not suggesting this behavior, I only point out
>> what I think follows from the first example. The end goal is to
>> simplify the behavior not overload it and thus add
>> further meaning to it.
>>
>
>No, if self was passed implicitly, then you'ld be back in the situation
>of having to specify (with additional syntax) which methods are instance
>methods. Less is more. Python proves that.
>
>> I do agree with Chas Emerick in that encoding special behavior in
>> variable names is a fragile solution.
>>
>
>Define fragile. If you mean, easy to break, I don't see it. There
>would be only one way to define an instance method: name its first
>parameter 'self'. There would be only one way to define a class method:
>name its first parameter 'klass' or 'cls' (or some other synoynm that we
>can all vote on). All other methods would be static methods.
>
>How is that fragile?
>
In a narrow context such as distinguishing between methods, classmethods,
and staticmethods, ISTM not so fragile. OTOH, generalize the concept too much
and you get 'hungarian' naming rules as a way of controlling processing.
Perhaps that is what Chas and Istvan were worrying about.

I think I pretty much agree with you (Paul), except that I think the test for
'self' (and analogously 'cls') should be a name.startswith(...) test.
There are a few nested-scope cases where it is necessary to distinguish
two simultaneous and distinct 'self'-parameter bindings, and you need distinct
names to avoid shadowing the outer with the inner. No time to look for the example
I'm thinking of, but I'm sure you can create one (if Peter Otten doesn't beat you to it ;-)

Regards,
Bengt Richter
--
http://mail.python.org/mailman/listinfo/python-list

pm_mon at yahoo

Aug 15, 2004, 12:44 PM

Post #18 of 35 (1031 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

Bengt Richter wrote:

>
> I think I pretty much agree with you (Paul), except that I think the test for
> 'self' (and analogously 'cls') should be a name.startswith(...) test.
> There are a few nested-scope cases where it is necessary to distinguish
> two simultaneous and distinct 'self'-parameter bindings, and you need distinct
> names to avoid shadowing the outer with the inner. No time to look for the example
> I'm thinking of, but I'm sure you can create one (if Peter Otten doesn't beat you to it ;-)
>

Ok, I spent 10 minutes thinking about the situation you describe and
can't come up with anything. I'd love to see the example you're
referring to. I'm even more curious how you would document such a class :-)

--
http://mail.python.org/mailman/listinfo/python-list

cemerick at snowtide

Aug 15, 2004, 6:27 PM

Post #19 of 35 (1042 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

On Aug 15, 2004, at 11:55 AM, Paul Morrow wrote:

>> Ouch. Sorry, the arguments going into a function shouldn't have
>> **anything** to do with the nature of that function. Overloading
>> their existence, lack thereof, or their names as a way of describing
>> the function they are hung off of seems like a horrible way to go.
>> (Not to mention the fact that, at least conceptually, it is also
>> violating that action-at-a-distance guideline...)
>
> That reminds me of how I once thought about using indentation as a
> means of denoting code blocks. How idiotic I thought that was. Now I
> realize the elegance, beauty, 'genius' in that.
>
> Because of the conventions widely used (in Python) today, the name of
> a method's first formal parameter *does* indicate the type of method.
> If you use 'self' as the name of your first parameter, the majority of
> us will assume that that this is an instance method. If you don't use
> 'self', we will assume that it is not an instance method (unless you
> use 'this', and we happen to be familiar with languages where that
> stands for the instance at hand, but then that is not the recommended
> practice). So you see, when you write a method, you are telling us
> something about it's type (or what type it isn't). You are
> overloading the semantics of the first parameter.
>
> Why don't we all just acknowledge that we are doing this? Why don't
> we all just admit that a well written instance method uses 'self' as
> its first argument. And well written static or class methods (as well
> as plain ol' functions) don't use 'self'.
>
> If we strive for well written (clear) code, we follow these
> conventions. These conventions convey meaning as to the type of
> method. Therefore, explicitly stating the type of method is both
> superfluous and a potential source of confusion.
>
> I believe that the problem many of us have with ideas like this is
> that no other even semi-popular languages do this. But does that make
> it wrong? Is our use of indentation wrong?

I think you have the direction of causation reversed here. Python
programmers don't use 'self' as the first argument to indicate an
instance method, they/we (again, I worry how much cred I have as a
python programmer yet :-) use 'self' *because* a method is an instance
method. I know you'd like the reverse to become a
standard/convention...that's a respectable position, but not a
particularly practical one since a soon-to-be-standard method for
defining a function's type is on its way that just happens to be
generalized enough to be useful in tons of other contexts.

I think the source of my gut reaction to the proposal you've advanced
(aside from the conceptual action-at-a-distance violation that I
already cited) is my past experience with Hungarian notation, where the
name of a variable indicates its type. The comparison isn't totally
clean cut because of the special peculiarities of Hn, but I think the
folly that it represents is a clear warning to stay away from taking
type information based on naming conventions.

I won't discuss the virtues or drawbacks of whitespace-as-structure,
since that's been hacked to death 1433 times already. However, I will
say that python's usage of whitespace kept me away from seriously
trying it for almost a year. Now, that's absolutely my fault, and
isn't representative of the technical ability of python. However, if
continued rapid uptake of python by new users is important, I would
suggest that using the success of whitespace-as-structure in 'the
market' is not the greatest reference for a proposal.

- Chas Emerick

--
http://mail.python.org/mailman/listinfo/python-list

cemerick at snowtide

Aug 15, 2004, 6:54 PM

Post #20 of 35 (1025 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

On Aug 15, 2004, at 2:55 PM, Bengt Richter wrote:

>> Define fragile. If you mean, easy to break, I don't see it. There
>> would be only one way to define an instance method: name its first
>> parameter 'self'. There would be only one way to define a class
>> method:
>> name its first parameter 'klass' or 'cls' (or some other synoynm that
>> we
>> can all vote on). All other methods would be static methods.
>>
>> How is that fragile?
>>
> In a narrow context such as distinguishing between methods,
> classmethods,
> and staticmethods, ISTM not so fragile. OTOH, generalize the concept
> too much
> and you get 'hungarian' naming rules as a way of controlling
> processing.
> Perhaps that is what Chas and Istvan were worrying about.

Ach, that'll teach me to read all the digests in my mailbox before
mailing to the list :-) Yes, that's one of the aspects of my worries
in connection with this proposal.

I wouldn't use 'fragile' to describe the nature of the proposal.
'Sneaky' is a better one, in that it would be far, far too easy for
someone to inadvertently make a classmethod without intending to. The
decorator approaches to changing a method's type as well as the
old/current approach of func=staticmethod(func) are both superior in
this respect, in that they require a distinct intention by the code's
author.

Another way of looking at this is that the use of an explicit self
argument was chosen, one can surmise, as a way of making it completely
clear what is going on in the context of a member function (i.e. better
to write self.attr=x than just attr=x...I think this is mentioned in
the python FAQ). It would run completely counter to that decision to
now go back and start hanging implicit semantics off of arguments that
were originally specified for clarity's sake.

- Chas Emerick

--
http://mail.python.org/mailman/listinfo/python-list

pm_mon at yahoo

Aug 15, 2004, 6:59 PM

Post #21 of 35 (1020 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

Chas Emerick wrote:
>
> I think you have the direction of causation reversed here. Python
> programmers don't use 'self' as the first argument to indicate an
> instance method, they/we (again, I worry how much cred I have as a
> python programmer yet :-) use 'self' *because* a method is an instance
> method. I know you'd like the reverse to become a
> standard/convention...that's a respectable position, but not a
> particularly practical one since a soon-to-be-standard method for
> defining a function's type is on its way that just happens to be
> generalized enough to be useful in tons of other contexts.
>

The "soon-to-be-standard" (gosh, I hope not!) technique would require
that we explicitly 'declare' class methods and static methods, as we do
now (albeit with a different syntax). Isn't that less practical than
simply having the system enforce the coding convention? And what
happens when the declaration disagrees with the convention? That is,
what happens when a developer writes

def foo(self): pass

but declares it to be a class or static method? Shouldn't the system at
least issue a warning message (that you're likely to be confusing your
poor readers)? And if it's going to go that far... :-)

> I think the source of my gut reaction to the proposal you've advanced
> (aside from the conceptual action-at-a-distance violation that I already
> cited) is my past experience with Hungarian notation, where the name of
> a variable indicates its type. The comparison isn't totally clean cut
> because of the special peculiarities of Hn, but I think the folly that
> it represents is a clear warning to stay away from taking type
> information based on naming conventions.
>

I don't see your point about an 'action-at-a-distance' violation.
Wouldn't that only be the case if something we do locally has side
effects that break something in another part of the application?

As for the Hungarian notation, I agree that in its most abused state, it
can be a real mess for all sorts of reasons. However in Python we do
use a very lightweight form of that in the way we identify private and
semi-private methods.

> I won't discuss the virtues or drawbacks of whitespace-as-structure,
> since that's been hacked to death 1433 times already. However, I will
> say that python's usage of whitespace kept me away from seriously trying
> it for almost a year. Now, that's absolutely my fault, and isn't
> representative of the technical ability of python. However, if
> continued rapid uptake of python by new users is important, I would
> suggest that using the success of whitespace-as-structure in 'the
> market' is not the greatest reference for a proposal.
>

I said that it was elegant and genius; I never said that is wasn't a
barrier for adoption. Still it'll be a sad day when Guido decides that
to increase Python's popularity, we must support curly braces :-(

--
http://mail.python.org/mailman/listinfo/python-list

anthonybaxter at gmail

Aug 15, 2004, 10:01 PM

Post #22 of 35 (1027 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

On Sun, 15 Aug 2004 13:43:30 -0400, Paul Morrow <pm_mon [at] yahoo> wrote:
> Define fragile. If you mean, easy to break, I don't see it. There
> would be only one way to define an instance method: name its first
> parameter 'self'. There would be only one way to define a class method:
> name its first parameter 'klass' or 'cls' (or some other synoynm that we
> can all vote on). All other methods would be static methods.
>
> How is that fragile?

Python currently doesn't _care_ about the argument list, and the variable
names in it.

Adding this sort of behaviour is nasty. How, for instance, would you handle
adding a method to a class at runtime? Do you poke into the newly added
method to make sure you get it right? Do you not do this?

What about for more complex decorators? Remember, staticmethod and
classmethod are the trivial cases that this feature addresses. How do you
handle the more complex ones?
--
http://mail.python.org/mailman/listinfo/python-list

pm_mon at yahoo

Aug 16, 2004, 3:20 AM

Post #23 of 35 (1026 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

Anthony Baxter wrote:
> On Sun, 15 Aug 2004 13:43:30 -0400, Paul Morrow <pm_mon [at] yahoo> wrote:
>
>>Define fragile. If you mean, easy to break, I don't see it. There
>>would be only one way to define an instance method: name its first
>>parameter 'self'. There would be only one way to define a class method:
>>name its first parameter 'klass' or 'cls' (or some other synoynm that we
>>can all vote on). All other methods would be static methods.
>>
>>How is that fragile?
>
>
> Python currently doesn't _care_ about the argument list, and the variable
> names in it.
>

One thought is, to preserve backwards compatability, this special
behavior would only be invoked for subclasses of the new Object class.

> Adding this sort of behaviour is nasty. How, for instance, would you handle
> adding a method to a class at runtime? Do you poke into the newly added
> method to make sure you get it right? Do you not do this?
>

Same rules apply. The Python system would dynamically determine the
method's type when you add it (at runtime), so you'd need to make sure
that the first parm name is correct in advance.

> What about for more complex decorators? Remember, staticmethod and
> classmethod are the trivial cases that this feature addresses. How do you
> handle the more complex ones?

The point is that method type declarations are not needed, so decorators
wouldn't be concerned with this. Take them off the list of things
decorators can do.

--
http://mail.python.org/mailman/listinfo/python-list

cemerick at snowtide

Aug 16, 2004, 4:39 AM

Post #24 of 35 (1026 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

On Aug 15, 2004, at 10:26 PM, Paul Morrow wrote:

>> I think the source of my gut reaction to the proposal you've advanced
>> (aside from the conceptual action-at-a-distance violation that I
>> already cited) is my past experience with Hungarian notation, where
>> the name of a variable indicates its type. The comparison isn't
>> totally clean cut because of the special peculiarities of Hn, but I
>> think the folly that it represents is a clear warning to stay away
>> from taking type information based on naming conventions.
>
> I don't see your point about an 'action-at-a-distance' violation.
> Wouldn't that only be the case if something we do locally has side
> effects that break something in another part of the application?

In a previous message, I was talking about how a function declaration
and that function's arguments are conceptually atomic, and that making
any semantic connection between the two was conceptual
action-at-a-distance. It's a stretch of the term, but the best way I
had to describe it at the time.

> As for the Hungarian notation, I agree that in its most abused state,
> it can be a real mess for all sorts of reasons. However in Python we
> do use a very lightweight form of that in the way we identify private
> and semi-private methods.

Ugh. I know, and it's one of the little things about python that I am
not so fond of. It has the feel of something that GvM did in one of
the earliest python scripts that just ended up catching on with a wider
audience. It screams 'accident', not 'designed'. Please, no more of
that.

- Chas Emerick

--
http://mail.python.org/mailman/listinfo/python-list

anthonybaxter at gmail

Aug 16, 2004, 8:24 AM

Post #25 of 35 (1018 views)
Permalink

Re: Decorators: an outsider's perspective [In reply to]

On Mon, 16 Aug 2004 06:20:18 -0400, Paul Morrow <pm_mon [at] yahoo> wrote:
> > Python currently doesn't _care_ about the argument list, and the variable
> > names in it.
> >
>
> One thought is, to preserve backwards compatability, this special
> behavior would only be invoked for subclasses of the new Object class.

How is this backwards compatible? If you'd introduced it at the same time
as object, _maybe_ you could argue that. But this isn't the case here.

> > Adding this sort of behaviour is nasty. How, for instance, would you handle
> > adding a method to a class at runtime? Do you poke into the newly added
> > method to make sure you get it right? Do you not do this?
> Same rules apply. The Python system would dynamically determine the
> method's type when you add it (at runtime), so you'd need to make sure
> that the first parm name is correct in advance.

Really. And how would you implement this special casing in a way that
wasn't incredibly tricky to explain to users running across it? One of the
great things about Python is that if you need to, or you want to, you can
poke into the innards of the OO system and see how it works (particularly
since descriptors were added). This adds Perl-like levels of OO-hackery.
If that comment is unclear, I mean that when you poke into Perl's OO,
it becomes very clear, very quickly, that it's a hack.

> > What about for more complex decorators? Remember, staticmethod and
> > classmethod are the trivial cases that this feature addresses. How do you
> > handle the more complex ones?
> The point is that method type declarations are not needed, so decorators
> wouldn't be concerned with this. Take them off the list of things
> decorators can do.

Huh? You proposed a hack to specify class and static methods, using a
custom meta-class that pokes at the argument list of a function, and
suddenly you've removed the need for decorators for this? Please - feel
free to use your metaclass in your own code, but don't think that this is
in any way a solution that should be considered for "mainstream" python
use. It's a hack - a neat hack and a nice example of some of the things
metaclasses can do[1], but it's not a valid "solution" for the problem that
decorators are meant to solve. Look, staticmethod and classmethod are
a tiny tiny fraction of the things that decorator will be used for. Looking
at a large amount of Python code I've got here, I can see three examples
of classmethods (all alternate constructors) and no uses of staticmethod
at all.

Anthony

([1] and, I should note, one I was about to post until I saw your post <wink>)
--
http://mail.python.org/mailman/listinfo/python-list

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads