On Tuesday 15 June 2010 17:43:03 Sivan Greenberg wrote: > On Tue, Jun 15, 2010 at 11:25 PM, Hugo Parente Lima > > <[email protected]> wrote: > > "foo" is a bool, so the getter can be "isFoo" or "hasFoo", it depends on > > the meaning of "foo". So the name clashes probably can occur only on > > boolean properties where the, getter name is different from the property > > name. But the Qt API was specially crafted to avoid these clashes, > > anyway if they occur we can > > just rename the property or method to the better name available to avoid > > the name clash and continue with a pythonic API. > > Can you please give an example for when such name clash would occur ? > Also, what would be considered a "better name" for the property?
I didn't found one yet, but imagine QWidget, is has a property called focus, the getter is "hasFocus" and the setter is "setFocus", so QWidget could have a method called "focus()" (but it doesn't have), so it would cause a name clash, to solve it you can rename the property or the method name. What is a "better name" is somewhat a bit subjective, in my hypothetical use case I would rename the method "focus()" to "setFocus()" :-) Hopefully I did find a name clash yet in Qt. > > Compatibility > > ============= > > > > The proposed API is incompatible with the known PySide and PyQt API, but > > since PySide is not yet widely used and hasn't reached version 1.0.0, it > > seems reasonable to break compatibility for the sake of getting PySide > > "right". > > I also think it makes sense to break things now, but maybe we could > provide an intermediate release that would be backward compatible to > the getters and setters a'la QT (albeit quite artificial for > Pythoneers) and after much of the code been ported, then cut the > support. I known that break compatibility is always a bad thing and do it often could ruin the project, but never do it would freeze us forever in the past, so we just need to do the changes in the right time before getting too late, and I guess the right time is just now before the 1.0 release which IMO is not so far away. > Now, thinking of the QT approach, I know this would be a nice to have > for people keen on the dynamic nature of Python, however, is it really > worth the trouble? That is, I feel the Qt's approach contribute much > to its nice flowing and structured developed and we might just be fine > preserving it in PySide, although compromising on the Pythonicity of > it? I'm sure that Qt doesn't use properties for one single reason, they doesn't exists in standard C++, just in some compiler extensions like Borland C++. > Really just my 2c. :-) > > Sivan -- Hugo Parente Lima INdT - Instituto Nokia de Tecnologia
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ PySide mailing list [email protected] http://lists.openbossa.org/listinfo/pyside
