On Sat, Apr 4, 2020 at 7:02 AM Christopher Barker <[email protected]> wrote: > So if folks think it's a good idea to allow modules to have a custom __str__: > it would be nice to add that feature to Python. > > I'm not saying I advocate for that -- but it's not completely unreasonable. >
It's not unreasonable, I agree. But it's also unnecessary. In theory, PEP 562 could have gone for a broader recommendation eg "any dunder on a module will be looked up in the instance", but in practice, which ones are you actually going to need? PEP 562 chose two (__getattr__ and __dir__), with definite use-cases for each. There's no need to override __new__/__init__, since the module body serves that purpose. Comparisons (__lt__ etc) don't make a lot of sense. Modules are generally singletons, so __hash__ and __eq__ aren't needed (the default of using object identity is fine). There is *one* other dunder that I can imagine getting some good use, and that's __call__. A few others might have occasional uses (maybe __setattr__ for deprecation warnings, same as __getattr__, and maybe __enter__/__exit__ so the module itself can be a context manager), but they would be rather more rare. Changing the repr/str of a module would also be pretty unusual. Fortunately, the unusual case IS possible - just not as easy. You subclass the module type, instantiate your subclass, and shove the instance into sys.modules. So if you really do need to mess with the repr of your module, you can, even if it's a package :) ChrisA _______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/UDPYBEJHHYV2Z62PKU6WVZXBMZCFAOSN/ Code of Conduct: http://python.org/psf/codeofconduct/
