Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #76486 > unrolled thread

Re: Module-level functions and the module type

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Module-level functions and the module type Chris Kaynor <ckaynor@zindagigames.com> - 2014-08-18 09:53 -0700

#76486 — Re: Module-level functions and the module type

[Multipart message — attachments visible in raw view] — view raw

On Sun, Aug 17, 2014 at 8:15 AM, Chris Angelico <rosuav@gmail.com> wrote:

> In a class definition, you have explicit state parameters on your
> functions - 'self':
>
> class C:
>     def foo(self, arg):
>         # blah blah
>
> At module level, there's equivalent state - the function "knows" what
> module it came from - but it's implicit:
>
> def foo(arg):
>     # blah blah
>
> print(foo.__globals__)
>
> How hard would it be to unify these, and make modules into classes?
> This would then allow stuff like properties, metaclasses, and so on,
> all with exactly the same semantics as they have in classes.
>
> Obviously this would be a huge backward-compatibility break if it
> happened everywhere, but what I'm looking at here is a way to
> basically bless this kind of concept:
>
> # spam.py
> class RealSpam:
>     # module contents here
>
> import sys
> sys.modules[__name__] = RealSpam()


> So the question is: Why is state implicit in one and explicit in the
> other? Which option is really the better way to do things?
>

As a heads up, we did this at work (mostly, just to support module-level
properties) by using an import hook to adjust the type of object loaded
from .py files. At the root, it was fairly easy to implement (though quite
a bit of boiler code), however the main problem we ran into was performance
- doing so slowed down all module accesses.

The other issue with the way we did it (we didn't pass in the module to all
functions) was that global accesses would not access the properties, so
work-arounds had to be done to access them within the module itself.

Chris

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web