Tại sao mọi người ngần ngại sử dụng Python 3?

Python 3 đã được phát hành vào tháng 12 năm 2008. Đã có rất nhiều thời gian trôi qua nhưng đến nay vẫn có nhiều nhà phát triển ngần ngại sử dụng Python 3. Ngay cả các khung phổ biến như Django vẫn chưa tương thích với Python 3 nhưng vẫn dựa vào Python 2.

Chắc chắn, Python 3 có một số điểm không tương thích với Python 2 và một số người cần dựa vào khả năng tương thích ngược. Nhưng không phải Python 3 đã tồn tại đủ lâu để hầu hết các dự án chuyển đổi hoặc bắt đầu với Python 3?

Có hai phiên bản cạnh tranh có rất nhiều nhược điểm; hai ngành cần được duy trì, gây nhầm lẫn cho người học và như vậy. Vậy tại sao có quá nhiều do dự trong cộng đồng Python về việc chuyển sang Python 3?

Lưu ý rằng tôi không còn cập nhật câu trả lời này. Tôi có một câu hỏi và trả lời về Python 3 dài hơn trên trang cá nhân của tôi tại http://python-notes.curiouseffic.org/en/latest/python3/questions_and_answers.html

Câu trả lời trước:

(Cập nhật trạng thái, tháng 9 năm 2012)

Chúng tôi (tức là các nhà phát triển lõi Python) đã dự đoán khi Python 3.0 được phát hành rằng sẽ mất khoảng 5 năm để 3.x trở thành lựa chọn "mặc định" cho các dự án mới trong loạt 2.x. Dự đoán đó là lý do tại sao thời gian bảo trì theo kế hoạch cho phiên bản 2.7 quá dài.

Bản phát hành Python 3.0 ban đầu cũng có một số vấn đề nghiêm trọng với hiệu suất IO kém khiến nó không thể sử dụng được cho hầu hết các mục đích thực tế, do đó, sẽ hợp lý hơn khi bắt đầu dòng thời gian từ việc phát hành Python 3.1 vào cuối tháng 6 năm 2009. (Những Các vấn đề về hiệu suất IO cũng là lý do tại sao không có bản phát hành bảo trì 3.0.z: không có lý do chính đáng để bất cứ ai muốn gắn bó với 3.0 hơn là nâng cấp lên 3.1).

Tại thời điểm viết (tháng 9 năm 2012), điều đó có nghĩa là chúng tôi hiện đang trải qua quá trình chuyển đổi hơn 3 năm và dự đoán đó dường như vẫn đang đi đúng hướng.

Mặc dù những người gõ mã Python 3 thường xuyên bị cắn bởi các thay đổi cú pháp như printtrở thành một hàm, nhưng điều đó thực sự không gây rắc rối cho việc chuyển thư viện vì 2to3công cụ chuyển đổi tự động xử lý nó khá vui vẻ.

Vấn đề lớn nhất trong thực tế là vấn đề ngữ nghĩa: Python 3 không cho phép bạn chơi nhanh và lỏng lẻo với mã hóa văn bản theo cách Python 2 làm. Đây vừa là lợi ích lớn nhất của nó so với Python 2, nhưng cũng là rào cản lớn nhất đối với việc chuyển cổng: bạn phải khắc phục các sự cố xử lý Unicode để có một cổng hoạt động chính xác (trong khi trong 2.x, rất nhiều mã đó đã âm thầm tạo ra dữ liệu không chính xác với đầu vào không phải ASCII, tạo ấn tượng làm việc, đặc biệt là trong các môi trường nơi dữ liệu không phải ASCII không phổ biến).

Ngay cả thư viện chuẩn trong Python 3.0 và 3.1 vẫn có vấn đề xử lý Unicode, khiến việc chuyển nhiều thư viện trở nên khó khăn (đặc biệt là các thư viện liên quan đến dịch vụ web).

