Fix SF bug #511603: Error calling str on subclass of int

Explicitly fill in tp_str with the same pointer as tp_repr.

int_mul():  new and vastly simpler overflow checking.  Whether it's
faster or slower will likely vary across platforms, favoring boxes
with fast floating point.  OTOH, we no longer have to worry about
people shipping broken LONG_BIT definitions <0.9 wink>.

Bugfix candidate.
int_repr():  we've never had a buffer big enough to hold the largest
possible result on a 64-bit box.  Now that we're using snprintf instead
of sprintf, this can lead to nonsense results instead of random stack
corruption.

sprintf() to PyOS_snprintf() for buffer overrun avoidance.

float (compare the recent checkin to complex).  Added tests for these.

Both int and long multiplication are changed to be more careful in
their assumptions about when one of the arguments is a sequence: the
assumption that at least one of the arguments must be an int (or long,
respectively) is still held, but the assumption that these don't smell
like sequences is no longer true: a subtype of int or long may well
have a sequence-repeat thingie!

I(0) << whatever, I(0) >> whatever, I(whatever) << 0 and I(whatever) >> 0
optimizations.

calls to PyXXX_CheckExact(X).

e.g., (1L << 40000)/(1L << 40001) returns 0.5, not Inf or NaN or whatever.

integer types, and y must be >= 0.  See discussion at
http://sf.net/tracker/index.php?func=detail&aid=457066&group_id=5470&atid=105470

PEP 238.  Changes:

- add a new flag variable Py_DivisionWarningFlag, declared in
  pydebug.h, defined in object.c, set in main.c, and used in
  {int,long,float,complex}object.c.  When this flag is set, the
  classic division operator issues a DeprecationWarning message.

- add a new API PyRun_SimpleStringFlags() to match
  PyRun_SimpleString().  The main() function calls this so that
  commands run with -c can also benefit from -Dnew.

- While I was at it, I changed the usage message in main() somewhat:
  alphabetized the options, split it in *four* parts to fit in under
  512 bytes (not that I still believe this is necessary -- doc strings
  elsewhere are much longer), and perhaps most visibly, don't display
  the full list of options on each command line error.  Instead, the
  full list is only displayed when -h is used, and otherwise a brief
  reminder of -h is displayed.  When -h is used, write to stdout so
  that you can do `python -h | more'.

Notes:

- I don't want to use the -W option to control whether the classic
  division warning is issued or not, because the machinery to decide
  whether to display the warning or not is very expensive (it involves
  calling into the warnings.py module).  You can use -Werror to turn
  the warnings into exceptions though.

- The -Dnew option doesn't select future division for all of the
  program -- only for the __main__ module.  I don't know if I'll ever
  change this -- it would require changes to the .pyc file magic
  number to do it right, and a more global notion of compiler flags.

- You can usefully combine -Dwarn and -Dnew: this gives the __main__
  module new division, and warns about classic division everywhere
  else.

This uses a slightly wimpy and wasteful approach, but it works. :-)

being passed as both the 2nd and 3rd args).  Regression test will follow.

warning and then redo the operation using long ints.

- Do not compile unicodeobject, unicodectype, and unicodedata if Unicode is disabled
- check for Py_USING_UNICODE in all places that use Unicode functions
- disables unicode literals, and the builtin functions
- add the types.StringTypes list
- remove Unicode literals from most tests.

This introduces:

- A new operator // that means floor division (the kind of division
  where 1/2 is 0).

- The "future division" statement ("from __future__ import division)
  which changes the meaning of the / operator to implement "true
  division" (where 1/2 is 0.5).

- New overloadable operators __truediv__ and __floordiv__.

- New slots in the PyNumberMethods struct for true and floor division,
  new abstract APIs for them, new opcodes, and so on.

I emphasize that without the future division statement, the semantics
of / will remain unchanged until Python 3.0.

Not yet implemented are warnings (default off) when / is used with int
or long arguments.

This has been on display since 7/31 as SF patch #443474.

Flames to /dev/null.

Part of SF patch #434992.

raising an error.  This was one of the two issues that the VPython
folks were particularly problematic for their students.  (The other
one was integer division...)  This implements (my) SF patch #440487.

i_divmod:  New and simpler algorithm.  Old one returned gibberish on most
boxes when the numerator was -sys.maxint-1.  Oddly enough, it worked in the
release (not debug) build on Windows, because the compiler optimized away
some tricky sign manipulations that were incorrect in this case.
Makes you wonder <wink> ...
Bugfix candidate.

- Get rid of int_cmp().

- Renamed Py_TPFLAGS_NEWSTYLENUMBER to Py_TPFLAGS_CHECKTYPES.

now as well.

Changes to error messages to increase consistency & clarity.

This (mostly) closes SourceForge patch #101839.

raise ValueError.  Checked in the patch as far as it went, but also changed
all of ints, longs and floats to raise ZeroDivisionError instead when raising
0 to a negative number.  This is what 754-inspired stds require, as the "true
result" is an infinity obtained from finite operands, i.e. it's a singularity.
Also changed float pow to not be so timid about using its square-and-multiply
algorithm.  Note that what math.pow does is unrelated to what builtin pow
does, and will still vary by platform.

#define'd to an unreasonable value (several recent gcc systems have
misdefined it, causing bogus overflows in integer multiplication).  Nuke
CHAR_BIT entirely.

Add definitions of INT_MAX and LONG_MAX to pyport.h.
Remove includes of limits.h and conditional definitions of INT_MAX
and LONG_MAX elsewhere.

This closes SourceForge patch #101659 and bug #115323.

This should match the situation in the 1.6b1 tree.

comments, docstrings or error messages. I fixed two minor things in
test_winreg.py ("didn't" -> "Didn't" and "Didnt" -> "Didn't").

There is a minor style issue involved: Guido seems to have preferred English
grammar (behaviour, honour) in a couple places. This patch changes that to
American, which is the more prominent style in the source. I prefer English
myself, so if English is preferred, I'd be happy to supply a patch myself ;)

This was a convenient excuse to create the pyport.h file recently
discussed!
Please use new Py_ARITHMETIC_RIGHT_SHIFT when right-shifting a
signed int and you *need* sign-extension.  This is #define'd in
pyport.h, keying off new config symbol SIGNED_RIGHT_SHIFT_ZERO_FILLS.
If you're running on a platform that needs that symbol #define'd,
the std tests never would have worked for you (in particular,
at least test_long would have failed).
The autoconfig stuff got added to Python after my Unix days, so
I don't know how that works.  Would someone please look into doing
& testing an auto-config of the SIGNED_RIGHT_SHIFT_ZERO_FILLS
symbol?  It needs to be defined if & only if, e.g., (-1) >> 3 is
not -1.

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.

is required" (we can't say more because we don't know in which context
it is called).

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.)