Python thay thế ký tự trong tuple

Công cụ sau đây trực quan hóa những gì máy tính đang làm từng bước khi nó thực thi chương trình nói trên

Trình chỉnh sửa mã Python

Có một cách khác để giải quyết giải pháp này?

Trước. Viết chương trình Python để in một bộ dữ liệu với định dạng chuỗi.
Tiếp theo. Viết chương trình Python để xóa [các] bộ dữ liệu trống khỏi danh sách các bộ dữ liệu.

Mức độ khó của bài tập này là gì?

Dễ dàng trung bình khó

Kiểm tra kỹ năng Lập trình của bạn với bài kiểm tra của w3resource



con trăn. Lời khuyên trong ngày

Làm cho nó bất biến

Hàm freezeset[] cho phép danh sách không thay đổi

Trong một số trường hợp, bạn có thể đã bắt đầu chương trình của mình với một danh sách thay vì các bộ vì kết luận rằng cấu trúc dữ liệu có thể thay đổi phù hợp hơn cho dự án. Nhưng mọi thứ thay đổi, các dự án phát triển và ý tưởng được biết là thay đổi lộ trình. Bây giờ bạn quyết định rằng bạn cần cấu trúc bất biến nhưng dường như đã quá muộn để thực hiện công việc chuyển đổi danh sách tẻ nhạt của bạn? . Frozenset[] sẽ làm cho nó trở nên dễ dàng

Lợi ích chính từ việc đăng ký LWN là giúp chúng tôi tiếp tục xuất bản, nhưng ngoài ra, người đăng ký có quyền truy cập ngay vào tất cả nội dung trang web và truy cập vào một số tính năng bổ sung của trang web. Hãy đăng ký ngay hôm nay

Bởi Jake Edge
Ngày 23 tháng 3 năm 2022

Một cuộc thảo luận gần đây về danh sách gửi thư ý tưởng python cung cấp một số thông tin chi tiết về cách — hoặc cách không — đề xuất một tính năng được thêm vào ngôn ngữ. Thoạt nhìn, việc thêm một phương thức vào kiểu bất biến của Python để thay thế một trong các phần tử của nó không phải là một ý tưởng đặc biệt lạ lùng, cũng không phải là một ý tưởng gây ra nhiều lo ngại về khả năng tương thích ngược. Mặc dù có một số bằng chứng được đưa ra rằng một phương pháp như vậy có thể hữu ích, nhưng có vẻ như ý tưởng này sẽ không đi đến đâu, ít nhất một phần là do cách tranh luận về lợi ích của nó lặp đi lặp lại, gần như hung hăng.

Vào ngày 10 tháng 3, "wfdc" đã đăng một ghi chú ngắn đề xuất một phương thức thay thế [] cho các bộ sẽ trả về một bộ mới với một trong các giá trị ban đầu được thay thế tại chỉ mục được chỉ định

    >>> t = [1, 2, 3]
    >>> t.replace[1, 9]
    [1, 9, 3]

Wfdc đã chỉ ra một câu hỏi về Stack Overflow về việc thay thế một giá trị trong một bộ và nói rằng nó sẽ là "bản sao tự nhiên" đối với phương thức _replace[] cho loại được đặt tên là một phần của mô-đun bộ sưu tập của thư viện chuẩn. Các bộ được đặt tên thêm khả năng tham chiếu đến các phần tử trong một bộ theo tên và phương thức _replace[] có thể được sử dụng để tạo một bộ có tên mới với các giá trị mới cho các tên được đặt làm đối số từ khóa

Rob Cliffe phản đối cái tên "thay thế", nói rằng nó có thể bị nhầm lẫn với phương thức thực hiện một điều gì đó hoàn toàn khác [thay thế một chuỗi con đã cho]. Ngoài ra, vì nó có thể được viết dưới dạng hàm một dòng, như đã trình bày trong bài đăng, "không cần một phương thức mới cho nó". Nhưng wfdc không đồng ý, nói rằng API của một phương thức cho một loại không liên quan "không phải là một phản đối hợp lệ". Họ đã đề cập đến triết lý "bao gồm pin" của Python và kết luận. "Nếu người dùng thấy mình triển khai lại cùng một chức năng tiện ích trong các dự án khác nhau, thì đó là một dấu hiệu tốt cho thấy chức năng đó phải là một phần của thư viện chuẩn. "

