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
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
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
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
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
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 =
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
[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
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__)
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.
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
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
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
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
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/)
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
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
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
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
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
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
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
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
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
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
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
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
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
28 matches
Mail list logo
