How to avoid "f.close" (no parens) bug?

[DomF]

"Terry Reedy" <tjreedy at udel.edu> wrote in message
news:mailman.3.1076613168.31398.python-list at python.org...
>
> "Paul Prescod" <paul at prescod.net> wrote in message
> news:402BB684.4010807 at prescod.net...
> > Michael Pyle wrote:
> > > try:
> > >         sys.frozen
> > > except AttributeError:
> > >         options.append( 'debug-on' )
> >
> > A cleaner and probably more efficient way of doing this is:
>
> Since I expect, based on old posts but without testing the current
> interpreter, the fixed cost of hasattr to be between the two costs of
> successful and exception-generating tries (the latter much higher), I
would
> expect relative efficiency to depend on the relative proportion of try
> outcomes.  But the difference should seldom be enough to be a deal
breaker
> either way.
>
> Regardless of speed, I like the below better.  The bare attribute
access is
> a bit jarring to me, though I can see how it might become an in-house
> idiom.
>
> > if not hasattr(sys, "frozen"):
> > options.append("debug-on")
>
> But for similar reasons, even if there were no use for bare names, I
would
> be opposed to breaking the currently simplicity of 'name recalls
object'.
> In any case, a Python compiler cannot, in general, know what type of
object
> a name will be bound to at runtime.  The parens following a name (or
> expression) amount to a behavioral-type promise by the programmer that
the
> resulting object will be callable.  If not, then a *runtime* exception
gets
> raised.  In return, the interpreter promises to make the call if at
all
> possible.
>
> Terry J. Reedy

This rang a bell. try/except vs. hasattr is using in the Python docs as
a timeit example :)

http://www.python.org/doc/current/lib/node397.html

Dom