Commit Graph

150 Commits

Author SHA1 Message Date
Eric Smith a9f7d62480 Backport of PEP 3101, Advanced String Formatting, from py3k.
Highlights:
 - Adding PyObject_Format.
 - Adding string.Format class.
 - Adding __format__ for str, unicode, int, long, float, datetime.
 - Adding builtin format.
 - Adding ''.format and u''.format.
 - str/unicode fixups for formatters.

The files in Objects/stringlib that implement PEP 3101 (stringdefs.h,
unicodedefs.h, formatter.h, string_format.h) are identical in trunk
and py3k.  Any changes from here on should be made to trunk, and
changes will propogate to py3k).
2008-02-17 19:46:49 +00:00
Eric Smith 5e527ebee1 Added PyNumber_ToBase and supporting routines _PyInt_Format and
_PyLong_Format.  In longobject.c, changed long_format to
_PyLong_Format.  In intobject.c, changed uses of PyOS_snprintf to
_PyInt_Format instead.

_PyLong_Format is similar to py3k's routine of the same name, except
it has 2 additional parameters: addL and newstyle.  addL was existing
in long_format, and controls adding the trailing "L".  This is
unneeded in py3k.  newstyle is used to control whether octal prepends
"0" (the pre-2.6 style), or "0o" (the 3.0 sytle).

PyNumber_ToBase is needed for PEP 3127 (Integer Literal Support and
Syntax) and PEP 3101 (Advanced String Formatting).

This changeset does not need merging into py3k.
2008-02-10 01:36:53 +00:00
Christian Heimes 422051a367 Patch #1953
I implemented the function sys._compact_freelists() and C API functions PyInt_/PyFloat_CompactFreeList() to compact the pre-allocated blocks of ints and floats. They allow the user to reduce the memory usage of a Python process that deals with lots of numbers.
The patch also renames sys._cleartypecache to sys._clear_type_cache
2008-02-04 18:00:12 +00:00
Jeffrey Yasskin 9871d8fe22 Continue rolling back pep-3141 changes that changed behavior from 2.5. This
round included:
 * Revert round to its 2.6 behavior (half away from 0).
 * Because round, floor, and ceil always return float again, it's no
   longer necessary to have them delegate to __xxx___, so I've ripped
   that out of their implementations and the Real ABC. This also helps
   in implementing types that work in both 2.6 and 3.0: you return int
   from the __xxx__ methods, and let it get enabled by the version
   upgrade.
 * Make pow(-1, .5) raise a ValueError again.
2008-01-05 08:47:13 +00:00
Jeffrey Yasskin 737c73f96f Make math.{floor,ceil}({int,long}) return float again for backwards
compatibility after r59671 made them return integral types.
2008-01-04 08:01:23 +00:00
Jeffrey Yasskin 2f3c16be73 Backport PEP 3141 from the py3k branch to the trunk. This includes r50877 (just
the complex_pow part), r56649, r56652, r56715, r57296, r57302, r57359, r57361,
r57372, r57738, r57739, r58017, r58039, r58040, and r59390, and new
documentation. The only significant difference is that round(x) returns a float
to preserve backward-compatibility. See http://bugs.python.org/issue1689.
2008-01-03 02:21:52 +00:00
Christian Heimes e93237dfcc #1629: Renamed Py_Size, Py_Type and Py_Refcnt to Py_SIZE, Py_TYPE and Py_REFCNT. Macros for b/w compatibility are available. 2007-12-19 02:37:44 +00:00
Brett Cannon 0153159e67 Add a bunch of GIL release/acquire points in tp_print implementations and for
PyObject_Print().

Closes issue #1164.
2007-09-17 03:28:34 +00:00
Martin v. Löwis 6819210b9e PEP 3123: Provide forward compatibility with Python 3.0, while keeping
backwards compatibility. Add Py_Refcnt, Py_Type, Py_Size, and
PyVarObject_HEAD_INIT.
2007-07-21 06:55:02 +00:00
Neal Norwitz d501d1fbc4 Port rev 55353 from Guido:
Add what looks like a necessary call to PyErr_NoMemory() when PyMem_MALLOC()
fails.

