PEP318: radical notion

[Arien Malec]

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

 

[Christophe Cavalaria]

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.

 

[Peter Hansen]

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

 

[Arien Malec]

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

 

[JCM]

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.

 

[Arthur]

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 Malec]

Arien Malec wrote:

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

 

[Christophe Cavalaria]

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 ?

 

[Arthur]

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

 

[Arien Malec]

Arien Malec wrote:

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

 

[Michael Sparks]

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.
--
(e-mail address removed)
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.

 

[Arien Malec]

Arien Malec wrote:
...

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

 

[Ronald Oussoren]

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

 

[Christophe Cavalaria]

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 ?

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

 

[Arien Malec]

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