On Wed, 2005-06-22 at 18:45 +0200, Maik Hertha wrote:
> Gustavo J. A. M. Carneiro schrieb:
> 
> >
> >  No, but there aren't any "pygtk vs gtk properties".  PyGTK properties
> >would be == gtk properties: a direct mapping.  PyGTK would automagically
> >create python properties for each GObject property. 
> >
> Yes I understand. What is with style properties (rw and ro)
> 
> >I don't see what
> >you mean by "that could be handled at class level in the
> >__getattribute__ method".
> >  
> >
> The problems you described below.
> 
> >  Also please note that the use of __slot__ is bad as it impedes
> >defining new instance attributes in a subclass' __init__.
> >
> >  The problem I'm describing is not specific to PyGTK properties.  All
> >python properties have this problem, if not see:
> >
> >  This works:
> >------------------------------------
> >class Foo(object):
> >    def get_xxx(self):
> >        print "DO SOMETHING"
> >        return self.__xxx
> >    def set_xxx(self, val):
> >        print "DO SOMETHING ELSE"
> >        self.__xxx = val
> >
> >    #xxx = property(get_xxx, set_xxx)
> >
> >class Bar(Foo):
> >    def __init__(self):
> >        Foo.__init__(self)
> >        self.xxx = 123
> >
> >Bar()
> >------------------------------------
> >
> >  Now try uncommenting the xxx property definition.  Then you suddenly
> >get "DO SOMETHING ELSE" printed on the console.  For that reason,
> >label.text will not be supported; that is not even up for discussion.
> >Unless you know some trick that I don't to make this work.  But note
> >that custom workarounds in pygtk code for property X or Y don't count.
> >The code must remain absolutely generic.  If you upgrade gtk and not
> >pygtk, new properties may appear underneath you, and that is
> >intentional.
> >
> >  
> >
> Your suggestion could be broken too. What is if properties will be 
> removed in the upgraded gtk?

  Properties cannot be removed when upgrading gtk.  All gtk 2.x versions
are backwards API/ABI compatible.

> 
> >  So, it looks like now the only two candidates are label.props.text and
> >label.properties.text.  Regarding the use of 'properties', I'd like to
> >point out that it is difficult to write with correct spelling for
> >non-english native speakers, thus I prefer props.
> >
> >  Regards.
> >  
> >
> This is not clean. There could be a list of properties (like 
> get_properties in libxml2) but one property will be a prop, in my point 
> of view.

  label.props/label.properties would be a "properties container object".
You could print dir(label.props), for example.

  Cheers.

-- 
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
pygtk mailing list   [email protected]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Reply via email to