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] 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. shrug 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] 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
