Subclassing by monkey-patching

[Jason]

I'm attempting to implement a recursive directory monitor based on the
GIO file monitor in PyGTK. My approach is basically to take the
gio.FileMonitor returned by the method gio.File.monitor_directory(),
connect to the "changed" signal, and add or remove monitors on create/
delete events for subdirectories.

I'd really like to do this by subclassing gio.FileMonitor. But the
problem I'm having is that it's never explicitly initialised in user
code (but somewhere in gio.File.monitor_directory() ). So there's no
point in just declaring a subclass — where would I actually create an
instance?

Is there a way I can write the subclass but then somehow... extend an
existing instance all at once rather than monkeypatch methods on one
by one? So I could take an existing instance of a FileMonitor and make
it an instance of my subclass? This would even allow me to override
the gio.File.monitor_directory() method to take the monitor returned
by the original method and decide whether to make it recursive based
on a parameter passed to monitor_directory().

Cheers,
Jason

PS. Asked a similar question on the pygtk list a few days ago:
http://www.daa.com.au/pipermail/pygtk/2010-September/018965.html

 

[Arnaud Delobelle]

Is there a way I can write the subclass but then somehow... extend an
existing instance all at once rather than monkeypatch methods on one
by one? So I could take an existing instance of a FileMonitor and make
it an instance of my subclass? This would even allow me to override
the gio.File.monitor_directory() method to take the monitor returned
by the original method and decide whether to make it recursive based
.... def __init__(self, x):
.... self.x = x
.... .... def x2(self):
.... return self.x**2
.... 1764

However, I've never really tried it so I don't know what ways it could
break.

HTH

 

[Peter Otten]

Is there a way I can write the subclass but then somehow... extend an
existing instance all at once rather than monkeypatch methods on one
by one? So I could take an existing instance of a FileMonitor and make
it an instance of my subclass? This would even allow me to override
the gio.File.monitor_directory() method to take the monitor returned
by the original method and decide whether to make it recursive based

... def __init__(self, x):
... self.x = x
...
... def x2(self):
... return self.x**2
...
1764

However, I've never really tried it so I don't know what ways it could
break.

I think this is fine for classes written Python but won't work here:
.... def whatever(self):
.... print 42
....Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: __class__ assignment: '__main__.GInotifyDirectoryMonitor'
deallocator differs from 'CC'

A possible alternative may be a class that wraps a FileMonitor instead of
subclassing it.

Peter

 

[Jason]

'C' will not necessarily be 'gio.FileMonitor' — I think the internals
of the GIO methods might further "subclass" it in some way depending
on what underlying monitors are available.

A possible alternative may be a class that wraps a FileMonitor instead of
subclassing it.

I've been avoiding this because it involves a lot of boilerplate: the
signals needs to be replicated and passed through, same for all
GObject properties, same for the usual methods. I'd basically have to
re-write the entire class in Python, and then tack on my methods.
Otherwise I have to write two sets of methods for anything that
touches this wrapped object.

Still, if it's the only way, sure.

— Jason

 

[Peter Otten]

'C' will not necessarily be 'gio.FileMonitor' — I think the internals
of the GIO methods might further "subclass" it in some way depending
on what underlying monitors are available.

That would only be relevant if it had worked, I think

I've been avoiding this because it involves a lot of boilerplate: the
signals needs to be replicated and passed through, same for all
GObject properties, same for the usual methods. I'd basically have to
re-write the entire class in Python, and then tack on my methods.
Otherwise I have to write two sets of methods for anything that
touches this wrapped object.

Still, if it's the only way, sure.

Does it have to be gio.FileMonitor? pyinotify can automatically add new
subdirectories out of the box.

Peter

 

[Jason]

Does it have to be gio.FileMonitor? pyinotify can automatically add new
subdirectories out of the box.

Well, since it's for a core part of the software, I'd like it to be
cross platform — not in the sense of Windows/Mac, but FreeBSD,
Solaris, etc. But it's looking more and more like I should give up
that particular goal.

Cheers,
Jason

 

[Jason]

But it's looking more and more like I should give up
that particular goal.

....buuuuut on the other hand I just knocked together a pyinotify
threaded watch system in about 50 lines. It's tempting to tell users
of other platforms to write their own and submit a patch. Maybe this
is all barking up the wrong tree.

Cheers,
Jason

 

[Bruno Desthuilliers]

Jason a écrit :

'C' will not necessarily be 'gio.FileMonitor' — I think the internals
of the GIO methods might further "subclass" it in some way depending
on what underlying monitors are available.


I've been avoiding this because it involves a lot of boilerplate: the
signals needs to be replicated and passed through, same for all
GObject properties, same for the usual methods.

Python is not Java !-)
http://docs.python.org/reference/datamodel.html#object.__getattr__

 

[Glazner]

Jason a écrit :




Python is not Java !-)http://docs.python.org/reference/datamodel.html#object.__getattr__

Yep, thats what i do...

def MySubclass(object):
def __init__(self):
self._ins = SomeObject()
def __getattr__(self,name):
return getattr(self._ins,name)