[Python-Dev] IEEE/ISO draft on Python vulnerabilities

[Kevin Coyne]

Victor:

Python.3 Type System [IHN] - The use of “extended precision” as a term to 
express Python’s  ability to create and manipulate integers of any size (within 
the memory limitations of the computer) is poor since that term is used in 
reference to floating point numbers almost exclusively. I will change it to 
“unlimited precision” in the revised annex.

Python.16 Wrap‐around Error [XYY] - My source for this is in the Python 
documentation under the 2nd reference to OverflowError in:
http://docs.python.org/py3k/library/exceptions.html?highlight=overflowerror

Python.23 Initialization of Variables [LAV] – Point taken on the unusual syntax 
(I am not a Python programmer) and I will change to the more common syntax s per 
your 2nd suggested syntax.

Python.32 Structured Programming [EWD] – The point I was trying to make was 
that, unlike many early languages, Python has no constructs, like the ones 
mentioned, that can be used to create an unstructured program. I am not 
advocating, nor would it be proper in this kind of paper, that the Python 
language be extended to allow for unstructured statements. I will try to clarify 
this better in the revised version.

Python.51 Undefined Behaviour [EWF] #1 – I need to do more research as your 
example does suggest that mutating, at least, does raise an exception.  Here are 
a few references that claim that this is undefined:
Refer to (10) under:
http://docs.python.org/release/2.4/lib/typesseq-mutable.html

Python.51 Undefined Behaviour [EWF] #2 – In regard to collections.OrderedDict, 
since I am only listing undefined behaviors I don’t think adding a defined 
behaviour here is appropriate.
Python.52 Implementation–defined Behaviour [FAB] – In regard to mixing tabs and 
spaces, I will add your advice to the 52.2 Guidance section
Thanks for your excellent comments; the paper will be improved because of them.

Kevin Coyne
703.901.6774