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


Groups > comp.lang.python > #76486

Re: Module-level functions and the module type

References <CAPTjJmpYBVcHPotvyb+e3QExDOhXc9J2xO5VY1aow8mQcUxVRQ@mail.gmail.com>
From Chris Kaynor <ckaynor@zindagigames.com>
Date 2014-08-18 09:53 -0700
Subject Re: Module-level functions and the module type
Newsgroups comp.lang.python
Message-ID <mailman.13102.1408380830.18130.python-list@python.org> (permalink)

Show all headers | View raw


[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

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread


Thread

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

csiph-web