Nick Coghlan writes: > While upstream changes turned out not to be necessary for the > "distributor breaking up the standard library" use case, they may > still prove worthwhile in making import errors more informative in the > case of "I just built my own Python from upstream sources and didn't > notice (or didn't read) the build message indicating that some modules > weren't built".
This case-by-case line of argument gives me a really bad feeling. Do we have to play whack-a-mole with every obscure message that pops up that somebody might not be reading? OK, this is a pretty common and confusing case, but surely there's something more systematic (and flexible vs. turning every error message into a complete usage manual ... which tl;dr) we can do. One way to play would be an interactive checklist-based diagnostic module (ie, a "rule-based expert system") that could be plugged into IDEs or even into sys.excepthook. Given Python's excellent introspective facilities, with a little care the rule interpreter could be designed with access to namespaces to provide additional detail or tweak rule priority. We could even build in a learning engine to give priority to users' habitual bugs (including typical mistaken diagnoses). That said, I don't have time to work on it :-(, so feel free to ignore me. And I grant that since AFAIK we have zero existing code for the engine and rule database, it might be a good idea to do something for some particular obscure errors in the 3.7 timeframe. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
