IEEE/ISO draft on Python vulnerabilities
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