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

[Paul Prescod]

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. 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).

 Paul Prescod