Properties

Hi,

I'm looking again at adding properties to the wx classes for all of the current gettter/setters that are in the classes, and would like to get some feedback from this group on a couple things.

* The first thing that needs to be resolved is a naming convention. I think that it should be easily predictable what the names of the properties are, and also that they are not likely to conflict with attributes that the programmer may have set in their derived classes. So I'm thinking that in in general (there will likely be exceptions to this rule) we'll just use the same name as the getter/setter with the "Get"/"Set" dropped. In other words, wx.Window will have properties like Size, ForegroundColour, Font, Sizer, etc. and wx.TextCtrl will have things like Value, InsertionPoint, etc.

* I'll be doing this for 2.7, but I'm wondering if the properties should be added in 2.6 as well. It's supposed to be a "stable" release series so the less rocking of the boat the better. Kevin O. has proposed making it optional in 2.6 by requiring the programmer to import a module that grafts new properties into the existing classes. This is doable but I think it is a bit messy because there would have to be additional modules for each of the non-core modules already in wxPython. Also adding them means that we would probably have to carry those modules forward into future releases even if they are just empty stubs that raise a deprecation warning.

Thoughts? Better ideas?

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Hi,

I'm looking again at adding properties to the wx classes for all of the current gettter/setters that are in the classes, and would like to get some feedback from this group on a couple things.

* The first thing that needs to be resolved is a naming convention. I think that it should be easily predictable what the names of the properties are, and also that they are not likely to conflict with attributes that the programmer may have set in their derived classes. So I'm thinking that in in general (there will likely be exceptions to this rule) we'll just use the same name as the getter/setter with the "Get"/"Set" dropped. In other words, wx.Window will have properties like Size, ForegroundColour, Font, Sizer, etc. and wx.TextCtrl will have things like Value, InsertionPoint, etc.

+1

* I'll be doing this for 2.7, but I'm wondering if the properties should be added in 2.6 as well. It's supposed to be a "stable" release series so the less rocking of the boat the better. Kevin O. has proposed making it optional in 2.6 by requiring the programmer to import a module that grafts new properties into the existing classes. This is doable but I think it is a bit messy because there would have to be additional modules for each of the non-core modules already in wxPython. Also adding them means that we would probably have to carry those modules forward into future releases even if they are just empty stubs that raise a deprecation warning.

Thoughts? Better ideas?

Push it off until 2.7

ka

···

On Jul 31, 2006, at 10:58 AM, Robin Dunn wrote:

Kevin Altis wrote:

Hi,

I'm looking again at adding properties to the wx classes for all of the current gettter/setters that are in the classes, and would like to get some feedback from this group on a couple things.

* The first thing that needs to be resolved is a naming convention. I think that it should be easily predictable what the names of the properties are, and also that they are not likely to conflict with attributes that the programmer may have set in their derived classes. So I'm thinking that in in general (there will likely be exceptions to this rule) we'll just use the same name as the getter/setter with the "Get"/"Set" dropped. In other words, wx.Window will have properties like Size, ForegroundColour, Font, Sizer, etc. and wx.TextCtrl will have things like Value, InsertionPoint, etc.

+1

Me too +1.

* I'll be doing this for 2.7, but I'm wondering if the properties should be added in 2.6 as well. It's supposed to be a "stable" release series so the less rocking of the boat the better. Kevin O. has proposed making it optional in 2.6 by requiring the programmer to import a module that grafts new properties into the existing classes. This is doable but I think it is a bit messy because there would have to be additional modules for each of the non-core modules already in wxPython. Also adding them means that we would probably have to carry those modules forward into future releases even if they are just empty stubs that raise a deprecation warning.

Thoughts? Better ideas?

Push it off until 2.7

Please wait until 2.7. For Dabo, we'll need to figure out what if any effect this will have on our Properties such as Font, Sizer, etc. I guess since our prop definitions are in subclasses of wx, they'd merely overwrite the wx ones, but that is kind of unfortunate as we are trying not to clobber the wx namespace.

···

