On Apr 2, 2020, at 13:35, Abdur-Rahmaan Janhangeer <arj.pyt...@gmail.com> wrote: > >> On Thu, Apr 2, 2020 at 8:15 PM Andrew Barnert <abarn...@yahoo.com> wrote: >> >> Why should modules break all of that, and be different from strings, tuples, >> functions, classes, etc.? > > python-ideas is for ideas without worrying about implementations unless it's > about some glaring breaking changes
But nobody’s mentioned implementation here. Nobody’s saying you can’t have this because it would be too hard to implement. (It almost surely wouldn’t be hard. For one thing, there are existing cases of special methods like __dir__, which are normally looked up on the type but for modules they’re looked up on the individual instance, and the same thing presumably could be done here just as easily. Even besides that, most types’ reprs, including module, already include information from the instance, so there’s no reason even without overloading module.__repr__ you couldn’t have a slightly different way to extensively customize the repr of each individual module.) People are saying you probably don’t want this because it would be inconsistent with other reprs, and with what repr is for and how it’s used—e.g., the concise and standard form of reprs is crucial to things like tracebacks and logs being useful for debugging. That’s not about implementation; that’s about the key idea in your proposal. >> The str, which you get from print(package), might be a different story. If >> there’s a representation of a module that’s more useful to end users than >> the repr, even if it’s not as good for debugging, the str should use that >> representation. But is there? What would the message be? How would the >> module specify it? And how it would be useful for the end user to see that >> message? >> ... >> I may be misinterpreting something about the goals of your proposal. If so, >> I apologize—but it would really help if you give a real example: some known >> module, what message you think it should include in its repr, where you plan >> to print out that repr, how you’d like to specify it within the module >> source, etc. > > Well as for example from known module, the proposal is all about introducing > the __repr__ option in modules. > If i understood well it does not seem to exist. As for purpose, well a > friendlier representation of a package. That’s not an example. Show us a module that you’d like to have a custom repr, and show us what you’d like that custom repr to be, and show us that it looks good in other contexts (a traceback, printing out sys.modules, etc.), or why it’s so good in the REPL that it overcomes the cost of being less good in those contexts. You may well have examples that are good enough. But if you don’t show us your examples, we can only use our own imagination, and obviously none of us are imagining anything nearly good enough to be worth it. Which is our failure, not yours—but you want this implemented, and if nobody backs your proposal because nobody imagines how useful it would be, you’re not going to get it.
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2BDUNV6TCNFKX5OBUGT3AAAYLXES3FNP/ Code of Conduct: http://python.org/psf/codeofconduct/
