> On 29 Nov 2016, at 02:48, Chris Angelico <ros...@gmail.com> wrote: > > On Tue, Nov 29, 2016 at 12:14 PM, Steven D'Aprano <st...@pearwood.info> wrote: >> What if I have two files? >> >> # a.py >> try: >> import spam >> except ImportError: >> import ham as spam >> >> # b.py >> try: >> import spam >> except ImportError: >> import cornedbeef as spam >> > > In the same project? Then you already have a maintenance nightmare, > because 'spam' will sometimes mean the same module (with state shared > between the files), but might mean two distinct modules (and thus > unrelated module objects). In different projects? They won't conflict.
Well, you *might* have a maintenance nightmare, but you might not. In particular, I should point out that “spam” is just a name (more correctly referred to as a.spam and b.spam.) If the “spam” module is intended to have global state that the “a” and “b” modules use to communicate then obviously this is a problem. But if it isn’t, then there is exactly no problem with each module choosing its own fallback. As a really silly example, consider sqlite3 again. If there were third-party modules that both implement the sqlite3 API, then there is no reason for each module to agree on what sqlite3 module they use unless types are being passed between them. If we consider “a” and “b” as truly separate non-communicating modules, then there’s no issue at all. Cory _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