On Jul 31, 2006, at 10:58 AM, Robin Dunn wrote:

--
Paul McNett
http://paulmcnett.com
http://dabodev.com

Hi all,

Kevin Altis wrote:

Hi,

I'm looking again at adding properties to the wx classes for all of the current gettter/setters that are in the classes, and would like to get some feedback from this group on a couple things.

* The first thing that needs to be resolved is a naming convention. I think that it should be easily predictable what the names of the properties are, and also that they are not likely to conflict with attributes that the programmer may have set in their derived classes. So I'm thinking that in in general (there will likely be exceptions to this rule) we'll just use the same name as the getter/setter with the "Get"/"Set" dropped. In other words, wx.Window will have properties like Size, ForegroundColour, Font, Sizer, etc. and wx.TextCtrl will have things like Value, InsertionPoint, etc.

+1

Me too +1.

* I'll be doing this for 2.7, but I'm wondering if the properties should be added in 2.6 as well. It's supposed to be a "stable" release series so the less rocking of the boat the better. Kevin O. has proposed making it optional in 2.6 by requiring the programmer to import a module that grafts new properties into the existing classes. This is doable but I think it is a bit messy because there would have to be additional modules for each of the non-core modules already in wxPython. Also adding them means that we would probably have to carry those modules forward into future releases even if they are just empty stubs that raise a deprecation warning.

Thoughts? Better ideas?

Push it off until 2.7

Please wait until 2.7. For Dabo, we'll need to figure out what if any effect this will have on our Properties such as Font, Sizer, etc. I guess since our prop definitions are in subclasses of wx, they'd merely overwrite the wx ones, but that is kind of unfortunate as we are trying not to clobber the wx namespace.

BTW, just to be clear, the method used for 2.6 would have no impact on existing code. To get properties in 2.6, you'd have to explicitly import them with a call such as "import wx.props" or "import wx.withprops as wx". Thus, no Dabo code would be affected in 2.6 regardless of what approach we take.

That said, thinking on it more, I think the only real reason for wanting 2.6 support for this is that 2.6 is probably what will be shipping with Leopard (OS X 10.5). I just thought it'd be nice if people didn't have to download/start using an unstable release to use props in wx. At the same time, it's true that just introducing it in 2.7 will be a simpler and smoother approach.

Regards,

Kevin

···

On Jul 31, 2006, at 12:13 PM, Paul McNett wrote:

On Jul 31, 2006, at 10:58 AM, Robin Dunn wrote:

--
Paul McNett
http://paulmcnett.com
http://dabodev.com

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org

Robin Dunn wrote:

I'm looking again at adding properties to the wx classes for all of the current gettter/setters that are in the classes

Why? I'm a big fan of the "pythonification" of wxPython, and also agree with Phillip J. Eby. that "Getters and setters are evil. Evil, evil, I say!" (from: http://dirtsimple.org/2004/12/python-is-not-java.html )

However, there is also a lot to be said for keeping compatibility with C++ wx. I know that translating MyWidget.GetSize to MyWidget.Size is pretty trivial, but it is another step. At least until we have a fully satisfactory "pure" wxPython docs, it's still a consideration.

Which brings up the point: I've been an advocate of creating a Pythonic layer around wx for years, yet haven't actually used any of the tools that do this (Dabo, PythonCard, Wax, Mindwrapper, ...) Why not? Well, honestly, i have given none of them a good look-see recently, but when I did, in every case, they just weren't complete, or didn't do what I needed (no sizers in PythonCard, at least for the first couple years, for instance). The fact that I can name four projects off the top of me head is another issue: I want something pretty standard.

So, that's my long winded introduction to the question:

Is this an attempt to move towards a more Pythonic API? If so, why not take this opportunity to really make substantive changes, rather than just name changes.

Paul McNett wrote:
> For Dabo, we'll need to figure out what if any
> effect this will have on our Properties such as Font, Sizer, etc.

That's a good example -- maybe the new wx.Windows.Font property should behave more like Dabo's Font property. (or like PythonCard or Wax or ...)

