did the same anyway.
I'm not sure what to do with Tools/compiler/compiler/* -- that isn't part of
distutils, is it ? Should it try to be compatible with old bytecode version ?
The common technique for printing out a pointer has been to cast to a long
and use the "%lx" printf modifier. This is incorrect on Win64 where casting
to a long truncates the pointer. The "%p" formatter should be used instead.
The problem as stated by Tim:
> Unfortunately, the C committee refused to define what %p conversion "looks
> like" -- they explicitly allowed it to be implementation-defined. Older
> versions of Microsoft C even stuck a colon in the middle of the address (in
> the days of segment+offset addressing)!
The result is that the hex value of a pointer will maybe/maybe not have a 0x
prepended to it.
Notes on the patch:
There are two main classes of changes:
- in the various repr() functions that print out pointers
- debugging printf's in the various thread_*.h files (these are why the
patch is large)
Closes SourceForge patch #100505.
For more comments, read the patches@python.org archives.
For documentation read the comments in mymalloc.h and objimpl.h.
(This is not exactly what Vladimir posted to the patches list; I've
made a few changes, and Vladimir sent me a fix in private email for a
problem that only occurs in debug mode. I'm also holding back on his
change to main.c, which seems unnecessary to me.)
Support for the new -U command line option option:
with the option enabled the Python compiler
interprets all "..." strings as u"..." (same with r"..." and
ur"...").
Follow a suggestion in an /*XXX*/ comment [in com_add()] to speed up
compilation by using supplemental dictionaries to keep track of names
and constants, eliminating quadratic behavior. With this patch in
place, the time to import a 5000-line file with lots of constants [at
the global level] is reduced from 20 seconds to under 3 on my system.
comparing code objects. This give sless surprising results in
-Optimized code. It also sorts code objects by name, now.
[I changed the patch to hash() slightly to touch fewer lines.]
executive summary:
Instead of typing 'apply(f, args, kwargs)' you can type 'f(*arg, **kwargs)'.
Some file-by-file details follow.
Grammar/Grammar:
simplify varargslist, replacing '*' '*' with '**'
add * & ** options to arglist
Include/opcode.h & Lib/dis.py:
define three new opcodes
CALL_FUNCTION_VAR
CALL_FUNCTION_KW
CALL_FUNCTION_VAR_KW
Python/ceval.c:
extend TypeError "keyword parameter redefined" message to include
the name of the offending keyword
reindent CALL_FUNCTION using four spaces
add handling of sequences and dictionaries using extend calls
fix function import_from to use PyErr_Format
For a long time I've seen absurd tracebacks under -O (e.g., negative
line numbers), but very rarely. Since I was looking at tracebacks
anyway, thought I'd track it down. Turns out to be Guido's only
predictable blind spot <wink -- "char" is signed on some non-GvR
systems>. Patch follows.
happen when you use a non-keyword argument after a keyword argument,
and in this case you also get a syntax error. I fully suspect that
the underflow is caused by the code that stops generating code when it
detects the syntax error, but I can't find the culprit right now. I
know, I know.)
have a unique name, otherwise they get squished by locals2fast (or
fast2locals, I dunno) when the debugger is invoked before they have
been transferred to real locals.
recognized by the code generator and code generation for the test and
the subsequent suite is suppressed.
One must write *exactly* ``if __debug__:'' or ``elif __debug__:'' --
no parentheses or operators must be present, or the optimization is
not carried through. Whitespace doesn't matter. Other uses of
__debug__ will find __debug__ defined as 0 or 1 in the __builtin__
module.
Thomas Wouters
Guido van Rossum
Peter Schneider-Kamp
Tim Peters
Jack Jansen
Fred Drake
Jeremy Hylton