2. تحلیل واژگانی

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

تحلیل‌گر واژگانی، کدگذاری متن برنامه را تعیین می‌کند (به‌طور پیش‌فرض UTF-8)، و متن را به نویسه‌های منبع کدگشایی می‌کند. اگر متن نتواند کدگشایی شود، یک SyntaxError پرتاب می‌شود.

در ادامه، تحلیل‌گر واژگانی از نویسه‌های منبع برای تولید جریانی از توکن‌ها استفاده می‌کند. نوع یک توکن تولیدشده عموماً به نویسه منبع بعدی که قرار است پردازش شود، بستگی دارد. به‌طور مشابه، سایر رفتارهای خاص تحلیل‌گر به نخستین نویسه منبع که هنوز پردازش‌نشده است، بستگی دارد. جدول زیر خلاصه‌ای سریع از این نویسه‌های منبع را به‌همراه پیوندهایی به بخش‌هایی که اطلاعات بیشتری دارند، ارائه می‌دهد.

نویسه

توکن بعدی (یا سایر مستندات مرتبط)

  • فاصله

  • زبانه

  • تغذیه‌ی صفحه (formfeed)

  • CR, LF

  • بک‌اسلش (\)

  • هش (#)

  • علامت نقل‌قول ('، ")

  • حرف ASCII (a-z، A-Z)

  • نویسه‌ی غیر ASCII

  • زیرخط (_)

  • عدد (0-9)

  • نقطه (.)

  • علامت سؤال (?)

  • دلار ($)

  • بک‌کوت (​`​)

  • نویسه‌ی کنترلی

  • خطا (خارج از رشته‌های لفظی و کامنت‌ها)

  • نویسه چاپی دیگر

  • پایان پرونده

2.1. ساختار سطر

یک برنامه پایتون به تعدادی خط منطقی تقسیم می‌شود.

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.2. سایر توکن‌ها

علاوه بر NEWLINE، INDENT و DEDENT، دسته‌های زیر از توکن‌ها وجود دارند: شناسه‌ها و کلیدواژه‌ها (NAME)، مقادیر لفظی (مانند NUMBER و STRING)، و نمادهای دیگر (عملگرها و جداکننده‌ها، OP). نویسه‌های فضای سفید (غیر از پایان‌دهنده‌های خط منطقی، که پیش‌تر به آن‌ها پرداخته شد) توکن محسوب نمی‌شوند، بلکه برای جداسازی توکن‌ها به کار می‌روند. در صورت وجود ابهام، یک توکن شامل طولانی‌ترین رشته‌ی ممکن است که هنگام خواندن از چپ به راست، یک توکن معتبر تشکیل می‌دهد.

2.3. نام‌ها (شناسه‌ها و کلیدواژه‌ها)

توکن‌های NAME نشان‌دهنده‌ی شناسه‌ها، کلیدواژه‌ها و کلیدواژه‌های نرم هستند.

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

  • حروف بزرگ و کوچک (A-Z و a-z)،

  • زیرخط (_)،

  • ارقام (0 تا 9)، که نمی‌توانند به‌عنوان اولین نویسه ظاهر شوند، و

  • نویسه‌های غیر ASCII. نام‌های معتبر فقط می‌توانند شامل نویسه‌های «حرف‌مانند» و «رقم‌مانند» باشند؛ برای جزئیات نویسه‌های غیر ASCII در نام‌ها را ببینید.

نام‌ها باید حداقل شامل یک نویسه باشند، اما محدودیت بالایی برای طول آن‌ها وجود ندارد. بزرگی و کوچکی حروف اهمیت دارد.

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

NAME:          name_start name_continue*
name_start:    "a"..."z" | "A"..."Z" | "_" | <non-ASCII character>
name_continue: name_start | "0"..."9"
identifier:    <NAME, except keywords>

توجه داشته باشید که همه‌ی نام‌هایی که با این گرامر مطابقت دارند، معتبر نیستند؛ برای جزئیات نویسه‌های غیر ASCII در نام‌ها را ببینید.

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. کلیدواژه‌های نرم

اضافه شده در نسخه‌ی 3.10.

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

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

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

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

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

تغییر یافته در نسخه‌ی 3.12: type اکنون یک کلیدواژه نرم (soft keyword) است.

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

توجه

نرمال‌سازی فقط در سطح واژگانی انجام می‌شود. توابع ران‌تایمی که نام‌ها را به‌عنوان رشته دریافت می‌کنند، معمولاً آرگومان‌های خود را نرمال‌سازی نمی‌کنند. برای مثال، متغیر تعریف‌شده در بالا در ران‌تایم در دیکشنری globals() به‌صورت globals()["finalization"] قابل دسترسی است، اما به‌صورت globals()["fiⁿₐˡᵢᶻₐᵗᵢᵒₙ"] قابل دسترسی نیست.

همان‌طور که نام‌های فقط 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 گنجانده شده است.

همچنین ملاحظه نمائید

  • PEP 3131 -- پشتیبانی از شناسه‌های غیر ASCII

  • PEP 672 -- ملاحظات امنیتی مرتبط با یونیکد برای پایتون

2.4. مقادیر لفظی

مقادیر لفظی نشانه‌هایی برای مقادیر ثابت برخی از انواع توکار هستند.

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

سایر «مقادیر لفظی» از نظر واژگانی با استفاده از کلیدواژه‌ها (None، True، False) و توکن سه‌نقطه ویژه (...) نشان داده می‌شوند.

2.5. مقادیر لفظی رشته و بایت

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

"spam"
'eggs'

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

'Say "Hello", please.'
"Don't do that!"

به جز این محدودیت، انتخاب نویسه‌ی علامت نقل‌قول (' یا ") تأثیری بر نحوه‌ی تجزیه‌ی لفظی ندارد.

در یک لفظی رشته، نویسه‌ی بک‌اسلش (\) یک دنباله‌ی خنثی‌سازی <escape sequence> را آغاز می‌کند که بسته به نویسه‌ی پس از بک‌اسلش، معنای خاصی دارد. برای مثال، \" نشان‌دهنده‌ی نویسه‌ی علامت نقل‌قول دوتایی است و رشته را به پایان نمی‌رساند:

>>> print("Say \"Hello\" to everyone!")
Say "Hello" to everyone!

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

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

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

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

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

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

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

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

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

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

b"data"
f'{result=}'

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

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

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

اضافه شده در نسخه‌ی 3.3: پیشوند 'rb' برای مقادیر لفظی بایت خام به‌عنوان مترادفی برای 'br' افزوده شده است.

پشتیبانی از لفظی قدیمی یونیکد (u'value') دوباره معرفی شد تا نگهداری پایگاه‌های کد دوگانه‌ی Python 2.x و 3.x ساده‌تر شود. برای اطلاعات بیشتر، PEP 414 را ببینید.

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 استاندارد تفسیر می‌شوند. دنباله‌های خنثی‌سازی شناخته‌شده عبارتند از:

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

معنی

\<newline>

پایان خط نادیده گرفته می‌شود

\\

بک‌اسلش

\'

علامت نقل‌قول تکی

\"

علامت نقل‌قول دوتایی

\a

زنگ ASCII (BEL)

\b

پس‌بر ASCII (BS)

\f

تغذیه‌ی صفحه ASCII (FF)

\n

تغذیه‌ی سطر ASCII (LF)

\r

بازگشت به ابتدای سطر ASCII (CR)

\t

تب افقی ASCII (TAB)

\v

تب عمودی ASCII (VT)

\ooo

نویسه‌ی مبنای هشت

\xhh

نویسه‌ی مبنای شانزده

\N{name}

نویسه‌ی یونیکد نام‌دار

\uxxxx

نویسه‌ی یونیکد مبنای شانزده

\Uxxxxxxxx

نویسه‌ی یونیکد مبنای شانزده

2.5.4.1. پایان خط نادیده گرفته می‌شود

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

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

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

2.5.4.2. نویسه‌های خنثی‌شده

برای درج یک بک‌اسلش در یک لفظی رشته پایتون غیر خام، باید آن را دو برابر کرد. دنباله خنثی‌سازی \\ نشان‌دهنده یک نویسه بک‌اسلش است:

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

به همین ترتیب، دنباله‌های \' و \" به‌ترتیب نشان‌دهنده‌ی نویسه‌ی نقل‌قول تکی و دوتایی هستند:

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

2.5.4.3. نویسه‌ی مبنای هشت

دنباله‌ی \ooo یک نویسه با مقدار مبنای ۸ ooo را نشان می‌دهد:

>>> '\120'
'P'

تا سه رقم مبنای هشت (۰ تا ۷) پذیرفته می‌شود.

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

تغییر یافته در نسخه‌ی 3.11: دنباله‌های خنثی‌سازی مبنای هشت با مقدار بزرگ‌تر از 0o377 (۲۵۵) یک DeprecationWarning تولید می‌کنند.

تغییر یافته در نسخه‌ی 3.12: دنباله‌های خنثی‌سازی مبنای هشت با مقداری بزرگ‌تر از 0o377 (۲۵۵) یک SyntaxWarning تولید می‌کنند. در نسخه‌ای آینده از پایتون یک SyntaxError پرتاب خواهند کرد.

2.5.4.4. نویسه‌ی مبنای شانزده

دنباله‌ی \xhh یک نویسه با مقدار مبنای شانزده (مبنای ۱۶) hh را نشان می‌دهد:

>>> '\x50'
'P'

برخلاف C استاندارد، دقیقاً دو رقم مبنای شانزده لازم است.

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

2.5.4.5. نویسه‌ی یونیکد نام‌دار

دنباله‌ی \N{name} یک نویسه‌ی یونیکد با نام داده‌شده را نشان می‌دهد:

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

این دنباله نمی‌تواند در مقادیر لفظی بایتی ظاهر شود.

تغییر یافته در نسخه‌ی 3.3: پشتیبانی از نام‌های مستعار اضافه شده است.

2.5.4.6. نویسه‌های یونیکد مبنای شانزده

این دنباله‌ها \uxxxx و \Uxxxxxxxx نویسه‌ی یونیکد با مقدار داده‌شده به مبنای شانزده را نشان می‌دهند. برای \u دقیقاً چهار رقم لازم است؛ برای \U دقیقاً هشت رقم لازم است. دومی می‌تواند هر نویسه‌ی یونیکد را کدگذاری کند.

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

این دنباله‌ها نمی‌توانند در مقادیر لفظی بایتی ظاهر شوند.

2.5.4.7. دنباله‌های خنثی‌سازی شناسایی‌نشده

برخلاف C استاندارد، همه‌ی دنباله‌های خنثی‌سازی ناشناخته بدون تغییر در رشته باقی می‌مانند، یعنی بک‌اسلش در نتیجه باقی می‌ماند:

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

توجه داشته باشید که برای مقادیر لفظی bytes، دنباله‌های خنثی‌سازیی که فقط در مقادیر لفظی رشته‌ای شناسایی می‌شوند (\N...، \u...، \U...) در دسته دنباله‌های خنثی‌سازی ناشناخته قرار می‌گیرند.

تغییر یافته در نسخه‌ی 3.6: دنباله‌های خنثی‌سازی ناشناخته، یک DeprecationWarning ایجاد می‌کنند.

تغییر یافته در نسخه‌ی 3.12: دنباله‌های خنثی‌سازی ناشناخته باعث ایجاد یک SyntaxWarning می‌شوند. در یک نسخه آینده از پایتون، این دنباله‌ها یک SyntaxError پرتاب خواهند کرد.

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. اف‌استرینگ‌ها

اضافه شده در نسخه‌ی 3.6.

تغییر یافته در نسخه‌ی 3.7: می‌توان از await و async for در عبارت‌های درون اف‌استرینگ‌ها استفاده کرد.

تغییر یافته در نسخه‌ی 3.8: مشخص‌کننده اشکال‌زدایی (=) افزوده شد.

تغییر یافته در نسخه‌ی 3.12: بسیاری از محدودیت‌های مربوط به عبارت‌های درون اف‌استرینگ‌ها برداشته شده‌اند. به‌ویژه، رشته‌های تودرتو، کامنت‌ها و بک‌اسلش‌ها اکنون مجاز هستند.

یک لفظی رشته قالب‌بندی‌شده <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'

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

CPython تودرتوی اف‌استرینگ‌ها را محدود نمی‌کند.

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

>>> 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

همچنین ملاحظه نمائید

  • PEP 498 -- درون‌یابی رشته‌ی لفظی

  • PEP 701 -- رسمی‌سازی سینتکسی اف‌استرینگ‌ها

  • str.format()، که از سازوکار رشته‌ی قالب‌بندی مرتبط استفاده می‌کند.

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

اضافه شده در نسخه‌ی 3.14.

رشته‌ی الگو (template string literal) <template string literal> یا تی‌استرینگ (t-string) <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

توجه

در قطعه دستور زبان بالا، قواعد f_quote و FSTRING_MIDDLE حساس به زمینه هستند — این قواعد به محتویات FSTRING_START در نزدیک‌ترین fstring دربرگیرنده بستگی دارند.

ساخت یک دستور زبان صوری سنتی‌تر از این قالب، به‌عنوان تمرینی برای خواننده باقی می‌ماند.

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

tstring:    TSTRING_START tstring_middle* TSTRING_END

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

2.6. مقادیر لفظی عددی

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

NUMBER: integer | floatnumber | imagnumber

مقدار عددی یک لفظی عددی (numeric literal) همان مقداری است که گویی آن لفظی به‌صورت یک رشته به سازنده‌ی کلاس int، float یا complex، به‌ترتیب، ارسال شود. توجه داشته باشید که همه‌ی ورودی‌های معتبر برای آن سازنده‌ها، مقادیر لفظی معتبر نیز نیستند.

اعداد لفظی شامل علامت نمی‌شوند؛ عبارتی مانند -1 در واقع عبارتی است که از عملگر یک‌عملوندی '-' و لفظ 1 تشکیل‌شده است.

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"

تغییر یافته در نسخه‌ی 3.6: اکنون استفاده از زیرسطرها برای اهداف گروه‌بندی در مقادیر لفظی مجاز است.

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

تغییر یافته در نسخه‌ی 3.6: اکنون استفاده از زیرسطرها برای اهداف گروه‌بندی در مقادیر لفظی مجاز است.

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")

2.7. عملگرها و جداکننده‌ها

دستور زبان زیر توکن‌های عملگر <operator> و جداکننده <delimiter> را تعریف می‌کند، یعنی نوع توکن عام OP. فهرستی از این توکن‌ها و نام‌های آن‌ها نیز در مستندات ماژول token در دسترس است.

OP:
   | assignment_operator
   | bitwise_operator
   | comparison_operator
   | enclosing_delimiter
   | other_delimiter
   | arithmetic_operator
   | "..."
   | other_op

assignment_operator:   "+=" | "-=" | "*=" | "**=" | "/="  | "//=" | "%=" |
                       "&=" | "|=" | "^=" | "<<=" | ">>=" | "@="  | ":="
bitwise_operator:      "&"  | "|"  | "^"  | "~"   | "<<"  | ">>"
comparison_operator:   "<=" | ">=" | "<"  | ">"   | "=="  | "!="
enclosing_delimiter:   "("  | ")"  | "["  | "]"   | "{"   | "}"
other_delimiter:       ","  | ":"  | "!"  | ";"   | "="   | "->"
arithmetic_operator:   "+"  | "-"  | "**" | "*"   | "//"  | "/"   | "%"
other_op:              "."  | "@"

توجه

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

برخی توکن‌ها می‌توانند بسته به کاربرد، به‌عنوان عملگر یا جداکننده به کار روند. برای مثال، * هم عملگر ضرب است و هم جداکننده‌ای که برای واگشایی دنباله به کار می‌رود، و @ هم عملگر ضرب ماتریسی است و هم جداکننده‌ای که دکوراتورها را معرفی می‌کند.

برای برخی توکن‌ها، این تمایز نامشخص است. برای مثال، برخی افراد .، ( و ) را جداکننده می‌دانند، در حالی که برخی دیگر آن‌ها را عملگر getattr() و عملگر(های) فراخوانی تابع می‌دانند.

برخی از عملگرهای پایتون، مانند and، or و not in، به‌جای «نمادها» (توکن‌های عملگر) از توکن‌های کلیدواژه استفاده می‌کنند.

دنباله‌ای از سه نقطه‌ی متوالی (...) به‌عنوان یک لفظی Ellipsis معنای ویژه‌ای دارد.