Jeremiah Vivian đồng ý với đánh giá đó, gợi ý rằng việc triển khai lại chức năng lặp đi lặp lại "có thể dễ đọc hơn một chút bằng cách biến nó thành một phương thức thực tế". Christopher Barker nói rằng anh ấy không muốn thêm các phương thức vào các loại tích hợp sẵn, nhưng đã nhận thấy nhu cầu thay thế các phần tử bộ "khá thường xuyên và điều đó luôn cảm thấy khó xử hơn nhiều so với bình thường". Ngoài ra, thêm nó như một phương thức có nghĩa là nó có thể được tối ưu hóa, vì việc triển khai Python sử dụng nhiều bộ hoặc danh sách tạm thời để xây dựng bộ mới

Chris Angelico đã đặt câu hỏi về việc sử dụng một bộ và nghĩ rằng một bộ có tên có thể là lựa chọn tốt hơn nếu chức năng thay thế là cần thiết. Nhưng Barker không đồng ý rằng chuyển sang têntuple nhất thiết phải là con đường đúng đắn. Anh ấy chỉ ra rằng việc triển khai một lớp ban đầu của wfdc là lỗi; . -]". Ngoài ra, các bộ dữ liệu được đặt tên nặng hơn các bộ dữ liệu và chậm hơn; . "

Trị giá

Có một số bất đồng về việc liệu câu hỏi về Stack Overflow có thực sự chỉ ra nhiều về nhu cầu của phương thức hay không và liệu replace[] có phải là thứ thường được cần hay không. Wfdc khẳng định rằng nó hữu ích, đặc biệt khi so sánh với các phương thức tuple tích hợp sẵn hiện có, chẳng hạn như [là một phần của các hoạt động chung cho các loại trình tự; tuple là một trình tự bất biến]. Nhưng Brendan Barnwell cho rằng lập luận đó không thuyết phục và bỏ qua một phần quan trọng

Theo như tôi thấy, bạn dường như không đưa ra nhiều lập luận thực chất ủng hộ đề xuất của mình. Tất cả những gì bạn đang nói là đôi khi nó có thể hữu ích và có những phương pháp hiện có khác không cực kỳ hữu ích, vậy tại sao không thêm phương pháp này nữa? . ]

Tương tự, những gì bạn không cung cấp là bất kỳ sự cân nhắc nào về *chi phí* của việc thêm tính năng này so với lợi ích. Các chi phí này bao gồm triển khai và bảo trì, tăng diện tích bề mặt API để người dùng tự làm quen và làm lộn xộn không gian tên của loại bằng một tên phương thức khác [mặc dù bạn có vẻ thừa nhận rằng nó đã lộn xộn với các phương thức không hữu ích lắm]. Ngược lại, chúng tôi có lợi ích là có thể "gán" một cách hiệu quả cho một phần tử tuple, phần tử này không bằng 0 nhưng cũng không chính xác là một nhu cầu cấp bách. Tôi không nghĩ rằng bạn sẽ thu hút được nhiều sự chú ý từ đề xuất này trừ khi ít nhất bạn cũng tham gia vào ý tưởng về chi phí và lợi ích của chính *tính năng được đề xuất* của bạn, thay vì chỉ tập trung vào những gì bạn cho là tiện ích thấp của mọi thứ

Paul Moore đã chỉ ra rằng việc tìm kiếm mã quan trọng sẽ được hưởng lợi từ một tính năng được đề xuất là cách tốt nhất để thêm nó vào ngôn ngữ. Anh ấy không ủng hộ ý tưởng này, nhưng nói rằng có lẽ một nhà phát triển cốt lõi khác sẽ quan tâm nếu có thể tìm thấy mã như vậy

Trước đây, các đề xuất thành công thường làm như vậy bằng cách khảo sát các phần quan trọng của mã trong thế giới thực [ví dụ: thư viện chuẩn] và chỉ ra nơi tính năng mới được đề xuất sẽ cải thiện đáng kể khả năng đọc hoặc khả năng bảo trì của các phần mã

Moore, giống như Angelico, thắc mắc về trường hợp sử dụng; . Moore nói rằng ông lo ngại rằng đó là một ví dụ về vấn đề XY, trong đó nhu cầu thực sự bị che khuất bởi câu hỏi được đặt ra [e. g. "Làm thế nào tôi có thể sử dụng X để làm Y?"]

Vấn đề trong thế giới thực đang được giải quyết là gì?

