Added checks for integer overflows, contributed by Google. Some are
only available if asserts are left in the code, in cases where they
can't be triggered from Python code.
assert (0, 'message')
An empty tuple does not create a warning. While questionable usage:
assert (), 'message'
should not display a warning. Tested manually.
The warning message could be improved. Feel free to update it.
The mapping between bytecode offsets and source lines (lnotab) did not contain
an entry for the beginning of the loop.
Now it does, and the lnotab can be a bit larger:
in particular, several statements on the same line generate several entries.
However, this does not bother the settrace function, which will trigger only
one 'line' event.
The lnotab seems to be exactly the same as with python2.4.
whole construct away, even when an 'else' clause is present::
while 0:
print("no")
else:
print("yes")
did not generate any code at all.
Now the compiler emits the 'else' block, like it already does for 'if' statements.
Will backport.
Allows dictionaries to be pre-sized (upto 255 elements) saving time lost
to re-sizes with their attendant mallocs and re-insertions.
Has zero effect on small dictionaries (5 elements or fewer), a slight
benefit for dicts upto 22 elements (because they had to resize once
anyway), and more benefit for dicts upto 255 elements (saving multiple
resizes during the build-up and reducing the number of collisions on
the first insertions). Beyond 255 elements, there is no addional benefit.
object's co_consts tuple; add a test to show that the previous behavior (where
these two constants were "collapsed" into one) causes serious malfunctioning.
It seems like this should be a different error than SystemError, but
I don't have any great ideas and SystemError was raised in 2.4 and earlier.
Will backport.
The compiler was checking that there was something on the fblock
stack, but not that there was a loop on the stack. Fixed that and
added a test for the specific syntax error.
Bug fix candidate.
there was no verification that privateobj was a PyString. If it wasn't
a string, this could have allowed a NULL pointer to creep in below and crash.
I wonder if this should be PyString_CheckExact? Must identifiers be strings
or can they be subclasses?
Klocwork #275
on each iteration. I'm not positive this is the best way to handle
this. I'm also not sure that there aren't other cases where
the lnotab is generated incorrectly. It would be great if people
that use pdb or tracing could test heavily.
Also:
* Remove dead/duplicated code that wasn't used/necessary
because we already handled the docstring prior to entering the loop.
* add some debugging code into the compiler (#if 0'd out).
Benjamin Peterson
Amaury Forgeot d'Arc
Antoine Pitrou
Gregory P. Smith
Christian Heimes
Georg Brandl
Neal Norwitz
Nick Coghlan
Brett Cannon
Mark Dickinson
Raymond Hettinger
Alex Martelli
Jeremy Hylton