Print یک تابع است¶

دستور print با تابع print() جایگزین شده است که با آرگومان‌های کلیدواژه‌ای، بیشتر سینتکس خاص دستور قدیمی print را جایگزین می‌کند (PEP 3105). مثال‌ها:

Old: print "The answer is", 2*2
New: print("The answer is", 2*2)

Old: print x,           # Trailing comma suppresses newline
New: print(x, end=" ")  # Appends a space instead of a newline

Old: print              # Prints a newline
New: print()            # You must call the function!

Old: print >>sys.stderr, "fatal error"
New: print("fatal error", file=sys.stderr)

Old: print (x, y)       # prints repr((x, y))
New: print((x, y))      # Not the same as print(x, y)!

شما همچنین می‌توانید جداکننده‌ی بین آیتم‌ها را سفارشی کنید، مثلاً:

print("There are <", 2**32, "> possibilities!", sep="")

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

<4294967296> امکان وجود دارد!

نکته:

• تابع print() از قابلیت فضای نرم (softspace) موجود در دستور قدیمی print پشتیبانی نمی‌کند. برای مثال، در پایتون 2.x، print "A\n", "B" رشته‌ی "A\nB\n" را می‌نوشت؛ اما در پایتون 3.0، print("A\n", "B") رشته‌ی "A\n B\n" را می‌نویسد.

• در ابتدا، متوجه خواهید شد که در حالت تعاملی، print x قدیمی را زیاد تایپ می‌کنید. وقت آن است که انگشتان خود را بازآموزی کنید تا به جای آن، print(x) را تایپ کنید!

• هنگام استفاده از ابزار تبدیل سورس به سورس 2to3، تمام دستورهای print به‌طور خودکار به فراخوانی‌های تابع print() تبدیل می‌شوند؛ بنابراین این موضوع برای پروژه‌های بزرگ‌تر عمدتاً مشکلی محسوب نمی‌شود.

نماها و پیمایش‌گرها به‌جای فهرست‌ها¶

برخی از APIهای شناخته‌شده دیگر فهرست‌ها را برنمی‌گردانند:

• متدهای dict یعنی dict.keys()، dict.items() و dict.values() به‌جای فهرست، «نما» برمی‌گردانند. برای مثال، این دیگر کار نمی‌کند: k = d.keys(); k.sort(). به‌جای آن از k = sorted(d) استفاده کنید (این در پایتون 2.5 هم کار می‌کند و به همان اندازه کارآمد است).

• همچنین، متدهای dict.iterkeys()، dict.iteritems() و dict.itervalues() دیگر پشتیبانی نمی‌شوند.

• map() و filter() پیمایش‌گر برمی‌گردانند. اگر واقعاً به یک فهرست نیاز دارید و دنباله‌های ورودی همگی طول برابر داشته باشند، یک راه‌حل سریع این است که map() را در list() دربرگیرید، مثلاً list(map(...))، اما راه‌حل بهتر اغلب استفاده از درک فهرستی است (به‌ویژه وقتی کد اصلی از lambda استفاده می‌کند)، یا بازنویسی کد به‌گونه‌ای که اصلاً به فهرست نیاز نداشته باشد. به‌ویژه دشوار حالتی است که map() برای اثرات جانبی تابع فراخوانی می‌شود؛ تبدیل صحیح، استفاده از یک حلقه‌ی معمولی for است (چون ایجاد یک فهرست صرفاً اتلاف خواهد بود).

  اگر دنباله‌های ورودی هم‌طول نباشند، map() با پایان کوتاه‌ترین دنباله متوقف می‌شود. برای سازگاری کامل با map() پایتون 2.x، دنباله‌ها را در itertools.zip_longest() نیز دربرگیرید؛ برای مثال map(func, *sequences) به list(map(func, itertools.zip_longest(*sequences))) تبدیل می‌شود.

