| msg61551 - (view) |
Author: Benjamin Peterson (benjamin.peterson) *  |
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) * |
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) * |
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) * |
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) * |
Date: 2008-01-23 09:31 |
| 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 threadmodule.c. 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) * |
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) * |
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 (http://docs.python.org/lib/module-threading.html), we should elect to take the more pythonic route on this. |
|
|
| msg61618 - (view) |
Author: Raymond Hettinger (rhettinger) * |
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) * |
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 code. Modules that serve as elemental building blocks (like threading, Queue, heapq, etc) need to have fast, clean code with as few dependencies as possible. 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) * |
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) * |
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) * |
Date: 2008-02-24 23:13 |
| I've filed issue 2179 to see if it's possible to make with as fast as try/finally. |
|
|