use class factory to set required class variables?

[Alan]

I have a class ``A`` that is intentionally incomplete:
it has methods that refer to class variables that do not exist.
The class ``A`` has several complicated methods, a number
of which reference the "missing" class variables.
Obviously, I do not directly use ``A``.

I have a class factory ``f``` that subclasses ``A`` *only* in
order to define the class variables.

The motivation/problem:
I did this because I need many versions of class ``A``,
which differ only in the class variables, which are not
known until run time.

Q: On the face of it, did I pick a reasonable solution to
my problem? If so is this a standard pattern? If not,
can you mention a better approach?

My solution is working for me, but the class ``A``
is bugging me, because of the odd (to me) way in
which it is incomplete. Obviously, I'm not a
computer science type ...

Thanks,
Alan Isaac

 

[Alan]

I have a class factory ``f``` that subclasses ``A`` *only* in
order to define the class variables.

I suppose it would be clearer to say that `f` *returns*
subclasses of `A`. Hopefully that was clear ...

Alan Isaac

 

[Steven D'Aprano]

I have a class ``A`` that is intentionally incomplete: it has methods
that refer to class variables that do not exist.

For the record, in Python it is usual to refer to "attributes" rather
than "class variables" and "instance variables". In Python, classes are
first-class objects (pun not intended) like ints, strings, floats etc.,
and so a "class variable" would be a variable holding a class, just as a
string variable would be a variable holding a string, an int variable
holds an int, etc.

The class ``A`` has
several complicated methods, a number of which reference the "missing"
class variables. Obviously, I do not directly use ``A``.

This is called an abstract class -- you need to subclass it to use it.

I have a class factory ``f``` that subclasses ``A`` *only* in order to
define the class variables.

The motivation/problem:
I did this because I need many versions of class ``A``, which differ
only in the class variables, which are not known until run time.

Q: On the face of it, did I pick a reasonable solution to my problem?
If so is this a standard pattern? If not, can you mention a better
approach?

You have a class factory which subclasses an abstract class. Seems
perfectly reasonable to me. More than reasonable -- it sounds like a
*good* way of dealing with the problem.

 

[Jean-Michel Pichavant]

I have a class ``A`` that is intentionally incomplete:
it has methods that refer to class variables that do not exist.
The class ``A`` has several complicated methods, a number
of which reference the "missing" class variables.
Obviously, I do not directly use ``A``.

I have a class factory ``f``` that subclasses ``A`` *only* in
order to define the class variables.

The motivation/problem:
I did this because I need many versions of class ``A``,
which differ only in the class variables, which are not
known until run time.

Q: On the face of it, did I pick a reasonable solution to
my problem? If so is this a standard pattern? If not,
can you mention a better approach?

My solution is working for me, but the class ``A``
is bugging me, because of the odd (to me) way in
which it is incomplete. Obviously, I'm not a
computer science type ...

Thanks,
Alan Isaac

Your design is perfectly fine. A is an abstract class, aka interface class.
This is a very common pattern, that can solve many problems.

However, and this is a personal advice, try to declare all the required
attributes/methods in the abstract class, setting them to None or
raising a NotImplementedError. That would help anyone, including you, to
know what is required to define when subclassing A.

class A:
A_VALUE = None
def aMethod(self):
raise NotImplementedError()

FYI, there is a python module that provide some feature to enhance your
abstract classes: http://docs.python.org/library/abc.html. These are
more advanced features, you may just ignore that module for now.

JM

 

[Bill Felton]

For the record, in Python it is usual to refer to "attributes" rather
than "class variables" and "instance variables". In Python, classes are
first-class objects (pun not intended) like ints, strings, floats etc.,
and so a "class variable" would be a variable holding a class, just as a
string variable would be a variable holding a string, an int variable
holds an int, etc.

Being nit-picky, this is a slightly flawed justification of the terminology.
In Smalltalk, classes are first class objects (pun similarly not intended). Yet in Smalltalk we refer to class variables and instance variables.
These are not necessarily variables that 'hold' classes. In fact, all classes are instances, and so all variables hold instances...
So there's something not quite right about your 'first class objects ... so ... would be a ...'.
This may well be a standard Python convention, and it is certainly not objectionable. But it isn't well-justified on the basis of the 'first-class-ness' of classes as objects...

Best regards,
Bill