(original) (raw)
On 11/15/2017 04:55 AM, Koos Zevenhoven wrote:
On Tue, Nov 14, 2017 at 10:34 PM, Ivan Levkivskyi wrote:
\>>
Rationale
\=========
\[...\] It would be convenient to simplify this
procedure by recognizing \`\`\_\_getattr\_\_\`\` defined directly in a module that
would act like a normal \`\`\_\_getattr\_\_\`\` method
\>> \[...\]
\>>
\>> The \`\`\_\_getattr\_\_\`\` function at the module level should accept one argumentSpecification
\=============
which is the name of an attribute and return the computed value or raise
an \`\`AttributeError\`\`::
def \_\_getattr\_\_(name: str) -> Any: ...
This function will be called only if \`\`name\`\` is not found in the module
through the normal attribute lookup.
The Rationale (quoted in the beginning of this email) easily leaves a different impression of this.​
I don't see how. This is exactly the way normal \_\_getattr\_\_ works.
​Oh sorry, I think I put this email together too quickly. I was writing down a bunch of thoughts I had earlier but hadn't written down.​ I think I was mixing this up in my head with overriding \_\_getitem\_\_ for the module namespace dict and \_\_class\_getitem\_\_ from PEP 560, which only gets called if the metaclass doesn't implement \_\_getitem\_\_ (IIRC).
But I did have another thought related to this. I was wondering whether the lack of passing the module to the methods as \`self\` would harm future attempts to generalize these ideas.
-- Koos
+ Koos Zevenhoven + http://twitter.com/k7hoven +