RetroSearch Browse

Mon Nov 10 11:34:28 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-November/040152.html

> >>     textfile(path[, mode='r'[, encoding='ascii']]) -> file object
> >> 
> >> or similar.
> >
> > I'm not so sure about that in this case.  There are quite a few places
> > where one writes a wrapper for open() that takes a mode and passes it
> > on to the real open().
> 
> I may just be being thick today but I can't think of many.  Most of
> the time passing in an already on file object would be better
> interface, surely?  Well, there's things like the codec writers, but
> textfile would hopefully subsume them.

Here's a pattern that I use frequently in unit tests:

  def makefile(self, data, mode="wb"):
      fn = tempfile.mktemp()
      self.tempfilenames.append(fn)
      f = open(fn, mode)
      f.write(data)
      f.close()
      return fn

> > Having to distinguish between multiple open() functions would
> > complexify this.
> >
> > OTOH my experimental standard I/O replacement (nondist/sandbox/sio)
> > does a similar thing, by providing different constructors for
> > different functionality (buffering, text translation, low-level I/O
> > basis).
> 
> Does text translation cover unicode issues here?

Yes, the framework should support Unicode encoding/decoding too (but
the implementation doesn't do much of this -- have a look).

--Guido van Rossum (home page: http://www.python.org/~guido/)

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-November/040152.html below:

[Python-Dev] other "magic strings" issues