By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,932 Members | 1,908 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,932 IT Pros & Developers. It's quick & easy.

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

P: n/a
I've just spent several very frustrating hours tracking down a bug in
one of my programs. The problem was that I was writing text to a
file, and when I was done I coded

f.close

when I should have been coding

f.close()

with the parentheses.

Although I love Python dearly, the fact that such an easy-to-make
mistake should do nothing useful and do it silently (which, in this
context, means: fail silently) seems to me a bit of a wart.

In any event, does anybody have any suggestions for how a coder could
avoid making such a mistake, or detect it quickly?

I teach the occasional beginning Python class, and I would hate to
have to tell my beginning students to watch out for making this kind
of mistake because it can bite you in a most nasty way.
Jul 18 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
Stephen Ferg wrote:
I've just spent several very frustrating hours tracking down a bug in
one of my programs. The problem was that I was writing text to a
file, and when I was done I coded

f.close

when I should have been coding

f.close()

with the parentheses.

Although I love Python dearly, the fact that such an easy-to-make
mistake should do nothing useful and do it silently (which, in this
context, means: fail silently) seems to me a bit of a wart.

In any event, does anybody have any suggestions for how a coder could
avoid making such a mistake, or detect it quickly?

I teach the occasional beginning Python class, and I would hate to
have to tell my beginning students to watch out for making this kind
of mistake because it can bite you in a most nasty way.


Try pychecker.

<pycheckerfodder.py>
if __name__ == "__name__":
f = file("xxx")
print f.readline(),
f.close
</pycheckerfodder.py>

....> pychecker pycheckerfodder.py
Processing pycheckerfodder...

Warnings...

pycheckerfodder.py:4: Statement appears to have no effect

Peter
Jul 18 '05 #2

P: n/a

Stephen> I've just spent several very frustrating hours tracking down a
Stephen> bug in one of my programs. The problem was that I was writing
Stephen> text to a file, and when I was done I coded

Stephen> f.close

Stephen> when I should have been coding

Stephen> f.close()

Stephen> with the parentheses.

Stephen> In any event, does anybody have any suggestions for how a coder
Stephen> could avoid making such a mistake, or detect it quickly?

Pychecker would probably have warned about this. Given this four-line file:

def bar():
return 5

bar

Pychecker reports:

% pychecker foo.py
name: foo
Processing foo...

Warnings...

foo.py:4: Statement appears to have no effect

Skip

Jul 18 '05 #3

P: n/a
DH
> Stephen> I've just spent several very frustrating hours tracking down a
Stephen> bug in one of my programs. The problem was that I was writing
Stephen> text to a file, and when I was done I coded

Stephen> f.close

Stephen> when I should have been coding

Stephen> f.close()

Stephen> with the parentheses.

Stephen> In any event, does anybody have any suggestions for how a coder
Stephen> could avoid making such a mistake, or detect it quickly?

Pychecker would probably have warned about this. Given this four-line file:


There are numerous common mistakes people making when coding in Python
that the compiler doesn't catch. Case-sensitive errors, errors in
indenting, etc.

I think PyChecker ( http://pychecker.sf.net/ ) should be mentioned in
every beginner tutorial, and should be integrated with every Python IDE.
Before you type anything, type "import pychecker.checker"
Jul 18 '05 #4

P: n/a
"Stephen Ferg" <st***@ferg.org> wrote in message
news:b1**************************@posting.google.c om...
I've just spent several very frustrating hours tracking down a bug in
one of my programs. The problem was that I was writing text to a
file, and when I was done I coded

f.close

when I should have been coding

f.close()

with the parentheses.

Although I love Python dearly, the fact that such an easy-to-make
mistake should do nothing useful and do it silently (which, in this
context, means: fail silently) seems to me a bit of a wart.

In any event, does anybody have any suggestions for how a coder could
avoid making such a mistake, or detect it quickly?

I teach the occasional beginning Python class, and I would hate to
have to tell my beginning students to watch out for making this kind
of mistake because it can bite you in a most nasty way.


I don't know about anyone else, but I'd appreciate a run
time error message when it detects an impossible operation
on a function/bound method/unbound method which has no /
one operand on the top of the stack.

Something simple, like: "Unsupported operation on {function
| unbound method | bound method} with {no | one} operand
detected. Did you forget the empty calling parameter list < () >?"

So far, that would have saved me close to a cumulative
person-week of work!

John Roth
Jul 18 '05 #5

P: n/a
Stephen Ferg wrote:

I've just spent several very frustrating hours tracking down a bug in
one of my programs. The problem was that I was writing text to a
file, and when I was done I coded

f.close

when I should have been coding

f.close()

with the parentheses.

Although I love Python dearly, the fact that such an easy-to-make
mistake should do nothing useful and do it silently (which, in this
context, means: fail silently) seems to me a bit of a wart.


One thing no one has done here yet is to ask about your background
in programming.