• range() اکنون مانند رفتار پیشینِ xrange() رفتار می‌کند، با این تفاوت که با مقادیر با اندازه‌ی دلخواه کار می‌کند. دومی دیگر وجود ندارد.

• zip() اکنون یک پیمایش‌گر برمی‌گرداند.

مقایسه‌های ترتیبی¶

پایتون 3.0 قواعد مقایسه‌های ترتیبی را ساده‌سازی کرده است:

• عملگرهای مقایسه‌ی ترتیبی (<، <=، >=، >) هنگامی که عملوندها ترتیب طبیعی معناداری نداشته باشند، استثنای TypeError ایجاد می‌کنند. بنابراین، عبارت‌هایی مانند 1 < ''، 0 > None یا len <= len دیگر معتبر نیستند و برای مثال None < None به‌جای بازگرداندن False، استثنای TypeError ایجاد می‌کند. نتیجه‌ی این امر آن است که مرتب‌سازی یک فهرست ناهمگون دیگر معنایی ندارد -- همه‌ی عناصر باید با یکدیگر قابل مقایسه باشند. توجه داشته باشید که این موضوع در مورد عملگرهای == و != صدق نمی‌کند: اشیایی از نوع‌های مختلفِ غیرقابل‌مقایسه همیشه با یکدیگر نابرابر مقایسه می‌شوند.

• sorted() و list.sort() دیگر آرگومان cmp را که تابعی برای مقایسه فراهم می‌کرد، نمی‌پذیرند. به‌جای آن از آرگومان key استفاده کنید. نکته: آرگومان‌های key و reverse اکنون «صرفاً کلیدواژه‌ای» (keyword-only) هستند.

• تابع cmp() را باید حذف‌شده در نظر بگیرید و دیگر از متد ویژه‌ی __cmp__() پشتیبانی نمی‌شود. از __lt__() برای مرتب‌سازی، از __eq__() همراه با __hash__() و از سایر مقایسه‌های غنی در صورت نیاز استفاده کنید. (اگر واقعاً به کارکرد cmp() نیاز دارید، می‌توانید از عبارت (a > b) - (a < b) به‌عنوان معادل cmp(a, b) استفاده کنید.)

اعداد صحیح¶

• PEP 237: اساساً، long به int تغییر نام یافت. به عبارت دیگر، تنها یک نوع عدد صحیح توکار وجود دارد که int نام دارد؛ اما این نوع عمدتاً مانند نوع قدیمی long رفتار می‌کند.

• PEP 238: عبارتی مانند 1/2 یک عدد اعشاری برمی‌گرداند. برای دستیابی به رفتار اسلایسی، از 1//2 استفاده کنید. (سینتکس دوم سال‌هاست که وجود دارد، دست‌کم از زمان پایتون 2.2.)

• ثابت sys.maxint حذف شد، زیرا دیگر محدودیتی برای مقدار اعداد صحیح وجود ندارد. با این حال، می‌توان از sys.maxsize به‌عنوان عدد صحیحی بزرگ‌تر از هر اندیس عملی فهرست یا رشته استفاده کرد. این مقدار با اندازه‌ی «طبیعی» عدد صحیح در پیاده‌سازی مطابقت دارد و معمولاً همان sys.maxint در نسخه‌های قبلی روی همان پلتفرم است (با فرض یکسان بودن گزینه‌های ساخت).

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

• مقادیر لفظی مبنای هشت دیگر به شکل 0720 نیستند؛ به‌جای آن از 0o720 استفاده کنید.

متن در برابر داده، به‌جای یونیکد در برابر ۸-بیتی¶

همه چیزهایی که فکر می‌کردید درباره داده‌های دودویی و یونیکد می‌دانید، تغییر کرده است.

