Mailman 3 March 2008 - Python-ideas

Ideas towards GIL removal
by Greg Ewing July 18, 2008

July 18, 2008

I've been thinking about some ideas for reducing the amount of refcount adjustment that needs to be done, with a view to making GIL removal easier. 1) Permanent objects In a typical Python program there are many objects that are created at the beginning and exist for the life of the program -- classes, functions, literals, etc. Refcounting these is a waste of effort, since they're never going to go away. So perhaps there could be a way of marking such objects as "permanent" or "immortal". … [View More]

8 19

adopt an enum type for the standard library?
by Mark Summerfield April 12, 2008

April 12, 2008

AFAIK if you want enumerations you must either create your own, or use a third party module, or use namedtuple: Files = collections.namedtuple("Files", "minimum maximum")(1, 200) ... x = Files.minimum Using: MINIMUM, MAXIMUM = 1, 200 is often inconvenient, since you might have several different ones. Of course you could do: MIN_FILES = 1 MIN_DIRS = 0 Personally, I like enums and consider them to be a fundamental, but I don't like the above approaches. There is an … [View More]

10 14

dictionary unpacking
by Mathias Panzenböck April 2, 2008

April 2, 2008

Maybe dictionary unpacking would be a nice thing? >>> d = {'foo': 42, 'egg': 23} >>> {'foo': bar, 'egg': spam} = d >>> print bar, spam 42 23 What do you think? Bad idea? Good idea? -panzi

7 9

Lambda again: Anonymous function definition
by Joel Bender March 31, 2008

March 31, 2008

Greg wrote: > What's needed is something very concise and unobtrusive, > such as > > x, y => x + y As inspired by Prolog: x, y :- x + y So this: f = lambda x, y: x ** 2 + y ** 2 Or this: def f(x, y): return x ** 2 + y ** 2 Becomes this: f = x, y :- x ** 2 + y ** 2 And would logically transpose into this: f(x, y) :- x ** 2 + y ** 2 Oooo...this rabbit hole is fun! Joel

3 2

Re: [Python-ideas] lambda
by Malte Helmert March 27, 2008

March 27, 2008

[follow up from py3k.devel list] Neil Toronto wrote: > Yep. In my seven years of CS instruction so far, I've only come across > this once, in a theory of programming languages course. "Lambda" simply > doesn't show up unless you do language theory or program in a Lisp... or > in Python. Since you mention Haskell below: > It's a little less terse than Haskell's "\->" it's worth pointing out that Haskell uses the backslash syntax because it is the nearest ASCII … [View More]

2 1

Lambda again: unnamed arguments
by Giovanni Bajo March 27, 2008

March 27, 2008

Hello, inspired by Greg's post about ideas on making the lambda syntax more concise, like: x,y => x+y I was wondering if using unnamed arguments had already been debated. Something like: \(_1+_2) where basically you're declaring implicitally declaring that your lambda takes two arguments. You wouldn't be able to call them through keyword arguments, nor to accept a variable number of arguments (nor to accept more arguments than they are actually used), but wouldn't it cover … [View More]

2 1

Lib/lib-tk goes away, package tkinter joins in
by Guilherme Polo March 25, 2008

March 25, 2008

Hello, (this is an idea for Python 3) Is there any reason for keeping the directory lib-tk at Lib ? I believe renaming it to tkinter and making it a package would make more sense. Tkinter module's code could then reside into __init__.py maybe. Other change that could be done in this package would be renaming some modules: Dialog -> dialog FileDialog -> filedialog FixTk -> fixtk ... Also, I believe tkSimpleDialog and dialog could be in a single module. There are other modules like … [View More]

2 1

Preparing an existing RPC mechanism for the standard library
by Guilherme Polo March 25, 2008

March 25, 2008

Hello, I've read this idea about "preparing an existing RPC mechanism for the standard library" at StandardLibrary ideas and I would be interested in doing it, but as you all know, including something into stdlib is not exactly easy and shouldn't be anyway. Also I'm not even sure if this idea is still desired. I'm considering the inclusion of rpyc, with appropriate changes (possibly lots). And would like to know your opinions towards this. Thanks, -- -- Guilherme H. Polo Goncalves

6 6

Re: [Python-ideas] [Python-Dev] The Case Against Floating Point ==
by Mark Dickinson March 19, 2008

March 19, 2008

