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

[Jeffrey Yasskin]

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]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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 and adds function call 
overhead, the __enter__/__exit dance, and possibly introducing a 
locally scoped variable with the "as" clause.

--
status: pending -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Jeffrey Yasskin]

Changes by Jeffrey Yasskin:


--
nosy: +jyasskin

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Benjamin Peterson]

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]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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/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.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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 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.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Benjamin Peterson]

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 on this.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Amaury Forgeot d'Arc]

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?

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Amaury Forgeot d'Arc]

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
threadmodule.c.

I don't think this module is performance critical. Maybe we can teach
"good practices" there.

--
nosy: +amaury.forgeotdarc

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Christian Heimes]

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: +georg.brandl
status: closed -> pending
title: _threading_local should use with -> Document that with is slower than 
try/finally

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com