Trong suốt chủ đề, yêu cầu này đã được nhiều người bình luận lặp lại, nhưng wfdc chưa bao giờ thực sự phản hồi nó. Giống như Moore, Steven D'Aprano đã cố gắng giúp wfdc đi đúng hướng. D'Aprano nghĩ rằng sẽ cần có Đề xuất cải tiến Python [PEP] nếu tính năng này được xem xét nghiêm túc. Ông cũng chỉ ra các chi phí liên quan đến việc thêm bất kỳ tính năng mới nào vào Python, một số chi phí có thể không rõ ràng. Có vẻ quá nặng nề khi đi theo con đường PEP, nhưng đó là con đường bình thường để đi theo; . Anh ấy đề xuất xem xét cả PEP thành công và không thành công để được hướng dẫn, đồng thời lưu ý rằng PEP 584 ["Add Union Operator To dict"], mà anh ấy là đồng tác giả, có một lịch sử thú vị

Nhân tiện, khi tôi bắt đầu viết PEP 584, tôi đã có ý định từ chối PEP một lần và mãi mãi, vì vậy chúng tôi có thể có một nơi để chỉ cho mọi người khi họ muốn biết [tại sao] họ không thể thêm các ký tự. Chỉ có điều hóa ra trường hợp "bổ sung" dict [dict union] mạnh hơn bất kỳ ai nghĩ và PEP đã được chấp nhận

D'Aprano đã mô tả những gì nên có trong PEP thuộc loại này ở một mức độ nào đó. Viết một PEP chắc chắn là một nhiệm vụ hơi khó khăn, đối với những gì có vẻ như là một bổ sung đơn giản cho ngôn ngữ, nhưng điều đó được mong đợi. Thay đổi ngôn ngữ 30 tuổi nên hơi khó khăn;

Cần

Wfdc đã thực hiện một bước để chứng minh rõ hơn nhu cầu với một cặp truy vấn Sourcegraph [tại đây và tại đây] sử dụng các biểu thức chính quy để tìm kiếm mã Python nguồn mở để biết sự tồn tại của mã triển khai hai cách phổ biến để thay thế mục nhập bộ dữ liệu. Kết quả cho thấy nhiều cách sử dụng các thành ngữ đó trong nhiều loại mã khác nhau trong hệ sinh thái Python. D'Aprano đánh giá cao nỗ lực này, mặc dù ban đầu các liên kết không hoạt động với anh ấy, nhưng lưu ý rằng có nhiều điều hơn là chỉ đăng liên kết

Cảm ơn bạn đã cung cấp một số thuật ngữ tìm kiếm, nhưng bạn hiểu sai quy trình đề xuất chức năng mới cho nội trang và stdlib. Trách nhiệm không thuộc về *chúng tôi* để thực hiện công việc, mà là của những người đưa ra đề xuất. Nếu chúng tôi yêu cầu các ví dụ, chúng tôi mong bạn thực hiện công việc quản lý một số ví dụ hay, chứ không chỉ đổ một biểu thức chính quy vào lòng chúng tôi và bảo chúng tôi tự tìm kiếm chúng

Một lần nữa, D'Aprano gợi ý rằng nếu wfdc muốn tiếp tục đẩy mạnh tính năng này, họ nên xem xét việc kết hợp một PEP và thu hút một nhà phát triển cốt lõi làm nhà tài trợ. Điều đó có thể kéo theo việc mở rộng ý tưởng để áp dụng cho lớp cơ sở trừu tượng [ABC] cho các chuỗi, vì chỉ cần thêm chức năng vào các bộ dữ liệu là một thay đổi nhỏ như vậy, D'Aprano nói

Tranh luận

Cuộc thảo luận đã giảm đi phần nào, với nhiều yêu cầu hơn đối với trường hợp sử dụng của wfdc, những bất đồng về tên, nhiều câu hỏi hơn về việc liệu nametuple có phải là lựa chọn tốt hơn hay không, liệu tính năng này có thực sự được triển khai dưới dạng một lớp lót hay không, v.v. Không có tiến triển thực sự nào đối với một đề xuất thực tế, cũng như không có nhà phát triển cốt lõi nào kêu gọi tài trợ cho một đề xuất. Một phần, đó là vì wfdc rõ ràng không muốn dành thời gian và công sức để đạt được điều đó, nhưng đã có khá nhiều hành động bắn tỉa [ở cả hai bên] xuyên suốt. Tuy nhiên, kiểu trao đổi này không phải là một mô hình hiếm gặp, như Cliffe đã lưu ý

