it-swarm-id.com

Apa kekurangan dari Python?

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. Tapi, sebagai orang bijak pernah berkata (memanggilnya orang bijak hanya karena saya tidak tahu siapa yang benar-benar mengatakannya; tidak yakin apakah dia bijak pada semua), untuk benar-benar mengetahui bahasa seseorang tidak hanya tahu sintaks, desain, dll, kelebihannya tetapi juga kelemahannya. Tidak ada bahasa yang sempurna, beberapa hanya 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 tujuan (ke tingkat tertentu) pendapat fitur bahasa yang dirancang dengan buruk, apakah, apa mungkin beberapa yang Anda lewatkan di dalamnya dan sebagainya. Jika harus menggunakan bahasa lain sebagai perbandingan, tetapi hanya untuk menggambarkan suatu titik yang akan sulit untuk diuraikan sebaliknya (yaitu untuk kemudahan pengertian)

147
Rook

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

  1. Itu lambat. Maksud saya benar-benar lambat. Sering kali ini tidak masalah, tetapi itu pasti berarti Anda 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 membuat saya kesal, tetapi ternyata itu tetap di Python 3 karena pernyataan nonlocal . Tidak bisa menunggu libs yang saya gunakan untuk di-port sehingga kesalahan ini dapat dikirim ke ash tumpukan sejarah untuk selamanya.

  3. Itu 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 dimuka sebagai tradeoff untuk dinamika yang Python menawarkan, 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.

109
dsimcha

Saya benci itu Python tidak dapat membedakan antara deklarasi dan penggunaan variabel. Anda tidak perlu mengetik statis untuk mewujudkannya. Akan lebih baik jika 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 Python variabel dalam gaya tulis-sekali, yaitu, saya memperlakukan variabel sebagai tidak berubah dan tidak memodifikasinya setelah penugasan 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 mencegah saya membentuk variabel yang menimpa atau menggunakan kembali.

Singkatnya, saya ingin memiliki dua kata kunci dalam bahasa ini: var dan let. Jika saya menulis ke variabel yang tidak dideklarasikan oleh salah satu dari mereka, Python akan menimbulkan kesalahan. Selanjutnya, let menyatakan variabel sebagai hanya-baca, sedangkan var variabelnya "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 variabel let adalah untuk semua maksud dan tujuan yang diketik secara statis karena mereka tidak dapat dikembalikan ke nilai baru, sementara variabel var variabel mungkin masih diketik secara dinamis).

Akhirnya, semua argumen metode harus secara otomatis let, yaitu mereka 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]
66
Konrad Rudolph

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

Namun ada antarmuka multiproses yang sangat mudah digunakan, namun 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 sekali 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 itu sangat bagus dan lebih baik daripada kebanyakan jika tidak semua bahasa utama di luar sana.

Anda juga dapat menangkap banyak bug runtime yang berjalan pylint .

44
cmcginty

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

28
Jacob

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

Edit:

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 sintaks obj.method Yang familier (dengan pengecualian operator kelebihan beban, dari tentu saja); 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 yang lebih umum (dan konsisten) obj.length umum dalam bahasa lain. Saya tahu ada alasan di balik keputusan desain ini, tetapi saya tidak menyukainya.

Selain itu, model OOP Python tidak memiliki perlindungan data apa pun, mis., Tidak ada anggota pribadi, yang dilindungi, dan publik; Anda dapat meniru mereka menggunakan _ dan __ di depan metode, tapi itu agak jelek. Demikian pula, Python tidak cukup mendapatkan aspek penyampaian pesan dari OOP benar juga.

27
mipadi

Hal yang tidak saya sukai tentang Python:

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

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 itu 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, umumnya 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.

18
jsternberg

Beberapa fitur Python yang membuatnya sangat fleksibel sebagai bahasa pengembangan juga dilihat 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 dinyatakan 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 yang umum untuk bahasa yang diketik secara statis OO. Terutama, parameter "self" untuk metode instance adalah 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 melewati referensi instance secara implisit) dan kontrol akses atribut dapat ' Tidak mudah diberlakukan berdasarkan apakah kode "di dalam" atau "di luar" kelas (karena perbedaan itu hanya ada saat 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 mudahnya, melalui perpustakaan ctypes).

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

global dan nonlocal kata kunci telah diperkenalkan untuk menambal kebodohan desain ini.

12
zvrba

Saya menemukan kombinasi python dari berorientasi objek this.method() dan prosedural/fungsional method(this) sintaks 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 global namespace : metode yang berkaitan dengan daftar, string, angka, konstruktor, metaprogramming, semua tercampur dalam satu besar daftar menurut 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 , tetapi saya masih berpikir itu ide yang buruk untuk mencampurkan 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 mengulangi Module saat memanggil Module.method(x). Mengambil contoh Daftar fungsional di atas, mengapa saya harus terus mengatakan List berulang kali? Seharusnya tahu bahwa itu adalah List dan saya tidak ingin memanggil fungsi Navigation.map() di atasnya! Menggunakan x.map() sintaks mempertahankannya DRY dan masih tidak ambigu.

Dan tentu saja ia memiliki kelebihan dibandingkan dengan cara menempatkan-semuanya-di-global-namespace untuk melakukannya. Bukan berarti cara saat ini adalah tidak mampu untuk menyelesaikan sesuatu. Ini bahkan cukup singkat (len(lst)), karena tidak ada yang dinamai! Saya memahami keuntungan dalam menggunakan fungsi (perilaku default, dll.) Di atas metode, tapi saya masih tidak menyukainya.

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

