summaryrefslogtreecommitdiffstats
path: root/Objects/intobject.c
Commit message (Collapse)AuthorAgeFilesLines
* staticforward bites the dust.Jeremy Hylton2002-07-171-1/+1
| | | | | | | | | | | | | | | The staticforward define was needed to support certain broken C compilers (notably SCO ODT 3.0, perhaps early AIX as well) botched the static keyword when it was used with a forward declaration of a static initialized structure. Standard C allows the forward declaration with static, and we've decided to stop catering to broken C compilers. (In fact, we expect that the compilers are all fixed eight years later.) I'm leaving staticforward and statichere defined in object.h as static. This is only for backwards compatibility with C extensions that might still use it. XXX I haven't updated the documentation.
* Patch #568124: Add doc string macros.Martin v. Löwis2002-06-131-2/+2
|
* Just added comments, and cleared some XXX questions, related to intTim Peters2002-04-281-3/+12
| | | | memory management.
* Make sure that tp_free frees the int the same way as tp_dealloc would.Guido van Rossum2002-04-261-0/+8
| | | | | | | | | This fixes the problem that Barry reported on python-dev: >>> 23000 .__class__ = bool crashes in the deallocator. This was because int inherited tp_free from object, which uses the default allocator. 2.2. Bugfix candidate.
* Add the 'bool' type and its values 'False' and 'True', as described inGuido van Rossum2002-04-031-12/+0
| | | | | | | | | | | | | PEP 285. Everything described in the PEP is here, and there is even some documentation. I had to fix 12 unit tests; all but one of these were printing Boolean outcomes that changed from 0/1 to False/True. (The exception is test_unicode.py, which did a type(x) == type(y) style comparison. I could've fixed that with a single line using issubtype(x, type(y)), but instead chose to be explicit about those places where a bool is expected. Still to do: perhaps more documentation; change standard library modules to return False/True from predicates.
* Bugfix candidate.Guido van Rossum2002-02-011-1/+1
| | | | | | Fix SF bug #511603: Error calling str on subclass of int Explicitly fill in tp_str with the same pointer as tp_repr.
* SF bug #488480: integer multiply to return -max_int-1.Tim Peters2001-12-041-127/+63
| | | | | | | 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>.
* SF bug #487743: test_builtin fails on 64 bit platform.Tim Peters2001-12-011-1/+1
| | | | | | | | 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.
* PyInt_FromString(), int_repr(), int_oct(), int_hex(): Conversion ofBarry Warsaw2001-11-281-5/+7
| | | | sprintf() to PyOS_snprintf() for buffer overrun avoidance.
* Add additional coercion support for "self subtypes" to int, long,Guido van Rossum2001-09-191-1/+12
| | | | float (compare the recent checkin to complex). Added tests for these.
* A fix for SF bug #461546 (bug in long_mul).Guido van Rossum2001-09-151-4/+6
| | | | | | | | | 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!
* More bug 460020. When I is a subclass of int, disable the +I(whatever),Tim Peters2001-09-111-10/+10
| | | | | I(0) << whatever, I(0) >> whatever, I(whatever) << 0 and I(whatever) >> 0 optimizations.
* Replace a few places where X->ob_type was compared to &PyXXX_Type withGuido van Rossum2001-09-111-4/+4
| | | | calls to PyXXX_CheckExact(X).
* Make the error msgs in our pow() implementations consistent.Tim Peters2001-09-051-3/+3
|
* Change long/long true division to return as many good bits as it can;Tim Peters2001-09-041-1/+8
| | | | e.g., (1L << 40000)/(1L << 40001) returns 0.5, not Inf or NaN or whatever.
* Move int_true_divide next to the other division routines.Tim Peters2001-09-041-6/+6
|
* New restriction on pow(x, y, z): If z is not None, x and y must be ofTim Peters2001-09-031-0/+5
| | | | | 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
* Add warning mode for classic division, almost exactly as specified inGuido van Rossum2001-08-311-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix typo: double semicolons.Guido van Rossum2001-08-301-1/+1
|
* Make int, long and float subclassable.Guido van Rossum2001-08-291-7/+40
| | | | This uses a slightly wimpy and wasteful approach, but it works. :-)
* err_ovf(): only raise OverflowError when OverflowWarning was raised.Guido van Rossum2001-08-231-1/+2
|
* int_pow(): Repair typo when passing on to float pow (the 2nd argument wasTim Peters2001-08-231-1/+1
| | | | being passed as both the 2nd and 3rd args). Regression test will follow.
* Change all case where we used to raise OverflowError to issue aGuido van Rossum2001-08-231-56/+88
| | | | warning and then redo the operation using long ints.
* Patch #445762: Support --disable-unicodeMartin v. Löwis2001-08-171-0/+4
| | | | | | | | - 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.
* Implement PEP 238 in its (almost) full glory.Guido van Rossum2001-08-081-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Merge of descr-branch back into trunk.Tim Peters2001-08-021-16/+69
|
* Kill more warnings from the SGI compiler.Fred Drake2001-07-191-1/+1
| | | | Part of SF patch #434992.
* On int to the negative integral power, let float handle it instead ofGuido van Rossum2001-07-121-7/+5
| | | | | | 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.
* SF bug 434186: 0x80000000/2 != 0x80000000>>1Tim Peters2001-06-181-23/+17
| | | | | | | | | 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.
* Use Py_CHARMASK for ctype macros. Fixes bug #232787.Martin v. Löwis2001-03-061-1/+1
|
* Rich comparisons fall-out:Guido van Rossum2001-01-171-14/+1
| | | | | | - Get rid of int_cmp(). - Renamed Py_TPFLAGS_NEWSTYLENUMBER to Py_TPFLAGS_CHECKTYPES.
* Make int a new style number type. Sequence repeat is now done hereNeil Schemenauer2001-01-041-64/+116
| | | | now as well.
* Ka-Ping Yee <ping@lfw.org>:Fred Drake2000-10-241-5/+5
| | | | | | Changes to error messages to increase consistency & clarity. This (mostly) closes SourceForge patch #101839.
* SF bug 115831 and Ping's SF patch 101751, 0.0**-2.0 returns inf rather thanTim Peters2000-10-061-2/+6
| | | | | | | | | | 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.
* Move LONG_BIT from intobject.c to pyport.h. #error if it's already beenTim Peters2000-10-051-8/+0
| | | | | | #define'd to an unreasonable value (several recent gcc systems have misdefined it, causing bogus overflows in integer multiplication). Nuke CHAR_BIT entirely.
* Rationalize use of limits.h, moving the inclusion to Python.h.Fred Drake2000-09-261-12/+0
| | | | | | | | 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.
* REMOVED all CWI, CNRI and BeOpen copyright markings.Guido van Rossum2000-09-011-9/+0
| | | | This should match the situation in the 1.6b1 tree.
* Spelling fixes supplied by Rob W. W. Hooft. All these are fixes in eitherThomas Wouters2000-07-161-1/+1
| | | | | | | | | | 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 ;)
* ANSI-fication of the sources.Fred Drake2000-07-091-89/+38
|
* Cray J90 fixes for long ints.Tim Peters2000-07-081-4/+1
| | | | | | | | | | | | | | | | 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.
* Change copyright notice - 2nd try.Guido van Rossum2000-06-301-6/+0
|
* Change copyright notice.Guido van Rossum2000-06-301-22/+7
|
* Trent Mick <trentm@activestate.com>:Fred Drake2000-06-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Replace PyErr_BadArgument() error in PyInt_AsLong() with "an integerGuido van Rossum2000-05-091-1/+1
| | | | | is required" (we can't say more because we don't know in which context it is called).
* Vladimir Marangozov's long-awaited malloc restructuring.Guido van Rossum2000-05-031-8/+6
| | | | | | | | | | 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.)
* Marc-Andre's third try at this bulk patch seems to work (except thatGuido van Rossum2000-04-051-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | his copy of test_contains.py seems to be broken -- the lines he deleted were already absent). Checkin messages: New Unicode support for int(), float(), complex() and long(). - new APIs PyInt_FromUnicode() and PyLong_FromUnicode() - added support for Unicode to PyFloat_FromString() - new encoding API PyUnicode_EncodeDecimal() which converts Unicode to a decimal char* string (used in the above new APIs) - shortcuts for calls like int(<int object>) and float(<float obj>) - tests for all of the above Unicode compares and contains checks: - comparing Unicode and non-string types now works; TypeErrors are masked, all other errors such as ValueError during Unicode coercion are passed through (note that PyUnicode_Compare does not implement the masking -- PyObject_Compare does this) - contains now works for non-string types too; TypeErrors are masked and 0 returned; all other errors are passed through Better testing support for the standard codecs. Misc minor enhancements, such as an alias dbcs for the mbcs codec. Changes: - PyLong_FromString() now applies the same error checks as does PyInt_FromString(): trailing garbage is reported as error and not longer silently ignored. The only characters which may be trailing the digits are 'L' and 'l' -- these are still silently ignored. - string.ato?() now directly interface to int(), long() and float(). The error strings are now a little different, but the type still remains the same. These functions are now ready to get declared obsolete ;-) - PyNumber_Int() now also does a check for embedded NULL chars in the input string; PyNumber_Long() already did this (and still does) Followed by: Looks like I've gone a step too far there... (and test_contains.py seem to have a bug too). I've changed back to reporting all errors in PyUnicode_Contains() and added a few more test cases to test_contains.py (plus corrected the join() NameError).
* Many changes for Unicode, by Marc-Andre Lemburg.Guido van Rossum2000-03-101-1/+1
|
* In response to one particular complaint on edu-sig, change some errorGuido van Rossum2000-02-151-3/+3
| | | | | | messages from "OverflowError: integer pow()" to "OverflowError: integer exponentiation". (Not that this takes care of the complaint in general that the error messages could be greatly improved. :-)
* The rest of the changes by Trent Mick and Dale Nagata for warning-freeGuido van Rossum2000-01-201-1/+1
| | | | compilation on NT Alpha. Mostly added casts etc.
* Mainlining the string_methods branch. See branch revision logBarry Warsaw1999-10-121-0/+43
| | | | messages for specific changes.