Apa kelemahan dari Python? [Tutup]

Python tampaknya sangat digemari akhir-akhir ini, dan bukan tidak patut - karena ini benar-benar sebuah bahasa yang dengannya seseorang hampir menikmati diberi masalah baru untuk dipecahkan. Tetapi, seperti yang pernah dikatakan oleh orang bijak (memanggilnya orang bijak hanya karena saya tidak tahu siapa yang sebenarnya mengatakannya; tidak yakin apakah dia benar-benar bijak), untuk benar-benar tahu bahasa seseorang tidak hanya tahu itu sintaks, desain, dll. kelebihan tetapi juga kelemahannya. Tidak ada bahasa yang sempurna, ada yang lebih baik dari yang lain.

Jadi, apa yang akan menurut Anda, kelemahan objektif Python.

Catatan: Saya tidak meminta perbandingan bahasa di sini (yaitu C # lebih baik daripada Python karena ... yadda yadda yadda) - lebih merupakan pendapat objektif (sampai tingkat tertentu) yang fitur bahasa dirancang dengan buruk, apakah, apa yang mungkin beberapa Anda hilang di dalamnya dan seterusnya. Jika harus menggunakan bahasa lain sebagai perbandingan, tetapi hanya untuk mengilustrasikan poin yang akan sulit untuk diuraikan sebaliknya (yaitu untuk kemudahan pemahaman)

Saya menggunakan Python agak teratur, dan secara keseluruhan saya menganggapnya sebagai bahasa yang sangat baik. Meskipun demikian, tidak ada bahasa yang sempurna. Berikut adalah kekurangannya menurut saya secara pribadi:

1. Itu lambat. Maksud saya benar-benar lambat. Sering kali ini tidak masalah, tetapi itu pasti berarti Anda akan membutuhkan bahasa lain untuk bit-bit yang kritis terhadap kinerja.

2. Fungsi bersarang semacam menyedot bahwa Anda tidak dapat memodifikasi variabel di lingkup luar. Sunting: Saya masih menggunakan Python 2 karena dukungan perpustakaan, dan cacat desain ini mengganggu saya, tetapi tampaknya sudah diperbaiki di Python 3 karena pernyataan nonlokal . Tidak bisa menunggu libs yang saya gunakan untuk diangkut sehingga cacat ini dapat dikirim ke tumpukan abu sejarah untuk selamanya.

3. Ini kehilangan beberapa fitur yang dapat berguna untuk perpustakaan / kode generik dan IMHO kesederhanaan dibawa ke ekstrem tidak sehat. Yang paling penting yang dapat saya pikirkan adalah tipe nilai yang ditentukan pengguna (Saya menduga ini dapat dibuat dengan metaclass magic, tapi saya belum pernah mencoba), dan parameter fungsi ref.

4. Jauh dari logam. Perlu menulis threading primitif atau kode kernel atau sesuatu? Semoga berhasil.

5. Sementara saya tidak keberatan kurangnya kemampuan untuk menangkap kesalahan semantik di muka sebagai tradeoff untuk dinamisme yang ditawarkan Python, saya berharap ada cara untuk menangkap kesalahan sintaksis dan hal-hal konyol seperti salah ketik nama variabel tanpa harus benar-benar menjalankan kode.

6. Dokumentasi tidak sebagus bahasa seperti PHP dan Java yang memiliki dukungan perusahaan yang kuat.

Saya benci bahwa Python tidak dapat membedakan antara deklarasi dan penggunaan variabel. Anda tidak perlu mengetik statis untuk mewujudkannya. Akan menyenangkan untuk memiliki cara untuk mengatakan "ini adalah variabel yang saya nyatakan dengan sengaja, dan saya bermaksud untuk memperkenalkan nama baru, ini bukan salah ketik".

Selain itu, saya biasanya menggunakan variabel Python dalam gaya tulis-sekali, yaitu, saya memperlakukan variabel sebagai tidak berubah dan tidak memodifikasinya setelah tugas pertama mereka. Berkat fitur seperti pemahaman daftar, ini sebenarnya sangat mudah dan membuat aliran kode lebih mudah diikuti.

Namun, saya tidak bisa mendokumentasikan fakta itu. Tidak ada dalam Python yang mencegah saya dari menimpa atau menggunakan kembali variabel.

Singkatnya, saya ingin memiliki dua kata kunci dalam bahasa: vardan let. Jika saya menulis ke variabel yang tidak dideklarasikan oleh salah satu dari mereka, Python seharusnya menimbulkan kesalahan. Lebih lanjut, letdeklarasikan variabel sebagai read-only, sementara varvariabelnya “normal”.

Pertimbangkan contoh ini:

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

Perhatikan bahwa jenisnya masih implisit (tetapi letvariabel untuk semua maksud dan tujuan diketik secara statis karena tidak dapat dikembalikan ke nilai baru, sementara varvariabel mungkin masih diketik secara dinamis).

Akhirnya, semua argumen metode harus secara otomatis let, yaitu argumen harus hanya-baca. Secara umum tidak ada alasan untuk memodifikasi parameter, kecuali untuk idiom berikut:

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

Ini bisa digantikan oleh idiom yang sedikit berbeda:

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

Keluhan utama saya adalah threading, yang tidak sebagus pemain dalam banyak keadaan (dibandingkan dengan Java, C dan lainnya) karena kunci juru bahasa global (lihat pembicaraan "Di dalam Python GIL" (tautan PDF) )

Namun ada antarmuka multiproses yang sangat mudah digunakan, namun itu akan lebih berat pada penggunaan memori untuk jumlah proses yang sama vs utas, atau sulit jika Anda memiliki banyak data bersama. Namun manfaatnya adalah bahwa begitu Anda memiliki program yang bekerja dengan banyak proses, ia dapat menskala di beberapa mesin, sesuatu yang tidak dapat dilakukan oleh program berulir.

Saya benar-benar tidak setuju dengan kritik dokumentasi, saya pikir ini sangat bagus dan lebih baik daripada kebanyakan jika tidak semua bahasa utama di luar sana.

Anda juga dapat menangkap banyak bug runtime yang menjalankan pylint .

Bisa dibilang , kurangnya pengetikan statis, yang dapat memperkenalkan kelas tertentu dari kesalahan runtime , tidak sebanding dengan fleksibilitas tambahan yang disediakan oleh pengetikan bebek.

Saya pikir bagian berorientasi objek dari Python merasa agak "melesat". Seluruh kebutuhan untuk secara eksplisit meneruskan "diri" ke setiap metode adalah gejala bahwa komponen OOP tidak direncanakan secara tersurat , bisa dibilang; ini juga menunjukkan aturan pelingkupan Python yang kadang-kadang berkutil yang dikritik dalam jawaban lain.

Sunting:

Ketika saya mengatakan bagian berorientasi objek Python merasa "melesat", maksud saya kadang-kadang, sisi OOP terasa agak tidak konsisten. Ambil Ruby, misalnya: Di Ruby, semuanya adalah objek, dan Anda memanggil metode menggunakan obj.methodsintaks yang sudah dikenal (tentu saja, kecuali operator yang kelebihan beban); dalam Python, semuanya adalah objek juga, tetapi beberapa metode yang Anda sebut sebagai fungsi; yaitu, Anda membebani __len__untuk mengembalikan panjang, tetapi menyebutnya menggunakan len(obj)alih-alih bahasa yang lebih umum (dan konsisten) obj.lengthdalam bahasa lain. Saya tahu ada alasan di balik keputusan desain ini, tetapi saya tidak menyukainya.

Plus, model OOP Python tidak memiliki perlindungan data apa pun, yaitu, tidak ada anggota pribadi, terlindungi, dan publik; Anda dapat meniru mereka menggunakan _dan __di depan metode, tapi itu agak jelek. Demikian pula, Python juga tidak cukup memahami aspek penyampaian pesan dari OOP.

Hal yang tidak saya sukai tentang Python:

1. Threading (saya tahu itu sudah disebutkan, tetapi layak disebutkan di setiap posting).
2. Tidak ada dukungan untuk fungsi anonim multi-baris ( lambdahanya dapat berisi satu ekspresi).
3. Kurangnya fungsi / kelas pembacaan input yang sederhana namun kuat (seperti cinatau scanfdalam C ++ dan C atau Scannerdi Jawa).
4. Semua string bukan unicode secara default (tetapi diperbaiki dalam Python 3).

Argumen default dengan tipe data yang bisa berubah.

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

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

Ini biasanya hasil dari beberapa bug halus. Saya pikir akan lebih baik jika ia membuat objek daftar baru setiap kali argumen default diperlukan (daripada membuat objek tunggal untuk digunakan untuk setiap panggilan fungsi).

Sunting: Ini bukan masalah besar, tetapi ketika sesuatu perlu dirujuk dalam dokumen, itu biasanya berarti itu adalah masalah. Ini seharusnya tidak diperlukan.

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

Terutama ketika itu seharusnya menjadi default. Itu hanya perilaku aneh yang tidak sesuai dengan apa yang Anda harapkan dan tidak berguna untuk sejumlah besar keadaan.

Beberapa fitur Python yang membuatnya sangat fleksibel sebagai bahasa pengembangan juga dipandang sebagai kelemahan utama oleh yang digunakan untuk analisis statis "seluruh program" yang dilakukan oleh proses kompilasi dan menghubungkan dalam bahasa seperti C ++ dan Java.

• Deklarasi implisit variabel lokal

Variabel lokal dideklarasikan menggunakan pernyataan penugasan biasa. Ini berarti bahwa pengikatan variabel dalam ruang lingkup lain memerlukan penjelasan eksplisit untuk diambil oleh kompiler (deklarasi global dan nonlokal untuk cakupan luar, notasi akses atribut untuk cakupan contoh). Ini secara besar-besaran mengurangi jumlah boilerplate yang dibutuhkan saat pemrograman, tetapi berarti bahwa alat analisis statis pihak ketiga (seperti serpihan) diperlukan untuk melakukan pemeriksaan yang ditangani oleh kompiler dalam bahasa yang memerlukan deklarasi variabel eksplisit.

• "Monkey patching" didukung

Isi modul, objek kelas dan bahkan namespace builtin dapat dimodifikasi saat runtime. Ini sangat kuat, memungkinkan banyak teknik yang sangat berguna. Namun, fleksibilitas ini berarti bahwa Python tidak menawarkan beberapa fitur umum untuk bahasa OO yang diketik secara statis. Yang paling penting, parameter "diri" ke metode instance lebih eksplisit daripada implisit (karena "metode" tidak harus didefinisikan di dalam kelas, mereka dapat ditambahkan kemudian dengan memodifikasi kelas, yang berarti bahwa itu tidak terlalu praktis untuk melewatkan referensi instance secara implisit) dan kontrol akses atribut tidak dapat dengan mudah ditegakkan berdasarkan pada apakah kode "di dalam" atau "di luar" kelas (karena perbedaan itu hanya ada ketika definisi kelas sedang dieksekusi).

• Jauh dari logam

Ini juga berlaku untuk banyak bahasa tingkat tinggi lainnya, tetapi Python cenderung mengabstraksi sebagian besar detail perangkat keras. Bahasa pemrograman sistem seperti C dan C ++ masih jauh lebih cocok untuk menangani akses perangkat keras langsung (namun, Python akan dengan senang hati berbicara dengan mereka baik melalui modul ekstensi CPython atau, lebih mudah dibawa, melalui ctypesperpustakaan).

1. Menggunakan lekukan untuk blok kode alih-alih {} / begin-end, apa pun.
2. Setiap bahasa modern yang lebih baru memiliki ruang lingkup leksikal yang tepat, tetapi tidak Python (lihat di bawah).
3. Dokumen kacau (bandingkan dengan dokumentasi Perl5, yang hebat).
4. Jaket selat (hanya ada satu cara untuk melakukannya).

Contoh untuk pelingkupan rusak; transkrip dari sesi juru bahasa:

>>> 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

globaldan nonlocalkata kunci telah diperkenalkan untuk menambal kebodohan desain ini.

Saya menemukan kombinasi python dari berorientasi objek this.method()dan method(this)sintaks prosedural / fungsional sangat mengganggu:

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

Ini sangat buruk karena sejumlah besar fungsi (bukan metode) hanya dibuang ke ruang nama global : metode yang berkaitan dengan daftar, string, angka, konstruktor, pemrograman, semua dicampur dalam satu daftar besar yang diurutkan berdasarkan abjad.

Paling tidak, bahasa-bahasa fungsional seperti F # memiliki semua fungsi dengan benar yang diberi nama dalam modul:

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

Jadi mereka tidak bersama-sama. Selain itu, ini adalah standar yang diikuti di seluruh perpustakaan, jadi setidaknya konsisten.

Saya mengerti alasan untuk melakukan fungsi vs metode hal, tetapi saya masih berpikir itu ide yang buruk untuk mencampur mereka seperti ini. Saya akan jauh lebih bahagia jika sintaks metode diikuti, setidaknya untuk operasi umum:

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

Apakah metode tersebut bermutasi atau tidak, menjadikannya sebagai metode pada objek memiliki beberapa keuntungan:

• Satu tempat untuk mencari operasi "umum" pada tipe data: perpustakaan lain / dll. mungkin memiliki hal-hal mewah lain yang bisa mereka lakukan untuk tipe data tetapi operasi "default" semua dalam metode objek.
• Tidak perlu terus mengulangi Modulesaat menelepon Module.method(x). Mengambil contoh Daftar fungsional di atas, mengapa saya harus terus mengatakannya Listberulang kali? Seharusnya tahu bahwa itu adalah Listdan saya tidak ingin memanggil Navigation.map()fungsi di atasnya! Menggunakan x.map()sintaksis membuatnya tetap KERING dan masih tidak ambigu.

Dan tentu saja ia memiliki kelebihan dibandingkan dengan cara namespace global dalam melakukannya. Bukannya cara saat ini tidak mampu menyelesaikan sesuatu. Ini bahkan cukup singkat ( len(lst)), karena tidak ada yang namanya namespace! Saya memahami keuntungan menggunakan fungsi (perilaku default, dll.) Daripada metode, tapi saya masih tidak menyukainya.

Hanya berantakan. Dan dalam proyek-proyek besar, kekacauan adalah musuh terburuk Anda.

Kurangnya homoiconicity .

Python harus menunggu 3.x untuk menambahkan kata kunci "with". Dalam bahasa homoikonik apa pun itu dapat dengan sepele ditambahkan di perpustakaan.

Sebagian besar masalah lain yang saya lihat dalam jawaban adalah dari satu dari 3 jenis:

1) Hal-hal yang dapat diperbaiki dengan tooling (misalnya serpihan) 2) Detail implementasi (GIL, kinerja) 3) Hal-hal yang dapat diperbaiki dengan standar pengkodean (yaitu fitur yang orang inginkan tidak ada di sana)