3.2 đã giải quyết rất nhiều vấn đề đó, cung cấp mục tiêu tốt hơn cho các thư viện và khung như Django. 3.2 cũng mang phiên bản làm việc đầu tiên của wsgiref(tiêu chuẩn chính được sử dụng để liên lạc giữa các máy chủ web và các ứng dụng web được viết bằng Python) cho 3.x, đây là điều kiện tiên quyết cần thiết để áp dụng trong không gian web.

Các phụ thuộc chính như NumPy và SciPy hiện đã được chuyển, các công cụ quản lý cài đặt và phụ thuộc như zc.buildout, pipvà virtualenvcó sẵn cho 3.x, bản phát hành Pyramid 1.3 hỗ trợ Python 3.2, bản phát hành Django 1.5 sắp tới bao gồm hỗ trợ Python 3 thử nghiệm và bản phát hành 12.0 của khung mạng Twisted đã bỏ hỗ trợ Python 2.5 để mở đường cho việc tạo phiên bản tương thích với Python 3.

Ngoài tiến trình trên các thư viện và khung tương thích Python 3, triển khai trình thông dịch PyPy do JIT biên dịch phổ biến đang tích cực làm việc trên hỗ trợ Python 3.

Các công cụ để quản lý quá trình di chuyển cũng đã được cải thiện rõ rệt. Ngoài 2to3công cụ được cung cấp như một phần của CPython (hiện được coi là phù hợp nhất cho các chuyển đổi ứng dụng một lần không cần duy trì hỗ trợ cho loạt 2.x), còn có python-modernize, sử dụng 2to3cơ sở hạ tầng để nhắm mục tiêu tập hợp con chung (lớn) của Python 2 và Python 3. Công cụ này tạo ra một cơ sở mã duy nhất sẽ chạy trên cả Python 2.6+ và Python 3.2+ với sự trợ giúp của sixthư viện tương thích. Bản phát hành Python 3.3 cũng loại bỏ một nguyên nhân chính gây ra "nhiễu" khi di chuyển các ứng dụng nhận biết Unicode hiện có: Python 3.3 một lần nữa hỗ trợ tiền tố 'u' cho các chuỗi ký tự (thực tế không phải vậybất cứ điều gì trong Python 3 - nó chỉ được khôi phục để tránh việc vô tình chuyển sang Python 3 khó hơn đối với người dùng đã phân biệt chính xác văn bản và chữ nhị phân của họ trong Python 2).

Vì vậy, chúng tôi thực sự khá hài lòng với cách mọi thứ đang tiến triển - vẫn còn gần 2 năm để đi vào khung thời gian ban đầu của chúng tôi và những thay đổi đang diễn ra tốt đẹp trong toàn bộ hệ sinh thái Python.

Do nhiều dự án không quản lý siêu dữ liệu Chỉ số gói Python của họ một cách chính xác và một số dự án có các nhà bảo trì ít hoạt động hơn đã được chia rẽ để thêm hỗ trợ Python 3, máy quét PyPI hoàn toàn tự động vẫn đưa ra cái nhìn quá tiêu cực về trạng thái của thư viện Python 3 ủng hộ.

Một lựa chọn thay thế ưa thích để có được thông tin về mức độ hỗ trợ Python 3 trên PyPI là http://py3ksupport.appspot.com/

Danh sách này được Brett Cannon (một nhà phát triển lõi Python lâu năm) quản lý để tính toán siêu dữ liệu dự án không chính xác, hỗ trợ Python 3 trong các công cụ kiểm soát nguồn nhưng chưa được phát hành chính thức và các dự án có nhiều bản cập nhật hơn hoặc các lựa chọn thay thế hỗ trợ Python 3. Trong nhiều trường hợp, các thư viện chưa có sẵn trên Python 3 bị thiếu phụ thuộc khóa và / hoặc thiếu hỗ trợ Python 3 trong các dự án khác làm giảm nhu cầu của người dùng (ví dụ: khi khung Django lõi có sẵn trên Python 3, các công cụ liên quan như South và django-celery có nhiều khả năng thêm hỗ trợ Python 3 và tính khả dụng của hỗ trợ Python 3 trong cả Pyramid và Django khiến cho nhiều khả năng hỗ trợ Python 3 sẽ được triển khai trong các công cụ khác như gevent).