• پایتون 3.0 به جای رشته‌های یونیکد و رشته‌های ۸-بیتی، از مفاهیم متن و داده (دودویی) استفاده می‌کند. همه‌ی متن‌ها یونیکد هستند؛ با این حال، یونیکدِ کدگذاری‌شده به صورت داده‌ی دودویی نمایش داده می‌شود. نوعی که برای نگه‌داری متن استفاده می‌شود str است و نوعی که برای نگه‌داری داده استفاده می‌شود bytes است. بزرگ‌ترین تفاوت با وضعیت 2.x این است که هر تلاشی برای ترکیب متن و داده در پایتون 3.0 باعث ایجاد TypeError می‌شود، در حالی که اگر در پایتون 2.x یونیکد و رشته‌های ۸-بیتی را ترکیب می‌کردید، در صورتی که رشته‌ی ۸-بیتی اتفاقاً فقط شامل بایت‌های ۷-بیتی (اسکی) بود، کار می‌کرد، اما اگر شامل مقادیر غیراسکی بود، UnicodeDecodeError دریافت می‌کردید. این رفتار وابسته به مقدار، طی سال‌ها چهره‌های ناراحت زیادی ایجاد کرده است.

• در نتیجه‌ی این تغییر در فلسفه، تقریباً تمام کدهایی که از یونیکد، کدگذاری یا داده‌های دودویی استفاده می‌کنند، به احتمال زیاد باید تغییر کنند. این تغییر در جهت بهبود است، زیرا در دنیای 2.x اشکالات فراوانی مربوط به ترکیب متن کدگذاری‌شده و کدگذاری‌نشده وجود داشت. برای آماده بودن در پایتون 2.x، استفاده از unicode را برای تمام متن‌های کدگذاری‌نشده و استفاده از str را فقط برای داده‌های دودویی یا کدگذاری‌شده آغاز کنید. در این صورت، ابزار 2to3 بیشتر کار را برای شما انجام خواهد داد.

• دیگر نمی‌توانید از مقادیر لفظی u"..." برای متن یونیکد استفاده کنید. با این حال، باید از مقادیر لفظی b"..." برای داده‌های دودویی استفاده کنید.

• از آنجا که نوع‌های str و bytes را نمی‌توان با هم ترکیب کرد، باید همیشه تبدیل بین آن‌ها را به‌طور صریح انجام دهید. برای رفتن از str به bytes از str.encode() استفاده کنید و برای رفتن از bytes به str از bytes.decode() استفاده کنید. همچنین می‌توانید به ترتیب از bytes(s, encoding=...) و str(b, encoding=...) استفاده کنید.

• مانند str، نوع bytes تغییرناپذیر است. نوع تغییرپذیر جداگانه‌ای برای نگه‌داشتن داده‌های دودویی بافرشده وجود دارد: bytearray. تقریباً همه‌ی API‌هایی که bytes را می‌پذیرند، bytearray را نیز می‌پذیرند. API تغییرپذیر بر پایه‌ی collections.MutableSequence است.

• همه‌ی بک‌اسلش‌ها در مقادیر لفظی رشته خام به‌صورت لفظی تفسیر می‌شوند. این بدان معناست که گریزهای '\U' و '\u' در رشته‌های خام به‌طور خاص در نظر گرفته نمی‌شوند. برای مثال، r'\u20ac' در Python 3.0 رشته‌ای از ۶ نویسه است، در حالی که در 2.6، ur'\u20ac' نویسه‌ی منفرد «یورو» بود. (البته، این تغییر فقط بر مقادیر لفظی رشته خام اثر می‌گذارد؛ نویسه‌ی یورو در Python 3.0 برابر '\u20ac' است.)

• نوع انتزاعی توکار basestring حذف شد. به‌جای آن از str استفاده کنید. انواع str و bytes به‌اندازه‌ی کافی کارکرد مشترک ندارند که وجود یک کلاس پایه‌ی مشترک را توجیه کند. ابزار 2to3 (در ادامه ببینید) تمام موارد basestring را با str جایگزین می‌کند.