# 2 bukan masalah dengan bahasa, IMO # 1 dan # 3 bukan masalah serius.

Python adalah bahasa favorit saya karena sangat ekspresif, tetapi masih membuat Anda tidak melakukan terlalu banyak kesalahan. Saya masih memiliki beberapa hal yang mengganggu saya:

• Tidak ada fungsi anonim nyata. Lambda dapat digunakan untuk fungsi pernyataan tunggal, dan withpernyataan itu dapat digunakan untuk banyak hal di mana Anda akan menggunakan blok kode di Ruby. Tetapi dalam beberapa situasi itu membuat hal-hal sedikit lebih canggung daripada yang seharusnya. (Jauh dari kikuk seperti di Jawa, tapi masih ...)

• Beberapa kebingungan dalam hubungan antara modul dan file. Menjalankan "python foo.py" dari baris perintah berbeda dari "import foo". Impor relatif di Python 2.x juga dapat menyebabkan masalah. Namun, modul Python jauh lebih baik daripada fitur yang sesuai dari C, C ++ dan Ruby.

• Eksplisit self. Meskipun saya mengerti beberapa alasan untuk itu, dan meskipun saya menggunakan Python setiap hari, saya cenderung membuat kesalahan dengan melupakannya. Masalah lainnya adalah sedikit membosankan untuk membuat kelas dari modul. Eksplisit diri terkait dengan pelingkupan terbatas yang telah dikeluhkan orang lain. Ruang lingkup terkecil di Python adalah ruang lingkup fungsi. Jika Anda menjaga fungsi Anda kecil, seperti seharusnya, itu bukan masalah dengan sendirinya dan IMO sering memberikan kode bersih.

