Dynamic class construction?

[David C. Ullrich]

Tim Peters wrote:

> [Adrian Eyre]
> >> [...]
> >>
> >> There's already a module which does this...
> >>
> >> import new
> >>
> >> def anOp(self):
> >>         return 'This is an instance of the class %s' % \
> >>                 self.__class__.__name__
> >>
> >> someOps={'__str__':anOp}
> >> G=new.classobj('G', (Group,), someOps) # Group defined elsewhere
>
> [David C. Ullrich]
> >     I sorta thought there might be a module that does this, but I
> > couldn't find it.
> >
> >     Um, I still can't find it. It appears to be a builtin module -
> > new.__doc__ says
> >
> > '     Functions to create new objects used by the interpreter.
> > You need to know a great deal about the interpreter to use this!',
> >
> > which is helpful, I guess, but I can't find any more about it in
> > the docs (or I'm not looking in the right place? It's not in the
> > "module index", I don't find any interesting files contaning
> > the text "classobj", etc.)
>
> The "new" module is deliberately undocumented.

    You mean _was_. It's undocumented in the official 1.5.2
docs, and it's documented in the "revised" 1.5.2 docs.

    If the docs are going to change more often than the program
(which is a good thing) the docs should have separate version
numbers. I could download the revised docs, but I don't see the
point, since I have no way of knowing tommorow whether
they're still current.

>  As the docstring says, you
> need to understand the internals of Python inside out to use it safely; but
> if you do know the internals sufficiently well to use "new" at all, you
> don't need any docs.  The module is not safe for general use (it provides
> unchecked access to the internals, and it's very easy to crash the
> interpreter by misusing it, and it's impossible not to misuse it if you
> don't know the internals ...).
>
> I'm not sure what the problem here is (haven't followed this thread), but
> "new" isn't the answer <0.9 wink>.

    The problem was that I didn't realize I was using 1.5.2 on n-1
machines and 1.5.1 on one machine (the one that wasn't in use
when I made the switch).

> If that doesn't dissuade you, study Modules/newmodule.c in the source
> distribution.

    Thanks. I had everything working exactly the way I wanted
except that __name__ was readonly - I started the thread just
looking for comments on whether I was doing it the "right"
way, and whether anyone saw any problems lurking in what
I'd been doing. Nobody's pointed out any possible Bad Things
with what I'd been doing, so right now everything's absolutely
perfect, thanks.

    Why _did_ the status of __name__ change? When I was
told that "new" was introduced in 1.5.2 I conjectured that
that was the reason. But that's not so so that can't be it...

> the-code-*is*-the-docs-in-this-case-ly y'rs  - tim

    It's code in that funny language where all the statements
are inside comments, right?

DU