Trang web tại http://getpython3.com/ bao gồm một số liên kết tuyệt vời đến sách và các tài nguyên khác cho Python 3, xác định một số thư viện và khung chính đã hỗ trợ Python 3 và cũng cung cấp một số thông tin về cách các nhà phát triển có thể tìm kiếm hỗ trợ tài chính từ PSF trong việc chuyển các dự án chính sang Python 3.

Một tài nguyên tốt khác là trang wiki cộng đồng về các yếu tố cần xem xét khi chọn phiên bản Python cho dự án mới: http://wiki.python.org/moin/Python2orPython3

Tôi tin rằng rất nhiều sự do dự đến từ hai điều:

• Nếu nó không bị hỏng, đừng sửa nó
• [Thư viện XYZ] chúng tôi yêu cầu không có cổng 3.0

Có khá nhiều điểm khác biệt trong cách ứng xử của ngôn ngữ cốt lõi, được nêu trong tài liệu này . Chẳng hạn, việc thay đổi "in" từ câu lệnh thành hàm, sẽ phá vỡ rất nhiều mã Python 2.x - và đó chỉ là cách đơn giản nhất. Họ đã loại bỏ hoàn toàn các lớp học kiểu cũ trong 3.0. Trên thực tế, chúng là các ngôn ngữ khá khác nhau - vì vậy việc chuyển mã cũ không đơn giản như một số ngôn ngữ có thể giả định.

Không có lý do bắt buộc để các doanh nghiệp hiện tại dành thời gian, tiền bạc và nỗ lực di chuyển đến một cái gì đó trong khi không có thay đổi trong bộ tính năng hiện có. Tôi muốn nói rằng mã cơ sở trên loạt Python 2 đã hoạt động trong một thời gian dài ổn định, được thử nghiệm và có tất cả các tính năng sản phẩm hiện tại được thiết lập. Tại sao mọi người sẽ dành thời gian, tiền bạc và công sức chỉ để di chuyển Python 3 chỉ vì mục đích di chuyển sang nó.

Bên cạnh việc di chuyển bài đảm bảo không có thất bại hồi quy và tất cả những gì đau đầu là không thể tránh khỏi.

Đối với các dự án mới, chính sách đơn giản và đơn giản, tất cả bắt đầu ở các điểm sau:

1. Có bất kỳ bản phân phối nào như Ubuntu gửi Python 3 trong cài đặt mặc định của họ không?
2. Hệ sinh thái thư viện cho Python 3 là gì.
3. Có phải tất cả các khung et al đều tương thích với Python 3. vv

Đó là quy trình 'chọn ngôn ngữ mới' thông thường của bạn. Đây là lúc vấn đề trứng gà xuất hiện, Không nhiều người đang sử dụng nó vì không có nhiều người sử dụng nó. Cuối cùng không ai cảm thấy muốn chuyển đến nó cả.

Khả năng tương thích ngược chưa bao giờ là một điều tốt, cuối cùng, bạn luôn kết thúc một tỷ lệ người dùng tốt.

Trong khoảng thời gian Python 2.0 được phát hành, Python đã nhanh chóng phổ biến. Có rất nhiều người dùng mới sử dụng phiên bản mới nhất một cách tự nhiên, vì họ không phụ thuộc vào các phiên bản cũ hơn. Với nhiều người áp dụng 2.0 theo mặc định, có rất nhiều áp lực đối với các nhà phát triển thư viện, v.v.