• پرونده‌هایی که به‌صورت پرونده متنی باز می‌شوند (که همچنان حالت پیش‌فرض تابع open() است) همیشه از یک کدگذاری برای نگاشت بین رشته‌ها (در حافظه) و بایت‌ها (روی دیسک) استفاده می‌کنند. پرونده‌های دودویی (که با b در آرگومان حالت باز می‌شوند) همیشه در حافظه از بایت‌ها استفاده می‌کنند. این بدان معناست که اگر پرونده‌ای با حالت یا کدگذاری نادرست باز شود، عملیات I/O به احتمال زیاد آشکارا شکست می‌خورد، به‌جای اینکه بی‌سروصدا داده‌های نادرست تولید کند. همچنین این بدان معناست که حتی کاربران یونیکس هم هنگام باز کردن یک پرونده باید حالت درست (متنی یا دودویی) را مشخص کنند. یک کدگذاری پیش‌فرض وابسته به پلتفرم وجود دارد که در پلتفرم‌های شبه‌یونیکس می‌توان آن را با متغیر محیطی LANG تنظیم کرد (و گاهی نیز با برخی دیگر از متغیرهای محیطی مرتبط با locale که مخصوص پلتفرم هستند). در بسیاری از موارد، اما نه همه، پیش‌فرض سیستم UTF-8 است؛ شما هرگز نباید بر این پیش‌فرض تکیه کنید. هر برنامه‌ای که چیزی بیش از متن اسکی خالص می‌خواند یا می‌نویسد، احتمالاً باید راهی برای نادیده گرفتن کدگذاری داشته باشد. دیگر هیچ نیازی به استفاده از جریان‌های آگاه از کدگذاری در ماژول codecs وجود ندارد.

• مقادیر اولیه‌ی sys.stdin، sys.stdout و sys.stderr اکنون پرونده‌های متنیِ صرفاً یونیکد هستند (یعنی نمونه‌هایی از io.TextIOBase هستند). برای خواندن و نوشتن داده‌های بایتی با این جریان‌ها، باید از ویژگی io.TextIOBase.buffer آن‌ها استفاده کنید.

• نام‌های پرونده به‌صورت رشته‌های (یونیکد) به API‌ها ارسال و از آن‌ها بازگردانده می‌شوند. این موضوع می‌تواند مشکلات خاص پلتفرم ایجاد کند، زیرا در برخی پلتفرم‌ها نام‌های پرونده رشته‌های بایتی دلخواه هستند. (از سوی دیگر، در ویندوز نام‌های پرونده به‌طور بومی به‌صورت یونیکد ذخیره می‌شوند.) به‌عنوان یک راهکار، بیشتر API‌هایی که نام پرونده می‌گیرند (مانند open() و بسیاری از توابع ماژول os)، علاوه بر رشته‌ها، اشیاء bytes را نیز می‌پذیرند و تعداد کمی از API‌ها راهی برای درخواست مقدار بازگشتی از نوع bytes دارند. بنابراین، os.listdir() اگر آرگومان آن نمونه‌ای از bytes باشد، فهرستی از نمونه‌های bytes را برمی‌گرداند و os.getcwdb() پوشه‌ی کاری جاری را به‌صورت نمونه‌ای از bytes برمی‌گرداند. توجه داشته باشید که وقتی os.listdir() فهرستی از رشته‌ها را برمی‌گرداند، نام‌های پرونده‌ای که نمی‌توان آن‌ها را به‌درستی کدگشایی کرد، به‌جای ایجاد استثنای UnicodeError حذف می‌شوند.

• برخی از APIهای سیستمی مانند os.environ و sys.argv نیز می‌توانند هنگامی که بایت‌های فراهم‌شده توسط سیستم با استفاده از کدگذاری پیش‌فرض قابل تفسیر نباشند، مشکل ایجاد کنند. تنظیم متغیر LANG و اجرای مجدد برنامه احتمالاً بهترین روش است.

• PEP 3138: خروجی repr() یک رشته دیگر نویسه‌های غیراسکی را خنثی نمی‌کند. با این حال، همچنان نویسه‌های کنترلی و نقاط کدی را که در استاندارد یونیکد وضعیت غیرقابل چاپ دارند، خنثی می‌کند.

