I'm a bit confused. Tim: are you saying that something goes wrong if we use class variable packageName to get the package name, and otherwise use it exactly as it used now (including testing it in the base class's constructor) and get rid of the class method getPackageName()? Does it make pylint unhappy for some reason?

I agree that using @property would be a bit safer but it doesn't work. K-T said yesterday he was not worried about buggy code accidentally changing the value of the class variable and I agree that it's unlikely to be a problem.

The pylint comment refers to complaining if "_" methods or variables are used by different classes. Python doesn't have the notion of an internal variable that can be used by subclasses.

I'm still trying to work out why this is a class method. The constructor trapping the package name not being set is irrelevant if people call the class method without instantiating an object. If this was an object method then getPackageName would serve no purpose and we could just delete it and use the attribute directly (maybe making it readonly). It seems that if we have a class variable we have no control over when people access it. Unless we switch to instance variables I'm inclined to just tag the class attribute with an underscore.

It is not presently necessary for package name to be a class attribute, but logically it makes sense for it to be, and we may end up with a use case someday.

However, there is no easy way to test that the subclass set it before the object is instantiated. K-T explicitly granted permission for the test to be deferred until then. There are alternatives, such as not testing it anywhere except a unit test. I object to that because I expect authors of new subclasses of CameraMapper will forget. The error will be caught eventually, but catching it earlier is nice if it's easy to do.

The package name, ie. how the source code is organized, is class metadata which should be invariant for any instances.

I agree that the package name is, by design, a constant for a given subclass of CameraMapper. The question is whether we need to enforce that const-ness. It is a pain to do in Python, so it's worth asking that question. I don't think we need to enforce const-ness and K-T said the same in the HipChat discussion (though it would carry more weight in this ticket).

We don't enforce const-ness with any other Python class constants that I know of, such as Task.ConfigClass, and I am not aware of any problems that this has caused.