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

John Roth newsgroups at jhrothjr.com
Fri Aug 20 03:15:56 CEST 2004


"Michael J. Fromberger" <Michael.J.Fromberger at Clothing.Dartmouth.EDU> wrote
in message news:Michael.J.Fromberger-AE7E18.17313219082004 at localhost...
> In article <10ia3aa8j6tbma5 at news.supernews.com>,
>  "John Roth" <newsgroups at jhrothjr.com> wrote:
>
> > "Michael J. Fromberger" <Michael.J.Fromberger at Clothing.Dartmouth.EDU>
wrote
> > in message news:Michael.J.Fromberger-D24476.14010119082004 at localhost...
> > > In article <10i9msuatli5p84 at news.supernews.com>,
> > >  "John Roth" <newsgroups at jhrothjr.com> wrote:
> > >
> > > > In other words, forget the use cases.  They're irrelevant.
> > >
> > > On this point, I strongly disagree.  If you don't have a use case,
there
> > > is no point whatsoever in arguing about the syntax of a feature.
> >
> > There is a use case. If you go back and read the original
> > post I was replying to, it contains the sentence:
> >
> > [begin quote]
> > I guess others had bigger plans for my proposal that I had planned.  It
> > has turned into the "solution" to many problems: type checking (both
> > arguments and returned values), metaclasses, metadata, interfaces,
> > function attributes, etc.).
> > [end quote]
>
> Ah, I see.  I misunderstood your intent.  My apologies.
>
> Nevertheless, I think it's clear the Python community at large ought to
> have a clearer idea of exactly what the use cases ARE (and, more
> importantly, what they're not) before deciding on a syntax.  It's not
> clear to me that there's consensus on purpose yet (as witness the wildly
> divergent ideas that have accumulated on the wiki, comp.lang.python, and
> python-dev).

I don't think they're particularly related. Functionally, whatever happens
as the result of a decorator will be the return of an object which
will be bound to the class or module (or serve as the input to another
decorator, of course.) In most cases, this will either be the original input
or a descriptor that has the original input as an attribute.

This is a very generic mechanism of amazing simplicity. It can be put
to as many uses as one wishes. There are currently implementations
of just about everything that has been suggested, including Design
by Contract, Aspects and several forms of type checking.

The whole question of syntax is simply orthogonal. The current
syntax works perfectly well; it's just very poor from an intention revealing
standpoint.

John Roth
>
> Cheers,
> -M
>
> -- 
> Michael J. Fromberger             | Lecturer, Dept. of Computer Science
> http://www.dartmouth.edu/~sting/  | Dartmouth College, Hanover, NH, USA





More information about the Python-list mailing list