Đây là một tình huống phổ biến trên python-list hoặc python-ideas. Ai đó có một ý tưởng mà họ nghĩ là điều tuyệt vời nhất kể từ khi cắt lát bánh mì. Họ đề xuất nó, và cảm thấy bị tổn thương/bị từ chối khi bị phản đối thay vì mọi người nhảy cẫng lên và nói rằng nó tuyệt vời như thế nào. Đôi khi họ hết sức thô lỗ. Tôi sẽ không nói rằng bạn đã hoàn toàn vượt qua ranh giới đó, nhưng giọng điệu của bạn chắc chắn [ít nhất là đối với tôi] là hiếu chiến. Nó sẽ không giúp ích gì cho sự nghiệp của bạn khi khiến mọi người ủng hộ. Tôi xin lỗi nếu đó không phải là ý của bạn

Kiểu lập luận được sử dụng bởi wfdc có phần gây tranh cãi, chắc chắn lặp đi lặp lại [ví dụ: họ đã liên kết các truy vấn nhiều lần] và nhiều câu trả lời của họ có các mục như "xem câu trả lời của tôi cho. " không có liên kết, điều này gây khó khăn cho việc xác định câu trả lời nào trong số [nhiều] câu trả lời mà họ đang đề cập đến. Một số người đã cố gắng giúp ích cho wfdc trong quá trình thực hiện, nhưng cũng có khá nhiều điều tiêu cực đến từ cộng đồng Python, như D'Aprano đã lưu ý. "Không có gì sai khi sử dụng các bộ dữ liệu đơn giản làm cấu trúc dữ liệu của bạn và ví dụ từ một số người rằng wfdc đã sai khi làm như vậy là kiêu ngạo, thô lỗ và trịch thượng. " D'Aprano tiếp tục điều đó trong một tin nhắn khác, nói lại rằng có chỗ cho cả hai bên để cải thiện

Đúng là phần lớn chủ đề này đã bị chi phối bởi một số câu trả lời cực kỳ tiêu cực, trịch thượng. Nhưng bạn không giúp đỡ bằng cách cắn vào tay những người đang cố gắng giúp đỡ bạn

Bạn đã được thông báo về các quy trình mà bạn phải tuân theo để thay đổi này được chấp nhận vào Python. Gầm gừ và cắn chúng tôi sẽ không thay đổi điều đó

Barker đã chia sẻ một số suy nghĩ giống như D'Aprano, lưu ý rằng Angelico gần đây đã "than thở rằng các ý tưởng Python dường như ngay lập tức từ chối bất kỳ ý tưởng mới nào ngoài tầm tay", nhưng anh ấy là một phần của điệp khúc tiêu cực trong chủ đề. Angelico không nhìn sự việc theo cách đó, nhưng Barker nói

Dù sao đi nữa -- mặc dù giọng điệu không hay lắm, nhưng tôi nghĩ cuộc trò chuyện ít nhất cũng có chút hiệu quả. OP nên có ý tưởng về những gì họ cần làm nếu họ thực sự muốn thúc đẩy điều này về phía trước. Và thuyết phục danh sách này không phải là điều cần làm

BTW. Tôi không gợi ý rằng đó là một ý tưởng tồi để làm nản lòng. nhận được một cái gì đó thậm chí có vẻ nhỏ vào Python là rất nhiều công việc và thường không thành công. Cung cấp cho người đề xuất một đánh giá trung thực về cơ hội của họ là điều nên làm

Nhưng có một sự khác biệt rất lớn về giọng điệu giữa

"Đây là một việc nhỏ, và tôi không nghĩ rằng nó có khả năng được chấp nhận"

và

"Đây không phải là một ý tưởng tốt chút nào"

Và nó cảm thấy [dù sao đối với tôi] giống như có khá nhiều thứ sau trong chủ đề này

Nếu không có những thay đổi lớn trong cách tiếp cận của wfdc, có vẻ như rất khó có ý tưởng nào xảy ra. Có lẽ ai đó khác có thể nhặt nó lên và đi theo con đường có nhiều khả năng thành công hơn, hoặc ít nhất là để tiến xa hơn trong quá trình này. Có nhiều câu trả lời trong chuỗi nêu rõ các bước cần thiết để làm như vậy—cùng với các ví dụ phong phú về cách không tương tác với cộng đồng Python. Xem xét một số điều đó sẽ hữu ích cho bất kỳ ai đang xem xét đề xuất một tính năng mới cho Python dưới bất kỳ hình thức nào, vì vậy cuộc thảo luận, tuy nhiên không hoạt động, chắc chắn có một số giá trị

Chúng ta có thể cập nhật các phần tử trong tuple không?

Thay thế [] trong Python là gì?