Re: [Python-Dev] Proposed changes to PEP 343
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 turns a generator into a >function that returns a context manager. > > So maybe the decorator should be called 'contextmanagergenerator'. > Or perhaps not, since that's getting rather too much of an > eyeful to parse... 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 generator, even though its really just a factory function that returns generator objects. So technically, the "contextmanager" decorator turns a generator factory function into a context manager factory function. But its easier to simply say that the decorator turns a generator into a context manager, even if that's technically incorrect. 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] Extending tuple unpacking
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, (2, 3), 4, (5, 6) > > if we are to retain today's multi-level consistency. That seems reasonable enough. I'd considered such code bad style though. And are you also > proposing to allow > >a, *b = [1] > > to put the empty list into b, or is that an unpacking error? It does the same as function parameter unpacking does, by making b the empty tuple. > This would allow users to provide an arbitrary number of positionals > rather than having them become keyword arguments. At present it's > difficult to specify that. That's the reasoning behind the "* without a name" idea: def f(a, b, c=default, *, foo=1, bar=2): pass Here, c is a positional argument with a default value, while foo and bar are forced to be keyword arguments. Completely nuts idea #576 wold involve extending this concept past the keyword dict as well to get function default values which aren't arguments: def f(pos1, pos2, pos3=default, *, kw1=1, kw2=2, **, const="Nutty idea"): pass Py> f(const=1) Traceback (most recent call last): File "", line 1, in ? TypeError: f() got an unexpected keyword argument 'const' 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] Making Queue.Queue easier to use
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 libraries which don't provide a proper event-based or select-style interface (which means the calls have to time out periodically in order to respond gracefully to program shutdown requests). However, because Queues are multi-producer, that isn't a problem - I just have to remember to push the shutdown request in through the Queue. Basically, I'd fallen into the "trying-to-write-C-in-Python" trap and I simply didn't notice until I read the responses in this thread :) 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] Extending tuple unpacking
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: http://mail.python.org/pipermail/python-dev/2004-November/050068.html Obviouly, I've changed my views over the last year or so ;) 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] Proposed changes to PEP 343
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 generator, even though its really just a factory >>function that returns generator objects. > > > Not the same. A precise term exists for "g": it's a generator function. > PEP 255 explicitly talks about this: > > "...Note that when > the intent is clear from context, the unqualified name "generator" may > be used to refer either to a generator-function or a generator- > iterator." > > What would the corresponding paragraph be for PEP 343? "...Note that when the intent is clear from context, the unqualified name 'context manager' may be used to refer either to a 'context manager function' or to an actual 'context manager object'. This distinction is primarily relevant for generator-based context managers, and is similar to that between a normal generator-function and a generator-iterator." Basically, a context manager object is an object with __enter__ and __exit__ methods, while the __with__ method itself is a context manager function. 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: > > 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 related to other threading facilities. > > 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 the loading of another > module behind the scenes to provide it. > Bad idea unless it is tied to a namespace. So that users knows where this auto-loaded functionality is coming from. Otherwise it's just as bad as 'from xxx import *'. 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 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 the loading of another > module behind the scenes to provide it. John Camera comments: > Bad idea unless it is tied to a namespace. So that users knows > where this auto-loaded functionality is coming from. Otherwise > it's just as bad as 'from xxx import *'. 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'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. -- 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] Extending tuple unpacking
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 arbitrary number of positionals > rather than having them become keyword arguments. At present it's > difficult to specify that. Antoine Pitrou already responded: > Do you mean it would also be forbidden to invoke a "positional" argument > using its keyword? It would be a huge step back in usability IMO. Some > people like invoking by position (because it's shorter) and some others > prefer invoking by keyword (because it's more explicit). Why should the > implementer of the API have to make a choice for the user of the API ? I strongly agree with Antoine here, but the combination of "keyword arguments after the star": > foo(a, b, c=1, *args, d=2, e=5, **kwargs) > ^ > positionalonly with kw > or with kw with "star without a name": > def f(a, b, c=default, *, foo=1, bar=2): pass > > Here, c is a positional argument with a default value, while foo and bar are > forced to be keyword arguments. is quite tempting. It satisfies Steve by allowing the implementer of the function to require keyword arguments. It satisfies Antoine and myself by also allowing the implementor of the function to permit positional OR keyword use, and making this the default behavior. It is logically consistant. There's just one big problem that I know of: Guido writes: > I've always wanted to write that as > > f(a, b, *args, foo=1, bar=2, **kwds) > > but the current grammar doesn't allow it. Hmm why doesn't the current grammar allow it, and can we fix that? I don't see that it's a limitation of the one-token-lookahead, could we permit this syntax by rearanging bits of the grammer? -- 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] [C++-sig] GCC version compatibility
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 Ludwig wrote: > On Sun, Jul 10, 2005 at 07:41:06PM +0200, "Martin v. Löwis" wrote: > > Maybe. For Python 2.4, feel free to contribute a more complex test. For > > Python 2.5, I would prefer if the entire code around ccpython.cc was > > removed. > > I submitted patch #1239112 that implements the test involving two TUs for > Python 2.4. I plan to work on a more comprehensive patch for Python 2.5 but > that will take some time. I finally had the spare time to look into this problem again and submitted patch #1324762. The proposed patch implements the following: 1) The configure option --with-cxx is renamed --with-cxx-main. This was done to avoid surprising the user by the changed meaning. Furthermore, it is now possible that CXX has a different value than provided by --with-cxx-main, so the old name would have been confusing. 2) The compiler used to translate python's main() function is stored in the configure / Makefile variable MAINCC. By default, MAINCC=$(CC). If --with-cxx-main is given (without an appended compiler name), then MAINCC=$(CXX). If --with-cxx-main= is on the configure command line, then MAINCC=. Additionally, configure sets CXX= unless CXX was already set on the configure command line. 3) The command used to link the python executable is (as before) stored in LINKCC. By default, LINKCC='$(PURIFY) $(MAINCC)', i.e. the linker front-end is the compiler used to translate main(). If necessary, LINKCC can be set on the configure command line in which case it won't be altered. 4) If CXX is not set by the user (on the command line or via --with-cxx-main), then configure tries several likely C++ compiler names. CXX is assigned the first name that refers to a callable program in the system. (CXX is set even if python is built with a C compiler only, so distutils can build C++ extensions.) 5) Modules/ccpython.cc is no longer used and can be removed. I think that makes it possible to build python appropriately on every platform: - By default, python is built with the C compiler only; CXX is assigned the name of a "likely" C++ compiler. This works fine, e.g., on ELF systems like x86 / Linux where python should not have any dependency on the C++ runtime to avoid conflicts with C++ extensions. distutils can still build C++ extensions since CXX names a callable C++ compiler. - On platforms that require main() to be a C++ function if C++ extensions are to be imported, the user can configure python --with-cxx-main. On platforms where one must compile main() with a C++ compiler, but does not need to link the executable with the same compiler, the user can specify both --with-cxx-main and LINKCC on the configure command line. Best regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html ___ 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 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 the loading of another > > module behind the scenes to provide it. > > John Camera comments: > > Bad idea unless it is tied to a namespace. So that users knows > > where this auto-loaded functionality is coming from. Otherwise > > it's just as bad as 'from xxx import *'. > > Michael Chermside comments: > 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'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 guess from Gregs comments Im not sure if he wants to import threading and as a result Queue becomes available in the local namespace and bound/loaded when it is first needed and thus saves himself from typing import Queue immediately after import threading or Queue becomes part of the threading namespace and bound/loaded when it is first needed. Queue then becomes accessible through threading.Queue When Greg says > 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. 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. The idea of delaying an import until its needed sounds like a great idea and having built in support for this would be great. Here are 2 possible suggestions for the import statements import Queue asneeded delayedimport Queue # can't think of a better name at this time But auto loading a module by a module on behalf of a client just doesnt sit too well for me. How about the confusion it would cause. Is Queue in treading module a reference to a Queue in a Queue module or a new class all together? If we go down this slippery slope we will see modules like array, struct, etc getting referenced and getting auto loaded on behalf of the client. Where will it end. John M. Camara > > 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 the loading of another > > module behind the scenes to provide it. > > John Camera comments: > > Bad idea unless it is tied to a namespace. So that users knows > > where this auto-loaded functionality is coming from. Otherwise > > it's just as bad as 'from xxx import *'. > > 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'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. > > -- 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)
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 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. continued... > I guess from Gregs comments Im not sure if he wants to [...] I'm going to stop trying to channel Greg here, he can speak for himself. But I will be quite surprised if _anyone_ supports the idea of having an module modify the local namespace importing it when it is imported. and later... > Here are 2 possible suggestions for the import statements > > import Queue asneeded > delayedimport Queue # can't think of a better name at this time Woah! There is no need for new syntax here! If you want to import Queue only when needed use this (currently legal) syntax: if queueIsNeeded: import Queue If you want to add a module (call it "Queue") to the namespace, but delay executing some of the code for now, then just use "import Queue" and modify the module so that it doesn't do all its work at import time, but delays some of it until needed. That too is possible today: # start of module initialized = False def doSomething(): if not initialized: initialize() # ... Python today is incredibly dynamic and flexible... despite the usual tenor of conversations on python-dev, it is very rare to encounter a problem that cannot be solved (and readably so) using the existing tools and constructs. -- 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
[Python-Dev] Europeans attention please!
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@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> 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 use any Michael> communication mechanism OTHER than Queue or something similar Michael> which has been carefully designed by someone knowlegable. 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. 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)
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] Pythonic concurrency
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 called ZODB. :) Just use the memory backend if you don't want the objects to persist. Granted, if you want automatic retry you'll need to create a decorator that catches conflict errors. But basically, ZODB implements a similar optimistic conflict management transaction algorithm to that described in the paper. Certainly, it's the closest thing you can get in CPython without a complete redesign of the VM. ___ 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] Pythonic concurrency
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. This may actually be one of those people for whom threading is > obvious (and Ian has always seemed like a smart guy, for example). I think it depends on which "level" you're talking about, concurrency IS very easy and "natural" at a conceptual level. It's also quite easy for doing basic stuff ... but it can become very complicated if you introduce different requirements and/or the system becomes complex and/or you're going to implement the actual mechanism. That's my limited experience (personally, I really like concurrency ... and to be honest, some people can't really understand the concept at all while others have no problem so it's a "personal thing" also) ___ 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] Extending tuple unpacking
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 PEP was never actually created: > http://mail.python.org/pipermail/python-dev/2004-November/050068.html > > Obviouly, I've changed my views over the last year or so ;) > > Cheers, > Nick. It looked like the PEP didn't get created because there wasn't enough interest at the time, not because there was anything wrong with the idea. And the motivation was, suprisingly, that this would be discussed again, and here it is. ;-) I reversed my view in the other direction in the past 6 months or so. Mostly because when chaining methods or functions with * and **, my mind (which often doesn't have enough sleep), want's to think they mean the same thing in both ends of the method. For example... (with small correction from the previous example) def div_at(self, *args): return self.__class__(self.div_iter(*args)) This would read better to me if it was. # (just an example, not a sugestion.) def div_at(self, *args): return self.__class__(self.div_iter(/args)) But I may be one of a few that this is a minor annoyance. I wonder if you make '*' work outside of functions arguments lists, if requests to do the same for '**' would follow? Cheers, Ron ___ 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
[Python-Dev] Early PEP draft (For Python 3000?)
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 directly). Also, locals() returns a dict, which implies it can affect the local scope, but quietly ignores changes. Using attribute access to access the local/global namespaces just as that is used in instance namespaces and other modules' namespaces, could reduce the mental footprint of Python. Method: All namespace accesses are attribute accesses, and not direct __dict__ accesses. Thus globals() is replaced by a "module" keyword (or "magic variable"?) that evaluates to the module object. Thus, reading/writing globals in module X, uses getattr/setattr on the module object, just like doing so in module Y would be. locals() would return be replaced by a function that returns the frame object (or a weaker equivalent of a frame object) of the currently running function. This object will represent the local namespace and will allow attribute getting/setting to read/write attributes. Or it can disallow attribute setting. Examples: global x ; x = 1 Replaced by: module.x = 1 or: globals()[x] = 1 Replaced by: setattr(module, x, 1) locals()['x'] = 1 # Quietly fails! Replaced by: frame.x = 1 # Raises error x = locals()[varname] Replaced by: x = getattr(frame, varname) Advantages: - Python becomes more consistent w.r.t namespacing and scopes. Disadvantages: - "module" is already possible by importing one's own module, but that is: * Confusing and unnecessarily requires naming one's self redundantly (Making renaming of the module a bit more difficult). * Not easily possible in a __main__/importable module. * No equivalent for locals() - Automatic script conversion may be difficult in some use cases of globals()/locals() ___ 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
[Python-Dev] Assignment to __class__ of module? (Autoloading? (Making Queue.Queue easier to use))
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 for heap types Have the rules concerning assignent to __class__ been made more restrictive recently? -- 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] Assignment to __class__ of module? (Autoloading? (Making Queue.Queue easier to use))
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'm getting > >TypeError: __class__ assignment: only for heap types > >Have the rules concerning assignent to __class__ been >made more restrictive recently? It happened in Python 2.3, actually. The best way to work around this is to add an instance of your subclass to sys.modules *first*, then call reload() on it to make the normal import process work. PEAK uses this to implement lazy loading. Actually, for your purposes, you might be able to just replace the module object and copy its contents to the new module's dictionary. ___ 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: > 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 related to threading, but is open for the addition of future thread-related features that might arise. -- 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)
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() that clients were required to use instead of just referencing the class, but that would be klunky in the extreme. 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. -- 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)
[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 becomes accessible through > ‘threading.Queue’ Yes. -- 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] Assignment to __class__ of module? (Autoloading? (Making Queue.Queue easier to use))
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 useful if this capability could be regained somehow without breaking things. -- 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
