| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
I changed some bytearray methods to use strings instead of unicode like bytes_repr
Also, bytearray.fromhex() can take strings as well as unicode
|
|
|
|
|
|
| |
Now the slot is filled with a function that always raises.
Will not backport: extensions compiled with 2.6.x would not run on 2.6.0.
|
|
|
|
|
|
|
|
|
|
| |
match Python 2.5 speed despite the __instancecheck__ / __subclasscheck__
mechanism. In the process, fix a bug where isinstance() and issubclass(),
when given a tuple of classes as second argument, were looking up
__instancecheck__ / __subclasscheck__ on the tuple rather than on each
type object.
Reviewed by Benjamin Peterson and Raymond Hettinger.
|
| |
|
|
|
|
| |
was missing from the patch for #3139.
|
|
|
|
|
|
|
| |
by denying s# to parse objects that have a releasebuffer procedure,
and introducing s*.
More module might need to get converted to use s*.
|
| |
|
|
|
|
|
|
|
| |
http://mail.python.org/pipermail/python-dev/2008-June/079988.html
Python 2.6 should stick with PyString_* in its codebase. The PyBytes_* names
in the spirit of 3.0 are available via a #define only. See the email thread.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
object and structmodule. But, these need to be finished in Python 3.0 first. No objects support the new buffer API in Python 2.6 as of yet, and except for the memoryview object, I don't think they will.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
| |
PyObject_Index() returns something other than an int or long. It should never be possible to trigger this, as PyObject_Index checks to make sure it returns an int or long.
|
|
|
|
| |
as suggested by Thomas Heller in #2115
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_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.
|
| |
|
|
|
|
| |
PyObject_FromString() to store a python string in a function level static var.
|
|
|
|
|
| |
Factor-out common calling code by simplifying the length_hint API.
Speed-up the function by caching the PyObject_String for the attribute lookup.
|
|
|
|
| |
can make list() raise a SystemError
|
|
|
|
| |
py3k branch ;)
|
|
|
|
|
|
|
|
| |
Backport abc.py and isinstance/issubclass overloading to 2.6.
I had to backport test_typechecks.py myself, and make one small change
to abc.py to avoid duplicate work when x.__class__ and type(x) are the
same.
|
|
|
|
|
|
|
| |
ever going back out to Python code in PyObject_Call(). Required introducing a
static RuntimeError instance so that normalizing an exception there is no
reliance on a recursive call that would put the exception system over the
recursion check itself.
|
| |
|
|
|
|
| |
dict.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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...
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
PyMapping_Size and PySequence_Size.
Because len() tries first sequence, then mapping size, it will always
raise a "non-mapping object has no len" error which is confusing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem of checking too eagerly for recursive calls is the
following: if a RuntimeError is caused by recursion, and if code needs
to normalize it immediately (as in the 2nd test), then
PyErr_NormalizeException() needs a call to the RuntimeError class to
instantiate it, and this hits the recursion limit again... causing
PyErr_NormalizeException() to never finish.
Moved this particular recursion check to slot_tp_call(), which is not
involved in instantiating built-in exceptions.
Backport candidate.
|
|
|
|
| |
typeobject.c.
|
|
|
|
| |
top of a block.
|
|
|
|
|
|
| |
attribute checked for __call__ itself, and will continue to look until it finds an object without the attribute. This can lead to an infinite recursion.
Closes bug #532646, again. Will be backported.
|
| |
|
|
|
|
|
| |
_PyObject_Call(Function|Method)_SizeT into Include/abstract.h. This gets
them under the umbrella of the extern "C" { ... } block in that file.
|
|
|
|
| |
PyObject_CallMethod aware of PY_SSIZE_T_CLEAN.
|
| |
|
|
|
|
| |
wrt to ssize_t.
|
|
|
|
| |
losing data
|
|
|
|
|
|
| |
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).
|