Re: [Python-Dev] a strange case
Jeremy> I think we decided this wasn't a pure bugfix :-). Some poor Jeremy> soul may have code that relies on being able to subclass a Jeremy> module.
How about at least deprecating that feature in 2.2.3 and warning about it so that poor soul knows this won't be supported forever?
I think I'm knocking on the poor-house door. Just last night, it occurred to me that modules could be made callable via subclassing. "Why in the world would you want callable modules you ask?" I don't have a real need, but I often see the line blurred between package, module, and class. Witness: from Foo import Bar frob = Bar() If Bar is initially a class, then is reimplemented as a module, client code must change to account for that. If Bar is reimplemented as a callable module, clients remain unaffected. I haven't any code that relies on subclassing the module type, but many times I've gone thru the cycle of coding a class then promoting it to a module as it becomes more complex. I'm certainly not advocating that the module type be subclassable or not, but I did want to point out a possible legitmate need to derive from it. Many apologies if I'm wasting space and time. -troy Silly example: troy@marchhare tmp $ cat foo.py def op(): print 'foo op' def frob(): print 'foo frob' def __call__(a, b, c): print 'module foo called!', a, b, c troy@marchhare tmp $ cat bar.py class ModuleObject(type(__builtins__)): def __init__(self, amodule): self.amodule = amodule self.__name__ = amodule.__name__ self.__file__ = amodule.__file__ def __getattr__(self, attr): return getattr(self.amodule, attr) def __call__(self, *a, **b): return self.amodule.__call__(*a, **b) import foo foo = ModuleObject(foo) foo(1,2,3) troy@marchhare tmp $ python2.3 bar.py module foo called! 1 2 3
At 01:45 PM 5/16/03 -0800, Troy Melhase wrote:
Jeremy> I think we decided this wasn't a pure bugfix :-). Some poor Jeremy> soul may have code that relies on being able to subclass a Jeremy> module.
How about at least deprecating that feature in 2.2.3 and warning about it so that poor soul knows this won't be supported forever?
I think I'm knocking on the poor-house door.
Just last night, it occurred to me that modules could be made callable via subclassing.
This isn't about subclassing the module *type*, but about subclassing *modules*. Subclassing a module doesn't do anything useful. Subclassing the module *type* does, as you demonstrate. Python 2.3 still allows you to subclass the module type, even though it does not allow you to subclass modules. Now, if you *really* want to subclass a *module*, then you should check out PEAK's "module inheritance" technique that lets you define new modules in terms of other modules. It's useful for certain types of AOP/SOP techniques. But it's currently implemented using bytecode hacking, and is therefore evil. ;) Anyway, it doesn't rely on actually *subclassing* modules. Speaking of bytecode hacking, it would be so much easier to implement "portable magic" if there were a fast, easy to use, language-defined intermediate representation for Python code that one could hack with. And don't tell me to "use Lisp", either... ;)
"Why in the world would you want callable modules you ask?" I don't have a real need, but I often see the line blurred between package, module, and class.
Please don't try to blur the line between module and class. This has been proposed many times, and the net result IMO is always more confusion and no more power. This is also why in 2.3, modules are no longer subclassable. If you really need to have a module that has behavior beyond what a module can offer, the officially sanctioned way is to stick an instance of a class in sys.modules[__name__] from inside the module's code. (I would explain more about *why* I think it's a really bad idea, but I'm officially on vacation.) --Guido van Rossum (home page: http://www.python.org/~guido/)
Please don't try to blur the line between module and class. This has been proposed many times, and the net result IMO is always more confusion and no more power. This is also why in 2.3, modules are no longer subclassable.
Loud and clear!
(I would explain more about *why* I think it's a really bad idea, but I'm officially on vacation.)
"There should be one-- and preferably only one --obvious way to do it" if I had to guess. Happy holidays. -troy
Guido van Rossum wrote:
"Why in the world would you want callable modules you ask?" I don't have a real need, but I often see the line blurred between package, module, and class.
Please don't try to blur the line between module and class. This has been proposed many times,
It sounds familiar! ;)
and the net result IMO is always more confusion and no more power. This is also why in 2.3, modules are no longer subclassable.
If you really need to have a module that has behavior beyond what a module can offer, the officially sanctioned way is to stick an instance of a class in sys.modules[__name__] from inside the module's code.
But reload() won't work for these pseudo modules (See http://www.python.org/sf/701743). What about the imp module?
(I would explain more about *why* I think it's a really bad idea, but I'm officially on vacation.)
Sure, this can wait. Bye, Walter Dörwald
But reload() won't work for these pseudo modules (See http://www.python.org/sf/701743).
Reload() is a hack that doesn't really work except in the most simple cases. This isn't one of those.
What about the imp module?
Yes, what about it? (I don't understand the remark.) --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
But reload() won't work for these pseudo modules (See http://www.python.org/sf/701743).
Reload() is a hack that doesn't really work except in the most simple cases. This isn't one of those.
It could be made to work, if the code in a module had a way of knowing whether this import is the first one or not, and it had access to what was in sys.modules before the import mechanism replaces it with an empty module.
What about the imp module?
Yes, what about it? (I don't understand the remark.)
Does the imp module work with modules that replace the module entry in sys.modules? (Code in PyImport_ExecCodeModuleEx() seems to indicate that it does.) Bye, Walter Dörwald
Troy Melhase <troy@gci.net>:
Just last night, it occurred to me that modules could be made callable via subclassing. "Why in the world would you want callable modules you ask?"
This has given me a thought concerning the naming problem that arises when you have a module (e.g. socket) that exists mainly to hold a single class. What if there were some easy way to make the class and the module the same thing? I'm thinking about having an alternative filename suffix, such as ".cls", whose contents is treated as though it were inside a class statement, and then the resulting class is put into sys.modules as though it were a module. Not sure how you'd specify base classes -- maybe a special __bases__ class attribute or something. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
participants (5)
-
Greg Ewing -
Guido van Rossum -
Phillip J. Eby -
Troy Melhase -
Walter Dörwald