Will backport.
2007-05-16 04:33:50 +00:00
Kristján Valur Jónsson abe1d48d20 As per Armin Rigo's suggestion, remove special handing from intobject.c to deal with the peculiarities of classobject's implementation of the number protocol. The nb_long method of classobject now falls back to nb_int if there is no __long__ attribute present. 2007-05-07 16:46:54 +00:00
Kristján Valur Jónsson f030394de3 Fix problems in x64 build that were discovered by the testsuite:
- Reenable modules on x64 that had been disabled aeons ago for Itanium.
- Cleared up confusion about compilers for 64 bit windows.  There is only Itanium and x64.  Added macros MS_WINI64 and MS_WINX64 for those rare cases where it matters, such as the disabling of modules above.
- Set target platform (_WIN32_WINNT and WINVER) to 0x0501 (XP) for x64, and 0x0400 (NT 4.0) otherwise, which are the targeted minimum platforms.
- Fixed thread_nt.h.  The emulated InterlockedCompareExchange function didn´t work on x64, probaby due to the lack of a "volatile" specifier.  Anyway, win95 is no longer a target platform.
- Itertools module used wrong constant to check for overflow in count()
- PyInt_AsSsize_t couldn't deal with attribute error when accessing the __long__ member.
- PyLong_FromSsize_t() incorrectly specified that the operand were unsigned.

With these changes, the x64 passes the testsuite, for those modules present.
2007-05-03 20:27:03 +00:00
Neal Norwitz ee3a1b5244 Variation of patch # 1624059 to speed up checking if an object is a subclass
of some of the common builtin types.

Use a bit in tp_flags for each common builtin type.  Check the bit
to determine if any instance is a subclass of these common types.
The check avoids a function call and O(n) search of the base classes.
The check is done in the various Py*_Check macros rather than calling
PyType_IsSubtype().

