Python 4 được phát hành khi nào?

Những người mới làm quen với ý tưởng python đôi khi tham khảo ý tưởng "Python 4000" khi đề xuất các thay đổi không tương thích ngược không cung cấp đường dẫn di chuyển rõ ràng từ mã Python 3 hợp pháp hiện tại. Xét cho cùng, chúng tôi đã cho phép loại thay đổi đó đối với Python 3. 0, vậy tại sao chúng tôi không cho phép nó cho Python 4. 0?

Tôi đã nghe câu hỏi đó đủ nhiều lần rồi [bao gồm cả cụm từ được quan tâm hơn "Bạn đã thực hiện một lần vi phạm khả năng tương thích ngược lớn, làm sao tôi biết bạn sẽ không lặp lại điều đó nữa?"], nên tôi nghĩ rằng tôi nên ghi lại câu trả lời của mình tại đây

Kỳ vọng hiện tại đối với Python 4 là gì. 0?

Lập trình và phát triển

• Blog nhà phát triển mũ đỏ
• Lập trình cheat sheet
• Thử miễn phí. Đăng ký học Red Hat
• sách điện tử. Giới thiệu về lập trình với Bash
• Bash Shell Scripting Cheat Sheet
• sách điện tử. Hiện đại hóa doanh nghiệp Java

Kỳ vọng hiện tại của tôi là Python 4. 0 sẽ chỉ là "bản phát hành sau Python 3. 9". Đó là nó. Không có thay đổi sâu sắc nào đối với ngôn ngữ, không có sự cố tương thích ngược lớn nào - bắt nguồn từ Python 3. 9 đến 4. 0 sẽ ổn định như đi từ Python 3. 3 đến 3. 4 [hoặc từ 2. 6 đến 2. 7]. Tôi thậm chí mong đợi Giao diện nhị phân ứng dụng ổn định [như được xác định lần đầu trong PEP 384] sẽ được giữ nguyên qua ranh giới

Với tốc độ phát hành tính năng ngôn ngữ hiện tại [khoảng 18 tháng một lần], điều đó có nghĩa là chúng ta có thể sẽ thấy Python 4. 0 vào năm 2023, thay vì xem Python 3. 10

Vậy Python sẽ tiếp tục phát triển như thế nào?

Đầu tiên và quan trọng nhất, không có gì thay đổi về quy trình Đề xuất cải tiến Python - các thay đổi tương thích ngược vẫn được đề xuất mọi lúc, với các mô-đun mới [như asyncio] và các tính năng ngôn ngữ [như yield from] được thêm vào để nâng cao khả năng có sẵn cho các ứng dụng Python. Thời gian trôi qua, Python 3 sẽ tiếp tục vượt xa Python 2 về các khả năng mà nó cung cấp theo mặc định, ngay cả khi người dùng Python 2 có quyền truy cập vào các khả năng tương đương thông qua các mô-đun bên thứ ba hoặc các bản nhập từ Python 3

Các tiện ích mở rộng và triển khai trình thông dịch cạnh tranh cũng sẽ tiếp tục khám phá các cách khác nhau để nâng cao Python, bao gồm khám phá của PyPy về tạo trình biên dịch JIT và bộ nhớ giao dịch phần mềm, cũng như khám phá của cộng đồng khoa học và phân tích dữ liệu về lập trình hướng mảng tận dụng tối đa khả năng vector hóa được cung cấp . Khả năng tích hợp với các thời gian chạy máy ảo khác [như JVM và CLR] cũng được dự kiến ​​sẽ cải thiện theo thời gian, đặc biệt khi những bước tiến mà Python đang tạo ra trong lĩnh vực giáo dục có thể sẽ khiến nó trở nên phổ biến hơn bao giờ hết như một ngôn ngữ kịch bản nhúng trong các ứng dụng lớn hơn chạy trong

Đối với các thay đổi không tương thích ngược, PEP 387 cung cấp thông tin tổng quan hợp lý về phương pháp đã được sử dụng trong nhiều năm trong chuỗi Python 2 và vẫn được áp dụng cho đến ngày nay. nếu một tính năng được xác định là quá có vấn đề, thì tính năng đó có thể không được dùng nữa và cuối cùng bị xóa

Tuy nhiên, một số thay đổi khác đã được thực hiện đối với quy trình phát triển và phát hành khiến cho việc ngừng sử dụng như vậy sẽ ít cần thiết hơn trong chuỗi Python 3

