[Python-bugs-list] [ python-Feature Requests-784509 ] interpret string argument as filename

[SourceForge.net]

Feature Requests item #784509, was opened at 2003-08-06 18:19
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russ Thompson (russt)
Assigned to: Nobody/Anonymous (nobody)
Summary: interpret string argument as filename

Initial Comment:

I think it would be great if, in general, anywhere
a python function asks for a file object, supplying
a string would be interpreted as a filename.

For example, one can do:
cPickle.dump('mypicklefile', myobject)

instead of:
f=file('mypicklefile','w')
cPickle.dump(f,myobject)
f.close()

Much faster in an interactive session!  And very
easy to implement.  And similarly for cPickle.load()
and lots of other functions.  Pickling of multiple
objects could still be accomplished through the
long form above.

Thanks,
-Russ





----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2003-08-11 22:42

Message:
Logged In: YES 
user_id=357491

My responses to Russ' response:

1) Yes it is supposed to help take programming to a higher level 
of abstraction, but not to the point of where you start to possibly 
question what you are using.  Is it reasonable for Perl to have 
``2+"3"`` equate to 5?  Python has always gone the road of 
"make it obvious about what is happening as long as you don't 
make the programmer have to jump through *too* many hoops".  
I don't see this as a case of having too many hoops to jump 
through.

2)But changing it in only a few places does complicate the API.  
Now, where you knew the function would want a file, you have to 
check whether it accepts a string on top of of a file object.  Usage 
becomes inconsistent in the library and that is no good.  It also 
then requires someone to know the API when reading your code; 
otherwise they might not realize that you are implicitly having the 
function open a file behind the scenes.  This can become important 
on read-only filesystems or where I/O is known to be very 
expensive.

3) But explicit closing is good.  If you don't want it closed then you 
have that option.  It also lets you keep track very easily how 
much file I/O you are doing.

4) See 2.

I understand your motivation, Russ, but I just don't see it as 
Pythonic.  This gets a -1 from me.

----------------------------------------------------------------------

Comment By: Russ Thompson (russt)
Date: 2003-08-11 21:33

Message:
Logged In: YES 
user_id=760126


I appreciate the fact that others have different
opinions than me.  I am confused, however, at 
the logic behind the reasons given.  

1)  "Explicit is better than implicit"
Isn't the point of a high level scripting language
like python to bury the gory details of the program?
Logically, explicit control over everything is 
provided much better by assembly language, not python.

2) "Supporting this everywhere would unnecessarily 
complicate the code"
Absolutely!  I'm not advocating some sort of global
universal solution, but rather on a case by case basis
where it makes sense.  Allowing file specifications
by string adds only a few lines of code in the 
implementation:
   def load(inputfile):
	if isinstance(inputfile, types.StringType):
		fname=inputfile
		inputfile=file(fname,'r')
	else:  fname=None
	....

	if fname!=None: inputfile.close()
This hardly adds a significant level of complication
to the code.  And the goal behind a scripting language
like python should be first to simplify the user's programs,
and only secondarily to simplify the libraries.

3) "the current way supports and encourages explicit file 
closing"
The implementation as in #2 doesn't explicitly open a 
file, and closing it is taken care of by the load()
function.  It's not possible to leave open files floating
about.

4) "munging parameters unnecessarily confuses/complicates 
the API"
All we're really talking about here is function overloading,
where the function behaves slightly differently depending
on the types of its arguments.  This is a well established
concept in object oriented programming, and highly useful.
Can you imagine having to use a different '+' operator
for floats than for integers?

On a higher level, it seems to me that the choice here is 
between adding a few lines of code to the library, or adding
a few lines of code to user's programs.  Given that python
is a language designed to make it easy to write simple 
powerful programs (as opposed to fast programs, or 
numerically
precise programs), the obvious choice seems to me to add
it once to the library rather than many times to user's 
programs.

The functions load() and dump() are convenience functions
anyway, which (implicitly) shield the user from creating
and manipulating a pickling object.  How can it hurt to
make a convenience function more convenient?



----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-08-11 17:52

Message:
Logged In: YES 
user_id=357491

I'm with Raymond.  "Explicit is better than implicit".

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-11 17:49

Message:
Logged In: YES 
user_id=80475

I prefer leaving the functions as they are now because:

* the current way supports and encourages explicit file 
closing 

* supporting this everywhere would unnecessarily complicate 
the code

* munging parameters unnecessarily confuses/complicates 
the API

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470