[I18n-sig] Modified open() builtin (Re: Python Character Model)
Sun, 11 Feb 2001 14:13:23 +0100
[Paul, it would help if you wouldn't always remove important parts
of the quoted messages... people who don't read the whole thread
won't have a chance to follow up]
Paul Prescod wrote:
> Guido van Rossum wrote:
> > ...
> > > open(filename, encoding, [[mode], bytes])
> > >
> > > And the documentation would say:
> > >
> > > "There is an obsolete variant that does not require an encoding string.
> > > This may cause a warning in future versions of Python and be removed
> > > sometime after that."
> > I am appalled at this lack of respect for existing conventions,
> You're the one who told everyone to move from string functions to string
> methods. This is a move of similar scope but for a much more important
> purpose than merely changing coding style.
> > when a
> > simple and obvious alternative (see below) is easily available. I
> > will have a hard time not to take this into account when I finally get
> > to reading up on your proposals.
> There is an important reason that we did not use a keyword argument.
> We (at least some subset of the people in the i18n-sig) want every
> single new instance of the "open" function to declare an encoding.
This doesn't make sense: not all uses of open() target text
information. What encoding information would you put into an
open() which wants to read a JPEG image from a file ?
> now we allow a lot of "ambiguous data" into the system. We do not know
> whether the user meant it to be binary or textual data and so we don't
> know the correct/valid coercions, conversions and operations. We are
> trying to retroactively make an open function that strongly encourages
> (and perhaps finally forces) people to make their intent known.
> The open extension is a backwards compatible way to allow people to move
> from the "old" ambiguous form to the new form. I considered it pretty
> well thought out in terms of backwards and forwards compatibility. We
> could also just invent a new function like "file" or "fileopen" but
> upgrading "open" seemed to show the *most* respect for existing
> conventions (and clutters up builtins the least).
We cannot turn override the mode parameter with an encoding
parameter... why do you believe that this is backwards compatible
in any way ? (Note that mode is an optional parameter!)
The keyword argument approach gives us a much better way to
integrate a new argument into the open() call:
f = open(filename, encoding='mbcs', mode='w')
f = open(filename, 'w', encoding='mbcs')
There's a little more typing required, but the readability is
Python Pages: http://www.lemburg.com/python/