Maybe this is a good time to make a decision about the direction that the wxPython API is going. It would be great if we could adopt the design behind an existing project, or if none of those really can work, take the best ideas from all of them.

I know: I'm proposing a lot of work that I'm not going to do -- but I've always been full of ideas!

-Chris

Oh, and I'd just go with 2.7, why add confusion and extra magic code?

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Hi Chris,

Robin Dunn wrote:

I'm looking again at adding properties to the wx classes for all of the current gettter/setters that are in the classes

Why? I'm a big fan of the "pythonification" of wxPython, and also agree with Phillip J. Eby. that "Getters and setters are evil. Evil, evil, I say!" (from: http://dirtsimple.org/2004/12/python-is-not-java.html )

However, there is also a lot to be said for keeping compatibility with C++ wx. I know that translating MyWidget.GetSize to MyWidget.Size is pretty trivial, but it is another step.

What makes you think Robin is going to remove the Get/Set functions in 2.7? That would break all currently existing code, which would effectively lead to no one using 2.7. There's no reason that I can see that we can't support both.

At least until we have a fully satisfactory "pure" wxPython docs, it's still a consideration.

On the way, hopefully... Just this weekend I wrote up some code to read in the wx C++ docs, convert types and Pythonify args, convert the remaining HTML to ReST, and spit out SWIG DocString files for them. :slight_smile: Robin and I have been talking about the final approach we'll use for the docs, but I think we'll have the remaining issues (like the annoying SF throttle on the main wxPyDocs page) resolved fairly soon.

Which brings up the point: I've been an advocate of creating a Pythonic layer around wx for years, yet haven't actually used any of the tools that do this (Dabo, PythonCard, Wax, Mindwrapper, ...) Why not? Well, honestly, i have given none of them a good look-see recently, but when I did, in every case, they just weren't complete, or didn't do what I needed (no sizers in PythonCard, at least for the first couple years, for instance). The fact that I can name four projects off the top of me head is another issue: I want something pretty standard.

So, that's my long winded introduction to the question:

Is this an attempt to move towards a more Pythonic API? If so, why not take this opportunity to really make substantive changes, rather than just name changes.

This is just my take on it, but fairly realistic (and mostly automated) changes tend to get done, whereas major reworks involving lots of time, design work and effort tend to get talked about, a lot in fact, but rarely done.

Paul McNett wrote:
> For Dabo, we'll need to figure out what if any
> effect this will have on our Properties such as Font, Sizer, etc.

That's a good example -- maybe the new wx.Windows.Font property should behave more like Dabo's Font property. (or like PythonCard or Wax or ...)

Maybe this is a good time to make a decision about the direction that the wxPython API is going.

I personally am far more interested in who is going to take it there. :slight_smile:

I think it's great to talk about improvements, but let's stick to talking about things someone's actually going to do. I've heard so many "next generation" discussions, and the one thing almost all of them have in common is that they never actually result in anything. I'd rather be spending time improving wxPython than talking about what someone might want to do someday to improve wxPython or somehow make it radically better. When it comes to brainstorming on improvements, there is literally no end to it - when will wxPython be so perfect that we'll run out of ideas on where to take it?

The bottom line is that we can't take it anywhere unless someone's going to take it there. (Aside from Robin, of course, who already bears pretty much the whole project on his shoulders!) Sorry if that sounds cynical, but I prefer the term "realistic". We have limited time and resources, so let's make the best of them.

Regards,

Kevin

···

On Jul 31, 2006, at 2:06 PM, Christopher Barker wrote:

It would be great if we could adopt the design behind an existing project, or if none of those really can work, take the best ideas from all of them.

I know: I'm proposing a lot of work that I'm not going to do -- but I've always been full of ideas!

-Chris

Oh, and I'd just go with 2.7, why add confusion and extra magic code?

--
Christopher Barker, Ph.D.
Oceanographer
                                        
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org

Hi Chris,

Robin Dunn wrote:

I'm looking again at adding properties to the wx classes for all of the current gettter/setters that are in the classes

