How does one transition to underscore naming while still using other packages?

Data Management
#1

How does one implement a switch to underscores for the entire package, when one is still calling camelCase routines from other modules? Is it kosher to only change to underscores for things defined in the present package? That, sadly, seems like it would still be confusing.

#2

Yeah, that’s the can of worms that we chose to open by changing our naming standards halfway along. But here’s the way I see it. Firstly, there’s always going to be a mix of camelCase and under_scores for external modules because not all the modules we use share the same convention. I don’t even think that all the modules in the python standard library share the same convention. There’s nothing we can do about that, so don’t sweat it. Secondly, I think the guidelines rightly call for consistency as the most important thing. If you’re editing a file that uses camelCase, then all the names you introduce (as opposed to all the names you use) should be camelCase. And vice versa.

Personally, I think it’s a terrible pity to not only have changed naming standards and introduced this can of worms, but to have left things in limbo for so long (the DM Python Style Guide still says camelCase) that we’re introducing more inconsistency. In my opinion, we need to choose a standard and standardise on it. No doubt some will dislike the naming standard that we standardise on, but that’s inevitable, and the halfway-standard we currently have is worse than half our developers being mildly dissatisfied with our coding standard. If you’re going to do something, do it well or don’t do it at all.

1 Like
#3

(My personal opinion). I think it’s fine, in practice, to switch an entire [eups] package to a PEP8-advocated underscore-style naming while other packages in the Stack remain camelCase. After all, in Python we work in an ecosystem where underscores dominate (we use astropy, numpy, scipy, matplotlib, …, all the time without confusion).

It’s only the truly ancient modules in the standard library that still use camel case. Once PEP8 was introduced, everyone rallied around underscores.

Update: I just realized that my statement above missed the real challenge, which is that changing naming conventions introduces a massive API change to any dependent packages. (Above I was thinking only about Packages that had no existing API users).

For this concern the alternatives are:

  1. Rename functions, methods, and attributes to the new style, and then create facade functions, methods and attributes (via properties) that retain the camelCase style. Put a decorator on those facades to indicate that those APIs are deprecated.

  2. Take advantage of EUPS’ ability to manage versions and somehow pin versions for dependent packages until the package is ready to use the new API.

1 Like
#4

I am strongly in favor of this option and I advocated it last year. Python even has a scheme for marking APIs as deprecated (I know because every time I run tests on Python 3 it tells me to stop using assertEquals and assert_). The only way to change the APIs is to provide a backwards compatibility shim (presumably enabled in the __init__.py file. This allows packages to be updated one at a time without having to do a big bang migration.