Nick Coghlan <ncogh...@gmail.com> added the comment: I think if someone is going to be put off by a FutureWarning, then that indicates they're not yet familiar with just what the provisional API status means, and those are exactly the folks we *want* to scare away from provisional APIs (or features in third party libraries and frameworks that depend on them).
After all, if "Set 'use_provisional_<module> = True' in __main__" is more of an inconvenience than someone is prepared to tolerate to enable warning-free access to a still evolving feature, imagine how upset they'd be if we actually *did* make a breaking change to that API. I did realise my draft warning was missing a bit though, which was to explain how to turn it off: import __main__ _feature_flag = f"use_provisional_{__name__}" if not getattr(__main__, _feature_flag): import warnings _provisional_msg = f"The {__name__} module is currently a provisional API - see documentation for details. Set '__main__.{_feature_flag} = True' to disable this warning." warnings.warn(FutureWarning, _provisional_msg) I also revised the draft message to account for Guido's observation about even "provisional" APIs being mostly stable by directing folks to the module documentation for details. That way the maintainers of the provisional API don't need to duplicate their explanation of how provisional the module actually is (e.g. the typing docs make it clear that feature additions and API changes are currently in scope for maintenance releases, but outright removal isn't listed as a possible outcome). Folks that want to always opt-in to various features in their REPL sessions can then set them via PYTHONSTARTUP. I'll also note here why I'm proposing this as a per-process flag rather than a per-module one: - checking a feature flag in __main__ is easy, checking a flag in the "importing module" is hard - module caching means only the first import would actually run the code to emit the warning any way - we know from experience that having to set per-module __future__ flags to access backwards incompatible syntax changes genuinely *is* annoying (to the point where we'll implement clever tricks like those Yury came up with for native coroutines to avoid needing them) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31742> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com