ข้อเสียของ Python คืออะไร [ปิด]

Python ดูเหมือนจะโกรธแค้นในทุกวันนี้และไม่ใช่เรื่องที่ไม่สมควรเพราะมันเป็นภาษาที่แท้จริงที่คนส่วนใหญ่ชอบที่จะได้รับปัญหาใหม่ในการแก้ปัญหา แต่ในฐานะที่เป็นนักปราชญ์เคยกล่าวไว้ว่า (เรียกเขาว่านักปราชญ์เท่านั้นเพราะฉันไม่รู้ว่าใครพูดจริง ๆ ไม่แน่ใจว่าเขาเป็นคนฉลาดเลย) เพื่อรู้ภาษาที่แท้จริงไม่เพียง แต่รู้ ไวยากรณ์, การออกแบบ, ฯลฯ , ข้อดี แต่ยังรวมถึงข้อเสียของมัน ไม่มีภาษาใดที่สมบูรณ์แบบบางคนดีกว่าคนอื่น

ดังนั้นสิ่งที่จะเป็นในความคิดของคุณข้อเสียวัตถุประสงค์ของงูหลาม

หมายเหตุ: ฉันไม่ได้ขอให้เปรียบเทียบภาษาที่นี่ (เช่น C # ดีกว่า Python เพราะ ... yadda yadda yadda) - มีวัตถุประสงค์มากกว่า (ในบางระดับ) ความคิดเห็นที่คุณลักษณะภาษาได้รับการออกแบบไม่ดีไม่ว่าจะเป็นอะไร บางอย่างที่คุณขาดไปและอื่น ๆ หากต้องใช้ภาษาอื่นเป็นการเปรียบเทียบ แต่เพียงเพื่อแสดงให้เห็นถึงจุดที่ยากที่จะอธิบายรายละเอียดอย่างอื่น (เช่นเพื่อความเข้าใจง่าย)

ฉันใช้ Python ค่อนข้างสม่ำเสมอและโดยรวมแล้วฉันคิดว่ามันเป็นภาษาที่ดีมาก อย่างไรก็ตามไม่มีภาษาที่สมบูรณ์แบบ นี่คือข้อเสียตามลำดับความสำคัญต่อฉันเป็นการส่วนตัว:

1. มันช้า ฉันหมายถึงช้าจริงๆ หลายครั้งที่เรื่องนี้ไม่สำคัญ แต่ก็หมายความว่าคุณต้องมีภาษาอื่นสำหรับบิตที่สำคัญต่อประสิทธิภาพ

2. ฟังก์ชั่นที่ซ้อนกันชนิดดูดที่คุณไม่สามารถแก้ไขตัวแปรในขอบเขตด้านนอก แก้ไข: ฉันยังคงใช้ Python 2 เนื่องจากการสนับสนุนห้องสมุดและข้อบกพร่องของการออกแบบนี้ทำให้ heck ออกมาจากฉัน แต่เห็นได้ชัดว่ามันได้รับการแก้ไขใน Python 3 เนื่องจากคำสั่งnonlocal อดใจรอไม่ไหวแล้วที่ libs ที่ฉันใช้จะถูกส่งไปยังพอร์ตดังนั้นข้อบกพร่องนี้สามารถส่งไปยังกองเถ้าของประวัติศาสตร์ได้ดี

3. มันขาดคุณสมบัติบางอย่างที่อาจเป็นประโยชน์ต่อไลบรารี่ / รหัสทั่วไปและ IMHO นั้นนำมาซึ่งความเรียบง่ายที่ไม่ดีต่อสุขภาพ สิ่งที่สำคัญที่สุดที่ฉันคิดว่าเป็นประเภทค่าที่ผู้ใช้กำหนด (ฉันเดาว่าสิ่งเหล่านี้สามารถสร้างขึ้นได้ด้วยเวทมนตร์ metaclass แต่ฉันไม่เคยลอง) และฟังก์ชั่นอ้างอิงพารามิเตอร์

4. มันไกลจากโลหะ ต้องการเขียนเธรดพื้นฐานหรือเคอร์เนลโค้ดหรืออะไร? โชคดี.

5. ในขณะที่ฉันไม่คิดว่าการขาดความสามารถในการตรวจจับข้อผิดพลาดทางความหมายล่วงหน้าเป็นข้อเสียเปรียบสำหรับพลวัตที่ Python เสนอฉันหวังว่าจะมีวิธีที่จะจับข้อผิดพลาดทางไวยากรณ์และสิ่งที่โง่ ๆ เช่นชื่อตัวแปรที่พิมพ์ผิด

6. เอกสารไม่ดีพอ ๆ กับภาษาอย่าง PHP และ Java ที่มี backings ของ บริษัท ที่แข็งแกร่ง

ฉันเกลียดที่ Python ไม่สามารถแยกความแตกต่างระหว่างการประกาศและการใช้งานของตัวแปร คุณไม่จำเป็นต้องพิมพ์แบบคงที่เพื่อให้เกิดขึ้น มันคงจะดีถ้ามีวิธีที่จะพูดว่า "นี่เป็นตัวแปรที่ฉันตั้งใจประกาศและฉันตั้งใจจะแนะนำชื่อใหม่นี่ไม่ใช่การพิมพ์ผิด"

นอกจากนี้ฉันมักจะใช้ตัวแปร Python ในรูปแบบการเขียนครั้งเดียวนั่นคือฉันถือว่าตัวแปรไม่สามารถเปลี่ยนแปลงได้และไม่ได้แก้ไขหลังจากการมอบหมายครั้งแรก ต้องขอบคุณคุณสมบัติต่างๆเช่นความเข้าใจในรายการซึ่งเป็นเรื่องง่ายอย่างเหลือเชื่อและทำให้การไหลของโค้ดง่ายขึ้น

อย่างไรก็ตามฉันไม่สามารถบันทึกข้อเท็จจริงนั้นได้ ไม่มีสิ่งใดใน Python ที่ทำให้ฉันไม่สามารถเขียนทับหรือใช้ตัวแปรซ้ำได้

โดยสรุปผมอยากจะมีสองคำในภาษานี้และvar letถ้าฉันเขียนไปยังตัวแปรที่ไม่ได้ประกาศโดยหนึ่งในนั้น Python ควรเพิ่มข้อผิดพลาด นอกจากนี้letประกาศตัวแปรเป็นแบบอ่านอย่างเดียวในขณะที่varตัวแปรเป็น“ ปกติ”

ลองพิจารณาตัวอย่างนี้:

x = 42    # Error: Variable `x` undeclared

var x = 1 # OK: Declares `x` and assigns a value.
x = 42    # OK: `x` is declared and mutable.

var x = 2 # Error: Redeclaration of existing variable `x`

let y     # Error: Declaration of read-only variable `y` without value
let y = 5 # OK: Declares `y` as read-only and assigns a value.

y = 23    # Error: Variable `y` is read-only

ขอให้สังเกตว่าประเภทนั้นยังคงอยู่โดยปริยาย (แต่letตัวแปรนั้นมีไว้สำหรับ intents และวัตถุประสงค์ทั้งหมดที่พิมพ์แบบคงที่เนื่องจากไม่สามารถสะท้อนกลับเป็นค่าใหม่ได้ในขณะที่varตัวแปรอาจยังพิมพ์แบบไดนามิก)

ในที่สุดอาร์กิวเมนต์ของเมธอดทั้งหมดควรเป็นletเช่นนั้นควรเป็นแบบอ่านอย่างเดียว โดยทั่วไปไม่มีเหตุผลที่ดีในการแก้ไขพารามิเตอร์ยกเว้นสำนวนต่อไปนี้:

def foo(bar = None):
    if bar == None: bar = [1, 2, 3]

สิ่งนี้อาจถูกแทนที่ด้วยสำนวนที่แตกต่างกันเล็กน้อย:

def foo(bar = None):
    let mybar = bar or [1, 2, 3]

การร้องเรียนหลักของฉันคือเธรดซึ่งไม่เป็นตัวแสดงในหลาย ๆ สถานการณ์ (เมื่อเทียบกับ Java, C และอื่น ๆ ) เนื่องจากการล็อคล่ามทั่วโลก (ดูที่"Inside the Python GIL" (ลิงก์ PDF) )

อย่างไรก็ตามมีอินเทอร์เฟซแบบหลายกระบวนการที่ใช้งานง่ายมากอย่างไรก็ตามมันจะหนักกว่าในการใช้หน่วยความจำสำหรับกระบวนการจำนวนมากเทียบกับเธรดหรือยากกว่าถ้าคุณมีข้อมูลที่ใช้ร่วมกันจำนวนมาก ประโยชน์ที่ได้รับคือเมื่อคุณมีโปรแกรมที่ทำงานกับหลายกระบวนการมันสามารถขยายข้ามหลาย ๆ เครื่องสิ่งที่โปรแกรมเธรดไม่สามารถทำได้

ฉันไม่เห็นด้วยกับคำวิจารณ์ของเอกสารฉันคิดว่ามันยอดเยี่ยมและดีกว่าถ้าไม่ใช่ภาษาหลักทั้งหมด

นอกจากนี้คุณสามารถจับหลายข้อบกพร่องรันไทม์ทำงานpylint

arguably , การขาดการพิมพ์แบบคงที่, ซึ่งสามารถแนะนำคลาสบางอย่างของข้อผิดพลาดรันไทม์ , ไม่คุ้มค่าความยืดหยุ่นเพิ่มที่เป็ดพิมพ์ให้

ฉันคิดว่าชิ้นส่วนที่เน้นวัตถุของ Python ให้ความรู้สึก "ติดแน่น" ความต้องการทั้งหมดในการส่ง "ตนเอง" ไปยังทุก ๆ วิธีอย่างชัดเจนเป็นอาการที่เป็นองค์ประกอบของ OOP ที่ไม่ได้วางแผนไว้อย่างชัดเจนคุณสามารถพูดได้ มันยังแสดงให้เห็นกฎการกำหนดขอบเขตของพิ ธ ที่บางครั้งก็ถูกวิพากษ์วิจารณ์ในคำตอบอื่น

แก้ไข:

เมื่อฉันพูดว่าชิ้นส่วนที่เป็นวัตถุของ Python จะรู้สึกว่า "สลักเกลียว" ฉันหมายความว่าในบางครั้งด้าน OOP รู้สึกค่อนข้างไม่สอดคล้องกัน ใช้ Ruby ตัวอย่างเช่นใน Ruby ทุกอย่างเป็นวัตถุและคุณเรียกใช้เมธอดโดยใช้obj.methodไวยากรณ์ที่คุ้นเคย(ยกเว้นตัวดำเนินการโอเวอร์โหลดที่แน่นอน) ใน Python ทุกอย่างก็เป็นวัตถุด้วยเช่นกัน แต่บางวิธีที่คุณเรียกว่าเป็นฟังก์ชั่น คือเกินคุณ__len__จะกลับมายาว แต่เรียกว่าใช้len(obj)แทนคุ้นเคยมากขึ้น (และสอดคล้องกัน) obj.lengthที่พบบ่อยในภาษาอื่น ๆ ฉันรู้ว่ามีเหตุผลที่อยู่เบื้องหลังการตัดสินใจออกแบบนี้ แต่ฉันไม่ชอบพวกเขา

ยิ่งกว่านั้นโมเดล OOP ของ Python ขาดการปกป้องข้อมูลใด ๆ กล่าวคือไม่มีสมาชิกส่วนบุคคลที่ได้รับการปกป้องและสาธารณะ คุณสามารถเลียนแบบพวกเขาโดยใช้_และ__ต่อหน้าวิธีการ แต่มันน่าเกลียด ในทำนองเดียวกันหลามไม่ได้ค่อนข้างได้รับด้านการส่งผ่านข้อความของ OOP ขวาอย่างใดอย่างหนึ่ง

สิ่งที่ฉันไม่ชอบเกี่ยวกับ Python:

1. การทำเกลียว (ฉันรู้ว่ามันถูกกล่าวถึงแล้ว แต่ควรพูดถึงในทุกโพสต์)
2. ไม่รองรับฟังก์ชั่นนิรนามหลายบรรทัด ( lambdaสามารถมีได้เพียงนิพจน์เดียวเท่านั้น)
3. ไม่มีฟังก์ชั่น / คลาสการอ่านอินพุตที่เรียบง่าย แต่ทรงพลัง (เช่นcinหรือscanfใน C ++ และ C หรือScannerใน Java)
4. สตริงทั้งหมดไม่ใช่ยูนิโค้ดตามค่าเริ่มต้น (แต่ได้รับการแก้ไขใน Python 3)

อาร์กิวเมนต์เริ่มต้นที่มีชนิดข้อมูลที่ไม่แน่นอน

def foo(a, L = []):
    L.append(a)
    print L

>>> foo(1)
[1]
>>> foo(2)
[1, 2]

มันมักจะเป็นผลมาจากข้อบกพร่องที่ลึกซึ้งบางอย่าง ฉันคิดว่ามันจะดีกว่าถ้ามันสร้างวัตถุรายการใหม่เมื่อใดก็ตามที่ต้องการอาร์กิวเมนต์เริ่มต้น (แทนที่จะสร้างวัตถุเดียวที่จะใช้สำหรับการเรียกใช้ฟังก์ชันทุกครั้ง)

แก้ไข: ไม่ใช่ปัญหาใหญ่ แต่เมื่อมีบางสิ่งที่จำเป็นต้องอ้างถึงในเอกสารบ่อยครั้งก็หมายความว่าเป็นปัญหา ไม่ควรทำเช่นนี้

def foo(a, L = None):
    if L is None:
        L = []
    ...

โดยเฉพาะเมื่อนั้นควรจะเป็นค่าเริ่มต้น มันเป็นพฤติกรรมแปลก ๆ ที่ไม่ตรงกับสิ่งที่คุณคาดหวังและไม่เป็นประโยชน์สำหรับสถานการณ์จำนวนมาก

ฟีเจอร์บางส่วนของ Python ที่ทำให้มันมีความยืดหยุ่นเช่นเดียวกับการพัฒนาภาษาก็ถูกมองว่าเป็นข้อเสียเปรียบที่สำคัญโดยที่ใช้ในการวิเคราะห์แบบคงที่ "ทั้งโปรแกรม" ดำเนินการโดยการรวบรวมและกระบวนการเชื่อมโยงในภาษาเช่น C ++ และ Java

• การประกาศตัวแปรท้องถิ่นโดยนัย

มีการประกาศตัวแปรท้องถิ่นโดยใช้คำสั่งการมอบหมายปกติ นี่หมายความว่าการผูกตัวแปรในขอบเขตอื่น ๆ นั้นจำเป็นต้องมีการเพิ่มความคิดเห็นอย่างชัดเจนโดยคอมไพเลอร์ (การประกาศโกลบอลและ nonlocal สำหรับขอบเขตด้านนอกสัญลักษณ์การเข้าถึงแอ็ตทริบิวต์สำหรับขอบเขตอินสแตนซ์) สิ่งนี้จะช่วยลดปริมาณของแผ่นฉนวนที่ต้องใช้อย่างมากเมื่อทำการเขียนโปรแกรม แต่หมายความว่าจำเป็นต้องใช้เครื่องมือวิเคราะห์แบบคงที่ของบุคคลที่สาม (เช่น pyflakes) เพื่อทำการตรวจสอบที่จัดการโดยคอมไพเลอร์ในภาษาที่ต้องการการประกาศตัวแปรที่ชัดเจน

• รองรับการ "Monkey patching"

เนื้อหาของโมดูลวัตถุคลาสและแม้กระทั่ง namespace ในตัวสามารถปรับเปลี่ยนได้ที่รันไทม์ สิ่งนี้มีพลังมหาศาลทำให้มีเทคนิคที่มีประโยชน์มากมาย อย่างไรก็ตามความยืดหยุ่นนี้หมายความว่า Python ไม่ได้มีคุณสมบัติบางอย่างร่วมกับภาษา OO ที่พิมพ์แบบคงที่ ที่โดดเด่นที่สุดคือพารามิเตอร์ "self" to method เป็นวิธีที่ชัดเจนมากกว่าโดยปริยาย (เนื่องจาก "method" ไม่จำเป็นต้องกำหนดไว้ในคลาสพวกเขาสามารถเพิ่มได้ในภายหลังโดยการปรับเปลี่ยนคลาสซึ่งหมายความว่ามันไม่ได้ใช้งานได้จริงโดยเฉพาะ การส่งผ่านการอ้างอิงอินสแตนซ์โดยนัย) และการควบคุมการเข้าถึงคุณลักษณะไม่สามารถบังคับได้อย่างง่ายดายโดยขึ้นอยู่กับว่ารหัสคือ "ข้างใน" หรือ "นอก" ชั้นเรียน (เนื่องจากความแตกต่างนั้นมีอยู่เฉพาะในขณะที่คำจำกัดความของชั้นเรียน

• ห่างไกลจากโลหะ

นี่เป็นความจริงสำหรับภาษาระดับสูงอื่น ๆ อีกมากมาย แต่ Python มีแนวโน้มที่จะสรุปรายละเอียดฮาร์ดแวร์ส่วนใหญ่ ภาษาการเขียนโปรแกรมระบบเช่น C และ C ++ ยังคงเหมาะสมกว่าสำหรับการจัดการการเข้าถึงฮาร์ดแวร์โดยตรง (อย่างไรก็ตาม Python จะพูดคุยอย่างมีความสุขกับภาษาเหล่านั้นผ่านทางโมดูลส่วนขยาย CPython หรือพกพาได้มากกว่าผ่านctypesห้องสมุด)

1. ใช้การเยื้องสำหรับบล็อกรหัสแทน {} / start-end อะไรก็ตาม
2. ภาษาสมัยใหม่ที่ใหม่กว่าทุกภาษามีการกำหนดขอบเขตคำศัพท์ที่เหมาะสม แต่ไม่ใช่ Python (ดูด้านล่าง)
3. Chaotic docs (เปรียบเทียบกับเอกสาร Perl5 ซึ่งยอดเยี่ยม)
4. ช่องแคบแจ็คเก็ต (มีทางเดียวเท่านั้นที่จะทำได้)

ตัวอย่างการกำหนดขอบเขตที่ขาด การถอดเสียงจากเซสชันล่าม:

>>> x=0
>>> def f():
...     x+=3
...     print x
... 
>>> f()
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 2, in f
UnboundLocalError: local variable 'x' referenced before assignment

globalและnonlocalมีการใช้คำหลักเพื่อแก้ไขความโง่เขลาของการออกแบบ

ฉันพบการผสมผสานของ python ของ object-oriented this.method()และmethod(this)syntax / functional syntax / functional function ที่ไม่มั่นคงมาก:

x = [0, 1, 2, 3, 4]
x.count(1)
len(x)
any(x)
x.reverse()
reversed(x)
x.sort()
sorted(x)

นี่เป็นสิ่งที่แย่มากเพราะฟังก์ชั่นจำนวนมาก (แทนที่จะเป็นวิธีการ) ถูกทิ้งลงในเนมสเปซส่วนกลาง : วิธีการที่เกี่ยวข้องกับรายการ, สตริง, ตัวเลข, ตัวสร้าง, metaprogramming ทั้งหมดรวมกันในรายการเรียงตามตัวอักษรขนาดใหญ่

อย่างน้อยที่สุดภาษาที่ใช้งานได้เช่น F # จะมีฟังก์ชั่นทั้งหมดตั้งชื่ออย่างถูกต้องในโมดูล:

List.map(x)
List.reversed(x)
List.any(x)

ดังนั้นพวกเขาจึงไม่ได้ทั้งหมดเข้าด้วยกัน ยิ่งกว่านั้นนี่คือมาตรฐานที่ติดตามทั่วทั้งห้องสมุดดังนั้นอย่างน้อยก็สอดคล้องกัน

ฉันเข้าใจเหตุผลในการทำฟังก์ชั่น vs วิธีแต่ฉันยังคงคิดว่ามันเป็นความคิดที่ไม่ดีที่จะผสมพวกเขาเช่นนี้ ฉันจะมีความสุขมากถ้าปฏิบัติตามไวยากรณ์วิธีอย่างน้อยสำหรับการดำเนินงานทั่วไป:

x.count(1)
x.len()
x.any()
x.reverse()
x.reversed()
x.sort()
x.sorted()

ไม่ว่าวิธีการกลายพันธุ์หรือไม่การมีวิธีการดังกล่าวบนวัตถุนั้นมีข้อดีหลายประการ:

• ที่เดียวเพื่อค้นหาการทำงาน "ทั่วไป" ใน data-type: libraries / etc อื่น ๆ อาจมีสิ่งแฟนซีอื่น ๆ ที่พวกเขาสามารถทำได้กับประเภทข้อมูล แต่การดำเนินการ "เริ่มต้น" ทั้งหมดในวิธีการของวัตถุ
• ไม่จำเป็นต้องให้ทำซ้ำเมื่อโทรModule Module.method(x)ยกตัวอย่างฟังก์ชั่นลิสต์ด้านบนทำไมฉันต้องพูดListซ้ำไปเรื่อย ๆ ? มันควรรู้ว่ามันคือ a Listและฉันไม่ต้องการเรียกใช้Navigation.map()ฟังก์ชันนี้! การใช้x.map()ไวยากรณ์ทำให้มันแห้งและยังคงชัดเจน

และแน่นอนว่ามันมีข้อได้เปรียบเหนือวิธีใส่ทุกอย่างในโลกของการทำมัน ไม่ใช่วิธีปัจจุบันที่ไม่สามารถทำสิ่งต่างๆให้สำเร็จได้ มันเป็นเรื่องที่ค่อนข้างสั้น ( len(lst)) เนื่องจากไม่มีสิ่งใดถูกกำหนดชื่อ! ฉันเข้าใจถึงข้อดีในการใช้ฟังก์ชั่น (พฤติกรรมเริ่มต้น ฯลฯ ) ผ่านวิธีการต่างๆ แต่ฉันก็ยังไม่ชอบ

มันยุ่งแค่ และในโครงการขนาดใหญ่ความยุ่งเหยิงคือศัตรูที่เลวร้ายที่สุดของคุณ

ขาดhomoiconicity

Python ต้องรอ 3.x เพื่อเพิ่มคำหลัก "with" ไม่ว่าจะเป็นภาษา homoiconic ก็ตามมันอาจถูกเพิ่มเข้าไปในห้องสมุดได้เล็กน้อย

ปัญหาอื่น ๆ ส่วนใหญ่ที่ฉันเห็นในคำตอบเป็นหนึ่งใน 3 ประเภท:

1) สิ่งที่สามารถแก้ไขได้ด้วยเครื่องมือ (เช่น pyflakes) 2) รายละเอียดการใช้งาน (GIL ประสิทธิภาพ) 3) สิ่งที่สามารถแก้ไขได้ด้วยมาตรฐานการเข้ารหัส (เช่นคุณสมบัติที่ผู้คนไม่ต้องการ)

