A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2003-May/035702.html below:

[Python-Dev] a strange case

[Python-Dev] a strange casePhillip J. Eby pje@telecommunity.com
Fri, 16 May 2003 19:48:21 -0400
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...  ;)




RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4