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

Kevin Coyne kevinjcoyne at hotmail.com
Sat Dec 17 16:54:17 CET 2011


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:

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:

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

More information about the Python-Dev mailing list