Use CamelCase syntax for all classesSee original GitHub issue
I would like to change the syntax of all the classes to use CamelCase, as this is how it should be for modern Python.
I started a pull request for this: https://github.com/gccxml/pygccxml/pull/89
Technically there is nothing really difficult here. There is just a choice to be made for our two main classes describing the different declarations and types:
I was thinking renaming them to
D is for the declaration hierarchy, the
T is for the type
hierarchy. This would lead to (for example):
On reason is to have something in the name that easily allows to see to what class hierarchy the class belongs to. One another reason is that I can not have a
Type class (
type is a reserved keyword in Python.
Type would be fine but I would like to avoid confusions between the lowercase/uppercase version).
- should it be
Tsuffix for all other classes
- Should we keep the old syntax around for the 2.0 release. I could do something like this: https://github.com/gccxml/pygccxml/pull/89/files#diff-f3ca1b6d15eb0878707ef50fcfa65c30R15 I was thinking about wrapping this with a deprecation warning, but I am worried performance could take a hit if a lit of warnings need to be printed … so I would prefer to remove the old syntax for 2.0. If people want to keep the old syntax, they can stay on 1.9.0
- Created 6 years ago
- Comments:5 (4 by maintainers)
Top GitHub Comments
I saw the branch few weeks ago and frankly I don’t know how to receive it or express gently my thoughts. pygccxml coding convention was born in order to make C++ developers feel comfortable with it. Not Python one, but C++. C++ developers was my main target. C++ has codding convention - std/boost libraries. For example - many names in “type traits” functionality are very similar/identical to C++. This is one point of view, another one current users. Why do you want to hurt them? Consider OMPL (https://github.com/gccxml/pygccxml/issues/56) py++/pygccxml performance issues. How many time/effort will be spent just to change the convention and for what? There are few project like it. For those projects investing time into “renaming” is a pure waste of time. Saying that, I understand your desire to make the package to be “Pythonic”. I also understand that in open source & free project it is very important to enjoy from it. May be you need/want to consider to provide “py2to3” like conversion script. So the transition will be “semi/fully” automated. I will test such script on my projects.
Abandoning this idea for the moment. Got stuck with other projects, and I have not so much time anymore to take care of pygccxml. So I do not want to generate more work than needed.