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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4