All the bits are set in tp_flags when the type is declared
in the Objects/*object.c files because PyType_Ready() is not called
for all the types.  Should PyType_Ready() be called for all types?
If so and the change is made, the changes to the Objects/*object.c files
can be reverted (remove setting the tp_flags).  Objects/typeobject.c
would also have to be modified to add conditions
for Py*_CheckExact() in addition to each the PyType_IsSubtype check.
2007-02-25 19:44:48 +00:00
Gustavo Niemeyer 37e6502c25 Minor change in int() docstring for proper spacing. 2007-01-10 16:15:48 +00:00
Gustavo Niemeyer a443bc8ec7 Mention in the int() docstring that a base zero has meaning, as
stated in http://docs.python.org/lib/built-in-funcs.html as well.
2007-01-10 16:13:40 +00:00
Georg Brandl 2c1375c8db Bug #1545497: when given an explicit base, int() did ignore NULs
embedded in the string to convert.
2006-10-12 11:27:59 +00:00
Armin Rigo 7ccbca93a2 Forward-port of r52136,52138: a review of overflow-detecting code.
* unified the way intobject, longobject and mystrtoul handle
  values around -sys.maxint-1.

* in general, trying to entierely avoid overflows in any computation
  involving signed ints or longs is extremely involved.  Fixed a few
  simple cases where a compiler might be too clever (but that's all
  guesswork).

* more overflow checks against bad data in marshal.c.

* 2.5 specific: fixed a number of places that were still confusing int
  and Py_ssize_t.  Some of them could potentially have caused
  "real-world" breakage.

* list.pop(x): fixing overflow issues on x was messy.  I just reverted
  to PyArg_ParseTuple("n"), which does the right thing.  (An obscure
  test was trying to give a Decimal to list.pop()... doesn't make
  sense any more IMHO)

* trying to write a few tests...
2006-10-04 12:17:45 +00:00
Martin v. Löwis 820d6ac9d7 Fix integer negation and absolute value to not rely
on undefined behaviour of the C compiler anymore.
Will backport to 2.5 and 2.4.
2006-10-04 05:47:34 +00:00
Tim Peters c10c9d0d6b "Conceptual" merge of rev 51711 from the 2.5 branch.
i_divmod():  As discussed on Python-Dev, changed the overflow
checking to live happily with recent gcc optimizations that
assume signed integer arithmetic never overflows.

This differs from the corresponding change on the 2.5 and 2.4
branches, using a less obscure approach, but one that /may/
tickle platform idiocies in their definitions of LONG_MIN.
The 2.4 + 2.5 change avoided introducing a dependence on
LONG_MIN, at the cost of substantially goofier code.
2006-09-05 02:18:09 +00:00
Neal Norwitz 8a87f5d37e Patch #1538606, Patch to fix __index__() clipping.
I modified this patch some by fixing style, some error checking, and adding
XXX comments.  This patch requires review and some changes are to be expected.
I'm checking in now to get the greatest possible review and establish a
baseline for moving forward.  I don't want this to hold up release if possible.
2006-08-12 17:03:09 +00:00
Skip Montanaro 429433b30b C++ compiler cleanup: bunch-o-casts, plus use of unsigned loop index var in a couple places 2006-04-18 00:35:43 +00:00
Thomas Wouters 9cb28bea04 Fix int() and long() to repr() their argument when formatting the exception,
to avoid confusing situations like:

>>> int("")
ValueError: invalid literal for int():
>>> int("2\n\n2")
ValueError: invalid literal for int(): 2

2

Also report the base used, to avoid:

ValueError: invalid literal for int(): 2

They now report:

>>> int("")
ValueError: invalid literal for int() with base 10: ''
>>> int("2\n\n2")
ValueError: invalid literal for int() with base 10: '2\n\n2'
>>> int("2", 2)
ValueError: invalid literal for int() with base 2: '2'

(Reporting the base could be avoided when base is 10, which is the default,
but hrm.) Another effect of these changes is that the errormessage can be
longer; before, it was cut off at about 250 characters. Now, it can be up to
four times as long, as the unrepr'ed string is cut off at 200 characters,
instead.

No tests were added or changed, since testing for exact errormsgs is (pardon
the pun) somewhat errorprone, and I consider not testing the exact text
preferable. The actually changed code is tested frequent enough in the
test_builtin test as it is (120 runs for each of ints and longs.)
2006-04-11 23:50:33 +00:00
Anthony Baxter 377be11ee1 More C++-compliance. Note especially listobject.c - to get C++ to accept the
PyTypeObject structures, I had to make prototypes for the functions, and
move the structure definition ahead of the functions. I'd dearly like a better
way to do this - to change this would make for a massive set of changes to
the codebase.

There's still some warnings - this is purely to get rid of errors first.
2006-04-11 06:54:30 +00:00
Georg Brandl 347b30042b Remove unnecessary casts in type object initializers. 2006-03-30 11:57:00 +00:00
Guido van Rossum 38fff8c4e4 Checking in the code for PEP 357.
This was mostly written by Travis Oliphant.
I've inspected it all; Neal Norwitz and MvL have also looked at it
(in an earlier incarnation).
2006-03-07 18:50:55 +00:00
Thomas Wouters 8b87a0b5fc Use %ld and casts to long for refcount printing, in absense of a universally
available %zd format character. Mark with an XXX comment so we can fix this,
later.
2006-03-01 05:41:20 +00:00
Martin v. Löwis 15e62742fa Revert backwards-incompatible const changes. 2006-02-27 16:46:16 +00:00
Georg Brandl 418a1ef089 RFE #1436243: make integers in [0..256] preallocated. 2006-02-22 11:30:06 +00:00
Thomas Wouters b1410fb433 Avoid unused variables when SIZEOF_SIZE_T == SIZEOF_LONG. Also normalize
whitespace.
2006-02-15 23:08:56 +00:00
Martin v. Löwis 18e165558b Merge ssize_t branch. 2006-02-15 17:27:45 +00:00
Jeremy Hylton af68c874a6 Add const to several API functions that take char *.
In C++, it's an error to pass a string literal to a char* function
without a const_cast().  Rather than require every C++ extension
module to put a cast around string literals, fix the API to state the
const-ness.

I focused on parts of the API where people usually pass literals:
PyArg_ParseTuple() and friends, Py_BuildValue(), PyMethodDef, the type
slots, etc.  Predictably, there were a large set of functions that
needed to be fixed as a result of these changes.  The most pervasive
change was to make the keyword args list passed to
PyArg_ParseTupleAndKewords() to be a const char *kwlist[].

One cast was required as a result of the changes:  A type object
mallocs the memory for its tp_doc slot and later frees it.
PyTypeObject says that tp_doc is const char *; but if the type was
created by type_new(), we know it is safe to cast to char *.
2005-12-10 18:50:16 +00:00
Brett Cannon c3647ac93e Make subclasses of int, long, complex, float, and unicode perform type
conversion using the proper magic slot (e.g., __int__()).  Also move conversion
code out of PyNumber_*() functions in the C API into the nb_* function.

Applied patch #1109424.  Thanks Walter Doewald.
2005-04-26 03:45:26 +00:00
Tim Peters c885443479 Stop producing or using OverflowWarning. PEP 237 thought this would
happen in 2.3, but nobody noticed it still was getting generated (the
warning was disabled by default).  OverflowWarning and
PyExc_OverflowWarning should be removed for 2.5, and left notes all over
saying so.
2004-08-25 02:14:08 +00:00
Neil Schemenauer 3a313e3655 Check the type of values returned by __int__, __float__, __long__,
__oct__, and __hex__.  Raise TypeError if an invalid type is
returned.  Note that PyNumber_Int and PyNumber_Long can still
return ints or longs.  Fixes SF bug #966618.
2004-07-19 16:29:17 +00:00
Raymond Hettinger a006c37472 SF bug #980419: int left-shift causes memory leak 2004-06-26 23:22:57 +00:00
Andrew M. Kuchling 41627bf78d Reword message 2004-06-05 19:49:12 +00:00
Andrew M. Kuchling 204d7861df Fix exception wording 2004-06-05 19:29:41 +00:00
Raymond Hettinger b32e640489 SF patch #875689: >100k alloc wasted on startup
(Contributed by Mike Pall.)

Make sure fill_free_list() is called only once rather than 106 times
when pre-allocating small ints.
2004-02-08 18:54:37 +00:00
Guido van Rossum 6c9e130524 - Removed FutureWarnings related to hex/oct literals and conversions
and left shifts.  (Thanks to Kalle Svensson for SF patch 849227.)
  This addresses most of the remaining semantic changes promised by
  PEP 237, except for repr() of a long, which still shows the trailing
  'L'.  The PEP appears to promise warnings for operations that
  changed semantics compared to Python 2.3, but this is not
  implemented; we've suffered through enough warnings related to
  hex/oct literals and I think it's best to be silent now.
2003-11-29 23:52:13 +00:00
Michael W. Hudson 71665dc90d Add a couple of decrefs to error paths.
Now test_descr only appears to leak two references & I think this
are in fact illusory (it's to do with things getting resurrected in
__del__ methods & it's easy to be believe confusion occurs when that
happens <wink>).  Woohoo!
2003-08-11 17:32:02 +00:00
Raymond Hettinger f466793fcc SF patch 703666: Several objects don't decref tmp on failure in subtype_new
Submitted By: Christopher A. Craig

Fillin some missing decrefs.
2003-06-28 20:04:25 +00:00
Thomas Heller a4ea603b05 SF # 595026: support for masks in getargs.c.
New functions:
  unsigned long PyInt_AsUnsignedLongMask(PyObject *);
  unsigned PY_LONG_LONG) PyInt_AsUnsignedLongLongMask(PyObject *);
  unsigned long PyLong_AsUnsignedLongMask(PyObject *);
  unsigned PY_LONG_LONG) PyLong_AsUnsignedLongLongMask(PyObject *);

New and changed format codes:

b unsigned char 0..UCHAR_MAX
B unsigned char none **
h unsigned short 0..USHRT_MAX
H unsigned short none **
i int INT_MIN..INT_MAX
I * unsigned int 0..UINT_MAX
l long LONG_MIN..LONG_MAX
k * unsigned long none
L long long LLONG_MIN..LLONG_MAX
K * unsigned long long none

Notes:

* New format codes.

** Changed from previous "range-and-a-half" to "none"; the
range-and-a-half checking wasn't particularly useful.

New test test_getargs2.py, to verify all this.
2003-04-17 18:55:45 +00:00
Thomas Heller 850566b644 Strange control flow in PyInt_AsLong. When nb_int is called inside
the PyInt_AsLong function, and this returns a long, the value is first
retrieved with PyLong_AsLong, but afterwards overwritten by a call to
PyInt_AS_LONG.

Fixes SF #690253.
2003-02-20 20:32:11 +00:00
Guido van Rossum 47710656e5 Issue a warning when int('0...', 0) returns an int with the sign
folded; this will change in Python 2.4.  On a 32-bit machine, this
happens for 0x80000000 through 0xffffffff, and for octal constants in
the same value range.  No warning is issued if an explicit base is
given, *or* if the string contains a sign (since in those cases no
sign folding ever happens).
2003-02-12 20:48:22 +00:00
Neal Norwitz de8b94c3e1 Fix SF bug #683467, 'int' ability to generate longs not inherited
When subclassing from an int but not overriding __new__,
long values were not converted properly.  Try to convert
longs into an int.
2003-02-10 02:12:43 +00:00
Guido van Rossum 5d9113d8be Implement appropriate __getnewargs__ for all immutable subclassable builtin
types.  The special handling for these can now be removed from save_newobj().
Add some testing for this.

Also add support for setting the 'fast' flag on the Python Pickler class,
which suppresses use of the memo.
2003-01-29 17:58:45 +00:00
Neal Norwitz fa56e2dc40 SF # 669553, fix memory (ref) leaks
Will backport.
2003-01-19 15:40:09 +00:00
Neal Norwitz b2501f4cd1 Since the *_Init() are private, prefix with _, suggested by Skip 2002-12-31 03:42:13 +00:00
Neal Norwitz c91ed400e0 SF #561244, Micro optimizations
Initialize the small integers and __builtins__ in startup.
This removes some if conditions.
Change XDECREF to DECREF for values which shouldn't be NULL.
2002-12-30 22:29:22 +00:00
Neil Schemenauer 0df295889c Consolidate the int and long sequence repeat code. Before the change,
integers checked for integer overflow but longs did not.
2002-12-30 20:19:02 +00:00