• PEP 3120: کدگذاری پیش‌فرض کد منبع اکنون UTF-8 است.

• PEP 3131: حروف غیراسکی اکنون در شناسه‌ها مجاز هستند. (با این حال، کتابخانه استاندارد به استثنای نام مشارکت‌کنندگان در کامنت‌ها، همچنان فقط اسکی باقی می‌ماند.)

• ماژول‌های StringIO و cStringIO دیگر وجود ندارند. در عوض، ماژول io را ایمپورت کنید و برای متن و داده به ترتیب از io.StringIO یا io.BytesIO استفاده کنید.

• همچنین راهنمای عملی یونیکد را ببینید، که برای پایتون 3.0 به‌روزرسانی شده است.

سینتکس جدید¶

• PEP 3107: حاشیه‌نویسی آرگومان و مقدار بازگشتی تابع. این روشی استاندارد برای حاشیه‌نویسی پارامترهای یک تابع و مقدار بازگشتی آن فراهم می‌کند. به چنین حاشیه‌نویسی‌هایی هیچ معناشناسی متصل نیست، به‌جز اینکه می‌توان آن‌ها را در زمان اجرا با استفاده از ویژگی __annotations__ بازرسی کرد. هدف، تشویق به آزمایش از طریق فراکلاس‌ها، دکوراتورها یا چارچوب‌ها است.

• PEP 3102: آرگومان‌های فقط‌کلیدواژه‌ای. پارامترهای نام‌داری که پس از *args در فهرست پارامترها قرار می‌گیرند، باید در فراخوانی با استفاده از سینتکس کلیدواژه‌ای مشخص شوند. همچنین می‌توانید از یک * تنها در فهرست پارامترها استفاده کنید تا نشان دهید که فهرست آرگومان‌های با طول متغیر را نمی‌پذیرید، اما آرگومان‌های فقط‌کلیدواژه‌ای دارید.

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

• PEP 3104: دستور nonlocal. اکنون با استفاده از nonlocal x می‌توانید مستقیماً به متغیری در یک محدوده‌ی بیرونی (اما غیرسراسری) انتساب دهید. nonlocal یک واژه‌ی رزرو‌شده‌ی جدید است.

• PEP 3132: واگشایی گسترش‌یافته‌ی پیمایش‌پذیرها. اکنون می‌توانید چیزهایی مانند a, b, *rest = some_sequence بنویسید. و حتی *rest, a = stuff. شیء rest همیشه یک فهرست (که ممکن است خالی باشد) است؛ سمت راست می‌تواند هر شیء پیمایش‌پذیری باشد. مثال:

  (a, *rest, b) = range(5)
  

  این کار a را برابر 0، b را برابر 4 و rest را برابر [1, 2, 3] قرار می‌دهد.

• درک دیکشنری: {k: v for k, v in stuff} همان معنی dict(stuff) را دارد، اما انعطاف‌پذیرتر است. (این همان PEP 274 است که حقانیتش اثبات شد. :-)

• مقادیر لفظی مجموعه، مثلاً {1, 2}. توجه داشته باشید که {} یک دیکشنری خالی است؛ برای مجموعه‌ی خالی از set() استفاده کنید. از درک مجموعه نیز پشتیبانی می‌شود؛ مثلاً {x for x in stuff} همان معنای set(stuff) را دارد، اما انعطاف بیشتری دارد.

• مقادیر لفظی مبنای هشت جدید، مثلاً 0o720 (از قبل در 2.6 موجود بود). مقادیر لفظی مبنای هشت قدیمی (0720) دیگر وجود ندارند.

• مقادیر لفظی دودویی جدید، مثلاً 0b1010 (از قبل در 2.6 موجود بود)، و یک تابع توکار متناظر جدید وجود دارد: bin().