# 2 ไม่ใช่ปัญหาเกี่ยวกับภาษา IMO # 1 และ # 3 ไม่ใช่ปัญหาร้ายแรง

Python เป็นภาษาที่ฉันชอบเนื่องจากมีการแสดงออกมาก แต่ก็ยังป้องกันไม่ให้คุณทำผิดพลาดมากเกินไป ฉันยังมีบางสิ่งที่รบกวนฉัน:

• ไม่มีฟังก์ชั่นที่ไม่ระบุชื่อจริง แลมบ์ดาสามารถใช้สำหรับฟังก์ชั่นคำสั่งเดียวและwithสามารถใช้คำสั่งสำหรับหลายสิ่งที่คุณต้องการใช้บล็อกโค้ดในรูบี แต่ในบางสถานการณ์มันทำให้งุ่มง่ามกว่าที่พวกเขาจะต้องเป็น (ห่างไกลจากความซุ่มซ่ามอย่างที่ควรจะเป็นใน Java แต่ก็ยัง ... )

• ความสับสนในความสัมพันธ์ระหว่างโมดูลและไฟล์ การใช้ "python foo.py" จากบรรทัดคำสั่งนั้นแตกต่างจาก "import foo" การนำเข้าสัมพัทธ์ใน Python 2.x สามารถทำให้เกิดปัญหาได้เช่นกัน อย่างไรก็ตามโมดูลของ Python นั้นดีกว่าคุณสมบัติที่เกี่ยวข้องของ C, C ++ และ Ruby

