[I18n-sig] Modified open() builtin (Re: Python Character Model)

[M.-A. Lemburg]

[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 ?

> Right
> 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')

or

f = open(filename, 'w', encoding='mbcs')

There's a little more typing required, but the readability is
unbeatable...

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company:                                        http://www.egenix.com/
Consulting:                                    http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/