(with apologies for the random extra level of quoting in the below...) > On Thu, Mar 13, 2008 at 11:09 AM, Imri Goldberg <lorgandon(a)gmail.com> > wrote: > > As I said earlier, I'd like static checkers (like Python-Lint) to catch > > this sort of cases, whatever the decision may be. > > > Hmm. Isn't that tricky? How does the static checker decide whether the objects being compared are floats? I guess one could be content with catching some cases where the … [View More]operands to == are clearly floats... Wouldn't you have to have run-time warnings to be really sure of catching all the cases? > > It's already too late for Python 3.0. > > Still, I believe it is worth discussing. > > > Sure. I didn't mean that to come out in quite the dismissive way it did :). Apologies. Maybe a PEP aimed at Python 4.0 is in order. If you're open to the idea of just having some way to enable warnings, it could be much sooner. > > While checking against a==0.0 (and other similar conditions) before > > dividing will indeed protect from outright division by zero, it will > > enlarge any error you will have in the computation. I guess it would be > > better to do the same check for 'a is small' for appropriate values of > > 'small'. > > Still, a check for 0.0 is good enough in some cases: if a is tiny, the large intermediate values may appear and then disappear happily before giving a sensible final result. These are usually the sort of cases where just having division by 0.0 return an infinity would have "just worked" too (making the whole "if" redundant), but that's not (currently!) an option in Python. It's a truism that floating-point equality tests should be avoided, but it's just not true that floating-point equality testing is *always* wrong, and I don't think that Python should make it so. Actually, one of the reasons I thought about this subject in the first > > place, was dict lookup for floating point numbers. It seems to me that > > it's something you just shouldn't do. > > > So your proposal would presumably include making x in dict and x not in dict errors for any float x, regardless of the contents of the dictionary (or list, or set, or frozenset, or...) dict? What would you do about Decimals? A Decimal is just another floating point format (albeit base 10 instead of base 2); so presumably all these warnings/errors should apply equally to Decimal instances? If not, why not? I'm not trying to be negative here---as Aahz says, this is an interesting idea; I'm just trying to understand exactly how things might work. Mark [View Less]

5 14

Faq 4.28 Suggestion -- Trailing comas
by Leszek Dubiel March 18, 2008

March 18, 2008

