Зауважте, що я більше не оновлюю цю відповідь. У мене набагато довше питання і відповіді на Python 3 на особистому веб-сайті http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html
Попередня відповідь:
(Оновлення статусу, вересень 2012 р.)
Ми (тобто розробники ядра Python) передбачили, коли Python 3.0 вийде, що піде приблизно 5 років, щоб 3.x став вибором "за замовчуванням" для нових проектів протягом серії 2.x. Це прогноз, чому запланований період технічного обслуговування для випуску 2,7 настільки довгий.
Оригінальний випуск Python 3.0 також виявив деякі критичні проблеми з низькою продуктивністю вводу-виводу, що зробило його практично непридатним для використання в більшості практичних цілей, тому більш доцільним є запуск часової шкали з виходу Python 3.1 наприкінці червня 2009 року. Проблеми з роботою IO також є причиною того, що немає версій технічного обслуговування 3.0.z: немає жодної вагомої причини, коли хтось не захоче дотримуватися версії 3.0 над оновленням до 3.1).
На момент написання (вересень 2012 р.) Це означає, що ми зараз трохи більше 3 років переходимо до процесу переходу, і це прогноз все ще здається на шляху.
Хоча люди, які набирають код Python 3, найчастіше кусаються за допомогою синтаксичних змін, таких як printперетворення на функцію, що насправді не є клопотом для перенесення бібліотеки, оскільки автоматизований 2to3інструмент перетворення обробляє це досить щасливо.
Найбільшою проблемою на практиці є насправді семантична проблема: Python 3 не дозволяє вам швидко і вільно грати з текстовими кодуваннями, як це робить Python 2. Це і найбільша перевага для Python 2, але і найбільший бар'єр для перенесення: вам потрібно виправити проблеми з обробкою Unicode, щоб порт працював правильно (тоді як у 2.x багато цього коду мовчки видавали невірні дані з не вхідні дані ASCII, що створює враження роботи, особливо в умовах, коли дані, що не належать до ASCII, є рідкістю).
Навіть у стандартній бібліотеці в Python 3.0 та 3.1 все ще виникали проблеми з обробкою Unicode, що ускладнює перенесення багатьох бібліотек (особливо тих, що стосуються веб-служб).
3.2 вирішено багато таких проблем, забезпечуючи набагато кращу ціль для бібліотек та рамок, таких як Django. 3.2 також представлена перша робоча версія wsgiref(основний стандарт, що використовується для зв'язку між веб-серверами та веб-додатками, написаними на Python) для 3.x, що було необхідною умовою для прийняття у веб-просторі.
Основна залежність , як NumPy і SciPy тепер було перенесено, установка і управління залежностями інструменти , такі як zc.buildout, pipі virtualenvдоступні для 3.x, реліз Pyramid 1.3 підтримує Python 3.2, майбутня Джанго 1,5 релізу включає в себе експериментальну підтримку Python 3, і випуску 12,0 Система Twisted Networks знизила підтримку Python 2.5, щоб прокласти шлях для створення сумісної версії Python 3.
На додаток до прогресу бібліотек та фреймворків сумісності Python 3, популярна реалізація інтерпретатора PyPy, складеного JIT, активно працює над підтримкою Python 3.
Інструменти управління процесом міграції також помітно покращилися. На додаток до 2to3інструменту, що надається у складі CPython (який зараз вважається найкращим для одноразових перетворень програм, яким не потрібно підтримувати підтримку серії 2.x), є також python-modernize, який використовує 2to3інфраструктуру для націлювання (великий) загальний підмножина Python 2 та Python 3. Цей інструмент створює єдину базу коду, яка працюватиме як на Python 2.6+, так і на Python 3.2+ за допомогою sixбібліотеки сумісності. Випуск Python 3.3 також усуває одну з основних причин "шуму" під час міграції існуючих програм, які знають Unicode: Python 3.3 ще раз підтримує префікс 'u' для рядкових літералів (він насправді не робитьщо - небудь в Python 3 - це тільки що було відновлено , щоб уникнути випадкового внесення переходу на Python 3 важче для користувачів , які вже правильно відзначилися їх текст і бінарні літерали в Python 2).
Таким чином, ми насправді дуже задоволені тим, як все прогресує - ще є майже два роки, щоб продовжити свій початковий часовий проміжок, і зміни непогано прорізаються через всю екосистему Python.
Оскільки багато проектів не виліковують метадані Python Package Index належним чином, а деякі проекти з менш активним обслуговуючим персоналом отримали можливість додавати підтримку Python 3, чисто автоматизовані сканери PyPI все ще надають надто негативне уявлення про стан бібліотеки Python 3 підтримка.
Кращою альтернативою для отримання інформації про рівень підтримки Python 3 на PyPI є http://py3ksupport.appspot.com/
Цей список особисто підготовлений Бреттом Кенноном (давнім розробником ядра Python) для обліку невірних метаданих проекту, підтримка Python 3, що знаходиться в інструментах контролю джерел, але ще не є офіційним випуском, та проекти, які мають більш сучасні вилки або альтернативи, що підтримують Python 3. У багатьох випадках у бібліотеках, які ще не доступні на Python 3, відсутні ключові залежності та / або відсутність підтримки Python 3 в інших проектах зменшується попит користувачів (наприклад, коли основна рамка Django буде доступна на Python 3, пов'язані такі інструменти, як South та django-celery, швидше додають підтримку Python 3, а наявність підтримки Python 3 і в Pyramid, і в Django робить більш ймовірним, що підтримка Python 3 буде реалізована в інших інструментах, таких як gevent).
Сайт на веб- сайті http://getpython3.com/ включає в себе чудові посилання на книги та інші ресурси для Python 3, визначає деякі ключові бібліотеки та рамки, які вже підтримують Python 3, а також надає деяку інформацію про те, як розробники можуть звернутися за фінансовою допомогою до PSF при перенесенні ключових проектів на Python 3.
Ще один хороший ресурс - сторінка вікі спільноти про фактори, які слід враховувати при виборі версії Python для нового проекту: http://wiki.python.org/moin/Python2orPython3