Skip to content

Globals

paystone.globals exists because some constants, functions, types, and data structures are broadly applicable across the codebase: in machine learning services, auxiliary services, Paystone packages, infrastructure code, and/or the CLI.

When considering whether a particular constant, function, type, or data structure belongs in Globals, ask yourself:

  • Is this only going to be used in one package right now?
    • If so, keep it in the package it is being used in. There are places for each of these things within specific packages.
  • Do we really need to make this for ourselves, or does it exist in a third-party?
    • Many functions which we may think we need to write for global use across the codebase will actually already exist in third-party packages.
    • If it already exists, include the dependency in requirements.txt files where necessary and avoid writing a global.

In general, we will try to keep the paystone.globals package lean. Its members, however, may be frequently accessed.

There is one rule: never under any circumstances create paystone/globals/paystone/globals/utils.py. That is just asking for trouble. All globals should have a very well defined bucket that they fit into.