Vào thời điểm Python 3.0 được phát hành, đã có một số lượng lớn người dùng phụ thuộc vào Python 2.0 và sự tăng trưởng theo cấp số nhân (giữ một yếu tố không đổi so với người dùng hiện tại) rõ ràng không thể duy trì lâu dài.

Cá nhân, các tính năng mới trở lại trong Python 2 ngày có vẻ hấp dẫn hơn nhiều so với các tính năng do Python 3 cung cấp.

Tôi đã từng nghĩ Python 3 cuối cùng sẽ tiếp quản, nhưng bây giờ tôi không chắc lắm. Nhưng nó không chỉ là Python có vấn đề này. Rốt cuộc, có bao nhiêu người trung thực sử dụng Perl 6? Điều đó đã tồn tại lâu hơn một chút so với Python 3, IIRC.

Một công cụ chặn chương trình lớn đối với tôi, mà tôi không nghĩ có thể được giải quyết bằng bản dịch tự động, là phân chia số nguyên. Tôi có các mã khoa học dựa vào x / 2 cho x làm tròn xuống (khi x là số nguyên).

Python 3 sẽ không làm điều đó, nhưng sẽ đưa ra câu trả lời .5 (cho số lẻ x).
Tôi không thể chỉ thay thế tất cả / trong mã của mình bằng // vì đôi khi tôi thực hiện phép chia float và vì vậy muốn có hành vi float.

Vì vậy, để tôi chuyển sang python 3, tôi sẽ phải duyệt qua hàng chục ngàn dòng mã, kiểm tra mỗi / và xem liệu tôi có thể biết liệu nó nên / hoặc //.

Python 3 thật tuyệt khi bắt đầu một dự án mới nếu tất cả các thư viện bạn cần đã được chuyển sang Py3k.

Nếu đây không phải là một tùy chọn, sử dụng Python 2.7 là tốt nhất của cả hai thế giới: bạn có hầu hết mọi thư viện được tạo cho Python 2.x và bạn có thể dần dần thay đổi mã của mình để tương thích với Py3k, do đó việc di chuyển trở nên dễ dàng khi bạn quyết định nó Danh sách các cú pháp cú pháp từ Py3k bạn đã có trong 2.7 khá dài, đừng quên nhập từ __future__. Yêu thích của tôi là Unicode theo mặc định và bộ phận luôn tạo ra một float.

Từ góc độ dịch vụ web: Không có khung máy chủ chính cũng như khung web nào hỗ trợ Python3.

Cập nhật: Rõ ràng đó là trường hợp vào đầu năm 2011, tính đến thời điểm hiện tại (cuối năm 2013), hầu hết các khung công tác chính đang hoạt động với Python3. Tuy nhiên một số vẫn không tương thích. Ví dụ đáng kể sẽ là Twisted, nơi nó vẫn đang hoạt động .

Không có lý do thuyết phục nào tôi từng thấy để sử dụng P3K trừ khi bạn đang làm công việc nặng i18n. Trong những lần chuyển đổi của mình, tôi đã thấy Unicode phổ biến là một rào cản đối với công việc (ASCII) của tôi và các trình tạo bắt buộc để làm tắc mã của tôi.

Trong một vài năm, 3 sẽ trình bày một môi trường hấp dẫn hơn, nhưng, không phải hôm nay.

Các bản phân phối không cung cấp Python3. Có một số phân phối rìa đã chuyển ra khỏi Python2. Nhưng các biến thể Linux chính thống như Debian, Ubuntu, v.v. Đó là lý do chính khiến tôi là tác giả ứng dụng cũng không làm.

Mặc dù tôi đã chuẩn bị quá trình chuyển đổi và thậm chí cố gắng tránh các cấu trúc cú pháp không tương thích , tôi không thể kiểm tra nó một cách chính xác. Nó sôi sùng sục đến vấn đề gà và trứng thực sự.