mirrors/cpython
1
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2025-09-26 10:19:53 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 8

#11565: Fix several typos. Patch by Piotr Kasprzyk.

Browse source
This commit is contained in:
Ezio Melotti 2011-03-16 11:05:33 +02:00
parent e3d09ff269
commit 13925008dc
94 changed files with 126 additions and 126 deletions
Download patch file Download diff file Expand all files Collapse all files

2
Objects/dictobject.c
View file

@ -2070,7 +2070,7 @@ dict_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
assert(d->ma_table == NULL && d->ma_fill == 0 && d->ma_used == 0);
INIT_NONZERO_DICT_SLOTS(d);
d->ma_lookup = lookdict_unicode;
/* The object has been implicitely tracked by tp_alloc */
/* The object has been implicitly tracked by tp_alloc */
if (type == &PyDict_Type)
_PyObject_GC_UNTRACK(d);
#ifdef SHOW_CONVERSION_COUNTS

2
Objects/listobject.c
View file

@ -11,7 +11,7 @@
/* Ensure ob_item has room for at least newsize elements, and set
* ob_size to newsize. If newsize > ob_size on entry, the content
* of the new slots at exit is undefined heap trash; it's the caller's
* responsiblity to overwrite them with sane values.
* responsibility to overwrite them with sane values.
* The number of allocated elements may grow, shrink, or stay the same.
* Failure is impossible if newsize <= self.allocated on entry, although
* that partly relies on an assumption that the system realloc() never

4
Objects/longobject.c
View file

@ -712,7 +712,7 @@ _PyLong_FromByteArray(const unsigned char* bytes, size_t n,
is_signed = *pendbyte >= 0x80;
/* Compute numsignificantbytes. This consists of finding the most
significant byte. Leading 0 bytes are insignficant if the number
significant byte. Leading 0 bytes are insignificant if the number
is positive, and leading 0xff bytes if negative. */
{
size_t i;
@ -3196,7 +3196,7 @@ long_true_divide(PyObject *a, PyObject *b)
if (failed)
return NULL;
/* 'aexp' and 'bexp' were initialized to -1 to silence gcc-4.0.x,
but should really be set correctly after sucessful calls to
but should really be set correctly after successful calls to
_PyLong_AsScaledDouble() */
assert(aexp >= 0 && bexp >= 0);

4
Objects/typeobject.c
View file

@ -1008,7 +1008,7 @@ subtype_dealloc(PyObject *self)
self has a refcount of 0, and if gc ever gets its hands on it
(which can happen if any weakref callback gets invoked), it
looks like trash to gc too, and gc also tries to delete self
then. But we're already deleting self. Double dealloction is
then. But we're already deleting self. Double deallocation is
a subtle disaster.
Q. Why the bizarre (net-zero) manipulation of
@ -5872,7 +5872,7 @@ recurse_down_subclasses(PyTypeObject *type, PyObject *name,
slots compete for the same descriptor (for example both sq_item and
mp_subscript generate a __getitem__ descriptor).
In the latter case, the first slotdef entry encoutered wins. Since
In the latter case, the first slotdef entry encountered wins. Since
slotdef entries are sorted by the offset of the slot in the
PyHeapTypeObject, this gives us some control over disambiguating
between competing slots: the members of PyHeapTypeObject are listed