• مقادیر لفظی بایت با یک پیشوند b یا B معرفی می‌شوند و یک تابع توکار جدید متناظر با آن‌ها وجود دارد: bytes().

سینتکس تغییر‌یافته¶

• PEP 3109 و PEP 3134: سینتکس جدید دستور raise: raise [expr [from expr]]. در ادامه ببینید.

• as و with اکنون کلیدواژه‌های رزروشده هستند. (در واقع از نسخه 2.6.)

• True، False و None واژه‌های رزرو‌شده هستند. (2.6 قبلاً محدودیت‌های مربوط به None را به‌طور جزئی اعمال کرده بود.)

• تغییر از except exc, var به except exc as var. به PEP 3110 مراجعه کنید.

• PEP 3115: سینتکس جدید فراکلاس. به جای:

  class C:
      __metaclass__ = M
      ...
  

  اکنون باید استفاده کنید از:

  class C(metaclass=M):
      ...
  

  متغیر سراسریِ ماژول __metaclass__ دیگر پشتیبانی نمی‌شود. (این یک وسیله‌ی کمکی بود تا کلاس‌ها به‌طور پیش‌فرض از نوع سبک جدید (new-style) باشند، بدون آنکه هر کلاس از object مشتق شود.)

• درک‌های فهرستی دیگر از شکل نحوی [... for var in item1, item2, ...] پشتیبانی نمی‌کنند. به‌جای آن از [... for var in (item1, item2, ...)] استفاده کنید. همچنین توجه داشته باشید که درک‌های فهرستی معناشناسی متفاوتی دارند: آن‌ها بیشتر شبیه قند نحوی برای یک عبارت تولیدگر درون سازنده‌ی list() هستند و به‌طور خاص، متغیرهای کنترل حلقه دیگر به محدوده‌ی اطراف نشت نمی‌کنند.

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

سینتکس حذف‌شده¶

• PEP 3113: واگشایی پارامتر تاپل حذف شد. شما دیگر نمی‌توانید def foo(a, (b, c)): ... بنویسید. به جای آن از def foo(a, b_c): b, c = b_c استفاده کنید.

• بک‌تیک‌ها حذف شدند (به‌جای آن‌ها از repr() استفاده کنید).

• <> حذف شد (به‌جای آن از != استفاده کنید).

• کلیدواژه حذف‌شده: exec() دیگر یک کلیدواژه نیست؛ بلکه به‌عنوان یک تابع باقی مانده است. (خوشبختانه سینتکس تابع در 2.x نیز پذیرفته می‌شد.) همچنین توجه داشته باشید که exec() دیگر آرگومان جریان نمی‌پذیرد؛ به‌جای exec(f) می‌توانید از exec(f.read()) استفاده کنید.

• مقادیر لفظی عدد صحیح دیگر از پسوند l یا L پشتیبانی نمی‌کنند.

• رشته‌های لفظی دیگر از پیشوند u یا U پشتیبانی نمی‌کنند.

• سینتکس from ماژول import * تنها در سطح ماژول مجاز است و دیگر درون توابع مجاز نیست.

• تنها سینتکس قابل قبول برای ایمپورت‌های نسبی، from .[module] import name است. تمام شکل‌های import که با . شروع نمی‌شوند، به‌عنوان ایمپورت‌های مطلق تفسیر می‌شوند. (PEP 328)

• کلاس‌های کلاسیک حذف شده‌اند.

عملگرها و متدهای ویژه¶

• اکنون != مخالفِ == را برمی‌گرداند، مگر اینکه == مقدار NotImplemented را برگرداند.

• مفهوم «متدهای غیرمقید» (unbound methods) از زبان حذف شده است. هنگام ارجاع به یک متد به‌عنوان ویژگی کلاس، اکنون یک شیء تابع ساده دریافت می‌کنید.

