[issue10968] threading.Timer should be a class so that it can be derived

Roundup Robot added the comment: New changeset 98499371ca53 by R David Murray in branch '3.3': #10968: commit threading doc changes and corresponding whatsnew entry. http://hg.python.org/cpython/rev/98499371ca53 New changeset ad435964fc9c by R David Murray in branch 'default': merge #10968:

[issue10968] threading.Timer should be a class so that it can be derived

R. David Murray added the comment: I have now committed (a revised version of) the doc changes. Like I said in the commit message, it is unfortunate that the underscore names were not kept as aliases and that RLock wasn't also converted to a class, but it is too late to fix that in 3.3. If

[issue10968] threading.Timer should be a class so that it can be derived

Éric Araujo mer...@netwok.org added the comment: Ping. -- keywords: +needs review stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10968 ___

[issue10968] threading.Timer should be a class so that it can be derived

Éric Araujo mer...@netwok.org added the comment: Victor: Yes, I know the doc needs an update, that’s why I posted a patch six weeks ago and asked for a review. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10968

[issue10968] threading.Timer should be a class so that it can be derived

STINNER Victor victor.stin...@haypocalc.com added the comment: that’s why I posted a patch six weeks ago and asked for a review Oh ok, cool, I missed the patches. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10968

[issue10968] threading.Timer should be a class so that it can be derived

STINNER Victor victor.stin...@haypocalc.com added the comment: @eric: The doc has to be updated: http://docs.python.org/dev/library/threading.html#threading.activeCount threading.Condition() A factory function that returns a new condition variable object. A condition variable allows one or

[issue10968] threading.Timer should be a class so that it can be derived

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 7f606223578a by Éric Araujo in branch 'default': Remove indirection in threading (issue #10968). http://hg.python.org/cpython/rev/7f606223578a -- nosy: +python-dev ___

[issue10968] threading.Timer should be a class so that it can be derived

Éric Araujo mer...@netwok.org added the comment: I’ve committed the cleanup to my 3.3 clone and will push this week. Here’s a doc patch. Before my patch, the various classes were documented in two parts: one entry with the factory function (e.g. Thread), without index reference, and one

[issue10968] threading.Timer should be a class so that it can be derived

R. David Murray rdmur...@bitdance.com added the comment: You ought to be able to use either a context directive (I forget its name and syntax), or the full reference syntax (:meth:`~threading.Thread.run`) to make those links work without moving things around. --

[issue10968] threading.Timer should be a class so that it can be derived

Éric Araujo mer...@netwok.org added the comment: You ought to be able to use either a context directive (I forget its name and syntax), Hm, do you mean something similar to currentmodule? or the full reference syntax (:meth:`~threading.Thread.run`) to make those links work without moving

[issue10968] threading.Timer should be a class so that it can be derived

Éric Araujo mer...@netwok.org added the comment: Attached patch removes the indirection functions; the _Verbose shenanigans are left alone. The test suite passes; I haven’t edited the doc yet. -- keywords: +patch Added file: http://bugs.python.org/file22631/threading-classes.diff

[issue10968] threading.Timer should be a class so that it can be derived

Éric Araujo mer...@netwok.org added the comment: One concern expressed on a duplicate report by Martijn van Oosterhout: Note this is a behaviour change. Under the old scheme (Foo is a class) Foo.timerclass = Timer created a method, whereas now it will just assign the class as an

[issue10968] threading.Timer should be a class so that it can be derived

Changes by Giampaolo Rodola' g.rod...@gmail.com: -- nosy: +giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10968 ___ ___

[issue10968] threading.Timer should be a class so that it can be derived

Changes by Eric Smith e...@trueblade.com: -- nosy: +eric.smith title: Timer should be a class so that it can be derived - threading.Timer should be a class so that it can be derived ___ Python tracker rep...@bugs.python.org

[issue10968] threading.Timer should be a class so that it can be derived

Éric Araujo mer...@netwok.org added the comment: Adding Guido, who checked the module in, to nosy. Guido: Could you tell us whether the fake classes in threading.py should stay as is or can be fixed? The whole _Verbose business and Thing/_Thing indirection seem a bit outdated and unneeded.

[issue10968] threading.Timer should be a class so that it can be derived

Guido van Rossum gu...@python.org added the comment: IIRC: The design started out this way because it predates new-style classes. When this was put in one couldn't subclass extension types, and there were plans/hopes to replace some of the lock types with platform-specific built-in versions

[issue10968] threading.Timer should be a class so that it can be derived

R. David Murray rdmur...@bitdance.com added the comment: See also issue 5831. That should probably be closed as a dup of this since this has an explanation. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org