Jim J. Jewett wrote:
I know I'm not the only one who is confused by at least some of the alternative terminology choices. I suspect I'm not the only one who sometimes missed part of the argument because I was distracted figuring out what the objects were, and forgot to verify what was being done and why. I also suspect that it could be much simpler to follow if the API were designed in the abstract, with the implementation left for later.
You're definitely not alone! I think I get the gist of the proposal, and its motivation, but I'm definitely confused by the terminology. As I stated elsewhere, the word "context" has a well-established meaning in Python, with context managers, their protocols, and contextlib. When talking with another Pythonista three years from now, I don't want to have to resolve which context they're talking about based on context. ;) I think you have a point too about designing the abstract behavior and API first, and then worry about implementation details (in fact, maybe take implementation discussions out of the PEP for now, and maybe hash that out in a PR). I also think you're on to something when you suggest that sys may not be the best place for these new APIs. sys is already a mishmash of lots of random stuff, and the concepts defined in PEP 550 are advanced enough that many Python developers will never need to worry about them. Putting them in sys leads to cognitive overload. I'm not sure I'd put them in builtins either, but a new module makes a lot of sense to me. Plus, it means that we can choose more natural names for the APIs since they'll be namespaced away in a separate module. Cheers, -Barry