PEP 318: Can't we all just get along?

[Bengt Richter]

On Wed, 18 Aug 2004 08:35:21 -0400, Paul Morrow <pm_mon at yahoo.com> wrote:

>Dan Sommers wrote:
>> On Tue, 17 Aug 2004 21:13:47 -0400,
>> Paul Morrow <pm_mon at yahoo.com> wrote:
>> 
>> 
>>>First though, I still believe that we should exploit existing
>>>conventions (recommended coding practices) as a way of getting 'free'
>>>declarations for class, static, and instance methods (e.g. methods
>>>whose first param is 'self' are instance methods, etc.). That feels
>>>very pythonic to me, just as we use naming conventions to distinguish
>>>public, private, and semi-private methods.
>> 
>> 
>> I don't understand how assigning semantic significance to a "recommended
>> coding practice" is Pythonic.
>> 
>> In the face of ambiguity, refuse to guess.
>> 
>> Explicit is better than implicit.
>> 
>
>Good conventions prevent ambiguity.
Conventions don't direct computation though, they just direct human interpretation.
That is, unless you use convention-patterns as you propose for self etc., and then
they aren't just conventions. (As you may infer, my second thoughts on this are
not supportive of overloading naming. I thought it was not that "fragile" in the
narrow context of ordinary method definition, but I think it's a step on a slippery
slope to name-tricks that too many clever people may be tempted to step onto ;-)

>
>    class Foo:
>       def method1(self, a, b): pass       # clearly an instance method
>       def method2(cls, a, b): pass        # clearly a class method
>       def method3(a, b): pass             # clearly a static method
        def method4(*args): pass            # clearly different ;-)
>
>
>When declarations conflict with conventions, it makes us wonder what the 
>author really intended.
Sure, that's natural. Depending on the author, you might look for something
interesting ;-)
>
>       def staticmethod setX(self, x):
>           self.x = x
>
> >
> > I think that the idea that started this thread is just right:
> >
>
>You're right, this thread is about decorators, not about more 
>opportunities for dynamic typing.  I just wanted to remind us that 
>decorators are a lot like static typing, which isn't terribly pythonic.
>
Maybe simple-name callables between the def and the function name
would cover most use cases, and you could let people do what they want
to set up the names. A single name could also be bound to a composition of
several things in a lambda or whatever, if handy for repetitive concise use.
    import mydecorators
    deco1 = mydecorators.deco1
    deco2 = mydecorators.deco2factory('this', 'that', 'tother')
    class Foo(object):
        def staticmethod deco1 method1(x,y): pass
        def deco2 method2(self): pass

A plain name series between def and arg list shouldn't be hard grammar-wise, IWT.
The idea is growing on me. It doesn't abuse naming itself.

Argh, must go ...

Regards,
Bengt Richter