Éric Araujo <mer...@netwok.org> added the comment: > Additionally, there is no way to prevent FileType from clobbering an existing > file > when used with write mode. I think this deserves its own feature request: now that Python 3.3 has an “exclusive create” mode, argparse.FileType could gain support for it. Would you open that request?
> Given these issues and others, We have one issue and one missing feature; what are the other issues? > it seems to me that the usefulness of FileType is outweighed by propensity to > encourage bad > coding. I think the problem is not as bad as you paint it. A great number of unclosed file handles may cause problem to some OSes, but that’s it. On the plus side, the fact that argparse accepts for its type argument any callable that can check and convert a string input is simple, clean and works. FileType is needed. In packaging/distutils2 for example we have similar functions that return an open file object and never close it: the responsibility is at a higher level. Other packaging code calling these functions does so in a with statement. It is not evil by nature. The problem here is that FileType may return stdin or stdout, so we can’t just always close the file object (or maybe we can, say using an atexit handler?). > Perhaps, it would be best if FileType (or some replacement) simply checked > that the file exists But then you’d run into race conditions. The only sure was to say if a file can be opened is to open it. ---------- nosy: +eric.araujo title: argparse.FileType opens a file without excepting resposibility for closing it -> argparse.FileType opens a file and never closes it _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13824> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
