[Python-Dev] PEP 318 (was re: redefining is)

[Jack Diederich]

On Thu, Mar 25, 2004 at 02:45:08AM -0500, Raymond Hettinger wrote:
> > > Heh, another use for the class variant of PEP 318.  Josiah's code
> > > depends on knowing which classes have immutable instances, using a
> > > hardcoded set of builtin types.  With PEP318, one could do
> > >
> > > class foo [immutable]:
> > >     ...
> > >
> > > with an appropriate definition of immutable that either decorates
> the
> > > class object or adds to the set of known immutables.  Perhaps also
> with
> > > code to catch and warn against obvious attempts at mutation of
> foos...
> 
> This PEP is losing its innocence.
> 
> Having been repeatedly confronted with FUD arguments in other contexts,
> I hate to put on that hat, but I do not think it wise to support too
> many varieties of weirdness.  Heck, we've already got meta-classes for
> that.

class decorators would make my code clearer, not weirder because I would
all but stop using metaclasses.  If someone were talking about inheriting
decorators, _that_ would be doubling the overall weirdness.

What he wants to do is weird, here is how I use the same effect
for something that is much saner.

def rebuild_nightly(cls):
  nightly_reports.append(cls)
  return cls

# without decorators
class NewUsersReport(Report):
  # fifty lines of class body
rebuild_nightly(NewUsersReport)

# with decorators
class NewUsersReport(Report) [rebuild_nightly]:
  # fifty lines of class body

Without decorators, it is easy to lose the rebuild_nightly() call.
And then my report dosn't run.
You can do it using metaclasses but then the magic is hidden very far
away in the Report's metaclass.  class Decorators say loudly that
the class that is about to be defined is modified or participates in X
right at the top where everyone can see it.

I currently do do this with metaclasses, because I've accidentally
left out or deleted the rebuild_nightly() call that was hidden far
away from the Report definition.  That hurts.

> 
> > One could even include the disclaimer that any code that modifies an
> > instance that is supposed to be immutable, is inherantly broken and is
> > not supported
> 
> <fud>
> I'm sensing an unnamed code smell.
> </fud>

Some people will use decorators instead of metaclasses to do odd things.
People currently eval() docstrings, use preprocessors, and do zany things
with stack frames.  That they might use decorators for the same unsupported
'features' (like contracts) doesn't make decorators any more culpable than 
docstrings or stack frames.

My world won't collapse without decorators, but it would be better with them.

-jackdied