| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
it a Sum.
|
|
|
|
|
|
|
|
| |
another class.
Now "regrtest.py -R:: test_compile" is satisfied.
Will backport.
|
|
|
|
|
| |
allow compiling Python AST objects into code objects
in compile().
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
of in a temp variable (bumps the magic number for pyc files)
|
| |
|
|
|
|
| |
with some help from Georg
|
|
|
|
| |
(mistmatch found by clang).
|
|
|
|
| |
there is no need to emit co_lnotab item when both offsets are zeros.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
in the same code unit. The fix is essentially the same as the fix for a
previous bug identifying 0. and -0.
|
|
|
|
| |
PyObject_FromString() to store a python string in a function level static var.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
optimized the
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New opcode, STORE_MAP saves the compiler from awkward stack manipulations
and specializes for dicts using PyDict_SetItem instead of PyObject_SetItem.
Old disassembly:
0 BUILD_MAP 0
3 DUP_TOP
4 LOAD_CONST 1 (1)
7 ROT_TWO
8 LOAD_CONST 2 ('x')
11 STORE_SUBSCR
12 DUP_TOP
13 LOAD_CONST 3 (2)
16 ROT_TWO
17 LOAD_CONST 4 ('y')
20 STORE_SUBSCR
New disassembly:
0 BUILD_MAP 0
3 LOAD_CONST 1 (1)
6 LOAD_CONST 2 ('x')
9 STORE_MAP
10 LOAD_CONST 3 (2)
13 LOAD_CONST 4 ('y')
16 STORE_MAP
|
| |
|
| |
|
|
|
|
| |
switches (better fix coming soon)
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Note that ast.c still has a mix of tabs and spaces, because it
attempts to use four-space indents for more of the new code.
|
|
|
|
| |
Reported by Mike Verdone.
|
|
|
|
|
| |
Move assembler structure next to assembler code to make it easier to
move it to a separate file.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
I'm undecided if this should be backported to 2.5 or 2.5.1.
Armin suggested to wait (I'm of the same opinion). Thomas W thinks
it's fine to go in 2.5.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
in the byte code and co_consts even if they were not used, ie
immediately popped off the stack.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
| |
to stackdepth_walk it will be dereffed.
Not sure if I found with failmalloc or Klockwork #55.
|
| |
|
| |
|
|
|
|
| |
had more than 255 blank lines. Byte codes need to go first, line #s second.
|
|
|
|
| |
started after line 256.
|
| |
|
| |
|
|
|
|
| |
(thanks to Neal for review)
|
| |
|
|
|
|
|
|
|
|
| |
discussion.
There are two places of documentation that still mention __context__:
Doc/lib/libstdtypes.tex -- I wasn't quite sure how to rewrite that without
spending a whole lot of time thinking about it; and whatsnew, which Andrew
usually likes to change himself.
|
| |
|
| |
|
| |
|
| |
|