<br><div class="gmail_quote">On Fri, Apr 27, 2012 at 6:31 AM, Jim Jewett <span dir="ltr"><<a href="mailto:jimjjewett@gmail.com" target="_blank">jimjjewett@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On Wed, Apr 25, 2012 at 2:35 PM, Matt Joiner <<a href="mailto:anacrolix@gmail.com">anacrolix@gmail.com</a>> wrote:<br>
> If this is to be done I'd like to see all special methods supported. One of<br>
> particular interest to modules is __getattr__...<br>
<br>
For What It's Worth, supporting __setattr__ and __getattr__ is one of<br>
the few reasons that I have considered subclassing modules.<br>
<br>
The workarounds of either offering public set_varX and get_varX<br>
functions, or moving configuration to a separate singleton, just feel<br>
kludgy.<br>
<br>
Since those module methods would be defined at the far left, I don't<br>
think it would mess up understanding any more than they already do on<br>
regular classes.  (There is always *some* surprise, just because they<br>
are unusual.)<br>
<br>
That said, I personally tend to view modules as a special case of<br>
classes, so I wouldn't be shocked if others found it more confusing<br>
than I would -- particularly as to whether or not the module's<br>
__getattr__ would somehow affect the lookup chain for classes defined<br>
within the module.<br>
<br>
-jJ<br></blockquote><div><br></div><div>Making modules "simply" be a class that could be subclasses rather than their own thing _would_ be nice for one particular project I've worked on where the project including APIs and basic implementations were open source but which allowed for site specific code to override many/most of those base implementations as a way of customizing it for your own specific (non open source) environment.  Any APIs that were unfortunately defined as a module with a bunch of functions in it was a real pain to make site specific overrides for.  Anything APIs that were thankfully defined as a class within a module even when there wasn't a real need for a class was much easier to make site specific.</div>

<div><br></div><div>But this is not an easy thing to do.  I wouldn't want functions in a module to need to be declared as class methods with a cls parameter nor would I want an implicit named equivalent of cls; or does that already exist through an existing __name__ style variable today that I've been ignoring?  This could leads to basically treating a module globals() dict as the class dict which at first glance seems surprising but I'd have to ponder this more.</div>

<div><br></div><div>(and yes, note that I am thinking of a module as a class, not an instance)</div><div><br></div><div>-gps</div></div>