Stop polluting the namespace!

[ceball]

E.g. could move nearly all attributes and methods of Parameterized into a sub-object.

Will need to provide a migration path.

[jlstevens]

Any reason this sub-object can't be on a param object?

In Parameterized, you would have self.param = SomeNamespace(...). I think once it is bound as an attribute on a class or object, there won't be issue with this name clashing with param the module.

[jbednar]

I thought about that too, but decided that it might make the docs confusing, because people wouldn't be able to distinguish easily between param.something_defined_at_the_module_level and param.something_defined_in_the_subobject. In code I think it's fine, but because everything will be on this subobject, we'll want a short way to refer to it in docs, and the obvious param as the short name (as opposed to Parameterized.param) would be unsuitable. If only param had some obvious short name we could use here for the subobject, but it's already a shortening and does not seem to. Just p is problematic, since we're already using that by convention. Maybe self.prm?

[jlstevens]

I'm not too sure that is an issue - it should be fairly easy to tell the module and sub-object apart as the module is used for class which are capitalized (e.g param.Parameterized, param.Integer etc) and the sub-object is holding methods which are lowercase (set_param, warning etc).

There are a few top-level functions (which could be moved into a util file?) but I think the vast majority of normal param usage falls into the two categories I just mentioned. I don't think there would be much confusion in practice and any other name (e.g prm) just seems a lot less nice to me.

[jbednar]

Fine by me, then.

[jlstevens]

I suppose we could make a branch, try it out and see how much we like it?

Trying it out is the best way for us to figure out how happy we are with any particular suggestion.

[jbednar]

Is trying it out as simple as doing self.param = self.__dict__ in the Parameterized constructor? That won't clean up the namespace, but it seems like it would let you see what using the new way would be like.

[jbednar]

Nearly done already, but needs the actual namespace cleanup to be done, which is a breaking change that is waiting on param 2.0.

[jbednar]

Covered under #233.