• selfชัดเจน แม้ว่าฉันจะเข้าใจเหตุผลบางอย่างและแม้ว่าฉันจะใช้ Python ทุกวัน แต่ฉันก็มักจะทำผิดพลาดจากการลืมมัน ปัญหาอีกประการหนึ่งของมันคือมันน่าเบื่อนิดหน่อยที่จะสร้างคลาสจากโมดูล ตนเองที่ชัดเจนนั้นเกี่ยวข้องกับการ จำกัด ขอบเขตที่คนอื่น ๆ บ่น ขอบเขตที่เล็กที่สุดใน Python คือขอบเขตของฟังก์ชัน หากคุณทำให้ฟังก์ชั่นของคุณมีขนาดเล็กอย่างที่ควรจะเป็นนั่นไม่ใช่ปัญหาด้วยตัวเองและ IMO มักจะให้โค้ดที่สะอาด

• ฟังก์ชั่นระดับโลกบางอย่างเช่นlenที่คุณคาดหวังว่าจะเป็นวิธีการ (ซึ่งจริง ๆ แล้วมันอยู่เบื้องหลัง)

• การเยื้องที่สำคัญ ไม่ใช่ความคิดของตัวเองซึ่งฉันคิดว่ายอดเยี่ยม แต่เนื่องจากนี่เป็นสิ่งเดียวที่ทำให้ผู้คนจำนวนมากลองใช้ Python บางที Python อาจจะดีกว่าด้วยสัญลักษณ์เริ่มต้น / สิ้นสุดบางอย่าง (เป็นทางเลือก) ไม่สนใจคนเหล่านั้นฉันสามารถมีชีวิตอยู่ด้วยขนาดที่บังคับสำหรับการเยื้องเช่นกัน