I would suggest to add question 4.28 to faq. Everybody who learns Python reads that and will not ask questions about "one-element tuples". I have compiled answer from responses to my last question about one-element tuple. Question: Why python allows to put comma at the end of list? This looks ugly and seems to break common rules... Answer: There are may reasons that follow. 1. If you defined multiline dictionary d = { "A": [1, 5], "B": [6, 7], # … [View More]

3 2

Python Pragmas
by Larry Hastings March 15, 2008

March 15, 2008

Recently-ish on c.l.py3k (iirc) folks were discussing how to write a script that exited with a human-friendly warning message if run under an incompatible version of the language. The problem with this code: import sys if sys.version < 3: sys.exit("Sorry, this script needs Python 3000") is that the code only executes once tokenization is finished--if your script uses any incompatible syntax, it will fail in the tokenizer, most likely with an error message that doesn't make … [View More]it particularly clear what is going on. After thinking about the problem for a while, it hit me--this is best expressed as a "pragma". For Python's purposes, I would define a "pragma" as an instruction to the tokenizer / compiler, executed immediately upon its complete tokenization. The use case here is pragma version >= 3 # python version must be less than 3.0 Again, this would be executed immediately, aborting before the tokenizer has a chance to see some old syntax it didn't like. What else might we use "pragma" for? Well, consider that Python already has two specialized syntaxes that are really pragmas: "from __future__ import" and "# -*- coding: ". I think this functionality would be more clearly expressed with a "pragma" syntax, for example: pragma encoding latin-1 pragma enable floatdivision It's a matter of taste, but I've never liked it when languages hide important directives in comments--isn't the compiler supposed to *ignore* comments?--nor do I like how "from __future__ import" doesn't really have anything to do with importing modules. Your tastes may vary. There was some discussion back in 2000 about adding a "pragma" to the language: http://www.python.org/dev/summary/2000-08-2/ It sounds like GvR wasn't wholly against the idea: http://mail.python.org/pipermail/python-dev/2000-August/008840.html But nothing seems to have come of it. The discussion died out in early September of 2000, and I didn't find any subsequent revivals. There was some worry back then that pragmas would be a slippery slope, resulting in increasingly elaborate pragma syntaxes until we--shudder!--wake up one day and have preprocessor macros. I agree that we don't want to go too far down this slippery slope. I have some specific suggestions on how we could obviate the temptation, but they are predicated on having pragmas at all, so I might as well keep quiet until such point as pragmas get traction. If you'd like to discuss this in person--or just give me a good hard slap for even suggesting it--I'm bouncing around PyCon until Wednesday afternoon. I'm the guy with the Facebook logos plastered around his person. Cheers, /larry/ [View Less]

3 2

Re: [Python-ideas] [Python-Dev] The Case Against Floating Point ==
by Neil Toronto March 15, 2008

March 15, 2008

Tiago A.O.A. wrote: > I would suggest something like a ~= b, for "approximately equal to". How > approximately? Well, there would be a default that could be changed > somewhere. > > Don't know if it's all that useful, though. Don't forget a !~ b, a <~ b, and a >~ b, and the associated __sim__, __nsim__, __ltsim__, and __gtsim__ slots. I'm not at all sure how serious I am right now. It's late, and I have fuzzy recollections of how those kinds of things might have been … [View More]

3 2

py3k: adding "print" methods to file-like objects
by Erick Tryzelaar March 15, 2008

March 15, 2008

This might be a minor thing, but I kind of wish that I could write this: sys.stderr.print('first line') sys.stderr.print('another line here') sys.stderr.print('and again') instead of: print('first line', file=sys.stderr) print('another line here', file=sys.stderr) print('and again', file=sys.stderr) As it's a lot easier to read for me. Of course you can always add spaces to make the lines line up, but with a long print statement your eye has to go a long distance to figure out what file, if … [View More]

4 4

One-element tuple
by Leszek Dubiel March 14, 2008

March 14, 2008

2 1

One-element tuple
by Leszek Dubiel March 14, 2008

March 14, 2008

2 1

Re: [Python-ideas] [Python-Dev] The Case Against Floating Point ==
by Aaron Watters March 14, 2008

March 14, 2008

For systems programming I often use floats as timestamps in dictionaries, and in this case I never do calculations and all I care about is "same" or "different", meaning "any single bit difference". If you change the way == works and also follow through and change the way floats in dictionaries work you would probably break very many applications like this. I think any "almost equal" should be implemented using a new method or syntax x~=y rather than break things. - Aaron Watters http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=stdio+stinks

1 0

Re: [Python-ideas] [Python-Dev] The Case Against Floating Point ==
by Imri Goldberg March 13, 2008

March 13, 2008

As per Aahz's suggestion, I'm moving this discussion here, from Python-Dev. (Thanks Aahz!) Mark Dickinson wrote: > On Thu, Mar 13, 2008 at 4:20 AM, Imri Goldberg <lorgandon(a)gmail.com > <mailto:lorgandon@gmail.com>> wrote: > > My suggestion is to do either of the following: > 1. Change floating point == to behave like a valid floating point > comparison. That means using precision and some error measure. > 2. Change floating point == to raise … [View More]an exception, with an error > string > suggesting using precision comparison, or the decimal module. > > > I don't much like either of these; I think option 1 would cause > a lot of confusion and difficulty---it changes a conceptually > simple operation into something more complicated. > > As for option 2., I'd agree that there are situations where having > a warning (not an exception) for floating-point equality (and > inequality) tests might be helpful; but that warning should be > off by default, or at least easily turned off. As I said earlier, I'd like static checkers (like Python-Lint) to catch this sort of cases, whatever the decision may be. > > Some Fortran compilers have such a (compile-time) warning, > I believe. But Fortran's users are much more likely to be > writing the sort of code that cares about this. > > > Since this change is not backwards compatible, I suggest it be added > only to Python 3. > > > It's already too late for Python 3.0. Still, I believe it is worth discussing. > > > 3. Programmers will still need the regular ==: > Maybe, and even then, only for very rare cases. For these, a special > function\method might be used, which could be named floating_exact_eq. > > > I disagree with the 'very rare' here. I've seen, and written, code like: > > if a == 0.0: > # deal with exceptional case > else: > b = c/a > ... > > or similarly, a test (a==b) before doing a division by a-b. That > one's kind of dodgy, by the way: a != b doesn't always guarantee > that a-b is nonzero, though you're okay if you're on an IEEE 754 > platform and a and b are both finite numbers. While checking against a==0.0 (and other similar conditions) before dividing will indeed protect from outright division by zero, it will enlarge any error you will have in the computation. I guess it would be better to do the same check for 'a is small' for appropriate values of 'small'. > > Or what if you wanted to generate random numbers in the open interval > (0.0, 1.0). random.random gives you numbers in [0.0, 1.0), so a > careful programmer might well write: > > while True: > x = random.random() > if x != 0.0: > break > > (A less fussy programmer might just say that the chance > of getting 0.0 is about 1 in 2**53, so it's never going to happen...) > > Other thoughts: > > - what should x == x do? If suggestion no. 1 is accepted, always return True. If no. 2 is accepted, raise an exception. Checking x==x is as meaningful as checking x==y. > - what should > > 1.0 in set([0.0, 1.0, 2.0]) > > and > > 3.0 in set([0.0, 1.0, 2.0]) > > do? > Actually, one of the reasons I thought about this subject in the first place, was dict lookup for floating point numbers. It seems to me that it's something you just shouldn't do. As for your examples, I believe these two should both raise an exception. This is even worse than normal comparison - here you are checking against the hash of a floating point number. So if you do that in the current implementation, there's a good chance you'll get unexpected results. If you do that given the implementation of suggestion 1, you'll have a hard time make set work. > Mark Cheers, Imri. ------------------------- Imri Goldberg www.algorithm.co.il/blogs www.imri.co.il ------------------------- Insert Signature Here ------------------------- [View Less]

2 1

cross platform memory usage high water mark for improved gc?
by Aaron Watters March 11, 2008

March 11, 2008

Hi. Some months ago I complained on the python-list that python gc did too much work for apps that allocate and deallocate lots of structures. In fact one of my apps was spending about 1/3 of its time garbage collecting and not finding anything to collect (before i disabled gc). My proposal was that python should have some sort of a smarter strategy for garbage collection, perhaps involving watching the global high water mark for memory allocation or other tricks. The appropriate response … [View More]

3 10

Re: [Python-ideas] [Python-Dev] PEP Proposal: Revised slice objects & lists use slice objects as indexes
by Neil Toronto March 10, 2008

March 10, 2008

Alexandre Vassalotti wrote: > On Sun, Mar 9, 2008 at 7:21 PM, Forrest Voight <voights(a)gmail.com> wrote: >> This would simplify the handling of list slices. >> >> Slice objects that are produced in a list index area would be different, >> and optionally the syntax for slices in list indexes would be expanded >> to work everywhere. Instead of being containers for the start, end, >> and step numbers, they would be generators, similar to xranges. &… [View More]

2 1

An official complaint regarding the marshal and pickle documentation
by Aaron Watters March 6, 2008

March 6, 2008

I just checked the python site documentation on marshal and pickle and I consider them to be irresponsibly and dangerously misleading. For example. Suppose Mercurial is implemented using pickle.load (I sure hope it isn't -- is it?). 1) I send someone a "patch" for their software claiming it makes their package run faster. 2) That person uses mercurial to "unpack" the patch and mercurial uses pickle.load. BAM! That person's filesystem is GONE! AND I'M NOT ASSUMING THAT THERE IS ANY BUG IN … [View More]

12 18

Re: [Python-ideas] adding a trim convenience function
by Erick Tryzelaar March 6, 2008

March 6, 2008

On Wed, Mar 5, 2008 at 1:30 PM, Matthew Russell <matt.horizon5(a)gmail.com> wrote: > Of couse that should of read: > sites = list(item.strip("http://") for item in sites) {l,r,}strip doesn't actually do what I'm talking about, which confused me for a long time. Consider this simple case: >>> 'abaaabcd'.lstrip('ab') 'cd' ltrim in this case would produce 'aaabcd'. On Wed, Mar 5, 2008 at 1:33 PM, Terry Reedy <tjreedy(a)udel.edu> wrote: > >>> [site.replace(… [View More]

3 3

adding a trim convenience function
by Erick Tryzelaar March 5, 2008

March 5, 2008

I find that when I'm normalizing strings, I end up writing this a lot: sites = ['www.google.com', 'http://python.org', 'www.yahoo.com'] new_sites = [] for site in sites: if site.startswith('http://'): site = site[len('http://'):] new_sites.append(site) But it'd be much nicer if I could use a convenience function trim that would do this for me, so I could just use a comprehension: def ltrim(s, prefix): if s.startswith(prefix): return s[len(prefix):] return s sites = ['www.… [View More]

4 4

new super redux (better late than never?)
by Anthony Tolle March 5, 2008

March 5, 2008

I was looking at the reference implementation in PEP 3135 (New Super), and I was inspired to put together a slightly different implementation that doesn't fiddle with bytecode. I know that the new super() in python 3000 doesn't follow the reference implementation in the PEP, but the code intrigued me enough to offer up this little tidbit, which can be easily be used in python 2.5. What I did was borrow the idea of using a metaclass to do a post-definition fix-up on the methods, but added a … [View More]new function decorator called autosuper_method. Like staticmethod or classmethod, the decorator wraps the function using the non-data descriptor protocol. The method wrapped by the decorator will receive an extra implicit argument (super) inserted before the instance argument (self). One caveat about the decorator: it must be the first decorator in the list (i.e. the outermost wrapper), or else the metaclass will not recognize the wrapped function as an instance of the decorator class. I think this implementation strikes me as more pythonic than the spooky behavior of the new python 3000 super() built-in, and it is more flexible because of the implicit argument design. This allows things like the ability to use the super argument in inner functions without worrying about the 'first argument' assumption of python 3000's super(). The implementation follows, which is also called autosuper in deference to the original reference implementation. It includes a demonstration of some of its flexibility: ------------------------------------------------------------ #!/usr/bin/env python # # autosuper.py class autosuper_method(object): def __init__(self, func, cls=None): self.func = func self.cls = cls def __get__(self, obj, type=None): # return self if self.cls is not set yet if self.cls is None: return self if obj is None: # class binding - assume first argument is instance, # and insert superclass before it def newfunc(*args, **kwargs): if not len(args): raise TypeError('instance argument missing') return self.func(super(self.cls, args[0]), *args, **kwargs) else: # instance binding - insert superclass as first # argument, and instance as second def newfunc(*args, **kwargs): return self.func(super(self.cls, obj), obj, *args, **kwargs) return newfunc class autosuper_meta(type): def __init__(cls, name, bases, clsdict): # set cls attribute of all instances of autosuper_method for v in clsdict: o = getattr(cls, v) if isinstance(o, autosuper_method): o.cls = cls class autosuper(object): __metaclass__ = autosuper_meta if __name__ == '__main__': class A(autosuper): def f(self): return 'A' # Demo - standard use class B(A): @autosuper_method def f(super, self): return 'B' + super.f() # Demo - reference super in inner function class C(A): @autosuper_method def f(super, self): def inner(): return 'C' + super.f() return inner() # Demo - define function before class definition @autosuper_method def D_f(super, self): return 'D' + super.f() class D(B, C): f = D_f # Demo - define function after class definition class E(B, C): pass # don't use @autosuper_method here! The metaclass has already # processed E, so it won't be able to set the cls attribute def E_f(super, self): return 'E' + super.f() # instead, use the extended version of the decorator E.f = autosuper_method(E_f, E) d = D() assert d.f() == 'DBCA' # Instance binding assert D.f(d) == 'DBCA' # Class binding e = E() assert e.f() == 'EBCA' # Instance binding assert E.f(e) == 'EBCA' # Class binding ------------------------------------------------------------ P.S. I know that using the word 'super' as an argument name might be frowned upon, but I'm just copying what I've seen done in the standard python library (e.g. using 'list' as a local variable name :). Anyway, it doesn't really hurt anything unless you wanted to call the original super() built-in from the decorated method, which would kind of defeat the purpose. P.P.S. Something like this might have been offered up already. I've been searching the mail list archives for a while, and found a few reference to using decorators, but didn't find any full implementations. This implementation also has the advantage of being compatible with existing code. [View Less]

2 2

List-comprehension-like extensions in normal for loops
by Adam Atlas March 3, 2008

March 3, 2008

How about letting ordinary for loops contain multiple "for"s and optionally "if"s like in list comprehensions and generator expressions? For example, on a site I was just looking at, it had the line: for record in [ r for r in db if r.name == 'pierre' ]: which could instead be: for record in db if record.name == 'pierre': And of course there could be much more complex ones too. I know you could just do "for x in <some generator expression>" and get the same effect and … [View More]

3 2

Restartable Threads
by Gabriel Grant March 3, 2008

March 3, 2008

Hi everyone, Why is it that threads can't be restarted? I hope this is the right place for this discussion. If this has been (or should be) discussed somewhere else, I apologize: my searches for "restart thread" and similar only turned up statements that restarting threads is impossible, which haven't satiated my curiosity. Is there any fundamental reason why this can't (or shouldn't) be done? If not, what would you think of making thread restartability an option? For those who are … [View More]wondering why I might wish to condemn myself by using threads at all (rather than, say, subprocesses), never mind threads that can be restarted while maintaining state, my use case is as follows: I am performing low-level hardware control through a C API that I have wrapped with ctypes. The main "run"-type C function takes a pointer to a struct in which it stores information about its state. This function blocks while the system is running, but also needs access to the shared memory space, and thus has to be executed in its own thread (I believe - other options welcomed). In order to signal events, the function returns with a signal code. Once the signal has been dealt with, the API specifies that the same C function call be made, passing the pointer to the original struct, so that the system can resume operation where it left off. I'm sure this could be done using a standard thread (although I haven't actually done it) with something like: def myloop(): while not self.ret == 0: self.resume_evt.clear() self.ret = sharedLib.blocking_call(self.c_state_struct) self.signal_evt.set() self.resume_evt.wait() t.Thread(target=myloop) ... do some things ... t.signal_evt.wait() ... deal with the signal ... t.signal_evt.clear() t.resume_evt.set() Or some such ugliness, but it seemed to me that the most natural implementation of such a system would be something more like: class myThread(Thread): def __init__(self): self.c_state_struct = structMaker() Thread.__init__(self) def run(self): self.ret = sharedLib.blocking_call(self.c_state_struct) which would then be executed with: >>> t = myThread() >>> t.start() ... do some other stuff ... >>> t.join() >>> signal_handle(t.ret) # deal with the returned value >>> t.start() # resume operation However this is impossible, since a thread's start() method can only be called once (as explained in [1], [2] and [3] python2.5 raises an assertion error, although as of rev 55785 this has been changed to a RuntimeError). What I have been unable to find explained, however, is why this should/needs to be the case. To see if I could get around this limitation, I initially hacked this together: class myThread(Thread): def __init__(self): self.i = 1 Thread.__init__(self) def start(self): Thread.__init__(self) Thread.start(self) def run(self): print self.i self.i += 1 return self.i to be used as: >>> t = myThread() >>> t.start() >>> t.join() 1 >>> t.start() >>> t.join() 2 Obviously it is not usable in the general case, since it completely clobbers the thread's internal state through the repeated __init__()s, but one could certainly imagine a more delicate implementation that saves the relevant bits and pieces, while resetting those that need it. With that in mind, I had a look into threading.py and, not immediately seeing any reason this couldn't be done, implemented essentially that functionality. The attached patch is implemented against threading.py from trunk. I've also uploaded a patched copy of my threading.py that can be used with python2.5 to [4], if anyone needs that. In order to maintain complete backward compatibility, I've left the default behaviour to have threads behave as they do today, but by initializing them with "restartable=True", start() can be called repeatedly. For example: class Counter(Thread): def run(self): if not hasattr(self, "count"): self.count = 0 else: self.count += 1 could be used with: >>> t = Counter(restartable=True) >>> t.start() >>> t.join() >>> print t.count 0 >>> t.start() >>> t.join() >>> print t.count 1 If an attempt is made to restart the thread while it is executing, it still raises a RuntimeError, which I think makes sense: >>> t = LongThread(restartable=True) >>> t.start() >>> t.start() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "threading.py", line 441, in start raise RuntimeError("thread already started") RuntimeError: thread already started So this _seems_ to work, but I have to admit, I'm somewhat afraid to use it. I can't help but wonder: is it safe, or is it tempting the Gods of parallelism to inflict sudden, multi-threaded death? Less superstitious opinions than my own would be greatly appreciated. Thanks, -Gabriel Note: In addition to the patch, I have attached a few usage examples/test cases, that I should really make into actual unit tests. Some of these are expected to fail, so the file can't be executed directly - the examples should be run in an interpreter. [1]: http://docs.python.org/lib/thread-objects.html [2]: http://mail.python.org/pipermail/python-list/2006-November/415503.html [3]: http://lookherefirst.wordpress.com/2007/12/20/can-i-restart-a-thread-in-pyt… [4]: http://ieeesb.mcmaster.ca/~grantgm/reThread/threading.py [View Less]

4 4