[issue15863] Fine-grained info about Python versions which support changes introduced in micro releases
Alexander Konovalenko added the comment: Andrew, I don't get it. :( Why not? The docs for Python 2.7 generally inform the reader in which Python version every feature appeared. That's really helpful if your code should run on earlier version of Python. You don't have to dig through the docs for older Python releases and compare them one to another; you can just read the latest docs and all information is there. How is the security patch case different? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15863] Fine-grained info about Python versions which support changes introduced in micro releases
New submission from Alexander Konovalenko: Some security fixes and bug fixes that are simultaneously issued for multiple Python versions require changes to the documentation. I'm now looking at the hash randomization vulnerability that was fixed in 2.6.8 and 2.7.3. The docs always mention the release in which a new feature was added. That's great. But for a security fix such as the bug in question, the set of versions which support it doesn't look like 2.x.y or later. The documentation for the -R command-line option and the PYTHONHASHSEED environment variable says New in version 2.6.8. A reader who is not familiar with the context would infer that those feature are supported in Python 2.7 through 2.7.2, which is not the case. The docs should say New in version 2.6.8 and 2.7.3. http://docs.python.org/using/cmdline.html#cmdoption-R http://docs.python.org/using/cmdline.html#envvar-PYTHONHASHSEED The documentation for the sys.flags.hash_randomization attribute says New in version 2.7.3. Again, that leaves out the version 2.6.8 and future versions in the 2.6.x branch, which presumably support the new attribute. The docs should say New in version 2.6.8 and 2.7.3. http://docs.python.org/library/sys.html#sys.flags Disclaimer: I did not test the relevant micro releases to see whether they actually support those features. Just checked the release dates and applied common sense. If you know of any other micro release bugfixes that were mentioned in the docs, the same considerations apply to them. Please verify the docs are correct, fix them or file appropriate bugs. -- assignee: docs@python components: Documentation messages: 169841 nosy: alexkon, docs@python priority: normal severity: normal status: open title: Fine-grained info about Python versions which support changes introduced in micro releases versions: Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15840] Ambiguity with regard to the effect of accessing a closed IOBase instance
New submission from Alexander Konovalenko: Two pieces of the documentation for io.IOBase seem to contradict each other: At http://docs.python.org/library/io.html#io.IOBase: Note that calling any method (even inquiries) on a closed stream is undefined. Implementations may raise IOError in this case. At http://docs.python.org/library/io.html#io.IOBase.close: Once the file is closed, any operation on the file (e.g. reading or writing) will raise a ValueError. Perhaps the confusion arises in part because it is not clear when a requirement for all IOBase implementations is documented and when the docs merely describe the default behavior of IOBase that implementations are free to override. Those passages are inconsistent on two points: 1) IOError and ValueError are not subclasses one of another. So what should we expect an IOBase implementation to raise? 2) Undefined behavior means literally anything can happen. Technically, that means calling read() or readable() on a closed file (or other kind of stream) could wreak havoc in a totally unrelated part of the system or segfault the Python interpreter. That is definitely a thing to carefully avoid in any production systems. On the other hand, raising an exception, even if we don't know in advance whether it will be ValueError or IOError, is pretty much defined behavior. An exception is easy to deal with and to contain inside a module. So please clarify how dangerous it actually is to access an IOBase stream after it has been closed. -- assignee: docs@python components: Documentation messages: 169660 nosy: alexkon, docs@python priority: normal severity: normal status: open title: Ambiguity with regard to the effect of accessing a closed IOBase instance versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15840 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
