[142] in The GTK GIMP ToolKit mailing list archive
[gtk-list] Re: Python (was Re: Proposal for a new project)
daemon@ATHENA.MIT.EDU (Andreas Kostyrka)
Wed May 14 06:23:17 1997
Date: Wed, 14 May 1997 12:20:34 +0000 (GMT)
From: Andreas Kostyrka <andreas@ag.or.at>
To: gtk-list@redhat.com
In-Reply-To: <199705132107.RAA27058@lacrosse.redhat.com>
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com
On Tue, 13 May 1997, Michael K. Johnson wrote:
> Having seen sample code for PerlGtk, I can say that as it stands, I'm
> not sure I would want a direct translation. There's nothing intrinsically
> wrong with the PerlGtk bindings -- I'd just want a more completely
> object-oriented set of bindings. I'm only in the first stages of thinking
> about what I'd want in such a set of bindings, and I don't have any real
> ideas to offer here yet -- I just have a vague idea that I want the
> binding I use to be truly object-oriented and well tied into Python (better
> than PythonTk, definitely), and I want to be able to use them in code
Yep. But keep in mind, that speed is also important (I've got here a
15000+ line mini app in Python/Tkinter and speed bothers me.), so keep
the interface more on the C side.
> that looks compact; extra verbiage bothers me. I think that means
> exporting lots of symbols rather than using dictionaries['with', 'lots',
> 'of', 'text', 'strings'] and so on.
self['width']=avalue is not nice, but it's understandable if you
see that Tk is quite dynamic, so it's not feasable the override
__getattr__, because it could conflict with the actual python members
somewhere in the future :( But with gtk I've got the impression the stuff
is more managable, so a attribute based solution may be doable :)
Andreas
--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
