[Python-Dev] file() vs open(), round 7

[Phillip J. Eby]

At 04:20 PM 12/27/2005 +0100, M.-A. Lemburg wrote:
>Phillip J. Eby wrote:
> > At 02:35 PM 12/27/2005 +0100, Fredrik Lundh wrote:
> >> M.-A. Lemburg wrote:
> >>
> >>>> can we add a opentext factory for file/codecs.open while we're at it ?
> >>> Why a new factory function ? Can't we just redirect to codecs.open()
> >>> in case an encoding keyword argument is passed to open() ?!
> >> I think open is overloaded enough as it is.  Using separate functions for
> >> distinct
> >> use cases is also a lot better than keyword trickery.
> >>
> >> Here's a rough draft:
> >>
> >>     def textopen(name, mode="r", encoding=None):
> >>         if "U" not in mode:
> >>             mode += "U"
> >>         if encoding:
> >>             return codecs.open(name, mode, encoding)
> >>         return file(name, mode)
> >
> > Nice. It should probably also check whether there's a 'b' or 't' in 'mode'
> > and raise an error if so.
>
>Why should it do that ?

It's not necessary if both codecs.open() and file() raise an error when 
there's both a 'U' and a 't' or 'b' in the mode string, I suppose.


>FYI: codecs.open() explicitly adds the 'b' to the mode since
>we don't want the platform text mode interfere with the
>Unicode line breaking.

I think maybe you're confusing the wrapped file's mode with the passed-in 
mode, here.  The passed-in mode should contain at most one of 'b', 't', or 
'U', IIUC.  The mode used for the wrapped file should of course always be 
'b', but that's not visible to the user of the routine.


> > I'd also prefer to call it 'textfile', as that
> > reads more nicely with "for line in textfile(...):" use cases, and it does
> > return a file object.
>
>Nope: open() is only guaranteed to return a file-like object,
>e.g. codecs.open() will return a wrapped version of a file
>object.

I meant it's a "file object" in use case terms, not that isinstance(ob,file).