Get() and Set() convention in wxpython code

Hi list,
Lately I have been refactoring the code of a project, and I wanted to implement extensive use of Python properties. All my code uses Getters and Setters, from the wx classes and my own, so this seems to be no easy task.

I checked the wxPython coding guidelines to see if there was any comment regarding the use of Set and Get or properties, but it seems to be a bit outdated by now.

So my question is: is there a concensus/suggestion/opinion on the use of Set/Get versus Python properties?

If you have pure Python code, then properties are clearly the more
convenient method. The reason so much wx code uses Get and Set is
because it is interfacing with native code in C and C++, where the
concept of a property does not exist.

···

Leockard wrote:

      Lately I have been refactoring the code of a project, and I

wanted to implement extensive use of Python properties. All my
code uses Getters and Setters, from the wx classes and my own,
so this seems to be no easy task.

I checked the wxPython
coding guidelines
to see if there was any comment
regarding the use of Set and Get or properties, but it seems
to be a bit outdated by now.

      So my question is: is there a concensus/suggestion/opinion

on the use of Set/Get versus Python properties?

-- Tim Roberts, Providenza & Boekelheide, Inc.

timr@probo.com

The reason so much wx code uses Get and Set is because it is interfacing
with native code in C and C++, where the concept of a property does not
exist.

If this is the case, is there a guarantee that using attributes instead of
Get/Set in wx classes is functionally the same?

If the properties are there then they will behave the same as the
Get/Set methods.
In Phoenix all the getters/setters have properties, Robin was even
thinking of hiding them, see the comment at the end of:
Werner

···

Hi,

  On 2/23/2015 23:41, Leonardo Torres wrote:
            The reason so much

wx code uses Get and Set is because it is interfacing
with native code in C and C++, where the concept of a
property does not exist.

          If this is the case, is there a guarantee that using

attributes instead of Get/Set in wx classes is
functionally the same?

http://wiki.wxpython.org/ProjectPhoenix/ProjectGoals

Werner,
That’s what I was looking for. I’ll have to rewrite my code at some point then.
Thanks!

···
            The reason so much

wx code uses Get and Set is because it is interfacing
with native code in C and C++, where the concept of a
property does not exist.

          If this is the case, is there a guarantee that using

attributes instead of Get/Set in wx classes is
functionally the same?

Lately I have been refactoring the code of a project, and I wanted to
implement extensive use of Python properties. All my code uses Getters and
Setters, from the wx classes and my own, so this seems to be no easy task.
I checked the wxPython coding guidelines
<http://www.wxpython.org/codeguidelines.php&gt; to see if there was any
comment regarding the use of Set and Get or properties, but it seems to be
a bit outdated by now.

Indeed -- I'll bet a patch would be accepted, or you could add it here:

http://wiki.wxpython.org/wxPython%20Style%20Guide

I wrote that a long time ago -- before the properties were there.

I, for one, think the properties are more pythonic.

-Chris

···

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (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

In you link I found a comment by Anthony Glasser about get/set and properties, which I didn’t find before asking my question. I thought of adding a comment about Robin thinking of removing Get/Set altogether to be on the secure side. However, the page says it’s ‘immutable’ and I didn’t find how to edit it.

···

On Wed, Feb 25, 2015 at 10:26 PM, Chris Barker chris.barker@noaa.gov wrote:

You received this message because you are subscribed to a topic in the Google Groups “wxPython-users” group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/wxpython-users/4v7kJ0PzFks/unsubscribe.

To unsubscribe from this group and all its topics, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

      Lately I have been refactoring the code of a project, and I

wanted to implement extensive use of Python properties. All my
code uses Getters and Setters, from the wx classes and my own,
so this seems to be no easy task.

I checked the wxPython
coding guidelines
to see if there was any comment
regarding the use of Set and Get or properties, but it seems
to be a bit outdated by now.

Indeed – I’ll bet a patch would be accepted, or you could add it here:

http://wiki.wxpython.org/wxPython%20Style%20Guide

I wrote that a long time ago – before the properties were there.

I, for one, think the properties are more pythonic.

-Chris

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (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,

In you link I found a comment by Anthony Glasser about get/set and properties, which I didn't find before asking my question. I thought of adding a comment about Robin thinking of removing Get/Set altogether to be on the secure side.

I might have confused the issue here, I believe Robin was thinking of removing them, but then decided against removing them.

However, the page says it's 'immutable' and I didn't find how to edit it.

You need to login/have an account to change the wiki - there was too much spam without that and a reCaptcha protection.

Werner

···

On 2/26/2015 13:06, Leonardo Torres wrote:

Werner wrote:

In Phoenix all the getters/setters have properties,

Just FYI for those that like to know stuff like this, it's a mostly automated process, although some classes do need to have properties tweaked by hand. As the tweaker code is processing the API definitions for a module the classes are scanned and if there is a method name starting with "Get" that takes zero required parameters then a property is added to the class definition with the same name but with the "Get" removed. If there is a matching "Set" method that has just one required parameter then it is used as the setter for the property. There are some cases where there is already a method with the name that would have been used for a property, so there won't be a property generated for them.

I was a little reluctant at first to do it this way, but Kevin talked me into it and it has really worked out well. In almost all cases the auto-generated properties are exactly what is needed, and it has saved lots of development time.

···

--
Robin Dunn
Software Craftsman

There are some cases where there is already a method with the name that would have been used for a property, so there won’t be a property generated for them.

Just today I think I may have found two instances where the property didn’t work exactly as the Get/Set methods. If there is automated code that generates this duality, would it be possible for this code to also add a warning note in the documentation that signals when the property is not the same as the Get/Set methods?

···

On Fri, Mar 6, 2015 at 8:34 PM, Robin Dunn robin@alldunn.com wrote:

In Phoenix all the getters/setters have properties,
Werner wrote:

Just FYI for those that like to know stuff like this, it’s a mostly automated process, although some classes do need to have properties tweaked by hand. As the tweaker code is processing the API definitions for a module the classes are scanned and if there is a method name starting with “Get” that takes zero required parameters then a property is added to the class definition with the same name but with the “Get” removed. If there is a matching “Set” method that has just one required parameter then it is used as the setter for the property. There are some cases where there is already a method with the name that would have been used for a property, so there won’t be a property generated for them.

I was a little reluctant at first to do it this way, but Kevin talked me into it and it has really worked out well. In almost all cases the auto-generated properties are exactly what is needed, and it has saved lots of development time.

Robin Dunn

Software Craftsman

http://wxPython.org

You received this message because you are subscribed to a topic in the Google Groups “wxPython-users” group.

To unsubscribe from this topic, visit https://groups.google.com/d/topic/wxpython-users/4v7kJ0PzFks/unsubscribe.

To unsubscribe from this group and all its topics, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.