2.1.1. سطرهای منطقی¶

پایان یک خط منطقی با توکن NEWLINE نمایش داده می‌شود. دستورها نمی‌توانند از مرزهای سطر منطقی عبور کنند، مگر در مواردی که NEWLINE از نظر سینتکس مجاز باشد (مثلاً بین دستورها در دستورهای مرکب). یک خط منطقی از یک یا چند خط فیزیکی با پیروی از قواعد اتصال خط صریح یا ضمنی تشکیل می‌شود.

2.1.2. سطرهای فیزیکی¶

یک خط فیزیکی، دنباله‌ای از نویسه‌ها است که با یکی از دنباله‌های پایان خط زیر پایان می‌یابد:

• قالب یونیکسی با استفاده از ASCII LF (خط جدید)،

• شکل ویندوزی با استفاده از دنباله‌ی ASCII یعنی CR LF (بازگشت به دنبال خط جدید)،

• قالب «Classic Mac OS» که از نویسه‌ی ASCII CR (return) استفاده می‌کند.

صرف‌نظر از سکو، هر یک از این دنباله‌ها با یک نویسه‌ی ASCII LF (linefeed) جایگزین می‌شود. (این کار حتی در داخل string literals نیز انجام می‌شود.) هر خط می‌تواند از هر یک از این دنباله‌ها استفاده کند؛ لازم نیست که این دنباله‌ها در یک پرونده یکدست باشند.

پایان ورودی همچنین به‌عنوان پایان‌دهنده‌ای ضمنی برای آخرین خط فیزیکی عمل می‌کند.

به‌صورت رسمی:

newline: <ASCII LF> | <ASCII CR> <ASCII LF> | <ASCII CR>

2.1.3. کامنت‌ها¶