11
Haoyi

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 (mis. Pyflakes) 2) Detail implementasi (GIL, kinerja) 3) Hal-hal yang dapat diperbaiki dengan standar pengkodean (mis. Fitur yang diinginkan orang tidak ada di sana)

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

8
Jason

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 pernyataan with 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 dalam 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 lain dengannya adalah menjadi sedikit membosankan untuk buat kelas dari modul. Cukup eksplisit terkait dengan pelingkupan terbatas yang dikeluhkan orang lain. Ruang lingkup terkecil dalam Python adalah lingkup fungsi. Jika Anda menjaga fungsi Anda kecil, seperti Anda 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 mencoba Python, mungkin Python akan lebih baik dengan beberapa (opsional) 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!

7
Martin Vilcans

Python belum sepenuhnya matang: bahasa python 3.2 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 upaya pengembangan lebih lanjut (menemukan paket yang dibutuhkan; memverifikasi kompatibilitas; mempertimbangkan memilih paket yang tidak baik yang mungkin lebih kompatibel; ambil versi terbaik, perbarui ke 3.2 yang dapat mengambil hari; kemudian mulai melakukan sesuatu yang bermanfaat).

Kemungkinan pada pertengahan 2012 ini akan menjadi kekurangan.

Perhatikan bahwa saya kira saya diputuskan oleh fan-boy. Selama diskusi pengembang tim pengembang tingkat tinggi kami mencapai kesimpulan yang sama.

Kematangan dalam satu arti utama berarti tim dapat menggunakan teknologi dan menjadi sangat cepat & berjalan tanpa risiko tersembunyi (termasuk masalah kompatibilitas). Pihak ke-3 python dan banyak aplikasi tidak bekerja 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 ' Kami telah mengimplementasikan solusi melalui localhost socket untuk menggunakan paket 2.6-only dengan 2.6, dan alat-alat kami lainnya tetap menggunakan 3.2) .M bahkan MoinMoin, wiki python murni, ditulis dalam Python = 3.

5

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

4
Mason Wheeler

Akses pengubah dalam Python tidak dapat diterapkan - membuatnya sulit untuk menulis kode termodulasi terstruktur 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 mengetahui apa yang bisa dan harus berada dalam ruang lingkup dan nilai apa yang akan ada pada suatu titik waktu - saya saat ini sedang berpikir untuk pindah dari Python bahasa karena kekurangan 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-proyek kompleks - lekukan dan garis bawah yang tidak berarti tampaknya tidak cukup memadai .

4
Vector

Keluhan saya tentang Python:

  • Bolted-on OOP (Lihat jawaban @ mipadi untuk elaborasi ini)
  • Implementasi lambda yang rusak
  • Masalah ruang lingkup
  • Tidak ada koleksi persisten di perpustakaan standar
  • Amenabilitas yang buruk terhadap DSL yang tertanam
4
missingfaktor

Pengiriman ganda tidak terintegrasi dengan baik dengan sistem jenis pengiriman tunggal dan tidak terlalu berkinerja.

Pemuatan dinamis adalah masalah besar pada sistem file paralel di mana semantik mirip POSIX mengarah ke perlambatan 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 ilmu baru yang signifikan hasil, jadi itu layak, tetapi itu adalah masalah ketika lebih dari satu barel minyak dibakar untuk memuat Python sekali.) Ketidakmampuan untuk menghubungkan secara statis telah memaksa kita untuk pergi ke contortions besar untuk dapatkan waktu muat yang masuk akal dalam skala, termasuk menambal libc-rtld untuk membuat dlopen melakukan akses sistem file kolektif.

3
Jed
  • 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 cakupan, 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 merupakan pengecualian.
  • kedalaman abstraksi yang berpotensi tidak terbatas misalnya, kelas, metaclass secara konseptual indah dan unik. Tetapi untuk menguasainya, Anda harus sangat memahami juru bahasa (di mana urutan python ditafsirkan, dll.). Ini tidak banyak dikenal dan digunakan (atau digunakan dengan benar), sementara sihir hitam yang serupa seperti sebagai 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 phantom Java. Java memiliki utas untuk pengumpulan sampah sementara tidak ada jawaban resmi tentang kapan pengumpulan sampah terjadi di python; Anda dapat mengamati bahwa pengumpulan sampah tidak terjadi jika tidak ada python kode dieksekusi, dan menyimpulkan itu mungkin terjadi kadang-kadang ketika mencoba mengalokasikan memori. Dapat 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 monomaniacs bukan bagian dari budaya python.

3
vincent

Saya mendukung python dan kerugian pertama yang muncul di benak saya adalah ketika berkomentar pernyataan seperti if myTest(): maka Anda harus mengubah lekukan dari seluruh blok yang dieksekusi yang Anda tidak inginkan tidak ada hubungannya dengan C atau Java. Faktanya dalam python alih-alih mengomentari if-clause, saya malah 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, membuat komentar pernyataan lebih mudah dengan C dan Java.

3
Niklas
  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 penerjemah 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.
3
dan_waterworth
  • OOP Aneh:
    • len(s) hingga __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 #)
2
deamon

"Kekekalan" bukan titik kuatnya. Angka AFAIK, tupel, dan string tidak dapat diubah, yang lainnya (mis. 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 ketidakbergantungan tidak sama pentingnya. (Ya, Pecinta FP, saya tahu bahwa kekekalan hebat bahkan tanpa konkurensi.))

0
Kosta

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.

0
rbanffy

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

0
a3nm