Hi everyone,
If wxPython-dev is making a brand new revolutionary version of wxPython, then why not take this opportunity to make all the methods be in lowercase with underscores, like is the norm in Python packages, rather than in CamelCase like it is now? It’s going to be harder to do that later, so there might not be another opportunity like this for years or decades.
Thanks,
Ram.
Hi,
Hi everyone,
If wxPython-dev is making a brand new revolutionary version of wxPython, then why not take this opportunity to make all the methods be in lowercase with underscores, like is the norm in Python packages, rather than in CamelCase like it is now? It’s going to be harder to do that later, so there might not be another opportunity like this for years or decades.
I can see three fundamental reasons:
because that will break millions of lines of code of existing wxPython applications.
because most of wxPython is based on wxWidgets, and they use CamelCase naming convention and it’s so much easier to write and test the wrappers.
because the method_name convention is just a recommendation from PEP8, not a dogma or a syntax error.
The usual question arises: are the benefits of such a change so huge to offset the large effort to actually implement it?
Andrea.
On Wednesday, June 17, 2015, Ram Rachum ram.rachum@gmail.com wrote:
Thanks,
Ram.
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Thanks for the answers, Boštjan and Andrea.
Regarding backward compatibility, I’ll say two things:
I agree it’s important, but I figure since wxPython is making the transition from 2 to 3, it’s considered acceptable to break backward compatibility. Consider that wxPython breaks backward compatibility in small ways in even minor releases, which is frowned upon in other software projects like Python. So a major version change is the biggest opportunity for changing the naming convention that wxPython is ever going to get.
If this change will be made, you could still provide camelCase aliases for the lowercase methods, so old code won’t break, but show a DeprecationWarning when people use the camelCase aliases and then fully remove them only in a future release, further reducing the burden.
I figure that people program in wxPython when they’re more connected to Python, and they want a GUI toolkit, rather than coming from the wxWidgets angle and choosing Python for some reason. So I think people are more likely to care about Python conventions than wxWidgets conventions
Regarding Andrea’s question of “why”. Lots of people in the Python community care about it, (which is why 95% of the open-source Python packages follow this rule) and I personally care deeply about it. When code is written to conform to accepted conventions it’s easier to scan it quickly and understand it because everything looks like you expect it to look. We’re very used to seeing a CamelCase name and assuming it’s a class, so when working with wxPython code it’s always annoying to see camelCase methods.
But yes, I understand why some people would see this as a weak reason. There are probably more reasons I could think of for why code conventions are important, but if the decision is to stay with camelCase, I guess that’s that.
On Wed, Jun 17, 2015 at 9:14 PM, Boštjan Mejak bostjan.xperia@gmail.com wrote:
That’s because wxPython is based on wxWidgets, and wxWidgets’ coding style is in CamelCase for classes and camelCase for functions/methods. wxPython is created from wxWidgets’ code base using SWIG and so wxWidgets’ coding style in wxPython is the same.
On Jun 17, 2015 7:49 PM, “Ram Rachum” ram.rachum@gmail.com wrote:
Hi everyone,
If wxPython-dev is making a brand new revolutionary version of wxPython, then why not take this opportunity to make all the methods be in lowercase with underscores, like is the norm in Python packages, rather than in CamelCase like it is now? It’s going to be harder to do that later, so there might not be another opportunity like this for years or decades.
Thanks,
Ram.
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
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/oo-zaDFGPiA/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.
Wasn’t dropping SWIG one of the bullet points in Phoenix? I remember seeing SIP recently when using wxPython code. So does Phoenix use SWIG?
On Wed, Jun 17, 2015 at 10:17 PM, Boštjan Mejak bostjan.xperia@gmail.com wrote:
Since wxPython is created automatically (using SWIG), there’s no human intervention here.
wxWidgets is written in C++ which uses CamelCase. And because of this, wxPython (created automatically), of course, comes with the same name form for classes and functions/methods. That’ll never change.
On Jun 17, 2015 8:47 PM, “Ram Rachum” ram@rachum.com wrote:
Thanks for the answers, Boštjan and Andrea.
Regarding backward compatibility, I’ll say two things:
- I agree it’s important, but I figure since wxPython is making the transition from 2 to 3, it’s considered acceptable to break backward compatibility. Consider that wxPython breaks backward compatibility in small ways in even minor releases, which is frowned upon in other software projects like Python. So a major version change is the biggest opportunity for changing the naming convention that wxPython is ever going to get.
- If this change will be made, you could still provide camelCase aliases for the lowercase methods, so old code won’t break, but show a DeprecationWarning when people use the camelCase aliases and then fully remove them only in a future release, further reducing the burden.
- I figure that people program in wxPython when they’re more connected to Python, and they want a GUI toolkit, rather than coming from the wxWidgets angle and choosing Python for some reason. So I think people are more likely to care about Python conventions than wxWidgets conventions
Regarding Andrea’s question of “why”. Lots of people in the Python community care about it, (which is why 95% of the open-source Python packages follow this rule) and I personally care deeply about it. When code is written to conform to accepted conventions it’s easier to scan it quickly and understand it because everything looks like you expect it to look. We’re very used to seeing a CamelCase name and assuming it’s a class, so when working with wxPython code it’s always annoying to see camelCase methods.
But yes, I understand why some people would see this as a weak reason. There are probably more reasons I could think of for why code conventions are important, but if the decision is to stay with camelCase, I guess that’s that.
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
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/oo-zaDFGPiA/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.
On Wed, Jun 17, 2015 at 9:14 PM, Boštjan Mejak bostjan.xperia@gmail.com wrote:
That’s because wxPython is based on wxWidgets, and wxWidgets’ coding style is in CamelCase for classes and camelCase for functions/methods. wxPython is created from wxWidgets’ code base using SWIG and so wxWidgets’ coding style in wxPython is the same.
On Jun 17, 2015 7:49 PM, “Ram Rachum” ram.rachum@gmail.com wrote:
Hi everyone,
If wxPython-dev is making a brand new revolutionary version of wxPython, then why not take this opportunity to make all the methods be in lowercase with underscores, like is the norm in Python packages, rather than in CamelCase like it is now? It’s going to be harder to do that later, so there might not be another opportunity like this for years or decades.
Thanks,
Ram.
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
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/oo-zaDFGPiA/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.
Okay, but it’s possible to make a simple algorithm to automatically convert CamelCase to lower_case. No human intervention needed.
On Wed, Jun 17, 2015 at 10:17 PM, Boštjan Mejak bostjan.xperia@gmail.com wrote:
Since wxPython is created automatically (using SWIG), there’s no human intervention here.
wxWidgets is written in C++ which uses CamelCase. And because of this, wxPython (created automatically), of course, comes with the same name form for classes and functions/methods. That’ll never change.
On Jun 17, 2015 8:47 PM, “Ram Rachum” ram@rachum.com wrote:
Thanks for the answers, Boštjan and Andrea.
Regarding backward compatibility, I’ll say two things:
- I agree it’s important, but I figure since wxPython is making the transition from 2 to 3, it’s considered acceptable to break backward compatibility. Consider that wxPython breaks backward compatibility in small ways in even minor releases, which is frowned upon in other software projects like Python. So a major version change is the biggest opportunity for changing the naming convention that wxPython is ever going to get.
- If this change will be made, you could still provide camelCase aliases for the lowercase methods, so old code won’t break, but show a DeprecationWarning when people use the camelCase aliases and then fully remove them only in a future release, further reducing the burden.
- I figure that people program in wxPython when they’re more connected to Python, and they want a GUI toolkit, rather than coming from the wxWidgets angle and choosing Python for some reason. So I think people are more likely to care about Python conventions than wxWidgets conventions
Regarding Andrea’s question of “why”. Lots of people in the Python community care about it, (which is why 95% of the open-source Python packages follow this rule) and I personally care deeply about it. When code is written to conform to accepted conventions it’s easier to scan it quickly and understand it because everything looks like you expect it to look. We’re very used to seeing a CamelCase name and assuming it’s a class, so when working with wxPython code it’s always annoying to see camelCase methods.
But yes, I understand why some people would see this as a weak reason. There are probably more reasons I could think of for why code conventions are important, but if the decision is to stay with camelCase, I guess that’s that.
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
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/oo-zaDFGPiA/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.
On Wed, Jun 17, 2015 at 9:14 PM, Boštjan Mejak bostjan.xperia@gmail.com wrote:
That’s because wxPython is based on wxWidgets, and wxWidgets’ coding style is in CamelCase for classes and camelCase for functions/methods. wxPython is created from wxWidgets’ code base using SWIG and so wxWidgets’ coding style in wxPython is the same.
On Jun 17, 2015 7:49 PM, “Ram Rachum” ram.rachum@gmail.com wrote:
Hi everyone,
If wxPython-dev is making a brand new revolutionary version of wxPython, then why not take this opportunity to make all the methods be in lowercase with underscores, like is the norm in Python packages, rather than in CamelCase like it is now? It’s going to be harder to do that later, so there might not be another opportunity like this for years or decades.
Thanks,
Ram.
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
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/oo-zaDFGPiA/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.
I can, but not like you said because the point is to do it for the methods, not classes. It’s a bit more complex but doable. But then I’m diverging from wxPython. What I’d really want is for wxPython to change to lower_case. But yeah, I understand that other people may have different opinions.
On Wed, Jun 17, 2015 at 10:38 PM, Boštjan Mejak bostjan.xperia@gmail.com wrote:
For the time being, you can make an alias for the classes and functions/methods you use in your Python script. Like this:
import wx.adv.TaskBarIcon as task_bar_icon
–
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/oo-zaDFGPiA/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.
like is the norm in Python packages
Hahahah right. You mean like in os.makedirs, or threading.Thread.setDaemon, or half of the standard library that doesn’t follow this particular style ? My own preference goes to lowerCamelCase but I’m not in the mood for trolling.
Best regards
Jérôme Laheurte
Very few Python packages use camelCase for methods. But they exist. The setDaemon example you gave was deprecated in Python 2.6, which was released 7 years ago. It’s true that many Python names don’t have underscores, which upsets me. But it’s still better than camelCase for methods.
On Thu, Jun 18, 2015 at 12:55 AM, Jérôme Laheurte fraca7@gmail.com wrote:
like is the norm in Python packages
Hahahah right. You mean like in os.makedirs, or threading.Thread.setDaemon, or half of the standard library that doesn’t follow this particular style ? My own preference goes to lowerCamelCase but I’m not in the mood for trolling.
Best regards
Jérôme Laheurte
–
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/oo-zaDFGPiA/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.
Very few Python packages use camelCase for methods.
This statement is as gratuitous as mine was. Which is kind of the point.
But they exist. The setDaemon example you gave was deprecated in Python 2.6, which was released 7 years ago. It's true that many Python names don't have underscores, which upsets me. But it's still better than camelCase for methods.
YMMV. Underscores upset me. CamelCase upsets me. What’s « better » is neither for me nor you to decide.
Best regards
Jérôme Laheurte
Le 17 juin 2015 à 23:59, Ram Rachum <ram@rachum.com> a écrit :
Ram Rachum wrote:
Okay, but it's possible to make a simple algorithm to automatically
convert CamelCase to lower_case. No human intervention needed.
If you do that, you have a documentation problem as well. Today, you
can get 90% of what you need from the wxWidgets documentation, without
using the Python-specific versions. With your change, the human mind
would have to do a translation.
There is NOT universal agreement that lower_case is the One True Way.
There are suggested coding standards, that's all. Given that, it is
just ridiculous to consider this kind of upheaval, when there are still
a large number of real issues to be solved.
I often disagree with Boštjan, but in this case he's right. This will
never change.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
Since wxPython is created automatically (using SWIG),
That is for classic only, Phoenix is using SIP by default.
there's no human intervention here.
I understand it required a lot of manual work, at least for the initial creation of a wrapping of a particular widget.
wxWidgets is written in C++ which uses CamelCase. And because of this, wxPython (created automatically), of course, comes with the same name form for classes and functions/methods. That'll never change.
Never in an IT project is a strong word:).
But I agree I don't think that will happen, unless someone steps up having the interest for this change and doing the actual work.
The tool set for wxPython Phoenix is changed and if I understand it correctly it is a lot more automated, see:
http://wiki.wxpython.org/ProjectPhoenix/DevelopmentProcess
Werner
On 6/17/2015 21:17, Boštjan Mejak wrote:
I really don’t understand this thread. Camel or not its only a convention, the code will work with whatever convention the dev will going to use.
Dev need to center in design and create apps. Dev can code in any language.
Enviado desde mi LG G3
El 18/06/2015 04:03, “Boštjan Mejak” bostjan.xperia@gmail.com escribió:
I actually find my_variable and my_function and my_class code style ugly as hell. I prefer myVariable and myFunction and MyClass code style over that shitty underscoring one.
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.