• ไม่ใช่ภาษาในตัวของเว็บเบราว์เซอร์แทนที่จะเป็น JavaScript

จากการร้องเรียนเหล่านี้เป็นเพียงคนแรกที่ฉันสนใจพอที่ฉันคิดว่าควรจะเพิ่มในภาษา อีกอันหนึ่งค่อนข้างเล็กยกเว้นอันสุดท้ายซึ่งจะดีมากถ้ามันเกิดขึ้น!

Python ไม่ได้พัฒนาเต็มที่: ภาษา python 3.2 ในขณะนี้มีปัญหาความเข้ากันได้กับแพคเกจส่วนใหญ่ที่กระจายอยู่ในปัจจุบัน นี่เป็นข้อเสียเปรียบครั้งใหญ่ที่ต้องใช้ความพยายามในการพัฒนามากขึ้น (ค้นหาแพ็คเกจที่ต้องการตรวจสอบความเข้ากันได้การเลือกแพคเกจที่ไม่ดีซึ่งอาจเข้ากันได้ดีกว่าใช้เวอร์ชันที่ดีที่สุดอัปเดตเป็น 3.2 ซึ่งอาจใช้เวลาหลายวัน เริ่มทำสิ่งที่มีประโยชน์)

มีแนวโน้มว่าในกลางปี ​​2012 นี้จะมีข้อเสียน้อยกว่า

