├── .editorconfig ├── .github ├── dependabot.yml └── workflows │ └── test-asm-builtins.yml ├── .gitignore ├── LICENSE ├── README.md ├── editing ├── README.md ├── captions │ ├── 6 │ │ ├── en.srt │ │ └── ru.srt │ ├── 7 │ │ ├── en.srt │ │ └── ru.srt │ └── 14 │ │ ├── en.srt │ │ └── ru.srt ├── poetry.lock ├── pyproject.toml ├── srt-from-json.py └── srt-shift.py ├── homeworks ├── 1-int.md ├── 10-==.md ├── 11-bytearray.md ├── 12-tuple.md ├── 13-print.md ├── 14-steering-council.md ├── 2-+.md ├── 3-what-is-python.md ├── 4-bool.md ├── 5-None.md ├── 6-float.md ├── 7-typeshed.md ├── 8-bytes.md └── 9-variables.md ├── lectures ├── 0-intro.key ├── 1-int.key ├── 10-==.key ├── 11-bytearray.key ├── 12-tuple.key ├── 13-print.key ├── 14-steering-council.key ├── 2-+.key ├── 3-what-is-python.key ├── 4-bool.key ├── 5-None.key ├── 6-float.key ├── 7-typeshed.key ├── 8-bytes.key ├── 9-variables.key └── README.md ├── practice └── asm-builtins │ ├── .editorconfig │ ├── .gitignore │ ├── README.md │ ├── asm_builtins │ └── mod.c │ └── pyproject.toml └── streaming └── film_default.png /.editorconfig: -------------------------------------------------------------------------------- 1 | # Check http://editorconfig.org for more information 2 | # This is the main config file for this project: 3 | root = true 4 | 5 | [*] 6 | charset = utf-8 7 | trim_trailing_whitespace = true 8 | end_of_line = lf 9 | indent_style = space 10 | insert_final_newline = true 11 | indent_size = 2 12 | 13 | [*.py] 14 | indent_size = 4 15 | -------------------------------------------------------------------------------- /.github/dependabot.yml: -------------------------------------------------------------------------------- 1 | version: 2 2 | updates: 3 | - package-ecosystem: pip 4 | directory: "/editing" 5 | schedule: 6 | interval: daily 7 | time: "02:00" 8 | open-pull-requests-limit: 10 9 | 10 | - package-ecosystem: github-actions 11 | directory: "/" 12 | schedule: 13 | interval: daily 14 | time: "02:00" 15 | open-pull-requests-limit: 10 16 | -------------------------------------------------------------------------------- /.github/workflows/test-asm-builtins.yml: -------------------------------------------------------------------------------- 1 | name: test 2 | 3 | 'on': 4 | push: 5 | branches: 6 | - master 7 | pull_request: 8 | paths: 9 | - 'practice/asm-builtins/**' 10 | - '.github/workflows/asm-builtins.yml' 11 | 12 | concurrency: 13 | group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }} 14 | cancel-in-progress: true 15 | 16 | permissions: 17 | contents: read 18 | 19 | jobs: 20 | test: 21 | runs-on: ubuntu-latest 22 | strategy: 23 | fail-fast: false 24 | matrix: 25 | python-version: ['3.9', '3.10', '3.11', '3.12', '3.13'] 26 | 27 | steps: 28 | - uses: actions/checkout@v4 29 | with: 30 | persist-credentials: false 31 | - name: Set up Python ${{ matrix.python-version }} 32 | uses: actions/setup-python@v5 33 | with: 34 | python-version: ${{ matrix.python-version }} 35 | 36 | - name: Install the module 37 | run: pip install . 38 | working-directory: practice/asm-builtins 39 | - name: Run tests 40 | run: python -c 'import asm_builtins; asm_builtins.print(1, 2)' 41 | working-directory: practice/asm-builtins 42 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | #### joe made this: http://goel.io/joe 2 | #### python #### 3 | # Byte-compiled / optimized / DLL files 4 | .pytest_cache 5 | __pycache__/ 6 | *.py[cod] 7 | *$py.class 8 | 9 | # C extensions 10 | *.so 11 | 12 | # Distribution / packaging 13 | .Python 14 | build/ 15 | develop-eggs/ 16 | dist/ 17 | downloads/ 18 | eggs/ 19 | .eggs/ 20 | lib/ 21 | lib64/ 22 | parts/ 23 | sdist/ 24 | var/ 25 | wheels/ 26 | *.egg-info/ 27 | .installed.cfg 28 | *.egg 29 | pip-wheel-metadata/ 30 | 31 | # PyInstaller 32 | # Usually these files are written by a python script from a template 33 | # before PyInstaller builds the exe, so as to inject date/other infos into it. 34 | *.manifest 35 | *.spec 36 | 37 | # Installer logs 38 | pip-log.txt 39 | pip-delete-this-directory.txt 40 | 41 | # Unit test / coverage reports 42 | htmlcov/ 43 | .tox/ 44 | .coverage 45 | .coverage.* 46 | .cache 47 | nosetests.xml 48 | coverage.xml 49 | *.cover 50 | .hypothesis/ 51 | 52 | # Translations 53 | *.mo 54 | *.pot 55 | 56 | # Django stuff: 57 | *.log 58 | local_settings.py 59 | 60 | # Flask stuff: 61 | instance/ 62 | .webassets-cache 63 | 64 | # Scrapy stuff: 65 | .scrapy 66 | 67 | # Sphinx documentation 68 | docs/_build/ 69 | 70 | # PyBuilder 71 | target/ 72 | 73 | # Jupyter Notebook 74 | .ipynb_checkpoints 75 | 76 | # pyenv 77 | .python-version 78 | 79 | # asdf 80 | .tool-versions 81 | 82 | # celery beat schedule file 83 | celerybeat-schedule 84 | 85 | # SageMath parsed files 86 | *.sage.py 87 | 88 | # Environments 89 | .env 90 | .venv 91 | env/ 92 | venv/ 93 | ENV/ 94 | 95 | # Spyder project settings 96 | .spyderproject 97 | .spyproject 98 | 99 | # Rope project settings 100 | .ropeproject 101 | 102 | # mkdocs documentation 103 | /site 104 | 105 | # mypy 106 | .mypy_cache/ 107 | #### macos #### 108 | # General 109 | *.DS_Store 110 | .AppleDouble 111 | .LSOverride 112 | 113 | # Icon must end with two \r 114 | Icon 115 | 116 | 117 | # Thumbnails 118 | ._* 119 | 120 | # Files that might appear in the root of a volume 121 | .DocumentRevisions-V100 122 | .fseventsd 123 | .Spotlight-V100 124 | .TemporaryItems 125 | .Trashes 126 | .VolumeIcon.icns 127 | .com.apple.timemachine.donotpresent 128 | 129 | # Directories potentially created on remote AFP share 130 | .AppleDB 131 | .AppleDesktop 132 | Network Trash Folder 133 | Temporary Items 134 | .apdisk 135 | #### windows #### 136 | # Windows thumbnail cache files 137 | Thumbs.db 138 | ehthumbs.db 139 | ehthumbs_vista.db 140 | 141 | # Dump file 142 | *.stackdump 143 | 144 | # Folder config file 145 | Desktop.ini 146 | 147 | # Recycle Bin used on file shares 148 | $RECYCLE.BIN/ 149 | 150 | # Windows Installer files 151 | *.cab 152 | *.msi 153 | *.msm 154 | *.msp 155 | 156 | # Windows shortcuts 157 | *.lnk 158 | #### linux #### 159 | *~ 160 | 161 | # temporary files which can be created if a process still has a handle open of a deleted file 162 | .fuse_hidden* 163 | 164 | # KDE directory preferences 165 | .directory 166 | 167 | # Linux trash folder which might appear on any partition or disk 168 | .Trash-* 169 | 170 | # .nfs files are created when an open file is removed but is still being accessed 171 | .nfs* 172 | #### jetbrains #### 173 | # Covers JetBrains IDEs: IntelliJ, RubyMine, PhpStorm, AppCode, PyCharm, CLion, Android Studio and Webstorm 174 | # Reference: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839 175 | 176 | # User-specific stuff: 177 | .idea/ 178 | 179 | ## File-based project format: 180 | *.iws 181 | 182 | ## Plugin-specific files: 183 | 184 | # IntelliJ 185 | /out/ 186 | 187 | # mpeltonen/sbt-idea plugin 188 | .idea_modules/ 189 | 190 | # JIRA plugin 191 | atlassian-ide-plugin.xml 192 | 193 | # Cursive Clojure plugin 194 | .idea/replstate.xml 195 | 196 | # Crashlytics plugin (for Android Studio and IntelliJ) 197 | com_crashlytics_export_strings.xml 198 | crashlytics.properties 199 | crashlytics-build.properties 200 | fabric.properties 201 | 202 | ### Custom ### 203 | # Buggy: 204 | .vscode/ 205 | 206 | # Used for testing: 207 | ex.py 208 | 209 | # Output of code generation: 210 | editing/out.srt 211 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Copyright (c) 2024 Nikita Sobolev 2 | 3 | Attribution-NonCommercial-ShareAlike 4.0 International 4 | 5 | ======================================================================= 6 | 7 | Creative Commons Corporation ("Creative Commons") is not a law firm and 8 | does not provide legal services or legal advice. Distribution of 9 | Creative Commons public licenses does not create a lawyer-client or 10 | other relationship. Creative Commons makes its licenses and related 11 | information available on an "as-is" basis. Creative Commons gives no 12 | warranties regarding its licenses, any material licensed under their 13 | terms and conditions, or any related information. Creative Commons 14 | disclaims all liability for damages resulting from their use to the 15 | fullest extent possible. 16 | 17 | Using Creative Commons Public Licenses 18 | 19 | Creative Commons public licenses provide a standard set of terms and 20 | conditions that creators and other rights holders may use to share 21 | original works of authorship and other material subject to copyright 22 | and certain other rights specified in the public license below. The 23 | following considerations are for informational purposes only, are not 24 | exhaustive, and do not form part of our licenses. 25 | 26 | Considerations for licensors: Our public licenses are 27 | intended for use by those authorized to give the public 28 | permission to use material in ways otherwise restricted by 29 | copyright and certain other rights. Our licenses are 30 | irrevocable. Licensors should read and understand the terms 31 | and conditions of the license they choose before applying it. 32 | Licensors should also secure all rights necessary before 33 | applying our licenses so that the public can reuse the 34 | material as expected. Licensors should clearly mark any 35 | material not subject to the license. This includes other CC- 36 | licensed material, or material used under an exception or 37 | limitation to copyright. More considerations for licensors: 38 | wiki.creativecommons.org/Considerations_for_licensors 39 | 40 | Considerations for the public: By using one of our public 41 | licenses, a licensor grants the public permission to use the 42 | licensed material under specified terms and conditions. If 43 | the licensor's permission is not necessary for any reason--for 44 | example, because of any applicable exception or limitation to 45 | copyright--then that use is not regulated by the license. Our 46 | licenses grant only permissions under copyright and certain 47 | other rights that a licensor has authority to grant. Use of 48 | the licensed material may still be restricted for other 49 | reasons, including because others have copyright or other 50 | rights in the material. A licensor may make special requests, 51 | such as asking that all changes be marked or described. 52 | Although not required by our licenses, you are encouraged to 53 | respect those requests where reasonable. More considerations 54 | for the public: 55 | wiki.creativecommons.org/Considerations_for_licensees 56 | 57 | ======================================================================= 58 | 59 | Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International 60 | Public License 61 | 62 | By exercising the Licensed Rights (defined below), You accept and agree 63 | to be bound by the terms and conditions of this Creative Commons 64 | Attribution-NonCommercial-ShareAlike 4.0 International Public License 65 | ("Public License"). To the extent this Public License may be 66 | interpreted as a contract, You are granted the Licensed Rights in 67 | consideration of Your acceptance of these terms and conditions, and the 68 | Licensor grants You such rights in consideration of benefits the 69 | Licensor receives from making the Licensed Material available under 70 | these terms and conditions. 71 | 72 | 73 | Section 1 -- Definitions. 74 | 75 | a. Adapted Material means material subject to Copyright and Similar 76 | Rights that is derived from or based upon the Licensed Material 77 | and in which the Licensed Material is translated, altered, 78 | arranged, transformed, or otherwise modified in a manner requiring 79 | permission under the Copyright and Similar Rights held by the 80 | Licensor. For purposes of this Public License, where the Licensed 81 | Material is a musical work, performance, or sound recording, 82 | Adapted Material is always produced where the Licensed Material is 83 | synched in timed relation with a moving image. 84 | 85 | b. Adapter's License means the license You apply to Your Copyright 86 | and Similar Rights in Your contributions to Adapted Material in 87 | accordance with the terms and conditions of this Public License. 88 | 89 | c. BY-NC-SA Compatible License means a license listed at 90 | creativecommons.org/compatiblelicenses, approved by Creative 91 | Commons as essentially the equivalent of this Public License. 92 | 93 | d. Copyright and Similar Rights means copyright and/or similar rights 94 | closely related to copyright including, without limitation, 95 | performance, broadcast, sound recording, and Sui Generis Database 96 | Rights, without regard to how the rights are labeled or 97 | categorized. For purposes of this Public License, the rights 98 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 99 | Rights. 100 | 101 | e. Effective Technological Measures means those measures that, in the 102 | absence of proper authority, may not be circumvented under laws 103 | fulfilling obligations under Article 11 of the WIPO Copyright 104 | Treaty adopted on December 20, 1996, and/or similar international 105 | agreements. 106 | 107 | f. Exceptions and Limitations means fair use, fair dealing, and/or 108 | any other exception or limitation to Copyright and Similar Rights 109 | that applies to Your use of the Licensed Material. 110 | 111 | g. License Elements means the license attributes listed in the name 112 | of a Creative Commons Public License. The License Elements of this 113 | Public License are Attribution, NonCommercial, and ShareAlike. 114 | 115 | h. Licensed Material means the artistic or literary work, database, 116 | or other material to which the Licensor applied this Public 117 | License. 118 | 119 | i. Licensed Rights means the rights granted to You subject to the 120 | terms and conditions of this Public License, which are limited to 121 | all Copyright and Similar Rights that apply to Your use of the 122 | Licensed Material and that the Licensor has authority to license. 123 | 124 | j. Licensor means the individual(s) or entity(ies) granting rights 125 | under this Public License. 126 | 127 | k. NonCommercial means not primarily intended for or directed towards 128 | commercial advantage or monetary compensation. For purposes of 129 | this Public License, the exchange of the Licensed Material for 130 | other material subject to Copyright and Similar Rights by digital 131 | file-sharing or similar means is NonCommercial provided there is 132 | no payment of monetary compensation in connection with the 133 | exchange. 134 | 135 | l. Share means to provide material to the public by any means or 136 | process that requires permission under the Licensed Rights, such 137 | as reproduction, public display, public performance, distribution, 138 | dissemination, communication, or importation, and to make material 139 | available to the public including in ways that members of the 140 | public may access the material from a place and at a time 141 | individually chosen by them. 142 | 143 | m. Sui Generis Database Rights means rights other than copyright 144 | resulting from Directive 96/9/EC of the European Parliament and of 145 | the Council of 11 March 1996 on the legal protection of databases, 146 | as amended and/or succeeded, as well as other essentially 147 | equivalent rights anywhere in the world. 148 | 149 | n. You means the individual or entity exercising the Licensed Rights 150 | under this Public License. Your has a corresponding meaning. 151 | 152 | 153 | Section 2 -- Scope. 154 | 155 | a. License grant. 156 | 157 | 1. Subject to the terms and conditions of this Public License, 158 | the Licensor hereby grants You a worldwide, royalty-free, 159 | non-sublicensable, non-exclusive, irrevocable license to 160 | exercise the Licensed Rights in the Licensed Material to: 161 | 162 | a. reproduce and Share the Licensed Material, in whole or 163 | in part, for NonCommercial purposes only; and 164 | 165 | b. produce, reproduce, and Share Adapted Material for 166 | NonCommercial purposes only. 167 | 168 | 2. Exceptions and Limitations. For the avoidance of doubt, where 169 | Exceptions and Limitations apply to Your use, this Public 170 | License does not apply, and You do not need to comply with 171 | its terms and conditions. 172 | 173 | 3. Term. The term of this Public License is specified in Section 174 | 6(a). 175 | 176 | 4. Media and formats; technical modifications allowed. The 177 | Licensor authorizes You to exercise the Licensed Rights in 178 | all media and formats whether now known or hereafter created, 179 | and to make technical modifications necessary to do so. The 180 | Licensor waives and/or agrees not to assert any right or 181 | authority to forbid You from making technical modifications 182 | necessary to exercise the Licensed Rights, including 183 | technical modifications necessary to circumvent Effective 184 | Technological Measures. For purposes of this Public License, 185 | simply making modifications authorized by this Section 2(a) 186 | (4) never produces Adapted Material. 187 | 188 | 5. Downstream recipients. 189 | 190 | a. Offer from the Licensor -- Licensed Material. Every 191 | recipient of the Licensed Material automatically 192 | receives an offer from the Licensor to exercise the 193 | Licensed Rights under the terms and conditions of this 194 | Public License. 195 | 196 | b. Additional offer from the Licensor -- Adapted Material. 197 | Every recipient of Adapted Material from You 198 | automatically receives an offer from the Licensor to 199 | exercise the Licensed Rights in the Adapted Material 200 | under the conditions of the Adapter's License You apply. 201 | 202 | c. No downstream restrictions. You may not offer or impose 203 | any additional or different terms or conditions on, or 204 | apply any Effective Technological Measures to, the 205 | Licensed Material if doing so restricts exercise of the 206 | Licensed Rights by any recipient of the Licensed 207 | Material. 208 | 209 | 6. No endorsement. Nothing in this Public License constitutes or 210 | may be construed as permission to assert or imply that You 211 | are, or that Your use of the Licensed Material is, connected 212 | with, or sponsored, endorsed, or granted official status by, 213 | the Licensor or others designated to receive attribution as 214 | provided in Section 3(a)(1)(A)(i). 215 | 216 | b. Other rights. 217 | 218 | 1. Moral rights, such as the right of integrity, are not 219 | licensed under this Public License, nor are publicity, 220 | privacy, and/or other similar personality rights; however, to 221 | the extent possible, the Licensor waives and/or agrees not to 222 | assert any such rights held by the Licensor to the limited 223 | extent necessary to allow You to exercise the Licensed 224 | Rights, but not otherwise. 225 | 226 | 2. Patent and trademark rights are not licensed under this 227 | Public License. 228 | 229 | 3. To the extent possible, the Licensor waives any right to 230 | collect royalties from You for the exercise of the Licensed 231 | Rights, whether directly or through a collecting society 232 | under any voluntary or waivable statutory or compulsory 233 | licensing scheme. In all other cases the Licensor expressly 234 | reserves any right to collect such royalties, including when 235 | the Licensed Material is used other than for NonCommercial 236 | purposes. 237 | 238 | 239 | Section 3 -- License Conditions. 240 | 241 | Your exercise of the Licensed Rights is expressly made subject to the 242 | following conditions. 243 | 244 | a. Attribution. 245 | 246 | 1. If You Share the Licensed Material (including in modified 247 | form), You must: 248 | 249 | a. retain the following if it is supplied by the Licensor 250 | with the Licensed Material: 251 | 252 | i. identification of the creator(s) of the Licensed 253 | Material and any others designated to receive 254 | attribution, in any reasonable manner requested by 255 | the Licensor (including by pseudonym if 256 | designated); 257 | 258 | ii. a copyright notice; 259 | 260 | iii. a notice that refers to this Public License; 261 | 262 | iv. a notice that refers to the disclaimer of 263 | warranties; 264 | 265 | v. a URI or hyperlink to the Licensed Material to the 266 | extent reasonably practicable; 267 | 268 | b. indicate if You modified the Licensed Material and 269 | retain an indication of any previous modifications; and 270 | 271 | c. indicate the Licensed Material is licensed under this 272 | Public License, and include the text of, or the URI or 273 | hyperlink to, this Public License. 274 | 275 | 2. You may satisfy the conditions in Section 3(a)(1) in any 276 | reasonable manner based on the medium, means, and context in 277 | which You Share the Licensed Material. For example, it may be 278 | reasonable to satisfy the conditions by providing a URI or 279 | hyperlink to a resource that includes the required 280 | information. 281 | 3. If requested by the Licensor, You must remove any of the 282 | information required by Section 3(a)(1)(A) to the extent 283 | reasonably practicable. 284 | 285 | b. ShareAlike. 286 | 287 | In addition to the conditions in Section 3(a), if You Share 288 | Adapted Material You produce, the following conditions also apply. 289 | 290 | 1. The Adapter's License You apply must be a Creative Commons 291 | license with the same License Elements, this version or 292 | later, or a BY-NC-SA Compatible License. 293 | 294 | 2. You must include the text of, or the URI or hyperlink to, the 295 | Adapter's License You apply. You may satisfy this condition 296 | in any reasonable manner based on the medium, means, and 297 | context in which You Share Adapted Material. 298 | 299 | 3. You may not offer or impose any additional or different terms 300 | or conditions on, or apply any Effective Technological 301 | Measures to, Adapted Material that restrict exercise of the 302 | rights granted under the Adapter's License You apply. 303 | 304 | 305 | Section 4 -- Sui Generis Database Rights. 306 | 307 | Where the Licensed Rights include Sui Generis Database Rights that 308 | apply to Your use of the Licensed Material: 309 | 310 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 311 | to extract, reuse, reproduce, and Share all or a substantial 312 | portion of the contents of the database for NonCommercial purposes 313 | only; 314 | 315 | b. if You include all or a substantial portion of the database 316 | contents in a database in which You have Sui Generis Database 317 | Rights, then the database in which You have Sui Generis Database 318 | Rights (but not its individual contents) is Adapted Material, 319 | including for purposes of Section 3(b); and 320 | 321 | c. You must comply with the conditions in Section 3(a) if You Share 322 | all or a substantial portion of the contents of the database. 323 | 324 | For the avoidance of doubt, this Section 4 supplements and does not 325 | replace Your obligations under this Public License where the Licensed 326 | Rights include other Copyright and Similar Rights. 327 | 328 | 329 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 330 | 331 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 332 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 333 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 334 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 335 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 336 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 337 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 338 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 339 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 340 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 341 | 342 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 343 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 344 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 345 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 346 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 347 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 348 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 349 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 350 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 351 | 352 | c. The disclaimer of warranties and limitation of liability provided 353 | above shall be interpreted in a manner that, to the extent 354 | possible, most closely approximates an absolute disclaimer and 355 | waiver of all liability. 356 | 357 | 358 | Section 6 -- Term and Termination. 359 | 360 | a. This Public License applies for the term of the Copyright and 361 | Similar Rights licensed here. However, if You fail to comply with 362 | this Public License, then Your rights under this Public License 363 | terminate automatically. 364 | 365 | b. Where Your right to use the Licensed Material has terminated under 366 | Section 6(a), it reinstates: 367 | 368 | 1. automatically as of the date the violation is cured, provided 369 | it is cured within 30 days of Your discovery of the 370 | violation; or 371 | 372 | 2. upon express reinstatement by the Licensor. 373 | 374 | For the avoidance of doubt, this Section 6(b) does not affect any 375 | right the Licensor may have to seek remedies for Your violations 376 | of this Public License. 377 | 378 | c. For the avoidance of doubt, the Licensor may also offer the 379 | Licensed Material under separate terms or conditions or stop 380 | distributing the Licensed Material at any time; however, doing so 381 | will not terminate this Public License. 382 | 383 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 384 | License. 385 | 386 | 387 | Section 7 -- Other Terms and Conditions. 388 | 389 | a. The Licensor shall not be bound by any additional or different 390 | terms or conditions communicated by You unless expressly agreed. 391 | 392 | b. Any arrangements, understandings, or agreements regarding the 393 | Licensed Material not stated herein are separate from and 394 | independent of the terms and conditions of this Public License. 395 | 396 | 397 | Section 8 -- Interpretation. 398 | 399 | a. For the avoidance of doubt, this Public License does not, and 400 | shall not be interpreted to, reduce, limit, restrict, or impose 401 | conditions on any use of the Licensed Material that could lawfully 402 | be made without permission under this Public License. 403 | 404 | b. To the extent possible, if any provision of this Public License is 405 | deemed unenforceable, it shall be automatically reformed to the 406 | minimum extent necessary to make it enforceable. If the provision 407 | cannot be reformed, it shall be severed from this Public License 408 | without affecting the enforceability of the remaining terms and 409 | conditions. 410 | 411 | c. No term or condition of this Public License will be waived and no 412 | failure to comply consented to unless expressly agreed to by the 413 | Licensor. 414 | 415 | d. Nothing in this Public License constitutes or may be interpreted 416 | as a limitation upon, or waiver of, any privileges and immunities 417 | that apply to the Licensor or You, including from the legal 418 | processes of any jurisdiction or authority. 419 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # "Лучший курс по Питону" 2 | 3 | [![Static Badge](https://img.shields.io/badge/%D0%BF%D0%BE%D0%B4%D0%B4%D0%B5%D1%80%D0%B6%D0%B0%D1%82%D1%8C-%D0%BA%D1%83%D1%80%D1%81-orange?style=flat&logo=boosty&color=orange)](https://boosty.to/sobolevn) 4 | [![Telegram chat](https://img.shields.io/badge/chat-join-blue?logo=telegram)](https://t.me/opensource_findings_chat) 5 | 6 | Привет! 7 | 8 | Здесь у нас: 9 | - Файлы с лекций 10 | - Файлы с дополнительными материалами 11 | - Файлы с практикой 12 | 13 | Видео тут: https://www.youtube.com/@sobolevn 14 | 15 | ## Лицензия 16 | 17 | Данный курс выходит под открытой лицензией. 18 | 19 | Можно: 20 | - Учиться и делиться им с друзьями и коллегами 21 | - Сделать форк, поправить что-то 22 | - Использовать данные материалы в некоммерческих целях 23 | 24 | Нельзя: 25 | - Использовать материалы в коммерческих целях 26 | -------------------------------------------------------------------------------- /editing/README.md: -------------------------------------------------------------------------------- 1 | # Гайд по тому, как редактировать видео 2 | 3 | ## Инструменты 4 | 5 | ### Работа с субтитрами 6 | 7 | **Обратите внимание, что русские субтитры – сгеренерированы при помощи ИИ. В них могут и будут ошибки и неточности. Если хочется исправить – присылай PR.** 8 | 9 | - Получение субтитров из видео / аудио: https://any2text.ru 10 | - Перевод субтитров и аудио: https://github.com/FOSWLY/vot-cli 11 | 12 | ### Скрипт для создания субтитров из английского видео 13 | 14 | Перед созданием русских субтитров необходимо создать английские! 15 | 16 | ```bash 17 | VIDEO_LINK='...' 18 | 19 | # First, create audio: 20 | npx vot-cli --output=. --lang=en --reslang=ru "$VIDEO_LINK" 21 | 22 | # Double check the audio and then you can create subs, if everything is fine: 23 | npx vot-cli --subs --output=. --lang=en --reslang=ru "$VIDEO_LINK" 24 | 25 | # Then, convert the output file from json to srt: 26 | python srt-from-json.py ru.json 27 | ``` 28 | -------------------------------------------------------------------------------- /editing/captions/14/en.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,571 --> 00:00:05,738 3 | Hello everyone, my name is Nikita Sobolev and this is 4 | the Best Python Python course. Today is an unusual 5 | 6 | 2 7 | 00:00:05,758 --> 00:00:12,206 8 | video, so to speak, special and unique, because our 9 | guest today is special and unique. Today I will talk 10 | 11 | 3 12 | 00:00:12,306 --> 00:00:19,876 13 | to another Python core-develope, who knows a lot 14 | about how free-theading, JIT, as well as many other 15 | 16 | 4 17 | 00:00:19,896 --> 00:00:25,824 18 | internal parts of Python, he is also a member of 19 | the Steering Council. This is such a special control 20 | 21 | 5 22 | 00:00:25,844 --> 00:00:32,862 23 | body for all Python. And, of course, I specially 24 | prepared Russian subtitles for you. You can turn them 25 | 26 | 6 27 | 00:00:32,882 --> 00:00:37,795 28 | on right on YouTube and listen in English and read in 29 | Russian, if it's easier for you. There are also 30 | 31 | 7 32 | 00:00:38,517 --> 00:00:46,536 33 | English subtitles, so you can use them if you want. I 34 | really want all python devs to understand how 35 | 36 | 8 37 | 00:00:46,556 --> 00:00:51,546 38 | management works with such a big project as the most 39 | popular programming language in the world. Because 40 | 41 | 9 42 | 00:00:51,566 --> 00:00:58,439 43 | this is also a real engineering task. Of course, not 44 | every one of us will encounter this in real life. 45 | 46 | 10 47 | 00:00:58,459 --> 00:01:03,147 48 | However, nothing prevents us from looking at how it 49 | really works and bringing something new and 50 | 51 | 11 52 | 00:01:03,468 --> 00:01:08,096 53 | interesting into our lives. Many people still 54 | mistakenly believe that Guido van Rossum makes all 55 | 56 | 12 57 | 00:01:08,116 --> 00:01:13,264 58 | decisions on his own. However, this is not the case. 59 | Now Python is managed by the Steering Council. This is 60 | 61 | 13 62 | 00:01:13,284 --> 00:01:19,955 63 | a select committee of five people, which changes 64 | every year. Any core-developer can join it, even 65 | 66 | 14 67 | 00:01:19,975 --> 00:01:27,066 68 | non-core-developers. It is the Steering Council that 69 | decides which PEPs will be accepted and which PEPs 70 | 71 | 15 72 | 00:01:27,086 --> 00:01:32,515 73 | will be rejected. That is, there are literally five 74 | people who determine the fate of all Python. Today I 75 | 76 | 16 77 | 00:01:32,595 --> 00:01:39,202 78 | invited one of them to talk about the whole process. 79 | And of course, when such a person comes to visit you, 80 | 81 | 17 82 | 00:01:39,382 --> 00:01:44,988 83 | you can't help but ask him about other interesting 84 | topics. For example, Donghee Na is one of the major 85 | 86 | 18 87 | 00:01:45,008 --> 00:01:50,314 88 | participants in the free-theading project. We will 89 | also touch on the JIT issue a little, because right now 90 | 91 | 19 92 | 00:01:50,334 --> 00:01:56,521 93 | we are considering a PEP that will change how JIT 94 | works, and it is very interesting to discuss it. Well, 95 | 96 | 20 97 | 00:01:56,541 --> 00:02:03,775 98 | we will also touch on such two topics as Relocatable 99 | Builds and BOLT. For those who do not know what it is, of 100 | 101 | 21 102 | 00:02:03,855 --> 00:02:08,804 103 | course, we will tell everything during the interview. Well, now to 104 | the interview itself. Let's get started. Donghee Na, it 105 | 106 | 22 107 | 00:02:08,884 --> 00:02:16,878 108 | is really nice to have you here. You are a very, very 109 | talented developer and Steering Council member. And 110 | 111 | 23 112 | 00:02:16,918 --> 00:02:22,646 113 | today we are going to talk about your Python 114 | contributions, your Steering Council work, and a lot 115 | 116 | 24 117 | 00:02:22,686 --> 00:02:29,334 118 | of stuff around CPython. So thanks a lot for joining, 119 | and please introduce yourself. OK, hi. So my name is 120 | 121 | 25 122 | 00:02:29,354 --> 00:02:40,446 123 | Donghee, and I'm from South Korea. And I've started to 124 | contribute to CPython from 2017, and I've promoted to 125 | 126 | 26 127 | 00:02:41,127 --> 00:02:48,274 128 | the CPython core dev around 2020. And then I'm now 129 | working as the Steering Council member from this 130 | 131 | 27 132 | 00:02:48,395 --> 00:02:58,36 133 | year. So, and these days I'm focusing on how 134 | free-threading works and other CPython stuff. So, I 135 | 136 | 28 137 | 00:02:58,4 --> 00:03:05,527 138 | really enjoy to contribute to the open source, yeah. It's really 139 | 140 | 29 141 | 00:03:05,587 --> 00:03:14,745 142 | great because you were the first person to introduce 143 | me to the Python Triage team back in 2021 or 2022, 144 | 145 | 30 146 | 00:03:14,765 --> 00:03:22,718 147 | something like that. And I'm still grateful for that. 148 | Thank you. It was really big fun to work as a triager 149 | 150 | 31 151 | 00:03:23,159 --> 00:03:29,805 152 | and to learn all the Python workflow and all the 153 | internals. Can you please explain to my audience what 154 | 155 | 32 156 | 00:03:29,845 --> 00:03:36,411 157 | Steering Council is? Yes, so the Python Steering 158 | Council is kind of a small group of the Python core devs 159 | 160 | 33 161 | 00:03:36,491 --> 00:03:45,079 162 | that are elected to oversee the development and 163 | direction of the Python language. So from 2018 and 164 | 165 | 34 166 | 00:03:45,219 --> 00:03:54,804 167 | after the Guido's resignation from the BDFL position, the 168 | first Steering Council was actually formed and the 169 | 170 | 35 171 | 00:03:54,824 --> 00:04:01,975 172 | Guido was one of the members for the first year. 173 | The primary responsibility of the 174 | 175 | 36 176 | 00:04:01,995 --> 00:04:09,711 177 | Steering Council is managing the PEP process and 178 | making decisions for which PEP will be accepted. And 179 | 180 | 37 181 | 00:04:09,771 --> 00:04:17,78 182 | then we also manage the core devs events, including 183 | the Python Language Summit, and the core sprint 184 | 185 | 38 186 | 00:04:17,8 --> 00:04:26,409 187 | stuff, and et cetera. A lot of stuff is 188 | actually managed by the Steering Council people. So 189 | 190 | 39 191 | 00:04:26,489 --> 00:04:35,019 192 | basically, the Steering Council is a group of Python 193 | people who direct and control all the evolution of the 194 | 195 | 40 196 | 00:04:35,039 --> 00:04:42,327 197 | Python language. So basically, that's a big work. And 198 | these are the most talented and the most 199 | 200 | 41 201 | 00:04:42,808 --> 00:04:49,478 202 | knowledgeable engineers in the Python core dev team. 203 | So I think that a lot of people should appreciate their 204 | 205 | 42 206 | 00:04:49,538 --> 00:04:56,81 207 | work, because it is really, really hard to move such a 208 | project. And can you please tell me about like, what is 209 | 210 | 43 211 | 00:04:56,91 --> 00:05:05,056 212 | a daily job of a Steering Council member? What do you do 213 | daily? What are your like, duties? Yeah, 214 | 215 | 44 216 | 00:05:05,096 --> 00:05:11,85 217 | so the first big change since I started my 218 | Steering Council work 219 | 220 | 45 221 | 00:05:11,87 --> 00:05:23,024 222 | is, to be honest, that I didn't read the PEPs as 223 | many as these days. But after I got promoted, after I 224 | 225 | 46 226 | 00:05:23,145 --> 00:05:30,025 227 | was elected as the Steering Council member, I obviously, I 228 | read all the PEPs, you know, three PEPs in a week, 229 | 230 | 47 231 | 00:05:30,045 --> 00:05:41,738 232 | and we actually discussed every bunch of PEPs in every 233 | weekly meeting. 234 | 235 | 48 236 | 00:05:41,859 --> 00:05:52,894 237 | In my time zone it is at 5 a.m., around 6 a.m. Friday, and we 238 | discuss the bunch of the PEPs that are on the list 239 | 240 | 49 241 | 00:05:53,235 --> 00:06:01,602 242 | for today. And then we discuss about each of the 243 | PEP, why it should be accepted, or 244 | 245 | 50 246 | 00:06:01,883 --> 00:06:09,472 247 | why it should be rejected, or why it should be 248 | updated to be more persuadable PEP for the SC 249 | 250 | 51 251 | 00:06:09,492 --> 00:06:17,942 252 | members. That's our normal task. And then the 253 | other stuff are actually included, like, 254 | 255 | 52 256 | 00:06:18,383 --> 00:06:25,552 257 | as you know, once you are promoted as the Python 258 | core dev, then you can, get a travel grant for the US 259 | 260 | 53 261 | 00:06:26,513 --> 00:06:34,003 262 | PyCon, then we should decide about the travel 263 | grant. And we need to discuss it with the member of the 264 | 265 | 54 266 | 00:06:34,063 --> 00:06:45,177 267 | PSF. And that kind of tasks are actually handled at every 268 | weekly meeting. So let's say that I want to write a PEP. 269 | 270 | 55 271 | 00:06:45,197 --> 00:06:55,234 272 | What should I start with? So if you are core dev, you 273 | can just write a PEP. And you can just share the draft 274 | 275 | 56 276 | 00:06:55,254 --> 00:07:03,723 277 | of PEP at the discuss.python.org. And then people 278 | will comment about it. And then finally, the 279 | 280 | 57 281 | 00:07:03,944 --> 00:07:11,452 282 | Steering Council members can review your PEP. But if 283 | you are not a core dev, you maybe need to find a 284 | 285 | 58 286 | 00:07:11,512 --> 00:07:19,582 287 | person who will sponsor your PEP. So that's the main 288 | difference between if the author is a core devs or 289 | 290 | 59 291 | 00:07:19,682 --> 00:07:28,092 292 | not. Let's say that I found someone from the core team 293 | who wants to sponsor this PEP that I wrote. What should 294 | 295 | 60 296 | 00:07:28,172 --> 00:07:36,643 297 | I put in this PEP for it to be accepted? Like, what are 298 | the sections, what are the examples and stuff like 299 | 300 | 61 301 | 00:07:36,683 --> 00:07:45,582 302 | this? Yeah, so there's a lot of PEPs that we 303 | actually accept. So there are many kinds of PEPs. 304 | 305 | 62 306 | 00:07:45,642 --> 00:07:51,739 307 | Sometimes it is a technical stuff and 308 | something it is a government stuff. So it's up to you what you 309 | 310 | 63 311 | 00:07:51,779 --> 00:08:01,536 312 | want to write. If you want to write the technical PEP, 313 | so you may need to fill why this PEP is needed and why 314 | 315 | 64 316 | 00:08:01,576 --> 00:08:09,791 317 | this PEP will give an advantage for the Python users 318 | and how we will not actually break a lot of things. It's 319 | 320 | 65 321 | 00:08:09,851 --> 00:08:17,496 322 | very important for the Python devs, because we are 323 | managing the, the very, very large code base, one of the biggest in 324 | 325 | 66 326 | 00:08:17,857 --> 00:08:23,964 327 | the world. So we are very careful in terms of the 328 | compatibility. And then, and also you should 329 | 330 | 67 331 | 00:08:25,085 --> 00:08:35,678 332 | persuade, like, how it will be effective, how it will 333 | affect a lot of code bases, you know, numerous 334 | 335 | 68 336 | 00:08:35,798 --> 00:08:43,491 337 | static stuff. So that kind of info should be included 338 | in your PEP. It is not that different from the technical 339 | 340 | 69 341 | 00:08:43,731 --> 00:08:49,296 342 | documentation that you are writing at any company. So 343 | if you're working at any tech company, 344 | 345 | 70 346 | 00:08:49,316 --> 00:08:56,743 347 | you are probably writing technical docs there, 348 | then it will be the same for the PEP. 349 | 350 | 71 351 | 00:08:56,783 --> 00:09:04,089 352 | Okay. Do you have any personal goals as a 353 | Steering Council member? For example, do you have any 354 | 355 | 72 356 | 00:09:04,61 --> 00:09:11,338 357 | big change that you want to achieve in the technical 358 | part of CPython or something like that? Oh, yes, 359 | 360 | 73 361 | 00:09:11,358 --> 00:09:16,806 362 | there are two things. First thing is a technical 363 | goal and the other thing is a non-technical one. 364 | 365 | 74 366 | 00:09:16,826 --> 00:09:28,464 367 | And so talking about the technical stuff, as you know, 368 | I'm very interested in the free-threading work. So I 369 | 370 | 75 371 | 00:09:28,824 --> 00:09:37,717 372 | think that I try to support the successful ending for 373 | the free-threading project. And, and if there is 374 | 375 | 76 376 | 00:09:37,777 --> 00:09:44,445 377 | something that needs an extra support, I will try to support them. And 378 | the other thing is the Faster CPython project. 379 | 380 | 77 381 | 00:09:44,766 --> 00:09:53,136 382 | There are many experimentation, including the JIT or 383 | Tier 2 interpreter. There are common areas for 384 | 385 | 78 386 | 00:09:53,176 --> 00:10:00,945 387 | the free-threading and Faster CPython. 388 | And the collaboration betwee the two is very, very 389 | 390 | 79 391 | 00:10:01,426 --> 00:10:09,658 392 | important. So I try to support them as well. Also these days 393 | many people are actually talking about the 394 | 395 | 80 396 | 00:10:09,978 --> 00:10:21,294 397 | ARM CPU, because unlike the x86, the ARM CPU 398 | is very energy efficient and it affects 399 | 400 | 81 401 | 00:10:21,314 --> 00:10:30,568 402 | cloud pricing, that's why people are very interested 403 | in using the ARM chips. But we need more efforts 404 | 405 | 82 406 | 00:10:30,608 --> 00:10:41,004 407 | for the more optimized CPython on the ARM. So, I try to 408 | support all people who work on that. So that's my main 409 | 410 | 83 411 | 00:10:41,024 --> 00:10:49,077 412 | technical interests. Secondly, as you know, 413 | many of the core devs are actually staying in the North 414 | 415 | 84 416 | 00:10:49,117 --> 00:10:57,365 417 | America and in Europe, mostly Western Europe. In 418 | APAC region, like Asia, Tokyo, or Korea, or 419 | 420 | 85 421 | 00:10:57,405 --> 00:11:04,295 422 | Singapore, or China, like there are just a few of core 423 | devs here. So I try to 424 | 425 | 86 426 | 00:11:04,415 --> 00:11:14,489 427 | represent our tech companies, 428 | when they're working on the CPython and try to 429 | 430 | 87 431 | 00:11:15,049 --> 00:11:22,35 432 | represent their needs. And also I try to organize the 433 | local core sprint, like that people can actually 434 | 435 | 88 436 | 00:11:22,43 --> 00:11:30,877 437 | participate even though only a few of the core devs stay 438 | in a APAC region. So that are two my main goals as the 439 | 440 | 89 441 | 00:11:31,358 --> 00:11:39,231 442 | Steering Council member for this year. Yeah, noble 443 | goals. I think that we should all support your deeds in 444 | 445 | 90 446 | 00:11:39,251 --> 00:11:47,832 447 | this field because I think that free-threading is a big 448 | feature and it should be the next milestone of Python 449 | 450 | 91 451 | 00:11:47,872 --> 00:11:53,222 452 | development and the next big milestone for the 453 | language itself. Yeah, really appreciate it. We have 454 | 455 | 92 456 | 00:11:53,262 --> 00:12:02,474 457 | one more question about your Steering Council work. I 458 | think that there are a lot of interesting PEPs that you 459 | 460 | 93 461 | 00:12:02,514 --> 00:12:10,164 462 | review and maybe you can name some of them like the most 463 | interesting ones to you or like the most technically 464 | 465 | 94 466 | 00:12:11,265 --> 00:12:19,536 467 | challenging, something like your top three PEPs that 468 | are in the works right now. Okay, so I actually cannot 469 | 470 | 95 471 | 00:12:19,556 --> 00:12:27,509 472 | pick the three PEPs at this moment. There are a lot of 473 | PEPs, but I can just pick 474 | 475 | 96 476 | 00:12:27,629 --> 00:12:39,387 477 | one. So one of my best PEPs, maybe of this year for me, is 478 | the PEPs 765 written by Irit Katriel. It's about 479 | 480 | 97 481 | 00:12:39,607 --> 00:12:47,271 482 | disallowing the return/break/continue at the finally 483 | block. This PEP is very well written 484 | 485 | 98 486 | 00:12:47,291 --> 00:12:57,501 487 | because it is very well researched. For example: 488 | how many people are actually using the wrong 489 | 490 | 99 491 | 00:12:57,561 --> 00:13:05,47 492 | Python code. And then, it actually suggests 493 | a way how to fix people's code 494 | 495 | 100 496 | 00:13:05,51 --> 00:13:15,975 497 | in a natural way without breaking anything. So, 498 | for me, it's the best PEP of this year, because it's 499 | 500 | 101 501 | 00:13:16,015 --> 00:13:25,437 502 | very persuasive and it also provides the statistics 503 | and it also provides a way to write a 504 | 505 | 102 506 | 00:13:25,478 --> 00:13:34,727 507 | better code. So both technical and non-technical 508 | stuff are great. I learned a lot of things from this PEP, so for 509 | 510 | 103 511 | 00:13:34,767 --> 00:13:43,59 512 | me, this PEP was the best that I read until this 513 | February. Maybe after this February we will have more great PEPs. 514 | 515 | 104 516 | 00:13:43,63 --> 00:13:50,985 517 | but for me, at this moment, this was the best PEP. I 518 | agree. That's a really great PEP. And I think that it 519 | 520 | 105 521 | 00:13:51,045 --> 00:14:03,079 522 | was one of the most problematic parts of the Python 523 | syntax. And I think that a lot of real-world code had 524 | 525 | 106 526 | 00:14:03,099 --> 00:14:12,727 527 | this bug. And it's great that we have ways now to fix it 528 | in a wider sense. Okay, we also want to talk about your 529 | 530 | 107 531 | 00:14:12,807 --> 00:14:22,015 532 | free-threading work because Steering Council is 533 | something like very few people touch but free-threading 534 | 535 | 108 536 | 00:14:22,295 --> 00:14:30,882 537 | is something for everyone. So, can you please explain 538 | what free-threading is in a very brief words for people 539 | 540 | 109 541 | 00:14:30,942 --> 00:14:40,05 542 | who are not familiar with it yet, because 3.13 was not so 543 | long ago and it still has this thing switched off by 544 | 545 | 110 546 | 00:14:40,07 --> 00:14:48,4 547 | default. Yeah, so I'm very happy to see that you are not 548 | using the term no-GIL. 549 | 550 | 111 551 | 00:14:48,821 --> 00:14:57,611 552 | Basically, free-threading is the project which tries to 553 | remove the GIL. And to be honest, it is at the 554 | 555 | 112 556 | 00:14:57,771 --> 00:15:05,86 557 | experimental stage of the CPython at this moment. And 558 | we are using the official term "free-threading" 559 | 560 | 113 561 | 00:15:05,98 --> 00:15:14,499 562 | instead of "no-GIL". So if you are using the "no-GIL", 563 | then you should change the term. So there was a lot of 564 | 565 | 114 566 | 00:15:14,579 --> 00:15:21,348 567 | tries to remove the GIL from the early years of the CPython. 568 | And many people tried to, and many people 569 | 570 | 115 571 | 00:15:21,368 --> 00:15:30,16 572 | actually failed. But a few years ago, I cannot remember 573 | which year, Sam Gross, who works at 574 | 575 | 116 576 | 00:15:30,48 --> 00:15:37,93 577 | Facebook* (organization is forbidden in Russia) AI Research, 578 | actually sent a mail that he succeed to remove GIL. And I believe that 579 | 580 | 117 581 | 00:15:38,062 --> 00:15:45,714 582 | nobody believed that the project was successful at 583 | that moment. Several people said: please show your 584 | 585 | 118 586 | 00:15:45,794 --> 00:15:52,945 587 | benchmarks. And then Sam showed the successful 588 | benchmark from the early release and everybody become 589 | 590 | 119 591 | 00:15:53,006 --> 00:15:59,998 592 | surprised. And here we are two years later. 593 | But, we still need the time for the analysis 594 | 595 | 120 596 | 00:16:00,158 --> 00:16:05,127 597 | There's a lot of components at the 598 | free-threading, like using the mimalloc and 599 | 600 | 121 601 | 00:16:05,168 --> 00:16:13,896 602 | new reference counting. And it took more 603 | than two years, from Python 3.13 to this very moment. 604 | 605 | 122 606 | 00:16:14,157 --> 00:16:22,358 607 | Many people actually participate in a 608 | free-threading project. And most of people are 609 | 610 | 123 611 | 00:16:22,498 --> 00:16:28,774 612 | actually from Meta* (organization is forbidden in Russia), 613 | because Meta* funded the project and still support it. 614 | 615 | 124 616 | 00:16:30,003 --> 00:16:38,073 617 | At the early stage, I actually had to set up the initial CI 618 | for using the GitHub Action for the free-threading CPython build 619 | 620 | 125 621 | 00:16:38,233 --> 00:16:44,02 622 | This is very technical, but very basic stuff, because we 623 | need to verify that the free-threading 624 | 625 | 126 626 | 00:16:44,04 --> 00:16:52,95 627 | Python is working well. And then, another thing is 628 | that I was focused on making the Python runtime 629 | 630 | 127 631 | 00:16:53,11 --> 00:16:59,919 632 | compatible with the free-threading project, because, 633 | one of the biggest technical challenge we are 634 | 635 | 128 636 | 00:16:59,979 --> 00:17:07,511 637 | facing with the free-threading Python is that we don't want to 638 | make a lot of the fragmentations between the regular 639 | 640 | 129 641 | 00:17:07,912 --> 00:17:15,565 642 | build and the free-threading build. Because, if 643 | you remove the GIL, everything suddenly is not 644 | 645 | 130 646 | 00:17:15,625 --> 00:17:24,48 647 | thread-safe. So at the Python runtime, we need to care 648 | about the data and thread-safety, 649 | 650 | 131 651 | 00:17:24,861 --> 00:17:32,038 652 | but you know, there are locks, critical sections, 653 | and atomic operations. You said two very important 654 | 655 | 132 656 | 00:17:32,439 --> 00:17:40,138 657 | phrases: atomics and critical sections. Can you 658 | please explain what these are for a wider audience? 659 | 660 | 133 661 | 00:17:40,237 --> 00:17:49,693 662 | Okay, so critical section is a sections that 663 | will guarantee the thread safety 664 | 665 | 134 666 | 00:17:49,713 --> 00:17:59,329 667 | without using an explicit lock. To simplify, 668 | just one thread can be involved in this 669 | 670 | 135 671 | 00:17:59,369 --> 00:18:07,043 672 | section, so everything will be thread safe in this 673 | section by definition, but the downside is, obviously, the cost. 674 | 675 | 136 676 | 00:18:07,083 --> 00:18:13,949 677 | The downside of the critical section is that be there 678 | could be a performance slowdown because the other 679 | 680 | 137 681 | 00:18:13,989 --> 00:18:23,137 682 | thread cannot be involve at this section and has to wait. But yeah, 683 | sometimes we need this feature. And atomic operations are not 684 | 685 | 138 686 | 00:18:23,197 --> 00:18:32,125 687 | like critical sections, they represent lower-level 688 | operations that can be processed in a single atomic way. So even if the 689 | 690 | 139 691 | 00:18:32,145 --> 00:18:40,032 692 | multiple threads try to modify a single atomic integer, 693 | it is guaranteed that there will be no race, and it will modified 694 | 695 | 140 696 | 00:18:40,534 --> 00:18:49,394 697 | one by one. So, but this does not guarantee the 698 | correct transaction inside the python objects. So, 699 | 700 | 141 701 | 00:18:49,594 --> 00:18:56,945 702 | the use case can be different between the critical 703 | sections and atomic operations. Note that 704 | 705 | 142 706 | 00:18:57,085 --> 00:19:01,821 707 | everything is happening in a C code base. So if you're 708 | just pure Python users, you don't have to care about it, but if 709 | 710 | 143 711 | 00:19:01,921 --> 00:19:09,284 712 | you are a C extension maintainer, then maybe you 713 | need to care about it. Yeah. You totally need to care 714 | 715 | 144 716 | 00:19:09,344 --> 00:19:16,152 717 | about it because you will totally need to support free-threading 718 | in some time in the future. And basically you 719 | 720 | 145 721 | 00:19:16,172 --> 00:19:23,86 722 | can say it like this. Atomic is a primitive supported by 723 | the compiler. Critical section is our own concept 724 | 725 | 146 726 | 00:19:23,88 --> 00:19:31,148 727 | that CPython maintains and supports as a feature. 728 | What about C extensions? Do authors of C extensions 729 | 730 | 147 731 | 00:19:31,268 --> 00:19:38,296 732 | would need to support free-threading soon? Yes, 733 | definitely. Maybe some of them do not need to 734 | 735 | 148 736 | 00:19:38,356 --> 00:19:47,066 737 | change anything, but I believe that, when you think about 738 | why people actually writing a C extension, it's mostly 739 | 740 | 149 741 | 00:19:47,086 --> 00:19:55,997 742 | because of the performance issues. So, there might be 743 | just pure C code that is not related to any Python 744 | 745 | 150 746 | 00:19:56,057 --> 00:20:05,795 747 | objects. So in that case, you don't really have to care about Python API. 748 | But, if you work with Python C-API, 749 | 750 | 151 751 | 00:20:05,835 --> 00:20:13,209 752 | in that case, you need to care about new race conditions. 753 | Even if you are 754 | 755 | 152 756 | 00:20:13,249 --> 00:20:22,559 757 | y using the C-API that provides borrowed reference 758 | count, then it will not guarantee the thread safety. 759 | 760 | 153 761 | 00:20:22,599 --> 00:20:30,427 762 | So, you have to change to be using the explicit reference 763 | count API. And then if you care about this stuff, like 764 | 765 | 154 766 | 00:20:30,547 --> 00:20:36,393 767 | if you search in the documentation, we already 768 | provide all the info about it. So you can read it and you can 769 | 770 | 155 771 | 00:20:36,413 --> 00:20:44,642 772 | switch to it. And if there is something that you need, like more API, 773 | then you can just file an issue, in the CPython repo, 774 | 775 | 156 776 | 00:20:44,722 --> 00:20:52,951 777 | then people will interact with your needs. I think 778 | that reference counting changed quite a bit in the 779 | 780 | 157 781 | 00:20:53,052 --> 00:21:03,271 782 | free-threading build. Can you please specify how and 783 | what changed about it? Yeah, it's very technical 784 | 785 | 158 786 | 00:21:03,331 --> 00:21:11,326 787 | stuff. So I'm not sure I can explain very easily, 788 | like in a simple way. Okay. So by default with the GIL, 789 | 790 | 159 791 | 00:21:11,366 --> 00:21:21,325 792 | there's just one reference count. This is why we needed the GIL 793 | before the free-threading build, because with multiple threads, 794 | 795 | 160 796 | 00:21:21,345 --> 00:21:30,323 797 | if they all try to modify the reference count, 798 | there will be a race condition. We need a lock. 799 | 800 | 161 801 | 00:21:30,443 --> 00:21:37,032 802 | In regular builds this lock is actually the GIL in the default build. 803 | But the free-threading build, there are 804 | 805 | 162 806 | 00:21:37,072 --> 00:21:46,527 807 | two reference counts. One is a shared reference 808 | count, and the other is, sorry I can't remember the other name. 809 | 810 | 163 811 | 00:21:46,768 --> 00:21:57,685 812 | But it's a reference count for 813 | the owner's thread. If the thread owns this object, 814 | 815 | 164 816 | 00:21:58,12 --> 00:22:08,839 817 | this thread can modify this reference count by itself 818 | without any atomic operation or locks. So, it will be 819 | 820 | 165 821 | 00:22:08,879 --> 00:22:18,296 822 | very fast. And if the other thread shares the same object, 823 | they actually modify the shared reference count. 824 | 825 | 166 826 | 00:22:18,616 --> 00:22:28,132 827 | And it will be modified by the atomic operation, and then it will 828 | be merged by the internal process. So it will be 829 | 830 | 167 831 | 00:22:28,192 --> 00:22:37,307 832 | guarantee the thread safety of the total 833 | reference count value. The basic hypothesis of this 834 | 835 | 168 836 | 00:22:37,844 --> 00:22:45,372 837 | approach is that the most of Python objects are 838 | actually owned by a single thread. In most cases, we 839 | 840 | 169 841 | 00:22:45,392 --> 00:22:54,101 842 | don't care about the shared reference count, but in some 843 | cases, when they need to be shared with the other thread, 844 | 845 | 170 846 | 00:22:54,241 --> 00:23:00,027 847 | then they will modify shared reference count, and 848 | there will be a small slowdown, but we can 849 | 850 | 171 851 | 00:23:00,127 --> 00:23:12,648 852 | overcome it. And if some object, CodeObject is 853 | a good example, that can be accessed by 854 | 855 | 172 856 | 00:23:12,668 --> 00:23:19,081 857 | multiple threads. In the case, we are actually using a 858 | deferred reference count. And this technique means that 859 | 860 | 173 861 | 00:23:21,005 --> 00:23:31,469 862 | we delay the reference count to a some point in the future. So, 863 | we can see that we have successfully overcomed multiple issues 864 | 865 | 174 866 | 00:23:31,99 --> 00:23:38,558 867 | tbat happened when we removed the GIL, as you can see, there are 868 | multiple techniques to do so. This is what 869 | 870 | 175 871 | 00:23:38,678 --> 00:23:43,805 872 | happened at the free-threading project. I'm not sure 873 | this is the easiest explanation, but this is my best 874 | 875 | 176 876 | 00:23:44,245 --> 00:23:51,254 877 | effort. Yeah. I think you did a great job. I really 878 | appreciate your explanation. Thank you. I also think 879 | 880 | 177 881 | 00:23:51,294 --> 00:23:57,944 882 | that we should mention how new GC will work, because if 883 | we touched reference counts, I think it's fair to 884 | 885 | 178 886 | 00:23:58,004 --> 00:24:04,553 887 | touch GC as well. Can you please share your thoughts 888 | about the future of GC and the work that has been done on 889 | 890 | 179 891 | 00:24:04,614 --> 00:24:13,947 892 | it? Yeah, so I'm not the expert of the GC, so I can't 893 | explain deep stuff in this talk. Yeah, me 894 | 895 | 180 896 | 00:24:13,967 --> 00:24:21,699 897 | neither. I have no idea how it works inside. It's too 898 | complex. Yeah, but two things, maybe. We introduced 899 | 900 | 181 901 | 00:24:21,739 --> 00:24:29,193 902 | Stop the World concept. It did not exist in the default build. 903 | It will be enabled in free-threading build. 904 | 905 | 182 906 | 00:24:29,254 --> 00:24:35,865 907 | And this is same mechanism when, if you're using Java or 908 | several other languages, because we need to stop 909 | 910 | 183 911 | 00:24:35,925 --> 00:24:45,861 912 | everything and the GC needs to collect all unusable 913 | objects. This is really important 914 | 915 | 184 916 | 00:24:46,583 --> 00:24:52,852 917 | for the interpreter. The other thing is, if I 918 | remember correctly, Mark Shannon is working on the 919 | 920 | 185 921 | 00:24:52,892 --> 00:25:00,719 922 | incremental GC, it's the 923 | same as the term, like it's handled incrementally, so 924 | 925 | 186 926 | 00:25:01,16 --> 00:25:07,832 927 | you can expect a faster GC, but at the moment, 928 | I cannot remember the progress of the 929 | 930 | 187 931 | 00:25:07,852 --> 00:25:13,803 932 | incremental GC, so I think you may want to open an original 933 | issue to find out more. Because I'm not the expert at 934 | 935 | 188 936 | 00:25:14,004 --> 00:25:23,238 937 | this area. I think that we had a very interesting bug 938 | back in 3.13, when in the last release candidate, when the 939 | 940 | 189 941 | 00:25:23,278 --> 00:25:30,508 942 | new GC was merged, and it slowed down a lot of cases for 943 | several noticeable percents, let's say it like this. 944 | 945 | 190 946 | 00:25:31,149 --> 00:25:40,683 947 | And people were very fast to create a new release 948 | candidate and to revert the GC change. And now we will 949 | 950 | 191 951 | 00:25:40,724 --> 00:25:49,481 952 | have the new GC in 3.14. I think so, at least I hope so, 953 | because this is a really big piece of work and not a lot 954 | 955 | 192 956 | 00:25:49,521 --> 00:25:58,372 957 | of people are aware of how hard it is to actually 958 | implement a garbage collector for language like 959 | 960 | 193 961 | 00:25:58,472 --> 00:26:07,643 962 | Python with all the backward compatibility 963 | guarantees in place. So you said that you are very 964 | 965 | 194 966 | 00:26:07,723 --> 00:26:15,683 967 | interested in ARM support and free-threading support. 968 | Do you have any specific work or specific issues that 969 | 970 | 195 971 | 00:26:15,723 --> 00:26:24,856 972 | you have in mind that are touching both of these 973 | topics? Yeah, so one thing I didn't talk about when I 974 | 975 | 196 976 | 00:26:24,916 --> 00:26:32,427 977 | explained the free-threading, as you know, 978 | Python 3.13 is just a kind of a pure proof of concept 979 | 980 | 197 981 | 00:26:32,707 --> 00:26:39,136 982 | version of the free-threading. And I know that people 983 | are actually disappointed with the single thread 984 | 985 | 198 986 | 00:26:39,217 --> 00:26:48,953 987 | performance issues in the free-threading build, it's very slow. 988 | Because when the free-threading was introduced, if I remember 989 | 990 | 199 991 | 00:26:48,973 --> 00:26:57,37 992 | correctly, it was based on the Python 3.9 and it didn't 993 | have the specializing interpreter that was written 994 | 995 | 200 996 | 00:26:57,43 --> 00:27:07,997 997 | by Mark Shannon. He's a very great man. So when we 998 | ported the Python free-threading, we didn't port the 999 | 1000 | 201 1001 | 00:27:08,858 --> 00:27:16,809 1002 | special writer at the Python 3.13. So that's the main 1003 | reason the free-threading was, the single thread of 1004 | 1005 | 202 1006 | 00:27:16,909 --> 00:27:27,52 1007 | free-threading is slow. So, but at the free 3.14, 1008 | Matt Page, Ken Jin, Sam Gross, and I, and Thomas 1009 | 1010 | 203 1011 | 00:27:27,56 --> 00:27:36,213 1012 | Wouters, and a lot of people actually joined. And we 1013 | successed to port the most of cases of the specializer to 1014 | 1015 | 204 1016 | 00:27:36,233 --> 00:27:45,105 1017 | be thread safe with using the per-thread mechanism. 1018 | So, we actually ran the benchmark a few weeks ago 1019 | 1020 | 205 1021 | 00:27:45,726 --> 00:27:57,047 1022 | between the GIL build and the free-threading. And it 1023 | now has 90% performance of the GIL build, so it's a lot 1024 | 1025 | 206 1026 | 00:27:57,107 --> 00:28:05,295 1027 | faster. So if you are using the free-threading at the 1028 | Python 3.14, you will not be disappointed with the single 1029 | 1030 | 207 1031 | 00:28:05,335 --> 00:28:11,22 1032 | thread performance. And more awesome things, you 1033 | know, like Ken Jin also introduced the tail call dispatch. 1034 | 1035 | 208 1036 | 00:28:11,26 --> 00:28:23,068 1037 | It can be used at, if your Python is built 1038 | by clang 19. And we noticed that the 1039 | 1040 | 209 1041 | 00:28:23,128 --> 00:28:32,872 1042 | the free-threading Python build with the Clang 19 and 1043 | the tail call dispatch is faster the 3.13 JIT build. So 1044 | 1045 | 210 1046 | 00:28:33,973 --> 00:28:41,044 1047 | you can enjoy everything. But if you are using the 1048 | technical specs with the default build, it will be faster. 1049 | 1050 | 211 1051 | 00:28:41,064 --> 00:28:48,095 1052 | I'm not sure like how to explain, but, 1053 | there are so many magical things that will happen in 3.14 1054 | 1055 | 212 1056 | 00:28:48,175 --> 00:28:56,488 1057 | So you can enjoy it. That's my simple 1058 | explanation. There were many attempts to make 1059 | 1060 | 213 1061 | 00:28:56,975 --> 00:29:05,55 1062 | Python bytecode dispatch logic be faster. 1063 | The first technique we are using is "computed goto". 1064 | 1065 | 214 1066 | 00:29:05,57 --> 00:29:17,653 1067 | And I think that this was the best effort for many 1068 | years. But starting from Clang 19, you can give a hint to the compiler, 1069 | 1070 | 215 1071 | 00:29:18,053 --> 00:29:28,044 1072 | to do the tail call dispatch. It's the same term that if you run 1073 | the algorithm, between the recursive call and 1074 | 1075 | 216 1076 | 00:29:28,164 --> 00:29:38,575 1077 | tail call, the later will be faster because it 1078 | doesn't need extra stack space and extra overhead, and 1079 | 1080 | 217 1081 | 00:29:38,735 --> 00:29:51,305 1082 | it also provides a kind of register optimization, 1083 | but it needs to be modified to be more familiar with the 1084 | 1085 | 218 1086 | 00:29:51,405 --> 00:30:03,578 1087 | tail call dispatch logic. At the moment Ken Jin is actually 1088 | re-writing a code generator to be more familiar with 1089 | 1090 | 219 1091 | 00:30:03,598 --> 00:30:13,376 1092 | the tail call optimization. Then if this tail call 1093 | dispatch is built by Clang 19, its performance 1094 | 1095 | 220 1096 | 00:30:13,496 --> 00:30:23,814 1097 | enhancement is almost 10%. So it is a very 1098 | amazing project. I think you can expect it soon. 1099 | 1100 | 221 1101 | 00:30:23,834 --> 00:30:31,285 1102 | Even if you don't know about the technical stuff about 1103 | how tail call dispatch works, 1104 | 1105 | 222 1106 | 00:30:31,305 --> 00:30:39,538 1107 | you can just use `uv`. And if you 1108 | use `uv` to install python 3.14 1109 | 1110 | 223 1111 | 00:30:40,419 --> 00:30:49,232 1112 | They are already building Python 3.14 by 1113 | Clang 19. So you can just be using it. 1114 | 1115 | 224 1116 | 00:30:49,252 --> 00:30:58,623 1117 | It is an awesome feature, I think. Yeah, it is one more 1118 | optimization, even better than computed GOTOs for 1119 | 1120 | 225 1121 | 00:30:58,683 --> 00:31:05,471 1122 | bytecode dispatch, and you should totally give it a 1123 | try. I think that it will be disabled by default for 1124 | 1125 | 226 1126 | 00:31:05,511 --> 00:31:16,638 1127 | this release. Am I wrong? Yeah, you're right. This is 1128 | my personal opinion about this decision, but this 1129 | 1130 | 227 1131 | 00:31:16,699 --> 00:31:26,118 1132 | is still in a consideration, okay? 1133 | The decision is not final. I believe that the 1134 | 1135 | 228 1136 | 00:31:26,138 --> 00:31:35,142 1137 | technical dispatch will not make big troubles, but 1138 | we cannot guarantee any safety 1139 | 1140 | 229 1141 | 00:31:35,362 --> 00:31:42,194 1142 | at this moment, because we need to know that actual 1143 | people are using it. There could be unexpected bugs. 1144 | 1145 | 230 1146 | 00:31:42,214 --> 00:31:50,965 1147 | Then we need to fix them. So, but if you can't enable it by default 1148 | in the Python 3.14. When you get the feedback, it might 1149 | 1150 | 231 1151 | 00:31:50,985 --> 00:32:01,459 1152 | take one or two years. It could be late. So people will 1153 | be in pain if there are bugs. So the right path is to 1154 | 1155 | 232 1156 | 00:32:01,479 --> 00:32:09,089 1157 | have it disabled to guarantee the more stable behavior. But 1158 | as I said, the `uv` actually already provides the 1159 | 1160 | 233 1161 | 00:32:09,129 --> 00:32:15,898 1162 | tail call dispatch from Python 3.14. You can 1163 | just test it and use it. And if there's no problem, it 1164 | 1165 | 234 1166 | 00:32:15,918 --> 00:32:23,55 1167 | might be enabled by default in the future. 1168 | Okay, I think that you've touched on one more very 1169 | 1170 | 235 1171 | 00:32:23,59 --> 00:32:31,742 1172 | interesting topic that I didn't specify in my 1173 | previous notes for you. But Relocatable Build is 1174 | 1175 | 236 1176 | 00:32:32,043 --> 00:32:37,571 1177 | also a very interesting big project that a lot of 1178 | people are working on right now. Can you please 1179 | 1180 | 237 1181 | 00:32:37,651 --> 00:32:47,076 1182 | explain how is it related to Python and what is going on 1183 | over there? Yeah. So, if you're using `uv`, 1184 | 1185 | 238 1186 | 00:32:47,096 --> 00:32:56,691 1187 | especially the part with the CPython distribution, 1188 | you're actually using a different Python binary that is actually 1189 | 1190 | 239 1191 | 00:32:56,751 --> 00:33:07,569 1192 | based on astandalone Python build, it is like 1193 | using the static build, which is focused on the 1194 | 1195 | 240 1196 | 00:33:07,609 --> 00:33:14,721 1197 | compatibility with the multiple platforms with just a 1198 | single build. So this is a very amazing project because 1199 | 1200 | 241 1201 | 00:33:16,203 --> 00:33:29,95 1202 | some of the people who work with a closed internet, or if 1203 | there's no internet, So it's just a one more new way to 1204 | 1205 | 242 1206 | 00:33:30,25 --> 00:33:38,85 1207 | deploy multiple Python distributions. This is a very 1208 | amazing project. If you're using the `uv python install`, you are 1209 | 1210 | 243 1211 | 00:33:39,492 --> 00:33:52,758 1212 | using this relocatable build concept. People from 1213 | Astral is now working closely with CPython devs to make 1214 | 1215 | 244 1216 | 00:33:53,099 --> 00:34:01,13 1217 | relocatable builds easier and faster and less error 1218 | prone because there are some bugs. I think that a lot of 1219 | 1220 | 245 1221 | 00:34:01,35 --> 00:34:09,401 1222 | problems on the relocatable builds are related to 1223 | our BOLT optimization. I saw like maybe five tickets 1224 | 1225 | 246 1226 | 00:34:09,441 --> 00:34:17,215 1227 | about it, something like that. Yeah. We need to 1228 | separate these two topics with this issue, 1229 | 1230 | 247 1231 | 00:34:17,235 --> 00:34:24,765 1232 | because they are building Python 1233 | using a static build, with no dynamic linking. 1234 | 1235 | 248 1236 | 00:34:24,865 --> 00:34:34,737 1237 | You can expect that the final binary is huge, 1238 | way bigger than the normal Python binary. 1239 | 1240 | 249 1241 | 00:34:34,797 --> 00:34:42,754 1242 | So, BOLT is an optimizer tool that is developed by Meta* 1243 | (organization is forbidden in Russia) 1244 | 1245 | 250 1246 | 00:34:43,417 --> 00:34:50,526 1247 | and there are multiple compiler optimization 1248 | techniques, the basic stuff might be if you pass the 1249 | 1250 | 251 1251 | 00:34:50,706 --> 00:35:01,062 1252 | option `-01`, `-02`, `-03` to the GCC, the compiler will 1253 | optimize your code, via their policy. And that's the one 1254 | 1255 | 252 1256 | 00:35:01,102 --> 00:35:13,188 1257 | part of the optimization process. And the other one 1258 | is PGO, it actually gathered the 1259 | 1260 | 253 1261 | 00:35:13,208 --> 00:35:22,841 1262 | profiling from your runtime and then regenerate the 1263 | binary by the compiler. That we call normal compiler 1264 | 1265 | 254 1266 | 00:35:22,901 --> 00:35:32,914 1267 | optimizer process. But the other stuff is what we call the 1268 | post-binary optimizer. Since the binary is huge, 1269 | 1270 | 255 1271 | 00:35:34,557 --> 00:35:42,195 1272 | there's a lot of error and cache miss ratio. 1273 | And so the one of the techniques they are 1274 | 1275 | 256 1276 | 00:35:42,296 --> 00:35:50,19 1277 | using is like the same as the PGO. They actually gather 1278 | the profiles in two ways. One is the 1279 | 1280 | 257 1281 | 00:35:50,23 --> 00:35:55,499 1282 | instrumentation and the other way is like, 1283 | live, like in production traffic 1284 | 1285 | 258 1286 | 00:35:56,02 --> 00:36:06,659 1287 | profiling. And then they relocate the 1288 | binary layout to be more optimized with the cache, 1289 | 1290 | 259 1291 | 00:36:06,679 --> 00:36:14,061 1292 | add-on cache. For example, if some of your code area is 1293 | exported very frequently, they are clustered. And if 1294 | 1295 | 260 1296 | 00:36:14,181 --> 00:36:24,316 1297 | this is less executed area, they are separated from the 1298 | core area. And then we can expect that the cache miss is 1299 | 1300 | 261 1301 | 00:36:24,817 --> 00:36:31,727 1302 | reduced. And then they also eliminate unnecessary 1303 | binary area. The final binary size can be reduced. So that's 1304 | 1305 | 262 1306 | 00:36:31,787 --> 00:36:37,516 1307 | why they are working on BOLT because like they are 1308 | major customer who is using BOLT. We added 1309 | 1310 | 263 1311 | 00:36:37,977 --> 00:36:45,374 1312 | the BOLT support in, maybe, 3.13 to CPython. I don't remember 1313 | correctly, This is why they are actually 1314 | 1315 | 264 1316 | 00:36:45,434 --> 00:36:54,747 1317 | working on it. I think that BOLT was introduced in 1318 | Python 3.12. Yeah, 3.12, right. Something like that. And 1319 | 1320 | 265 1321 | 00:36:54,847 --> 00:37:04,018 1322 | I think that you were the person who contributed it. So, 1323 | it's one more big project from you. Let's give a 1324 | 1325 | 266 1326 | 00:37:04,038 --> 00:37:16,372 1327 | credit. But I have to say, BOLT was actually a 1328 | first attempted from the Pyston people. 1329 | 1330 | 267 1331 | 00:37:16,392 --> 00:37:25,31 1332 | People who worked at Dropbox and then they developed 1333 | the Pyston version of Python at Dropbox. 1334 | 1335 | 268 1336 | 00:37:25,571 --> 00:37:34,423 1337 | After they left Dropbox, they organized 1338 | Faster CPython project. 1339 | 1340 | 269 1341 | 00:37:35,084 --> 00:37:41,593 1342 | In Pyston one of the optimization 1343 | they were using was BOLT. We actually 1344 | 1345 | 270 1346 | 00:37:41,653 --> 00:37:52,251 1347 | adopted their technique. I want to say that the major 1348 | works were done by those people and my work was like 1349 | 1350 | 271 1351 | 00:37:52,451 --> 00:37:58,346 1352 | supporting the BOLT PR landing, for example, 1353 | in detecting parts where we can use it. So I thank you for 1354 | 1355 | 272 1356 | 00:37:58,447 --> 00:38:07,973 1357 | the credit, but I need to clarify that. And also credit other 1358 | people. Yeah. Okay, so I think that I have 1359 | 1360 | 273 1361 | 00:38:08,514 --> 00:38:16,865 1362 | one last technical question, but it is also a very deep 1363 | one, so let's prepare our audience for it. I think that 1364 | 1365 | 274 1366 | 00:38:17,546 --> 00:38:26,698 1367 | in Python 3.14 there will be a big change to our JIT 1368 | pipeline, because right now we require LLVM as a build 1369 | 1370 | 275 1371 | 00:38:26,738 --> 00:38:34,348 1372 | time dependency. and it is proposed to eliminate that 1373 | dependency in the build time. Do you have any 1374 | 1375 | 276 1376 | 00:38:34,388 --> 00:38:42,818 1377 | information about it? Like, what is going to happen 1378 | and how it works? Yeah, so like there is a trial to 1379 | 1380 | 277 1381 | 00:38:42,878 --> 00:38:50,327 1382 | remove the build dependency for the LLVM in the 1383 | CPython, but there's also a PEP about it, 1384 | 1385 | 278 1386 | 00:38:50,367 --> 00:38:58,237 1387 | and Steering Council actually review this PEP at the moment. 1388 | So, at the moment, I cannot say anything about the PEP. 1389 | 1390 | 279 1391 | 00:38:58,258 --> 00:39:05,868 1392 | It would be hard for me at this moment. 1393 | Okay, yeah, completely understand it. 1394 | 1395 | 280 1396 | 00:39:05,888 --> 00:39:14,119 1397 | I think that we should put a link to this PEP in the 1398 | description so people can read it and express their 1399 | 1400 | 281 1401 | 00:39:14,159 --> 00:39:22,869 1402 | opinion in the discussion thread, in the discourse, 1403 | if they have such opinions. This is my personal 1404 | 1405 | 282 1406 | 00:39:22,949 --> 00:39:31,381 1407 | opinion, but if we successful end this project, 1408 | those build tasks will not be needed. 1409 | 1410 | 283 1411 | 00:39:31,401 --> 00:39:40,293 1412 | So, yeah, that would be a very important PEP 1413 | for the project. But, the final decision will be, will 1414 | 1415 | 284 1416 | 00:39:40,313 --> 00:39:46,922 1417 | be handled by Steering Council. So I cannot say 1418 | anything. Okay. Okay. I don't have any opinion 1419 | 1420 | 285 1421 | 00:39:47,102 --> 00:39:54,767 1422 | either, because this is way out of my expertise area. 1423 | One last question about your other 1424 | 1425 | 286 1426 | 00:39:54,787 --> 00:40:03,401 1427 | activity. You said that you also organize sprints in 1428 | your hometown and that you invite people to join and 1429 | 1430 | 287 1431 | 00:40:03,481 --> 00:40:09,771 1432 | participate. Can you please tell a little bit more 1433 | about what these sprints are and what are the results 1434 | 1435 | 288 1436 | 00:40:09,931 --> 00:40:17,062 1437 | and how you organize them? What should people do 1438 | there? Yeah, so every region, there might be a lot of 1439 | 1440 | 289 1441 | 00:40:17,202 --> 00:40:25,794 1442 | local sprints for the CPython development, but like in Korea or 1443 | Japan or Thailand, maybe Russia, I know that 1444 | 1445 | 290 1446 | 00:40:25,954 --> 00:40:34,406 1447 | there are no sprints that are organized by core 1448 | developers. So for some people, it might be 1449 | 1450 | 291 1451 | 00:40:34,866 --> 00:40:43,724 1452 | difficult to participate in US PyCon because of the 1453 | financial issues, distance, 1454 | 1455 | 292 1456 | 00:40:43,844 --> 00:40:56,221 1457 | or finance, or busy schedule. So I try to 1458 | organize the sprint that you can work on the CPython in 1459 | 1460 | 293 1461 | 00:40:56,261 --> 00:41:04,85 1462 | a single day in Korea. I try to provide the help and the 1463 | manual about how you can contribute to 1464 | 1465 | 294 1466 | 00:41:04,89 --> 00:41:12,198 1467 | CPython and how to run the CI, how to run the new tasks, 1468 | and how you can write new code, and how to get 1469 | 1470 | 295 1471 | 00:41:12,298 --> 00:41:24,201 1472 | a review from the CPython team. That is one of my 1473 | trial to organize a sprint at my local area. 1474 | 1475 | 296 1476 | 00:41:24,221 --> 00:41:31,634 1477 | Because I think that those kinds of activity is 1478 | one of the ways that people can improve the 1479 | 1480 | 297 1481 | 00:41:31,694 --> 00:41:38,126 1482 | community driven ranking in CPython. People 1483 | represent their stance and what their needs are and 1484 | 1485 | 298 1486 | 00:41:38,266 --> 00:41:44,296 1487 | if they take a part in solving issues, so they can be 1488 | more familiar with the process. So I believe that such activity can 1489 | 1490 | 299 1491 | 00:41:44,357 --> 00:41:54,063 1492 | make more interactions between the Python core team 1493 | and other people. 1494 | 1495 | 300 1496 | 00:41:54,103 --> 00:42:02,082 1497 | Thank you. This is a really great activity, 1498 | and I hope one day to 1499 | 1500 | 301 1501 | 00:42:02,162 --> 00:42:07,871 1502 | participate in such events, or maybe even organize 1503 | it, because I completely agree. Letting people know 1504 | 1505 | 302 1506 | 00:42:07,911 --> 00:42:18,006 1507 | that contributing to CPython is easy and fun is a big 1508 | goal, because a lot of people assume that it is a hard 1509 | 1510 | 303 1511 | 00:42:18,567 --> 00:42:28,564 1512 | work that is not fun, but it is a hard work that is fun. 1513 | And I think that a lot of people should know that you can 1514 | 1515 | 304 1516 | 00:42:28,604 --> 00:42:35,617 1517 | do it and you should do it. And I try to encourage people 1518 | with my videos as well to contribute to CPython, to 1519 | 1520 | 305 1521 | 00:42:35,697 --> 00:42:44,83 1522 | report issues about some unexpected behavior and 1523 | stuff like that. So this year, 1524 | 1525 | 306 1526 | 00:42:44,87 --> 00:42:51,478 1527 | in my schedule is South Korea, 1528 | I try to organize it around August. So if you visit 1529 | 1530 | 307 1531 | 00:42:51,538 --> 00:43:02,43 1532 | Korea, maybe PyKR is happening at August 15th. So you 1533 | can join the sprint if you visit Korea. And I also plan 1534 | 1535 | 308 1536 | 00:43:02,49 --> 00:43:11,947 1537 | to visit Taiwan this year. So maybe if you have a plan 1538 | to visit Taiwan, maybe you can also visit the sprint. 1539 | 1540 | 309 1541 | 00:43:12,067 --> 00:43:20,362 1542 | And if there are other chances, I will try to support them as well. 1543 | And I think that you also can maybe organize a sprint. So if you need 1544 | 1545 | 310 1546 | 00:43:20,602 --> 00:43:31,702 1547 | kind of resources for the local sprint, I happily 1548 | provide what I use for the local sprint at the Tokyo or 1549 | 1550 | 311 1551 | 00:43:31,722 --> 00:43:41,471 1552 | Seoul or any other area. Awesome. Thank you. And once 1553 | again, very big respect for your work on CPython and 1554 | 1555 | 312 1556 | 00:43:41,592 --> 00:43:48,446 1557 | your Steering Council work. We should really 1558 | appreciate people like you and give credit for all the 1559 | 1560 | 313 1561 | 00:43:48,486 --> 00:43:55,26 1562 | hard work they do for all of the rest of the world. 1563 | Thanks again, and thank you for coming and giving this 1564 | 1565 | 314 1566 | 00:43:55,341 --> 00:44:02,615 1567 | interview. And I hope people will enjoy it. And if you 1568 | leave your contacts, your GitHub handle, for 1569 | 1570 | 315 1571 | 00:44:02,675 --> 00:44:11,604 1572 | example, and people will have some questions about 1573 | free-threading issues, can they tag you? Yeah, so I will 1574 | 1575 | 316 1576 | 00:44:11,644 --> 00:44:21,816 1577 | provide my GitHub username. My handle is actually a very 1578 | weird name. It's @corona10. It's not related to that 1579 | 1580 | 317 1581 | 00:44:21,836 --> 00:44:32,828 1582 | Corona. Yeah, but I'm using it before maybe 2019, so I 1583 | don't care about it. So my handle at GitHub is @corona10 1584 | 1585 | 318 1586 | 00:44:32,948 --> 00:44:45,708 1587 | and my Twitter is @dongheena92, 92 is my birthday year, so 1588 | you can interact with me if you want. And my mail is 1589 | 1590 | 319 1591 | 00:44:45,969 --> 00:44:51,796 1592 | donghee.na@python.org. I will put everything in the 1593 | description so people can contact you. 1594 | 1595 | 320 1596 | 00:44:51,836 --> 00:44:57,163 1597 | You can just send me an email and I will 1598 | happily reply if you have any interest about 1599 | 1600 | 321 1601 | 00:44:57,303 --> 00:45:05,691 1602 | contributing to CPython. I know one thing I want to say to 1603 | Nikita, you are also an awesome core 1604 | 1605 | 322 1606 | 00:45:05,712 --> 00:45:12,579 1607 | dev who interact with the external contributors. So, 1608 | like, I want to say also thank you to all your 1609 | 1610 | 323 1611 | 00:45:12,98 --> 00:45:19,568 1612 | activity, and CPython work. Yeah. I very respect 1613 | your activities, including the triaging 1614 | 1615 | 324 1616 | 00:45:19,688 --> 00:45:26,496 1617 | issues, fixing everything. Yeah. I very respect 1618 | your activitis too. Yeah, thank you. Thank you. 1619 | 1620 | 325 1621 | 00:45:26,656 --> 00:45:33,163 1622 | Thank you. Bye bye. And that's all for now. I hope it was 1623 | interesting, because during the interview it was 1624 | 1625 | 326 1626 | 00:45:33,243 --> 00:45:39,52 1627 | really very interesting for me personally. I learned a lot of new 1628 | things, I talked to an amazing smart person, and it's 1629 | 1630 | 327 1631 | 00:45:39,54 --> 00:45:47,065 1632 | always very nice. And I hope that now you also know that 1633 | you can manage such a programming language as Python. 1634 | 1635 | 328 1636 | 00:45:47,426 --> 00:45:53,357 1637 | This is a realistic goal for engineers who are 1638 | interested in this. And I hope that maybe at least one 1639 | 1640 | 329 1641 | 00:45:53,377 --> 00:45:58,867 1642 | of you I was able to motivate to develop your skills in this 1643 | direction. I will be happy to help in any way if someone 1644 | 1645 | 330 1646 | 00:45:58,887 --> 00:46:05,398 1647 | wants to. And I have three wonderful links, as usual. 1648 | The first link is my GitHub. You can support my work 1649 | 1650 | 331 1651 | 00:46:05,418 --> 00:46:11,688 1652 | there by putting some stars, some forks. You can 1653 | support my work on Boosty if you want to support with 1654 | 1655 | 332 1656 | 00:46:11,868 --> 00:46:18,679 1657 | rubles, it's always nice. I do not offer any unique 1658 | content, I believe that all content should be free and 1659 | 1660 | 333 1661 | 00:46:19,02 --> 00:46:24,348 1662 | open to everyone, so this is just additional 1663 | motivation for me. And, of course, my Telegram 1664 | 1665 | 334 1666 | 00:46:24,368 --> 00:46:32,344 1667 | channel. My Telegram channel is a place where a lot of 1668 | technical stuff about Python is written. So if you 1669 | 1670 | 335 1671 | 00:46:32,364 --> 00:46:38,116 1672 | like this kind of content, join us. For example, 1673 | recently I wrote a series of two posts about how GIL 1674 | 1675 | 336 1676 | 00:46:38,197 --> 00:46:44,569 1677 | works in Python. And, of course, I showed the code in 1678 | C, which physically shows different Python's guts 1679 | 1680 | 337 1681 | 00:46:44,589 --> 00:46:50,798 1682 | and operating system in order to show how the GIL 1683 | switching actually happens. So if you are interested 1684 | 1685 | 338 1686 | 00:46:50,818 --> 00:46:56,627 1687 | in text content about Python's guts, feel free to join. 1688 | Well, if you want to see someone specific as a 1689 | 1690 | 339 1691 | 00:46:56,647 --> 00:47:01,514 1692 | guest, you can write in the comments who you would like 1693 | to see, and I will try to invite this person and talk to 1694 | 1695 | 340 1696 | 00:47:01,534 --> 00:47:05,5 1697 | them about what they do. That's all from me, thank you 1698 | very much, bye. 1699 | -------------------------------------------------------------------------------- /editing/captions/14/ru.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:00,571 --> 00:00:05,738 3 | Всем привет, меня зовут Никита Соболев, и это 4 | лучший курс по Python. Сегодня у нас необычное 5 | 6 | 2 7 | 00:00:05,758 --> 00:00:12,206 8 | видео, можно сказать, особенное и уникальное, потому что наш 9 | гость сегодня особенный и уникальный. Сегодня я буду говорить 10 | 11 | 3 12 | 00:00:12,306 --> 00:00:19,876 13 | с другим разработчиком ядра Python, который знает много 14 | о том, как работают свободные потоки, JIT, а также многие другие 15 | 16 | 4 17 | 00:00:19,896 --> 00:00:25,824 18 | внутренние части Python. Он также является членом 19 | Steering Council. Это такой специальный управляющий 20 | 21 | 5 22 | 00:00:25,844 --> 00:00:32,862 23 | орган для всего Python. И, конечно, я специально 24 | подготовил для вас русские субтитры. Вы можете включить их 25 | 26 | 6 27 | 00:00:32,882 --> 00:00:37,795 28 | прямо на YouTube и слушать на английском, а читать на 29 | русском, если вам так удобнее. Также есть 30 | 31 | 7 32 | 00:00:38,517 --> 00:00:46,536 33 | английские субтитры, так что вы можете использовать их, если хотите. Я 34 | очень хочу, чтобы все разработчики Python понимали, как 35 | 36 | 8 37 | 00:00:46,556 --> 00:00:51,546 38 | управляется такой большой проект, как самый 39 | популярный язык программирования в мире. Потому что 40 | 41 | 9 42 | 00:00:51,566 --> 00:00:58,439 43 | это тоже настоящая инженерная задача. Конечно, не 44 | каждый из нас столкнется с этим в реальной жизни. 45 | 46 | 10 47 | 00:00:58,459 --> 00:01:03,147 48 | Однако ничто не мешает нам посмотреть, как это 49 | действительно работает, и привнести что-то новое и 50 | 51 | 11 52 | 00:01:03,468 --> 00:01:08,096 53 | интересное в нашу жизнь. Многие до сих пор 54 | ошибочно полагают, что Гвидо ван Россум принимает все 55 | 56 | 12 57 | 00:01:08,116 --> 00:01:13,264 58 | решения самостоятельно. Однако это не так. 59 | Сейчас Python управляется Steering Council. Это 60 | 61 | 13 62 | 00:01:13,284 --> 00:01:19,955 63 | избранный комитет из пяти человек, который меняется 64 | каждый год. Любой разработчик ядра может войти в него, даже 65 | 66 | 14 67 | 00:01:19,975 --> 00:01:27,066 68 | не разработчики ядра. Именно Steering Council 69 | решает, какие PEP будут приняты, а какие PEP 70 | 71 | 15 72 | 00:01:27,086 --> 00:01:32,515 73 | будут отклонены. То есть буквально пять 74 | человек определяют судьбу всего Python. Сегодня я 75 | 76 | 16 77 | 00:01:32,595 --> 00:01:39,202 78 | пригласил одного из них, чтобы поговорить обо всем этом процессе. 79 | И, конечно, когда такой человек приходит к вам в гости, 80 | 81 | 17 82 | 00:01:39,382 --> 00:01:44,988 83 | вы не можете не спросить его о других интересных 84 | темах. Например, Донгхи На — один из основных 85 | 86 | 18 87 | 00:01:45,008 --> 00:01:50,314 88 | участников проекта свободных потоков. Мы также 89 | немного затронем вопрос JIT, потому что сейчас 90 | 91 | 19 92 | 00:01:50,334 --> 00:01:56,521 93 | рассматривается PEP, который изменит работу JIT, 94 | и это очень интересно обсудить. Ну, 95 | 96 | 20 97 | 00:01:56,541 --> 00:02:03,775 98 | мы также затронем такие две темы, как Relocatable 99 | Builds и BOLT. Для тех, кто не знает, что это такое, конечно, 100 | 101 | 21 102 | 00:02:03,855 --> 00:02:08,804 103 | мы расскажем все во время интервью. Ну а теперь перейдем 104 | к самому интервью. Давайте начнем. Донгхи На, очень 105 | 106 | 22 107 | 00:02:08,884 --> 00:02:16,878 108 | приятно видеть вас здесь. Вы очень, очень 109 | талантливый разработчик и член Steering Council. И 110 | 111 | 23 112 | 00:02:16,918 --> 00:02:22,646 113 | сегодня мы поговорим о вашем вкладе в Python, 114 | вашей работе в Steering Council и многом 115 | 116 | 24 117 | 00:02:22,686 --> 00:02:29,334 118 | другом, связанном с CPython. Спасибо большое за то, что присоединились, 119 | и, пожалуйста, представьтесь. ОК, привет. Меня зовут 120 | 121 | 25 122 | 00:02:29,354 --> 00:02:40,446 123 | Донгхи, я из Южной Кореи. Я начал вносить вклад в CPython 124 | с 2017 года, а в 2020 году стал разработчиком ядра 125 | 126 | 26 127 | 00:02:41,127 --> 00:02:48,274 128 | CPython. Сейчас я работаю членом Steering Council 129 | с этого года. В последнее время я сосредоточен на том, как 130 | 131 | 27 132 | 00:02:48,395 --> 00:02:58,36 133 | работают свободные потоки и другие аспекты CPython. Мне 134 | очень нравится вносить вклад в open source, да. Это действительно 135 | 136 | 28 137 | 00:02:58,4 --> 00:03:05,527 138 | здорово, потому что вы были первым, кто познакомил 139 | меня с командой Python Triage в 2021 или 2022 году, 140 | 141 | 29 142 | 00:03:05,587 --> 00:03:14,745 143 | где-то так. И я до сих пор благодарен за это. 144 | Спасибо. Было очень весело работать триажером 145 | 146 | 30 147 | 00:03:14,765 --> 00:03:22,718 148 | и изучать все рабочие процессы Python и его внутренности. 149 | Не могли бы вы объяснить моей аудитории, что такое 150 | 151 | 31 152 | 00:03:23,159 --> 00:03:29,805 153 | Steering Council? Да, Python Steering Council — это 154 | небольшая группа разработчиков ядра Python, 155 | 156 | 32 157 | 00:03:29,845 --> 00:03:36,411 158 | которые избираются для наблюдения за разработкой и 159 | направлением развития языка Python. С 2018 года, 160 | 161 | 33 162 | 00:03:36,491 --> 00:03:45,079 163 | после того как Гвидо ушел с позиции BDFL, был 164 | сформирован первый Steering Council, и 165 | 166 | 34 167 | 00:03:45,219 --> 00:03:54,804 168 | Гвидо был одним из его членов в первый год. 169 | Основная ответственность 170 | 171 | 35 172 | 00:03:54,824 --> 00:04:01,975 173 | Steering Council заключается в управлении процессом PEP и 174 | принятии решений о том, какие PEP будут приняты. И 175 | 176 | 36 177 | 00:04:01,995 --> 00:04:09,711 178 | мы также управляем событиями для разработчиков ядра, включая 179 | Python Language Summit и спринты разработчиков ядра, 180 | 181 | 37 182 | 00:04:09,771 --> 00:04:17,78 183 | и так далее. Многое на самом деле 184 | управляется людьми из Steering Council. Так что 185 | 186 | 38 187 | 00:04:17,8 --> 00:04:26,409 188 | в основном Steering Council — это группа людей из Python, 189 | которая направляет и контролирует всю эволюцию 190 | 191 | 39 192 | 00:04:26,489 --> 00:04:35,019 193 | языка Python. Это большая работа. И 194 | это самые талантливые и самые 195 | 196 | 40 197 | 00:04:35,039 --> 00:04:42,327 198 | знающие инженеры в команде разработчиков ядра Python. 199 | Я думаю, что многие люди должны ценить их 200 | 201 | 41 202 | 00:04:42,808 --> 00:04:49,478 203 | работу, потому что действительно очень сложно двигать 204 | такой проект. Не могли бы вы рассказать, в чем 205 | 206 | 42 207 | 00:04:49,538 --> 00:04:56,81 208 | заключается ежедневная работа члена Steering Council? Что вы делаете 209 | ежедневно? Каковы ваши обязанности? Да, 210 | 211 | 43 212 | 00:04:56,91 --> 00:05:05,056 213 | первое большое изменение с тех пор, как я начал работать 214 | в Steering Council, 215 | 216 | 44 217 | 00:05:05,096 --> 00:05:11,85 218 | честно говоря, это то, что я не читал столько PEP, 219 | сколько читаю сейчас. Но после того, как я 220 | 221 | 45 222 | 00:05:11,87 --> 00:05:23,024 223 | был избран членом Steering Council, я, конечно же, 224 | читаю все PEP, знаете, три PEP в неделю, 225 | 226 | 46 227 | 00:05:23,145 --> 00:05:30,025 228 | и мы обсуждаем каждую группу PEP на еженедельных 229 | встречах. 230 | 231 | 47 232 | 00:05:30,045 --> 00:05:41,738 233 | В моем часовом поясе это около 5 утра, в районе 6 утра в пятницу, и мы 234 | обсуждаем группу PEP, которые находятся в списке 235 | 236 | 48 237 | 00:05:41,859 --> 00:05:52,894 238 | на сегодня. Затем мы обсуждаем каждый PEP, 239 | почему его следует принять, или 240 | 241 | 49 242 | 00:05:53,235 --> 00:06:01,602 243 | почему его следует отклонить, или почему его следует 244 | обновить, чтобы он стал более убедительным для членов SC. 245 | 246 | 50 247 | 00:06:01,883 --> 00:06:09,472 248 | Это наша обычная задача. Кроме того, мы занимаемся 249 | другими вещами, например, 250 | 251 | 51 252 | 00:06:09,492 --> 00:06:17,942 253 | как вы знаете, когда вас повышают до разработчика ядра Python, 254 | вы можете получить грант на поездку на PyCon в США, 255 | 256 | 52 257 | 00:06:18,383 --> 00:06:25,552 258 | и мы должны решить, кому выдать грант. 259 | Мы обсуждаем это с членами 260 | 261 | 53 262 | 00:06:26,513 --> 00:06:34,003 263 | PSF. И такие задачи решаются на каждой 264 | еженедельной встрече. Допустим, я хочу написать PEP. 265 | 266 | 54 267 | 00:06:34,063 --> 00:06:45,177 268 | С чего мне начать? Если вы разработчик ядра, вы 269 | можете просто написать PEP. И вы можете поделиться черновиком 270 | 271 | 55 272 | 00:06:45,197 --> 00:06:55,234 273 | PEP на discuss.python.org. Затем люди 274 | будут комментировать его. И, наконец, 275 | 276 | 56 277 | 00:06:55,254 --> 00:07:03,723 278 | члены Steering Council могут рассмотреть ваш PEP. Но если 279 | вы не разработчик ядра, вам, возможно, нужно найти 280 | 281 | 57 282 | 00:07:03,944 --> 00:07:11,452 283 | человека, который спонсирует ваш PEP. Это основное 284 | различие между автором, являющимся разработчиком ядра, и 285 | 286 | 58 287 | 00:07:11,512 --> 00:07:19,582 288 | не являющимся им. Допустим, я нашел кого-то из команды ядра, 289 | кто хочет спонсировать этот PEP, который я написал. Что я должен 290 | 291 | 59 292 | 00:07:19,682 --> 00:07:28,092 293 | включить в этот PEP, чтобы его приняли? Какие разделы, 294 | примеры и тому подобное? 295 | 296 | 60 297 | 00:07:28,172 --> 00:07:36,643 298 | Да, есть много PEP, которые мы 299 | принимаем. Есть разные виды PEP. 300 | 301 | 61 302 | 00:07:36,683 --> 00:07:45,582 303 | Иногда это технические вещи, а иногда 304 | это управленческие вещи. Так что это зависит от того, что вы 305 | 306 | 62 307 | 00:07:45,642 --> 00:07:51,739 308 | хотите написать. Если вы хотите написать технический PEP, 309 | вам нужно объяснить, зачем этот PEP нужен и какую 310 | 311 | 63 312 | 00:07:51,779 --> 00:08:01,536 313 | преимущество он даст пользователям Python, и как 314 | мы не сломаем многое. Это 315 | 316 | 64 317 | 00:08:01,576 --> 00:08:09,791 318 | очень важно для разработчиков Python, потому что мы 319 | управляем очень, очень большой кодовой базой, одной из самых больших в 320 | 321 | 65 322 | 00:08:09,851 --> 00:08:17,496 323 | мире. Поэтому мы очень осторожны в вопросах 324 | совместимости. И также вы должны 325 | 326 | 66 327 | 00:08:17,857 --> 00:08:23,964 328 | убедить, как это будет эффективно, как это повлияет 329 | на множество кодовых баз, знаете, множество 330 | 331 | 67 332 | 00:08:25,085 --> 00:08:35,678 333 | статических вещей. Такого рода информация должна быть 334 | включена в ваш PEP. Это не сильно отличается от технической 335 | 336 | 68 337 | 00:08:35,798 --> 00:08:43,491 338 | документации, которую вы пишете в любой компании. Так что 339 | если вы работаете в любой технологической компании, 340 | 341 | 69 342 | 00:08:43,731 --> 00:08:49,296 343 | вы, вероятно, пишете техническую документацию там, 344 | то же самое будет и для PEP. 345 | 346 | 70 347 | 00:08:49,316 --> 00:08:56,743 348 | Хорошо. Есть ли у вас личные цели как у члена 349 | Steering Council? Например, есть ли у вас какие-то 350 | 351 | 71 352 | 00:08:56,783 --> 00:09:04,089 353 | большие изменения, которые вы хотите достичь в технической 354 | части CPython или что-то в этом роде? О, да, 355 | 356 | 72 357 | 00:09:04,61 --> 00:09:11,338 358 | есть две вещи. Первая — это техническая 359 | цель, а вторая — нетехническая. 360 | 361 | 73 362 | 00:09:11,358 --> 00:09:16,806 363 | Говоря о технической части, как вы знаете, 364 | я очень заинтересован в работе над свободными потоками. Так что я 365 | 366 | 74 367 | 00:09:16,826 --> 00:09:28,464 368 | стараюсь поддержать успешное завершение проекта 369 | свободных потоков. И если что-то 370 | 371 | 75 372 | 00:09:28,824 --> 00:09:37,717 373 | нуждается в дополнительной поддержке, я постараюсь поддержать. И 374 | другая вещь — это проект Faster CPython. 375 | 376 | 76 377 | 00:09:37,777 --> 00:09:44,445 378 | Есть много экспериментов, включая JIT или 379 | интерпретатор Tier 2. Есть общие области для 380 | 381 | 77 382 | 00:09:44,766 --> 00:09:53,136 383 | свободных потоков и Faster CPython. 384 | И сотрудничество между ними очень, очень 385 | 386 | 78 387 | 00:09:53,176 --> 00:10:00,945 388 | важно. Так что я стараюсь поддерживать их тоже. Также в последнее время 389 | многие люди говорят о 390 | 391 | 79 392 | 00:10:01,426 --> 00:10:21,294 393 | ARM CPU, потому что, в отличие от x86, ARM CPU 394 | очень энергоэффективен, и это влияет 395 | 396 | 80 397 | 00:10:21,314 --> 00:10:30,568 398 | на цены в облаке, поэтому люди очень заинтересованы 399 | в использовании ARM чипов. Но нам нужно больше усилий 400 | 401 | 81 402 | 00:10:30,608 --> 00:10:41,004 403 | для более оптимизированного CPython на ARM. Так что я стараюсь 404 | поддерживать всех, кто работает над этим. Это мои основные 405 | 406 | 82 407 | 00:10:41,024 --> 00:10:49,077 408 | технические интересы. Во-вторых, как вы знаете, 409 | многие разработчики ядра находятся в Северной 410 | 411 | 83 412 | 00:10:49,117 --> 00:10:57,365 413 | Америке и в Европе, в основном в Западной Европе. В 414 | регионе APAC, например, в Азии, Токио, Корее, 415 | 416 | 84 417 | 00:10:57,405 --> 00:11:04,295 418 | Сингапуре или Китае, очень мало разработчиков ядра. 419 | Так что я стараюсь 420 | 421 | 85 422 | 00:10:57,405 --> 00:11:04,295 423 | Сингапур или Китай, здесь очень мало разработчиков ядра. 424 | Так что я стараюсь 425 | 426 | 86 427 | 00:11:04,415 --> 00:11:14,489 428 | представлять наши технологические компании, 429 | когда они работают над CPython, и стараюсь 430 | 431 | 87 432 | 00:11:15,049 --> 00:11:22,35 433 | представлять их потребности. А также я стараюсь организовывать 434 | локальные спринты, чтобы люди могли 435 | 436 | 88 437 | 00:11:22,43 --> 00:11:30,877 438 | участвовать, даже если в регионе APAC очень мало разработчиков ядра. 439 | Так что это две мои основные цели как члена 440 | 441 | 89 442 | 00:11:31,358 --> 00:11:39,231 443 | Steering Council в этом году. Да, благородные 444 | цели. Я думаю, что мы все должны поддерживать ваши усилия в 445 | 446 | 90 447 | 00:11:39,251 --> 00:11:47,832 448 | этой области, потому что я считаю, что свободные потоки — это большая 449 | функция, и она должна стать следующим этапом развития Python 450 | 451 | 91 452 | 00:11:47,872 --> 00:11:53,222 453 | и следующим большим шагом для самого языка. Да, действительно ценю это. У нас есть 454 | 455 | 92 456 | 00:11:53,262 --> 00:12:02,474 457 | еще один вопрос о вашей работе в Steering Council. Я думаю, что вы 458 | просматриваете много интересных PEP, и, возможно, вы можете назвать 459 | 460 | 93 461 | 00:12:02,514 --> 00:12:10,164 462 | несколько из них, самых интересных для вас или самых технически 463 | сложных, например, ваши топ-3 PEP, которые сейчас в работе. 464 | 465 | 94 466 | 00:12:11,265 --> 00:12:19,536 467 | Хорошо, я не могу выбрать три PEP в данный момент. Их очень много, 468 | но я могу выбрать 469 | 470 | 95 471 | 00:12:19,556 --> 00:12:27,509 472 | один. Один из лучших PEP для меня, возможно, в этом году, это 473 | PEP 765, написанный Ирит Катриэль. Он о 474 | 475 | 96 476 | 00:12:27,629 --> 00:12:39,387 477 | запрете return/break/continue в блоке finally. 478 | Этот PEP очень хорошо написан, 479 | 480 | 97 481 | 00:12:39,607 --> 00:12:47,271 482 | потому что он очень хорошо исследован. Например: 483 | сколько людей используют неправильный 484 | 485 | 98 486 | 00:12:47,291 --> 00:12:57,501 487 | код на Python. И затем он предлагает 488 | способ, как исправить код людей 489 | 490 | 99 491 | 00:12:57,561 --> 00:13:05,47 492 | естественным образом, ничего не ломая. Так что 493 | для меня это лучший PEP этого года, потому что он 494 | 495 | 100 496 | 00:13:05,51 --> 00:13:15,975 497 | очень убедителен, а также предоставляет статистику 498 | и предлагает способ писать 499 | 500 | 101 501 | 00:13:16,015 --> 00:13:25,437 502 | лучший код. Так что и технические, и нетехнические 503 | аспекты великолепны. Я многое узнал из этого PEP, так что 504 | 505 | 102 506 | 00:13:25,478 --> 00:13:34,727 507 | для меня это лучший PEP, который я читал до этого 508 | февраля. Возможно, после февраля у нас будет больше отличных PEP. 509 | 510 | 103 511 | 00:13:34,767 --> 00:13:43,59 512 | Но для меня, на данный момент, это лучший PEP. Я 513 | согласен. Это действительно отличный PEP. И я думаю, что 514 | 515 | 104 516 | 00:13:43,63 --> 00:13:50,985 517 | это была одна из самых проблемных частей синтаксиса Python. 518 | И я думаю, что много реального кода имело 519 | 520 | 105 521 | 00:13:51,045 --> 00:14:03,079 522 | эту ошибку. И здорово, что теперь у нас есть способы исправить это 523 | в более широком смысле. Хорошо, мы также хотим поговорить о вашей 524 | 525 | 106 526 | 00:14:03,099 --> 00:14:12,727 527 | работе над свободными потоками, потому что Steering Council — это 528 | что-то, к чему прикасаются очень немногие, но свободные потоки — 529 | 530 | 107 531 | 00:14:12,807 --> 00:14:22,015 532 | это что-то для всех. Не могли бы вы объяснить, что такое 533 | свободные потоки, очень кратко, для людей, 534 | 535 | 108 536 | 00:14:22,295 --> 00:14:30,882 537 | которые еще не знакомы с этим, потому что 3.13 вышел не так давно, 538 | и эта функция все еще отключена по умолчанию. 539 | 540 | 109 541 | 00:14:30,942 --> 00:14:40,05 542 | Да, я очень рад, что вы не используете термин "без GIL". 543 | 544 | 110 545 | 00:14:40,07 --> 00:14:48,4 546 | В основном, свободные потоки — это проект, который пытается 547 | убрать GIL. И, честно говоря, он находится на 548 | 549 | 111 550 | 00:14:48,821 --> 00:14:57,611 551 | экспериментальной стадии в CPython на данный момент. И 552 | мы используем официальный термин "свободные потоки" 553 | 554 | 112 555 | 00:14:57,771 --> 00:15:05,86 556 | вместо "без GIL". Так что если вы используете "без GIL", 557 | то вам стоит изменить термин. Было много 558 | 559 | 113 560 | 00:15:05,98 --> 00:15:14,499 561 | попыток убрать GIL с первых лет CPython. 562 | И многие пытались, и многие 563 | 564 | 114 565 | 00:15:14,579 --> 00:15:21,348 566 | потерпели неудачу. Но несколько лет назад, я не помню 567 | точно, в каком году, Сэм Гросс, который работает в 568 | 569 | 115 570 | 00:15:21,368 --> 00:15:30,16 571 | Facebook* (в России признана экстремистской и запрещена) AI Research, 572 | отправил письмо, что ему удалось убрать GIL. И я думаю, что 573 | 574 | 116 575 | 00:15:30,48 --> 00:15:37,93 576 | никто не поверил, что проект был успешным в тот момент. 577 | Несколько человек сказали: пожалуйста, покажите ваши 578 | 579 | 117 580 | 00:15:38,062 --> 00:15:45,714 581 | бенчмарки. И затем Сэм показал успешные 582 | бенчмарки из раннего релиза, и все были 583 | 584 | 118 585 | 00:15:45,794 --> 00:15:52,945 586 | удивлены. И вот мы здесь, два года спустя. 587 | Но нам все еще нужно время для анализа. 588 | 589 | 119 590 | 00:15:53,006 --> 00:15:59,998 591 | В свободных потоках много компонентов, 592 | таких как использование mimalloc и 593 | 594 | 120 595 | 00:16:00,158 --> 00:16:05,127 596 | нового подсчета ссылок. И это заняло больше 597 | двух лет, от Python 3.13 до этого момента. 598 | 599 | 121 600 | 00:16:05,168 --> 00:16:13,896 601 | Многие люди участвуют в проекте 602 | свободных потоков. И большинство из них 603 | 604 | 122 605 | 00:16:14,157 --> 00:16:22,358 606 | из Meta* (в России признана экстремистской и запрещена), 607 | потому что Meta* финансирует проект и до сих пор поддерживает его. 608 | 609 | 123 610 | 00:16:22,498 --> 00:16:28,774 611 | На раннем этапе мне пришлось настроить начальный CI 612 | с использованием GitHub Actions для сборки CPython с поддержкой свободных потоков. 613 | 614 | 124 615 | 00:16:30,003 --> 00:16:38,073 616 | Это очень техническая, но базовая вещь, потому что нам 617 | нужно убедиться, что CPython с поддержкой свободных потоков 618 | 619 | 125 620 | 00:16:38,233 --> 00:16:44,02 621 | работает хорошо. И затем, другая вещь, на которой я сосредоточился, — это 622 | сделать среду выполнения Python совместимой с проектом свободных потоков, потому что 623 | 624 | 126 625 | 00:16:44,04 --> 00:16:52,95 626 | одна из самых больших технических проблем, с которыми мы сталкиваемся 627 | в CPython с поддержкой свободных потоков, — это то, что мы не хотим 628 | 629 | 127 630 | 00:16:53,11 --> 00:16:59,919 631 | создавать много фрагментации между обычной 632 | сборкой и сборкой с поддержкой свободных потоков. Потому что, если 633 | 634 | 128 635 | 00:16:59,979 --> 00:17:07,511 636 | вы убираете GIL, все внезапно становится 637 | не потокобезопасным. Так что в среде выполнения Python нам нужно заботиться 638 | 639 | 129 640 | 00:17:07,912 --> 00:17:15,565 641 | о данных и потокобезопасности. Но, знаете, есть блокировки, критические секции 642 | и атомарные операции. Вы упомянули два очень важных 643 | 644 | 130 645 | 00:17:15,625 --> 00:17:24,48 646 | термина: атомарные операции и критические секции. Не могли бы вы объяснить, 647 | что это такое, для более широкой аудитории? 648 | 649 | 131 650 | 00:17:24,861 --> 00:17:32,038 651 | Хорошо, критические секции — это секции, которые 652 | гарантируют потокобезопасность 653 | 654 | 132 655 | 00:17:32,439 --> 00:17:40,138 656 | без использования явной блокировки. Упрощенно, 657 | только один поток может находиться в этой 658 | 659 | 133 660 | 00:17:40,237 --> 00:17:49,693 661 | секции, так что все будет потокобезопасно в этой 662 | секции по определению, но недостаток, очевидно, в стоимости. 663 | 664 | 134 665 | 00:17:49,713 --> 00:17:59,329 666 | Недостаток критических секций в том, что может 667 | произойти замедление производительности, потому что другие 668 | 669 | 135 670 | 00:17:59,369 --> 00:18:07,043 671 | потоки не могут находиться в этой секции и должны ждать. Но да, 672 | иногда нам нужна эта функция. А атомарные операции — это не 673 | 674 | 136 675 | 00:18:07,083 --> 00:18:13,949 676 | критические секции, они представляют собой низкоуровневые 677 | операции, которые могут быть выполнены атомарно. Так что даже если 678 | 679 | 137 680 | 00:18:13,989 --> 00:18:23,137 681 | несколько потоков пытаются изменить одно атомарное целое число, 682 | гарантируется, что не будет гонки, и оно будет изменено 683 | 684 | 138 685 | 00:18:23,197 --> 00:18:32,125 686 | по одному. Но это не гарантирует правильной 687 | транзакции внутри объектов Python. Так что 688 | 689 | 139 690 | 00:18:32,145 --> 00:18:40,032 691 | случаи использования могут быть разными между критическими 692 | секциями и атомарными операциями. Заметьте, что 693 | 694 | 140 695 | 00:18:40,534 --> 00:18:49,394 696 | все это происходит в кодовой базе на C. Так что если вы 697 | просто пользователь Python, вам не нужно об этом заботиться, но если 698 | 699 | 141 700 | 00:18:49,594 --> 00:18:56,945 701 | вы поддерживаете C-расширения, то, возможно, вам 702 | нужно об этом позаботиться. Да. Вам точно нужно 703 | 704 | 142 705 | 00:18:57,085 --> 00:19:01,821 706 | об этом заботиться, потому что в будущем вам точно 707 | понадобится поддержка свободных потоков. И в основном вы 708 | 709 | 143 710 | 00:19:01,921 --> 00:19:09,284 711 | можете сказать так: атомарные операции — это примитив, поддерживаемый 712 | компилятором. Критические секции — это наша собственная концепция, 713 | 714 | 144 715 | 00:19:09,344 --> 00:19:16,152 716 | которую CPython поддерживает и развивает как функцию. 717 | А что насчет C-расширений? Нужно ли авторам C-расширений 718 | 719 | 145 720 | 00:19:16,172 --> 00:19:23,86 721 | поддерживать свободные потоки в ближайшее время? Да, 722 | определенно. Возможно, некоторым из них не нужно 723 | 724 | 146 725 | 00:19:23,88 --> 00:19:31,148 726 | ничего менять, но я думаю, что, когда вы думаете о том, 727 | почему люди пишут C-расширения, это в основном 728 | 729 | 147 730 | 00:19:31,268 --> 00:19:38,296 731 | из-за проблем с производительностью. Так что, возможно, 732 | это просто чистый код на C, который не связан с объектами Python. 733 | 734 | 148 735 | 00:19:38,356 --> 00:19:47,066 736 | Так что в этом случае вам не нужно заботиться о Python API. 737 | Но если вы работаете с Python C-API, 738 | 739 | 149 740 | 00:19:47,086 --> 00:19:55,997 741 | то вам нужно заботиться о новых условиях гонки. 742 | Даже если вы используете C-API, который предоставляет заимствованные ссылки, 743 | 744 | 150 745 | 00:19:56,057 --> 00:20:05,795 746 | то это не гарантирует потокобезопасность. Так что вам нужно 747 | перейти на использование явного API подсчета ссылок. И если вы заботитесь об этом, 748 | 749 | 151 750 | 00:20:05,835 --> 00:20:13,209 751 | то, если вы поищете в документации, мы уже 752 | предоставили всю информацию об этом. Так что вы можете прочитать и 753 | 754 | 152 755 | 00:20:13,249 --> 00:20:22,559 756 | переключиться на это. И если вам нужно что-то еще, например, больше API, 757 | то вы можете просто создать issue в репозитории CPython, 758 | 759 | 153 760 | 00:20:22,599 --> 00:20:30,427 761 | и люди отреагируют на ваши потребности. Я думаю, что 762 | подсчет ссылок изменился довольно сильно в сборке 763 | 764 | 154 765 | 00:20:30,547 --> 00:20:36,393 766 | с поддержкой свободных потоков. Не могли бы вы уточнить, как и 767 | что изменилось в этом? Да, это очень техническая 768 | 769 | 155 770 | 00:20:36,413 --> 00:20:44,642 771 | тема. Я не уверен, что смогу объяснить это очень просто. 772 | Хорошо. По умолчанию, с GIL, 773 | 774 | 156 775 | 00:20:44,722 --> 00:20:52,951 776 | есть только один счетчик ссылок. Именно поэтому нам нужен был GIL 777 | до сборки с поддержкой свободных потоков, потому что с несколькими потоками, 778 | 779 | 157 780 | 00:20:53,052 --> 00:21:03,271 781 | если все они попытаются изменить счетчик ссылок, 782 | возникнет состояние гонки. Нам нужна блокировка. 783 | 784 | 158 785 | 00:21:03,331 --> 00:21:11,326 786 | В обычных сборках эта блокировка — это GIL в стандартной сборке. 787 | Но в сборке с поддержкой свободных потоков есть 788 | 789 | 159 790 | 00:21:11,366 --> 00:21:21,325 791 | два счетчика ссылок. Один — это общий счетчик ссылок, 792 | а другой — извините, я не могу вспомнить его название. 793 | 794 | 160 795 | 00:21:21,345 --> 00:21:30,323 796 | Но это счетчик ссылок для потока-владельца. Если поток владеет этим объектом, 797 | 798 | 161 799 | 00:21:30,443 --> 00:21:37,032 800 | он может изменять этот счетчик ссылок самостоятельно, 801 | без атомарных операций или блокировок. Так что это будет 802 | 803 | 162 804 | 00:21:37,072 --> 00:21:46,527 805 | очень быстро. А если другой поток разделяет тот же объект, 806 | он изменяет общий счетчик ссылок. 807 | 808 | 163 809 | 00:21:46,768 --> 00:21:57,685 810 | И он будет изменен с помощью атомарной операции, а затем 811 | будет объединен внутренним процессом. Так что это гарантирует 812 | 813 | 164 814 | 00:21:58,12 --> 00:22:08,839 815 | потокобезопасность общего значения счетчика ссылок. Основная гипотеза 816 | этого подхода заключается в том, что большинство объектов Python 817 | 818 | 165 819 | 00:22:08,879 --> 00:22:18,296 820 | очень быстро. И если другой поток использует тот же объект, 821 | они фактически изменяют общий счетчик ссылок. 822 | 823 | 166 824 | 00:22:18,616 --> 00:22:28,132 825 | И он будет изменен с помощью атомарной операции, а затем 826 | будет объединен внутренним процессом. Таким образом, это 827 | 828 | 167 829 | 00:22:28,192 --> 00:22:37,307 830 | гарантирует потокобезопасность общего 831 | значения счетчика ссылок. Основное предположение этого 832 | 833 | 168 834 | 00:22:37,844 --> 00:22:45,372 835 | подхода заключается в том, что большинство объектов Python 836 | фактически принадлежат одному потоку. В большинстве случаев мы 837 | 838 | 169 839 | 00:22:45,392 --> 00:22:54,101 840 | не заботимся об общем счетчике ссылок, но в некоторых 841 | случаях, когда они должны быть разделены с другим потоком, 842 | 843 | 170 844 | 00:22:54,241 --> 00:23:00,027 845 | тогда они изменяют общий счетчик ссылок, и 846 | это приведет к небольшому замедлению, но мы можем 847 | 848 | 171 849 | 00:23:00,127 --> 00:23:12,648 850 | преодолеть это. И если какой-то объект, например, CodeObject, 851 | может быть доступен 852 | 853 | 172 854 | 00:23:12,668 --> 00:23:19,081 855 | нескольким потокам. В этом случае мы фактически используем 856 | отложенный счетчик ссылок. И эта техника означает, что 857 | 858 | 173 859 | 00:23:21,005 --> 00:23:31,469 860 | мы откладываем подсчет ссылок до некоторого момента в будущем. Таким образом, 861 | мы видим, что мы успешно преодолели несколько проблем, 862 | 863 | 174 864 | 00:23:31,99 --> 00:23:38,558 865 | которые возникли, когда мы удалили GIL, как вы можете видеть, есть 866 | несколько техник для этого. Это то, что 867 | 868 | 175 869 | 00:23:38,678 --> 00:23:43,805 870 | произошло в проекте free-threading. Я не уверен, 871 | что это самое простое объяснение, но это моя лучшая 872 | 873 | 176 874 | 00:23:44,245 --> 00:23:51,254 875 | попытка. Да. Я думаю, ты отлично справился. Я действительно 876 | ценю твое объяснение. Спасибо. Я также думаю, 877 | 878 | 177 879 | 00:23:51,294 --> 00:23:57,944 880 | что мы должны упомянуть, как будет работать новый GC, потому что если 881 | мы затронули счетчики ссылок, я думаю, это справедливо 882 | 883 | 178 884 | 00:23:58,004 --> 00:24:04,553 885 | затронуть и GC. Можешь ли ты поделиться своими мыслями 886 | о будущем GC и работе, которая была проделана 887 | 888 | 179 889 | 00:24:04,614 --> 00:24:13,947 890 | над ним? Да, я не эксперт в GC, поэтому я не могу 891 | объяснить глубокие вещи в этом разговоре. Да, я 892 | 893 | 180 894 | 00:24:13,967 --> 00:24:21,699 895 | тоже. Я понятия не имею, как это работает внутри. Это слишком 896 | сложно. Да, но две вещи, возможно. Мы ввели 897 | 898 | 181 899 | 00:24:21,739 --> 00:24:29,193 900 | концепцию "Stop the World". Ее не было в стандартной сборке. 901 | Она будет включена в сборку free-threading. 902 | 903 | 182 904 | 00:24:29,254 --> 00:24:35,865 905 | И это тот же механизм, который используется, если вы используете Java или 906 | несколько других языков, потому что нам нужно остановить 907 | 908 | 183 909 | 00:24:35,925 --> 00:24:45,861 910 | все, и GC должен собрать все неиспользуемые 911 | объекты. Это действительно важно 912 | 913 | 184 914 | 00:24:46,583 --> 00:24:52,852 915 | для интерпретатора. Другая вещь, если я 916 | помню правильно, Марк Шеннон работает над 917 | 918 | 185 919 | 00:24:52,892 --> 00:25:00,719 920 | инкрементальным GC, это 921 | то же самое, как это обрабатывается инкрементально, так что 922 | 923 | 186 924 | 00:25:01,16 --> 00:25:07,832 925 | вы можете ожидать более быстрый GC, но на данный момент 926 | я не могу вспомнить прогресс 927 | 928 | 187 929 | 00:25:07,852 --> 00:25:13,803 930 | инкрементального GC, поэтому я думаю, вы можете открыть оригинальный 931 | issue, чтобы узнать больше. Потому что я не эксперт в 932 | 933 | 188 934 | 00:25:14,004 --> 00:25:23,238 935 | этой области. Я думаю, что у нас был очень интересный баг 936 | в 3.13, когда в последнем релиз-кандидате, когда новый 937 | 938 | 189 939 | 00:25:23,278 --> 00:25:30,508 940 | GC был объединен, и это замедлило многие случаи на 941 | несколько заметных процентов, скажем так. 942 | 943 | 190 944 | 00:25:31,149 --> 00:25:40,683 945 | И люди очень быстро создали новый релиз-кандидат 946 | и откатили изменения GC. И теперь мы 947 | 948 | 191 949 | 00:25:40,724 --> 00:25:49,481 950 | получим новый GC в 3.14. Я так думаю, по крайней мере, я надеюсь, 951 | потому что это действительно большая работа, и не многие 952 | 953 | 192 954 | 00:25:49,521 --> 00:25:58,372 955 | люди знают, насколько сложно на самом деле 956 | реализовать сборщик мусора для языка, такого как 957 | 958 | 193 959 | 00:25:58,472 --> 00:26:07,643 960 | Python, с учетом всех гарантий обратной совместимости. 961 | Так что ты сказал, что ты очень 962 | 963 | 194 964 | 00:26:07,723 --> 00:26:15,683 965 | заинтересован в поддержке ARM и free-threading. 966 | Есть ли у тебя какая-то конкретная работа или конкретные проблемы, 967 | 968 | 195 969 | 00:26:15,723 --> 00:26:24,856 970 | которые ты имеешь в виду, которые касаются обеих этих 971 | тем? Да, одна вещь, о которой я не говорил, когда 972 | 973 | 196 974 | 00:26:24,916 --> 00:26:32,427 975 | объяснял free-threading, как ты знаешь, 976 | Python 3.13 — это просто своего рода чистое доказательство концепции 977 | 978 | 197 979 | 00:26:32,707 --> 00:26:39,136 980 | версии free-threading. И я знаю, что люди 981 | на самом деле разочарованы проблемами производительности 982 | 983 | 198 984 | 00:26:39,217 --> 00:26:48,953 985 | в однопоточном режиме в сборке free-threading, она очень медленная. 986 | Потому что когда free-threading был введен, если я правильно 987 | 988 | 199 989 | 00:26:48,973 --> 00:26:57,37 990 | помню, он был основан на Python 3.9, и у него не было 991 | специализированного интерпретатора, который был написан 992 | 993 | 200 994 | 00:26:57,43 --> 00:27:07,997 995 | Марком Шенноном. Он очень великий человек. Поэтому, когда мы 996 | перенесли Python free-threading, мы не перенесли 997 | 998 | 201 999 | 00:27:08,858 --> 00:27:16,809 1000 | специализатор в Python 3.13. Так что это основная 1001 | причина, по которой однопоточная производительность 1002 | 1003 | 202 1004 | 00:27:16,909 --> 00:27:27,52 1005 | free-threading низкая. Но в 3.14, 1006 | Мэтт Пейдж, Кен Джин, Сэм Гросс, и я, и Томас 1007 | 1008 | 203 1009 | 00:27:27,56 --> 00:27:36,213 1010 | Вутерс, и многие другие люди присоединились. И мы 1011 | смогли перенести большинство случаев специализатора 1012 | 1013 | 204 1014 | 00:27:36,233 --> 00:27:45,105 1015 | в потокобезопасный режим с использованием механизма per-thread. 1016 | Так что мы фактически запустили бенчмарк несколько недель назад 1017 | 1018 | 205 1019 | 00:27:45,726 --> 00:27:57,047 1020 | между сборкой с GIL и free-threading. И теперь 1021 | она имеет 90% производительности сборки с GIL, так что это намного 1022 | 1023 | 206 1024 | 00:27:57,107 --> 00:28:05,295 1025 | быстрее. Так что если вы используете free-threading в 1026 | Python 3.14, вы не будете разочарованы однопоточной 1027 | 1028 | 207 1029 | 00:28:05,335 --> 00:28:11,22 1030 | производительностью. И еще более крутые вещи, 1031 | например, Кен Джин также представил tail call dispatch. 1032 | 1033 | 208 1034 | 00:28:11,26 --> 00:28:23,068 1035 | Он может быть использован, если ваш Python собран 1036 | с помощью clang 19. И мы заметили, что 1037 | 1038 | 209 1039 | 00:28:23,128 --> 00:28:32,872 1040 | сборка free-threading Python с Clang 19 и 1041 | tail call dispatch быстрее, чем сборка 3.13 с JIT. Так что 1042 | 1043 | 210 1044 | 00:28:33,973 --> 00:28:41,044 1045 | вы можете наслаждаться всем этим. Но если вы используете 1046 | технические спецификации с стандартной сборкой, она будет быстрее. 1047 | 1048 | 211 1049 | 00:28:41,064 --> 00:28:48,095 1050 | Я не уверен, как это объяснить, но 1051 | в 3.14 произойдет много магических вещей. 1052 | 1053 | 212 1054 | 00:28:48,175 --> 00:28:56,488 1055 | Так что вы можете наслаждаться этим. Это мое простое 1056 | объяснение. Было много попыток сделать 1057 | 1058 | 213 1059 | 00:28:56,975 --> 00:29:05,55 1060 | логику диспетчеризации байткода Python быстрее. 1061 | Первая техника, которую мы используем, — это "computed goto". 1062 | 1063 | 214 1064 | 00:29:05,57 --> 00:29:17,653 1065 | И я думаю, что это была лучшая попытка на протяжении многих 1066 | лет. Но начиная с Clang 19, вы можете дать подсказку компилятору, 1067 | 1068 | 215 1069 | 00:29:18,053 --> 00:29:28,044 1070 | чтобы он использовал tail call dispatch. Это тот же термин, что если вы запустите 1071 | алгоритм, между рекурсивным вызовом и 1072 | 1073 | 216 1074 | 00:29:28,164 --> 00:29:38,575 1075 | tail call, последний будет быстрее, потому что он 1076 | не требует дополнительного места в стеке и дополнительных накладных расходов, и 1077 | 1078 | 217 1079 | 00:29:38,735 --> 00:29:51,305 1080 | он также предоставляет своего рода оптимизацию регистров, 1081 | но его нужно модифицировать, чтобы он был более знаком с 1082 | 1083 | 218 1084 | 00:29:51,405 --> 00:30:03,578 1085 | логикой tail call dispatch. В данный момент Кен Джин фактически 1086 | переписывает генератор кода, чтобы он был более знаком с 1087 | 1088 | 219 1089 | 00:30:03,598 --> 00:30:13,376 1090 | оптимизацией tail call. Затем, если этот tail call 1091 | dispatch собран с помощью Clang 19, его производительность 1092 | 1093 | 220 1094 | 00:30:13,496 --> 00:30:23,814 1095 | увеличивается почти на 10%. Так что это очень 1096 | удивительный проект. Я думаю, вы можете ожидать его в ближайшее время. 1097 | 1098 | 221 1099 | 00:30:23,834 --> 00:30:31,285 1100 | Даже если вы не знаете технических деталей о том, 1101 | как работает tail call dispatch, 1102 | 1103 | 222 1104 | 00:30:31,305 --> 00:30:39,538 1105 | вы можете просто использовать `uv`. И если вы 1106 | используете `uv` для установки Python 3.14 1107 | 1108 | 223 1109 | 00:30:40,419 --> 00:30:49,232 1110 | Они уже собирают Python 3.14 с помощью 1111 | Clang 19. Так что вы можете просто использовать его. 1112 | 1113 | 224 1114 | 00:30:49,252 --> 00:30:58,623 1115 | Это потрясающая функция, я думаю. Да, это еще одна 1116 | оптимизация, даже лучше, чем computed GOTOs для 1117 | 1118 | 225 1119 | 00:30:58,683 --> 00:31:05,471 1120 | диспетчеризации байткода, и вы должны обязательно попробовать. 1121 | Я думаю, что она будет отключена по умолчанию для 1122 | 1123 | 226 1124 | 00:31:05,511 --> 00:31:16,638 1125 | этого релиза. Я ошибаюсь? Да, ты прав. Это мое 1126 | личное мнение об этом решении, но это 1127 | 1128 | 227 1129 | 00:31:16,699 --> 00:31:26,118 1130 | все еще на рассмотрении, хорошо? 1131 | Решение не окончательное. Я верю, что 1132 | 1133 | 228 1134 | 00:31:26,138 --> 00:31:35,142 1135 | техническая диспетчеризация не вызовет больших проблем, но 1136 | мы не можем гарантировать безопасность 1137 | 1138 | 229 1139 | 00:31:35,362 --> 00:31:42,194 1140 | на данный момент, потому что нам нужно знать, что реальные 1141 | люди используют это. Могут быть неожиданные баги. 1142 | 1143 | 230 1144 | 00:31:42,214 --> 00:31:50,965 1145 | Затем нам нужно будет их исправить. Так что, если мы не сможем включить это по умолчанию 1146 | в Python 3.14. Когда мы получим отзывы, это может 1147 | 1148 | 231 1149 | 00:31:50,985 --> 00:32:01,459 1150 | занять один или два года. Это может быть поздно. Так что люди будут 1151 | страдать, если будут баги. Поэтому правильный путь — это 1152 | 1153 | 232 1154 | 00:32:01,479 --> 00:32:09,089 1155 | оставить это отключенным, чтобы гарантировать более стабильное поведение. Но 1156 | как я сказал, `uv` уже предоставляет 1157 | 1158 | 233 1159 | 00:32:09,129 --> 00:32:15,898 1160 | tail call dispatch для Python 3.14. Вы можете 1161 | просто протестировать его и использовать. И если нет проблем, он 1162 | 1163 | 234 1164 | 00:32:15,918 --> 00:32:23,55 1165 | может быть включен по умолчанию в будущем. 1166 | Хорошо, я думаю, что ты затронул еще одну очень 1167 | 1168 | 235 1169 | 00:32:23,59 --> 00:32:31,742 1170 | интересную тему, которую я не указал в своих 1171 | предыдущих заметках для тебя. Но Relocatable Build — 1172 | 1173 | 236 1174 | 00:32:32,043 --> 00:32:37,571 1175 | это тоже очень интересный большой проект, над которым 1176 | сейчас работают многие люди. Можешь ли ты объяснить, 1177 | 1178 | 237 1179 | 00:32:37,651 --> 00:32:47,076 1180 | как это связано с Python и что происходит 1181 | в этой области? Да. Если ты используешь `uv`, 1182 | 1183 | 238 1184 | 00:32:47,096 --> 00:32:56,691 1185 | особенно часть с дистрибутивом CPython, 1186 | ты фактически используешь другой бинарный файл Python, который 1187 | 1188 | 239 1189 | 00:32:56,751 --> 00:33:07,569 1190 | основан на standalone сборке Python, это как 1191 | использование статической сборки, которая ориентирована на 1192 | 1193 | 240 1194 | 00:33:07,609 --> 00:33:14,721 1195 | совместимость с несколькими платформами с одной 1196 | сборкой. Так что это очень удивительный проект, потому что 1197 | 1198 | 241 1199 | 00:33:16,203 --> 00:33:29,95 1200 | некоторые люди, которые работают в закрытом интернете или без 1201 | интернета, могут использовать это как новый способ 1202 | 1203 | 242 1204 | 00:33:30,25 --> 00:33:38,85 1205 | развертывания нескольких дистрибутивов Python. Это очень 1206 | удивительный проект. Если ты используешь `uv python install`, ты 1207 | 1208 | 243 1209 | 00:33:39,492 --> 00:33:52,758 1210 | используешь концепцию relocatable build. Люди из 1211 | Astral сейчас тесно сотрудничают с разработчиками CPython, чтобы сделать 1212 | 1213 | 244 1214 | 00:33:53,099 --> 00:34:01,13 1215 | relocatable builds проще, быстрее и менее подверженными ошибкам, 1216 | потому что есть некоторые баги. Я думаю, что многие 1217 | 1218 | 245 1219 | 00:34:01,35 --> 00:34:09,401 1220 | проблемы с relocatable builds связаны с 1221 | нашей оптимизацией BOLT. Я видел, может быть, пять тикетов 1222 | 1223 | 246 1224 | 00:34:09,441 --> 00:34:17,215 1225 | об этом, что-то вроде того. Да. Нам нужно 1226 | разделить эти две темы с этим вопросом, 1227 | 1228 | 247 1229 | 00:34:17,235 --> 00:34:24,765 1230 | потому что они собирают Python 1231 | используя статическую сборку, без динамической линковки. 1232 | 1233 | 248 1234 | 00:34:24,865 --> 00:34:34,737 1235 | Можно ожидать, что итоговый бинарный файл будет огромным, 1236 | намного больше, чем обычный бинарный файл Python. 1237 | 1238 | 249 1239 | 00:34:34,797 --> 00:34:42,754 1240 | Итак, BOLT — это инструмент оптимизации, разработанный Meta* 1241 | (в России признана экстремистской и запрещена) 1242 | 1243 | 250 1244 | 00:34:43,417 --> 00:34:50,526 1245 | и есть несколько техник оптимизации компилятора, 1246 | базовые вещи могут быть, если вы передадите 1247 | 1248 | 251 1249 | 00:34:50,706 --> 00:35:01,062 1250 | опцию `-01`, `-02`, `-03` в GCC, компилятор 1251 | оптимизирует ваш код в соответствии с их политикой. И это одна 1252 | 1253 | 252 1254 | 00:35:01,102 --> 00:35:13,188 1255 | часть процесса оптимизации. Другая часть — 1256 | это PGO, который фактически собирает 1257 | 1258 | 253 1259 | 00:35:13,208 --> 00:35:22,841 1260 | профилирование во время выполнения и затем пересобирает 1261 | бинарный файл с помощью компилятора. Это мы называем обычным процессом 1262 | 1263 | 254 1264 | 00:35:22,901 --> 00:35:32,914 1265 | оптимизации компилятора. Но другая вещь — это то, что мы называем 1266 | пост-бинарной оптимизацией. Поскольку бинарный файл огромный, 1267 | 1268 | 255 1269 | 00:35:34,557 --> 00:35:42,195 1270 | там много ошибок и промахов кэша. 1271 | И одна из техник, которые они используют, 1272 | 1273 | 256 1274 | 00:35:42,296 --> 00:35:50,19 1275 | похожа на PGO. Они фактически собирают 1276 | профили двумя способами. Один из них — 1277 | 1278 | 257 1279 | 00:35:50,23 --> 00:35:55,499 1280 | инструментация, а другой способ — это 1281 | живое профилирование, например, в рабочем трафике. 1282 | 1283 | 258 1284 | 00:35:56,02 --> 00:36:06,659 1285 | Затем они перераспределяют структуру бинарного файла, 1286 | чтобы он был более оптимизирован для кэша, 1287 | 1288 | 259 1289 | 00:36:06,679 --> 00:36:14,061 1290 | дополнительного кэша. Например, если какая-то область кода 1291 | используется очень часто, она группируется. А если 1292 | 1293 | 260 1294 | 00:36:14,181 --> 00:36:24,316 1295 | это область, которая выполняется реже, она отделяется от 1296 | основной области. И тогда можно ожидать, что промахи кэша 1297 | 1298 | 261 1299 | 00:36:24,817 --> 00:36:31,727 1300 | уменьшатся. Затем они также устраняют ненужные 1301 | области бинарного файла. Итоговый размер бинарного файла может быть уменьшен. Поэтому 1302 | 1303 | 262 1304 | 00:36:31,787 --> 00:36:37,516 1305 | они работают над BOLT, потому что они являются 1306 | основным заказчиком, использующим BOLT. Мы добавили 1307 | 1308 | 263 1309 | 00:36:37,977 --> 00:36:45,374 1310 | поддержку BOLT в, возможно, 3.13 для CPython. Я не помню 1311 | точно, поэтому они фактически 1312 | 1313 | 264 1314 | 00:36:45,434 --> 00:36:54,747 1315 | работают над этим. Я думаю, что BOLT был введен в 1316 | Python 3.12. Да, 3.12, точно. Что-то вроде того. И 1317 | 1318 | 265 1319 | 00:36:54,847 --> 00:37:04,018 1320 | я думаю, что ты был тем, кто внес вклад в это. Так что 1321 | это еще один большой проект от тебя. Давай отдадим 1322 | 1323 | 266 1324 | 00:37:04,038 --> 00:37:16,372 1325 | должное. Но я должен сказать, что BOLT был фактически 1326 | первой попыткой от людей, работающих над Pyston. 1327 | 1328 | 267 1329 | 00:37:16,392 --> 00:37:25,31 1330 | Люди, которые работали в Dropbox, а затем разработали 1331 | версию Python под названием Pyston в Dropbox. 1332 | 1333 | 268 1334 | 00:37:25,571 --> 00:37:34,423 1335 | После того, как они покинули Dropbox, они организовали 1336 | проект Faster CPython. 1337 | 1338 | 269 1339 | 00:37:35,084 --> 00:37:41,593 1340 | В Pyston одной из оптимизаций, 1341 | которую они использовали, был BOLT. Мы фактически 1342 | 1343 | 270 1344 | 00:37:41,653 --> 00:37:52,251 1345 | переняли их технику. Я хочу сказать, что основная 1346 | работа была проделана этими людьми, а моя работа заключалась в 1347 | 1348 | 271 1349 | 00:37:52,451 --> 00:37:58,346 1350 | поддержке внедрения BOLT, например, 1351 | в определении частей, где мы можем его использовать. Так что я благодарю тебя за 1352 | 1353 | 272 1354 | 00:37:58,447 --> 00:38:07,973 1355 | признание, но мне нужно уточнить это. И также отдать должное другим 1356 | людям. Да. Хорошо, у меня есть 1357 | 1358 | 273 1359 | 00:38:08,514 --> 00:38:16,865 1360 | последний технический вопрос, но он также очень глубокий, 1361 | так что давайте подготовим нашу аудиторию к нему. Я думаю, что 1362 | 1363 | 274 1364 | 00:38:17,546 --> 00:38:26,698 1365 | в Python 3.14 произойдут большие изменения в нашем JIT 1366 | пайплайне, потому что сейчас нам требуется LLVM как зависимость 1367 | 1368 | 275 1369 | 00:38:26,738 --> 00:38:34,348 1370 | во время сборки. И предлагается устранить эту 1371 | зависимость во время сборки. Есть ли у тебя 1372 | 1373 | 276 1374 | 00:38:34,388 --> 00:38:42,818 1375 | какая-то информация об этом? Например, что произойдет 1376 | и как это будет работать? Да, есть попытка 1377 | 1378 | 277 1379 | 00:38:42,878 --> 00:38:50,327 1380 | убрать зависимость от LLVM во время сборки 1381 | CPython, но также есть PEP по этому поводу, 1382 | 1383 | 278 1384 | 00:38:50,367 --> 00:38:58,237 1385 | и Steering Council сейчас рассматривает этот PEP. 1386 | Так что на данный момент я не могу ничего сказать о PEP. 1387 | 1388 | 279 1389 | 00:38:58,258 --> 00:39:05,868 1390 | Мне было бы сложно на данный момент. 1391 | Хорошо, да, я полностью понимаю. 1392 | 1393 | 280 1394 | 00:39:05,888 --> 00:39:14,119 1395 | Я думаю, что мы должны добавить ссылку на этот PEP в 1396 | описание, чтобы люди могли прочитать его и выразить свое 1397 | 1398 | 281 1399 | 00:39:14,159 --> 00:39:22,869 1400 | мнение в обсуждении, в discourse, 1401 | если у них есть такие мнения. Это мое личное 1402 | 1403 | 282 1404 | 00:39:22,949 --> 00:39:31,381 1405 | мнение, но если мы успешно завершим этот проект, 1406 | эти задачи сборки больше не понадобятся. 1407 | 1408 | 283 1409 | 00:39:31,401 --> 00:39:40,293 1410 | Так что да, это будет очень важный PEP 1411 | для проекта. Но окончательное решение будет 1412 | 1413 | 284 1414 | 00:39:40,313 --> 00:39:46,922 1415 | принято Steering Council. Так что я не могу ничего сказать. 1416 | Хорошо. Хорошо. У меня нет мнения 1417 | 1418 | 285 1419 | 00:39:47,102 --> 00:39:54,767 1420 | по этому поводу, потому что это выходит за пределы моей экспертной области. 1421 | Последний вопрос о твоей другой 1422 | 1423 | 286 1424 | 00:39:54,787 --> 00:40:03,401 1425 | деятельности. Ты сказал, что также организуешь спринты в 1426 | своем родном городе и приглашаешь людей присоединиться и 1427 | 1428 | 287 1429 | 00:40:03,481 --> 00:40:09,771 1430 | участвовать. Можешь ли ты рассказать немного больше 1431 | о том, что это за спринты, какие результаты 1432 | 1433 | 288 1434 | 00:40:09,931 --> 00:40:17,062 1435 | и как ты их организуешь? Что должны делать люди 1436 | там? Да, в каждом регионе может быть много 1437 | 1438 | 289 1439 | 00:40:17,202 --> 00:40:25,794 1440 | локальных спринтов для разработки CPython, но в Корее, 1441 | Японии или Таиланде, возможно, в России, я знаю, что 1442 | 1443 | 290 1444 | 00:40:25,954 --> 00:40:34,406 1445 | нет спринтов, организованных основными 1446 | разработчиками. Так что для некоторых людей может быть 1447 | 1448 | 291 1449 | 00:40:34,866 --> 00:40:43,724 1450 | сложно участвовать в US PyCon из-за 1451 | финансовых проблем, расстояния, 1452 | 1453 | 292 1454 | 00:40:43,844 --> 00:40:56,221 1455 | или занятости. Поэтому я стараюсь 1456 | организовать спринт, где можно работать над CPython 1457 | 1458 | 293 1459 | 00:40:56,261 --> 00:41:04,85 1460 | в течение одного дня в Корее. Я стараюсь предоставить помощь и 1461 | руководство о том, как можно внести вклад в 1462 | 1463 | 294 1464 | 00:41:04,89 --> 00:41:12,198 1465 | CPython, как запустить CI, как выполнять новые задачи, 1466 | и как писать новый код, и как получить 1467 | 1468 | 295 1469 | 00:41:12,298 --> 00:41:24,201 1470 | рецензию от команды CPython. Это одна из моих 1471 | попыток организовать спринт в моем регионе. 1472 | 1473 | 296 1474 | 00:41:24,221 --> 00:41:31,634 1475 | Потому что я думаю, что такие активности — 1476 | это один из способов, с помощью которых люди могут улучшить 1477 | 1478 | 297 1479 | 00:41:31,694 --> 00:41:38,126 1480 | рейтинг сообщества в CPython. Люди 1481 | представляют свою позицию и свои потребности, и 1482 | 1483 | 298 1484 | 00:41:38,266 --> 00:41:44,296 1485 | если они принимают участие в решении проблем, они могут 1486 | стать более знакомыми с процессом. Поэтому я верю, что такие активности могут 1487 | 1488 | 299 1489 | 00:41:44,357 --> 00:41:54,063 1490 | увеличить взаимодействие между основной командой Python 1491 | и другими людьми. 1492 | 1493 | 300 1494 | 00:41:54,103 --> 00:42:02,082 1495 | Спасибо. Это действительно замечательная активность, 1496 | и я надеюсь однажды 1497 | 1498 | 301 1499 | 00:42:02,162 --> 00:42:07,871 1500 | поучаствовать в таких мероприятиях или даже организовать 1501 | их, потому что я полностью согласен. Дать людям понять, 1502 | 1503 | 302 1504 | 00:42:07,911 --> 00:42:18,006 1505 | что вносить вклад в CPython легко и весело, — это большая 1506 | цель, потому что многие считают, что это тяжелая 1507 | 1508 | 303 1509 | 00:42:18,567 --> 00:42:28,564 1510 | работа, которая не приносит удовольствия, но это тяжелая работа, которая приносит удовольствие. 1511 | И я думаю, что многие должны знать, что вы можете 1512 | 1513 | 304 1514 | 00:42:28,604 --> 00:42:35,617 1515 | это делать, и вы должны это делать. И я стараюсь поощрять людей 1516 | с помощью своих видео вносить вклад в CPython, 1517 | 1518 | 305 1519 | 00:42:35,697 --> 00:42:44,83 1520 | сообщать о проблемах с неожиданным поведением 1521 | и тому подобное. Так что в этом году, 1522 | 1523 | 306 1524 | 00:42:44,87 --> 00:42:51,478 1525 | в моем расписании — Южная Корея, 1526 | я стараюсь организовать это в августе. Так что если вы посетите 1527 | 1528 | 307 1529 | 00:42:51,538 --> 00:43:02,43 1530 | Корею, возможно, PyKR пройдет 15 августа. Так что вы 1531 | можете присоединиться к спринту, если посетите Корею. Я также планирую 1532 | 1533 | 308 1534 | 00:43:02,49 --> 00:43:11,947 1535 | посетить Тайвань в этом году. Так что если у вас есть планы 1536 | посетить Тайвань, возможно, вы также сможете посетить спринт. 1537 | 1538 | 309 1539 | 00:43:12,067 --> 00:43:20,362 1540 | И если будут другие возможности, я постараюсь их поддержать. 1541 | И я думаю, что вы тоже можете организовать спринт. Так что если вам нужны 1542 | 1543 | 310 1544 | 00:43:20,602 --> 00:43:31,702 1545 | ресурсы для локального спринта, я с радостью 1546 | предоставлю то, что использую для локальных спринтов в Токио или 1547 | 1548 | 311 1549 | 00:43:31,722 --> 00:43:41,471 1550 | Сеуле или любом другом регионе. Отлично. Спасибо. И еще раз, 1551 | большое уважение за вашу работу над CPython и 1552 | 1553 | 312 1554 | 00:43:41,592 --> 00:43:48,446 1555 | вашу работу в Steering Council. Мы действительно должны 1556 | ценить таких людей, как вы, и отдавать должное за всю 1557 | 1558 | 313 1559 | 00:43:48,486 --> 00:43:55,26 1560 | тяжелую работу, которую они делают для всего мира. 1561 | Еще раз спасибо, и спасибо за то, что пришли и дали это 1562 | 1563 | 314 1564 | 00:43:55,341 --> 00:44:02,615 1565 | интервью. Я надеюсь, что людям понравится. И если вы 1566 | оставите свои контакты, ваш GitHub, например, 1567 | 1568 | 315 1569 | 00:44:02,675 --> 00:44:11,604 1570 | и у людей будут вопросы о free-threading, 1571 | могут ли они упомянуть вас? Да, я предоставлю 1572 | 1573 | 316 1574 | 00:44:11,644 --> 00:44:21,816 1575 | мой GitHub username. Мой handle — это очень 1576 | странное имя. Это @corona10. Оно не связано с той 1577 | 1578 | 317 1579 | 00:44:21,836 --> 00:44:32,828 1580 | Короной. Да, но я использую его с 2019 года, так что 1581 | мне все равно. Так что мой handle на GitHub — @corona10, 1582 | 1583 | 318 1584 | 00:44:32,948 --> 00:44:45,708 1585 | а мой Twitter — @dongheena92, 92 — это год моего рождения, так что 1586 | вы можете связаться со мной, если хотите. И моя почта — 1587 | 1588 | 319 1589 | 00:44:45,969 --> 00:44:51,796 1590 | donghee.na@python.org. Я добавлю все в 1591 | описание, чтобы люди могли с вами связаться. 1592 | 1593 | 320 1594 | 00:44:51,836 --> 00:44:57,163 1595 | Вы можете просто написать мне на почту, и я с радостью 1596 | отвечу, если у вас есть интерес к 1597 | 1598 | 321 1599 | 00:44:57,303 --> 00:45:05,691 1600 | внесению вклада в CPython. Я знаю, что хочу сказать Никите, 1601 | ты тоже отличный основной 1602 | 1603 | 322 1604 | 00:45:05,712 --> 00:45:12,579 1605 | разработчик, который взаимодействует с внешними 1606 | контрибьюторами. Так что я хочу также сказать спасибо за все твои 1607 | 1608 | 323 1609 | 00:45:12,98 --> 00:45:19,568 1610 | активности и работу над CPython. Да. Я очень уважаю 1611 | твои активности, включая триажирование 1612 | 1613 | 324 1614 | 00:45:19,688 --> 00:45:26,496 1615 | проблем, исправление всего. Да. Я очень уважаю 1616 | твои активности тоже. Да, спасибо. Спасибо. 1617 | 1618 | 325 1619 | 00:45:26,656 --> 00:45:33,163 1620 | Спасибо. Пока-пока. И это все на данный момент. Я надеюсь, что это было 1621 | интересно, потому что во время интервью это было 1622 | 1623 | 326 1624 | 00:45:33,243 --> 00:45:39,52 1625 | действительно очень интересно лично для меня. Я узнал много нового, 1626 | я поговорил с удивительным умным человеком, и это 1627 | 1628 | 327 1629 | 00:45:39,54 --> 00:45:47,065 1630 | всегда очень приятно. И я надеюсь, что теперь вы также знаете, 1631 | что вы можете управлять таким языком программирования, как Python. 1632 | 1633 | 328 1634 | 00:45:47,426 --> 00:45:53,357 1635 | Это реалистичная цель для инженеров, которые 1636 | интересуются этим. И я надеюсь, что, возможно, хотя бы один 1637 | 1638 | 329 1639 | 00:45:53,377 --> 00:45:58,867 1640 | из вас я смог мотивировать развивать свои навыки в этом 1641 | направлении. Я буду рад помочь любым способом, если кто-то 1642 | 1643 | 330 1644 | 00:45:58,887 --> 00:46:05,398 1645 | захочет. И у меня есть три замечательных ссылки, как обычно. 1646 | Первая ссылка — это мой GitHub. Вы можете поддержать мою работу 1647 | 1648 | 331 1649 | 00:46:05,418 --> 00:46:11,688 1650 | там, поставив звезды или сделав форки. Вы можете 1651 | поддержать мою работу на Boosty, если хотите поддержать 1652 | 1653 | 332 1654 | 00:46:11,868 --> 00:46:18,679 1655 | рублями, это всегда приятно. Я не предлагаю уникального 1656 | контента, я считаю, что весь контент должен быть бесплатным и 1657 | 1658 | 333 1659 | 00:46:19,02 --> 00:46:24,348 1660 | открытым для всех, так что это просто дополнительная 1661 | мотивация для меня. И, конечно, мой Telegram 1662 | 1663 | 334 1664 | 00:46:24,368 --> 00:46:32,344 1665 | канал. Мой Telegram канал — это место, где много 1666 | технической информации о Python. Так что если вам 1667 | 1668 | 335 1669 | 00:46:32,364 --> 00:46:38,116 1670 | нравится такой контент, присоединяйтесь. Например, 1671 | недавно я написал серию из двух постов о том, как работает 1672 | 1673 | 336 1674 | 00:46:38,197 --> 00:46:44,569 1675 | GIL в Python. И, конечно, я показал код на 1676 | C, который физически показывает внутренности Python 1677 | 1678 | 337 1679 | 00:46:44,589 --> 00:46:50,798 1680 | и операционной системы, чтобы показать, как происходит 1681 | переключение GIL. Так что если вам интересен 1682 | 1683 | 338 1684 | 00:46:50,818 --> 00:46:56,627 1685 | текстовый контент о внутренностях Python, присоединяйтесь. 1686 | Ну, а если вы хотите увидеть кого-то конкретного в качестве 1687 | 1688 | 339 1689 | 00:46:56,647 --> 00:47:01,514 1690 | гостя, вы можете написать в комментариях, кого бы вы хотели 1691 | увидеть, и я постараюсь пригласить этого человека и поговорить с 1692 | 1693 | 340 1694 | 00:47:01,534 --> 00:47:05,5 1695 | ним о том, чем он занимается. Это все от меня, большое спасибо, 1696 | пока. 1697 | -------------------------------------------------------------------------------- /editing/captions/7/en.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:33,189 --> 00:00:46,173 3 | Welcome to my channel, Alex. Can you please introduce yourself? It's great to be here. Yeah, I'm Alex. 4 | My day job currently is working at Astral, where I work on the linter ruff. And in my spare 5 | 6 | 2 7 | 00:00:46,193 --> 00:01:00,557 8 | time, I do a lot of open source stuff in the Python community. So I'm a CPython core dev. I'm a 9 | typeshed maintainer. I also maintain the typing focused linter flake8-pyi, and I make triage 10 | 11 | 3 12 | 00:01:00,577 --> 00:01:16,939 13 | with MyPy. And I maintain typing_extensions as well. Oh, very, very good list. I'm happy that 14 | you accepted this invitation and I'm going to ask you about some deep typeshed stuff. And I 15 | 16 | 4 17 | 00:01:17,539 --> 00:01:29,543 18 | really want to know, are there any things that we can really improve in the typeshed testing? 19 | Because right now there are a lot of checks, a lot of CI jobs. We check mostly everything that we 20 | 21 | 5 22 | 00:01:29,583 --> 00:01:44,842 23 | can. What can we do better? What's your opinion? That's a really interesting question. I think, 24 | yeah, we already have a lot of tests that make sure that the annotations that we do have are good 25 | 26 | 6 27 | 00:01:45,083 --> 00:01:56,651 28 | and that the stubs that we have are consistent with the runtime. I think probably the thing I 29 | would want to improve on is better stub generation. so that it's easier for people to just add 30 | 31 | 7 32 | 00:01:56,711 --> 00:02:10,032 33 | baseline stubs, which have a decent quality, and they don't have to work really hard to get that. 34 | We have stub generation scripts, and they will produce very basic stubs, but those stubs aren't 35 | 36 | 8 37 | 00:02:10,036 --> 00:02:18,405 38 | really worth much. There are easy ways that we can make them better, and we've got some 39 | contributors at MyPy that are working on stubgen quite a lot at the moment, which is great to see, 40 | 41 | 9 42 | 00:02:19,326 --> 00:02:31,074 43 | but there's still so much more that we can do there, I think. So that's where I would probably 44 | focus efforts right now. I also think that we don't have any side jobs on non-Linux, non-MacOS, 45 | 46 | 10 47 | 00:02:31,154 --> 00:02:45,975 48 | or non-Windows. We only have three operating systems here. And I think it might be a very good 49 | idea to run something like Solitis or something like that. Yeah. Yeah, it's interesting. I 50 | 51 | 11 52 | 00:02:46,035 --> 00:02:58,881 53 | don't know that we've had many people complain about the quality of type checking on Solaris, 54 | for example. But if that's a, so I don't know how much of a problem that is. But if it is a problem, 55 | 56 | 12 57 | 00:02:58,901 --> 00:03:10,786 58 | then I would definitely, definitely be in favor of that. Yeah, I'd be interested in talking to 59 | Solaris folks and seeing what their Yeah, I think that not a lot of people use Solaris, so we don't 60 | 61 | 13 62 | 00:03:10,867 --> 00:03:22,653 63 | have a lot of complaints there, because you have to not only use Solaris and CPython type check, 64 | and you also have to use some specific APIs for that, so you can see the actual problems. But yeah, 65 | 66 | 14 67 | 00:03:23,634 --> 00:03:38,168 68 | that's my point that I really want to see improved from time to time. Okay, I think that this 69 | question is not really related to typeshed, but I cannot simply skip it because I think it will be 70 | 71 | 15 72 | 00:03:38,208 --> 00:03:50,517 73 | very interesting for my audience and for me as well. How do you find Rust and its type system 74 | compared to CPython? I've been enjoying it a lot. The last few days I've been refactoring a lot of 75 | 76 | 16 77 | 00:03:50,537 --> 00:04:03,911 78 | tests, and it is a pain that you have to make every test compile before you can run a single one. 79 | That part I'm not enjoying so much. I think the thing that I studied learning Rust relatively 80 | 81 | 17 82 | 00:04:03,951 --> 00:04:14,659 83 | recently in December, and the thing that surprised me most was that I was expecting it to be 84 | stricter than Python's type system in every way. And in reality, that wasn't the case. There's 85 | 86 | 18 87 | 00:04:14,779 --> 00:04:28,031 88 | some things that you can do in Rust that you can't do in Python. For example, it's much easier to 89 | redefine a symbol to a different type later in the same function in Rust than it is in Python. Mypy 90 | 91 | 19 92 | 00:04:28,033 --> 00:04:42,122 93 | typically won't let you do that. Pirate will never let you do that. So that took me by surprise. 94 | And the reason for that is that Rust scoping rules are such that it's possible to do that safely in 95 | 96 | 20 97 | 00:04:42,162 --> 00:04:59,671 98 | Rust, whereas you couldn't do that safely in Python. But yeah, no, I'm loving writing Rust. It's 99 | very refreshing. I think it's very refreshing. Because when you write in Rust, you compose 100 | 101 | 21 102 | 00:04:59,731 --> 00:05:10,373 103 | programs, you don't just write them. You have to think everything through. You have to think 104 | about memory management, you have to think about exceptions. I mean, the lack of exceptions. 105 | 106 | 22 107 | 00:05:11,835 --> 00:05:21,446 108 | It's very interesting. Yeah, I understand that. Okay. So if we're talking about type systems 109 | and their difference in different languages, what do you think about what are the biggest 110 | 111 | 23 112 | 00:05:21,486 --> 00:05:33,006 113 | challenges for Python type system right now? I think we're at an interesting point in the type 114 | systems development. Over the last, you know, since PEP 484, which was the PEP that introduced 115 | 116 | 24 117 | 00:05:33,062 --> 00:05:45,449 118 | the type system, was introduced, we've had a lot of new features introduced in pretty much every 119 | Python release. So it's been a period of really rapid evolution. And right now, over the past 120 | 121 | 25 122 | 00:05:45,529 --> 00:05:56,792 123 | year, we've seen the creation of the Typing Council and the creation of the first version of the 124 | Typing Swag. And I think... Can you please elaborate a little more on that? Because I'm pretty 125 | 126 | 26 127 | 00:05:56,832 --> 00:06:11,586 128 | sure that a lot of people are not familiar with that. Thanks, yeah. So the Typing Council is a new 129 | body that's been set up, which has several type checker authors represented in it, and several 130 | 131 | 27 132 | 00:06:11,606 --> 00:06:24,851 133 | other people who have been heavily involved in the typing system for the last few years. They 134 | serve as an advisory body to the Steering Council, essentially, where the Steering Council 135 | 136 | 28 137 | 00:06:25,331 --> 00:06:34,515 138 | delegates many decisions on PEPs to them. I think delegate might not be quite the right word 139 | because the Steering Council does have the final say, but it heavily takes their advice on 140 | 141 | 29 142 | 00:06:34,555 --> 00:06:44,038 143 | board. So there has been a new specification for the typing system written up. So that's an 144 | attempt to formally describe how all of the rules that have been created through the various 145 | 146 | 30 147 | 00:06:44,078 --> 00:06:57,411 148 | Python Enhancement Proposals over the last few years, how they all fit together, how they 149 | should work in tandem. And any small minor changes to the typing spec can be automatically 150 | 151 | 31 152 | 00:06:57,451 --> 00:07:07,885 153 | approved by the Typing Council without having to have a new PEP being written. So that's the 154 | other role that the Typing Council has, other than giving their feedback on PEPs. I think the 155 | 156 | 32 157 | 00:07:07,965 --> 00:07:18,452 158 | overall mood in the typing community. So my sense is that at the moment, I can't speak for 159 | everybody in the typing community, but my sense is that the overall mood right now is that we want 160 | 161 | 33 162 | 00:07:18,512 --> 00:07:30,819 163 | to slow down with features a little bit and more formally figure out exactly how they should, how 164 | the existing features that we have should work together and interoperate a bit more. Now, I 165 | 166 | 34 167 | 00:07:30,839 --> 00:07:44,237 168 | think that typing console is doing a great job because the amount of information they have to 169 | collect and to approve with different type checkers and to standardize is just... Very huge. 170 | 171 | 35 172 | 00:07:44,897 --> 00:07:57,301 173 | And I also want to highlight that they don't just create a specification for that. They also 174 | create a compliance suite for all the type checkers. So all the type checkers can have a baseline 175 | 176 | 36 177 | 00:07:57,742 --> 00:08:08,426 178 | of features that should be supported and should be treated the same way. I think that it was a 179 | long-awaited addition to the Python governance team. So very appreciate their work. I 180 | 181 | 37 182 | 00:08:08,446 --> 00:08:19,631 183 | completely agree. Can you please share a bit of maybe a personal history? How did you start 184 | contributing to typeshed? So it might be a good example for others who just want to start 185 | 186 | 38 187 | 00:08:19,651 --> 00:08:31,024 188 | contributing or just for someone who is not aware that they can contribute to typeshed right 189 | now. To go back a bit further, I originally started learning about Python typing because I was 190 | 191 | 39 192 | 00:08:31,046 --> 00:08:46,154 193 | fairly new to Python, really, and I was using PyCharm. PyCharm's type checker was on by default, 194 | so I kept on writing code and I kept on up with these weird, annoying errors about how I said that 195 | 196 | 40 197 | 00:08:46,655 --> 00:08:56,344 198 | this was a list and now it's a dict and PyCharm was getting very angry at me. So I read up on loads of 199 | tutorials and I guess when I learn about something, I like to learn about it properly. So I 200 | 201 | 41 202 | 00:08:56,384 --> 00:09:07,653 203 | learned quite a lot about the Python typing system as a result of that, and then quickly found out 204 | Answering questions on Python typing was a really good way to get lots of points on Stack 205 | 206 | 42 207 | 00:09:07,693 --> 00:09:20,301 208 | Overflow because there were loads of questions on Stack Overflow about Python typing. So 209 | carried on building up my Python typing expertise because of that. And then eventually I was 210 | 211 | 43 212 | 00:09:20,321 --> 00:09:34,991 213 | just reading through the type shed subs for built-ins one day and noticed that a bunch of 214 | parameters weren't marked as positional-only in the stubs when they were. Oh yeah. Yeah. By the 215 | 216 | 44 217 | 00:09:35,031 --> 00:09:48,576 218 | way, did we fix all the param positional-only problems? All that can be detected automatically 219 | using stochastic. Yeah. So I filed a PR, like making some parameters and some methods on 220 | 221 | 45 222 | 00:09:48,596 --> 00:10:00,094 223 | built-in stock property positional-only. And it was merged at like five minutes, I think. I was 224 | like, wow, that was fun. Let's do that again. That was how I got my start. Quickly discovered that 225 | 226 | 46 227 | 00:10:00,096 --> 00:10:09,983 228 | it was really fun working with the team and that the team was incredibly welcoming. I owe a lot to 229 | the other typeshed maintainers because those were some of the first open source contributions 230 | 231 | 47 232 | 00:10:10,043 --> 00:10:22,428 233 | I made. I can completely agree because the typeshed team is amazing. They're very fast to 234 | respond. They're very picky in a good way. They find a lot of different details and different 235 | 236 | 48 237 | 00:10:23,228 --> 00:10:38,792 238 | thing to prove. And I think that it is a very rare example of a project that it is very addictive 239 | contributing to. Yes. Yeah, definitely. So my advice for starting to contribute is to, we're 240 | 241 | 49 242 | 00:10:38,832 --> 00:10:53,518 243 | still adding stubs for things that were added or changed in Python 3.13. So I have an issue open on 244 | typeshed that I wrote up during the PyCon sprints, add or change things that were added or 245 | 246 | 50 247 | 00:10:53,538 --> 00:11:04,604 248 | changed in Python 3.13 to our stubs. So that's a great way you can help us out right now. Yeah, 249 | another way you can help us out is we have a lot of our standard library stubs generally have 250 | 251 | 51 252 | 00:11:05,005 --> 00:11:16,536 253 | fairly complete annotations. But for our third party stubs, there's loads of parameters which 254 | don't have any annotations. or are marked with incomplete, which means it's an alias for any, 255 | 256 | 52 257 | 00:11:16,616 --> 00:11:26,911 258 | but it means that we don't know exactly what should go there yet because we haven't looked into it 259 | yet. So if you fancy going through our stubs and helping improve our third party stubs, those are 260 | 261 | 53 262 | 00:11:26,951 --> 00:11:40,485 263 | also very welcome. I have a very specific workflow for finding stops that you can help with. You 264 | can just press go to type definition and you can find the stops right in front of you in your IDE. So 265 | 266 | 54 267 | 00:11:40,645 --> 00:11:53,459 268 | you can see what stops are filled with annotations and what stops are missing right now. This is 269 | really helpful. So please consider doing that. I would definitely encourage just very small 270 | 271 | 55 272 | 00:11:53,499 --> 00:12:03,793 273 | PRs, five or 10 lines are very welcome. They're very easy for us to review and we'll probably 274 | review them very quickly. If it's a PR of 1000 lines, then we'll get to it eventually, but it might 275 | 276 | 56 277 | 00:12:03,813 --> 00:12:14,222 278 | take a while for us to to look at it because we're quite busy people. Yeah, don't be afraid to just 279 | make very piecemeal contributions. There's just as good as larger contributions, and there's 280 | 281 | 57 282 | 00:12:14,262 --> 00:12:26,791 283 | no shame in that small PR. TypeShift is very beginner-friendly. It is very easy to contribute, 284 | and I highly promote doing so. Yeah, I completely agree. I think my first PR was like five lines or 285 | 286 | 58 287 | 00:12:26,851 --> 00:12:43,294 288 | so changed, and so were around my first 30 PRs. Yeah. I also have one more question that arised just 289 | now, because there are two type systems actually. One is for static checks and one is for Python 290 | 291 | 59 292 | 00:12:43,334 --> 00:12:55,857 293 | runtime. And I think that we've missed the runtime part. Do you have some insights about what 294 | steps are going to land in this part? What are the problems right now that we can solve in the 295 | 296 | 60 297 | 00:12:55,917 --> 00:13:14,423 298 | future? And what are the problems that we cannot solve at all? Sure. Are you interested in Python 299 | 3.13 or 14? I think we can discuss both of them. Okay. Python 3.13 is a really exciting release 300 | 301 | 61 302 | 00:13:15,083 --> 00:13:28,332 303 | because we have both an experimental mode where you can turn off the GIL at runtime, which is the 304 | global interpreter lock, which prevents more than one thread running simultaneously in 305 | 306 | 62 307 | 00:13:28,552 --> 00:13:42,403 308 | Python. And we also have another experimental mode, which creates a just-in-time 309 | interpreter. And you can also enable both at once if you want, although they've been created by 310 | 311 | 63 312 | 00:13:42,463 --> 00:13:53,902 313 | different people and different teams, but they do somehow work together nonetheless. So both 314 | of those are unlikely to make your code much faster right now. The version of Python without the 315 | 316 | 64 317 | 00:13:53,942 --> 00:14:09,019 318 | GIL has quite a few optimizations turned off because they're not thread safe yet. And the 319 | just-in-time interpreter for the other experimental build option is very new and doesn't slow 320 | 321 | 65 322 | 00:14:09,021 --> 00:14:18,316 323 | Python down at all, but also doesn't speed it up yet. So for both of them, you'll probably have to 324 | wait until Python 3.14 until they speed up your code much, but you can play around with them now. 325 | 326 | 66 327 | 00:14:19,236 --> 00:14:29,763 328 | And that's exciting things coming for Python 3.14, which is not the next Python release, but the 329 | one after that. We'll hopefully have big speed ups for both single-threaded and 330 | 331 | 67 332 | 00:14:43,839 --> 00:14:43,919 333 | multi-threaded code. In Python 3.14, so not the Python release that's coming out in October, 334 | but the one that will be coming out in 2025, I suppose, we will hopefully be getting PEP 649, 335 | 336 | 68 337 | 00:14:43,919 --> 00:14:58,242 338 | which is lazily evaluated annotations by default in Python. So currently, if you have a 339 | function that returns a class, and then you define that class later on in the same file, or it's a 340 | 341 | 69 342 | 00:14:58,282 --> 00:15:12,551 343 | method on that class that returns itself, then you'll get a name error if you try to reference 344 | that class that doesn't yet exist in the return type of that function or method. And you can get 345 | 346 | 70 347 | 00:15:12,571 --> 00:15:21,802 348 | around that at the moment by doing from done to future import annotations at the top of your file. 349 | But the problem with that is that it turns every annotation in your file into a string. So this 350 | 351 | 71 352 | 00:15:21,862 --> 00:15:35,362 353 | breaks tools that do runtime introspection of annotations Uh, like the TypeGuard library or 354 | TriCast or Pydantic or FastAPI. Uh, and these tools have become really popular for the last few 355 | 356 | 72 357 | 00:15:35,402 --> 00:15:46,032 358 | years. So originally the plan was from, for, from future import annotations to become the 359 | default in Python 3.10. But then that plan was scrapped, uh, because it was realized that it 360 | 361 | 73 362 | 00:15:46,052 --> 00:15:57,559 363 | would break all of these tools. So the new plan is to, uh, have. all annotations be runtime 364 | objects, just like they are now, but for those two runtime objects to be lazily evaluated on 365 | 366 | 74 367 | 00:15:57,599 --> 00:16:11,086 368 | request using descriptors. This is quite a complicated change to implement, which involves 369 | lots of changes to the compiler and to the Python data model, but it should hopefully solve all 370 | 371 | 75 372 | 00:16:11,186 --> 00:16:25,414 373 | use cases. It is currently halfway towards being implemented in CPython at the moment and 374 | should be landing in Python 3.14. And the work is being done by Jelle Zijlstra. I hope I 375 | 376 | 76 377 | 00:16:25,434 --> 00:16:38,322 378 | pronounced his name correctly. Yeah, I think so. I think so. But I learned several times how to 379 | pronounce his name correctly. So yeah. Yeah. So he's the other typing module maintainer at 380 | 381 | 77 382 | 00:16:38,342 --> 00:16:50,641 383 | CPython, and also a typeshed maintainer, and black developer, and MyPy maintainer, and 384 | typing_extensions maintainer. So he also does a lot of things. He does a lot of things. He is very 385 | 386 | 78 387 | 00:16:50,701 --> 00:17:01,409 388 | active in both the Python core development and in typeshed and in typing_extensions because I 389 | think that he is the main maintainer of type extensions as far as I remember. Do you have any other 390 | 391 | 79 392 | 00:17:01,429 --> 00:17:13,479 393 | examples of things that will be better in future versions of Python considering runtime 394 | support of types? So for introspection, maybe some changes to inspect modules, something like 395 | 396 | 80 397 | 00:17:13,519 --> 00:17:28,265 398 | that. Oh, inspect.signatures. Has that been implemented? It's a work in progress. Right. Yeah. 399 | So there's currently a proposal by Serhiy Storchaka, again, I hope I pronounced his name 400 | 401 | 81 402 | 00:17:28,285 --> 00:17:40,715 403 | correctly, to implement support for functions, better support for functions that have 404 | multiple signatures in Python. So we already support these in the static typing system via 405 | 406 | 82 407 | 00:17:40,775 --> 00:17:52,664 408 | typing.overload. But at runtime, if you call inspect.signature on a function, then it will 409 | only ever give you one signature for that function. And that's often not very accurate if you 410 | 411 | 83 412 | 00:17:52,684 --> 00:18:05,372 413 | have something like a function that's decorated with functools.singleDispatch, for 414 | example. or just a built-in function like max or min, which you can use in many different ways. If 415 | 416 | 84 417 | 00:18:05,432 --> 00:18:14,754 418 | it's implemented, then this proposal will mean that I can't remember whether the proposal was 419 | for it to return a multi-signature object or a list of signature objects. It's quite a 420 | 421 | 85 422 | 00:18:14,814 --> 00:18:24,977 423 | complicated thing to work through exactly how it would work. Yeah. So we'll see whether that 424 | happens, but fingers crossed. I think it would definitely better reflect Python semantics at 425 | 426 | 86 427 | 00:18:25,037 --> 00:18:38,581 428 | runtime. I really hope that Python will get better at both static checks and at runtime checks 429 | because both are very important for the ecosystem and for Python developers. Typing is really 430 | 431 | 87 432 | 00:18:38,601 --> 00:18:51,047 433 | interesting and I highly recommend everyone to at least try to contribute to typeshed and maybe 434 | some other tools like pyright, MyPy and CPython itself. Alex, thanks a lot for coming and 435 | 436 | 88 437 | 00:18:51,167 --> 00:19:07,102 438 | answering my questions. I think that our audience will have a lot to learn from your expertise 439 | and from your interview. And it was a pleasure for me to see you here. So thanks. Thanks so much for 440 | 441 | 89 442 | 00:19:07,142 --> 00:19:08,183 443 | inviting me. This is really fun. 444 | -------------------------------------------------------------------------------- /editing/captions/7/ru.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:33,630000 --> 00:00:35,220000 3 | добро пожаловать на мой канал, Алекс. 4 | 5 | 2 6 | 00:00:35,220000 --> 00:00:36,520000 7 | не мог бы ты, пожалуйста, представиться? 8 | 9 | 3 10 | 00:00:36,520000 --> 00:00:37,650000 11 | я рад быть здесь. 12 | 13 | 4 14 | 00:00:37,910000 --> 00:00:39,580000 15 | да, я Алекс. 16 | 17 | 5 18 | 00:00:39,580000 --> 00:00:45,820000 19 | в настоящее время я работаю в astral-sh, где работаю над линтером ruff. 20 | 21 | 6 22 | 00:00:45,820000 --> 00:00:50,700000 23 | а в свободное время я занимаюсь многими вещами с открытым исходным кодом в сообществе Python. 24 | 25 | 7 26 | 00:00:50,700000 --> 00:00:52,370000 27 | так что я core-разработчик CPython. 28 | 29 | 8 30 | 00:00:52,790000 --> 00:00:54,700000 31 | я занимаюсь сопровождением typeshed. 32 | 33 | 9 34 | 00:00:54,700000 --> 00:01:02,050000 35 | я также поддерживаю flake-pyi, ориентированный на типизацию, и помогаю с MyPy. 36 | 37 | 10 38 | 00:01:02,350000 --> 00:01:04,970000 39 | и я также поддерживаю typing_extensions. 40 | 41 | 11 42 | 00:01:05,190000 --> 00:01:08,210000 43 | о, это очень, очень хороший список. 44 | 45 | 12 46 | 00:01:09,150000 --> 00:01:16,120000 47 | я рад, что ты принял это приглашение, и я собираюсь спросить тебя о некоторых глубоких typeshed штуках. 48 | 49 | 13 50 | 00:01:16,120000 --> 00:01:23,450000 51 | и я действительно хочу знать, есть ли какие-то вещи, которые мы действительно можем улучшить в тестировании typeshed? 52 | 53 | 14 54 | 00:01:23,710000 --> 00:01:28,260000 55 | потому что прямо сейчас проводится много проверок, много заданий CI. 56 | 57 | 15 58 | 00:01:28,260000 --> 00:01:30,620000 59 | мы проверяем в основном все, что можем. 60 | 61 | 16 62 | 00:01:30,620000 --> 00:01:31,700000 63 | что мы можем сделать лучше? 64 | 65 | 17 66 | 00:01:31,700000 --> 00:01:32,890000 67 | каково твое мнение? 68 | 69 | 18 70 | 00:01:34,870000 --> 00:01:36,570000 71 | это действительно интересный вопрос. 72 | 73 | 19 74 | 00:01:37,830000 --> 00:01:48,420000 75 | я думаю, да, у нас уже есть множество тестов, которые позволяют убедиться, что аннотации, которые у нас есть, хороши, а заглушки, которые у нас есть, соответствуют среде выполнения. 76 | 77 | 20 78 | 00:01:48,420000 --> 00:01:53,570000 79 | я думаю, что, вероятно, единственное, что я хотел бы улучшить, - это улучшить генерацию заглушек. 80 | 81 | 21 82 | 00:01:53,630000 --> 00:02:03,850000 83 | чтобы людям было проще просто добавлять базовые заглушки, которые имеют достойное качество, и им не нужно было бы очень усердно работать, чтобы добиться этого. 84 | 85 | 22 86 | 00:02:04,710000 --> 00:02:11,960000 87 | у нас есть скрипты генерации заглушек, и они будут создавать очень простые заглушки, но на самом деле эти заглушки не так уж много стоят. 88 | 89 | 23 90 | 00:02:11,960000 --> 00:02:22,010000 91 | есть простые способы сделать их еще лучше, и у нас в MyPy есть несколько участников, которые в данный момент довольно много работают над stubgen, что приятно видеть, но, я думаю, мы можем сделать гораздо больше. 92 | 93 | 24 94 | 00:02:22,670000 --> 00:02:25,810000 95 | так вот, именно на этом я бы, наверное, сосредоточил свои усилия прямо сейчас. 96 | 97 | 25 98 | 00:02:26,310000 --> 00:02:32,460000 99 | я также думаю, что у нас нет никакой подработки, кроме Linux, macOS или Windows. 100 | 101 | 26 102 | 00:02:32,460000 --> 00:02:35,250000 103 | у нас здесь всего три операционные системы. 104 | 105 | 27 106 | 00:02:35,390000 --> 00:02:42,540000 107 | и я думаю, что было бы очень хорошей идеей запустить что-то вроде Solitis или что-то в этом роде. 108 | 109 | 28 110 | 00:02:42,540000 --> 00:02:43,010000 111 | да. 112 | 113 | 29 114 | 00:02:43,950000 --> 00:02:45,370000 115 | да, это интересно. 116 | 117 | 30 118 | 00:02:46,350000 --> 00:02:54,100000 119 | я не знаю, много ли людей жаловались на качество проверки типов в Solaris, например. 120 | 121 | 31 122 | 00:02:54,100000 --> 00:02:58,050000 123 | но если это так, то я не знаю, насколько это серьезная проблема. 124 | 125 | 32 126 | 00:02:58,390000 --> 00:03:02,220000 127 | но если это действительно проблема, то я бы определенно высказался за это. 128 | 129 | 33 130 | 00:03:02,220000 --> 00:03:06,490000 131 | да, мне было бы интересно поговорить с ребятами из Solaris и посмотреть, что у них на уме 132 | 133 | 34 134 | 00:03:06,910000 --> 00:03:22,680000 135 | да, я думаю, что не так много людей используют Solaris, так что у нас не так много жалоб, потому что вам нужно не только использовать Solaris и проверку типов в CPython, но и использовать для этого некоторые специфические API, чтобы вы могли видеть реальные проблемы. 136 | 137 | 35 138 | 00:03:22,680000 --> 00:03:29,410000 139 | но да, именно в этом и заключается моя точка зрения, что я действительно хочу видеть улучшения время от времени. 140 | 141 | 36 142 | 00:03:30,030000 --> 00:03:41,810000 143 | хорошо, я думаю, что этот вопрос на самом деле не имеет отношения к типизации, но я не могу просто пропустить его, потому что думаю, что это будет очень интересно как для моей аудитории, так и для меня самого. 144 | 145 | 37 146 | 00:03:42,310000 --> 00:03:46,890000 147 | как тебе Rust и его система типов по сравнению с CPython? 148 | 149 | 38 150 | 00:03:47,790000 --> 00:03:49,260000 151 | мне это очень нравится. 152 | 153 | 39 154 | 00:03:49,260000 --> 00:03:57,570000 155 | последние несколько дней я занимался рефакторингом множества тестов, и мне очень неприятно, что приходится компилировать каждый тест, прежде чем запустить хоть один из них. 156 | 157 | 40 158 | 00:03:59,710000 --> 00:04:01,520000 159 | эта часть мне не очень нравится. 160 | 161 | 41 162 | 00:04:01,520000 --> 00:04:11,850000 163 | я думаю, что дело в том, что я изучал Rust относительно недавно, в декабре, и больше всего меня удивило то, что я ожидал, что она будет более строгой, чем система типов Python, во всех отношениях. 164 | 165 | 42 166 | 00:04:11,990000 --> 00:04:15,020000 167 | на самом деле все было не так. 168 | 169 | 43 170 | 00:04:15,020000 --> 00:04:18,320000 171 | есть некоторые вещи, которые вы можете делать в Rust и которые вы не можете сделать в Python. 172 | 173 | 44 174 | 00:04:18,320000 --> 00:04:28,560000 175 | например, гораздо проще переопределить символ на другой тип позже в той же функции в Rust, чем в Python. 176 | 177 | 45 178 | 00:04:28,560000 --> 00:04:30,410000 179 | MyPy, как правило, не позволяет тебе этого делать. 180 | 181 | 46 182 | 00:04:30,990000 --> 00:04:32,600000 183 | pyright никогда не позволит тебе этого сделать. 184 | 185 | 47 186 | 00:04:32,600000 --> 00:04:35,180000 187 | так что это застало меня врасплох. 188 | 189 | 48 190 | 00:04:35,180000 --> 00:04:45,060000 191 | и причина этого в том, что правила определения области действия Rust таковы, что это можно безопасно сделать в Rust, в то время как в Python это невозможно. 192 | 193 | 49 194 | 00:04:45,060000 --> 00:04:48,570000 195 | но да, мне нравится писать на Rust. 196 | 197 | 50 198 | 00:04:52,950000 --> 00:04:54,220000 199 | это очень освежает. 200 | 201 | 51 202 | 00:04:54,220000 --> 00:04:55,930000 203 | я думаю, это очень освежает. 204 | 205 | 52 206 | 00:04:56,110000 --> 00:05:01,960000 207 | потому что, когда ты пишешь на Rust, ты композируешь программы, а не просто пишешь их. 208 | 209 | 53 210 | 00:05:01,960000 --> 00:05:04,360000 211 | ты должен все тщательно продумать. 212 | 213 | 54 214 | 00:05:04,360000 --> 00:05:07,890000 215 | ты должен подумать об управлении памятью, ты должен подумать об исключениях. 216 | 217 | 55 218 | 00:05:09,190000 --> 00:05:11,250000 219 | я имею в виду отсутствие исключений. 220 | 221 | 56 222 | 00:05:12,230000 --> 00:05:13,280000 223 | это очень интересно. 224 | 225 | 57 226 | 00:05:13,280000 --> 00:05:14,450000 227 | да, я это понимаю. 228 | 229 | 59 230 | 00:05:15,340000 --> 00:05:24,850000 231 | итак, если мы говорим о системах типов и их различиях в разных языках, что вы думаете о том, какие самые большие вызовы стоят перед системой типов Python прямо сейчас? 232 | 233 | 60 234 | 00:05:24,910000 --> 00:05:28,890000 235 | я думаю, что мы находимся на интересном этапе разработки систем типов. 236 | 237 | 61 238 | 00:05:29,310000 --> 00:05:41,050000 239 | за последнее время, с тех пор, как был представлен PEP 484, который был тем самым PEP, который ввел систему типов, у нас появилось много новых функций практически в каждом выпуске Python. 240 | 241 | 62 242 | 00:05:41,550000 --> 00:05:44,170000 243 | так что это был период действительно стремительной эволюции. 244 | 245 | 63 246 | 00:05:44,430000 --> 00:05:53,420000 247 | и прямо сейчас, за прошедший год, мы стали свидетелями создания Typing Council и создания первой версии Typing Spec. 248 | 249 | 64 250 | 00:05:53,420000 --> 00:05:56,420000 251 | и я думаю... Не мог ли бы ты, пожалуйста, немного подробнее остановиться на этом? 252 | 253 | 65 254 | 00:05:56,420000 --> 00:06:00,330000 255 | потому что я почти уверен, что многие люди с этим не знакомы. 256 | 257 | 66 258 | 00:06:00,510000 --> 00:06:01,450000 259 | спасибо, да. 260 | 261 | 67 262 | 00:06:01,830000 --> 00:06:16,280000 263 | так вот, Typing Council - это недавно созданный орган, в котором представлены несколько авторов средств проверки типов, а также несколько других людей, которые активно занимались системой типов в течение последних нескольких лет. 264 | 265 | 68 266 | 00:06:16,280000 --> 00:06:29,080000 267 | по сути, они выступают в качестве консультативного органа при Steering Council, где Steering Council делегирует им многие решения, касающиеся PEPs. 268 | 269 | 69 270 | 00:06:29,080000 --> 00:06:35,810000 271 | я думаю, что слово "делегировать", возможно, не совсем подходящее, потому что последнее слово остается за Steering Council, но он в значительной степени учитывает их рекомендации. 272 | 273 | 70 274 | 00:06:35,870000 --> 00:06:39,320000 275 | так вот, была разработана новая спецификация для системы типов. 276 | 277 | 71 278 | 00:06:39,320000 --> 00:06:51,820000 279 | таким образом, это попытка формально описать, как все правила, которые были созданы с помощью различных предложений по улучшению Python за последние несколько лет, как все они сочетаются друг с другом, как они должны работать в тандеме. 280 | 281 | 72 282 | 00:06:51,820000 --> 00:07:01,780000 283 | и любые небольшие изменения в спецификации типов могут быть автоматически одобрены Typing Council без необходимости написания нового PEP по типам. 284 | 285 | 73 286 | 00:07:01,780000 --> 00:07:08,080000 287 | так что это еще одна функция Typing Council, помимо предоставления отзывов о PEP по типам. 288 | 289 | 74 290 | 00:07:08,080000 --> 00:07:10,730000 291 | я думаю, что это влияет на общее настроение в сообществе типизации. 292 | 293 | 75 294 | 00:07:10,990000 --> 00:07:25,400000 295 | так что, по моему мнению, на данный момент я не могу говорить за всех в сообществе, но мне кажется, что общее настроение в сообществе типизации настроение прямо сейчас таково, что мы хотим немного притормозить с функциями и более формально разобраться, как именно они работают 296 | 297 | 76 298 | 00:07:25,400000 --> 00:07:30,800000 299 | я хотел бы узнать, как существующие функции, которые у нас есть, должны работать вместе и взаимодействовать немного лучше. 300 | 301 | 77 302 | 00:07:30,800000 --> 00:07:43,450000 303 | так вот, я думаю, что Typing Council отлично справляется со своей работой, потому что объем информации, которую им приходится собирать, согласовывать с различными средствами проверки типов и стандартизировать, просто... 304 | 305 | 78 306 | 00:07:44,150000 --> 00:07:45,250000 307 | он очень большой. 308 | 309 | 79 310 | 00:07:45,270000 --> 00:07:50,560000 311 | и я также хочу подчеркнуть, что они не просто создают спецификацию для этого. 312 | 313 | 80 314 | 00:07:50,560000 --> 00:07:54,690000 315 | они также создают пакет соответствия для всех средств проверки типов. 316 | 317 | 81 318 | 00:07:54,750000 --> 00:08:02,570000 319 | таким образом, все средства проверки типов могут иметь базовый набор функций, которые должны поддерживаться и к которым следует относиться одинаково. 320 | 321 | 82 322 | 00:08:02,910000 --> 00:08:07,220000 323 | я думаю, что это было долгожданное дополнение к команде управления Python. 324 | 325 | 83 326 | 00:08:07,220000 --> 00:08:08,900000 327 | я очень ценю их работу. 328 | 329 | 84 330 | 00:08:08,900000 --> 00:08:09,970000 331 | я полностью согласен с ними. 332 | 333 | 85 334 | 00:08:10,070000 --> 00:08:13,400000 335 | не мог бы ты, пожалуйста, рассказать немного о своей личной истории? 336 | 337 | 86 338 | 00:08:13,400000 --> 00:08:15,740000 339 | как ты начал вносить свой вклад в typeshed? 340 | 341 | 87 342 | 00:08:15,740000 --> 00:08:26,300000 343 | так что это может послужить хорошим примером для тех, кто только хочет начать вносить свой вклад, или просто для тех, кто не знает, что они могут внести свой вклад в typeshed прямо сейчас. 344 | 345 | 88 346 | 00:08:26,300000 --> 00:08:35,410000 347 | если вернуться немного назад, то я изначально начал изучать типизацию в Python, потому что на самом деле я был новичком в Python и пользовался PyCharm. 348 | 349 | 89 350 | 00:08:35,710000 --> 00:08:50,740000 351 | функция проверки типов в PyCharm была включена по умолчанию, так что я продолжал писать код и постоянно сталкивался с этими странными, раздражающими ошибками о том, как я сказал, что это был list, а теперь это dict, и PyCharm очень разозлился 352 | 353 | 90 354 | 00:08:50,740000 --> 00:08:51,040000 355 | и ругался на меня. 356 | 357 | 91 358 | 00:08:51,040000 --> 00:08:56,600000 359 | Так вот, я прочитал множество учебных пособий и думаю, что когда я узнаю что-то новое, мне нравится изучать это как следует. 360 | 361 | 92 362 | 00:08:56,600000 --> 00:09:03,880000 363 | в результате этого я узнал довольно много о системе типов в Python, а затем быстро разобрался во всем 364 | 365 | 93 366 | 00:09:03,880000 --> 00:09:14,210000 367 | ответы на вопросы о типизации в Python были действительно хорошим способом получить много баллов в Stack Overflow, потому что в Stack Overflow было множество таких вопросов. 368 | 369 | 94 370 | 00:09:14,710000 --> 00:09:18,740000 371 | из-за этого я продолжал наращивать свой опыт в типизации Python. 372 | 373 | 95 374 | 00:09:18,740000 --> 00:09:31,320000 375 | а потом, в конце концов, однажды я просто просматривал разделы typeshed для встроенных модулей и заметил, что множество параметров не были помечены как только-позиционные в stubs, где они были. 376 | 377 | 96 378 | 00:09:31,320000 --> 00:09:32,010000 379 | о да. 380 | 381 | 97 382 | 00:09:32,510000 --> 00:09:33,130000 383 | да. 384 | 385 | 98 386 | 00:09:35,230000 --> 00:09:40,580000 387 | кстати, мы исправили все проблемы, связанные c только-позиционными параметрами? 388 | 389 | 99 390 | 00:09:40,580000 --> 00:09:43,540000 391 | все, которые можно автоматически обнаружить. 392 | 393 | 100 394 | 00:09:43,540000 --> 00:09:43,960000 395 | да. 396 | 397 | 101 398 | 00:09:43,960000 --> 00:09:51,340000 399 | так что я создал PR, например, сделал некоторые параметры в некоторых методах только позиционными. 400 | 401 | 102 402 | 00:09:51,340000 --> 00:09:54,090000 403 | и все это было сделано примерно за пять минут, я думаю. 404 | 405 | 103 406 | 00:09:54,350000 --> 00:09:56,530000 407 | я подумал: "Вау, это было весело". 408 | 409 | 104 410 | 00:09:58,190000 --> 00:09:59,320000 411 | давай повторим это еще раз. 412 | 413 | 105 414 | 00:09:59,320000 --> 00:10:00,680000 415 | именно так я начал свою карьеру. 416 | 417 | 106 418 | 00:10:00,680000 --> 00:10:05,280000 419 | я быстро понял, что работать с командой было действительно весело и что команда была невероятно гостеприимной. 420 | 421 | 107 422 | 00:10:05,280000 --> 00:10:11,060000 423 | я многим обязан другим разработчикам typeshed, потому что это были одни из первых моих вкладов в разработку открытого исходного кода. 424 | 425 | 108 426 | 00:10:11,060000 --> 00:10:15,100000 427 | я могу с этим полностью согласиться, потому что команда typeshed потрясающая. 428 | 429 | 109 430 | 00:10:15,100000 --> 00:10:17,130000 431 | они очень быстро реагируют. 432 | 433 | 110 434 | 00:10:17,590000 --> 00:10:19,820000 435 | они очень разборчивы в хорошем смысле этого слова. 436 | 437 | 111 438 | 00:10:19,820000 --> 00:10:25,200000 439 | они находят много разных деталей и доказывают разные вещи. 440 | 441 | 112 442 | 00:10:25,200000 --> 00:10:32,280000 443 | и я думаю, что это очень редкий пример проекта, участие в котором вызывает сильное привыкание. 444 | 445 | 113 446 | 00:10:32,280000 --> 00:10:32,730000 447 | да. 448 | 449 | 114 450 | 00:10:32,950000 --> 00:10:34,530000 451 | да, определенно. 452 | 453 | 115 454 | 00:10:35,070000 --> 00:10:44,490000 455 | так что мой совет для того, чтобы начать вносить свой вклад, заключается в следующем: мы все еще добавляем заглушки для вещей, которые были добавлены или изменены в Python 3.13. 456 | 457 | 116 458 | 00:10:44,510000 --> 00:10:56,600000 459 | Итак, у меня есть открытая проблема с typeshed, о которой я написал во время спринтов PyCon, добавляйте или изменяйте вещи, которые были добавлены или изменены в Python 3.13, в наши заглушки. 460 | 461 | 117 462 | 00:10:56,600000 --> 00:10:59,540000 463 | так что это отличный способ, которым ты можешь помочь нам прямо сейчас. 464 | 465 | 118 466 | 00:10:59,540000 --> 00:11:07,100000 467 | да, еще один способ, которым ты можешь нам помочь, заключается в том, что у нас есть много стандартных библиотечных заглушек, которые, как правило, содержат довольно полные аннотации. 468 | 469 | 119 470 | 00:11:07,100000 --> 00:11:11,770000 471 | но в наших сторонних заглушках есть множество параметров, которые не содержат никаких аннотаций. 472 | 473 | 120 474 | 00:11:12,070000 --> 00:11:21,700000 475 | или помечены как неполные, что означает, что это псевдоним для любого из них, но это означает, что мы пока точно не знаем, что там должно быть, потому что мы еще не изучали это. 476 | 477 | 121 478 | 00:11:21,700000 --> 00:11:28,540000 479 | так что, если у тебя есть желание ознакомиться с нашими заглушками и помочь улучшить наши сторонние заглушки, мы также будем очень рады. 480 | 481 | 122 482 | 00:11:28,540000 --> 00:11:33,580000 483 | у меня есть очень специфический рабочий процесс поиска заглушек, с которым ты можешь помочь. 484 | 485 | 123 486 | 00:11:33,580000 --> 00:11:40,650000 487 | ты можешь просто нажать перейти к определению типа и найти заглушки прямо перед собой в своей IDE. 488 | 489 | 124 490 | 00:11:40,710000 --> 00:11:47,730000 491 | так ты сможешь увидеть, какие заглушки заполнены аннотациями, а какие отсутствуют прямо сейчас. 492 | 493 | 125 494 | 00:11:47,870000 --> 00:11:49,120000 495 | это действительно полезно. 496 | 497 | 126 498 | 00:11:49,120000 --> 00:11:50,690000 499 | так что, пожалуйста, подумай о том, чтобы сделать это. 500 | 501 | 127 502 | 00:11:51,270000 --> 00:11:57,180000 503 | я бы определенно рекомендовал использовать только очень маленькие PR, 5 или 10 строк приветствуются. 504 | 505 | 128 506 | 00:11:57,180000 --> 00:12:00,820000 507 | нам очень легко их просмотреть, и мы, вероятно, просмотрим их очень быстро. 508 | 509 | 129 510 | 00:12:00,820000 --> 00:12:08,100000 511 | если речь идет о PR в 1000 строк, то в конце концов мы дойдем до этого, но нам может потребоваться некоторое время, чтобы ознакомиться с ними, потому что мы довольно занятые люди. 512 | 513 | 130 514 | 00:12:08,100000 --> 00:12:11,900000 515 | да, не бойся вносить свой вклад по частям. 516 | 517 | 131 518 | 00:12:11,900000 --> 00:12:16,940000 519 | это так же хорошо, как и более крупные взносы, и в этом маленьком PR нет ничего постыдного. 520 | 521 | 132 522 | 00:12:16,940000 --> 00:12:19,240000 523 | typeshed очень дружелюбна к начинающим. 524 | 525 | 133 526 | 00:12:19,240000 --> 00:12:23,040000 527 | внести свой вклад очень просто, и я всячески поощряю это. 528 | 529 | 134 530 | 00:12:23,040000 --> 00:12:24,280000 531 | да, я полностью согласен. 532 | 533 | 135 534 | 00:12:24,280000 --> 00:12:31,850000 535 | я думаю, что мой первый PR состоял примерно из пяти измененных строк, как и мои первые 30 PR. 536 | 537 | 136 538 | 00:12:32,430000 --> 00:12:32,920000 539 | да. 540 | 541 | 137 542 | 00:12:32,920000 --> 00:12:40,060000 543 | у меня только что возник еще один вопрос, потому что на самом деле существует две системы типов. 544 | 545 | 138 546 | 00:12:40,060000 --> 00:12:44,560000 547 | одна предназначена для статических проверок, а другая - для среды выполнения Python. 548 | 549 | 139 550 | 00:12:44,560000 --> 00:12:47,450000 551 | и я думаю, что мы пропустили часть времени выполнения. 552 | 553 | 140 554 | 00:12:47,470000 --> 00:12:53,570000 555 | у тебя есть какие-нибудь идеи о том, какие шаги будут выполнены в этой части? 556 | 557 | 141 558 | 00:12:53,670000 --> 00:12:56,960000 559 | какие проблемы существуют прямо сейчас и которые мы можем решить в будущем? 560 | 561 | 142 562 | 00:12:56,960000 --> 00:12:59,730000 563 | а какие проблемы мы вообще не можем решить? 564 | 565 | 143 566 | 00:13:01,830000 --> 00:13:02,320000 567 | конечно. 568 | 569 | 144 570 | 00:13:02,320000 --> 00:13:05,450000 571 | тебя интересует Python 3.13 или 14? 572 | 573 | 145 574 | 00:13:07,870000 --> 00:13:09,930000 575 | я думаю, мы можем обсудить оба. 576 | 577 | 146 578 | 00:13:10,750000 --> 00:13:11,370000 579 | хорошо. 580 | 581 | 147 582 | 00:13:11,910000 --> 00:13:26,980000 583 | Python 3.13 - действительно захватывающий релиз, потому что у нас есть экспериментальный режим, в котором вы можете отключить GIL во время выполнения, что является глобальной блокировкой интерпретатора, которая предотвращает 584 | 585 | 148 586 | 00:13:26,980000 --> 00:13:29,700000 587 | выполнение более одного потока в Python одновременно. 588 | 589 | 149 590 | 00:13:29,700000 --> 00:13:37,170000 591 | а еще у нас есть другой экспериментальный режим, который создает JIT интерпретатор. 592 | 593 | 150 594 | 00:13:37,230000 --> 00:13:47,290000 595 | и вы также можете включить оба режима одновременно, если хотите, хотя они были созданы разными людьми и разными командами, но, тем не менее, они каким-то образом работают вместе. 596 | 597 | 151 598 | 00:13:48,590000 --> 00:13:52,820000 599 | так что оба этих способа вряд ли значительно ускорят ваш код прямо сейчас. 600 | 601 | 152 602 | 00:13:52,820000 --> 00:14:00,080000 603 | в версии Python без GIL отключено довольно много оптимизаций, потому что они еще не являются потокобезопасными. 604 | 605 | 153 606 | 00:14:00,080000 --> 00:14:12,440000 607 | а JIT интерпретатор для другого варианта экспериментальной сборки очень новый и совсем не замедляет работу Python, но и пока не ускоряет ее. 608 | 609 | 154 610 | 00:14:12,440000 --> 00:14:19,170000 611 | так что для них обоих вам, вероятно, придется подождать до версии Python 3.14, пока они не значительно ускорят ваш код, но теперь ты можешь поиграть с ними. 612 | 613 | 155 614 | 00:14:19,310000 --> 00:14:26,210000 615 | вот что интересного ждет нас в версии Python 3.14, которая не является следующей версией Python, а будет выпущена после нее. 616 | 617 | 156 618 | 00:14:26,910000 --> 00:14:31,650000 619 | мы надеемся, что у нас будет значительное ускорение как для однопоточного, так и для многопоточного кода. 620 | 621 | 157 622 | 00:14:31,910000 --> 00:14:46,940000 623 | в версии Python 3.14, так что, я полагаю, мы получим PEP 649 не в том выпуске Python, который выйдет в октябре, а в том, который выйдет в 2025 году. 624 | 625 | 158 626 | 00:14:46,940000 --> 00:14:49,780000 627 | в котором Python по умолчанию используют ленивое вычисление аннотации. 628 | 629 | 159 630 | 00:14:49,780000 --> 00:15:04,880000 631 | так что в настоящее время, если у вас есть функция, которая возвращает класс, а затем вы определяете этот класс позже в том же файле, или это метод этого класса, который возвращает сам себя, то при попытке ссылаться на него вы получите ошибку имени 632 | 633 | 160 634 | 00:15:04,880000 --> 00:15:10,540000 635 | это класс, который еще не существует в возвращаемом типе этой функции или метода. 636 | 637 | 161 638 | 00:15:10,540000 --> 00:15:17,440000 639 | и на данный момент вы можете обойти эту проблему, выполнив в верхней части вашего файла `from __future__ import annotations`. 640 | 641 | 162 642 | 00:15:17,440000 --> 00:15:21,610000 643 | но проблема в том, что это превращает каждую аннотацию в вашем файле в строку. 644 | 645 | 163 646 | 00:15:21,950000 --> 00:15:32,770000 647 | так что это нарушает работу инструментов, которые выполняют самоанализ аннотаций во время выполнения, таких как библиотека TypeGuard, TryCast, Pydantic или FastAPI. 648 | 649 | 164 650 | 00:15:33,070000 --> 00:15:36,480000 651 | и эти инструменты стали действительно популярными за последние несколько лет. 652 | 653 | 165 654 | 00:15:36,480000 --> 00:15:42,560000 655 | так что изначально планировалось, что аннотации импорта из будущего станут стандартными в Python 3.10. 656 | 657 | 166 658 | 00:15:42,560000 --> 00:15:48,000000 659 | но потом этот план был отменен, потому что стало ясно, что это приведет к поломке всех этих инструментов. 660 | 661 | 167 662 | 00:15:48,000000 --> 00:15:50,690000 663 | так что новый план заключается в том, чтобы иметь. 664 | 665 | 168 666 | 00:15:50,710000 --> 00:16:00,730000 667 | все аннотации должны быть объектами среды выполнения, такими же, как сейчас, но чтобы эти два объекта среды выполнения лениво вычислялись по запросу, используя дескрипторы. 668 | 669 | 169 670 | 00:16:01,070000 --> 00:16:12,610000 671 | Это довольно сложное изменение для реализации, которое включает в себя множество изменений в компиляторе и модели данных Python, но, надеюсь, оно должно решить все проблемы. варианты использования. 672 | 673 | 170 674 | 00:16:12,790000 --> 00:16:20,210000 675 | в настоящее время оно находится на полпути к реализации в CPython и должно появиться в Python 3.14. 676 | 677 | 171 678 | 00:16:20,630000 --> 00:16:25,370000 679 | и этой работой занимается Jelle Zijlstra. 680 | 681 | 172 682 | 00:16:25,390000 --> 00:16:27,490000 683 | я надеюсь, что правильно произнес его имя. 684 | 685 | 173 686 | 00:16:28,070000 --> 00:16:29,490000 687 | да, я так думаю. 688 | 689 | 174 690 | 00:16:29,510000 --> 00:16:30,340000 691 | я так думаю. 692 | 693 | 175 694 | 00:16:30,340000 --> 00:16:34,020000 695 | но я несколько раз учился правильно произносить его имя. 696 | 697 | 176 698 | 00:16:34,020000 --> 00:16:34,650000 699 | так что да. 700 | 701 | 177 702 | 00:16:35,030000 --> 00:16:35,650000 703 | да. 704 | 705 | 178 706 | 00:16:36,390000 --> 00:16:47,640000 707 | так вот, он еще один специалист по сопровождению модулей типизации в CPython, а также специалист по сопровождению typeshed, разработчик black, сопровождает MyPy и typing_extensions. 708 | 709 | 179 710 | 00:16:47,640000 --> 00:16:49,010000 711 | так что он еще много чего делает. 712 | 713 | 180 714 | 00:16:49,230000 --> 00:16:50,600000 715 | Он много чего делает. 716 | 717 | 181 718 | 00:16:50,600000 --> 00:17:00,370000 719 | Он очень активен как в разработке ядра Python, так и в typing и в typing_extensions, потому что, насколько я помню, он является главным разработчиком typing_extensions. 720 | 721 | 182 722 | 00:17:00,550000 --> 00:17:09,400000 723 | есть ли у тебя какие-нибудь другие примеры того, что будет улучшено в будущих версиях Python с учетом поддержки типов в runtime? 724 | 725 | 183 726 | 00:17:09,400000 --> 00:17:14,480000 727 | Что мы можем улучшить в модуле inspect для интроспекции? 728 | 729 | 184 730 | 00:17:14,480000 --> 00:17:17,410000 731 | О, inspect.signatures. 732 | 733 | 185 734 | 00:17:17,550000 --> 00:17:19,010000 735 | это уже реализовано? 736 | 737 | 186 738 | 00:17:19,670000 --> 00:17:21,210000 739 | работа продолжается. 740 | 741 | 187 742 | 00:17:21,510000 --> 00:17:22,130000 743 | правильно. 744 | 745 | 188 746 | 00:17:22,990000 --> 00:17:23,420000 747 | да. 748 | 749 | 189 750 | 00:17:23,420000 --> 00:17:37,820000 751 | так вот, в настоящее время есть предложение Serhiy Storchaka, опять же, я надеюсь, что правильно произнес его имя, реализовать поддержку функций, которые имеют несколько сигнатур в Python. 752 | 753 | 190 754 | 00:17:37,820000 --> 00:17:41,900000 755 | итак, мы уже поддерживаем их в системе статической типизации с помощью typing. 756 | 757 | 191 758 | 00:17:41,900000 --> 00:17:42,500000 759 | это `@typing.overload`. 760 | 761 | 192 762 | 00:17:42,500000 --> 00:17:45,160000 763 | но во время выполнения, если вы вызываете inspect. 764 | 765 | 193 766 | 00:17:45,160000 --> 00:17:50,410000 767 | сингатура функции, то она всегда будет выдавать вам только одну сигнатуру для этой функции. 768 | 769 | 194 770 | 00:17:50,550000 --> 00:17:58,520000 771 | и это часто бывает не очень точно, если у вас есть что-то вроде функции, с декоратором functools. 772 | 773 | 195 774 | 00:17:58,520000 --> 00:18:00,330000 775 | singledispatch. 776 | 777 | 196 778 | 00:18:00,590000 --> 00:18:05,820000 779 | или просто встроенная функция, такая как max или min, которую вы можете использовать самыми разными способами, с разными сигнатурами. 780 | 781 | 197 782 | 00:18:05,820000 --> 00:18:14,530000 783 | если она будет реализована, то это предложение будет означать, что я не могу вспомнить, предлагалось ли возвращать объект с несколькими сигнатурами или список объектов с сигнатурами. 784 | 785 | 198 786 | 00:18:14,750000 --> 00:18:18,880000 787 | довольно сложно разобраться, как именно это будет работать. 788 | 789 | 199 790 | 00:18:18,880000 --> 00:18:19,320000 791 | да. 792 | 793 | 200 794 | 00:18:19,320000 --> 00:18:22,040000 795 | так что посмотрим, произойдет ли это, но скрестим пальцы. 796 | 797 | 201 798 | 00:18:22,040000 --> 00:18:26,330000 799 | я думаю, что это определенно лучше отразит семантику Python во время выполнения. 800 | 801 | 202 802 | 00:18:26,390000 --> 00:18:37,730000 803 | я действительно надеюсь, что Python станет лучше справляться как со статическими проверками, так и с проверками во время выполнения, потому что и то, и другое очень важно для экосистемы и для разработчиков Python. 804 | 805 | 203 806 | 00:18:38,070000 --> 00:18:48,770000 807 | Типизация действительно интересная, и я настоятельно рекомендую всем хотя бы попытаться внести свой вклад в typeshed и, возможно, в некоторые другие инструменты, такие как pyright, MyPy и CPython сам по себе. 808 | 809 | 204 810 | 00:18:49,070000 --> 00:18:52,850000 811 | Алекс, большое спасибо, что пришел и ответил на мои вопросы. 812 | 813 | 205 814 | 00:18:53,390000 --> 00:19:01,450000 815 | я думаю, что нашей аудитории будет чему поучиться у тебя. 816 | 817 | 206 818 | 00:19:01,510000 --> 00:19:05,180000 819 | и мне было приятно видеть тебя здесь. 820 | 821 | 207 822 | 00:19:05,180000 --> 00:19:06,330000 823 | так что спасибо. 824 | 825 | 208 826 | 00:19:06,990000 --> 00:19:08,260000 827 | большое спасибо за то, что пригласил меня. 828 | 829 | 209 830 | 00:19:08,260000 --> 00:19:09,090000 831 | это действительно весело. 832 | -------------------------------------------------------------------------------- /editing/poetry.lock: -------------------------------------------------------------------------------- 1 | # This file is automatically @generated by Poetry 1.8.3 and should not be changed by hand. 2 | 3 | [[package]] 4 | name = "srt" 5 | version = "3.5.3" 6 | description = "A tiny library for parsing, modifying, and composing SRT files." 7 | optional = false 8 | python-versions = ">=2.7" 9 | files = [ 10 | {file = "srt-3.5.3.tar.gz", hash = "sha256:4884315043a4f0740fd1f878ed6caa376ac06d70e135f306a6dc44632eed0cc0"}, 11 | ] 12 | 13 | [metadata] 14 | lock-version = "2.0" 15 | python-versions = "^3.11" 16 | content-hash = "b1c8fc30beb41961ac8bf5656f8b610454220dd60ffd7c835f1f47799d2b6edd" 17 | -------------------------------------------------------------------------------- /editing/pyproject.toml: -------------------------------------------------------------------------------- 1 | [tool.poetry] 2 | name = "editing" 3 | version = "0.0.0" 4 | description = "Internal tooling for editing videos" 5 | authors = ["sobolevn "] 6 | license = "MIT" 7 | readme = "README.md" 8 | package-mode = false 9 | classifiers = [ 10 | "Private :: Do not Upload", 11 | ] 12 | 13 | [tool.poetry.dependencies] 14 | python = "^3.11" 15 | 16 | srt = "^3.5" 17 | 18 | 19 | [build-system] 20 | requires = ["poetry-core"] 21 | build-backend = "poetry.core.masonry.api" 22 | -------------------------------------------------------------------------------- /editing/srt-from-json.py: -------------------------------------------------------------------------------- 1 | import sys 2 | import json 3 | import datetime as dt 4 | from typing import Final 5 | 6 | _TIME_FORMAT: Final = '%H:%M:%S,%f' 7 | 8 | 9 | def _srt_from_json(filepath: str) -> int: 10 | with open(filepath, encoding='utf8') as json_file: 11 | contents = json.loads(json_file.read()) 12 | 13 | start_time = None 14 | resulting_lines = [] 15 | for index, entry in enumerate(contents['subtitles']): 16 | # Number 17 | resulting_lines.append(f'{index + 1}\n') 18 | 19 | # Time 20 | if start_time is None: 21 | start_time = dt.datetime( 22 | year=1, month=1, day=1, hour=0, minute=0, second=0, 23 | ) + dt.timedelta(milliseconds=entry['startMs']) 24 | end = start_time + dt.timedelta(milliseconds=entry['durationMs']) 25 | resulting_lines.append('{0} --> {1}\n'.format( 26 | start_time.strftime(_TIME_FORMAT), 27 | end.strftime(_TIME_FORMAT), 28 | )) 29 | start_time = None 30 | 31 | # Content 32 | resulting_lines.append(entry['text']) 33 | 34 | # Newlines 35 | resulting_lines.extend(['\n'] * 2) 36 | 37 | with open('out.srt', 'w', encoding='utf8') as output_file: 38 | output_file.writelines(resulting_lines) 39 | return 0 40 | 41 | 42 | if __name__ == '__main__': 43 | sys.exit(_srt_from_json(filepath=sys.argv[1])) 44 | -------------------------------------------------------------------------------- /editing/srt-shift.py: -------------------------------------------------------------------------------- 1 | import argparse 2 | import sys 3 | import datetime as dt 4 | from io import TextIOWrapper 5 | 6 | import srt 7 | 8 | 9 | def _update_time( 10 | start: dt.datetime, 11 | delta: dt.timedelta, 12 | *, 13 | is_negative: bool, 14 | ) -> dt.datetime: 15 | if is_negative: 16 | return start - delta 17 | return start + delta 18 | 19 | 20 | def _cut_since_with_duration( 21 | fileobj: TextIOWrapper, 22 | since: int, 23 | duration: str, 24 | *, 25 | is_negative: bool, 26 | ) -> int: 27 | delta = dt.timedelta(seconds=duration) 28 | 29 | captions = srt.parse(fileobj.read()) 30 | fileobj.close() 31 | 32 | updated_srt = [] 33 | for caption in captions: 34 | if caption.index >= since: 35 | caption.start = _update_time( 36 | caption.start, delta, is_negative=is_negative, 37 | ) 38 | caption.end = _update_time( 39 | caption.end, delta, is_negative=is_negative, 40 | ) 41 | updated_srt.append(caption) 42 | 43 | with open('out.srt', mode='w', encoding='utf8') as out: 44 | out.write(srt.compose(updated_srt)) 45 | 46 | 47 | if __name__ == '__main__': 48 | parser = argparse.ArgumentParser(__name__) 49 | parser.add_argument('fileobj', type=argparse.FileType()) 50 | parser.add_argument('--since', type=int) 51 | parser.add_argument('--seconds', type=int) 52 | parser.add_argument('--negative', action='store_true') 53 | args = parser.parse_args() 54 | 55 | code = _cut_since_with_duration( 56 | args.fileobj, 57 | args.since, 58 | duration=args.seconds, 59 | is_negative=args.negative, 60 | ) 61 | sys.exit(code) 62 | -------------------------------------------------------------------------------- /homeworks/1-int.md: -------------------------------------------------------------------------------- 1 | ## Теория 2 | 3 | База: 4 | - Как хранятся числа в памяти? http://www.5byte.ru/11/0008.php 5 | - Как устроен `int` внутри? https://www.codementor.io/@arpitbhayani/python-caches-integers-16jih595jk 6 | - Super long `int` in Python: https://www.youtube.com/watch?v=FNuwKuVF8Y0 7 | - `int` interning (`x, y = 1, 1; id(x) == id(y) # True`): https://www.codesansar.com/python-programming/integer-interning.htm 8 | - Immortal `int`s: https://peps.python.org/pep-0683/ 9 | 10 | Исходники: 11 | - `int`: https://github.com/python/cpython/blob/main/Objects/longobject.c 12 | 13 | Документация: 14 | - `numbers.py`: https://docs.python.org/3/library/numbers.html 15 | - Дополнительные методы на `int`: https://docs.python.org/3/library/stdtypes.html?highlight=str#additional-methods-on-integer-types 16 | -------------------------------------------------------------------------------- /homeworks/10-==.md: -------------------------------------------------------------------------------- 1 | ## Теория 2 | 3 | База: 4 | - Байткод `COMPARE_OP`: https://docs.python.org/3/library/dis.html#opcode-COMPARE_OP 5 | - Байткод `IS_OP`: https://docs.python.org/3/library/dis.html#opcode-IS_OP 6 | - Как работают сравнения в Python? https://docs.python.org/3/reference/datamodel.html#object.__eq__ 7 | - `functools.total_ordering`: https://docs.python.org/3/library/functools.html#functools.total_ordering 8 | - `functools.cmp_to_key`: https://docs.python.org/3/library/functools.html#functools.cmp_to_key 9 | - `@dataclass(eq=True, order=True)`: https://docs.python.org/3/library/dataclasses.html#dataclasses.dataclass 10 | - `ast.Compare`: https://docs.python.org/3/library/ast.html#ast.Compare 11 | 12 | Другие статьи: 13 | - https://snarky.ca/unravelling-rich-comparison-operators/ 14 | - https://snarky.ca/unravelling-is-and-is-not/ 15 | 16 | Жесть: 17 | - `PyObject_RichCompare`: https://docs.python.org/3/c-api/object.html#c.PyObject_RichCompare 18 | - `tp_richcompare`: https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_richcompare и https://docs.python.org/3/c-api/typeobj.html#c.richcmpfunc 19 | -------------------------------------------------------------------------------- /homeworks/11-bytearray.md: -------------------------------------------------------------------------------- 1 | ## Теория 2 | 3 | База: 4 | - `bytearray`: https://docs.python.org/3/library/stdtypes.html#bytearray 5 | - Методы `MutableSequence`: https://docs.python.org/3/library/collections.abc.html#collections-abstract-base-classes 6 | - `MutableSequence`: https://docs.python.org/3/library/collections.abc.html#collections.abc.MutableSequence 7 | 8 | Жесть: 9 | - Выбор стратегии для ресайза: https://github.com/python/cpython/blob/6309e9e07a855e08c223a0e295710c8bd66e793d/Objects/bytearrayobject.c#L195-L223 10 | - Изменение `->ob_start`: https://github.com/python/cpython/blob/6309e9e07a855e08c223a0e295710c8bd66e793d/Objects/bytearrayobject.c#L457-L476 11 | 12 | Мой PR с фиксом бага в `bytearray_getbuffer`: https://github.com/python/cpython/pull/126981 13 | -------------------------------------------------------------------------------- /homeworks/12-tuple.md: -------------------------------------------------------------------------------- 1 | ## Теория 2 | 3 | Исходники: 4 | - `tuple`: https://github.com/python/cpython/blob/main/Include/cpython/tupleobject.h 5 | - `collections.namedtuple`: https://github.com/python/cpython/blob/baf65715fc9002e43cd0e1010b8dba9b4c84d503/Lib/collections/__init__.py#L361 6 | - `typing.NamedTuple`: https://github.com/python/cpython/blob/baf65715fc9002e43cd0e1010b8dba9b4c84d503/Lib/typing.py#L2961-L3106 7 | 8 | Документация: 9 | - `collections.namedtuple`: https://docs.python.org/3/library/collections.html#collections.namedtuple 10 | - `typing.NamedTuple`: https://docs.python.org/3/library/typing.html#typing.NamedTuple 11 | - `PyTuple_SetItem`: https://docs.python.org/3/c-api/tuple.html#c.PyTuple_SetItem 12 | - `PyStructSequence`: https://docs.python.org/3/c-api/tuple.html#struct-sequence-objects 13 | - `ast.Tuple`: https://docs.python.org/3/library/ast.html#ast.Tuple 14 | - `typing.Tuple[...]` и `tuple[...]`: https://docs.python.org/3/library/typing.html#annotating-tuples 15 | 16 | Жесть: 17 | - `Tuple` против `List`. Мы на самом деле немного врем людям, говоря, что разница в мутабельности и иммутабельности. Что на самом деле является лишь деталью реализации в Python. Ведь есть языки, где оба типа данных иммутабельны: Erlang, Haskell, тд. Фундаметальное различие лежит внутри Теории Категории. Из нее мы узнаем, что `Tuple` - тип произведение, а `List` (по хорошему) - монада (в питоне всего лишь моноид в смысле `l + []` и недо-функтор в смысле `map(f, l)`). Вот почему тип `List[x]` имеет kind `* -> *`, а `Tuple[x, ...]` имеет kind `* -> ... -> *`. Повторить Теорию Категорий: https://github.com/hmemcpy/milewski-ctfp-pdf 18 | - `tuple` должен быть иммутабельным на уровне C: https://github.com/python/cpython/issues/127058 19 | - Algebraic Data Types: https://jrsinclair.com/articles/2019/algebraic-data-types-what-i-wish-someone-had-explained-about-functional-programming/ 20 | - Теория категорий для программистов: https://github.com/hmemcpy/milewski-ctfp-pdf 21 | - `BUILD_TUPLE`: https://docs.python.org/3/library/dis.html#opcode-BUILD_TUPLE 22 | - `INTRINSIC_LIST_TO_TUPLE`: https://docs.python.org/3/library/dis.html#opcode-CALL_INTRINSIC_1 23 | 24 | 25 | ## Практика 26 | 27 | - Разобраться с https://github.com/sobolevn/mutable-tuple 28 | -------------------------------------------------------------------------------- /homeworks/13-print.md: -------------------------------------------------------------------------------- 1 | ## Теория 2 | 3 | Документация: 4 | - `sys.stdout`: https://docs.python.org/3/library/sys.html#sys.stdout 5 | - `sys.__stdout__`: https://docs.python.org/3/library/sys.html#sys.__stdout__ 6 | - `print`: https://docs.python.org/3/library/functions.html#print 7 | - `pprint`: https://docs.python.org/3/library/pprint.html#module-pprint 8 | 9 | ASM: 10 | - `printf` на FASM: https://github.com/number571/printf 11 | - Linux syscalls `x86_64`: https://blog.rchapman.org/posts/Linux_System_Call_Table_for_x86_64 12 | - Compiler explorer: https://godbolt.org 13 | 14 | Kernel: 15 | - https://en.wikipedia.org/wiki/Write_(system_call) 16 | - syscalls in kernel: https://0xax.gitbooks.io/linux-insides/content/SysCall/linux-syscall-2.html 17 | - OS in 1000 lines of code: https://operating-system-in-1000-lines.vercel.app/en 18 | - How `printf` works? https://www.maizure.org/projects/printf 19 | 20 | История: 21 | - `print` в Python2: https://www.youtube.com/watch?v=wi2N9Fpx-5U 22 | 23 | ## Практика 24 | 25 | - Разобраться с https://github.com/sobolevn/the-best-python-course/tree/main/practice/asm-builtins 26 | -------------------------------------------------------------------------------- /homeworks/14-steering-council.md: -------------------------------------------------------------------------------- 1 | # Упоминалось в разговоре 2 | 3 | - `finally` PEP: https://peps.python.org/pep-0765 4 | - Remove `LLVM` build-time dependency PEP: https://peps.python.org/pep-0774 5 | - BOLT: https://github.com/facebookarchive/BOLT 6 | - Pyston: https://github.com/pyston/pyston 7 | - Incremental GC: https://github.com/python/cpython/issues/108362 8 | - Specializing Interpreter (Tier1) in free-threading: https://github.com/python/cpython/issues/115999 9 | - `uv install python` https://docs.astral.sh/uv/guides/install-python 10 | 11 | Контакты Donghee Na: https://github.com/corona10 12 | -------------------------------------------------------------------------------- /homeworks/2-+.md: -------------------------------------------------------------------------------- 1 | ## Теория 2 | 3 | База: 4 | - Порядок операторов: https://docs.python.org/3/reference/expressions.html#operator-precedence 5 | - `NotImplemented` vs `NotImplementedError`: https://www.youtube.com/watch?v=GSBqmYUnBdk 6 | - Почему `x[0] += [1]` работает так?: https://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works 7 | 8 | Исходники: 9 | - `operator`: https://github.com/python/cpython/blob/main/Lib/operator.py 10 | - `_operator`: https://github.com/python/cpython/blob/main/Modules/_operator.c 11 | - `PyNumber_Add`: https://github.com/python/cpython/blob/3.12/Objects/abstract.c#L1059-L1076 12 | - `PySequence_Concat`: https://github.com/python/cpython/blob/3.12/Objects/abstract.c#L1740-L1764 13 | - `PyNumber_InPlaceAdd`: https://github.com/python/cpython/blob/efeb8a24b82627bafeea7e6f6c42971fa866051c/Objects/abstract.c#L1247-L1268 14 | 15 | Документация: 16 | - `NotImplemented`: https://docs.python.org/3/library/constants.html#NotImplemented 17 | - `__add__`: https://docs.python.org/3/reference/datamodel.html#object.__add__ 18 | - `__radd__`: https://docs.python.org/3/reference/datamodel.html#object.__radd__ 19 | - `__iadd__`: https://docs.python.org/3/reference/datamodel.html#object.__iadd__ 20 | 21 | Инструменты: 22 | - Создание и работа с грамматиками: https://ohmjs.org 23 | 24 | ## Практика 25 | 26 | Напишите C-extension, который умеет складывать себя с `int` объектами, прибавляя `1`, 27 | и с `str` объектами, прибавляя `'a'` к ним. 28 | -------------------------------------------------------------------------------- /homeworks/3-what-is-python.md: -------------------------------------------------------------------------------- 1 | ## Теория 2 | 3 | База: 4 | - Compiled vs Interpreted: https://www.freecodecamp.org/news/compiled-versus-interpreted-languages 5 | - `.pyc`: https://peps.python.org/pep-0552 6 | 7 | Документация: 8 | - CAPI: https://docs.python.org/3.13/c-api 9 | 10 | Исходники: 11 | - JIT: https://github.com/python/cpython/tree/main/Tools/jit 12 | - WASM: https://github.com/python/cpython/tree/main/Tools/wasm и https://github.com/psf/webassembly 13 | 14 | ## Практика 15 | 16 | Возьмите [`mypyc`](https://github.com/python/mypy/tree/master/mypyc) и попытайтесь скомпилировать парочку модулей в своем проекте. Замерьте изменения производительности. 17 | Какие модули дают самый большой прирост? (Подсказка: где меньше работы с сетью) 18 | -------------------------------------------------------------------------------- /homeworks/4-bool.md: -------------------------------------------------------------------------------- 1 | ## Теория 2 | 3 | База: 4 | - Почему `all([]) is True` https://buttondown.email/hillelwayne/archive/why-all-is-true-prod-is-1-etc 5 | 6 | Документация: 7 | - https://docs.python.org/3/library/stdtypes.html#typebool 8 | - https://docs.python.org/3/library/stdtypes.html#truth 9 | - https://docs.python.org/3/c-api/bool.html 10 | 11 | Исходники: 12 | - Заголовок: https://github.com/python/cpython/blob/main/Include/boolobject.h и 13 | - Имплементация, включая `_PyTrue_Struct` и `_PyFalseStruct`: https://github.com/python/cpython/blob/main/Objects/boolobject.c 14 | - FlowGraph: https://github.com/python/cpython/blob/main/Python/flowgraph.c 15 | -------------------------------------------------------------------------------- /homeworks/5-None.md: -------------------------------------------------------------------------------- 1 | ## Теория 2 | 3 | База: 4 | - Null References: The Billion Dollar Mistake: https://infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare 5 | 6 | Документация: 7 | - `Py_None`: https://docs.python.org/3/c-api/none.html 8 | - `types.NoneType`: https://docs.python.org/3/library/types.html#types.NoneType 9 | - PEP-505, None-aware operators: https://peps.python.org/pep-0505 10 | 11 | Исходники: 12 | - `None`: https://github.com/python/cpython/blob/42351c3b9a357ec67135b30ed41f59e6f306ac52/Objects/object.c#L2051 13 | - `Maybe`: https://github.com/dry-python/returns 14 | -------------------------------------------------------------------------------- /homeworks/6-float.md: -------------------------------------------------------------------------------- 1 | ## Теория 2 | 3 | База: 4 | - https://standards.ieee.org/ieee/754/4211 и https://standards.ieee.org/ieee/754/6210/ 5 | - https://0.30000000000000004.com 6 | - Как перевести число в `float` / `double`? https://www.wikihow.com/Convert-a-Number-from-Decimal-to-IEEE-754-Floating-Point-Representation и https://class.ece.iastate.edu/arun/CprE281_F05/ieee754/ie2.html 7 | - Опасности float: http://www.indowsway.com/floatingpoint.htm 8 | - Что каждый разработчик должен знать про float? https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html 9 | - Что такое FLOPS: https://ru.wikipedia.org/wiki/FLOPS 10 | 11 | Инструменты: 12 | - Визуализация IEEE754: https://bartaz.github.io/ieee754-visualization и https://www.h-schmidt.net/FloatConverter/IEEE754.html 13 | - Онлайн калькулятор для превращения чисел: https://www.binaryconvert.com/result_double.html 14 | - Калькулятор IEEE754 `+`: http://weitz.de/ieee 15 | 16 | Видео: 17 | - Сложение двух `float`'ов: https://www.youtube.com/watch?v=mKJiD2ZAlwM 18 | 19 | Документация: 20 | - float точность и способы использования: https://docs.python.org/3/tutorial/floatingpoint.html 21 | - `float` тип: https://docs.python.org/3/library/functions.html#float 22 | - `fractions`: https://docs.python.org/3/library/fractions.html 23 | - `sys.float_info`: https://docs.python.org/3/library/sys.html#sys.float_info 24 | - `sys.float_repr_style`: https://docs.python.org/3/library/sys.html#sys.float_repr_style 25 | 26 | Исходники: 27 | - Получение exponent и mantissa из double в glibc: https://git.musl-libc.org/cgit/musl/tree/src/math/frexp.c 28 | - Симуляции `float` на питоне: https://github.com/robclewley/ieee754_simulation 29 | - `floatobject.h`: https://github.com/python/cpython/blob/main/Include/floatobject.h 30 | - `floatobject.c`: https://github.com/python/cpython/blob/main/Objects/floatobject.c 31 | - `dtoa.c`: https://github.com/python/cpython/blob/main/Python/dtoa.c 32 | 33 | Альтернативные реализации: 34 | - https://github.com/mdickinson/bigfloat 35 | 36 | Книги: 37 | - Numerical Computing With IEEE Floating Point Arithmetic: Including One Theorem, One Rule of Thumb, and One Hundred and One Exercises First Edition by Michael L. Overton https://www.amazon.com/Numerical-Computing-Floating-Point-Arithmetic/dp/0898714826 38 | 39 | 40 | ## Практика 41 | 42 | Написать скрипт, который переводит введенное пользователем 43 | число с плавающей точкой в: 44 | 1. float 32x битный формат 45 | 2. double 64х битный формат 46 | 47 | Как пример вывода можно использовать пример со слайда: 48 | 49 | ``` 50 | Number: 85.125 51 | Binary sign: 0 52 | Binary whole part: 1010101 53 | Binary frac part: 001 54 | Binary form: 1010101.001 55 | Exponent: 2**6 56 | Biased exponent: 1029 57 | Binary exponent: 10000000101 58 | Binary mantissa: 010101001 59 | 60 | Final result: 61 | 0 10000000101 0101010010000000000000000000000000000000000000000000 62 | s eeeeeeeeeee mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm 63 | ``` 64 | -------------------------------------------------------------------------------- /homeworks/7-typeshed.md: -------------------------------------------------------------------------------- 1 | ## Теория 2 | 3 | База: 4 | - PEP 561 – Distributing and Packaging Type Information: https://peps.python.org/pep-0561 5 | - `CONTRIBUTING.md` в `typeshed`: https://github.com/python/typeshed/blob/main/CONTRIBUTING.md 6 | 7 | Инструменты: 8 | - `stubtest`: https://mypy.readthedocs.io/en/stable/stubtest.html 9 | - `stubgen`: https://mypy.readthedocs.io/en/stable/stubgen.html 10 | - `stubdefaulter`: https://github.com/JelleZijlstra/stubdefaulter 11 | - `autotyping`: https://github.com/JelleZijlstra/autotyping 12 | - `monkeytype`: https://github.com/Instagram/MonkeyType 13 | - `pytest-monkeytype`: https://github.com/mariusvniekerk/pytest-monkeytype 14 | 15 | Исходники: 16 | - `_typeshed`: https://github.com/python/typeshed/tree/main/stdlib/_typeshed 17 | 18 | 19 | ## Практика 20 | 21 | 1. Зайдите в список задач в `typeshed`: https://github.com/python/typeshed/issues 22 | 2. Выберите задачу для себя 23 | 3. Решите её 24 | 4. Пришлите PR, тегните меня для ревью: `@sobolevn` 25 | -------------------------------------------------------------------------------- /homeworks/8-bytes.md: -------------------------------------------------------------------------------- 1 | ## Теория 2 | 3 | База: 4 | - `bytes-like`: https://docs.python.org/3/glossary.html#term-bytes-like-object 5 | - `bytes`: https://docs.python.org/3/library/stdtypes.html#bytes 6 | - Making the buffer protocol accessible in Python: https://peps.python.org/pep-0688 7 | 8 | Инструменты: 9 | - mypy: bytes и bytearray c `disable_bytearray_promotion` и `disable_memoryview_promotion` https://github.com/python/mypy/commit/2d70ac0b33b448d5ef51c0856571068dd0754af6 10 | 11 | Жесть: 12 | - Мутабельность `bytes` https://docs.python.org/3.13/c-api/bytes.html#c._PyBytes_Resize 13 | - `PyBytes_Writer` API: https://github.com/capi-workgroup/decisions/issues/39 14 | - `ob_shash` deprecation: https://github.com/python/cpython/issues/91020 15 | -------------------------------------------------------------------------------- /homeworks/9-variables.md: -------------------------------------------------------------------------------- 1 | ## Теория 2 | 3 | База: 4 | - Байткод для `LOAD_FAST` и прочего: https://docs.python.org/3/library/dis.html#opcode-LOAD_FAST 5 | - `LOAD_CLOSURE:` https://docs.python.org/3/library/dis.html#opcode-LOAD_CLOSURE 6 | - `UnboundLocalError`: https://docs.python.org/3/library/exceptions.html#UnboundLocalError 7 | - Rules for `global` and `local` variables: https://docs.python.org/3/faq/programming.html#what-are-the-rules-for-local-and-global-variables-in-python 8 | - `locals`: https://docs.python.org/3/library/functions.html#locals 9 | - `globals`: https://docs.python.org/3/library/functions.html#globals 10 | - `Cell` objects: https://docs.python.org/3/c-api/cell.html 11 | - Константы в Python: https://sobolevn.me/2018/07/real-python-contants 12 | -------------------------------------------------------------------------------- /lectures/0-intro.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sobolevn/the-best-python-course/bd5c73f595fd4606b7a8bf1dbce7257fea573b32/lectures/0-intro.key -------------------------------------------------------------------------------- /lectures/1-int.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sobolevn/the-best-python-course/bd5c73f595fd4606b7a8bf1dbce7257fea573b32/lectures/1-int.key -------------------------------------------------------------------------------- /lectures/10-==.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sobolevn/the-best-python-course/bd5c73f595fd4606b7a8bf1dbce7257fea573b32/lectures/10-==.key -------------------------------------------------------------------------------- /lectures/11-bytearray.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sobolevn/the-best-python-course/bd5c73f595fd4606b7a8bf1dbce7257fea573b32/lectures/11-bytearray.key -------------------------------------------------------------------------------- /lectures/12-tuple.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sobolevn/the-best-python-course/bd5c73f595fd4606b7a8bf1dbce7257fea573b32/lectures/12-tuple.key -------------------------------------------------------------------------------- /lectures/13-print.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sobolevn/the-best-python-course/bd5c73f595fd4606b7a8bf1dbce7257fea573b32/lectures/13-print.key -------------------------------------------------------------------------------- /lectures/14-steering-council.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sobolevn/the-best-python-course/bd5c73f595fd4606b7a8bf1dbce7257fea573b32/lectures/14-steering-council.key -------------------------------------------------------------------------------- /lectures/2-+.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sobolevn/the-best-python-course/bd5c73f595fd4606b7a8bf1dbce7257fea573b32/lectures/2-+.key -------------------------------------------------------------------------------- /lectures/3-what-is-python.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sobolevn/the-best-python-course/bd5c73f595fd4606b7a8bf1dbce7257fea573b32/lectures/3-what-is-python.key -------------------------------------------------------------------------------- /lectures/4-bool.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sobolevn/the-best-python-course/bd5c73f595fd4606b7a8bf1dbce7257fea573b32/lectures/4-bool.key -------------------------------------------------------------------------------- /lectures/5-None.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sobolevn/the-best-python-course/bd5c73f595fd4606b7a8bf1dbce7257fea573b32/lectures/5-None.key -------------------------------------------------------------------------------- /lectures/6-float.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sobolevn/the-best-python-course/bd5c73f595fd4606b7a8bf1dbce7257fea573b32/lectures/6-float.key -------------------------------------------------------------------------------- /lectures/7-typeshed.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sobolevn/the-best-python-course/bd5c73f595fd4606b7a8bf1dbce7257fea573b32/lectures/7-typeshed.key -------------------------------------------------------------------------------- /lectures/8-bytes.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sobolevn/the-best-python-course/bd5c73f595fd4606b7a8bf1dbce7257fea573b32/lectures/8-bytes.key -------------------------------------------------------------------------------- /lectures/9-variables.key: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sobolevn/the-best-python-course/bd5c73f595fd4606b7a8bf1dbce7257fea573b32/lectures/9-variables.key -------------------------------------------------------------------------------- /lectures/README.md: -------------------------------------------------------------------------------- 1 | # Здесь выложены слайды лекций 2 | 3 | ## Конвертация Keynote (.key) в PowerPoint (.pptx) или PDF формат через iCloud 4 | 5 | Если у вас нет macOS, а файлы Keynote (.key) открываются некорректно в LibreOffice, можно конвертировать их в PowerPoint (.pptx) с помощью iCloud. Для этого: 6 | 7 | ### Инструкция по конвертации: 8 | 9 | 1. **Зарегистрируйтесь** или **войдите** в iCloud: 10 | Перейдите на [iCloud.com](https://www.icloud.com/) и войдите в свою учетную запись Apple ID. 11 | 12 | 2. **Откройте Keynote в iCloud:** 13 | В главном меню iCloud выберите **Keynote**. 14 | 15 | 3. **Загрузите .key файл:** 16 | - Нажмите на иконку загрузки (`Облако с стрелкой вверх`). 17 | - Выберите файл **.key** со своего компьютера. 18 | - Дождитесь завершения загрузки. 19 | 20 | 4. **Откройте загруженную презентацию:** 21 | Дважды кликните по загруженному файлу, чтобы открыть его в iCloud Keynote. 22 | 23 | 5. **Скачайте файл в формате PowerPoint (.pptx):** 24 | - Нажмите на кнопку `•••` (три точки) в правом верхнем углу. 25 | - Выберите **Загрузить копию** (`Download a Copy`). 26 | - В появившемся окне выберите формат **PowerPoint (.pptx)** или **PDF**. 27 | - Дождитесь завершения конвертации и скачивания файла. 28 | 29 | 6. **Используйте полученный .pptx файл** 30 | Теперь его можно открыть в LibreOffice Impress или Microsoft PowerPoint. 31 | 32 | --- 33 | 34 | После конвертации, если качество отображения слайдов не идеальное, проверьте используемые шрифты и корректность форматирования. 35 | 36 | Если у вас есть идеи по улучшению этого процесса, вы можете отправить Pull Request с предложениями! 37 | -------------------------------------------------------------------------------- /practice/asm-builtins/.editorconfig: -------------------------------------------------------------------------------- 1 | # Check http://editorconfig.org for more information 2 | # This is the main config file for this project: 3 | root = true 4 | 5 | [*] 6 | charset = utf-8 7 | end_of_line = lf 8 | insert_final_newline = true 9 | indent_style = space 10 | indent_size = 2 11 | trim_trailing_whitespace = true 12 | 13 | [*.{py,pyi,c,h}] 14 | indent_size = 4 15 | -------------------------------------------------------------------------------- /practice/asm-builtins/.gitignore: -------------------------------------------------------------------------------- 1 | #### joe made this: https://goel.io/joe 2 | 3 | # Git style-guide: 4 | # https://github.com/agis-/git-style-guide 5 | 6 | #####=== OSX ===##### 7 | .DS_Store 8 | .AppleDouble 9 | .LSOverride 10 | 11 | # Icon must end with two \r 12 | Icon 13 | 14 | 15 | # Thumbnails 16 | ._* 17 | 18 | # Files that might appear on external disk 19 | .Spotlight-V100 20 | .Trashes 21 | 22 | # Directories potentially created on remote AFP share 23 | .AppleDB 24 | .AppleDesktop 25 | Network Trash Folder 26 | Temporary Items 27 | .apdisk 28 | 29 | #####=== Windows ===##### 30 | # Windows image file caches 31 | Thumbs.db 32 | ehthumbs.db 33 | 34 | # Folder config file 35 | Desktop.ini 36 | 37 | # Recycle Bin used on file shares 38 | $RECYCLE.BIN/ 39 | 40 | # Windows Installer files 41 | *.cab 42 | *.msi 43 | *.msm 44 | *.msp 45 | 46 | # Windows shortcuts 47 | *.lnk 48 | 49 | #####=== Python ===##### 50 | 51 | # Byte-compiled / optimized / DLL files 52 | __pycache__/ 53 | *.py[cod] 54 | 55 | # C extensions 56 | *.so 57 | 58 | # Distribution / packaging 59 | .Python 60 | env/ 61 | develop-eggs/ 62 | dist/ 63 | downloads/ 64 | eggs/ 65 | lib/ 66 | lib64/ 67 | parts/ 68 | sdist/ 69 | var/ 70 | *.egg-info/ 71 | .installed.cfg 72 | *.egg 73 | 74 | # PyInstaller 75 | # Usually these files are written by a python script from a template 76 | # before PyInstaller builds the exe, so as to inject date/other infos into it. 77 | *.manifest 78 | *.spec 79 | 80 | # Installer logs 81 | pip-log.txt 82 | pip-delete-this-directory.txt 83 | 84 | # Unit test / coverage reports 85 | htmlcov/ 86 | .tox/ 87 | .coverage 88 | .cache 89 | nosetests.xml 90 | coverage.xml 91 | 92 | # Translations 93 | *.mo 94 | *.pot 95 | 96 | # Django stuff: 97 | *.log 98 | 99 | # Sphinx documentation 100 | docs/_build/ 101 | 102 | # PyBuilder 103 | target/ 104 | 105 | #####=== Sass ===##### 106 | 107 | .sass-cache 108 | *.css.map 109 | 110 | #####=== Yeoman ===##### 111 | 112 | node_modules/ 113 | bower_components/ 114 | *.log 115 | 116 | build/ 117 | dist/ 118 | 119 | #####=== Vagrant ===##### 120 | .vagrant/ 121 | 122 | #####=== Node ===##### 123 | 124 | # Logs 125 | logs 126 | *.log 127 | 128 | # Runtime data 129 | pids 130 | *.pid 131 | *.seed 132 | 133 | # Directory for instrumented libs generated by jscoverage/JSCover 134 | lib-cov 135 | 136 | # Coverage directory used by tools like istanbul 137 | coverage 138 | 139 | # Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) 140 | .grunt 141 | 142 | # node-waf configuration 143 | .lock-wscript 144 | 145 | # Compiled binary addons (http://nodejs.org/api/addons.html) 146 | build/Release 147 | 148 | # Dependency directory 149 | # https://www.npmjs.org/doc/misc/npm-faq.html#should-i-check-my-node_modules-folder-into-git- 150 | node_modules 151 | 152 | # Debug log from npm 153 | npm-debug.log 154 | 155 | #### jetbrains #### 156 | # Covers JetBrains IDEs: IntelliJ, RubyMine, PhpStorm, AppCode, PyCharm, CLion, Android Studio and Webstorm 157 | # Reference: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839 158 | # You can uncomment these lines to enable configuration sharing between 159 | # team members, or you can restrict `.idea/` folder at all (default). 160 | 161 | # User-specific stuff: 162 | # .idea/**/workspace.xml 163 | # .idea/**/tasks.xml 164 | # .idea/dictionaries 165 | 166 | # # Sensitive or high-churn files: 167 | # .idea/**/dataSources/ 168 | # .idea/**/dataSources.ids 169 | # .idea/**/dataSources.xml 170 | # .idea/**/dataSources.local.xml 171 | # .idea/**/sqlDataSources.xml 172 | # .idea/**/dynamic.xml 173 | # .idea/**/uiDesigner.xml 174 | 175 | # # Gradle: 176 | # .idea/**/gradle.xml 177 | # .idea/**/libraries 178 | 179 | # # Mongo Explorer plugin: 180 | # .idea/**/mongoSettings.xml 181 | 182 | # # Cursive Clojure plugin 183 | # .idea/replstate.xml 184 | 185 | # Restrict `.idea/` folder at all: 186 | .idea/ 187 | 188 | # CMake 189 | cmake-build-debug/ 190 | 191 | ## File-based project format: 192 | *.iws 193 | 194 | ## Plugin-specific files: 195 | 196 | # IntelliJ 197 | /out/ 198 | 199 | # mpeltonen/sbt-idea plugin 200 | .idea_modules/ 201 | 202 | # JIRA plugin 203 | atlassian-ide-plugin.xml 204 | 205 | # Crashlytics plugin (for Android Studio and IntelliJ) 206 | com_crashlytics_export_strings.xml 207 | crashlytics.properties 208 | crashlytics-build.properties 209 | fabric.properties 210 | 211 | 212 | #####=== Custom ===##### 213 | # Directories: 214 | media/ 215 | .static/ 216 | /static/ 217 | 218 | # File types: 219 | *.sqlite3 220 | *.db 221 | 222 | # Configuration file with private data: 223 | *.env 224 | .env 225 | 226 | # Local settings files: 227 | *local.py 228 | 229 | # Deploy files for Docker: 230 | docker-compose.deploy.yml 231 | 232 | # Certificates: 233 | docker/caddy/certs/ 234 | 235 | # Artifacts: 236 | .gitlab/.svn/ 237 | artifacts/ 238 | 239 | # mypy: 240 | .mypy_cache/ 241 | 242 | # pytest and hypothesis 243 | .pytest_cache/ 244 | .hypothesis/ 245 | 246 | # ipython: 247 | .ipython/ 248 | 249 | # ruff: 250 | .ruff_cache/ 251 | 252 | # import-linter: 253 | .import_linter_cache/ 254 | 255 | # safety: 256 | .safety/ 257 | -------------------------------------------------------------------------------- /practice/asm-builtins/README.md: -------------------------------------------------------------------------------- 1 | # Builtins implemented in x86_64 ASM 2 | 3 | Reimplements some parts of the Python's builtins but in ASM. Currently supports: 4 | - `builtins.print`, which calls `sys_write` syscall with x86_64 ASM directly from C 5 | 6 | Why? Because I am bored. I created this just for fun for a video in my [the-best-python-course](https://github.com/sobolevn/the-best-python-course). 7 | 8 | Please, don't use this! 9 | 10 | 11 | ## Usage 12 | 13 | ```python 14 | >>> import asm_builtins 15 | 16 | >>> asm_builtins.print("hello", "world") 17 | "hello world" 18 | ``` 19 | 20 | 😱 21 | 22 | 23 | ## Install 24 | 25 | Clone this locally, `cd` into this folder and then: 26 | 27 | ```bash 28 | pip install . 29 | ``` 30 | 31 | 32 | ## License 33 | 34 | [WTFPL](https://en.wikipedia.org/wiki/WTFPL) 35 | -------------------------------------------------------------------------------- /practice/asm-builtins/asm_builtins/mod.c: -------------------------------------------------------------------------------- 1 | // TODO: possibly support other platforms and archs. 2 | #if !defined(__x86_64__) || !defined(linux) 3 | #error "This module only supports x86_64 Linux for now." 4 | #endif 5 | 6 | #include 7 | 8 | static long 9 | sys_write_call(const char *msg, Py_ssize_t size) 10 | { 11 | // TODO: allow to pass `fd` as `print(file=...)` does. 12 | long ret; 13 | asm volatile ( 14 | // TODO: convert this ugly AT&T ASM into beautiful Intel one: 15 | "mov $1, %%rax\n" // sys_write call number 16 | "mov $1, %%rdi\n" // stdout=1 and stderr=2 17 | "mov %1, %%rsi\n" // `msg` address 18 | "mov %2, %%rdx\n" // `msg_len` 19 | "syscall\n" 20 | "mov %%rax, %0\n" // save the result 21 | : "=r"(ret) 22 | : "r"(msg), "r"(size) // inputs 23 | : "rax", "rdi", "rsi", "rdx" // changed registers 24 | ); 25 | 26 | // TODO: maybe handle special cases like `EINTR` 27 | return ret; 28 | } 29 | 30 | static PyObject * 31 | print(PyObject *self, PyObject *args) 32 | { 33 | // Don't expect much from this funny demo. 34 | // It does not support buffering, flushing, different `end` and `sep`. 35 | // It also does not support correct `stdout` captures and `file=` arguments. 36 | // This is just for fun. 37 | 38 | // TODO: this should be customizable 39 | const char *sep = " "; 40 | // TODO: this should be customizable, just like in CPython. 41 | const char *end = "\n"; 42 | 43 | Py_ssize_t len = PyTuple_GET_SIZE(args); 44 | 45 | for (Py_ssize_t i = 0; i < len; i++) { 46 | PyObject *value = PyObject_Str(PyTuple_GET_ITEM(args, i)); 47 | if (value == NULL) { 48 | goto error; 49 | } 50 | 51 | Py_ssize_t size; 52 | const char* msg = PyUnicode_AsUTF8AndSize(value, &size); 53 | Py_DECREF(value); 54 | if (msg == NULL) { 55 | goto error; 56 | } 57 | 58 | // Write our data with the syscall! 59 | // It is slow, bug prone, not portable, but it is cool! 60 | if (sys_write_call(msg, size) < 0) { 61 | goto write_error; 62 | } 63 | 64 | // Now print the separator, if there are still elements in args. 65 | if (i < len - 1) { 66 | if (sys_write_call(sep, strlen(sep)) < 0) { 67 | goto write_error; 68 | } 69 | } 70 | else if (i == len - 1) { 71 | // Now, print the end of the string, 72 | // which is the newline char by default. 73 | if (sys_write_call(end, strlen(end)) < 0) { 74 | goto write_error; 75 | } 76 | } 77 | } 78 | 79 | Py_RETURN_NONE; 80 | 81 | write_error: 82 | PyErr_SetString(PyExc_OSError, "sys_write_call failed with no recover"); 83 | 84 | error: 85 | return NULL; 86 | } 87 | 88 | PyDoc_STRVAR(print__doc__, 89 | "print($module, /, *args)\n" 90 | "--\n" 91 | "\n" 92 | "Print passed args as strings."); 93 | 94 | 95 | static PyMethodDef module_methods[] = { 96 | // TODO: also support `input` 97 | {"print", (PyCFunction)print, METH_VARARGS, print__doc__}, 98 | {NULL} // sentinel 99 | }; 100 | 101 | 102 | static struct PyModuleDef asm_builtins_spec = { 103 | PyModuleDef_HEAD_INIT, 104 | "asm_builtins", 105 | PyDoc_STR("Builtins re-implemented in ASM"), 106 | -1, 107 | module_methods 108 | }; 109 | 110 | 111 | PyMODINIT_FUNC PyInit_asm_builtins(void) { 112 | return PyModule_Create(&asm_builtins_spec); 113 | } 114 | -------------------------------------------------------------------------------- /practice/asm-builtins/pyproject.toml: -------------------------------------------------------------------------------- 1 | [build-system] 2 | requires = ["setuptools>=74.1"] 3 | build-backend = "setuptools.build_meta" 4 | 5 | [project] 6 | name = "asm_builtins" 7 | description = "Builtins rewrite in ASM" 8 | version = "0.1.0" 9 | 10 | [tool.setuptools] 11 | ext-modules = [ 12 | { name = "asm_builtins", sources = ["asm_builtins/mod.c"] } 13 | ] 14 | -------------------------------------------------------------------------------- /streaming/film_default.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sobolevn/the-best-python-course/bd5c73f595fd4606b7a8bf1dbce7257fea573b32/streaming/film_default.png --------------------------------------------------------------------------------