• __getslice__()، __setslice__() و __delslice__() حذف شدند. سینتکس a[i:j] اکنون به a.__getitem__(slice(i, j)) تبدیل می‌شود (یا __setitem__() یا __delitem__()، وقتی به‌ترتیب به‌عنوان هدف انتساب یا هدف حذف استفاده شود).

• PEP 3114: متد استاندارد next() به __next__() تغییر نام یافته است.

• متدهای ویژه‌ی __oct__() و __hex__() حذف شده‌اند -- oct() و hex() اکنون برای تبدیل آرگومان به عدد صحیح از __index__() استفاده می‌کنند.

• پشتیبانی از __members__ و __methods__ حذف شد.

• ویژگی‌های تابع با نام func_X برای استفاده از شکل __X__ تغییر نام داده شده‌اند و بدین ترتیب این نام‌ها در فضای نام ویژگی‌های تابع برای ویژگی‌های تعریف‌شده توسط کاربر آزاد می‌شوند. به‌طور مشخص، func_closure، func_code، func_defaults، func_dict، func_doc، func_globals و func_name به ترتیب به __closure__، __code__، __defaults__، __dict__، __doc__، __globals__ و __name__ تغییر نام داده شدند.

• __nonzero__() اکنون __bool__() است.

توکارها¶

• PEP 3135: super() جدید. اکنون می‌توانید super() را بدون آرگومان فراخوانی کنید و (با فرض اینکه این در یک متد نمونه‌ی معمولی تعریف‌شده درون دستور class باشد) کلاس و نمونه‌ی درست به‌طور خودکار انتخاب خواهند شد. با آرگومان‌ها، رفتار super() بدون تغییر است.

• PEP 3111: raw_input() به input() تغییر نام یافت. یعنی، تابع جدید input() یک سطر را از sys.stdin می‌خواند و آن را با حذف سطر جدید انتهایی برمی‌گرداند. اگر ورودی پیش از موعد خاتمه یابد، EOFError مطرح می‌شود. برای به‌دست آوردن رفتار قدیمی input()، از eval(input()) استفاده کنید.

• تابع توکار جدید next() برای فراخوانی متد __next__() بر روی یک شیء اضافه شد.

• راهبرد گرد کردن و نوع بازگشتی تابع round() تغییر کرده‌اند. حالت‌های دقیقاً میانی اکنون به نزدیک‌ترین نتیجه‌ی زوج گرد می‌شوند، نه به سمت دور از صفر. (برای مثال، round(2.5) اکنون 2 را برمی‌گرداند، نه 3.) round(x[, n]) اکنون به جای اینکه همیشه یک عدد اعشاری برگرداند، کار را به x.__round__([n]) واگذار می‌کند. این تابع به‌طور کلی هنگام فراخوانی با یک آرگومان، یک عدد صحیح و هنگام فراخوانی با دو آرگومان، مقداری از همان نوع x برمی‌گرداند.

• intern() به sys.intern() منتقل شد.

• حذف‌شده: apply(). به جای apply(f, args) از f(*args) استفاده کنید.

• تابع callable() حذف شد. به جای callable(f) می‌توانید از isinstance(f, collections.Callable) استفاده کنید. تابع operator.isCallable() نیز حذف شده است.

• تابع coerce() حذف شد. این تابع اکنون که کلاس‌های کلاسیک از بین رفته‌اند، دیگر کاربردی ندارد.

• execfile() حذف شد. به جای execfile(fn) از exec(open(fn).read()) استفاده کنید.

• نوع file حذف شد. از open() استفاده کنید. اکنون چندین نوع مختلف از جریان‌ها وجود دارد که open می‌تواند در ماژول io برگرداند.

• reduce() حذف شد. اگر واقعاً به آن نیاز دارید، از functools.reduce() استفاده کنید؛ با این حال، در ۹۹ درصد موارد یک حلقه‌ی صریح for خواناتر است.

• reload() حذف شد. از imp.reload() استفاده کنید.

• حذف شد. dict.has_key() -- به جای آن از عملگر in استفاده کنید.