PEP318: radical notion

Discussion in 'Python' started by Arien Malec, Aug 23, 2004.

  1. Arien Malec

    Arien Malec Guest

    Apologies for feeding the fire, when we are rallying around a consensus,
    but I've been concerned about the clash between syntax and semantics, and
    I've finally reached a mini-epiphany:

    The problem with PEP318 is that it is too powerful, and tries to do too
    much. It is a sledgehammer for attacking three problems:

    1) Metadata, a la Java and C#
    2) class & static method defs
    3) Arbitrary post-definitional transformations of functions.

    (where 2 is a special frequent use case that's part of 3).

    We have ueber-powerful semantics (implementing 3), trying to solve
    problems with very different semantics (e.g., 1).

    OK, that's what I know. Here's a proprosal, that may or may not work,
    because my knowledge of metaclass programming is only sketchy:

    1) Make PEP318 *only* implement problem (1). That is, create sematics for
    defining and retrieving function/method/class metadata
    2) Create a new default metaclass that uses metadata for class/static
    method definitions to perform the necessary class/staticmethod
    transformations. Perhaps use this metaclass as default in 2.4 only via a
    "from __future__ import foo".
    3) Leave any arbitrary transformations to be implemented via custom
    metaclasses -- these metaclasses will have access to the custom metadata
    to trigger method def transformations.

    Arien
     
    Arien Malec, Aug 23, 2004
    #1
    1. Advertising

  2. Arien Malec wrote:

    > Apologies for feeding the fire, when we are rallying around a consensus,
    > but I've been concerned about the clash between syntax and semantics, and
    > I've finally reached a mini-epiphany:
    >
    > The problem with PEP318 is that it is too powerful, and tries to do too
    > much. It is a sledgehammer for attacking three problems:
    >
    > 1) Metadata, a la Java and C#
    > 2) class & static method defs
    > 3) Arbitrary post-definitional transformations of functions.
    >
    > (where 2 is a special frequent use case that's part of 3).
    >
    > We have ueber-powerful semantics (implementing 3), trying to solve
    > problems with very different semantics (e.g., 1).
    >
    > OK, that's what I know. Here's a proprosal, that may or may not work,
    > because my knowledge of metaclass programming is only sketchy:
    >
    > 1) Make PEP318 *only* implement problem (1). That is, create sematics for
    > defining and retrieving function/method/class metadata
    > 2) Create a new default metaclass that uses metadata for class/static
    > method definitions to perform the necessary class/staticmethod
    > transformations. Perhaps use this metaclass as default in 2.4 only via a
    > "from __future__ import foo".
    > 3) Leave any arbitrary transformations to be implemented via custom
    > metaclasses -- these metaclasses will have access to the custom metadata
    > to trigger method def transformations.
    >
    > Arien


    Unfortunately for you, you can use decorators on normal functions and not
    only on member functions. It rules out any metaclass based implementation.
     
    Christophe Cavalaria, Aug 23, 2004
    #2
    1. Advertising

  3. Arien Malec

    Peter Hansen Guest

    Arien Malec wrote:

    > Apologies for feeding the fire, when we are rallying around a consensus,
    > but I've been concerned about the clash between syntax and semantics, and
    > I've finally reached a mini-epiphany:
    >
    > The problem with PEP318 is that it is too powerful, and tries to do too
    > much. It is a sledgehammer for attacking three problems:

    [snip]

    I believe your mini-epiphany has been reached by several other people
    in this forum and discussed at length, certainly not in exactly the
    same words but surely in a very similar form.

    If you've checked the archives and seen those discussions, but still
    feel you have something really original to contribute, I suggest
    contrasting your argument with those previous ones to demonstrate
    how it is different and worth further discussion at this point.
    If you don't, I expect many people will feel you are just rehashing
    something very late in the game and will mostly ignore your post.

    -Peter
     
    Peter Hansen, Aug 23, 2004
    #3
  4. Arien Malec

    Arien Malec Guest

    Peter Hansen <> wrote in
    news::

    > Arien Malec wrote:
    >
    >> Apologies for feeding the fire, when we are rallying around a
    >> consensus, but I've been concerned about the clash between syntax and
    >> semantics, and I've finally reached a mini-epiphany:
    >>
    >> The problem with PEP318 is that it is too powerful, and tries to do
    >> too much. It is a sledgehammer for attacking three problems:

    > [snip]
    >
    > I believe your mini-epiphany has been reached by several other people
    > in this forum and discussed at length, certainly not in exactly the
    > same words but surely in a very similar form.


    I haven't heard too much resolution about it. The discussion I've seen
    has been oriented mostly around syntax, partly around "this is ugly but
    Guido says it goes".

    I haven't heard the "it's really not ugly, and here's why" part of this.

    Arien

    Arien
     
    Arien Malec, Aug 23, 2004
    #4
  5. Arien Malec

    JCM Guest

    Arien Malec <> wrote:
    > Apologies for feeding the fire, when we are rallying around a consensus,
    > but I've been concerned about the clash between syntax and semantics, and
    > I've finally reached a mini-epiphany:


    > The problem with PEP318 is that it is too powerful, and tries to do too
    > much. It is a sledgehammer for attacking three problems:


    > 1) Metadata, a la Java and C#
    > 2) class & static method defs
    > 3) Arbitrary post-definitional transformations of functions.


    Agreed. I think trying to address all of this with decorators is the
    wrong way to go.
     
    JCM, Aug 23, 2004
    #5
  6. Arien Malec

    Arthur Guest

    On Mon, 23 Aug 2004 18:12:57 GMT, Arien Malec
    <> wrote:

    >
    >The problem with PEP318 is that it is too powerful, and tries to do too
    >much. It is a sledgehammer for attacking three problems:
    >
    >1) Metadata, a la Java and C#
    >2) class & static method defs
    >3) Arbitrary post-definitional transformations of functions.


    The problem as you see it was, I think, was very well put forth by
    Chris King early in the game, and then promptly bypassed.

    Guido, as late as May or June, I think, suggested that no new syntax
    be added to 2.4. But then backed off that position, to the point that
    discussion about anything other than *which* new syntax to empower the
    sledgehammer, has become anti-social, or something.

    Perhaps Guido could not answer the question to himself, or anybody
    else, as to - no new syntax in 2.4, pending what.

    Folks a lot more qualified than myself have expressed an opinion that
    the reprecussions here are not likely to be pretty. And been booed off
    the stage, and considerately left the stage - it not being their
    problem in the end, in anycase.

    So it is my opinion the weight of discussion on python-list at this
    point does not accurately reflect the weight of sentiment on the
    issue. Most folks don't like being anti-social.

    I allow myself to be. Sometimes.

    Art

    >
    >Arien
     
    Arthur, Aug 24, 2004
    #6
  7. Arien Malec

    Arien Malec Guest

    Christophe Cavalaria <> wrote in message news:<412a4222$0$293$>...
    > Arien Malec wrote:


    > > 1) Make PEP318 *only* implement problem (1). That is, create sematics for
    > > defining and retrieving function/method/class metadata
    > > 2) Create a new default metaclass that uses metadata for class/static
    > > method definitions to perform the necessary class/staticmethod
    > > transformations. Perhaps use this metaclass as default in 2.4 only via a
    > > "from __future__ import foo".
    > > 3) Leave any arbitrary transformations to be implemented via custom
    > > metaclasses -- these metaclasses will have access to the custom metadata
    > > to trigger method def transformations.


    > Unfortunately for you, you can use decorators on normal functions and not
    > only on member functions. It rules out any metaclass based implementation.


    Is there a valid use case that supports arbitrary magical non-metadata
    transformations of standalone functions?

    Arien
     
    Arien Malec, Aug 24, 2004
    #7
  8. Arien Malec wrote:

    > Christophe Cavalaria <> wrote in message
    > news:<412a4222$0$293$>...
    >> Arien Malec wrote:

    >
    >> > 1) Make PEP318 *only* implement problem (1). That is, create sematics
    >> > for defining and retrieving function/method/class metadata
    >> > 2) Create a new default metaclass that uses metadata for class/static
    >> > method definitions to perform the necessary class/staticmethod
    >> > transformations. Perhaps use this metaclass as default in 2.4 only via
    >> > a "from __future__ import foo".
    >> > 3) Leave any arbitrary transformations to be implemented via custom
    >> > metaclasses -- these metaclasses will have access to the custom
    >> > metadata to trigger method def transformations.

    >
    >> Unfortunately for you, you can use decorators on normal functions and not
    >> only on member functions. It rules out any metaclass based
    >> implementation.

    >
    > Is there a valid use case that supports arbitrary magical non-metadata
    > transformations of standalone functions?
    >
    > Arien


    memoize for example. No metadata, only transformation, doesn't really apply
    to a member function in fact ( although it might be possible à

    Why is it that there are always some people who doesn't understand all the
    possibilities of decorators and so want to minimise their usefulness ?
     
    Christophe Cavalaria, Aug 24, 2004
    #8
  9. Arien Malec

    Arthur Guest

    On Wed, 25 Aug 2004 00:57:41 +0200, Christophe Cavalaria
    <> wrote:

    >Why is it that there are always some people who doesn't understand all the
    >possibilities of decorators and so want to minimise their usefulness ?


    I can't understand, yet, talking about decorators as if they *are*
    something.

    We have shortedened some syntax.

    Before alpha 2, decorators were not.

    Now they ain't.

    ;)

    Art
     
    Arthur, Aug 25, 2004
    #9
  10. Arien Malec

    Arien Malec Guest

    Christophe Cavalaria <> wrote in
    news:412bc7e6$0$4065$:

    > Arien Malec wrote:


    >> Is there a valid use case that supports arbitrary magical
    >> non-metadata transformations of standalone functions?

    >
    > memoize for example. No metadata, only transformation, doesn't really
    > apply to a member function in fact ( although it might be possible à


    Classically, memoize is implemented as function composition, or as a true
    GoF decorator. It's not clear (to me, at least) how much benefit the
    syntactic sugar gets you.

    > Why is it that there are always some people who doesn't understand all
    > the possibilities of decorators and so want to minimise their
    > usefulness ?


    I dunno. Who are those people? My objection to PEP318 is that makes
    something that's really powerful (arbitrary transformation) look like a
    trivial declaration. In Common Lisp, for instance, a defmacro form hints
    that powerful mojo is being performed; the same is not apparent in
    PEP318.

    Arien
     
    Arien Malec, Aug 25, 2004
    #10
  11. Arien Malec wrote:
    ....
    > Is there a valid use case that supports arbitrary magical non-metadata
    > transformations of standalone functions?


    2 use cases (in addition to others people have mentioned) I can think of
    off the top of my head:
    * Adding call tracing to specific functions without disturbing the
    code.
    * Wrapping generator functions so that they can recieve data in an
    IPC manner.

    using:
    trace(level=1)
    def somefunc(foo):
    if bla(foo) == 1:
    return weeble(foo)
    elif baz(foo) == 2:
    return wobble(foo)
    elif bibble(foo) == 3:
    return jeeble(foo)
    elif bloing(foo) == 4:
    return jobble(foo)
    elif nickynickynack(foo) == 5:
    return fnarkle(foo)

    Adding a trace function in here temporarily would mean you can intercept
    both the call and the return values conveniently - as you would with
    memoise (say), but you can do something interesting with it.
    Furthermore, if you're not sure your memoise decorator is doing the
    right thing you could do something like:

    using:
    trace(level=1)
    memoise
    def somefunc(foo):
    if bla(foo) == 1: ...

    Followed by...

    using:
    memoise
    trace(level=1)
    def somefunc(foo):
    if bla(foo) == 1: ...

    And potentially:

    using:
    trace(level=1)
    def somefunc(foo):
    if bla(foo) == 1: ...

    And do a compare and contrast of results. Behaviour is transformed,
    there is no metadata involved and it's suitable for any function -
    whether it's part of a class's namespace (as any kind of method), or
    not. Since they're not necessarily part of a class you can't use
    metaclasses to do this.

    Regards,


    Michael.
    --

    British Broadcasting Corporation, Research and Development
    Kingswood Warren, Surrey KT20 6NP

    This message (and any attachments) may contain personal views
    which are not the views of the BBC unless specifically stated.
     
    Michael Sparks, Aug 25, 2004
    #11
  12. Arien Malec

    Arien Malec Guest

    Michael Sparks <> wrote in
    news:cgi4vh$4q7$:

    > Arien Malec wrote:
    > ...
    >> Is there a valid use case that supports arbitrary magical
    >> non-metadata transformations of standalone functions?

    >
    > 2 use cases (in addition to others people have mentioned) I can think
    > of off the top of my head:
    > * Adding call tracing to specific functions without disturbing the
    > code.
    > * Wrapping generator functions so that they can recieve data in an
    > IPC manner.


    PEP318 = AOP by another name?

    I can think of a couple of workaround for the issue you raise:

    1) Allow a "module metaclass" -- something that can intercept function
    defs at a module level, read metadata, and apply necessary
    transformations

    2) Have a default class that standalone functions are static members of,
    which can have a default metaclass associated with it.

    I personally think that separating metadata from transformations is a
    much cleaner approach than using the transformation implementation for
    everything.

    Arien
     
    Arien Malec, Aug 25, 2004
    #12
  13. On 25-aug-04, at 0:13, Arien Malec wrote:

    >
    > Is there a valid use case that supports arbitrary magical non-metadata
    > transformations of standalone functions?


    Barray Warsaw has mentioned several times on py-dev that he has
    actually used several of the propesed syntaxes to rewrite existing code
    that uses decorators (IIRC mailman).

    Ronald
     
    Ronald Oussoren, Aug 25, 2004
    #13
  14. Arien Malec wrote:

    > Christophe Cavalaria <> wrote in
    > news:412bc7e6$0$4065$:
    >
    >> Arien Malec wrote:

    >
    >>> Is there a valid use case that supports arbitrary magical
    >>> non-metadata transformations of standalone functions?

    >>
    >> memoize for example. No metadata, only transformation, doesn't really
    >> apply to a member function in fact ( although it might be possible à

    >
    > Classically, memoize is implemented as function composition, or as a true
    > GoF decorator. It's not clear (to me, at least) how much benefit the
    > syntactic sugar gets you.


    Ease of writing and reading aren't benefits for you ?

    >> Why is it that there are always some people who doesn't understand all
    >> the possibilities of decorators and so want to minimise their
    >> usefulness ?

    >
    > I dunno. Who are those people? My objection to PEP318 is that makes
    > something that's really powerful (arbitrary transformation) look like a
    > trivial declaration.


    If that's your objection, say it. I'm ok with that. But don't do that :

    people : we need generators for usage a, b, c
    you : here is a great syntax. It handles case a and b in such a beautiful
    way and it's much much better that some other proposal
    people : what about case c ?
    you : case what ?

    > In Common Lisp, for instance, a defmacro form hints
    > that powerful mojo is being performed; the same is not apparent in
    > PEP318.


    Well, if the @pie form isn't a clear way to say that something strange is
    going on, I don't know what is :)
     
    Christophe Cavalaria, Aug 25, 2004
    #14
  15. Arien Malec

    Arien Malec Guest

    Christophe Cavalaria <> wrote in message news:<412d13bc$0$14159$>...
    > Arien Malec wrote:
    >
    > > Christophe Cavalaria <> wrote in
    > > news:412bc7e6$0$4065$:


    > >> Why is it that there are always some people who doesn't understand all
    > >> the possibilities of decorators and so want to minimise their
    > >> usefulness ?

    > >
    > > I dunno. Who are those people? My objection to PEP318 is that makes
    > > something that's really powerful (arbitrary transformation) look like a
    > > trivial declaration.

    >
    > If that's your objection, say it. I'm ok with that.


    I did, see the top of this thread.

    To be clear, I don't deny that autotransformers of module-scoped
    functions wouldn't be quite useful; I'm queasy about using the same
    syntax to add metadata AND mangle functions and methods.

    My thought was that metadata + metaclasses gives the same ability as
    PEP318 in a clean way to a suffiently large subset of use cases that
    it's better to go with that and figure out separately how to perform
    metaclass-like magic to module-scoped functions than it is to apply
    the function autotransformation semantics to solve all problems.

    Arien
     
    Arien Malec, Aug 27, 2004
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. T Chheng

    class? :: notion

    T Chheng, Aug 17, 2004, in forum: Perl
    Replies:
    1
    Views:
    462
    Jim Gibson
    Aug 17, 2004
  2. PEP318

    , Aug 11, 2004, in forum: Python
    Replies:
    30
    Views:
    1,239
    Greg Ewing
    Aug 17, 2004
  3. Arthur

    RE: PEP318

    Arthur, Aug 13, 2004, in forum: Python
    Replies:
    0
    Views:
    379
    Arthur
    Aug 13, 2004
  4. Ronald Oussoren

    Re: PEP318

    Ronald Oussoren, Aug 13, 2004, in forum: Python
    Replies:
    2
    Views:
    395
    Arthur
    Aug 23, 2004
  5. Stefan Ram

    Searching for a notion

    Stefan Ram, Sep 2, 2008, in forum: Java
    Replies:
    15
    Views:
    518
    Stefan Ram
    Sep 3, 2008
Loading...

Share This Page