• Beberapa fungsi global, seperti len, yang Anda harapkan menjadi metode (yang sebenarnya ada di balik layar).

• Lekukan yang signifikan. Bukan ide itu sendiri, yang menurut saya hebat, tetapi karena ini adalah satu-satunya hal yang mencegah begitu banyak orang dari mencoba Python, mungkin Python akan lebih baik dengan beberapa (opsional) simbol awal / akhir. Mengabaikan orang-orang itu, aku benar-benar bisa hidup dengan ukuran yang dipaksakan untuk lekukan juga.

• Itu bukan bahasa bawaan browser web, bukan JavaScript.

Dari keluhan-keluhan ini, itu hanya yang pertama yang saya cukup peduli sehingga saya pikir itu harus ditambahkan ke bahasa. Yang lain agak kecil, kecuali yang terakhir, yang akan bagus jika itu terjadi!

Python tidak sepenuhnya matang: bahasa python 3.2 pada saat ini memiliki masalah kompatibilitas dengan sebagian besar paket yang saat ini didistribusikan (biasanya mereka kompatibel dengan python 2.5). Ini adalah kelemahan besar yang saat ini membutuhkan lebih banyak upaya pengembangan (menemukan paket yang dibutuhkan; memverifikasi kompatibilitas; mempertimbangkan memilih paket yang tidak baik yang mungkin lebih kompatibel; mengambil versi terbaik, memperbaruinya menjadi 3,2 yang bisa memakan waktu berhari-hari; kemudian mulai melakukan sesuatu yang bermanfaat).