โปรดทราบว่าฉันคิดว่าฉันได้รับการโหวตจากแฟนบอย ในระหว่างการอภิปรายนักพัฒนาทีมนักพัฒนาระดับสูงของเราถึงข้อสรุปเดียวกันแม้ว่า

ครบกําหนดในความหมายหลักหมายถึงทีมสามารถใช้เทคโนโลยีและทำงานได้อย่างรวดเร็วโดยไม่มีความเสี่ยงซ่อนเร้น (รวมถึงปัญหาความเข้ากันได้) แพคเกจหลามของบุคคลที่สามและแอพจำนวนมากไม่ทำงานภายใต้ 3.2 สำหรับแพ็คเกจส่วนใหญ่ในปัจจุบัน สิ่งนี้ทำให้เกิดการรวมการทำงานการทดสอบการนำเทคโนโลยีมาใช้ใหม่มากกว่าการแก้ปัญหาในมือ == เทคโนโลยีที่เป็นผู้ใหญ่น้อยลง

อัปเดตสำหรับมิถุนายน 2556: Python 3 ยังคงมีปัญหาที่ครบกำหนด บ่อยครั้งที่สมาชิกในทีมจะกล่าวถึงแพคเกจที่จำเป็นแล้วพูดว่า "ยกเว้นเพียง 2.6" (ในบางกรณีเหล่านี้ฉันได้ใช้วิธีแก้ปัญหาผ่านซ็อกเก็ต localhost เพื่อใช้แพ็คเกจ 2.6 เท่านั้นที่มี 2.6 และส่วนที่เหลือของ เครื่องมือของเราใช้ 3.2) ไม่ใช่แม้แต่ MoinMoin, pure-python wiki, ถูกเขียนใน Python 3

