Re: Proposal fort GTK bindings



>>>>> "Arun" == Arun Sharma <asharma@netscape.com>
>>>>> wrote the following on 04 Nov 1997 10:45:23 -0800

Arun> On Tue, 04 Nov 1997 15:08:30 +0100, Michael Lausch wrote:
m> I poropose the following archtiecture of the GTK pYthon bindings.

m> provide bindings for all the GTK functions in a gtk module.

Arun> This is what Neil has done in his SWIG based bindings. I was
Arun> trying to save a function call in not doing it:

Arun> Gtk.Button("foo") {Python} ->
Arun> gtk.gtk_button_new_with_label("foo") {Python} ->
Arun> gtk_button_new_with_label("foo") {C}

Arun> is slower than

Arun> gtk.button("foo") -> gtk_button_new_with_label("foo")

Arun> I don't know if the savings will be significant, but I didn't
Arun> think that not going with SWIG would introduce a huge
Arun> implementation penalty.

m> Build a python class hierarchy using these functions in the Gtk
m> module.

Arun> The class hierarchy would be relatively flat for now. I don't
Arun> think there is a need to expose abstract classes in gtk (gtk_box
Arun> for example) in Python.

Arun> However, object oriented principles have been used in that:

Arun> both gtk.vbox.pack() gtk.hbox.pack() eventually translate to
Arun> gtk_box_pack_start().

Arun> Of course, any new classes which add extra functionality to
Arun> these classes would form a class hierarchy.

m> The user should only access to Gtk module.

Arun> Certainly.

m> Why now implement the class hierarchy in C? Because it's not
m> possible, without overhead, to inherit from C defines classes.

Arun> Could you please elaborate ?

Well, classes and extension types are two different things in
Python. Everything written in C (or another programming language) is
an Extension Type. Classes written in Python are, of course, classes.

You can't inherit from extension types.

Suppose you have a class in C called gtk_button. Thene the following
Python code will not work:

class QuitButton(gtk_button):
	def __init__(self, .....):
.....

Your only chance to use inheritance in Python is to do something like
this:

class QuitButton:
	def __init__(self, ....):
		self.instance = gtk.button();
	def show(self):
		self.instance.show();
.....

This means that the savings of a function call in you first example
are not here any more. Of course, without using a Python class
hierarchy, then your proposal (and implementation)  wins. But as soon
as subclassing is requested by the user, the same overhead is here again.

There exists an implementation done by Jim Fulton which allows you to
inherit from extension types. I have no idea how good, stable,fast
this mechanism is, but it's available at:
<http://www.digicool.com/releases/ExtensionClass/>


Arun> 	-Arun

Arun> [ CC'ed to gtk-list so that more people can take part in the
Arun> discussion]

Also Cc: to gtk-list (which i just subscribed, hopefully)
Arun> -- #include <stddisclaimer.h>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]