Kemungkinan pada pertengahan 2012 ini akan menjadi kekurangan.

Perhatikan bahwa saya kira saya dipilih oleh seorang fan-boy. Namun, selama diskusi pengembang, tim pengembang tingkat tinggi kami mencapai kesimpulan yang sama.

Kedewasaan dalam satu arti utama berarti tim dapat menggunakan teknologi dan menjadi sangat cepat & berjalan tanpa risiko tersembunyi (termasuk masalah kompatibilitas). Paket python pihak ke-3 dan banyak aplikasi tidak berfungsi di bawah 3.2 untuk sebagian besar paket saat ini. Ini menciptakan lebih banyak pekerjaan integrasi, menguji, mengimplementasikan kembali teknologi itu sendiri alih-alih menyelesaikan masalah yang ada == teknologi yang kurang matang.

Pembaruan untuk Juni 2013: Python 3 masih memiliki masalah kedewasaan. Sering kali seorang anggota tim akan menyebutkan paket yang diperlukan lalu mengatakan "kecuali itu hanya untuk 2,6" (dalam beberapa kasus ini saya telah menerapkan solusi melalui localhost socket untuk menggunakan paket 2.6-only dengan 2.6, dan sisanya dari alat kami tetap dengan 3.2). Bahkan MoinMoin, wiki python murni, tidak ditulis dalam Python 3.

