Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
Why do I have the feeling you sent this to the wrong list? On 7/10/06, Perkins, Christopher [EMAIL PROTECTED] wrote: John, I see what you are doing with the algorithm now, and I can easily re-factor it. What I am having issues with is how structured it is. 5 minute windows? Then running hours will always be recorded in 1/12th time steps. Would it not be more accurate to record engine time where the breaker was closed? -chris ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
Steven Bethard wrote: Nick Coghlan wrote: Having module attribute access obey the descriptor protocol (__get__, __set__, __delete__) sounds like a pretty good option to me. It would even be pretty backwards compatible, as I'd be hardpressed to think why anyone would have a descriptor *instance* as a top-level object in a module (descriptor definition, yes, but not an instance). Aren't all functions descriptors? So Josh pointed out. py def baz(): ... print Evaluating baz! ... return Module attribute ... py baz() Evaluating baz! 'Module attribute' py baz.__get__(__import__(__name__), None) bound method ?.baz of module '__main__' (built-in) py baz.__get__(__import__(__name__), None)() Traceback (most recent call last): File interactive input, line 1, in ? TypeError: baz() takes no arguments (1 given) How would your proposal change the invocation of module-level functions? It would, alas, break it. And now that I think about it, functions have to work the way they do, otherwise binding an arbitrary function to a class variable wouldn't work properly. So the class descriptor protocol can't be used as is at the module level, because functions are descriptor instances. Ah well, another idea runs aground on the harsh rocks of reality. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
On 10/17/05, Nick Coghlan [EMAIL PROTECTED] wrote: Ah well, another idea runs aground on the harsh rocks of reality. I should point out that it's intentional that there are very few similarities between modules and classes. Many attempts have been made to unify the two, but these never work right, because the module can't decide whether it behaves like a class or like an instance. Also the direct access to global variables prevents you to put any kind of code in the get-attribute path. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
Nick Coghlan wrote: Having module attribute access obey the descriptor protocol (__get__, __set__, __delete__) sounds like a pretty good option to me. It would even be pretty backwards compatible, as I'd be hardpressed to think why anyone would have a descriptor *instance* as a top-level object in a module (descriptor definition, yes, but not an instance). Aren't all functions descriptors? py def baz(): ... print Evaluating baz! ... return Module attribute ... py baz() Evaluating baz! 'Module attribute' py baz.__get__(__import__(__name__), None) bound method ?.baz of module '__main__' (built-in) py baz.__get__(__import__(__name__), None)() Traceback (most recent call last): File interactive input, line 1, in ? TypeError: baz() takes no arguments (1 given) How would your proposal change the invocation of module-level functions? STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
BTW, what's the performance problem in importing unnecessary stuff (assuming pyc files are already generated) ? Fredrik larger modules can easily take 0.1-0.2 seconds to import (at Fredrik least if they use enough external dependencies). I wish it was that short. At work we use lots of SWIG-wrapped C++ libraries. Whole lotta dynamic linking goin' on... In our case I don't think autoloading would help all that much. We actually use all that stuff. The best we could do would be to defer the link step for a couple seconds. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
Sokolov Yura wrote:
May be allow modules to define __getattr__ ?
I think I like the descriptor idea better. Besides
being more in keeping with modern practice, it would
allow for things like
from autoloading import autoload
Foo = autoload('foomodule', 'Foo')
Blarg = autoload('blargmodule', 'Blarg')
where autoload is defined as a suitable descriptor
subclass.
I guess we could do with a PEP on this...
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
Sokolov Yura wrote: May be allow modules to define __getattr__ ? def __getattr__(thing): try: return __some_standart_way__(thing) except AttributeError: if thing==Queue: import sys from Queue import Queue setattr(sys.modules[__name__],Queue,Queue) return Queue raise I proposed something like this in the RFE tracker a while ago, but no one commented on it. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
[EMAIL PROTECTED] wrote: It sounds like he feels Queue should just be part of threading but queues can be used in other contexts besides threading. So having separate modules is a good thing. If threads aren't involved, you should use collections.deque directly, rather than going through Queue.Queue. The latter jumps through a lot of hoops in order to be thread-safe. This confusion is one of the reasons I have a problem with the current name of the Queue module. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
Greg Ewing wrote: BTW, I agree that special *syntax* isn't necessarily needed. But it does seem to me that some sort of hook is needed somewhere to make this doable smoothly, that doesn't exist today. Having module attribute access obey the descriptor protocol (__get__, __set__, __delete__) sounds like a pretty good option to me. It would even be pretty backwards compatible, as I'd be hardpressed to think why anyone would have a descriptor *instance* as a top-level object in a module (descriptor definition, yes, but not an instance). Consider lazy instance attributes: Py def lazyattr(func): ... class wrapper(object): ... def __get__(self, instance, cls): ... val = func() ... setattr(instance, func.__name__, val) ... return val ... return wrapper() ... Py class test(object): ... @lazyattr ... def foo(): ... print Evaluating foo! ... return Instance attribute ... Py t = test() Py t.foo Evaluating foo! 'Instance attribute' Py t.foo 'Instance attribute' And lazy class attributes: Py def lazyclassattr(func): ... class wrapper(object): ... def __get__(self, instance, cls): ... val = func() ... setattr(cls, func.__name__, val) ... return val ... return wrapper() ... Py class test(object): ... @lazyclassattr ... def bar(): ... print Evaluating bar! ... return Class attribute ... Py test.bar Evaluating bar! 'Class attribute' Py test.bar 'Class attribute' Unfortunately, that trick doesn't work at the module level: Py def lazymoduleattr(func): ... class wrapper(object): ... def __get__(self, instance, cls): ... val = func() ... globals()[func.__name__] = val ... return val ... return wrapper() ... Py @lazymoduleattr ... def baz(): ... print Evaluating baz! ... return Module attribute ... Py baz # Descriptor not invoked __main__.wrapper object at 0x00B9E3B0 Py import sys Py main = sys.modules[__main__] Py main.baz # Descriptor STILL not invoked :( __main__.wrapper object at 0x00B9E3B0 But putting the exact same descriptor in a class lets it work its magic: Py class lazy(object): ... baz = baz ... Py lazy.baz Evaluating baz! 'Module attribute' Py baz 'Module attribute' Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
Guido van Rossum wrote: BTW, Queue.Queue violates a recent module naming standard; it is now considered bad style to name the class and the module the same. Modules and packages should have short all-lowercase names, classes should be CapWords. Even the same but different case is bad style. unfortunately, this standard seem to result in generic spamtools modules into which people throw everything that's even remotely related to spam, followed by complaints about bloat and performance from users, followed by various more or less stupid attempts to implement lazy loading of hidden in- ternal modules, followed by more complaints from users who no longer has a clear view of what's really going on in there... I think I'll stick to the old standard for a few more years... /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
On 10/13/05, Fredrik Lundh [EMAIL PROTECTED] wrote: Guido van Rossum wrote: BTW, Queue.Queue violates a recent module naming standard; it is now considered bad style to name the class and the module the same. Modules and packages should have short all-lowercase names, classes should be CapWords. Even the same but different case is bad style. unfortunately, this standard seem to result in generic spamtools modules into which people throw everything that's even remotely related to spam, followed by complaints about bloat and performance from users, followed by various more or less stupid attempts to implement lazy loading of hidden in- ternal modules, followed by more complaints from users who no longer has a clear view of what's really going on in there... I think I'll stick to the old standard for a few more years... Yeah, until you've learned to use packages. :( -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
unfortunately, this standard seem to result in generic spamtools modules into which people throw everything that's even remotely related to spam, followed by complaints about bloat and performance from users, followed by various more or less stupid attempts to implement lazy loading of hidden in- ternal modules, followed by more complaints from users who no longer has a clear view of what's really going on in there... BTW, what's the performance problem in importing unnecessary stuff (assuming pyc files are already generated) ? Has it been evaluated somewhere ? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
Guido van Rossum wrote: BTW, Queue.Queue violates a recent module naming standard; it is now considered bad style to name the class and the module the same. Modules and packages should have short all-lowercase names, classes should be CapWords. Even the same but different case is bad style. unfortunately, this standard seem to result in generic spamtools modules into which people throw everything that's even remotely related to spam, followed by complaints about bloat and performance from users, followed by various more or less stupid attempts to implement lazy loading of hidden in- ternal modules, followed by more complaints from users who no longer has a clear view of what's really going on in there... I think I'll stick to the old standard for a few more years... Yeah, until you've learned to use packages. :( what does packages has to do with this ? does this new module naming standard only apply to toplevel package names ? /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
On 10/12/05, Michael Chermside [EMAIL PROTECTED] wrote: I'm not familiar with the clever trick Greg is proposing, but I do agree that _IF_ everything else were equal, then Queue seems to belong in the threading module. My biggest reason is that I think anyone who is new to threading probably shouldn't use any communication mechanism OTHER than Queue or something similar which has been carefully designed by someone knowlegable. I *still* disagree. At some level, Queue is just an application of threading, while the threading module provides the basic API (never mind that there's an even more basic API, the thread module -- it's too low-level to consider and we actively recommend against it, at least I hope we do). While at this point there may be no other applications of threading in the standard library, that may not remain the case; it's quite possble that some of the discussions of threading APIs will eventually lead to a PEP proposing a different threading paradigm build on top of the threading module. I'm using the word application loosely here because I realize one person's application is another's primitive operation. But I object to the idea that just because A and B are often used together or A is recommended for programs using B that A and B should live in the same module. We don't put urllib and httplib in the socket module either! Now, if we had a package structure, I would sure like to see threading and Queue end up as neighbors in the same package. But I don't think it's right to package them all up in the same module. (Not to say that autoloading is a bad idea; I'm -0 on it for myself, but I can see use cases; but it doesn't change my mind on whether Queue should become threading.Queue. I guess I didn't articulate my reasoning for being against that well previously and tried to hide behind the load time argument.) BTW, Queue.Queue violates a recent module naming standard; it is now considered bad style to name the class and the module the same. Modules and packages should have short all-lowercase names, classes should be CapWords. Even the same but different case is bad style. (I'd suggest queueing.Queue except nobody can type that right. :) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
On 10/12/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is the Queue class very useful outside a multithreaded context? No. It was designed specifically for inter-thread communication. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
John Camera writes: It sounds like he feels Queue should just be part of threading but queues can be used in other contexts besides threading. So having separate modules is a good thing. Michael Chermside Perhaps I am wrong here, but the Queue.Queue class is designed specifically for synchronization, and I have always been under the impression that it was probably NOT the best tool for normal queues that have nothing to do with threading. Why incur the overhead of synchronization locks when you don't intend to use them. I would advise against using Queue.Queue in any context besides threading. I haven't used the Queue class before as I normally use a list for a queue. I just assumed a Queue was just a queue that was perhaps optimized for performance. I guess I would have expected the Queue class as defined in the standard library to have a different name if it wasn't just a queue. Well I should have known better than to make assumption on this list. :) I now see where Greg is coming from but I'm still not comfortable having it in the threading module. To me threads and queues are two different beasts. John M. Camara ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
Guido At some level, Queue is just an application of threading, while Guido the threading module provides the basic API ... While Queue is built on top of threading Lock and Condition objects, it is a highly useful synchronization mechanism in its own right, and is almost certainly easier to use correctly (at least for novices) than the lower-level synchronization objects the threading module provides. If threading is the friendly version of thread, perhaps Queue should be considered the friendly synchronization object. (I'm playing the devil's advocate here. I'm fine with Queue being where it is.) Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
Skip write: Is the Queue class very useful outside a multithreaded context? The notion of a queue as a data structure has meaning outside of threaded applications. Its presence might seduce a new programmer into thinking it is subtly different than it really is. A cursory test suggests that it works, though q.get() on a empty queue seems a bit counterproductive. Also, Queue objects are probably quite a bit less efficient than lists. Taken as a whole, perhaps a stronger attachment with the threading module isn't such a bad idea. Maybe Queue belongs in a module called synchronize to avoid any confusions. John M. Camara ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
Maybe Queue belongs in a module called synchronize to avoid any confusions. Why not /just/ make the doc a little bit more explicit ? Instead of saying: It is especially useful in threads programming when information must be exchanged safely between multiple threads. Replace it with: It is dedicated to threads programming for safe exchange of information between multiple threads. On the other hand, if you are only looking for a single-thread queue structure, use the built-in list type, or the deque class from the collections module. If necessary, put it in bold ;) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
On Wed, Oct 12, 2005, Greg Ewing wrote: Guido van Rossum wrote: I see no need. Code that *doesn't* need Queue but does use threading shouldn't have to pay for loading Queue.py. I'd argue that such code is rare enough (given the current emphasis on Queue) that the performance issue doesn't matter. However, it does seem awkward to have a whole module providing just one small class that logically is so closely related to other threading facilities. The problem is that historically Queue did not use ``threading``; it was built directly on top of ``thread``, and people were told to use Queue regardless of whether they were using ``thread`` or ``threading``. Obviously, there is no use case for putting Queue into ``thread``, so off it went into its own module. At this point, my opinion is that we should leave reorganizing the thread stuff until Python 3.0. (Python 3.0 should deprecate ``thread`` by renaming it to ``_thread``). -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ If you think it's expensive to hire a professional to do the job, wait until you hire an amateur. --Red Adair ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
On 10/12/05, Aahz [EMAIL PROTECTED] wrote: (Python 3.0 should deprecate ``thread`` by renaming it to ``_thread``). +1. (We could even start doing this before 3.0.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
Aahz writes: (Python 3.0 should deprecate ``thread`` by renaming it to ``_thread``). Guido says: +1. (We could even start doing this before 3.0.) Before 3.0, let's deprecate it by listing it in the Deprecated modules section within the documentation... no need to gratuitously break code by renaming it until 3.0 arrives. -- Michael Chermside ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
On Wed, Oct 12, 2005, Michael Chermside wrote: Guido says: Aahz writes: (Python 3.0 should deprecate ``thread`` by renaming it to ``_thread``). +1. (We could even start doing this before 3.0.) Before 3.0, let's deprecate it by listing it in the Deprecated modules section within the documentation... no need to gratuitously break code by renaming it until 3.0 arrives. Note carefully the deprecation in quotes. It's not going to be literally deprecated, only renamed, similar to the way _socket and socket work together. We could also rename to _threading, but I prefer the simpler change of only a prepended underscore. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ If you think it's expensive to hire a professional to do the job, wait until you hire an amateur. --Red Adair ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
On 10/12/05, Aahz [EMAIL PROTECTED] wrote: Note carefully the deprecation in quotes. It's not going to be literally deprecated, only renamed, similar to the way _socket and socket work together. We could also rename to _threading, but I prefer the simpler change of only a prepended underscore. Could you specify exactly what you have in mind? How would backwards compatibility be maintained in 2.x? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
On Wed, Oct 12, 2005, Guido van Rossum wrote: On 10/12/05, Aahz [EMAIL PROTECTED] wrote: Note carefully the deprecation in quotes. It's not going to be literally deprecated, only renamed, similar to the way _socket and socket work together. We could also rename to _threading, but I prefer the simpler change of only a prepended underscore. Could you specify exactly what you have in mind? How would backwards compatibility be maintained in 2.x? I'm suggesting that we add a doc note that using the thread module is discouraged and that it will be renamed in 3.0. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ If you think it's expensive to hire a professional to do the job, wait until you hire an amateur. --Red Adair ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
Aahz writes: I'm suggesting that we add a doc note that using the thread module is discouraged and that it will be renamed in 3.0. Then we're apparently all in agreement. -- Michael Chermside ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
Michael Chermside wrote: John, I think what Greg is suggesting is that we include Queue in the threading module, but that we use a Clever Trick(TM) to address Guido's point by not actually loading the Queue code until the first time (if ever) that it is used. I wasn't actually going so far as to suggest doing this, rather pointing out that, if we had an autoloading mechanism, this would be an obvious use case for it. I'm not familiar with the clever trick Greg is proposing, I'll see if I can cook up an example of it to show. Be warned, it is very hackish... -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
I wrote:
I'll see if I can cook up an example of it to show. Be
warned, it is very hackish...
Well, here it is. It's even slightly uglier than I thought
it would be due to the inability to change the class of a
module these days.
When you run it, you should get
Imported my_module
Loading the spam module
Glorious processed meat product!
Glorious processed meat product!
#--
#
# test.py
#
import my_module
print Imported my_module
my_module.spam()
my_module.spam()
#
# my_module.py
#
import autoloading
autoloading.register(__name__, {'spam': 'spam_module'})
#
# spam_module.py
#
print Loading the spam module
def spam():
print Glorious processed meat product!
#
# autoloading.py
#
import sys
class AutoloadingModule(object):
def __getattr__(self, name):
modname = self.__dict__['_autoload'][name]
module = __import__(modname, self.__dict__, {}, [name])
value = getattr(module, name)
setattr(self, name, value)
return value
def register(module_name, mapping):
module = sys.modules[module_name]
m2 = AutoloadingModule()
m2.__name__ = module.__name__
m2.__dict__ = module.__dict__
# Drop all references to the original module before assigning
# the _autoload attribute. Otherwise, when the original module
# gets cleared, _autoload is set to None.
sys.modules[module_name] = m2
del module
m2._autoload = mapping
#--
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
[EMAIL PROTECTED] +--+
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