یک کامنت با نویسه‌ی هش (#) که بخشی از یک رشته‌ی لفظی نیست، آغاز می‌شود و در پایان خط فیزیکی تمام می‌شود. یک کامنت نشان‌دهنده‌ی پایان خط منطقی است، مگر اینکه قواعد پیوستن ضمنی سطرهای اعمال شوند. کامنت‌ها توسط سینتکس نادیده گرفته می‌شوند.

2.1.4. اعلامیه‌های کدگذاری¶

اگر یک کامنت در خط اول یا دوم اسکریپت پایتون با عبارت باقاعده coding[=:]\s*([-\w.]+) مطابقت داشته باشد، این کامنت به‌عنوان یک اعلامیه کدگذاری پردازش می‌شود؛ اولین گروه این عبارت، کدگذاری پرونده کد منبع را مشخص می‌کند. اعلامیه کدگذاری باید در خط جداگانه‌ای قرار گیرد. اگر در خط دوم باشد، خط اول نیز باید تنها شامل کامنت باشد. شکل‌های توصیه‌شده برای عبارت کدگذاری عبارتند از

# -*- coding: <encoding-name> -*-

که GNU Emacs نیز آن را شناسایی می‌کند، و

# vim:fileencoding=<encoding-name>

که توسط VIM متعلق به Bram Moolenaar شناسایی می‌شود.

اگر هیچ اعلان کدگذاری یافت نشود، کدگذاری پیش‌فرض UTF-8 است. اگر کدگذاری ضمنی یا صریح یک پرونده UTF-8 باشد، یک نشانگر ترتیب بایت (byte-order mark) اولیه‌ی UTF-8 (b'\xef\xbb\xbf') به‌جای اینکه خطای سینتکس باشد، نادیده گرفته می‌شود.

اگر کدگذاری اعلام‌شده باشد، نام کدگذاری باید توسط پایتون شناخته شود (به کدگذاری‌های استاندارد مراجعه کنید). از این کدگذاری برای تمام تحلیل واژگانی، از جمله رشته‌های لفظی، کامنت‌ها و شناسه‌ها استفاده می‌شود.

تمام تحلیل واژگانی، شامل مقادیر لفظی رشته، کامنت‌ها و شناسه‌ها، روی متن یونیکد کدگشایی‌شده با کدگذاری منبع انجام می‌شود. هر نقطه کد یونیکد، به‌جز نویسه کنترلی NUL، می‌تواند در منبع پایتون ظاهر شود.

source_character:  <any Unicode code point, except NUL>

2.1.5. پیوند صریح سطرهای¶

دو یا چند خط فیزیکی را می‌توان با استفاده از نویسه‌های بک‌اسلش (\) به هم پیوست کرد تا سطرهای منطقی تشکیل شوند، به این صورت: هرگاه یک خط فیزیکی با بک‌اسلشی پایان یابد که بخشی از یک لفظی رشته یا کامنت نیست، با خط بعدی پیوسته می‌شود و یک خط منطقی واحد را تشکیل می‌دهد؛ در این حالت بک‌اسلش و نویسه‌ی پایان خط بعدی حذف می‌شوند. برای مثال:

if 1900 < year < 2100 and 1 <= month <= 12 \
   and 1 <= day <= 31 and 0 <= hour < 24 \
   and 0 <= minute < 60 and 0 <= second < 60:   # Looks like a valid date
        return 1

سطری که با بک‌اسلش پایان می‌یابد، نمی‌تواند حاوی یک کامنت باشد. بک‌اسلش یک کامنت را ادامه نمی‌دهد. بک‌اسلش یک توکن را ادامه نمی‌دهد، مگر در مورد رشته‌های لفظی (یعنی توکن‌هایی غیر از رشته‌های لفظی نمی‌توانند با استفاده از بک‌اسلش بین سطرهای فیزیکی شکسته شوند). بک‌اسلش در هر جای دیگری از یک خط، خارج از یک رشته‌ی لفظی، غیرمجاز است.

2.1.6. پیوند ضمنی سطرهای¶

عبارات داخل پرانتز، کروشه یا آکولاد را می‌توان بدون استفاده از بک‌اسلش در بیش از یک خط فیزیکی تقسیم کرد. برای مثال:

month_names = ['Januari', 'Februari', 'Maart',      # These are the
               'April',   'Mei',      'Juni',       # Dutch names
               'Juli',    'Augustus', 'September',  # for the months
               'Oktober', 'November', 'December']   # of the year

سطرهای ادامه‌یافته به‌صورت ضمنی می‌توانند حاوی کامنت باشند. تورفتگی سطرهای ادامه مهم نیست. سطرهای ادامه خالی مجاز هستند. بین سطرهای ادامه ضمنی هیچ توکن NEWLINE وجود ندارد. سطرهای ادامه‌یافته به‌صورت ضمنی همچنین می‌توانند درون رشته‌های سه‌نقل‌قولی (در ادامه ببینید) رخ دهند؛ در این حالت نمی‌توانند حاوی کامنت باشند.

2.1.7. سطرهای خالی¶

یک خط منطقی که فقط شامل فاصله‌ها، تب‌ها، تغذیه‌های صفحه (formfeeds) و احتمالاً یک کامنت باشد، نادیده گرفته می‌شود (یعنی هیچ توکن NEWLINE تولید نمی‌شود). در حین ورودی تعاملی دستورها، پردازش یک خط خالی ممکن است بسته به پیاده‌سازی حلقه‌ی خواندن-ارزیابی-چاپ (read-eval-print loop) متفاوت باشد. در مفسر تعاملی استاندارد، یک خط منطقی کاملاً خالی (یعنی سطری که حتی شامل هیچ نویسه‌ی خالی یا کامنتی هم نباشد) یک دستور چندخطی را پایان می‌دهد.

2.1.8. تورفتگی¶

فضای سفید ابتدایی (فاصله‌ها و تب‌ها) در آغاز یک خط منطقی، برای محاسبه‌ی سطح تورفتگی آن خط استفاده می‌شود، که به نوبه‌ی خود برای تعیین گروه‌بندی دستورات به کار می‌رود.

تب‌ها (از چپ به راست) با ۱ تا ۸ فاصله جایگزین می‌شوند، به‌گونه‌ای که تعداد کل نویسه‌ها تا پایان جایگزینی، مضربی از ۸ باشد (هدف این است که همان قاعده‌ای باشد که در یونیکس استفاده می‌شود). سپس تعداد کل فاصله‌های پیش از اولین نویسه‌ی غیرسفید، تورفتگی خط را تعیین می‌کند. تورفتگی را نمی‌توان با استفاده از بک‌اسلش‌ها به چند خط فیزیکی تقسیم کرد؛ فضای سفید تا اولین بک‌اسلش، تورفتگی را تعیین می‌کند.

اگر یک پرونده منبع تب‌ها و فاصله‌ها را به‌گونه‌ای با هم ترکیب کند که معنا به ارزش یک تب بر حسب فاصله وابسته باشد، تورفتگی به‌عنوان ناسازگار رد می‌شود؛ در این صورت یک TabError پرتاب می‌شود.

یادداشت سازگاری بین‌سکویی: به دلیل ماهیت ویرایشگرهای متن در سکوهای غیر UNIX، استفاده از ترکیبی از فاصله‌ها و تب‌ها برای تورفتگی در یک پرونده منبع واحد، عاقلانه نیست. همچنین باید توجه داشت که سکوهای مختلف ممکن است به‌صراحت حداکثر سطح تورفتگی را محدود کنند.

ممکن است یک نویسه‌ی تغذیه‌ی صفحه (formfeed) در ابتدای خط وجود داشته باشد؛ این نویسه در محاسبات تورفتگی ذکرشده در بالا نادیده گرفته می‌شود. نویسه‌های تغذیه‌ی صفحه (formfeed) که در جاهای دیگر فضای سفید ابتدای خط قرار دارند، اثر تعریف‌نشده‌ای دارند (برای نمونه، ممکن است تعداد فاصله‌ها را به صفر بازنشانی کنند).

سطوح تورفتگی سطرهای متوالی، با استفاده از یک پشته، به شرح زیر برای تولید توکن‌های INDENT و DEDENT استفاده می‌شوند.

پیش از آنکه نخستین خط پرونده خوانده شود، یک صفر روی پشته قرار می‌گیرد؛ این صفر هرگز دوباره از پشته برداشته نخواهد شد. اعدادی که روی پشته قرار می‌گیرند، همیشه از پایین به بالا به‌طور اکید صعودی خواهند بود. در آغاز هر خط منطقی، سطح تورفتگی آن خط با بالای پشته مقایسه می‌شود. اگر برابر باشد، هیچ اتفاقی نمی‌افتد. اگر بزرگ‌تر باشد، روی پشته قرار می‌گیرد و یک توکن INDENT تولید می‌شود. اگر کوچک‌تر باشد، باید یکی از اعداد موجود روی پشته باشد؛ تمام اعداد بزرگ‌تر روی پشته برداشته می‌شوند و به ازای هر عدد برداشته‌شده، یک توکن DEDENT تولید می‌شود. در پایان پرونده، به ازای هر عدد باقی‌مانده روی پشته که بزرگ‌تر از صفر باشد، یک توکن DEDENT تولید می‌شود.

در اینجا نمونه‌ای از یک قطعه کد پایتون با تورفتگی صحیح (هرچند گیج‌کننده) آمده است:

def perm(l):
        # Compute the list of all permutations of l
    if len(l) <= 1:
                  return [l]
    r = []
    for i in range(len(l)):
             s = l[:i] + l[i+1:]
             p = perm(s)
             for x in p:
              r.append(l[i:i+1] + x)
    return r

مثال زیر خطاهای مختلف تورفتگی را نشان می‌دهد:

 def perm(l):                       # error: first line indented
for i in range(len(l)):             # error: not indented
    s = l[:i] + l[i+1:]
        p = perm(l[:i] + l[i+1:])   # error: unexpected indent
        for x in p:
                r.append(l[i:i+1] + x)
            return r                # error: inconsistent dedent

(در واقع، سه خطای اول توسط پارسر تشخیص داده می‌شوند؛ تنها آخرین خطا توسط تحلیل‌گر واژگانی (lexical analyzer) پیدا می‌شود --- تورفتگی return r با سطحی که از پشته برداشته شده است مطابقت ندارد.)

2.1.9. فضای سفید بین توکن‌ها¶

به‌جز در ابتدای یک خط منطقی یا در رشته‌های لفظی (string literals)، می‌توان از نویسه‌های فضای خالی یعنی فاصله، تب و تغذیه‌ی صفحه (formfeed) برای جدا کردن توکن‌ها به‌جای یکدیگر استفاده کرد:

whitespace:  ' ' | tab | formfeed

فضای سفید تنها زمانی بین دو توکن لازم است که در نبود آن، الحاق آن‌ها بتواند به‌عنوان یک توکن متفاوت تفسیر شود. برای مثال، ab یک توکن است، اما a b دو توکن است. با این حال، +a و + a هر دو، دو توکن + و a را تولید می‌کنند، زیرا +a یک توکن معتبر نیست.

2.1.10. نشانگر پایان¶

در پایان ورودی غیرتعاملی، تحلیل‌گر واژگانی یک توکن ENDMARKER تولید می‌کند.

2.3.1. کلیدواژه‌ها¶

نام‌های زیر به‌عنوان واژه‌های رزروشده، یا کلیدواژه‌های زبان، استفاده می‌شوند و نمی‌توان از آن‌ها به‌عنوان شناسه‌های عادی استفاده کرد. آن‌ها باید دقیقاً به همان شکلی که اینجا نوشته شده‌اند، نوشته شوند:

False      await      else       import     pass
None       break      except     in         raise
True       class      finally    is         return
and        continue   for        lambda     try
as         def        from       nonlocal   while
assert     del        global     not        with
async      elif       if         or         yield

2.3.2. کلیدواژه‌های نرم¶

برخی نام‌ها تنها در زمینه‌های خاص محفوظ هستند. این موارد به‌عنوان کلیدواژه‌های نرم شناخته می‌شوند:

• match، case و _، هنگامی که در دستور match استفاده می‌شوند.

• type، هنگامی که در دستور type استفاده می‌شود.

• lazy، هنگامی که قبل از یک دستور import استفاده شود.

این موارد از نظر نحوی در زمینه‌های خاص خود به‌عنوان کلیدواژه عمل می‌کنند، اما این تمایز در سطح پارسر صورت می‌گیرد، نه هنگام توکن‌بندی (tokenizing).

به‌عنوان کلیدواژه‌های نرم (soft keywords)، استفاده از آن‌ها در دستور زبان ممکن است، در حالی که سازگاری با کد موجودی که از این نام‌ها به‌عنوان شناسه استفاده می‌کند همچنان حفظ می‌شود.

2.3.3. کلاس‌های رزروشده‌ی شناسه‌ها¶

برخی از کلاس‌های شناسه‌ها (به‌جز کلیدواژه‌ها) معانی خاصی دارند. این کلاس‌ها با الگوهای نویسه‌های زیرخط آغازین و پایانی شناسایی می‌شوند:

_*

با from module import * ایمپورت نمی‌شود.

_

در یک الگوی case درون یک دستور match، _ یک کلیدواژه نرم است که یک wildcard را نشان می‌دهد.

به‌طور جداگانه، مفسر تعاملی نتیجه آخرین ارزیابی را در متغیر _ در دسترس قرار می‌دهد. (این نتیجه در ماژول builtins، در کنار توابع توکار مانند print ذخیره می‌شود.)

در جاهای دیگر، _ یک شناسه معمولی است. اغلب از آن برای نام‌گذاری آیتم‌های «خاص» استفاده می‌شود، اما برای خود پایتون خاص نیست.

نکته

نام _ اغلب همراه با بین‌المللی‌سازی استفاده می‌شود؛ برای اطلاعات بیشتر درباره این قرارداد، به مستندات ماژول gettext مراجعه کنید.

همچنین به‌طور رایج برای متغیرهای استفاده‌نشده به کار می‌رود.

__*__

نام‌های تعریف‌شده توسط سیستم، که به‌طور غیررسمی به نام‌های «dunder» شناخته می‌شوند. این نام‌ها توسط مفسر و پیاده‌سازی آن (از جمله کتابخانه استاندارد) تعریف شده‌اند. نام‌های سیستمی فعلی در بخش نام متدهای ویژه و جاهای دیگر بررسی شده‌اند. احتمالاً نام‌های بیشتری در نسخه‌های آینده پایتون تعریف خواهند شد. هر استفاده‌ای از نام‌های __*__، در هر زمینه‌ای، که از کاربرد به‌صراحت مستندشده پیروی نکند، در معرض از کار افتادن بدون هشدار است.

__*

نام‌های خصوصی کلاس. نام‌های این دسته، هنگامی که در زمینه‌ی تعریف کلاس استفاده شوند، به‌شکل درهم‌ریخته (mangled form) بازنویسی می‌شوند تا به جلوگیری از تداخل نام میان ویژگی‌های «خصوصی» کلاس‌های پایه و مشتق‌شده کمک کنند. بخش شناسه‌ها (نام‌ها) را ببینید.

2.3.4. نویسه‌های غیر ASCII در نام‌ها¶

نام‌هایی که شامل نویسه‌های غیر ASCII هستند، به نرمال‌سازی و اعتبارسنجی بیشتری فراتر از قواعد و دستور زبان توضیح‌داده‌شده در بالا نیاز دارند. برای مثال، ř_1، 蛇 یا साँप نام‌های معتبر هستند، اما r〰2، € یا 🐍 معتبر نیستند.

این بخش قواعد دقیق را توضیح می‌دهد.

تمام نام‌ها هنگام تجزیه به normalization form NFKC تبدیل می‌شوند. این بدان معناست که، برای مثال، برخی صورت‌های تایپوگرافیک نویسه‌ها به فرم «پایه» خود تبدیل می‌شوند. برای مثال، fiⁿₐˡᵢᶻₐᵗᵢᵒₙ به finalization نرمال‌سازی می‌شود، بنابراین پایتون آن‌ها را یک نام یکسان در نظر می‌گیرد:

>>> fiⁿₐˡᵢᶻₐᵗᵢᵒₙ = 3
>>> finalization
3

همان‌طور که نام‌های فقط ASCII باید فقط شامل حروف، ارقام و زیرخط باشند و نمی‌توانند با یک رقم آغاز شوند، یک نام معتبر باید با نویسه‌ای از مجموعه «شبیه‌حروف» xid_start آغاز شود و نویسه‌های باقی‌مانده باید در مجموعه «شبیه‌حروف و ارقام» xid_continue قرار داشته باشند.

این مجموعه‌ها بر پایه‌ی مجموعه‌های XID_Start و XID_Continue هستند، همان‌گونه که در پیوست UAX-31 استاندارد یونیکد تعریف شده‌اند. xid_start پایتون افزون بر این شامل زیرخط (_) نیز می‌شود. توجه داشته باشید که پایتون لزوماً با UAX-31 مطابقت ندارد.

فهرست غیرهنجاری (non-normative) از نویسه‌های موجود در مجموعه‌های XID_Start و XID_Continue، طبق تعریف یونیکد، در پرونده DerivedCoreProperties.txt در پایگاه داده نویسه‌های یونیکد در دسترس است. برای ارجاع، قواعد ساخت مجموعه‌های xid_* در زیر آمده است.

مجموعه id_start به‌صورت اجتماع زیر تعریف شده است:

• دسته‌ی یونیکد <Lu> - حروف بزرگ (شامل A تا Z)

• دسته یونیکد <Ll> - حروف کوچک (شامل a تا z)

• دسته یونیکد <Lt> - حروف عنوان‌نویسی‌شده (titlecase)

• رده‌ی یونیکد <Lm> - حروف اصلاح‌کننده

• دسته‌ی یونیکد <Lo> - حروف دیگر

• دسته یونیکد <Nl> - اعداد حرفی

• {"_"} - زیرخط

• <Other_ID_Start> - مجموعه‌ای صریح از نویسه‌ها در PropList.txt برای پشتیبانی از سازگاری با نسخه‌های پیشین

سپس مجموعه‌ی xid_start این مجموعه را تحت نرمال‌سازی NFKC، با حذف تمام نویسه‌هایی که نرمال‌سازی آن‌ها به شکل id_start id_continue* نیست، بسته می‌کند.

مجموعه‌ی id_continue به‌صورت اجتماع زیر تعریف می‌شود:

• id_start (بالا را ببینید)

• دسته‌بندی یونیکد <Nd> - اعداد دهدهی (شامل 0 تا 9 می‌شود)

• دسته یونیکد <Pc> - نمادگذاری‌های اتصال

• دسته‌ی یونیکد <Mn> - علامت‌های بدون فاصله

• دسته‌ی یونیکد <Mc> - علامت‌های ترکیبی فاصله‌دار

• <Other_ID_Continue> - مجموعه صریح دیگری از نویسه‌ها در PropList.txt برای پشتیبانی از سازگاری با عقب

باز هم، xid_continue این مجموعه را تحت نرمال‌سازی NFKC بسته می‌کند.

دسته‌بندی‌های یونیکد از همان نسخه‌ای از پایگاه داده‌ی نویسه‌های یونیکد استفاده می‌کنند که در ماژول unicodedata گنجانده شده است.

2.5.1. رشته‌های سه‌علامت‌نقل‌قولی¶

رشته‌ها همچنین می‌توانند درون گروه‌های سه‌تایی همسان از علامت‌های نقل‌قول تکی یا دوتایی محصور شوند. به این رشته‌ها به‌طور کلی رشته‌های سه‌نقل‌قولی (triple-quoted strings) گفته می‌شود:

"""این یک رشته سه‌نقل‌قولی است."""

در مقادیر لفظی سه‌نقل‌قولی، علامت‌های نقل‌قول خنثی‌نشده مجاز هستند (و حفظ می‌شوند)، به این استثنا که سه علامت نقل‌قول خنثی‌نشده پشت‌سرهم، اگر از همان نوع (' یا ") استفاده‌شده در ابتدا باشند، لفظی را پایان می‌دهند:

"""این رشته در خود "علامت‌های نقل‌قول" دارد."""

سطرهای جدید خنثی‌نشده نیز مجاز هستند و حفظ می‌شوند:

'''This triple-quoted string
continues on the next line.'''

2.5.2. پیشوندهای رشته¶

رشته‌های لفظی می‌توانند یک prefix اختیاری داشته باشند که بر نحوه‌ی تجزیه‌ی محتوای آن‌ها تأثیر می‌گذارد، برای مثال:

b"data"
f'{result=}'

پیشوندهای مجاز عبارتند از:

• b: لفظی بایت

• r: رشته خام

• f: رشته لفظی قالب‌بندی‌شده («اف‌استرینگ»)

• t: رشته‌ی الگویی («t-string»)

• u: بدون اثر (برای سازگاری با نسخه‌های پیشین مجاز است)

برای جزئیات مربوط به هر نوع، بخش‌های پیوندشده را ببینید.

پیشوندها به بزرگی و کوچکی حروف حساس نیستند (برای مثال، 'B' مانند 'b' عمل می‌کند). پیشوند 'r' می‌تواند با 'f'، 't' یا 'b' ترکیب شود، بنابراین 'fr'، 'rf'، 'tr'، 'rt'، 'br' و 'rb' نیز پیشوندهای معتبر هستند.

2.5.3. دستور زبان صوری¶

رشته‌های لفظی، به‌جز «اف‌استرینگ‌ها» و «تی‌استرینگ‌ها»، با تعاریف واژگانی زیر توصیف شده‌اند.

این تعریف‌ها از پیش‌نگرهای منفی (!) استفاده می‌کنند تا نشان دهند که علامت نقل‌قول پایانی، لفظی را پایان می‌دهد.

STRING:          [stringprefix] (stringcontent)
stringprefix:    <("r" | "u" | "b" | "br" | "rb"), case-insensitive>
stringcontent:
   | "'''" ( !"'''" longstringitem)* "'''"
   | '"""' ( !'"""' longstringitem)* '"""'
   | "'" ( !"'" stringitem)* "'"
   | '"' ( !'"' stringitem)* '"'
stringitem:      stringchar | stringescapeseq
stringchar:      <any source_character, except backslash and newline>
longstringitem:  stringitem | newline
stringescapeseq: "\" <any source_character>

توجه داشته باشید که مانند همه‌ی تعاریف واژگانی، فضای سفید معنادار است. به‌ویژه، پیشوند (در صورت وجود) باید بلافاصله با علامت نقل‌قول آغازین دنبال شود.

2.5.4. دنباله‌های خنثی‌سازی¶

مگر آنکه پیشوند 'r' یا 'R' وجود داشته باشد، دنباله‌های خنثی‌سازی در مقادیر لفظی رشته و بایت طبق قوانینی مشابه قوانین به‌کاررفته در C استاندارد تفسیر می‌شوند. دنباله‌های خنثی‌سازی شناخته‌شده عبارتند از:

>>> 'This string will not include \
... backslashes or newline characters.'
'This string will not include backslashes or newline characters.'

>>> print('C:\\Program Files')
C:\Program Files

>>> print('\' and \"')
' and "

>>> '\120'
'P'

>>> '\x50'
'P'

>>> '\N{LATIN CAPITAL LETTER P}'
'P'
>>> '\N{SNAKE}'
'🐍'

>>> '\u1234'
'ሴ'
>>> '\U0001f40d'
'🐍'

>>> print('\q')
\q
>>> list('\q')
['\\', 'q']

2.5.5. مقادیر لفظی بایتی¶

مقادیر لفظی بایت (Bytes literals) همیشه پیشوند 'b' یا 'B' دارند؛ آن‌ها نمونه‌ای از نوع bytes را به جای نوع str تولید می‌کنند. آن‌ها فقط می‌توانند شامل نویسه‌های ASCII باشند؛ بایت‌هایی با مقدار عددی ۱۲۸ یا بیشتر باید با دنباله‌های خنثی‌سازی نوشته شوند (معمولاً نویسه‌ی مبنای شانزده یا نویسه‌ی مبنای هشت):

>>> b'\x89PNG\r\n\x1a\n'
b'\x89PNG\r\n\x1a\n'
>>> list(b'\x89PNG\r\n\x1a\n')
[137, 80, 78, 71, 13, 10, 26, 10]

به‌طور مشابه، یک بایت صفر باید با استفاده از یک دنباله خنثی‌سازی بیان شود (معمولاً \0 یا \x00).

2.5.6. مقادیر لفظی رشته خام¶

هم مقادیر لفظی رشته و هم مقادیر لفظی بایت می‌توانند به‌صورت اختیاری با حرف 'r' یا 'R' پیشوند بگیرند؛ به چنین ساختارهایی به‌ترتیب مقادیر لفظی رشته خام (raw string literals) و مقادیر لفظی بایت خام (raw bytes literals) گفته می‌شود و آن‌ها بک‌اسلش‌ها را به‌عنوان نویسه‌های لفظی در نظر می‌گیرند. در نتیجه، در مقادیر لفظی رشته خام، دنباله‌های خنثی‌سازی به‌صورت ویژه پردازش نمی‌شوند:

>>> r'\d{4}-\d{2}-\d{2}'
'\\d{4}-\\d{2}-\\d{2}'

حتی در یک لفظی خام، می‌توان علامت‌های نقل‌قول را با بک‌اسلش خنثی کرد، اما بک‌اسلش در نتیجه باقی می‌ماند؛ برای مثال، r"\"" یک لفظی رشته‌ی معتبر است که از دو نویسه تشکیل شده است: یک بک‌اسلش و یک علامت نقل‌قول دوتایی؛ r"\" یک لفظی رشته‌ی معتبر نیست (حتی یک رشته‌ی خام نمی‌تواند با تعداد فردی از بک‌اسلش‌ها تمام شود). به‌طور مشخص، یک لفظی خام نمی‌تواند با یک بک‌اسلش تمام شود (زیرا بک‌اسلش، نویسه‌ی نقل‌قول بعدی را خنثی می‌کند). همچنین توجه داشته باشید که یک بک‌اسلش تنها که پس از آن یک نویسه‌ی خط جدید باشد، به‌عنوان همان دو نویسه و بخشی از لفظی تفسیر می‌شود، نه به‌عنوان ادامه‌ی خط.

2.5.7. اف‌استرینگ‌ها¶

یک لفظی رشته قالب‌بندی‌شده (formatted string literal) یا اف‌استرینگ (f-string)، لفظی رشته‌ای است که با 'f' یا 'F' پیشوند دارد. برخلاف سایر مقادیر لفظی رشته، اف‌استرینگ‌ها مقدار ثابت ندارند. آن‌ها ممکن است حاوی فیلدهای جایگزینی باشند که با آکولاد {} محصور شده‌اند. فیلدهای جایگزینی حاوی عبارت‌هایی هستند که در ران‌تایم ارزیابی می‌شوند. برای مثال:

>>> who = 'nobody'
>>> nationality = 'Spanish'
>>> f'{who.title()} expects the {nationality} Inquisition!'
'Nobody expects the Spanish Inquisition!'

هر کمانک دوتایی ({{ یا }}) خارج از فیلدهای جایگزینی، با کمانک تکی متناظر جایگزین می‌شود:

>>> print(f'{{...}}')
{...}

سایر نویسه‌های خارج از فیلدهای جایگزینی مانند لیترال‌های رشته‌ای معمولی رفتار می‌شوند. این بدان معنا است که دنباله‌های خنثی‌سازی کدگشایی می‌شوند (مگر وقتی که یک لیتِرال نیز به‌عنوان رشته خام علامت‌گذاری شده باشد) و امکان استفاده از سطرهای جدید در اف‌استرینگ‌های با سه علامت نقل‌قول وجود دارد:

>>> name = 'Galahad'
>>> favorite_color = 'blue'
>>> print(f'{name}:\t{favorite_color}')
Galahad:       blue
>>> print(rf"C:\Users\{name}")
C:\Users\Galahad
>>> print(f'''Three shall be the number of the counting
... and the number of the counting shall be three.''')
Three shall be the number of the counting
and the number of the counting shall be three.

عبارات در رشته‌های قالب‌بندی‌شده مانند عبارات معمولی پایتون رفتار می‌شوند. هر عبارت در زمینه‌ای که رشته قالب‌بندی‌شده در آن ظاهر می‌شود، به ترتیب از چپ به راست ارزیابی می‌شود. عبارت خالی مجاز نیست، و هر دو عبارت lambda و عبارت‌های انتساب := باید در پرانتزهای صریح قرار گیرند:

>>> f'{(half := 1/2)}, {half * 42}'
'0.5, 21.0'

استفاده‌ی مجدد از نوع علامت نقل‌قول اف‌استرینگ بیرونی در داخل یک فیلد جایگزینی (replacement field) مجاز است:

>>> a = dict(x=2)
>>> f"abc {a["x"]} def"
'abc 2 def'

بک‌اسلش‌ها نیز در فیلدهای جایگزینی مجاز هستند و به همان شیوه‌ی هر زمینه‌ی دیگری ارزیابی می‌شوند:

>>> a = ["a", "b", "c"]
>>> print(f"List a contains:\n{"\n".join(a)}")
List a contains:
a
b
c

می‌توان اف‌استرینگ‌ها را تودرتو کرد:

>>> name = 'world'
>>> f'Repeated:{f' hello {name}' * 3}'
'Repeated: hello world hello world hello world'

برنامه‌های پایتون قابل‌حمل نباید از بیش از ۵ سطح تودرتویی استفاده کنند.

عبارت‌های جایگزینی می‌توانند در هر دو نوع اف‌استرینگ با یک علامت نقل‌قول و با سه علامت نقل‌قول شامل سطرهای جدید باشند و همچنین می‌توانند شامل کامنت باشند. هر چیزی که پس از # درون یک فیلد جایگزینی بیاید، یک کامنت است (حتی آکولادهای بسته و علامت‌های نقل‌قول). این بدان معناست که فیلدهای جایگزینی دارای کامنت باید در خط دیگری بسته شوند:

>>> a = 2
>>> f"abc{a  # This comment  }"  continues until the end of the line
...       + 3}"
'abc5'

پس از عبارت، فیلدهای جایگزینی می‌توانند به‌اختیار شامل موارد زیر باشند:

• یک مشخص‌کننده اشکال‌زدایی -- یک علامت تساوی (=)، که به‌صورت اختیاری در یک یا هر دو طرف با فضای سفید احاطه شده است؛

• یک مشخص‌کننده تبدیل -- !s، !r یا !a؛ و/یا

• یک مشخص‌کننده قالب که با یک دونقطه (:) پیشوند داده شده است.

برای جزئیات درباره چگونگی ارزیابی این فیلدها، بخش کتابخانه استاندارد درباره اف‌استرینگ‌ها را ببینید.

همان‌طور که آن بخش توضیح می‌دهد، مشخص‌کننده‌های قالب‌بندی به‌عنوان دومین آرگومان به تابع format() ارسال می‌شوند تا مقدار یک فیلد جایگزینی را قالب‌بندی کنند. برای مثال، می‌توان از آن‌ها برای مشخص کردن عرض فیلد و نویسه‌های پرکننده با استفاده از زبان کوچک مشخصات قالب‌بندی استفاده کرد:

>>> number = 14.3
>>> f'{number:20.7f}'
'          14.3000000'

مشخص‌کننده‌های قالب سطح بالا ممکن است شامل فیلدهای جایگزینی تودرتو باشند:

>>> field_size = 20
>>> precision = 7
>>> f'{number:{field_size}.{precision}f}'
'          14.3000000'

این فیلدهای تودرتو ممکن است شامل فیلدهای تبدیل و مشخص‌کننده‌های قالب خود باشند:

>>> number = 3
>>> f'{number:{field_size}}'
'                   3'
>>> f'{number:{field_size:05}}'
'00000000000000000003'

با این حال، این فیلدهای تودرتو نمی‌توانند شامل فیلدهای جایگزینی با تودرتویی عمیق‌تر باشند.

مقادیر لفظی رشته قالب‌بندی‌شده را نمی‌توان به‌عنوان رشته مستند استفاده کرد، حتی اگر شامل عبارت نباشند:

>>> def foo():
...     f"Not a docstring"
...
>>> print(foo.__doc__)
None

2.5.8. تی‌استرینگ‌ها (t-strings)¶

رشته‌ی الگو (template string literal) یا تی‌استرینگ (t-string) یک رشته‌ی لفظی (string literal) است که با 't' یا 'T' پیشوند داده‌شده است. این رشته‌ها از همان قواعد نحوی رشته‌های قالب‌بندی‌شده پیروی می‌کنند. برای تفاوت‌ها در قواعد ارزیابی، بخش کتابخانه‌ی استاندارد درباره‌ی تی‌استرینگ‌ها را ببینید

2.5.9. دستور زبان رسمی برای اف‌استرینگ‌ها¶

اف‌استرینگ‌ها تا حدی توسط تحلیل‌گر واژگانی (lexical analyzer) پردازش می‌شوند که توکن‌های FSTRING_START، FSTRING_MIDDLE و FSTRING_END را تولید می‌کند، و تا حدی توسط پارسر که عبارت‌های درون فیلد جایگزینی را پردازش می‌کند. روش دقیق تقسیم این کار، جزئیاتی از پیاده‌سازی CPython است.

به‌طور متناظر، گرامر اف‌استرینگ ترکیبی از تعاریف واژگانی و نحوی است.

فضای سفید در این موقعیت‌ها اهمیت دارد:

• در FSTRING_START نباید هیچ فضای سفیدی وجود داشته باشد (بین پیشوند و علامت نقل‌قول).

• فضای سفید در FSTRING_MIDDLE بخشی از محتوای رشته‌ی لفظی است.

• در fstring_replacement_field، اگر f_debug_specifier وجود داشته باشد، تمام فضای سفید پس از آکولاد باز تا f_debug_specifier، و همچنین فضای سفید بلافاصله پس از f_debug_specifier، به‌عنوان بخشی از عبارت حفظ می‌شود.

  عبارت در مرحله‌ی توکن‌بندی (tokenization) پردازش نمی‌شود؛ بلکه با استفاده از موقعیت‌های توکن { و توکن بعد از = از کد منبع بازیابی می‌شود.

تعریف FSTRING_MIDDLE از پیش‌نگری‌های منفی (negative lookaheads) (!) برای مشخص کردن نویسه‌های خاص (بک‌اسلش، خط جدید، {، }) و دنباله‌ها (f_quote) استفاده می‌کند.

fstring:    FSTRING_START fstring_middle* FSTRING_END

FSTRING_START:      fstringprefix ("'" | '"' | "'''" | '"""')
FSTRING_END:        f_quote
fstringprefix:      <("f" | "fr" | "rf"), case-insensitive>
f_debug_specifier:  '='
f_quote:            <the quote character(s) used in FSTRING_START>

fstring_middle:
   | fstring_replacement_field
   | FSTRING_MIDDLE
FSTRING_MIDDLE:
   | (!"\" !newline !'{' !'}' !f_quote) source_character
   | stringescapeseq
   | "{{"
   | "}}"
   | <newline, in triple-quoted f-strings only>
fstring_replacement_field:
   | '{' f_expression [f_debug_specifier] [fstring_conversion]
         [fstring_full_format_spec] '}'
fstring_conversion:
   | "!" ("s" | "r" | "a")
fstring_full_format_spec:
   | ':' fstring_format_spec*
fstring_format_spec:
   | FSTRING_MIDDLE
   | fstring_replacement_field
f_expression:
   | ','.(conditional_expression | "*" or_expr)+ [","]
   | yield_expression

دستور زبان تی‌استرینگ‌ها با دستور زبان اف‌استرینگ‌ها یکسان است، با این تفاوت که t به‌جای f در ابتدای نام قواعد و توکن‌ها و در پیشوند قرار می‌گیرد.

tstring:    TSTRING_START tstring_middle* TSTRING_END

<rest of the t-string grammar is omitted; see above>

2.6.1. مقادیر لفظی عدد صحیح¶

مقادیر لفظی عدد صحیح، اعداد حسابی را نشان می‌دهند. برای مثال:

7
3
2147483647

هیچ محدودیتی برای طول مقادیر لفظی عدد صحیح وجود ندارد، مگر آنچه می‌تواند در حافظه‌ی موجود ذخیره شود:

7922816251426433759354395033679228162514264337593543950336

می‌توان از زیرسطرها برای گروه‌بندی ارقام جهت خوانایی بهتر استفاده کرد، و آن‌ها هنگام تعیین مقدار عددی لفظی نادیده گرفته می‌شوند. برای مثال، مقادیر لفظی زیر معادل هستند:

100_000_000_000
100000000000
1_00_00_00_00_000

زیرسطرها فقط می‌توانند بین ارقام قرار بگیرند. برای مثال، _123، 321_ و 123__321 مقادیر لفظی معتبر نیستند.

می‌توان اعداد صحیح را به‌ترتیب با پیشوندهای 0b، 0o و 0x در مبنای ۲ (دودویی)، مبنای ۸ (هشت‌هشتی) یا مبنای شانزده (مبنای ۱۶) مشخص کرد. ارقام ۱۰ تا ۱۵ مبنای شانزده با حروف A-F و بدون حساسیت به بزرگی و کوچکی حروف نمایش داده می‌شوند. برای مثال:

0b100110111
0b_1110_0101
0o177
0o377
0xdeadbeef
0xDead_Beef

یک زیرخط می‌تواند پس از مشخص‌کننده‌ی مبنا بیاید. برای مثال، 0x_1f یک لفظی معتبر است، اما 0_x1f و 0x__1f معتبر نیستند.

صفرهای آغازین در یک عدد دهدهی غیرصفر مجاز نیستند. برای مثال، 0123 یک لفظ معتبر نیست. این برای تمایز از لفظ‌های مبنای هشت به‌سبک C است، که پایتون پیش از نسخه 3.0 از آن‌ها استفاده می‌کرد.

به‌طور رسمی، مقادیر لفظی عدد صحیح با تعاریف واژگانی زیر توصیف می‌شوند:

integer:      decinteger | bininteger | octinteger | hexinteger | zerointeger
decinteger:   nonzerodigit (["_"] digit)*
bininteger:   "0" ("b" | "B") (["_"] bindigit)+
octinteger:   "0" ("o" | "O") (["_"] octdigit)+
hexinteger:   "0" ("x" | "X") (["_"] hexdigit)+
zerointeger:  "0"+ (["_"] "0")*
nonzerodigit: "1"..."9"
digit:        "0"..."9"
bindigit:     "0" | "1"
octdigit:     "0"..."7"
hexdigit:     digit | "a"..."f" | "A"..."F"

2.6.2. مقادیر لفظی ممیز شناور¶

مقادیر لفظی ممیز شناور (float)، مانند 3.14 یا 1.5، بیانگر تقریب‌هایی از اعداد حقیقی هستند.

آن‌ها از بخش‌های صحیح و کسری تشکیل شده‌اند که هر یک از ارقام دهدهی ساخته شده است. این بخش‌ها با یک نقطه‌ی اعشار، .، از هم جدا می‌شوند:

2.71828
4.0

برخلاف مقادیر لفظی عدد صحیح، صفرهای پیشرو مجاز هستند. برای مثال، 077.010 معتبر است و همان عدد 77.01 را نشان می‌دهد.

مانند مقادیر لفظی عدد صحیح، زیرسطرهای تکی می‌توانند بین ارقام قرار بگیرند تا خوانایی را بهبود بخشند:

96_485.332_123
3.14_15_93

هر یک از این بخش‌ها می‌تواند خالی باشد، اما نه هر دو. برای مثال:

10.  # (equivalent to 10.0)
.001  # (equivalent to 0.001)

به‌صورت اختیاری، ممکن است پس از بخش عدد صحیح و بخش کسری یک توان بیاید: حرف e یا E، به دنبال آن یک علامت اختیاری، + یا -، و عددی با همان قالب بخش‌های عدد صحیح و کسری. e یا E به معنای «ضرب در ده به توانِ» است:

1.0e3  # (represents 1.0×10³, or 1000.0)
1.166e-5  # (represents 1.166×10⁻⁵, or 0.00001166)
6.02214076e+23  # (represents 6.02214076×10²³, or 602214076000000000000000.)

در اعداد اعشاریی که فقط بخش عدد صحیح و بخش توان دارند، می‌توان نقطه اعشار را حذف کرد:

1e3  # (equivalent to 1.e3 and 1.0e3)
0e0  # (equivalent to 0.)

به‌طور رسمی، مقادیر لفظی ممیز شناور با تعاریف واژگانی زیر توصیف می‌شوند:

floatnumber:
   | digitpart "." [digitpart] [exponent]
   | "." digitpart [exponent]
   | digitpart exponent
digitpart: digit (["_"] digit)*
exponent:  ("e" | "E") ["+" | "-"] digitpart

2.6.3. مقادیر لفظی موهومی¶

پایتون اشیای عدد مختلط دارد، اما هیچ لفظی مختلطی ندارد. در عوض، مقادیر لفظی موهومی نشان‌دهنده‌ی اعداد مختلط با بخش حقیقی صفر هستند.

برای مثال، در ریاضیات، عدد مختلط 3+4.2i به‌صورت جمع عدد حقیقی 3 با عدد موهومی 4.2i نوشته می‌شود. پایتون از سینتکس مشابهی استفاده می‌کند، با این تفاوت که واحد موهومی به‌جای i به‌صورت j نوشته می‌شود:

3+4.2j

این یک عبارت تشکیل‌شده از لفظی عدد صحیح 3، عملگر '+'، و لفظی موهومی 4.2j است. از آن‌جا که این‌ها سه توکن جداگانه هستند، فضای خالی بین آن‌ها مجاز است:

3 + 4.2j

هیچ فضای سفیدی در درون هر توکن مجاز نیست. به‌ویژه، پسوند j نمی‌تواند از عدد پیش از خود جدا شود.

عدد پیش از j همان سینتکس یک لفظی ممیز شناور را دارد. بنابراین، موارد زیر مقادیر لفظی موهومی معتبر هستند:

4.2j
3.14j
10.j
.001j
1e100j
3.14e-10j
3.14_15_93j

برخلاف یک لفظی ممیز شناور، اگر عدد موهومی فقط بخش صحیح داشته باشد، می‌توان نقطه اعشار را حذف کرد. این عدد همچنان به‌عنوان یک عدد ممیز شناور ارزیابی می‌شود، نه یک عدد صحیح:

10j
0j
1000000000000000000000000j   # equivalent to 1e+24j

پسوند j به بزرگی و کوچکی حروف حساس نیست. این بدان معناست که می‌توانید به جای آن از J استفاده کنید:

3.14J   # equivalent to 3.14j

به‌طور رسمی، مقادیر لفظی موهومی با تعریف واژگانی زیر توصیف می‌شوند:

imagnumber: (floatnumber | digitpart) ("j" | "J")