Would I be write in guessing that you have used VisualBASIC a lot
in the past? Or perhaps a similar language which allows the type
of function call you would expect with the first form above?

I have *never* made this particular mistake in Python, nor, as
far as I can tell, have any of the several dozen Python programmers
I've hired over the past few years (none of whom have VB backgrounds).

I believe f.close could be a legal call in VB (am I right?) and
I'm guessing that is the reason you are making this mistake.
I doubt it's a common problem for many people, but maybe it is for
those with a particular background.

-Peter
Jul 18 '05 #6

P: n/a
On Thu, 12 Feb 2004 08:55:10 -0500, Peter Hansen <pe***@engcorp.com>
wrote:
Stephen Ferg wrote:

I've just spent several very frustrating hours tracking down a bug in
one of my programs. The problem was that I was writing text to a
file, and when I was done I coded

f.close

when I should have been coding

f.close()

with the parentheses.

Would I be write in guessing that you have used VisualBASIC a lot
in the past? Or perhaps a similar language which allows the type
of function call you would expect with the first form above?

I believe f.close could be a legal call in VB (am I right?) and
I'm guessing that is the reason you are making this mistake.
I doubt it's a common problem for many people, but maybe it is for
those with a particular background.

Pascal, Delphi also use this convention. Personally, I think that
design for a language is strange, but if the language doesn't support
a "pointer to function" or "function" type, there's no ambiguosity to
the compiler. A casual reader of the code can get confused, not
knowing if the code is referring to a function that returns a value,
or a simple attribute. Delphi complicates it further by having
"attributes", which are sort of like a getter/setter used
(syntactically) as if it were an attribute assignment/reference.
Point being it's not just VisualBasic (and Access and VBA). I
think it's not unreasonable that your thought about someone's
background is relevant. I'm from a C background, and never made this
particular mistake.
--dang
Jul 18 '05 #7

P: n/a
Peter Hansen wrote:
...
I have *never* made this particular mistake in Python, nor, as
far as I can tell, have any of the several dozen Python programmers
I've hired over the past few years (none of whom have VB backgrounds).


I make this mistake from time to time although by now I am more fluent
in Python than any other language (and I was never fluent in a language
where you called functions without parens). I also leave off trailing
colons, quotes, etc. It is just laziness. I suspect I would never write:

f.close

(it does stand out like a sore thumb)

But I might write

foo(bar[0].doSomething)

I can usually diagnose these pretty quickly.

Paul Prescod

Jul 18 '05 #8

P: n/a
Paul Prescod wrote:

But I might write

foo(bar[0].doSomething)


Good point. Given that this is much more likely to be deliberate,
it's also more likely to occur as a mistake for those of us who
would "never" write f.close accidentally.

I also leave off the odd colon, though I believe that's the only
such error I've made more than maybe once with Python. Never left
quotes off anything that was supposed to have them, unless it was
strictly a slip of the finger (instead of the mind).

-Peter
Jul 18 '05 #9

P: n/a
Peter Hansen <pe***@engcorp.com> pisze:
Would I be write in guessing that you have used VisualBASIC a lot
in the past? Or perhaps a similar language which allows the type
of function call you would expect with the first form above?


You call Pascal "similar to VB"?

--
Jarek Zgoda
http://jpa.berlios.de/
Jul 18 '05 #10

P: n/a
Jarek Zgoda wrote:

Peter Hansen <pe***@engcorp.com> pisze:
Would I be write in guessing that you have used VisualBASIC a lot
in the past? Or perhaps a similar language which allows the type
of function call you would expect with the first form above?


You call Pascal "similar to VB"?


Yes, in at least this once sense, obviously. Clearly no other similarity
with VB is needed to suffice as a background for someone who makes such
a mistake "commonly", if my theory is correct.

-Peter
Jul 18 '05 #11

P: n/a
>>>>> "Dang" == Dang Griffith <no*****@noemail4u.com> writes:

Dang> I'm from a C background, and never made this particular mistake.

At least in GCC, the compiler will emit a warning when you do that (provided
that you use -Wall), telling you that you've generated a value without using
it. This isn't possible in Python (or did I miss something?), so you never
know how many such subtle problem lies in your program, especially because
forgetting to close a file "normally" won't cause any visible problem (that
is, until you modify the same file somewhere elso and when the program
exits, half of your modifications are gone).

Regards,
Isaac.
Jul 18 '05 #12

P: n/a
Peter Hansen <pe***@engcorp.com> wrote:
Stephen Ferg wrote:
I've just spent several very frustrating hours tracking down a bug in
one of my programs. The problem was that I was writing text to a
file, and when I was done I coded

f.close

when I should have been coding

f.close()

with the parentheses.


One thing no one has done here yet is to ask about your background
in programming.


As a long time Perl programmer I've found myself making exactly that
mistake in Python. In Perl method calls don't need parens if the call
doesn't take any arguments.

However I've also discovered pychecker ;-)

--
Nick Craig-Wood
nc*@axis.demon.co.uk
Jul 18 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.