Pelingkupan Python rusak parah, yang membuat pemrograman berorientasi objek di Python sangat canggung.

Keluhan saya tentang Python:

• Bolt-on OOP (Lihat jawaban @ mipadi untuk penjelasan lebih lanjut tentang ini)
• Implementasi lambda yang rusak
• Masalah ruang lingkup
• Tidak ada koleksi persisten di perpustakaan standar
• Amenabilitas yang buruk terhadap DSL yang tertanam

Akses pengubah dalam Python tidak dapat ditegakkan - membuatnya sulit untuk menulis kode terstruktur, termodulasi dengan baik.

Saya kira itu adalah bagian dari pelingkupan @ Mason yang rusak - masalah besar secara umum dengan bahasa ini. Untuk kode yang seharusnya dapat dibaca, tampaknya cukup sulit untuk mencari tahu apa yang bisa dan harus berada dalam ruang lingkup dan berapa nilainya pada suatu titik waktu - saya saat ini sedang berpikir untuk pindah dari bahasa Python karena kelemahan ini .

Hanya karena "kita semua menyetujui orang dewasa" tidak berarti bahwa kita tidak melakukan kesalahan dan tidak bekerja lebih baik dalam struktur yang kuat, terutama ketika bekerja pada proyek yang kompleks - lekukan dan garis bawah yang tidak berarti tampaknya tidak cukup memadai .

