|
29 | 29 |
|
30 | 30 | ---- |
31 | 31 |
|
32 | | -.. _project-structure: |
| 32 | +.. _definations: |
33 | 33 |
|
34 | | -ساختار پروژه |
| 34 | +تعاریف |
35 | 35 | -------------- |
36 | 36 |
|
37 | 37 | سورس کد یک پروژه به زبان پایتون در قالب یک یا چند «ماژول» (Module) توسعه مییابد که در سورس کدهایی با بیش از یک ماژول بهتر است ماژولهایی که از نظر منطقی با یکدیگر مرتبط هستند را درون دایرکتوریهایی مجزا قرار دهیم که به این نوع دایرکتوریها در زبان پایتون «بسته» (Package) گفته میشود. |
|
40 | 40 | یک یا چند ماژول درون یک دایرکتوری مشخص تشکیل یک بسته را میدهند و هر بسته خود میتواند حاوی بسته(های) دیگری باشد. |
41 | 41 |
|
42 | 42 | .. note:: |
43 | | - از نسخه 3.3 پایتون با افزوده شدن ویژگی جدیدی به نام «بسته فضانام» (Namespace Package - `PEP 420 <http://www.python.org/dev/peps/pep-0420>`_)، تعریف بسته پایتون به دو شاخه «بسته عادی» (Regular Package) که همان تعریف قدیمی از بسته میباشد و بسته فضانام گسترش یافته است. در انتهای این درس به تفاوت این دو بسته پرداخته خواهد شد. |
| 43 | + از نسخه 3.3 پایتون با افزوده شدن ویژگی جدیدی به نام «بسته فضانام» (Namespace Package - `PEP 420 <http://www.python.org/dev/peps/pep-0420>`_)، تعریف بسته پایتون به دو شاخه «بسته عادی» (Regular Package) که همان تعریف قدیمی از بسته میباشد و بسته فضانام گسترش یافته است. |
| 44 | + |
| 45 | + در واقع، تا قبل از پایتون 3.3 هر بسته پایتون میبایست حاوی یک فایل ``init__.py__`` باشد ولی اکنون نیازی به این فایل نیست و مفسر پایتون اکنون میتواند تمامی بستههای داخل پروژه را محل یابی کند. در این درس به منظور شفافسازی بستهها از روش Regular Package استفاده خواهد شد. |
44 | 46 |
|
45 | 47 | در تعریف زبان پایتون دو نوع ماژول وجود دارد: |
46 | 48 |
|
47 | | -۱- Pure Module (ماژول عادی)، همان تعریف عادی از ماژول پایتون است؛ فایلهایی با پسوند py که کد (تعاریف و دستورات) پایتون در آنها نوشته میشوند. |
| 49 | +۱- Pure Module (ماژول عادی)، همان تعریف عادی از ماژول پایتون است؛ فایلهایی با پسوند py که کد (تعاریف و دستورات) به زبان پایتون در آنها نوشته میشود. |
48 | 50 |
|
49 | | -۲- Extension Module (ماژول توسعه)، ماژولهایی که توسط زبانهای برنامهنویسی دیگری به غیر از پایتون ایجاد شدهاند. از درس یکم به خاطر داریم که پایتون یک زبان توسعهپذیر است و در کنار آن میتوان از کدهای نوشته شده با دیگر زبانهای برنامهنویسی استفاده نمود: به مانند C و ++C در پیادهسازی CPython یا Java در پیادهسازی Jython یا #C در پیادهسازی IronPython - بررسی این نوع ماژول خارج از حوزه این کتاب است. در صورت علاقه برای مطالعه بیشتر میتوانید به مستندات پایتون مراجعه (`Python/C API Reference <https://docs.python.org/3/c-api/index.html>`_) یا کتاب Python 3.6 Extending and Embedding Python نوشته Guido Van Rossum را تهیه نمایید. |
| 51 | +۲- Extension Module (ماژول توسعه)، ماژولهایی که توسط زبانهای برنامهنویسی دیگری به غیر از پایتون تهیه شدهاند. از درس یکم به خاطر داریم که پایتون یک زبان توسعهپذیر است و در کنار آن میتوان از کدهای نوشته شده با دیگر زبانهای برنامهنویسی استفاده نمود: به مانند C و ++C در پیادهسازی CPython یا Java در پیادهسازی Jython یا #C در پیادهسازی IronPython - بررسی این نوع ماژول خارج از حوزه این کتاب است. در صورت علاقه برای مطالعه بیشتر میتوانید به مستندات پایتون مراجعه (`Python/C API Reference <https://docs.python.org/3/c-api/index.html>`_) یا کتاب Python 3.6 Extending and Embedding Python نوشته Guido Van Rossum را تهیه نمایید. |
50 | 52 |
|
51 | 53 | .. note:: |
52 | 54 | از این پس هر جایی از این کتاب که گفته شود «ماژول» منظور Pure Module خواهد بود، مگر اینکه نام «ماژول توسعه» به صراحت ذکر گردد. |
53 | 55 |
|
54 | | -در ایجاد یک پروژه از پایتون هیچ اجباری به رعایت ساختار خاصی نیست و حتی سورس کد یک پروژه میتواند تنها شامل یک ماژول باشد. به عنوان نمونه، شمای پایین از پروژه فرضی SampleProject را در نظر بگیرید: |
| 56 | +در ایجاد یک پروژه از پایتون هیچ اجباری به رعایت ساختار خاصی نیست و سورس کد یک پروژه میتواند تنها شامل یک ماژول (فایل با پسوند py.) باشد. به عنوان نمونه، شمای پایین از پروژه فرضی SampleProject را در نظر بگیرید: |
55 | 57 |
|
56 | 58 | .. code:: |
57 | 59 | |
58 | 60 | SampleProject |
59 | 61 | . |
60 | 62 | ├── sample_project.py |
61 | | - ├── module_one.py |
62 | 63 | └── pakage/ |
63 | 64 | ├── __init__.py |
64 | 65 | ├── module_two.py |
65 | | - └── module_three.py |
| 66 | + └── module_one.py |
66 | 67 |
|
67 | 68 | .. tip:: |
68 | | - در پایتون هر **بسته عادی** میبایست حاوی فایل ویژه init\_\_.py_\_\ باشد که البته الزامی به کدنویسی درون این فایل وجود ندارد. این فایل دایرکتوری خود را به عنوان یک بسته (محلی برای یافتن ماژولهای مرتبط) به مفسر پایتون معرفی میکند. |
| 69 | + در پایتون هر **Regular Package** میبایست حاوی فایل ویژه ``init__.py__`` باشد که البته الزامی به کدنویسی درون این فایل وجود ندارد. این فایل دایرکتوری خود را به عنوان یک بسته (محلی برای یافتن ماژولهای مرتبط) به مفسر پایتون معرفی میکند. |
69 | 70 |
|
70 | | -در ایجاد سورس کد باید به صورتی عمل شود که با اجرای یک ماژول مشخص تمام برنامه اجرا گردد. این ماژول معمولا هم نام پروژه در نظر گرفته و با عنوان «اسکریپت» (Script) از آن یاد میشود (اینجا: sample_project.py). در واقع اسکریپت، ماژولی است که با هدف اجرای برنامه توسعه مییابد و ایجاد سورس کد نیز از آن شروع میگردد. از طرفی همانطور که میدانیم یکی از ویژگیهای پایتون امکان برنامه نویسی ماژولار (`Modular <http://en.wikipedia.org/wiki/Modular_programming>`_) است به این صورت که میتوان کدهای خود را بر حسب نیاز در ماژولهایی جداگانه نوشت و با وارد کردن (Import) آنها در اسکریپت (یا ماژولهای دیگر) از کد درون آنها استفاده نمود. با این منطق میشود سورس کد یک پروژه از پایتون را تنها شامل یک اسکریپت تصور کرد که میتواند توسط تعدادی ماژول گسترش یابد؛ البته ممکن است ماژولها نیز بر حسب نیاز در بستههایی جداگانه قرار گرفته باشند. |
| 71 | +در ایجاد سورس کد باید به صورتی عمل شود که با اجرای یک ماژول مشخص تمام برنامه اجرا گردد. این ماژول معمولا هم نام پروژه در نظر گرفته و با عنوان «اسکریپت» (Script) از آن یاد میشود (اینجا: sample_project.py). در واقع اسکریپت، ماژولی است که با هدف اجرای برنامه توسعه مییابد و ایجاد سورس کد نیز از آن شروع میگردد. |
71 | 72 |
|
72 | 73 | .. tip:: |
73 | | - [`PEP 8 <http://www.python.org/dev/peps/pep-0008/>`_]: در نامگذاری ماژولها تنها از حروف کوچک استفاده میشود و در صورت نیاز میتوان از کاراکتر خط زیرین (``_``) نیز استفاده نمود. نام بستهها کوتاه بوده و از حروف کوچک تشکیل میگردد؛ استفاده از ``_`` در نام بسته پیشنهاد نمیشود. |
74 | | - |
75 | | -اکنون اطلاعات کافی برای شروع یک پروژه از پایتون را دارید ولی چنانچه میخواهید با ساختار مناسب پروژهای که قرار است برای استفاده افراد دیگر از طریق PyPI یا سرویسهایی نظیر github.com منتشر شود (مانند یک کتابخانه کاربردی) آشنا شوید، ادامه این بخش را نیز مطالعه نمایید. در غیر این صورت میتوانید به بخش بعدی از همین درس `پرش <#source-code>`_ نمایید. |
76 | | - |
77 | | -جدا از سورس کد لازم است موارد دیگری نیز در ساختار این نوع پروژهها در نظر گرفته شود؛ به ساختار پایین توجه نمایید: |
78 | | - |
79 | | - |
80 | | -.. code:: |
81 | | - |
82 | | - my_project |
83 | | - . |
84 | | - ├── pyproject.toml |
85 | | - │ |
86 | | - ├── LICENSE.txt |
87 | | - ├── README.rst |
88 | | - ├── requirements.txt |
89 | | - │ |
90 | | - ├── src/ |
91 | | - │ └── unique_pakage_name/ |
92 | | - │ ├── __init__.py |
93 | | - │ └── main.py |
94 | | - │ |
95 | | - ├── docs/ |
96 | | - └── test/ |
97 | | -
|
98 | | -
|
99 | | -ساختار ابتدایی تنها شامل سورس کد میبود ولی در این ساختار تمام سورس کد در قالب یک بسته پایتون بخشی از مجموعه بزرگتری است که در آن یک سری فایل به مانند requirements.txt ،README.rst و pyproject.toml افزوده شده است. تاکید میشود که در حال حاضر نیازی به رعایت این ساختار و ایجاد تمامی این فایلها نیست. |
100 | | - |
101 | | -اکنون می توان از روی این پروژه یک توزیع (Distribution) ایجاد و آن را با استفاده از ابزارهایی به مانند `Twine <https://twine.readthedocs.io/en/stable/>`_ یا `Poetry <https://python-poetry.org/>`_ بر روی PyPI منتشر ساخت. [برای کسب اطلاعات بیشتر میتوانید از `اسناد پایتون <https://packaging.python.org/en/latest/tutorials/packaging-projects/>`_ استفاده نمایید] |
102 | | - |
103 | | -در صورت علاقه میتوانید نگاهی نیز به پروژه `saeiddrv/PackagingPythonProjects <https://github.com/saeiddrv/PackagingPythonProjects>`_ بیاندازید که تمامی مراحل را به صورت کاربردی پیادهسازی کرده است. |
| 74 | + هر پروژه پایتون باید حاوی یک و تنها یک اسکریپت باشد ولی میتواند هیچ، یک یا چند ماژول داشته باشد که این ماژولها نیز میتوانند در قالب بستههایی جداگانه سازماندهی شوند. |
104 | 75 |
|
| 76 | +.. tip:: |
| 77 | + [`PEP 8 <http://www.python.org/dev/peps/pep-0008/>`_]: در نامگذاری ماژولها تنها از حروف کوچک استفاده میشود و در صورت نیاز میتوان از کاراکتر خط زیرین (``_``) نیز استفاده نمود (اما پیشنهاد نمیشود). نام بستهها کوتاه بوده و از حروف کوچک تشکیل میگردد. |
105 | 78 |
|
106 | 79 | .. _source-code: |
107 | 80 |
|
|
280 | 253 | IDE یا Integrated development environment به ابزارهایی گفته میشود که علاوهبر یک ویرایشگر متن پیشرفته، امکانات بسیار کاربردی دیگری را نیز به مانند دیباگر (`Debugger <https://en.wikipedia.org/wiki/Debugger>`__) در اختیار برنامهنویس قرار میدهد. |
281 | 254 |
|
282 | 255 |
|
| 256 | +.. _python-import: |
| 257 | + |
| 258 | +دستور import |
| 259 | +--------------- |
| 260 | + |
| 261 | + |
| 262 | + |
283 | 263 | پشت صحنه اجرا |
284 | 264 | --------------- |
285 | 265 | زمانی که اقدام به اجرای یک اسکریپت میکنید؛ ابتدا، اسکریپت و تمام ماژولهای وارد شده در آن به بایتکد کامپایل و سپس بایتکدهای حاصل جهت تفسیر به زبان ماشین و اجرا، به ماشین مجازی فرستاده میشوند. آنچه ما از آن به عنوان مفسر پایتون (پیادهسازی CPython) یاد میکنیم در واقع ترکیبی از یک کامپایلر و یک ماشین مجازی است. تصویر پایین به خوبی روند اجرای کدهای پایتون را نمایش میدهد. |
@@ -420,6 +400,44 @@ pyvenv |
420 | 400 | > |
421 | 401 |
|
422 | 402 |
|
| 403 | +.. _packaging-projects: |
| 404 | + |
| 405 | +انتشار پروژه |
| 406 | +-------------- |
| 407 | + |
| 408 | + |
| 409 | +اکنون اطلاعات کافی برای شروع یک پروژه از پایتون را دارید ولی چنانچه میخواهید با ساختار مناسب پروژهای که قرار است برای استفاده افراد دیگر از طریق PyPI یا سرویسهایی نظیر github.com منتشر شود (مانند یک کتابخانه کاربردی) آشنا شوید، ادامه این بخش را نیز مطالعه نمایید. در غیر این صورت میتوانید به بخش بعدی از همین درس `پرش <#source-code>`_ نمایید. |
| 410 | + |
| 411 | +جدا از سورس کد لازم است موارد دیگری نیز در ساختار این نوع پروژهها در نظر گرفته شود؛ به ساختار پایین توجه نمایید: |
| 412 | + |
| 413 | + |
| 414 | +.. code:: |
| 415 | + |
| 416 | + my_project |
| 417 | + . |
| 418 | + ├── pyproject.toml |
| 419 | + │ |
| 420 | + ├── LICENSE.txt |
| 421 | + ├── README.rst |
| 422 | + ├── requirements.txt |
| 423 | + │ |
| 424 | + ├── src/ |
| 425 | + │ └── unique_pakage_name/ |
| 426 | + │ ├── __init__.py |
| 427 | + │ └── main.py |
| 428 | + │ |
| 429 | + ├── docs/ |
| 430 | + └── test/ |
| 431 | +
|
| 432 | +
|
| 433 | +ساختار ابتدایی تنها شامل سورس کد میبود ولی در این ساختار تمام سورس کد در قالب یک بسته پایتون بخشی از مجموعه بزرگتری است که در آن یک سری فایل به مانند requirements.txt ،README.rst و pyproject.toml افزوده شده است. تاکید میشود که در حال حاضر نیازی به رعایت این ساختار و ایجاد تمامی این فایلها نیست. |
| 434 | + |
| 435 | +اکنون می توان از روی این پروژه یک توزیع (Distribution) ایجاد و آن را با استفاده از ابزارهایی به مانند `Twine <https://twine.readthedocs.io/en/stable/>`_ یا `Poetry <https://python-poetry.org/>`_ بر روی PyPI منتشر ساخت. [برای کسب اطلاعات بیشتر میتوانید از `اسناد پایتون <https://packaging.python.org/en/latest/tutorials/packaging-projects/>`_ استفاده نمایید] |
| 436 | + |
| 437 | +در صورت علاقه میتوانید نگاهی نیز به پروژه `saeiddrv/PackagingPythonProjects <https://github.com/saeiddrv/PackagingPythonProjects>`_ بیاندازید که تمامی مراحل را به صورت کاربردی پیادهسازی کرده است. |
| 438 | + |
| 439 | + |
| 440 | + |
423 | 441 | | |
424 | 442 |
|
425 | 443 | ---- |
|
0 commit comments