@@ -29,14 +29,13 @@ In this post, I will try to discuss improvements done in Core Python version
29
29
30
30
* breakpoint():
31
31
32
- Breakpoints are extream important feature for debugging. Since I
33
- started learning Python, I am using the same API of putting breakpoints. With
34
- latest improvements, you can put breakpoints by calling the function
35
- "breakpoint()". The ```breakpoint`` is a built in function. Calling buildting
36
- function is more handy than its previous way which is importing a
37
- ``` set_trace ``` method from the ``` pdb ``` module.
32
+ Breakpoints are extream important for debugging. Since I started learning
33
+ Python, I am using the same API of putting breakpoints. With this release,
34
+ breakpoint() is a new build-in function for putting breakpoints in your
35
+ code. This way is more handy than its previous way which is importing and
36
+ calling a set_trace method from the pdb module like pdb.set_trace
38
37
39
- Below is the example of using breakpoints in your program:
38
+ Below is the example of using putting breakpoint in your program:
40
39
41
40
# Note: A Gif will be more batter example for this.
42
41
``` python
@@ -48,18 +47,25 @@ In this post, I will try to discuss improvements done in Core Python version
48
47
...
49
48
```
50
49
50
+ Explaination:
51
+
52
+ The above code will take a pause by opening a Python Debugger (pdb) when the
53
+ value of iterator variable i will be even. All the odd values are printed on
54
+ screen.
55
+
51
56
* PYTHONBREAKPOINT environment variable:
52
57
53
- You can disable all the breakpoints by setting this environment variable to
54
- " 1" . Sometimes debugging can lead to a level where number of breakpoints are
55
- too many. This environment variable can provide a great way of toggling them
56
- in one shot.
58
+ You can disable all the breakpoints in your code by setting this environment
59
+ variable to " 1" . Sometimes debugging can lead to a level where number of
60
+ breakpoints are out of control. Process of finding, removing and re- ading a
61
+ breakpoint becomes overhead. This environment variable can provide a great
62
+ way of toggling them in one shot.
57
63
58
64
# TODO : Add demonstration of gif for this point.
59
65
60
- I advise to set " PYTHONBREAKPOINT=0" at production environment. That will
61
- prevent long holding if someone someone forgets to remove a breakpoint from
62
- their code and deploys it to production. I have seen people doing this .
66
+ I advise to set " PYTHONBREAKPOINT=0" at production environment. This will
67
+ prevent your code from long holding if you merge a code with breakpoint by
68
+ mistake .
63
69
64
70
65
71
* Subprocess got new parameter capture_output:
@@ -68,16 +74,16 @@ In this post, I will try to discuss improvements done in Core Python version
68
74
stream (stderr) by enabling capture_output parameter of subprocess.run
69
75
command.
70
76
71
- Without this parameter, capturing the Standard stream was lengthy using
72
- subprocess.PIPE parameter like below
77
+ Without this parameter, capturing the Standard streams was lengthy. Below is
78
+ the example by using subprocess.PIPE parameter
73
79
74
80
```python
75
81
subprocess.run(
76
82
[" ls" , " -l" , " /var" ], stdout = subprocess.PIPE , stderr = subprocess.PIPE
77
83
)
78
84
```
79
85
80
- With capture_output parameter, this will become shorten like below
86
+ With capture_output parameter, this will become more concise like below
81
87
82
88
``` python
83
89
subprocess.run([" ls" , " -l" , " /var" ], capture_output = True )
@@ -107,7 +113,7 @@ In this post, I will try to discuss improvements done in Core Python version
107
113
```
108
114
109
115
110
- * Dataclasses:
116
+ * Dataclasses module :
111
117
112
118
The new class level decorator "@dataclass " will reduce many lines of your
113
119
code. Python is well known for developing features which allows to achieve
@@ -116,7 +122,9 @@ In this post, I will try to discuss improvements done in Core Python version
116
122
days. Until there, I will suggest to grab any available tutorial from your
117
123
Google search.
118
124
119
- Below is the usual way to define a Class and creating an object from it.
125
+ Below is the usual way to define a Class and creating an object from it. I
126
+ will explain how below approach can be reduced by wrapping a @dataclass
127
+ decorator to it.
120
128
121
129
``` python
122
130
>> > class Point :
@@ -129,8 +137,13 @@ In this post, I will try to discuss improvements done in Core Python version
129
137
< __main__.Point object at 0x 7f3c73688b00>
130
138
```
131
139
132
- Converting above example with``` @dataclass ``` decorator below and then I will
133
- discuss some more advantages of using a dataclass decorator.
140
+ Converting above example with @dataclass decorator, Those lines of putting
141
+ odious construct code is gone! Additionally, the class level decorator
142
+ @dataclass will automatically define a behaviour for dander methods
143
+ __ repr__ (), __ eq__ () and __ hash__ () for us.
144
+
145
+ Below is the example code of wrapping Point class with @dataclass decorator
146
+ demonstrated earlier.
134
147
135
148
``` python
136
149
>> > from dataclasses import dataclass
@@ -144,47 +157,25 @@ In this post, I will try to discuss improvements done in Core Python version
144
157
Point(x = 2 , y = 4 )
145
158
```
146
159
147
- Those lines of putting obious construct code is gone! Additionally, the class
148
- level decorator ``` @dataclass ``` is authomatically defining behaviours for
149
- dundre methods ``` __repr__() ``` , ``` __eq__() ``` and ``` __hash__() ```
150
- for us. I will advise of using this decorator for defining your Classes.
151
-
152
160
153
161
* Putting underscores in defining Integers:
154
162
155
- Writing large numbers as value in code is difficult to read. I myself put
156
- finger on screen and count the places to get an idea of number. In this
157
- version, you can add put * _ * for values. Below example will make it more
158
- clear .
163
+ Writing large numbers as value invites a difficulty of reading it later. Many
164
+ times I myself put finger on screen and count the places to get an idea of
165
+ number. In this version, you can put _ for separating numbers for constructing
166
+ more readable value. Below example will make more understanding to this .
159
167
160
168
``` python
161
169
>> > x = 1_00_000
162
170
>> > x
163
171
100000
164
172
```
165
173
166
- * Module level definition of dunder methods __ dir__ () and __ attr__ ():
167
-
168
- I was facing this issue of hinding actual imports of my module with user. It
169
- was always confusing when someone calls "dir()" on my modules. There is
170
- already dunder method called "__ dir__ ()" to override this behaviour, but this
171
- method was limited to Classes. With this version, it is possible to override
172
- the behaviour of module by defining module level ``` __dir__() ``` method.
173
-
174
-
175
- # TODO: Write the example of them here.
176
-
177
- * __ attr__ : You can override this method for various purposes like firing an
178
- API deprication warning. The method will behave just as it was behaving on
179
- Class.
180
-
181
- # TODO: Example of __ attr__ at module level.
174
+ Explanation:
182
175
176
+ The integer value of x is 1, 00, 000. Putting underscore at places of comma
177
+ makes larger value more readable than writing entire value together.
183
178
184
- I request to share your views on this post. If you think I have missed any
185
- important point, or something is confusing I request you to write me at
186
- [ [email protected] ] ( mailto:[email protected] ) . I will be happy to find
187
- improvements on me. Thanks for reading :)
188
179
189
180
* Default arguments to Namedtuples:
190
181
@@ -207,3 +198,14 @@ In this post, I will try to discuss improvements done in Core Python version
207
198
The default arguments will be assigned in to attributes in the order from left
208
199
to right. Here, the default argument 2 will be assigned to y, and not
209
200
x.
201
+
202
+
203
+
204
+ * .pyc files are now diffed with hash approach:
205
+
206
+ .pyc are object files generated everytime you change your Python code file
207
+ (.py). At present identifying the change in Python code is done by comparing
208
+ meta fields like edited date. With this release, that functionality is
209
+ improved by comparing files with hash based approach. Hashbased approach quick
210
+ and more consistent than a meta data approach. Though this improvment is still
211
+ considered unstable and CPython will continue with the meta data approach.
0 commit comments