[I18n-sig] Re: Python Character Model

[Paul Prescod]

"Martin v. Loewis" wrote:
> 
> > ...
> > You seem to agree above that file is a better name so I'm not sure why
> > we're still talking about "codec"!
> 
> Because that is how it works in Python 2.0. I'm against moving
> functions around like that, as this gives a clear message that
> python-dev can and will break anything anytime. 

Aliasing a function into builtins would not break anything!

> Please see a recent
> message from Fredrik Lundh who was complaining about this very
> problem: people seem to be fond of breaking other people's code "for
> their own good".

That will happen in the language's evolution. We sometimes make mistakes
that must be fixed later. I think most of us agree that in the year 2001
it is a mistake to have literal strings map to byte strings instead of
character strings. We're going to have to break some code to fix that
mistake. The only question is whether we do it a little at a time like
K&R C->ANSI C->C++ or in a big bang like C++ -> Java or VB to VB.NET. I
prefer the former.

> > Do you have any problems with reusing open with a quasi-mandatory
> > (HIGHLY RECOMMENDED!) encoding argument?
> 
> No, that is certainly better than another builtin. It'd depend on the
> exact signature, though - as you point out, open has already two
> optional arguments. Adding a third one won't fly; it has to be a
> keyword argument, then.

At the bottom of one of my messages I proposed that we insert it as the
second argument. Although the encoding and mode are both strings there
is no syntactic overlap between [rwa][+]?[tb]+ and the set of existent
or proposed encodings. If we merely outlaw encodings with that name then
we can quickly figure out whether the second argument is a mode or an
encoding. So the documented syntax would be

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

 Paul Prescod