Re: [Pysdl-devel] Patch: Python file objects

[Martijn F. <fa...@ve...>]

Mark Baker wrote:
> On Wed, 19 Apr 2000, Martijn Faassen wrote:
> > I think we shouldn't overload the load function too much. Can't we
> > instead have two functions, one to load from a file object, and another
> > to load through a filename? Or perhaps just don't have the last one
> > at at all; it's not hard to create a file object after all. Generally
> > it's better to have multiple functions instead of one function which
> > can receive an argument that can be fundamentally different types (such as
> > strings or file-like objects).
> 
> The load function will remain the same, API wise.

So it'll accept both file objects and filenames. 
That's overloading it. It's confusing if you can put a filename string into
a function *and* a file object. I'd rather have two differently
named functions, one for the filename string, one for the file object.
Or just the latter; it's trivial to do an open() myself, after all.

> For languages like C++, function overloading using different types is common
> place. Though these are through seperate functions, in C++, the internal
> representation to the user of PySDL isn't overly important.

I know C++ allows stuff like this, but that doesn't mean we should
apply it here. :) I think it pollutes the API to do this, and it just
doesn't seem necessary. I understand it already works like that, so in
that case I'm complaining about the current functionality (I haven't
experimented with it yet).

> > Loading from strings directly doesn't seem necessary to me either; you can
> > easily use StringIO or cStringIO to wrap the string up as a file-like
> > object after all?
> 
> I agree. Polluting the API isn't worth the hassle, and its use is fairly
> limited.

But it's already polluted now. :)

This is just confusion:

f = "foo.bmp"
load(f)

and this:

f = "foo.bmp"
f = open(f, "r")
load(f)

It should just accept one and not the other. It shouldn't be too smart and
try to guess what the user meant; Python isn't Perl after all. It should 
complain as soon as it gets a string.

> > From what I understood from the example, it seems 'file like' objects
> > are supported already, as I saw StringIO being used, right?
> 
> In my implementation, file objects are supported. This is a direct type check
> in the module, so it doesn't support non-file objects with the same relative
> API.
> Eric Jacob's patch adds "file-like" object support, via inspecting the object
> passed to the various load functions, and determining if they have
> read/seek/etc methods; this is why StringIO works in his example.

That would indeed be an improvement.

Regards,

Martijn