Use CamelCase syntax for all classes
See original GitHub issueI 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: type_t
and declaration_t
.
I was thinking renaming them to DeclarationD
and TypeT
. The D
is for the declaration hierarchy, the T
is for the type hierarchy
. This would lead to (for example): EnumerationD
and ShortIntT
.
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).
I know that @RomanYakovenko @mamoll @MarkOates may have an opinion on this:
- should it be
Declaration
andType
, orDeclarationD
and aTypeT
+D
orT
suffix 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
Issue Analytics
- State:
- Created 6 years ago
- Comments:5 (4 by maintainers)
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.
Regards, Roman
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.