I'm not too worried about that situation. From what the documentation for dir says, I don't think one should use dir to determine all the attributes a class has. Adding emphasis to the key parts:
Because dir()<https://docs.python.org/3/library/functions.html#dir> is supplied primarily as a convenience for use at an interactive prompt, it tries to supply an interesting set of names more than it tries to supply a rigorously or consistently defined set of names, and its detailed behavior may change across releases. For example, metaclass attributes are not in the result list when the argument is a class. So: 1. The intended use of dir is for convenience at an interactive prompt 2. The list of names returned is not guarantees to be complete 3. The list of names is not guaranteed to be stable across releases Altogether, this indicates to me that in your hypothetical the programmer made a mistake by relying on dir to provide a complete list of methods. As for what to do, perhaps we should be relying on linters and typing.final / typing.overrides in situations like this to prevent inheritance problems. Vincent Macri (he/him) ________________________________ From: [email protected] <[email protected]> on behalf of Nils Bruin <[email protected]> Sent: Tuesday, October 7, 2025 7:35:16 p.m. To: sage-devel <[email protected]> Subject: Re: [sage-devel] hidding aliases from tab-completion [â–³EXTERNAL] On Tuesday, 7 October 2025 at 15:54:22 UTC-7 mathzeta2 wrote: When handling inheritance, there is a disadvantage to defining an alias with `bar = foo`. [...] In some places in Sage an alias `baz` will be defined as def baz(self): return self.foo() and a short doc that says it is an alias, instead of the better solution of having the full docstring of foo() with a prefix that tells this is an alias. In fact, this already points to an unintended complication with modifying the output of "dir": Someone might be looking to subclass something and install new functionality. They check "dir" of the ancestor and find that the name they were thinking of to be unused, so they happily put their own function in. But as it happens, they have now overwritten an alias that was there for legacy reasons and now their subclassed objects fail to behave properly in other legacy contexts where other routines are relying on the aliases that are now overridden with different functionality. This could even lead to silent wrong results -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sage-devel/TO1PPFB4708EDB71F6925B6776793B3DC91F7E1A%40TO1PPFB4708EDB7.CANPRD01.PROD.OUTLOOK.COM.
