[issue1910] Document that with is slower than try/finally

Jeffrey Yasskin added the comment: I've filed issue 2179 to see if it's possible to make with as fast as try/finally. __ Tracker <[EMAIL PROTECTED]> __ _

[issue1910] Document that with is slower than try/finally

Raymond Hettinger added the comment: 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

[issue1910] Document that with is slower than try/finally

Changes by Jeffrey Yasskin: -- nosy: +jyasskin __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue1910] Document that with is slower than try/finally

Benjamin Peterson added the comment: Ok, I see your reasoning. I'm going to start going to through the rest of the library for places with should be used. __ Tracker <[EMAIL PROTECTED]> __

[issue1910] Document that with is slower than try/finally

Raymond Hettinger added the comment: 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/tear

[issue1910] Document that with is slower than try/finally

Raymond Hettinger added the comment: 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 faste

[issue1910] Document that with is slower than try/finally

Benjamin Peterson added the comment: 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 (http://docs.python.org/lib/module-threading.html), we should elect to take the more pythonic route

[issue1910] Document that with is slower than try/finally

Amaury Forgeot d'Arc added the comment: 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? __

[issue1910] Document that with is slower than try/finally

Amaury Forgeot d'Arc added the comment: Raymond, does your comment also apply to change at r60189 ? It is exactly the same thing, in threading.py... OTOH, _threading_local.py is not used by the standard library, except by the dummy_threading module; threading.local normally comes from threadmodu

[issue1910] Document that with is slower than try/finally

Christian Heimes added the comment: 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. -- assignee: -> georg.brandl components: +Documentation -Library (Lib) keywords: -patch nosy: