Georg Brandl added the comment:
This is now fixed for 2.7 (see #15829); no fix needed for 3.3+.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14502
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14502
___
___
Petri Lehtinen pe...@digip.org added the comment:
The docs of 2.7 and 3.2 still first say that RuntimeError is raised, and then
that a ThreadError is raised:
...
If an attempt is made to release an unlocked lock, a RuntimeError
will be raised.
...
Lock.release()
...
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment:
Re. logging, logging._acquireLock and logging._releaseLock are not part of the
public API and are undocumented at present. The case when _releaseLock does not
raise an error is when threading couldn't be imported, so the _lock variable is
Jim Jewett jimjjew...@gmail.com added the comment:
Vinay,
The current question is what contract locks should follow, and whether
all locks should follow it. Would it be acceptable for
logging._releaseLock to raise a RuntimeError if the lock hadn't
previously been acquired? In other words,
Antoine Pitrou pit...@free.fr added the comment:
The current question is what contract locks should follow, and whether
all locks should follow it. Would it be acceptable for
logging._releaseLock to raise a RuntimeError if the lock hadn't
previously been acquired?
I don't see the point of
Georg Brandl ge...@python.org added the comment:
Agreed. Jim, I think you're trying to get consistency where none is required.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14502
___
Jim Jewett jimjjew...@gmail.com added the comment:
On Fri, Apr 6, 2012 at 10:32 PM, R. David Murray rep...@bugs.python.org wrote:
R. David Murray rdmur...@bitdance.com added the comment:
I, on the other hand, would prefer if it were made part of the API contract
that an
error is raised,
R. David Murray rdmur...@bitdance.com added the comment:
I think dummy_threading should be fixed (but only in 3.3, just in case it
causes any backward compatibility issues with someone's code).
Logging I'd leave to Vinay to decide about.
I'm assuming that if any of the others devs nosy on
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 068a614e9d97 by Sandro Tosi in branch 'default':
Issue #14502: it's RuntimeError on 3.3
http://hg.python.org/cpython/rev/068a614e9d97
--
___
Python tracker
Antoine Pitrou pit...@free.fr added the comment:
On Thu, Apr 5, 2012 at 5:38 PM, Antoine Pitrou rep...@bugs.python.org wrote:
Antoine Pitrou pit...@free.fr added the comment:
Not sure what you're talking about. The doc patch is about unacquired
locks, not locks that someone else
Jim Jewett jimjjew...@gmail.com added the comment:
On Fri, Apr 6, 2012 at 5:57 AM, Antoine Pitrou rep...@bugs.python.org wrote:
Antoine Pitrou pit...@free.fr added the comment:
Not sure what you're talking about. The doc patch is about unacquired
locks, not locks that someone else (another
R. David Murray rdmur...@bitdance.com added the comment:
It doesn't matter *how* you get to the situation where you are releasing a lock
that hasn't been acquired, the point is to document what actually happens when
you do the release. And just yesterday I needed to know this, since I have a
Jim Jewett jimjjew...@gmail.com added the comment:
I have a lock that may or may not be currently held when I release it,
and now I know I can just catch RuntimeError in that case.
Only if you're willing to make assumptions about the threading model and the
source of locks. And I fear the
R. David Murray rdmur...@bitdance.com added the comment:
I, on the other hand, would prefer if it were made part of the API contract
that an error is raised, and to fix any stdlib implementations *of that API*
that don't conform to that. (That is, locks from other modules may well not
follow
New submission from Georg Brandl ge...@python.org:
From d...@python.org:
I recently ran into a situation where I could not be certain that a lock
was currently in the acquired state. I checked the documentation to
determine what would happen if I attempted to release a lock that was
already
Sandro Tosi sandro.t...@gmail.com added the comment:
On Thu, Apr 5, 2012 at 09:06, Georg Brandl rep...@bugs.python.org wrote:
I agree: if we know that a ThreadError will always be raised in this
instance, we should document it as such.
I've already prepared a small patch for that (every
Georg Brandl ge...@python.org added the comment:
What different exceptions are they? Note that thread.error == _thread.error ==
threading.ThreadError. The docs should always use the last one (ThreadError).
--
___
Python tracker
Georg Brandl ge...@python.org added the comment:
Ah, and I missed that apparently on 3.3, _thread.Error is aliased to
RuntimeError. In that case you should use RuntimeError of course :)
--
___
Python tracker rep...@bugs.python.org
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset efeca6ff2751 by Sandro Tosi in branch '2.7':
Issue #14502: release() and unlocked lock generates a ThreadError
http://hg.python.org/cpython/rev/efeca6ff2751
New changeset acea9d95a6d8 by Sandro Tosi in branch '3.2':
Changes by Sandro Tosi sandro.t...@gmail.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14502
___
Jim Jewett jimjjew...@gmail.com added the comment:
At least put the information inside some disclaimers about normally; even the
stdlib has some fake locks that let you release a lock someone else holds. (I
think I found them in in workarounds for threading not being available, such as
the
Antoine Pitrou pit...@free.fr added the comment:
At least put the information inside some disclaimers about normally;
even the stdlib has some fake locks that let you release a lock
someone else holds.
Not sure what you're talking about. The doc patch is about unacquired
locks, not locks
Jim Jewett jimjjew...@gmail.com added the comment:
On Thu, Apr 5, 2012 at 5:38 PM, Antoine Pitrou rep...@bugs.python.org wrote:
Antoine Pitrou pit...@free.fr added the comment:
Not sure what you're talking about. The doc patch is about unacquired
locks, not locks that someone else (another
24 matches
Mail list logo