• sự nhấn mạnh nhiều hơn vào Chỉ mục gói Python, thể hiện qua sự hợp tác giữa nhóm phát triển cốt lõi CPython và Cơ quan quản lý bao bì Python, cũng như gói trình cài đặt pip với Python 3. 4+, giảm áp lực phải thêm các mô-đun vào thư viện chuẩn trước khi chúng đủ ổn định để đáp ứng chu kỳ cập nhật ngôn ngữ tương đối chậm
• khái niệm "API tạm thời" [được giới thiệu trong PEP 411] cho phép áp dụng giai đoạn "quyết định" cho các thư viện và API được đánh giá là có khả năng hưởng lợi từ phản hồi rộng hơn trước khi đưa ra các đảm bảo về khả năng tương thích ngược tiêu chuẩn
• rất nhiều hành vi kế thừa tích lũy thực sự đã bị loại bỏ trong quá trình chuyển đổi Python 3 và các yêu cầu đối với các bổ sung mới cho Python và thư viện chuẩn hiện nay nghiêm ngặt hơn nhiều so với trong Python 1. x và Python 2. x ngày
• sự phát triển rộng rãi của các thư viện và khung Python 2/3 "nguồn đơn" khuyến khích mạnh mẽ việc sử dụng "không dùng nữa" trong Python 3, ngay cả khi các tính năng được thay thế bằng các lựa chọn thay thế mới hơn, được ưu tiên hơn. Trong những trường hợp này, một thông báo ngừng sử dụng được đặt trong tài liệu, gợi ý cách tiếp cận được ưu tiên cho mã mới, nhưng không có cảnh báo ngừng sử dụng có lập trình nào được thêm vào. Điều này cho phép mã hiện có, bao gồm mã hỗ trợ cả Python 2 và Python 3, không bị thay đổi [với chi phí là người dùng mới có khả năng phải tìm hiểu thêm một chút khi được giao nhiệm vụ duy trì cơ sở mã hiện có]

Từ [hầu hết] tiếng Anh đến tất cả các ngôn ngữ viết

Cũng cần lưu ý rằng Python 3 không được kỳ vọng sẽ gây rối như hóa ra. Trong số tất cả các thay đổi không tương thích ngược trong Python 3, nhiều rào cản nghiêm trọng đối với việc di chuyển có thể được đặt dưới chân một dấu đầu dòng nhỏ trong PEP 3100

• Đặt tất cả các chuỗi thành Unicode và có loại byte[] riêng biệt. Loại chuỗi mới sẽ được gọi là 'str'

PEP 3100 là ngôi nhà cho những thay đổi của Python 3 được coi là đủ không gây tranh cãi đến mức không có PEP riêng biệt nào được coi là cần thiết. Lý do thay đổi cụ thể này được coi là không gây tranh cãi là vì trải nghiệm của chúng tôi với Python 2 đã chỉ ra rằng các tác giả của khung web và GUI đã đúng. Xử lý hợp lý Unicode với tư cách là nhà phát triển ứng dụng có nghĩa là đảm bảo tất cả dữ liệu văn bản được chuyển đổi từ dạng nhị phân càng gần ranh giới hệ thống càng tốt, được xử lý dưới dạng văn bản, sau đó được chuyển đổi trở lại thành dạng nhị phân cho các mục đích đầu ra

Thật không may, Python 2 không khuyến khích các nhà phát triển viết chương trình theo cách đó - nó làm mờ đi ranh giới giữa dữ liệu nhị phân và văn bản, đồng thời khiến các nhà phát triển khó tách biệt hai thứ này trong đầu, chứ đừng nói đến mã của họ. Vì vậy, các tác giả khung web và GUI phải nói với người dùng Python 2 của họ "luôn sử dụng văn bản Unicode. Nếu không, bạn có thể gặp phải các lỗi khó hiểu và khó theo dõi khi xử lý đầu vào Unicode"

Python 3 thì khác. nó tạo ra sự tách biệt lớn hơn nhiều giữa "miền nhị phân" và "miền văn bản", giúp viết mã ứng dụng thông thường dễ dàng hơn, đồng thời khiến việc viết mã hoạt động với các ranh giới hệ thống trở nên khó khăn hơn một chút khi có sự phân biệt giữa dữ liệu nhị phân và dữ liệu văn bản . Tôi đã viết chi tiết hơn ở nơi khác về những gì thực sự đã thay đổi trong mô hình văn bản giữa Python 2 và Python 3

Cuộc cách mạng hỗ trợ Unicode của Python này đang diễn ra trong bối cảnh quá trình di chuyển nền tảng lớn hơn của thao tác văn bản tính toán từ ASCII chỉ có tiếng Anh [được xác định chính thức vào năm 1963], thông qua sự phức tạp của mô hình "khai báo mã hóa + dữ liệu nhị phân" [bao gồm cả C/POSIX

Tại sao lại đề cập đến điểm này? . Với các vấn đề cụ thể về ngôn ngữ đã được giải quyết bằng quá trình chuyển đổi Python 3, rào cản gia nhập đối với các tính năng ngôn ngữ mới cao hơn nhiều so với những ngày đầu của Python và không có sự di chuyển toàn ngành nào khác trên quy mô chuyển đổi từ "dữ liệu nhị phân có mã hóa" sang . Thay vào đó, tôi hy vọng chúng ta sẽ có thể đáp ứng bất kỳ sự phát triển ngôn ngữ nào trong tương lai trong các quy trình quản lý thay đổi thông thường và bất kỳ đề xuất nào không thể xử lý theo cách đó sẽ bị từ chối vì áp đặt chi phí cao không thể chấp nhận được đối với cộng đồng và sự phát triển cốt lõi

Được xuất bản lần đầu trên Curious Efficiency và cũng có trên Blog nhà phát triển Red Hat. Tái bản dưới Creative Commons. Để biết thêm thông tin về quá trình phát triển của Python, bạn có thể quan tâm đến Sự chuyển đổi sang lập trình đa ngôn ngữ với Python, cũng của Nick Coghlan

Đọc gì tiếp theo

thẻ

con trăn

lập trình

Nick Coghlan

Nick là nhà phát triển cốt lõi của CPython và là thành viên Hội đồng quản trị của Quỹ phần mềm Python

Thêm về tôi