Skip to content

Document a module inclusion policy #80

@woodruffw

Description

@woodruffw

The automated module list generation (e.g. #77, #78, #79) works, but it reveals some weaknesses:

  1. For older Python versions it uses the Sphinx inventory, meaning that modules that are no longer listed (or are listed in subtly different ways) appear to "disappear" when the list is updated;
  2. For all Python versions it uses the latest minor version, which may have its own (intentional) variations;
  3. It's fundamentally tied to the Python build itself, meaning that (currently) it won't correctly detect modules that are only defined on non-Linux hosts.

I'm not sure if there's a good way to solve all of these, but one thing we can do: rather than replacing the old list on each update, we can instead merge it, resulting in a list for each Python version that effectively represents the "superset" of everything seen so far.

The upside to this is that our lists will appear more complete; the downside is that it means that some modules will be "inaccurately" listed for a particular Python version, since the end user's host or minor version may not have those modules. On the other hand, it was never guaranteed that these names could be imported to begin with, so maybe that downside isn't so serious.

CC @miketheman for thoughts 🙂

Metadata

Metadata

Assignees

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions