Hi. Can someone advise of the future of PEP8 naming strategies for wxpython. I have generally started to get my code to conform to this standard and wondering whether this will be implemented for wxpython. Though it would be a significant change, are there any thoughts about moving forward with this to bring wxpython to standard with other modules.
I realize that many packages are still not compliant but the general direction seems to be toward standardization. I also recognize that there has been an effort for standardizing syntax for wiki contributions.
Hi. Can someone advise of the future of PEP8 naming strategies for wxpython. I have generally started to get my code to conform to this standard and wondering whether this will be implemented for wxpython. Though it would be a significant change, are there any thoughts about moving forward with this to bring wxpython to standard with other modules.
I realize that many packages are still not compliant but the general direction seems to be toward standardization. I also recognize that there has been an effort for standardizing syntax for wiki contributions.
It's possible that some changes can be made for 3.0. That is when some big (and probably incompatible) changes will likely be happening in wxWidgets, and so since we will be breaking things anyway that would be a good time to migrate some aspects of wxPython to be more standards compliant and perhaps to remove some other warts as well. That said, I highly dislike names_with_underscores and so will probably not go that far, but I do like leadingLowerCaseNames.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Yeah, there was quite the discussion in the python-dev mailing list in
regards to whether words_with_underscores was more readable than
StudlyCaps. Some international users find reading
words_with_underscores easier to read than StudlyCaps, which is
basically why they went with it. I'm personally of the opinion that we
should attempt to break as little code as possible, and to try to be
consistant across all of wxPython - which is why I prefer StudlyCaps for
wxPython.
- Josiah
···
Robin Dunn <robin@alldunn.com> wrote:
David Pratt wrote:
> Hi. Can someone advise of the future of PEP8 naming strategies for
> wxpython. I have generally started to get my code to conform to this
> standard and wondering whether this will be implemented for wxpython.
> Though it would be a significant change, are there any thoughts about
> moving forward with this to bring wxpython to standard with other modules.
>
> I realize that many packages are still not compliant but the general
> direction seems to be toward standardization. I also recognize that
> there has been an effort for standardizing syntax for wiki contributions.
It's possible that some changes can be made for 3.0. That is when some
big (and probably incompatible) changes will likely be happening in
wxWidgets, and so since we will be breaking things anyway that would be
a good time to migrate some aspects of wxPython to be more standards
compliant and perhaps to remove some other warts as well. That said, I
highly dislike names_with_underscores and so will probably not go that
far, but I do like leadingLowerCaseNames.
leadingLowerCaseNames for methods might help with the Java people migrating to Python.
One of the things I did like about Java was the overall consistency of the API. We will never have this on Python but… we could have it in wxPython.
One other thing I would really like to see is the elimination of Get/Set methods by using properties
Hmm... did they also prefer ALL_CAPITALS_WITH_UNDERSCORES as being
easier to read, too? They'd love raw wxPython, then, with that
pervasive use of such yummy code throughout.
···
On 2/19/06, Josiah Carlson <jcarlson@uci.edu> wrote:
Yeah, there was quite the discussion in the python-dev mailing list in
regards to whether words_with_underscores was more readable than
StudlyCaps. Some international users find reading
words_with_underscores easier to read than StudlyCaps, which is
basically why they went with it.
ALL_CAPS_WITH_UNDERSCORES was seen as being difficult to type as well as
annoying to read to basically everyone who chimed in.
Except for the various Get/Set methods on wxPython, I think the style is
pretty nice. I've never tried manipulating properties in a subclass, so
I don't know if that kind of thing is usable or not, or whether wxPython
should rely on them.
- Josiah
···
"Peter Decker" <pydecker@gmail.com> wrote:
On 2/19/06, Josiah Carlson <jcarlson@uci.edu> wrote:
> Yeah, there was quite the discussion in the python-dev mailing list in
> regards to whether words_with_underscores was more readable than
> StudlyCaps. Some international users find reading
> words_with_underscores easier to read than StudlyCaps, which is
> basically why they went with it.
Hmm... did they also prefer ALL_CAPITALS_WITH_UNDERSCORES as being
easier to read, too? They'd love raw wxPython, then, with that
pervasive use of such yummy code throughout.