การกำหนดขอบเขตของ Python เสียอย่างรุนแรงซึ่งทำให้การเขียนโปรแกรมเชิงวัตถุใน Python อึดอัดใจมาก

ความรู้เกี่ยวกับ Python ของฉัน:

• ปิด OOP (ดูคำตอบของ @ mipadi สำหรับรายละเอียดเกี่ยวกับเรื่องนี้)
• การใช้งาน lambdas ที่ไม่สมบูรณ์
• ปัญหาขอบเขต
• ไม่มีการรวบรวมถาวรในไลบรารีมาตรฐาน
• ความคลาดเคลื่อนไม่ดีต่อ DSLs ในตัว

ตัวดัดแปลงการเข้าถึงใน Python ไม่สามารถใช้บังคับได้ - ทำให้ยากในการเขียนโค้ดที่มีโครงสร้างและโมดูลาร์ที่ดี

ฉันคิดว่านั่นเป็นส่วนหนึ่งของการกำหนดขอบเขตของ @ Mason ปัญหาใหญ่โดยทั่วไปเกี่ยวกับภาษานี้ สำหรับโค้ดที่ควรอ่านได้ดูเหมือนว่าเป็นการยากที่จะคิดว่าอะไรที่ควรและควรอยู่ในขอบเขตและสิ่งที่มีค่าจะอยู่ ณ จุดใด ๆ ในเวลา - ฉันกำลังคิดที่จะย้ายจากภาษา Python เนื่องจากข้อเสียเหล่านี้ .

เพียงเพราะ "เราทุกคนยินยอมผู้ใหญ่" ไม่ได้หมายความว่าเราไม่ได้ทำผิดพลาดและไม่ทำงานได้ดีขึ้นในโครงสร้างที่แข็งแกร่งโดยเฉพาะเมื่อทำงานในโครงการที่ซับซ้อน - การเยื้องและการขีดเส้นใต้ที่ไม่มีความหมายดูเหมือนจะไม่เพียงพอ .

