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 th
Phillip J. Eby wrote:
> At 01:47 PM 10/13/2005 +1300, Greg Ewing wrote:
>
>> I'm trying to change the __class__ of a newly-imported
>> module to a subclass of types.ModuleType
>
> It happened in Python 2.3, actually.
Is there a discussion anywhere about the reason this was
done? It would be usef
[EMAIL PROTECTED] wrote:
> I guess from Greg’s comments I’m not sure if he wants to
>
> import threading
>
> and as a result
>
> ‘Queue’ becomes available in the local namespace
No!!!
> Queue becomes part of the threading namespace and bound/loaded
> when it is first needed. Queue then beco
Michael Chermside wrote:
> # start of module
> initialized = False
>
> def doSomething():
> if not initialized:
> initialize()
But how do you do this if the thing in question is a
class rather than a function?
The module could export a function getSomeClass()
tha
[EMAIL PROTECTED] wrote:
> 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.
All right then, how about putting it in a module called
threadutils or something like that, which is clearly
re
At 01:47 PM 10/13/2005 +1300, Greg Ewing wrote:
>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
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 f
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 fa
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
direc
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:/
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
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 unde
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
> sectio
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 r
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 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
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 does
> 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 w
> 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
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 easi
> 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 specifical
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
> th
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'
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/)
___
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 proba
Michael> I'm not familiar with the clever trick Greg is proposing, but I
Michael> do agree that _IF_ everything else were equal, then Queue seems
Michael> to belong in the threading module. My biggest reason is that I
Michael> think anyone who is new to threading probably shouldn't
I have some 65%-off passes to EuroOSCON which starts next Monday in
Amsterdam. Anybody interested?
http://conferences.oreillynet.com/eurooscon/grid/
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@
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.
Perhaps I am wrong here, but the Queue.Queue class is designed specifically
for synchronization, and I h
> > Guido van Rossum writes:
> > Code that *doesn't* need Queue but does use threading
> > shouldn't have to pay for loading Queue.py.
>
> Greg Ewing responds:
> > What we want in this kind of situation is some sort
> > of autoloading mechanism, so you can import something
> > from a module and ha
Hi,
this is to continue a discussion started back in July by a posting by
Dave Abrahams http://thread.gmane.org/gmane.comp.python.devel/69651>
regarding the compiler (C vs. C++) used to compile python's main() and to link
the executable.
On Sat, Jul 16, 2005 at 12:13:58PM +0200, Christoph Ludwi
Steve Holden writes:
> I do feel that for Python 3 it might be better to make a clean
> separation between keywords and positionals: in other words, of the
> function definition specifies a keyword argument then a keyword must be
> used to present it.
>
> This would allow users to provide an arbitr
> Guido van Rossum writes:
> Code that *doesn't* need Queue but does use threading
> shouldn't have to pay for loading Queue.py.
Greg Ewing responds:
> What we want in this kind of situation is some sort
> of autoloading mechanism, so you can import something
> from a module and have it trigger th
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.
>
> However, it does seem awkward to have a whole module
> providing just one small class that logically is so
> closely relat
Jason Orendorff wrote:
> On 10/12/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
>>Strictly speaking this fits in with the existing confusion of "generator
>>factory" and "generator":
>>
>>Py> def g():
>>... yield None
>>...
>>Py> type(g)
>>
>>Py> type(g())
>>
>>
>>Most people would call "g" a
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:
Guido van Rossum wrote:
> Apart from trying to guess the API without reading the docs (:-), what
> are the use cases for using put/get with a timeout? I have a feeling
> it's not that common.
Actually, I think wanting to use a timeout is an artifact of a history of
dealing with too many C librari
Steve Holden wrote:
> But don't forget that at present unpacking can be used at several levels:
>
> >>> ((a, b), c) = ((1, 2), 3)
> >>> a, b, c
> (1, 2, 3)
> >>>
>
> So presumably you'd need to be able to say
>
>((a, *b), c, *d) = ((1, 2, 3), 4, 5, 6)
>
> and see
>
>a, b, c, d == 1,
Greg Ewing wrote:
> Jason Orendorff wrote:
>
>
>>A contextmanager is a function that returns a new context manager.
>>
>>Okay, that last bit is weird.
>
>
> If the name of the decorator is to be 'contextmanager', it
> really needs to say something like
>
>The contextmanager decorator t
38 matches
Mail list logo
