Ron Adam wrote:
I wonder if something like the following would fulfill the need?
Funny you should say that. . .
A pre-PEP propsing itertools.iunpack (amongst other things):
http://mail.python.org/pipermail/python-dev/2004-November/050043.html
And the reason that PEP was never actually created:
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/)
At 02:35 AM 10/12/2005 +, Joshua Spoerri wrote:
that stm paper isn't the end.
there's a java implementation which seems to be exactly what we want:
http://research.microsoft.com/~tharris/papers/2003-oopsla.pdf
There's already a Python implementation of what's described in the
paper. It's
On Fri, 7 Oct 2005 18:47:51 +0200, Bruce Eckel wrote
(in article [EMAIL PROTECTED]):
It's hard to know how to answer. I've met enough brilliant people to
know that it's just possible that the person posting really does
easily grok concurrency issues and thus I must seem irreconcilably
thick.
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
Nick Coghlan wrote:
Ron Adam wrote:
I wonder if something like the following would fulfill the need?
Funny you should say that. . .
A pre-PEP propsing itertools.iunpack (amongst other things):
http://mail.python.org/pipermail/python-dev/2004-November/050043.html
And the reason that
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
I would like to re-suggest a suggestion I have made in the past, but
with a mild difference, and a narrower scope.
Name: Attribute access for all namespaces
Rationale: globals() access is conceptually the same as setting the
module's attributes but uses a different idiom (access of the dict
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 just tried to implement an autoloader using a technique
I'm sure I used in an earlier Python version, but it no
longer seems to be allowed.
I'm trying to change the __class__ of a newly-imported
module to a subclass of types.ModuleType, but I'm getting
TypeError: __class__ assignment: only
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
21 matches
Mail list logo
