There has been discussion from time to time about dropping CamelCase in Panda3D in favor of snake_case which also would be more “Pythonic” to begin with. For anyone who doesn’t know in what way it would be more Pythonic to use snake_case, please have a look at PEP 8. (admittedly, one can argue that PEP 8 was devised to keep the Python Standard Library on a single coding style, though IMHO it is a proven and good style convention to follow also outside of the standard library)
This would entail the following:
All methods in Panda3D would be by default in snake_case (e.g. loader.load_model instead of loader.loadModel) => There are a limited amount of cases left, where only CamelCase is available currently, otherwise snake_case is almost entirely available in Panda3D as of the time of this writing
All member variables => This would be a potentially/likely breaking change and ample advanced notice should be given. My suggestion would be to announce it 2 releases prior to it taking effect
All function arguments => same as member variables
There are ideas floating around to keep both notations around for legacy purposes and since I’m neither a core dev of Panda3D nor do I have any big project that couldn’t be updated with some easy refactoring if CamelCase were to be dropped, I started this discussion to hear from other Panda3D users to collect suggestions, objections, critique and so forth.
The C++ code is actually already snake_case afaik. Interrogate just wraps around CamelCase at the moment, but that can be changed w/o problems in future versions.
That… would be a pain for me. I use camel-case, not snake-case, and I don’t want to either refactor my projects nor change my coding style–especially as the reasons given for the change aren’t particularly compelling to me. And especially so if the renaming might break things!
(PEP’s recommendations are suggestions, as far as I’m concerned; I see little particularly good reason to hew to them or eschew them, beyond personal preference.)
Unless this would cause additional trouble for the developers of the engine, I would ask that camel-case be preserved for those who prefer it.
(One of my projects is quite large, but since you mention this taking place in at most two releases, I don’t know whether it would be affected.)
I was in the camelCase camp for a long time but not anymore, but
I’m not sure that breaking a lot of existing code for pep8-sake is worth it.
Would converting to snake_case and having camelCase aliases (opposite of what we have now) be a problem?
As a side note - I think the snake case constants used in p3d are not formatted according to PEP8 - eg FTLinearMipmapLinear became FT_linear_mipmap_linear but it should be FT_LINEAR_MIPMAP_LINEAR
I don’t want to create any confusion and following PEP8 in the API wasn’t meant to enforce its use in Panda3D, but it was probably poorly worded by me in the first post. Rather how the API at this point would be getting inconsistent in naming, with the efforts of adding snake_case. So to clarify:
Method names in camelCase would still be available and there isn’t any need to drop those as far as I can tell, but the API reference would/could be switched to snake_case as default w/o much effort. (being the part I wanted to point out as following PEP8)
but…
Members (e.g. base.camNode) and function arguments (base.make_camera(aspectRatio=12.0)) are the main issue here. Those would need renaming to stay consistent in the API, if the switch of snake_case were to be flipped. (There are ideas floating around to enable both, but all would come at the price of additional overhead for existing Panda apps and/or increased code complexity of the Panda3D source code)
It might not be worth going further than just adding all currently missing aliases in snake_case for methods and leave the Python API unchanged (as in default being camelCase), if the feedback were to be generally a big NO.
@Thaumaturge: given my clarification above, am I right to assume, that this still would be a pain for you? @wezu: Given that camelCase methods would remain, do you think it unreasonable to make such a change over the period of 2 release cycles? There might even be a direct replacement by then, so I figure that most legacy code would either be run in older P3D versions or ported to use new capabilities, but again, I could be dead wrong…
In fact, it is necessary to follow the PEP8 in the collective development of the project.
It would be better to change the names of the classes and methods to more logical ones. For example, everyone is familiar with pain?
disableMouse()
or.
If I understand correctly, it would be less of a pain (as my method-names would at least be fine), but still a pain (as quite a few variable-uses and keyword-parameters would be broken), indeed.
This, on the other hand, I’m in favour of. (And indeed, I’m a little surprised that there are un-aliased methods!) That would at least allow those who prefer snake-case to use it consistently, without being required to occasionally use camel-case.
(Except, alas, for the aforementioned parameters and variables, which is a pity, I will admit. :/)
I would argue that, when developing collaboratively, it’s a good idea to stick to a common style. However, that needn’t be PEP8’s style–just whatever the development group decides on. (And it doesn’t rule out aliases, such as we already use.)
There is an argument for the problem of integrating third-party snake-case code into a camel-case project.
I suppose that, in part, I just don’t like arbitrary decisions being determined by external bodies.
Hah, I wouldn’t mind seeing those things changed, I think! (Well, if it weren’t for all of the stuff that it might break!)
I think we should eventually settle on snake_case, not only because it’s what Panda’s C++ codebase uses (and has always used), but also because it’s what the vast majority of other Python projects uses (PEP8 or not).
Having to maintain aliases is awkward, and adds bloat for no good technical reason.
Hmm… That, I will confess, is a compelling set of arguments. Fair enough then, if the developers decide to switch over to snake-case, I won’t gainsay it.
@Thaumaturge: I understand your reluctance to adopt snake_case very well; I’ve been there too . But a certain rdb nevertheless managed to convert me to a snake_case proponent - and in turn I converted my code .
Like @wezu pointed out, having a script to do the refactoring for Panda3D specific method, argument and member names could be part of that goal to move to a snake_case only API.
I have worked with regex in the past in Python and feel comfortable to look for patterns and replace suitably, but I suspect some potential pitfalls in the task. It isn’t just a matter of doing a simple find and replace, instead I believe it would need at least rudimentary parsing capabilities to follow the code and not to mangle parts that should be left alone (e.g. comments, strings, etc.).
To encounter and prevent those pitfalls, next to working out a suitable design, much testing on as many different code bases as possible would have to be done, once we have an initial version of the script, to guarantee a sufficiently high level of certainty, that using the script won’t just create more work to the user than manually refactoring of a code base.
Anyone with a lot of experience in scripted refactoring of large code bases here maybe to chime in?
I really did not do this, but at the time when I was programming the site of the engine. I used PHP, it will cope. This is actually a regular replacement for text pattern. The main thing is to make a list of names for replacement.
I typed an example in PHP and, of course, it works, I think that Python will cope too. The problem with comments and lines is contrived, you can form a report about where and what was replaced, check manually and correct if necessary. This is much less than replacing the code for all the lines manually.
Does anyone know how to get all the names that need to be replaced in the style of a camel? Of course, it would be better and option in the style of a snake.
This is necessary to rename user functions. I found out the panda methods directly from dir () and compared them to each other. Please note this guarantees work in such cases when there is no snake style for the method.
My solution is based not on the presence of capital letters, but on patterns. This is brief.
. But a certain rdb nevertheless managed to convert me to a snake_case proponent - and in turn I converted my code 
.