This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author David.Layton
Recipients David.Layton, Paolo.Elvati, Stefan.Pfeiffer, bethard, manveru
Date 2012-01-19.12:25:38
SpamBayes Score 5.474841e-10
Marked as misclassified No
Message-id <1326975939.94.0.524131708506.issue13824@psf.upfronthosting.co.za>
In-reply-to
Content
argparse.FileType.__call__ opens the specified file and returns it. This is well documented as an anit-idiom in http://docs.python.org/howto/doanddont.html#exceptions. 

"...a serious problem — due to implementation details in CPython, the file would not be closed when an exception is raised until the exception handler finishes; and, worse, in other implementations (e.g., Jython) it might not be closed at all regardless of whether or not an exception is raised."

Disregarding the above, handling a file which may or may not have been opened depending the users input requires a bit of boilerplate code compared to the usual with-open idiom.  

Additionally, there is no way to prevent FileType from clobbering an existing file when used with write mode. 

Given these issues and others, it seems to me that the usefulness of FileType is outweighed by propensity to encourage bad coding. Perhaps, it would be best if FileType (or some replacement) simply checked that the file exists (when such a check is appropriate), it can be opened in the specified mode, and, curry the call to open (i.e. return lambda: open(string, self._mode, self._bufsize))
History
Date User Action Args
2012-01-19 12:25:40David.Laytonsetrecipients: + David.Layton, bethard, Paolo.Elvati, manveru, Stefan.Pfeiffer
2012-01-19 12:25:39David.Laytonsetmessageid: <1326975939.94.0.524131708506.issue13824@psf.upfronthosting.co.za>
2012-01-19 12:25:39David.Laytonlinkissue13824 messages
2012-01-19 12:25:38David.Laytoncreate