Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #111127
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Newsgroups | comp.lang.python |
| Subject | Re: Making Classes Subclassable |
| Date | 2016-07-05 08:52 -0600 |
| Message-ID | <mailman.100.1467730382.2295.python-list@python.org> (permalink) |
| References | <ca1ee22e-9769-4e76-81f3-b9d0dcb55212@googlegroups.com> <87eg79q1i0.fsf@handshake.de> <CALwzidkULYyspVyr3ZWSCrM9qVYZzdU3tOzRntyLxjUQ9aQSew@mail.gmail.com> |
On Mon, Jul 4, 2016 at 1:57 AM, dieter <dieter@handshake.de> wrote:
> Lawrence D’Oliveiro <lawrencedo99@gmail.com> writes:
>
>> Some of the classes in Qahirah, my Cairo binding <https://github.com/ldo/qahirah> I found handy to reuse elsewhere, for example in my binding for Pixman <https://github.com/ldo/python_pixman>. Subclassing is easy, but then you need to ensure that operations inherited from the superclass return instances of the right class. This means that superclass methods must never refer directly to the class by name for constructing new objects; they need to obtain the current class by more indirect means.
>
> --> "type(obj)" or "obj.__class__" (there are small differences)
> give you the type/class of "obj".
Another option is a classmethod factory:
class X:
@classmethod
def new(cls, *args, **kwargs):
return cls(*args, **kwargs)
def method(self):
return self.new()
class Y(X): pass
Y().method() will return a new Y instance. There's not a lot of reason
to prefer this over type(self)(), but by overriding the classmethod
you can have subclasses that use different signatures in the
constructor but still support the same signature in the factory for
compatibility with the base class. You can also make the classmethod
private, if you wish.
Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread
Making Classes Subclassable Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-02 21:31 -0700
Re: Making Classes Subclassable dieter <dieter@handshake.de> - 2016-07-04 09:57 +0200
Re: Making Classes Subclassable Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-04 01:34 -0700
Re: Making Classes Subclassable Michael Selik <michael.selik@gmail.com> - 2016-07-05 05:26 +0000
Re: Making Classes Subclassable Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-05 00:08 -0700
Re: Making Classes Subclassable dieter <dieter@handshake.de> - 2016-07-05 09:55 +0200
Re: Making Classes Subclassable Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-07-05 18:31 +1000
Re: Making Classes Subclassable Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-05 08:41 -0600
Re: Making Classes Subclassable Steven D'Aprano <steve@pearwood.info> - 2016-07-06 01:33 +1000
Re: Making Classes Subclassable Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-05 09:02 -0600
Re: Making Classes Subclassable Steven D'Aprano <steve@pearwood.info> - 2016-07-06 01:41 +1000
Re: Making Classes Subclassable Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-05 19:31 -0700
Re: Making Classes Subclassable Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-07-05 20:04 -0700
Re: Making Classes Subclassable Ian Kelly <ian.g.kelly@gmail.com> - 2016-07-05 08:52 -0600
csiph-web