17

A pretty silly trivial question. The canonical example is f = open('filename'), but

  • f is not very descriptive. After not looking at code in a while, you can forget whether it means "file" or "function f(x)" or "fourier transform results" or something else. EIBTI.
  • In Python, file is already taken by a function.

What else do you use?

endolith
  • 25,479
  • 34
  • 128
  • 192

6 Answers6

8
 data_file
 settings_file
 results_file
 .... etc
endolith
  • 25,479
  • 34
  • 128
  • 192
Aziz
  • 20,065
  • 8
  • 63
  • 69
  • 1
    "Method Names and Instance Variables - Use the function naming rules: lowercase with words separated by underscores as necessary to improve readability." http://www.python.org/dev/peps/pep-0008/ – endolith Sep 13 '09 at 23:50
  • @endolith: You should use my suggestion for Python code. Camel case is Java style. – Unknown Sep 19 '09 at 23:24
  • As I said, "with" doesn't work for me, and "f" is too short and non-descript (which was the whole point of this question). I wish this answer were python style, but it's still the best of the bunch. – endolith Sep 26 '09 at 14:28
6

You can append it to the beginning, Hungarian-like "file_fft".

However, I would try to close file descriptors as soon as possible, and I recommend using the with statement like this so you don't have to worry about closing it, and it makes it easier to not lose track of it.

with open("x.txt") as f:
    data = f.read()
    do something with data
Unknown
  • 45,913
  • 27
  • 138
  • 182
  • 1
    "with" is a great! It has definitely cleaned my code up considerable. You can use it in 2.5 "from __future__ import with_statement" – John Paulett Sep 14 '09 at 04:14
  • The object I'm using to open the file does not work with with statements. "object has no attribute '__exit__'" – endolith Sep 19 '09 at 22:52
  • 2
    @endolith: Then use [`contextlib.closing`](http://docs.python.org/library/contextlib.html#contextlib.closing). – icktoofay Oct 06 '12 at 03:34
4

I'm happy to use f (for either a function OR a file;-) if that identifier's scope is constrained to a pretty small compass (such as with open('zap') as f: would normally portend, say). In general, identifiers with large lexical scopes should be longer and more explicit, ones with lexically small/short scopes/lifespans can be shorter and less explicit, and this applies to open file object just about as much as to any other kind of object!-)

Alex Martelli
  • 854,459
  • 170
  • 1,222
  • 1,395
3

Generally if the scope of a file object is only a few lines, f is perfectly readable - the variable name for the filename in the open call is probably descriptive enough. otherwise something_file is probably a good idea.

Glenjamin
  • 7,150
  • 6
  • 25
  • 26
2

generally I'll use "fp" for a short-lifetime file pointer.

for a longer-lived descriptor, I'll be more descriptive. "fpDebugLog", for example.

timdev
  • 61,857
  • 6
  • 82
  • 92
0

I rather use one of: f, fp, fd.

Sometimes inf / outf for input and output file.

uolot
  • 1,480
  • 1
  • 13
  • 18