1. Performanya tidak baik, tetapi membaik dengan pypy,
2. GIL mencegah penggunaan threading untuk mempercepat kode, (meskipun ini biasanya optimasi prematur),
3. Ini hanya berguna untuk pemrograman aplikasi,

Tetapi memiliki beberapa fitur penukaran yang hebat:

1. Ini sempurna untuk RAD,
2. Mudah untuk berinteraksi dengan C (dan untuk C menanamkan interpreter python),
3. Ini sangat mudah dibaca,
4. Mudah dipelajari,
5. Ini didokumentasikan dengan baik,
6. Baterai benar-benar disertakan, perpustakaan standarnya sangat besar dan pypi berisi modul untuk hampir semuanya,
7. Ia memiliki komunitas yang sehat.

Saya mendukung python dan kerugian pertama yang muncul di benak saya adalah ketika mengomentari pernyataan seperti if myTest():maka Anda harus mengubah lekukan dari seluruh blok yang dieksekusi yang tidak perlu Anda lakukan dengan C atau Java. Sebenarnya dalam python alih-alih mengomentari sebuah if-clause, saya sudah mulai berkomentar dengan cara ini: `if True: #myTest () jadi saya juga tidak perlu mengubah blok kode berikut. Karena Java dan C tidak bergantung pada indentasi, itu membuat komentar pernyataan lebih mudah dengan C dan Java.

Pengiriman ganda tidak terintegrasi dengan baik dengan sistem jenis pengiriman tunggal yang sudah mapan dan tidak terlalu performan.

Pemuatan dinamis adalah masalah besar pada sistem file paralel di mana semantik mirip POSIX mengarah pada pelambatan katastropik untuk operasi intensif metadata. Saya memiliki kolega yang telah membakar seperempat juta core-jam hanya mendapatkan Python (dengan numpy, mpi4py, petsc4py, dan modul ekstensi lainnya) dimuat di 65k core. (Simulasi memberikan hasil sains baru yang signifikan, jadi itu sepadan, tetapi itu adalah masalah ketika lebih dari satu barel minyak dibakar untuk memuat Python sekali.) Ketidakmampuan untuk terhubung secara statis telah memaksa kita untuk pergi ke contortions besar untuk mendapatkan waktu pemuatan yang wajar pada skala, termasuk menambal libc-rtld untuk dlopenmelakukan akses sistem file kolektif.

• cukup banyak perpustakaan dan perangkat lunak pihak ke-3 yang sangat umum yang banyak digunakan, tidak terlalu pythonic. Beberapa contoh: soaplib, openerp, reportlab. Kritik berada di luar jangkauan, itu ada di sana, itu digunakan secara luas, tetapi itu membuat budaya python membingungkan (itu menyakitkan moto yang mengatakan "Harus ada satu - dan lebih disukai hanya satu - cara yang jelas untuk melakukannya"). Keberhasilan pythonic yang dikenal (seperti Django atau trac) tampaknya menjadi pengecualian.
• kedalaman abstraksi yang berpotensi tak terbatas misalnya, kelas, metaclass secara konseptual indah dan unik. Tetapi untuk menguasainya, Anda harus sangat memahami juru bahasa (di mana urutan kode python ditafsirkan, dll.). Ini tidak banyak dikenal dan digunakan (atau digunakan dengan benar), sementara sihir hitam yang serupa seperti C # generics, yang secara konsep lebih berbelit-belit (IMHO) tampaknya lebih dikenal dan digunakan secara proporsional.
• untuk mendapatkan pemahaman yang baik tentang memori dan model threading, Anda harus cukup berpengalaman dengan python, karena tidak ada spesifikasi komprehensif. Anda hanya tahu apa yang berhasil, mungkin karena Anda membaca sumber juru bahasa atau kebiasaan unik dan menemukan cara untuk memperbaikinya. Misalnya, hanya ada referensi kuat atau lemah, bukan referensi lunak dan hantu java. Java memiliki utas untuk pengumpulan sampah sementara tidak ada jawaban resmi tentang kapan pengumpulan sampah terjadi dengan python; Anda bisa mengamati bahwa pengumpulan sampah tidak terjadi jika tidak ada kode python dieksekusi, dan menyimpulkan itu mungkin terjadi kadang-kadang ketika mencoba mengalokasikan memori. Dapat menjadi rumit ketika Anda tidak tahu mengapa sumber daya yang terkunci tidak dirilis (pengalaman saya tentang itu adalah mod_python di freeswitch).

Bagaimanapun, python adalah bahasa utama saya selama 4 tahun sekarang. Menjadi fanboys, elitis atau monomaniac bukanlah bagian dari budaya python.

• OOP aneh:
  • len(s)melalui __len__(self)dan "metode khusus" lainnya
  • metode khusus ekstra yang dapat diturunkan dari metode khusus lainnya ( __add__dan __iadd__untuk +dan +=)
  • self sebagai parameter metode pertama
  • Anda bisa lupa memanggil konstruktor kelas dasar
  • tidak ada pengubah akses (pribadi, terlindungi ...)
• tidak ada definisi yang konstan
• tidak ada kekekalan untuk jenis khusus
• GIL
• kinerja buruk yang mengarah ke campuran Python dan C dan masalah dengan build (mencari C libs, dependensi platform ...)
• dokumentasi yang buruk, terutama di lib pihak ketiga
• ketidakcocokan antara Python 2.x dan 3.x
• alat analisis kode yang buruk (dibandingkan dengan apa yang ditawarkan untuk bahasa yang diketik secara statis seperti Java atau C #)

"Kekekalan" bukan titik kuatnya. Angka AFAIK, tupel, dan string tidak dapat diubah, yang lainnya (yaitu objek) dapat berubah. Bandingkan dengan bahasa fungsional seperti Erlang atau Haskell di mana semuanya tidak berubah (secara default, setidaknya).

Namun, Immutability benar-benar bersinar dengan concurrency *, yang juga bukan poin kuat Python, jadi setidaknya itu konsekuensinya.

(* = Untuk para nitpicker: maksud saya konkurensi yang setidaknya sebagian paralel. Saya kira Python tidak apa-apa dengan konkurensi "single-threaded", di mana imutabilitas tidak sama pentingnya. (Ya, pecinta FP, saya tahu bahwa immutabilitas adalah hebat bahkan tanpa konkurensi.))

Saya ingin memiliki konstruksi paralel yang eksplisit. Lebih sering daripada tidak, ketika saya menulis daftar pemahaman suka

[ f(x) for x in lots_of_sx ]

Saya tidak peduli urutan elemen akan diproses. Kadang-kadang, saya bahkan tidak peduli dalam urutan mana mereka dikembalikan.

Bahkan jika CPython tidak dapat melakukannya dengan baik ketika f saya adalah Python murni, perilaku seperti ini dapat didefinisikan untuk implementasi lain untuk digunakan.

Python tidak memiliki optimisasi panggilan-ekor, sebagian besar karena alasan filosofis . Ini berarti bahwa pengulangan ekor pada struktur besar dapat menghabiskan biaya O (n) memori (karena tumpukan yang tidak perlu disimpan) dan akan meminta Anda untuk menulis ulang rekursi sebagai loop untuk mendapatkan memori O (1).