1. ประสิทธิภาพไม่ดี แต่ปรับปรุงด้วย pypy
2. GIL ป้องกันการใช้เธรดเพื่อเร่งโค้ด (แม้ว่านี่จะเป็นการปรับให้เหมาะสมก่อนกำหนด)
3. มันมีประโยชน์สำหรับการเขียนโปรแกรมประยุกต์เท่านั้น

แต่มันมีคุณสมบัติการไถ่ที่ยอดเยี่ยม:

1. มันเหมาะสำหรับ RAD
2. ง่ายต่อการเชื่อมต่อกับ C (และสำหรับ C เพื่อฝังล่ามหลาม)
3. มันอ่านง่ายมาก
4. มันง่ายที่จะเรียนรู้
5. มันเป็นเอกสารที่ดี
6. รวมแบตเตอรี่จริง ๆ มันเป็นห้องสมุดมาตรฐานที่มีขนาดใหญ่มากและ pypi มีโมดูลสำหรับการใช้งานจริงทุกอย่าง
7. มันมีชุมชนที่มีสุขภาพดี

ฉันชอบงูใหญ่และข้อเสียแรกที่มาถึงใจของฉันคือเมื่อแสดงความคิดเห็นออกคำสั่งเช่นif myTest():นั้นคุณต้องเปลี่ยนการเยื้องของบล็อกที่ถูกประหารทั้งหมดซึ่งคุณไม่ต้องทำกับ C หรือ Java อันที่จริงแล้วใน python แทนที่จะแสดงความคิดเห็นในประโยค if-clause แทนฉันเริ่มให้ความเห็นด้วยวิธีนี้: `ถ้าเป็น True: #myTest () ดังนั้นฉันจะไม่ต้องเปลี่ยนบล็อกโค้ดต่อไปนี้อีก เนื่องจาก Java และ C ไม่พึ่งพาการเยื้องจึงทำให้การคอมเม้นท์คำสั่งง่ายขึ้นด้วย C และ Java

การจัดส่งหลายรายการไม่สามารถทำงานร่วมกับระบบประเภทการจัดส่งแบบเดี่ยวได้ดีและไม่ค่อยมีประสิทธิภาพ

การโหลดแบบไดนามิกเป็นปัญหาใหญ่ในระบบไฟล์แบบขนานที่ความหมายคล้าย POSIX นำไปสู่การชะลอตัวลงอย่างรุนแรงสำหรับการดำเนินการที่ต้องใช้ข้อมูลเมตา ฉันมีเพื่อนร่วมงานที่เผาผลาญหนึ่งในสี่ล้านชั่วโมงในการทำงานเพียงแค่รับ Python (ที่มี numpy, mpi4py, petc4py และโมดูลส่วนขยายอื่น ๆ ) ที่โหลดบนแกน 65k (การจำลองส่งผลลัพธ์ทางวิทยาศาสตร์ใหม่ ๆ ที่สำคัญดังนั้นมันจึงคุ้มค่า แต่เป็นปัญหาเมื่อมีการเผาน้ำมันมากกว่าหนึ่งถังเพื่อโหลด Python หนึ่งครั้ง) การไม่สามารถเชื่อมโยงแบบคงที่ได้บังคับให้เราไปสู่การมีส่วนร่วมที่ยอดเยี่ยม เวลาในการโหลดที่สมเหตุสมผลในระดับรวมถึงการแพตช์ libc-rtld เพื่อให้dlopenการเข้าถึงระบบไฟล์ส่วนรวม

• ค่อนข้างมากของห้องสมุดบุคคลที่สามที่สำคัญมากและซอฟต์แวร์ที่ใช้กันอย่างแพร่หลายค่อนข้างไม่ pythonic ตัวอย่างเล็ก ๆ น้อย ๆ : soaplib, openerp, reportlab คำติชมอยู่นอกขอบเขตมันอยู่ที่นั่นมันถูกใช้อย่างกว้างขวาง แต่มันทำให้วัฒนธรรมของงูหลามสับสน (มันเจ็บคำขวัญที่บอกว่า "ควรมีอย่างใดอย่างหนึ่ง ความสำเร็จแบบ pythonic ที่เป็นที่รู้จัก (เช่น django หรือ trac) ดูเหมือนจะเป็นข้อยกเว้น
• ความลึกที่ไม่ จำกัด ของอินสแตนซ์คลาสคลาสเมตาคลาสนั้นมีความสวยงามและเป็นเอกลักษณ์ แต่เพื่อให้เชี่ยวชาญคุณต้องรู้ล่ามอย่างลึกซึ้ง (ซึ่งในรหัสไพ ธ อนนั้นถูกตีความ ฯลฯ ) มันไม่เป็นที่รู้จักและใช้กันอย่างแพร่หลาย (หรือใช้อย่างถูกต้อง) ในขณะที่เวทมนตร์สีดำที่คล้ายกันเช่น C # generics ซึ่งเป็นแนวคิดที่ซับซ้อนมากขึ้น (IMHO) ดูเหมือนว่ารู้จักและใช้กันอย่างแพร่หลายมากขึ้นตามสัดส่วน
• เพื่อให้เข้าใจหน่วยความจำและแบบจำลองเกลียวได้ดีคุณต้องมีประสบการณ์กับงูหลามเนื่องจากไม่มีสเป็คที่ครอบคลุม คุณเพิ่งรู้ว่าอะไรทำงานได้ดีอาจเป็นเพราะคุณอ่านล่ามหรือล่ามที่มีประสบการณ์และค้นพบวิธีการแก้ไข ตัวอย่างเช่นมีการอ้างอิงที่แข็งแกร่งหรืออ่อนแอเท่านั้นไม่ใช่การอ้างอิงแบบ soft และ phantom ของ java Java มีเธรดสำหรับการรวบรวมขยะในขณะที่ไม่มีคำตอบอย่างเป็นทางการเกี่ยวกับเมื่อการรวบรวมขยะเกิดขึ้นในหลาม คุณสามารถสังเกตได้ว่าการรวบรวมขยะไม่ได้เกิดขึ้นหากไม่มีการเรียกใช้งานโค้ดไพ ธ อนและสรุปได้ว่าบางครั้งมันอาจเกิดขึ้นเมื่อพยายามจัดสรรหน่วยความจำ อาจเป็นเรื่องยุ่งยากเมื่อคุณไม่รู้ว่าทำไมทรัพยากรที่ถูกล็อคไม่ได้ถูกปล่อยออกมา (ประสบการณ์ของฉันเกี่ยวกับสิ่งนั้นคือ mod_python ใน freeswitch)

อย่างไรก็ตามหลามเป็นภาษาหลักของฉันเป็นเวลา 4 ปีแล้ว การเป็นแฟนบอย, ชนชั้นนำหรือโมโนมาเนียไม่ได้เป็นส่วนหนึ่งของวัฒนธรรมหลาม

• OOP แปลก ๆ
  • len(s)ผ่าน__len__(self)และ "วิธีการพิเศษ" อื่น ๆ
  • วิธีพิเศษเพิ่มเติมซึ่งอาจมาจากวิธีพิเศษอื่น ๆ ( __add__และ__iadd__สำหรับ+และ+=)
  • self เป็นพารามิเตอร์วิธีแรก
  • คุณสามารถลืมที่จะเรียกตัวสร้างคลาสฐาน
  • ไม่มีตัวดัดแปลงการเข้าถึง (ส่วนตัวป้องกัน ... )
• ไม่มีคำจำกัดความคงที่
• ไม่มีการเปลี่ยนแปลงไม่ได้สำหรับประเภทที่กำหนดเอง
• GIL
• ประสิทธิภาพต่ำซึ่งนำไปสู่การผสมผสานของ Python และ C และปัญหาในการสร้าง (มองหา C libs การพึ่งพาแพลตฟอร์ม ... )
• เอกสารไม่ดีโดยเฉพาะใน libs ของบุคคลที่สาม
• ความไม่ลงรอยกันระหว่าง Python 2.x และ 3.x
• เครื่องมือวิเคราะห์รหัสที่ไม่ดี (เทียบกับสิ่งที่เสนอสำหรับภาษาที่พิมพ์แบบคงที่เช่น Java หรือ C #)

"การเปลี่ยนไม่ได้" ไม่ได้เป็นจุดแข็ง หมายเลข AFAIK tuples และสตริงไม่เปลี่ยนรูปทุกอย่างอื่น (เช่นวัตถุ) ไม่แน่นอน เปรียบเทียบกับภาษาที่ใช้งานได้เช่น Erlang หรือ Haskell ที่ซึ่งทุกอย่างไม่เปลี่ยนรูป (โดยค่าเริ่มต้นอย่างน้อย)

อย่างไรก็ตามการเปลี่ยนไม่ได้จริงๆส่องแสงพร้อมกัน * ซึ่งไม่ได้เป็นจุดแข็งของ Python ดังนั้นอย่างน้อยก็เป็นผลที่ตามมา

(* = สำหรับ nitpickers: ฉันหมายถึงการทำงานพร้อมกันซึ่งอย่างน้อยก็ส่วนคู่ขนานกันฉันเดาว่า Python ใช้ได้กับการเห็นพ้องด้วย "single-threaded" ซึ่งการเปลี่ยนแปลงไม่ได้สำคัญเท่าไร (ใช่ FP-lovers ฉันรู้ว่าการเปลี่ยนแปลงไม่ได้ ยอดเยี่ยมแม้ไม่มีการเกิดขึ้นพร้อมกัน))

ฉันชอบที่จะมีโครงสร้างที่ขนานกันอย่างชัดเจน บ่อยกว่าเมื่อฉันเขียนรายการความเข้าใจเช่น

[ f(x) for x in lots_of_sx ]

ฉันไม่สนใจลำดับที่จะประมวลผลองค์ประกอบ บางครั้งฉันไม่สนใจว่าพวกเขาจะกลับมาเพื่อ

แม้ว่า CPython จะไม่สามารถทำได้ดีเมื่อ f ของฉันเป็น Python แท้ๆ แต่พฤติกรรมเช่นนี้อาจถูกกำหนดไว้สำหรับการใช้งานอื่น ๆ ที่จะใช้

งูใหญ่ไม่มีหางเพิ่มประสิทธิภาพการโทรส่วนใหญ่สำหรับเหตุผลปรัชญา ซึ่งหมายความว่าการวนรอบซ้ำในโครงสร้างขนาดใหญ่อาจทำให้หน่วยความจำ O (n) (เนื่องจากสแต็กที่ไม่จำเป็นซึ่งถูกเก็บไว้) และคุณต้องเขียนการสอบถามซ้ำเป็นวนซ้ำเพื่อรับหน่วยความจำ O (1)