Skip to content

Commit f47b75d

Browse files
zpointzpoint
committed
grammarly for english version
1 parent fdfe510 commit f47b75d

21 files changed

Lines changed: 447 additions & 448 deletions

File tree

‎BasicObject/bytearray/bytearray.md‎

Lines changed: 22 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -5,10 +5,10 @@
55
* [related file](#related-file)
66
* [memory layout](#memory-layout)
77
* [example](#example)
8-
* [empty bytearray](#empty-bytearray)
9-
* [append](#append)
10-
* [resize](#resize)
11-
* [slice](#slice)
8+
* [empty bytearray](#empty-bytearray)
9+
* [append](#append)
10+
* [resize](#resize)
11+
* [slice](#slice)
1212
* [ob_exports/buffer protocol](#ob_exports)
1313

1414
#### related file
@@ -18,11 +18,11 @@
1818

1919
#### memory layout
2020

21-
The **ob_alloc** field represent the real allocated size in bytes
21+
The **ob_alloc** field represents the real allocated size in bytes
2222

2323
**ob_bytes** is the physical begin address, and **ob_start** is the logical begin address
2424

25-
**ob_exports** means how many other object are sharing this buffer, like reference count in a way
25+
**ob_exports** means how many other objects are sharing this buffer, like reference count in a way
2626

2727
![memory layout](https://img-blog.csdnimg.cn/20190315152551189.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNzIwMzI5,size_16,color_FFFFFF,t_70)
2828

@@ -31,7 +31,7 @@ The **ob_alloc** field represent the real allocated size in bytes
3131

3232
##### empty bytearray
3333

34-
>>> a = bytearray(b"")
34+
>>> a = bytearray(b"")
3535
>>> id(a)
3636
4353755656
3737
>>> b = bytearray(b"")
@@ -45,7 +45,7 @@ The **ob_alloc** field represent the real allocated size in bytes
4545

4646
after append a charracter 'a', **ob_alloc** becomes 2, **ob_bytes** and **ob_start** all points to same address
4747

48-
a.append(ord('a'))
48+
a.append(ord('a'))
4949

5050
![append_a](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/bytearray/append_a.png)
5151

@@ -65,75 +65,75 @@ The size grow pattern is shown in the code
6565

6666
In appending, ob_alloc is 2, and request size is 2, 2 <= 2 * 1.125, so the new allocated size is 2 + (2 >> 3) + 3 ==> 5
6767

68-
a.append(ord('b'))
68+
a.append(ord('b'))
6969

7070
![resize](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/bytearray/resize.png)
7171

7272
##### slice
7373

74-
b = bytearray(b"abcdefghijk")
74+
b = bytearray(b"abcdefghijk")
7575

7676
![slice](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/bytearray/slice.png)
7777

7878
After the slice operation, **ob_start** points to the real beginning of the content, and **ob_bytes** still points to the begin address of the malloced block
7979

80-
b[0:5] = [1,2]
80+
b[0:5] = [1,2]
8181

8282
![after_slice](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/bytearray/after_slice.png)
8383

84-
as long as the slice operation is going to shrink the bytearray, and the **new_size < alloc / 2** is False, the resize operation won't shrink the real mallcoed size
84+
as long as the slice operation is going to shrink the bytearray, and the **new_size < allocate / 2** is False, the resize operation won't shrink the real malloced size
8585

86-
b[2:6] = [3, 4]
86+
b[2:6] = [3, 4]
8787

8888
![after2_slice](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/bytearray/after2_slice.png)
8989

90-
now, in the shrink operation, the **new_size < alloc / 2** is True, the resize operation will be triggered
90+
now, in the shrink operation, the **new_size < allocate / 2** is True, the resize operation will be triggered
9191

92-
b[0:3] = [7,8]
92+
b[0:3] = [7,8]
9393

9494
![after3_slice](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/bytearray/after3_slice.png)
9595

96-
The grow pattern in slice operation is same as the append operation
96+
The growing pattern in slice operation is the same as the append operation
9797

9898
request size is 6, 6 < 6 * 1.125, so new allocated size is 6 + (6 >> 3) + 3 ==> 9
9999

100-
b[0:3] = [1,2,3,4]
100+
b[0:3] = [1,2,3,4]
101101

102102
![after_grow_slice](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/bytearray/after_grow_slice.png)
103103

104104
##### ob_exports
105105

106106
what's field **ob_exports** mean ? If you need detail, you can refer to [less-copies-in-python-with-the-buffer-protocol-and-memoryviews](https://eli.thegreenplace.net/2011/11/28/less-copies-in-python-with-the-buffer-protocol-and-memoryviews) and [PEP 3118](https://www.python.org/dev/peps/pep-3118/)
107107

108-
buf = bytearray(b"abcdefg")
108+
buf = bytearray(b"abcdefg")
109109

110110
![exports](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/bytearray/exports.png)
111111

112112
the **bytearray** implements the **buffer protocol**, and **memoryview** is able to access the internal data block via the **buffer protocol**, **mybuf** and **buf** are all sharing the same internal block
113113

114114
field **ob_exports** becomes 1, which indicate how many objects currently sharing the internal block via **buffer protocol**
115115

116-
mybuf = memoryview(buf)
116+
mybuf = memoryview(buf)
117117
mybuf[1] = 3
118118

119119
![exports_1](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/bytearray/exports_1.png)
120120

121121
so does **mybuf2** object(**ob_exports** doesn't change because you need to call the c function defined by **buf** object via the **buffer protocol**, **mybuf2** barely calls the slice function of **mybuf**)
122122

123-
mybuf2 = mybuf[:4]
123+
mybuf2 = mybuf[:4]
124124
mybuf2[0] = 1
125125

126126
![exports_2](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/bytearray/exports_2.png)
127127

128128
**ob_exports** becomes 2
129129

130-
mybuf3 = memoryview(buf)
130+
mybuf3 = memoryview(buf)
131131

132132
![exports_3](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/bytearray/exports_3.png)
133133

134134
**ob_exports** becomes 0
135135

136-
del mybuf
136+
del mybuf
137137
del mybuf2
138138
del mybuf3
139139

‎BasicObject/bytes/bytes.md‎

Lines changed: 12 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -5,13 +5,13 @@
55
* [related file](#related-file)
66
* [memory layout](#memory-layout)
77
* [example](#example)
8-
* [empty bytes](#empty-bytes)
9-
* [ascii characters](#ascii-characters)
10-
* [nonascii characters](#nonascii-characters)
8+
* [empty bytes](#empty-bytes)
9+
* [ascii characters](#ascii-characters)
10+
* [nonascii characters](#nonascii-characters)
1111
* [summary](#summary)
12-
* [ob_shash](#ob_shash)
13-
* [ob_size](#ob_size)
14-
* [summary](#summary)
12+
* [ob_shash](#ob_shash)
13+
* [ob_size](#ob_size)
14+
* [summary](#summary)
1515

1616
#### related file
1717
* cpython/Objects/bytesobject.c
@@ -30,21 +30,21 @@ The memory layout of **PyBytesObject** looks like [memory layout of tuple object
3030

3131
**bytes** object is an immutable object, whenever you need to modify a **bytes** object, you need to create a new one, which keeps the implementation simple.
3232

33-
s = b""
33+
s = b""
3434

3535
![empty](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/bytes/empty.png)
3636

3737
##### ascii characters
3838

3939
let's initialize a byte object with ascii characters
4040

41-
s = b"abcdefg123"
41+
s = b"abcdefg123"
4242

4343
![ascii](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/bytes/ascii.png)
4444

4545
##### nonascii characters
4646

47-
s = "我是帅哥".encode("utf8")
47+
s = "我是帅哥".encode("utf8")
4848

4949
![nonascii](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/bytes/nonascii.png)
5050

@@ -54,11 +54,11 @@ let's initialize a byte object with ascii characters
5454
##### ob_shash
5555

5656

57-
The field **ob_shash** should stores the hash value of the byte object, value **-1** means not computed yet.
57+
The field **ob_shash** should store the hash value of the byte object, value **-1** means not computed yet.
5858

5959
The first time the hash value computed, it will be cached to the **ob_shash** field
6060

61-
the cached hash value can saves recalculation and speeds up dict lookups
61+
the cached hash value can save recalculation and speeds up dictionary lookups
6262

6363
##### ob_size
6464

@@ -70,7 +70,7 @@ The **PyBytesObject** is a python wrapper of c style null terminate string, with
7070

7171
The implementation of **PyBytesObject** looks like the **embstr** encoding in redis
7272

73-
redis-cli
73+
redis-cli
7474
127.0.0.1:6379> set a "hello"
7575
OK
7676
127.0.0.1:6379> object encoding a

‎BasicObject/class/class.md‎

Lines changed: 17 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -5,12 +5,12 @@
55
* [related file](#related-file)
66
* [memory layout](#memory-layout)
77
* [fields](#fields)
8-
* [im_func](#im_func)
9-
* [im_self](#im_self)
8+
* [im_func](#im_func)
9+
* [im_self](#im_self)
1010
* [free_list](#free_list)
1111
* [classmethod and staticmethod](#classmethod-and-staticmethod)
12-
* [classmethod](#classmethod)
13-
* [staticmethod](#staticmethod)
12+
* [classmethod](#classmethod)
13+
* [staticmethod](#staticmethod)
1414

1515
#### related file
1616
* cpython/Objects/classobject.c
@@ -52,24 +52,24 @@ field **im_self** stores the instance object this method bound to
5252

5353
when you call
5454

55-
>>> c.f1(123)
56-
123
55+
>>> c.f1(123)
56+
123
5757

5858
the **PyMethodObject** delegate the real call to **im_func** with **im_self** as the first argument
5959

6060
static PyObject *
6161
method_call(PyObject *method, PyObject *args, PyObject *kwargs)
6262
{
6363
PyObject *self, *func;
64-
/* get im_self */
64+
/* get im_self */
6565
self = PyMethod_GET_SELF(method);
6666
if (self == NULL) {
6767
PyErr_BadInternalCall();
6868
return NULL;
6969
}
70-
/* get im_func */
70+
/* get im_func */
7171
func = PyMethod_GET_FUNCTION(method);
72-
/* call im_func with im_self as the first argument */
72+
/* call im_func with im_self as the first argument */
7373
return _PyObject_Call_Prepend(func, self, args, kwargs);
7474
}
7575

@@ -102,8 +102,8 @@ the **PyMethodObject** will be created when you trying to access the bound-metho
102102

103103
now, let's see an example of free_list
104104

105-
>>> c1_f1_1 = c1.f1
106-
>>> c1_f1_2 = c1.f1
105+
>>> c1_f1_1 = c1.f1
106+
>>> c1_f1_2 = c1.f1
107107
>>> id(c1_f1_1)
108108
4529762024
109109
>>> id(c1_f1_2)
@@ -157,7 +157,7 @@ the **@classmethod** keeps type of **c1.fc** as **method**
157157

158158
![classmethod](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/class/classmethod.png)
159159

160-
how **classmethod** work internally ?
160+
how **classmethod** work internally?
161161

162162
**classmethod** is a **type** in python3
163163

@@ -186,14 +186,14 @@ let's see what's under the hood
186186
>>> cc.fc1
187187
<bound method <lambda> of <class '__main__.C'>>
188188

189-
get different result when access the same object in different way, why ?
189+
get a different result when access the same object in a different way, why?
190190

191-
when you trying to access the **fc1** in instance cc, the **descriptor protocol** will try several different path to get the attribute in the following step
191+
when you trying to access the **fc1** in instance cc, the **descriptor protocol** will try several different paths to get the attribute in the following step
192192
* call `__getattribute__` of the object C
193193
* `C.__dict__["fc1"]` is a data descriptor?
194-
* yes, return `C.__dict__['fc1'].__get__(instance, Class)`
195-
* no, return `cc.__dict__['fc1']` if 'fc1' in `cc.__dict__` else
196-
* `C.__dict__['fc1'].__get__(instance, Class)` if hasattr(`C.__dict__['fc1']`, `__get__`) else `C.__dict__['fc1']`
194+
* yes, return `C.__dict__['fc1'].__get__(instance, Class)`
195+
* no, return `cc.__dict__['fc1']` if 'fc1' in `cc.__dict__` else
196+
* `C.__dict__['fc1'].__get__(instance, Class)` if hasattr(`C.__dict__['fc1']`, `__get__`) else `C.__dict__['fc1']`
197197
* if not found in above steps, call `c.__getattr__("fc1")`
198198

199199
![object-attribute-lookup](https://blog.ionelmc.ro/2015/02/09/understanding-python-metaclasses/object-attribute-lookup.png)

‎BasicObject/complex/complex.md‎

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -21,11 +21,11 @@ the handling process and representation are mostly the same as [float](https://g
2121

2222
#### example
2323

24-
c = complex(0, 1)
24+
c = complex(0, 1)
2525

2626
![example0](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/complex/example0.png)
2727

28-
d = complex(0.1, -0.2)
28+
d = complex(0.1, -0.2)
2929

3030
![example1](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/complex/example1.png)
3131

@@ -53,13 +53,13 @@ let's read the add function
5353
return PyComplex_FromCComplex(result);
5454
}
5555

56-
the add operation is quiet simple, sum the **real**, sum the **imag** part and return the new value
56+
the add operation is quite simple, sum the **real**, sum the **image** part and return the new value
5757

5858
the sub/divide/pow/neg operations are similar
5959

60-
>>> e = c + d
61-
>>> repr(e)
62-
'(0.1+0.8j)'
60+
>>> e = c + d
61+
>>> repr(e)
62+
'(0.1+0.8j)'
6363

6464
![example2](https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/complex/example2.png)
6565

0 commit comments

Comments
 (0)