[Python-Dev] Next version of PEP278 - universal newline support - available

[Neal Norwitz]

Guido van Rossum wrote:
> 
> >     Guido> I wonder if it would make sense to put a warning when people use
> >     Guido> f.read(n) on a file opened in text mode?  I think f.read(n) is an
> >     Guido> almost sure sign that they're seeing the file as binary data.
> >     Guido> However, f.read() or f.read(-1) is used to slurp in text as well,
> >     Guido> so should not trigger the warning.
> >
> >     Guido> Opinions?
> >
> > Pass this off to PyChecker?
> >
> > I guess with the presence of PyChecker I'm getting a bit
> > schizophrenic about whether warnings go in the Python byte compiler
> > or in PyChecker.  It warns about so many more things now than the
> > compiler as it stands that it seems to me to be the more natural
> > place to stick new warnings.
> 
> I don't think this is a good match for PyChecker, but I'll leat Neal
> think about that.

A long time ago, there was a feature request to point out 
possible portability problems.  One such problem was open() 
because it can be different with respect to binary/text 
on unix/windows.

I think this warning is a good idea, but I'm not sure what 
should trigger the warning.  That's part of the reason I never 
got around to implementing the portability problems.

In general, it's probably easiest to use pychecker as 
an early warning system.  As soon as new features are 
added into python, we can upgrade pychecker to warn 
about a potential incompatibility.  This should give
people the most time to address potential upgrade problems.

I intend to add warnings for version incompatibilities
as much as possible.

> More importantly, I believe that "official" deprecation warnings
> should come from the Python interpreter, not rely on an add-on tool
> (no matter how nice).

Agreed.

Neal