Move out of the global namespace

[nworden]

We currently have all our stuff in the global namespace, and it'd be nice to have our modules in our own namespace. The obvious options are either "personfinder" or simply "pf"; I'd prefer "pf" since "personfinder" is kinda long. I don't think we need to worry about "pf" colliding with anything else, especially since that name on PyPI is occupied by a project that its owner is apparently not very interested in.

There's not really a good time to do this, but the move to Python 3 might be the least bad time to do it. I'll experiment with pfif-tools and see how much of a hassle it'll be.

[gimite]

Just curious, what is the motivation doing this? PF is an application, not a library, so defining classes in the global namespace doesn't look bad to me. It won't harm to put it in a namespace though.

[nworden]

We could live without it, but there's a couple reasons I'd like to do it:

• In getting pfif-tools fully onto Django and onto the Python 3 runtime, I've found that both Django and GAE kinda expect that your code will be in its own namespace. It hasn't been a blocker (at least not so far), but it's kinda awkward.
• We wouldn't have to even think about naming collisions. It's very unlikely to be an issue, since most libraries have fairly unique names, but some don't (e.g., the "requests" library). Possibly related: I've run into a couple cases where pylint (or at least isort, a pylint dependency) complains about the config module being a standard import. I haven't figured out the reason, but I doubt we'd have any problems like that if we were in our own namespace.

I could be wrong, but I think it's pretty common for projects to use their own namespace even if they're not libraries. For example, Django's project generation tool puts files into a project-specific namespace by default (I moved them out to be consistent with the rest of PF)

[gimite]

I see, sounds good if it's a common practice and can also solve real issues.