Why? I'm a big fan of the "pythonification" of wxPython, and also agree with Phillip J. Eby. that "Getters and setters are evil. Evil, evil, I say!" (from: http://dirtsimple.org/2004/12/python-is-not-java.html )

However, there is also a lot to be said for keeping compatibility with C++ wx. I know that translating MyWidget.GetSize to MyWidget.Size is pretty trivial, but it is another step.

What makes you think Robin is going to remove the Get/Set functions in 2.7? That would break all currently existing code, which would effectively lead to no one using 2.7. There's no reason that I can see that we can't support both.

Yeah the C++ API can't ever go away at this point. It is more important that wxPython have reasonable API compatibility with older versions of wxPython and wxWidgets than a brand new API that is somehow more pythonic.

Which brings up the point: I've been an advocate of creating a Pythonic layer around wx for years, yet haven't actually used any of the tools that do this (Dabo, PythonCard, Wax, Mindwrapper, ...) Why not? Well, honestly, i have given none of them a good look-see recently, but when I did, in every case, they just weren't complete, or didn't do what I needed (no sizers in PythonCard, at least for the first couple years, for instance). The fact that I can name four projects off the top of me head is another issue: I want something pretty standard.

So, that's my long winded introduction to the question:

Is this an attempt to move towards a more Pythonic API? If so, why not take this opportunity to really make substantive changes, rather than just name changes.

This is just my take on it, but fairly realistic (and mostly automated) changes tend to get done, whereas major reworks involving lots of time, design work and effort tend to get talked about, a lot in fact, but rarely done.

Having worked on a simpler API, helpers such as auto-event binding, and other items on and off since 2001 I'm pretty comfortable saying that I don't think we'll ever do a purely pythonic API for wxPython from scratch. It is actually a good thing that multiple projects are doing different simplification layers. The ones that don't survive either missed the mark and even if they didn't we can check out what they attempted and borrow from them. The ones like dabo and PythonCard that are healthy projects can borrow from each other as required for their different audiences.

Things like properties which were in PythonCard from the beginning used to be a major complication and pain to support. Now they are a breeze and have no negative impact on the underlying getter/setter methods for a wrapper like wxPython. The main thing we have to worry about is breaking existing code. I understand the import suggestion Kevin made but on general principle I would rather we avoid adding features in 2.6.

ka

···

On Jul 31, 2006, at 4:44 PM, Kevin Ollivier wrote:

On Jul 31, 2006, at 2:06 PM, Christopher Barker wrote:

What makes you think Robin is going to remove the Get/Set functions in 2.7?

I didn't mean that, but I assume the goal is to deprecate them in same fashion. if not, then it's really just cluttering the namespace.

Yeah the C++ API can't ever go away at this point. It is more important that wxPython have reasonable API compatibility with older versions of wxPython and wxWidgets than a brand new API that is somehow more pythonic.

Can we have both?

This is just my take on it, but fairly realistic (and mostly automated) changes tend to get done, whereas major reworks involving lots of time, design work and effort tend to get talked about, a lot in fact, but rarely done.

Quite true. But in fact, PythonCard and Dabo are projects that are getting done. They are wrappers, rather than re-works, but that's a fine way to ease the transition.

It is actually a good thing that multiple projects are doing different simplification layers. The ones that don't survive either missed the mark and even if they didn't we can check out what they attempted and borrow from them.

Well, diversity vs. wasted resources is a trade-off. Having could healthy projects around is good, but many more, and it's just spreading the work too thin.

The ones like dabo and PythonCard that are healthy projects can borrow from each other as required for their different audiences.

Are the audiences really that different? I'd suspect they overlap a LOT. Indeed, I don't think either one restricts you, and therefore any of us could be using either one. It's probably a taste issue more.

I understand the import suggestion Kevin made but on general principle I would rather we avoid adding features in 2.6.

I agree with that. Remember the 2.5 series -- there were a lot of changes (most for good reason), but it did sully wxPython's reputation.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov