470,866 Members | 1,878 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,866 developers. It's quick & easy.

Getting a list of all classes derived from a base class

Hi,
I have a requirement to findout all the classes that are derived from a
single base class.

This is how I do it currently.

class Test:
case = []

class Test1(Test):
Test.case.append("Test1")

class Test2(Test):
Test.case.append("Test2")

1. Is there a better way of doing this.
2. Is there a way to generalize the Test.case.append("TestN")
statements to something like
Test.case.append(__myclass__)

--
Warm Regards,
Vijairaj

Apr 3 '06 #1
6 2753
Vijairaj R wrote:
Hi,
I have a requirement to findout all the classes that are derived from a
single base class.

This is how I do it currently.

class Test:
case = []

class Test1(Test):
Test.case.append("Test1")

class Test2(Test):
Test.case.append("Test2")

1. Is there a better way of doing this.
2. Is there a way to generalize the Test.case.append("TestN")
statements to something like
Test.case.append(__myclass__)

--
Warm Regards,
Vijairaj


If you're willing to use metaclass madness:

class TestMeta(type):
def __init__(cls, name, bases, dct):
if bases == (object,): return # Prevent the appending of Test
cls.case.append(cls)

class Test(object):
__metaclass__ = TestMeta
case = []

class Test1(Test): pass
class Test2(Test): pass

print Test.case

Apr 3 '06 #2
Vijairaj R <Vi********@gmail.com> wrote:
...
class Test:


do not use old-style classes: they exist ONLY for backwards
compatibility.

Make you class Test new-style:

class Test(object):
...
and you can call Test.__subclasses__() to get a list of all extant
subclassed of Test at any time.
Alex
Apr 3 '06 #3
Thanks Dylan and Alex, that was a new learning for me.

but both the solutions don't work in jython 2.1 is there an alternative
that will work with jython2.1

--
Thanks,
Vijairaj

Apr 3 '06 #4
Alex Martelli wrote:
Vijairaj R <Vi********@gmail.com> wrote:
...
class Test:


do not use old-style classes: they exist ONLY for backwards
compatibility.

Make you class Test new-style:

class Test(object):
...
and you can call Test.__subclasses__() to get a list of all extant
subclassed of Test at any time.
Alex


Thanks Alex. That's a new one to me -- new-style classes have so many
strange properties.

Apr 3 '06 #5
Vijairaj <Vi********@gmail.com> wrote:
Thanks Dylan and Alex, that was a new learning for me.

but both the solutions don't work in jython 2.1 is there an alternative
that will work with jython2.1


Alas, no: your simple idea is essentially the best you can do in any
implementation of Pyhon at 2.1 level.

To put a positive spin on it: if there *WEREN'T* some things that are
much easier and slicker in Python 2.4, with all the years and the work
we've put into Python since 2.1's times, now THAT would be bad!-)

I do hope that Jython does eventually "grow up" to a more modern version
of Python -- unfortunately, I'm too rusty with Java, and not involved
enough in JVM work day by day, to actually help out there, and
apparently so are most potential contributors to Jython:-(
Alex
Apr 3 '06 #6
Dylan Moreland <dy************@gmail.com> wrote:
...
do not use old-style classes: they exist ONLY for backwards
compatibility. ... and you can call Test.__subclasses__() to get a list of all extant
subclassed of Test at any time.
... Thanks Alex. That's a new one to me -- new-style classes have so many
strange properties.


You're welcome! Actually, IMHO, it's the _legacy_ style classes which
have odd quirks, as they fail to distinguish cleanly between a type/clas
and its instances, and provide a unified conceptual model.

For example, given an object X which has an attribute named __call__
(has it directly, not from its class/type), does calling X() call
X.__call__()? In the new-style model, the answer is clear and sharp:
no. Special methods that Python internally invokes always come from the
type/class, never from the object itself. In the legacy model, the
answer is fuzzy and muddled: "mostly yes _except_ if X is a class then
no", because if X is a class then X.__call__ is meant to influence the
behavior of calling *instances* of X, only, not that of calling X
itself.

This kind of "conceptual muddle" in oldstyle classes could not be solved
without breaking backwards compatibility, so a parallel concept of
"newstyle" was introduced, and behaves much more simply and predictably;
in Python 3.0, oldstyle will go away -- good riddance!-)

This is quite separate from the fact that, since Python 2.2 where
newstyle objects were introduced, some handy features such as __mro__
and __subclasses__ were introduced -- not to legacy classes, of course,
since you should not use those in new code (not for conceptual reasons).
The "conceptual" side of things can be boiled down to descriptors (and
to a lesser extent, custom metaclasses, but those are rare beasts).
Alex
Apr 3 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Indiana Epilepsy and Child Neurology | last post: by
9 posts views Thread by Naren | last post: by
16 posts views Thread by chameleon | last post: by
8 posts views Thread by Pallav singh | last post: by
6 posts views Thread by Immortal Nephi | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.