This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Document that with is slower than try/finally
Type: Stage:
Components: Documentation Versions: Python 2.6
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: georg.brandl Nosy List: amaury.forgeotdarc, benjamin.peterson, christian.heimes, georg.brandl, jyasskin, rhettinger
Priority: low Keywords: easy

Created on 2008-01-22 23:58 by benjamin.peterson, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
_threading_local-with-stmt.diff benjamin.peterson, 2008-01-22 23:58
Messages (12)
msg61551 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-01-22 23:58
I was reading _threading_local and noticed it didn't use the with
statment, yet. So, I cooked up this trivial patch. I hope this isn't to
small. Thanks for your time.
msg61561 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-23 07:04
Thanks! :)
Lot's of code doesn't use the with statement yet. Feel free to
contribute more fixes.
msg61562 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2008-01-23 07:09
I appreciate the patch submission but am going to reject it.  The 
try/finally form is faster.  In general, I think we only want to do 
this in code that isn't performance critical and that would be made 
much cleaner.
msg61572 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-23 09:22
Oh, I didn't know that with is slower than try/finally. It should get
documented that try/finally is better suited than with for performance
critical code.
msg61574 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-01-23 09:31
Raymond, does your comment also apply to change at r60189 ? It is
exactly the same thing, in

OTOH, is not used by the standard library, except by
the dummy_threading module; threading.local normally comes from

I don't think this module is performance critical. Maybe we can teach
"good practices" there.
msg61575 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-01-23 09:35
In ceval.c, the "case WITH_CLEANUP" contains the following lines:
  /* XXX Not the fastest way to call it... */
  x = PyObject_CallFunctionObjArgs(x, u, v, w, NULL);

Maybe this is something not too difficult to improve?
msg61617 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-01-24 03:08
Most platforms use the faster thread.LockType. Correct? Perhaps, since
this module is more a reference implementation and it is pointed to by
the threading docs (,
we should elect to take the more pythonic route on this.
msg61618 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2008-01-24 03:54
Generally we don't document the speed differences between various 
alternatives.  One reason is that relative performance varies across 
releases and platforms.  Another reason is that the rule in this case 
is somewhat generic (inlined code is typically faster than making a 
call to the same code without in-lining.  Us developers are supposed to 
know that sort of thing or time it if we don't.
msg61619 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2008-01-24 04:06
Amaury, please do revert 60189.  There is no reason to destabalize this 
code, slow it down, and introduce new dependencies.

Use of the with-statement is not in and of itself a "best practice".  
Where it really shines is in factoring-away repeated setup/teardown 

Modules that serve as elemental building blocks (like threading, Queue, 
heapq, etc) need to have fast, clean code with as few dependencies as 

Also, we should change/modernize something like asyncore or threading 
with a great deal of care and restraint.  It is too easy to introduce 
hard to find bugs in this code.  It took a long time for this code to 
stabalize and we should enjoy the benefits of its maturity.
msg61658 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-01-24 23:49
Ok, I see your reasoning. I'm going to start going to through the rest
of the library for places with should be used.
msg62889 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2008-02-24 09:19
FWIW, we don't usually document relative speeds (or even O(n) 
performance).  Those things are implementation dependent and can vary 
across releases.

In the case of the with-statement, it would seem self-evident 
that "with" does everything try/finally does and adds function call 
overhead, the __enter__/__exit dance, and possibly introducing a 
locally scoped variable with the "as" clause.
msg62952 - (view) Author: Jeffrey Yasskin (jyasskin) * (Python committer) Date: 2008-02-24 23:13
I've filed issue 2179 to see if it's possible to make with as fast as
Date User Action Args
2022-04-11 14:56:30adminsetgithub: 46205
2008-02-24 23:13:08jyasskinsetmessages: + msg62952
2008-02-24 09:19:13rhettingersetstatus: pending -> closed
messages: + msg62889
2008-02-24 08:04:37jyasskinsetnosy: + jyasskin
2008-01-24 23:49:47benjamin.petersonsetmessages: + msg61658
2008-01-24 04:06:16rhettingersetmessages: + msg61619
2008-01-24 03:54:14rhettingersetmessages: + msg61618
2008-01-24 03:08:02benjamin.petersonsetmessages: + msg61617
2008-01-23 09:35:15amaury.forgeotdarcsetmessages: + msg61575
2008-01-23 09:31:11amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg61574
2008-01-23 09:22:13christian.heimessetstatus: closed -> pending
title: _threading_local should use with -> Document that with is slower than try/finally
nosy: + georg.brandl
messages: + msg61572
assignee: georg.brandl
components: + Documentation, - Library (Lib)
keywords: - patch
2008-01-23 07:09:23rhettingersetstatus: open -> closed
resolution: rejected
messages: + msg61562
nosy: + rhettinger
2008-01-23 07:04:01christian.heimessetpriority: low
keywords: + patch, easy
messages: + msg61561
nosy: + christian.heimes
2008-01-22 23:58:43benjamin.petersoncreate