การรวบรวมพฤติกรรมที่น่าประหลาดใจของ Python ได้จุดประกายการอภิปรายเรื่องคุณภาพการออกแบบภาษาโปรแกรมขึ้นมาใหม่ โดยนักพัฒนาเปรียบเทียบความแปลกประหลาดของ Python กับความไม่สอดคล้องที่มีชื่อเสียงของ JavaScript โปรเจกต์ What the f*ck Python! ได้แสดงให้เห็นพฤติกรรมของโค้ดที่ไม่คาดคิด ซึ่งท้าทายสมมติฐานของนักพัฒนาเกี่ยวกับการทำงานของ Python ภายใต้ฮูด
ความเหมือนกันของ String เทียบกับความเท่าเทียมกันสร้างความสับสน
การจัดการวัตถุ string ของ Python เผยให้เห็นรายละเอียดการดำเนินการที่อาจทำให้นักพัฒนาสับสน เมื่อสร้าง string ที่เหมือนกัน Python บางครั้งจะเก็บไว้เป็นวัตถุเดียวกันในหน่วยความจำ และบางครั้งก็สร้างวัตถุแยกต่างหาก สิ่งนี้นำไปสู่ผลลัพธ์ที่ไม่คาดคิดเมื่อใช้ตัวดำเนินการ is ซึ่งตรวจสอบความเหมือนกันของวัตถุมากกว่าความเท่าเทียมกันของเนื้อหา พฤติกรรมนี้ขึ้นอยู่กับปัจจัยต่างๆ เช่น string interning และวิธีการสร้าง string ทำให้ยากต่อการคาดเดาหากไม่มีความรู้เชิงลึกเกี่ยวกับภายในของ PythonString interning: เทคนิคการปรับปรุงประสิทธิภาพของ Python ที่ string เหมือนกันจะถูกเก็บไว้ครั้งเดียวในหน่วยความจำและนำมาใช้ซ้ำ
พฤติกรรมแปลกๆ ของ Python ที่พบบ่อย:
- ปัญหาเอกลักษณ์ของสตริง:
"wtf" is "wtf"จะคืนค่าTrueแต่"wtf!" is "wtf!"อาจคืนค่าFalse - การเปรียบเทียบแบบต่อเนื่อง:
False == False in [False]จะประเมินผลเป็นTrueเนื่องจากการเชื่อมโยงตัวดำเนินการ - พฤติกรรมของ Object ID: ผลลัพธ์ของฟังก์ชัน
id()ขึ้นอยู่กับการจัดเก็บสตริงภายในและอายุการใช้งานของออบเจ็กต์ - การแปลงค่าบูลีน:
bool("False")จะคืนค่าTrueเพราะสตริงที่ไม่ว่างเปล่าจะมีค่าความจริง
การเปรียบเทียบแบบต่อเนื่องให้ผลลัพธ์ที่ไม่คาดคิด
หนึ่งในพฤติกรรมที่น่าประหลาดใจที่สุดเกี่ยวข้องกับตัวดำเนินการเปรียบเทียบแบบต่อเนื่อง นิพจน์ False == False in [False] ประเมินผลเป็น True ซึ่งดูขัดกับสัญชาตญาณไม่ว่าคุณจะแยกวิเคราะห์ในใจอย่างไร สิ่งนี้เกิดขึ้นเพราะ Python ถือว่าการเปรียบเทียบแบบต่อเนื่องเป็นนิพจน์บูลีนผสม โดยแปลงคำสั่งให้เป็น (False == False) and (False in [False]) อย่างมีประสิทธิภาพ แม้ว่าคุณสมบัตินี้จะช่วยให้สามารถใช้สัญลักษณ์ทางคณิตศาสตร์เช่น 1 < x < 10 ได้ แต่ก็อาจสร้างความสับสนเมื่อนำไปใช้กับตัวดำเนินการที่ไม่ใช่ transitive
ชุมชนแบ่งแยกเรื่องการวิจารณ์ภาษา
การอภิปรายได้เผยให้เห็นความแตกแยกอย่างชัดเจนในวิธีที่นักพัฒนามองการวิจารณ์ภาษา บางคนโต้แย้งว่าตัวอย่างเหล่านี้แสดงถึงกรณีขอบที่ไม่ค่อยปรากฏในโค้ดที่ใช้งานจริง โดยเน้นว่า Python ที่ดีจะปฏิบัติตามแบบแผนที่ยอมรับและไม่ค่อยใช้ฟังก์ชันเช่น id() คนอื่นๆ โต้แย้งว่าภาษาโปรแกรมควรได้รับการทดสอบอย่างเข้มงวดเหมือนซอฟต์แวร์อื่นๆ เนื่องจากความไม่สอดคล้องอาจนำไปสู่ข้อบกพร่องที่ละเอียดอ่อนในแอปพลิเคชันจริง
สำหรับภาษาที่ใช้กันอย่างแพร่หลายเช่น Python เราควรทดสอบมันเหมือนนักทดสอบ QA ความไม่สอดคล้องทั้งหมดนี้รวมกันเป็นข้อบกพร่องมากมายเมื่อคุณคาดหวังให้บางสิ่งปฏิบัติตามรูปแบบที่สอดคล้องกันแต่กลับไม่เป็นเช่นนั้น
ประเด็นสำคัญในการอภิปราย:
- ผลกระทบต่อการผลิต: ตัวอย่างส่วนใหญ่ใช้ฟังก์ชันเช่น
id()ที่ไม่ค่อยปรากฏในโค้ดจริง - การออกแบบภาษา: การถกเถียงว่าควรให้ความสำคัญกับความสอดคล้องหรือความสามารถในการอ่านมากกว่ากัน
- คุณภาพของเอกสาร: Python ขาดข้อกำหนดอย่างเป็นทางการเมื่อเปรียบเทียบกับภาษาหลักอื่นๆ
- การเปรียบเทียบกับ JavaScript: ชุมชนแบ่งออกเป็นสองฝ่ายว่า Python ควรได้รับการวิพากษ์วิจารณ์เช่นเดียวกับ JS หรือไม่
ข้อกังวลเรื่องข้อกำหนดและเอกสาร
การถกเถียงยังได้เน้นย้ำข้อกังวลเกี่ยวกับการขาดข้อกำหนดอย่างเป็นทางการของ Python ไม่เหมือนกับภาษาที่มีข้อกำหนดรายละเอียดที่ช่วยให้สามารถดำเนินการแยกต่างหากได้ Python อาศัย CPython เป็นหลักเป็นการดำเนินการอ้างอิง วิธีการนี้หมายความว่าพฤติกรรมบางอย่างเป็นรายละเอียดการดำเนินการมากกว่าคุณสมบัติภาษาที่รับประกัน ทำให้นักพัฒนายากที่จะคาดเดาว่าโค้ดจะทำงานอย่างไรในการดำเนินการ Python ที่แตกต่างกัน
การอภิปรายสะท้อนความตึงเครียดที่กว้างขึ้นในการออกแบบภาษาโปรแกรมระหว่างความสามารถในการอ่าน ความสอดคล้อง และความเป็นไปได้ในการดำเนินการ แม้ว่าปรัชญาการออกแบบของ Python จะเน้นความสามารถในการอ่านโค้ดและประสิทธิภาพของนักพัฒนา แต่ตัวอย่างเหล่านี้แสดงให้เห็นว่าแม้แต่ภาษาที่ออกแบบมาอย่างดีก็สามารถแสดงพฤติกรรมที่น่าประหลาดใจซึ่งท้าทายแบบจำลองทางจิตของนักพัฒนาเกี่ยวกับวิธีที่ภาษาควรทำงาน
อ้างอิง: What the f*ck Python!