Apa kelemahan dari Python? [Tutup]


147

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)


50
Saya pikir ini adalah pertanyaan subjektif yang bermanfaat, dan akan memalukan untuk menutupnya.
Eric Wilson

25
Tampaknya ada fanboy python di sini yang hanya menurunkan semua jawaban anti-python.
zvrba

2
@ TMN: Itu masih memperlakukan spasi putih sebagai token, hanya saja tidak mengembalikannya - dan itulah yang dilakukan tata bahasa Python juga.

9
@Roger: konvensi tentang SO adalah untuk mengomentari downvotes. Karena ini adalah situs untuk opini subjektif , saya tidak melihat alasan untuk downvotes, esp. tanpa komentar. Jadi, saya mendukung "panggilan nama" saya.
zvrba

8
@zvrba: Downvotes masih berarti "tidak berguna", seperti biasa.

Jawaban:


109

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.


60
@ Casey, saya harus tidak setuju. Indeksnya mengerikan - coba cari withpernyataan, atau metode pada list. Apa pun yang tercakup dalam tutorial pada dasarnya tidak dapat ditelusuri. Saya lebih beruntung dengan dokumentasi Microsoft untuk C ++.
Mark Ransom

17
Sekitar 5 - cukup gunakan kepingan salju. Ini ditulis untuk menangkap kesalahan-kesalahan itu.
Alexander Solovyov

4
Mengenai kecepatan: dengan munculnya PyPy, banyak pengguna Python sekarang akan dapat menangani masalah kecepatan hanya dengan menggunakan juru bahasa dengan kompiler JIT bawaan (untuk saat ini, pengguna Python 3 dan pengguna modul ekstensi C tidak ditangani oleh cpyext tidak memiliki opsi ini).
ncoghlan

29
Saya membenci dokumen Python. Mereka lebih cantik daripada kebanyakan untuk memastikan, tetapi banyak kali banyak informasi yang berguna disatukan ke dalam satu halaman, seperti metode pada string dan daftar - dan semua jenis urutan disatukan juga. Ketika saya mencari informasi ini, saya hanya mendarat di buku tebal besar, dan harus mencari ke bawah halaman untuk menemukan apa yang saya inginkan. Saya juga menemukan indeks pada halaman-halaman ini sulit dibaca, dan kadang-kadang sulit untuk mengatakan bagian mana yang saya inginkan.
Carson Myers

5
Bagaimana jarak dari logam bisa menjadi argumen? Apakah Python pernah menyatakan dirinya sebagai bahasa sistem?
Mark Canlas

66

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]

6
Saya sangat berharap Python memiliki pernyataan "var". Selain alasan (sangat bagus) Anda menyatakan, itu juga akan membuatnya lebih mudah untuk membaca kode karena Anda hanya dapat memindai halaman untuk melihat semua deklarasi variabel.
jhocking

25
Seolah-olah pengembang python mengabaikan pelajaran masa lalu. Tidak mendeklarasikan variabel, tidak mendeklarasikan fungsi, adalah kesalahan yang pertama kali dibuat pada 1950-an. Mereka yang sulit menemukan bug yang dihasilkan dari kesalahan ketik yang sulit dikenali pertama kali dibuat pada tahun 1950-an. Kesalahan bahasa ini telah dibuat (dan kemudian diperbaiki) berkali-kali. Mendeklarasikan variabel bukanlah beban besar. Ini telah menyelamatkan pantat saya beberapa kali. Saya mau tidak mau use strict;dan use warnings;di perl pada skrip dari berbagai ukuran. Python telah menghapus terlalu banyak pengembang alat bantu debugging.
David Hammen

19
@ David, Agar adil untuk python, itu akan memunculkan pengecualian jika Anda mencoba mengakses variabel yang belum ditugaskan. Banyak bahasa yang tidak memiliki deklarasi akan mengembalikan semacam nilai default. Akibatnya, versi Python jauh lebih tidak bermasalah daripada versi itu.
Winston Ewert

1
@yi_H Proposal itu tidak dimaksudkan untuk kompatibel ke belakang - atau bahkan proposal nyata. Pertanyaannya adalah, "apa kekurangan Python" ... well, tidak memiliki vardan let(atau mekanisme serupa) adalah kelemahan. Dengan kata lain: seandainya saya menjadi perancang Python, saya akan melakukan sesuatu seperti ini. Yang mengatakan , versi masa depan dapat menyertakan ini ketika Anda memuat paket khusus (mirip dengan __future__). Katakan import strict,. Ini tidak akan terjadi, karena ini memerlukan peretasan sintaksis ...
Konrad Rudolph

3
+1 Untuk menambahkan kemampuan pemrograman 'fungsional-seperti' yang lebih baik.
Evan Plaice

44

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 .


2
+1 untuk pylint. Saya tidak menyadarinya. Lain kali saya melakukan proyek dengan Python, saya akan mencobanya. Juga, multithreading tampaknya berfungsi dengan baik jika Anda menggunakan Jython alih-alih implementasi CPython referensi. OTOH Jython sedikit lebih lambat dari CPython, jadi ini sebagian dapat mengalahkan tujuannya.
dsimcha

3
Threading tidak didukung dengan baik? Pustaka threading sudah ada di sana sejak sebelum 2.1.
rox0r

2
Saya tahu ada dukungan threading, tetapi dibandingkan dengan Java atau C, GIL akan benar-benar menurunkan kinerja Anda. Itu sebabnya modul multiprosesing lebih disukai daripada threading.
cmcginty

2
Dokumentasinya bagus jika Anda dapat menemukannya. Kelas Googling Java jauh lebih mudah daripada Python.
Brendan Long

@Casey Saya telah mengklarifikasi kata-kata dalam jawaban, karena threading didukung, hanya menunjukkan beberapa kinerja aneh (menambahkan referensi dan beberapa tautan ke dokumen juga)
dbr

28

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


5
Ini benar, meskipun ada alat seperti PyChecker yang dapat memeriksa kesalahan yang dilakukan oleh kompiler dalam bahasa seperti C / Java.
Oliver Weiler

24
Pengetikan dinamis adalah keputusan desain yang disengaja, bukan kelemahan.
missingfaktor

14
Ini sama dengan mengatakan kelemahan Java adalah kurangnya pengetikan dinamis.
MAK

12
@missingfaktor, @MAK, jelas mengetik bebek adalah fitur yang dimaksudkan. Tetapi sebagian besar keputusan desain memperkenalkan manfaat dan kelemahan obyektif. Fleksibilitas kode yang ditambahkan adalah manfaat dari pengetikan dinamis, dan kelas tambahan dari kesalahan runtime potensial adalah kelemahan. Bagian subjektifnya adalah apakah fitur itu layak atau tidak.
Jacob

6
Kurangnya pengetikan statis memudahkan programmer untuk menulis kode yang memiliki kesalahan runtime. Di C #, int foo = 4; Console.Write(foo.Length);tidak dikompilasi, jadi kesalahan "Int32 tidak memiliki panjang properti" tidak dapat secara tidak sengaja masuk ke perangkat lunak yang diterbitkan. Dalam python, kecuali jika Anda menjalankan alat sekunder opsional untuk mencari kesalahan seperti itu, kode yang mengakses anggota objek yang tidak ada dapat tidak terdeteksi sampai akhirnya menyebabkan kesalahan runtime.
Yakub

27

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.


17
Parameter diri hanya membuat eksplisit apa bahasa lain meninggalkan implisit. Bahasa-bahasa itu jelas memiliki parameter "mandiri".

13
@Roger Pate: Ya, tapi kebutuhan eksplisit untuk "diri" itu agak menyebalkan (dan, saya berpendapat, abstraksi yang bocor). Itu juga tidak muncul sebagai keputusan desain yang disengaja, tetapi karena aturan pelingkupan "aneh" Python. Saya tidak dapat menemukan artikel dengan cepat, tetapi ada posting email dari Guido van Rossum yang menjelaskan dengan baik mengapa parameter "mandiri" diperlukan.
mipadi

2
@Roger Pate: Dalam bahasa berorientasi objek, melewati target sebagai parameter pertama masih dapat dianggap sebagai detail implementasi. Maksud saya, bukan, apakah itu ide yang bagus atau tidak; intinya adalah bahwa dengan Python, ini bukan karena keputusan desain yang disengaja, melainkan untuk mengatasi kutil dalam sistem pelingkupan.
mipadi

3
@mipadi: Pembaruan memiliki alasan yang lebih baik (jadi saya akan menghapus downvote), tetapi jika Anda melihat len ​​sebagai operator yang kelebihan beban, itu lebih banyak OO dalam Python. Senang melihat contoh atau alasan tentang bagaimana Python salah menyampaikan pesan.

8
Eksplisit diri adalah hasil dari kenyataan bahwa metode hanya berfungsi (dan, seperti yang dicatat Winston, deklarasi variabel lokal implisit). Anda bebas untuk tidak menyukai keputusan desain itu, tetapi memanggil OOP "melesat" dalam bahasa di mana semuanya dapat diakses sebagai objek saat runtime adalah konyol.
ncoghlan

19

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

5
Mengenai (2), saya pikir ini diimbangi oleh kemungkinan memiliki fungsi bersarang.
Konrad Rudolph

3
@KonradRudolph Kualitas utama saya dengan fungsi bersarang alih-alih lambda multi-baris adalah urutan pembacaannya ditukar.
CookieOfFortune

2
@wkschwartz: raw_inputdan 'sys.stdin' adalah barebones yang cantik. Mereka tidak mendukung untuk mendapatkan input yang diformat (mis. Sesuatu seperti "% d:% d:% d"% (jam, menit, dtk) untuk dibaca tepat waktu). Sejauh ini Python tidak memiliki sesuatu yang mendekati fungsi scanf (dalam C) atau Scanner (Java).
MAK

2
@limscoder: Semua string unicode secara default di Java. Saya tidak melihat alasan yang baik untuk memiliki kelas str dan unicode yang terpisah. IMHO, string dan array byte tidak boleh diwakili oleh abstraksi yang sama. Kelas string seharusnya untuk menyimpan dan memanipulasi teks - yang representasi internalnya tidak begitu kita pedulikan. Kita seharusnya tidak ingin melakukan hal-hal seperti truncate / replace / delete / insert pada byte tertentu dalam sebuah string - kita ingin melakukan ini pada karakter tertentu . Sangat mudah untuk melupakan perbedaan dan membuat kode Anda meledak ketika diberi input non-Inggris.
MAK

1
@limscoder: jika Anda ingin melihat unicode mudah, coba Tcl. Saya harus beralih dari Tcl ke Python beberapa tahun yang lalu, dan saya terkejut melihat betapa uniknya dukungan unicode python dalam perbandingan. Ini benar-benar tidak terlihat di Tcl, dan rasa sakit yang hebat pada python.
Bryan Oakley

18

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.


Saya melihat banyak keluhan tentang ini, tetapi mengapa orang bersikeras memiliki daftar kosong (yang diubah fungsi) sebagai argumen default? Apakah ini benar-benar masalah besar? Yaitu, apakah ini masalah nyata ?
Martin Vilcans

8
Itu melanggar prinsip paling tidak mengejutkan. Orang tidak akan mengharapkan parameter fungsi untuk bertahan di seluruh panggilan.
aib

Ini konsekuensi dari itu menjadi bahasa scripting. Anda hanya akan bingung oleh bug ini SEKALI, dan tidak pernah lagi. Mengetahui bug ini untuk diri sendiri benar-benar memberi Anda tendangan untuk mengingatkan Anda bahwa ya, ini masih merupakan bahasa scripting. Dan itu hanya karena bahasanya bagus dalam menyembunyikan aspek scripting (dengan asumsi Anda menggunakannya dengan benar).
Zoran Pavlovic

@ZoranPavlovic karena penasaran, mengapa ini konsekuensi dari itu menjadi bahasa scripting? Tampaknya menjadi masalah dengan kapan data diikat dan karena daftar bisa berubah (yang merupakan dua hal yang biasanya baik, tetapi akhirnya menjadi buruk ketika digabungkan bersama-sama). Masalah yang sama bisa terjadi dalam bahasa non-skrip jika Anda mengikat data pada saat pembuatan fungsi daripada membuat daftar baru setiap kali fungsi dipanggil.
jsternberg

@aib: Saya tidak berpikir begitu - parameter di sini, seperti setiap objek Python lainnya - adalah pointer ke objek. Dalam hal ini, objek adalah objek yang dapat berubah, dan variabel terikat ketika fungsi dideklarasikan. Parameter tidak "bertahan di panggilan," tetapi yang bertahan adalah referensi ke objek yang bisa berubah.
Patrick Collins

14

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


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


2
mengenai pelingkupan, mungkin layak bagi yang penasaran untuk melihat python.org/dev/peps/pep-3104 untuk memahami alasan metode saat ini.
Winston Ewert

Setuju dengan +1. Jadi, +1.
Jas

34
Memiliki satu cara untuk melakukannya adalah keuntungan. Ketika Anda membaca kode orang lain, Anda tidak pernah menguraikan pernyataan tunggal. Setelah idiom tertanam di otak Anda, Anda harus memiliki pengenalan instan.
rox0r

9
Sepenuhnya setuju dengan @ rox0r. "Jaket lurus" mencegah segala macam perang sintaksis.
keithjgrant

8
Sejujurnya, saya sangat jarang membutuhkan kata kunci globalatau nonlocaldalam Python. Sangat jarang bahwa saya lupa masalah ini ada dan harus google-ulang itu beberapa kali muncul, meskipun saya menulis kode Python setiap hari di tempat kerja. Bagi saya, kode yang perlu memodifikasi variabel global (atau lebih buruk, variabel non-global luar) adalah bau kode. Biasanya ada (tidak selalu) cara yang lebih baik.
Ben

11

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.


1
ya ... Saya sangat merindukan gaya LINQ (saya yakin LINQ bukan yang pertama mengimplementasikannya, tapi saya paling akrab dengannya) penanganan daftar.
CookieOfFortune

1
Jangan menganggap len (x) sebagai metode. "len" adalah fungsi. Python memiliki fungsi dan metode dan saya tidak melihat ada yang salah dengan pendekatan itu. Kurangnya fungsi yang tepat, biasanya, sumber banyak mengetik yang tidak perlu.
rbanffy

Saya tahu len()adalah fungsi, dan apa kelebihannya. Saya juga menyatakan mengapa saya pikir itu ide yang buruk, mengapa saya pikir fungsi global adalah ide yang sangat buruk, dan mengapa saya pikir metode memberikan metode yang nyaman untuk mengatur dan pelingkupan fungsi Anda =)
Haoyi

Saya tidak berpikir bahwa 42 (atau 43?) Kata kunci adalah angka 'besar'. Itu juga termasuk hal-hal seperti def, classdan panggilan non-fungsi lainnya. Bandingkan dengan 100+ di sebagian besar bahasa populer lainnya. Juga, pertimbangkan garis dari import this: Namespaces are one honking great idea -- let's do more of those!. Saya pikir Anda mungkin salah memahami ruang nama Python;)
Wayne Werner

8

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.


1
withtersedia dari Python 2.5 dengan from __future__ import with_statement, tapi saya setuju, saya kadang-kadang merasa tidak beruntung bahwa pernyataan seperti if/ for/ print/ etc adalah "spesial" dan bukan fungsi biasa
dbr

7

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!


+1 Ini membuat saya bertanya-tanya apakah menulis datetime.datetime.now()ketika satu proyek bisa menulis datetime.nowdan kemudian mencampur dua proyek satu cara penulisan itu mengesampingkan yang lain dan tentunya ini tidak akan terjadi di Jawa yang tidak akan menamai modul sama dengan file (?) Jika Anda melihat bagaimana cara umum tampaknya membuat modul membingungkan kita dengan file ketika kedua penggunaan dipraktikkan dan eksplisit selfsaya masih mencoba memahami karena panggilan tidak memiliki jumlah argumen yang sama dengan fungsi. Dan Anda mungkin berpikir bahwa VM python itu lambat?
Niklas Rosencrantz

Mengenai masalah Anda dengan kata kunci mandiri yang eksplisit. Mungkin saya sarankan menggunakan IDE python yang bagus untuk itu? Saya tahu PyDev di Eclipse secara otomatis melengkapi bagian diri dari tanda tangan fungsi jika mendeteksi Anda menulis di dalam kelas.
Zoran Pavlovic

5

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.


2
Saya setuju dengan Anda hanya jika definisi jatuh tempo Anda tidak kompatibel dengan versi yang tidak sesuai dengan desain .
tshepang

3
Saya setuju bahwa dua aliran python yang tidak kompatibel adalah masalah (meskipun dapat dimengerti mengapa hal itu dilakukan), tetapi saya tidak melihat itu sebagai masalah "kedewasaan".
Winston Ewert

Kedewasaan di satu sisi 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.
Jonathan Cline IEEE

2
Kemudian gunakan saja Python 2.x. Anda tahu ... versi yang digunakan semua orang. Atau baca dokumentasi paket selama 2 detik untuk mencari tahu versi apa yang kompatibel dengannya.
jsternberg

2
"Hanya karena python 3.0 telah dirilis untuk beberapa waktu tidak berarti ini versi yang harus Anda gunakan. Python 3.0 dan 2.x sedang dikembangkan pada saat yang sama. Saya berharap di masa depan kita semua dapat menggunakan python 3.0, tetapi untuk sekarang menggunakan 2.x adalah solusi yang bagus "-> Itu adalah cara 500 karakter untuk mengatakan: Ini belum matang.
Jonathan Cline IEEE

4

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


8
dapatkah kamu memberi contoh (Saya yakin Anda benar, tetapi saya ingin contoh)
Winston Ewert

24
Saya suka Python tetapi saya benar-benar membenci harus meletakkan self.di depan setiap referensi ke properti contoh dan metode. Itu membuat mustahil untuk menggunakan Python untuk membuat DSL seperti itu sangat mudah dilakukan di Ruby.
Adam Crossland

35
Saya tidak menemukan diri yang canggung, saya suka dengan orang yang suka berbicara.
Winston Ewert

9
Saya tidak mengerti apa masalahnya tentang diri eksplisit. Dalam C ++, Java dan D, orang sering membuat variabel anggota eksplisit dengan konvensi, misalnya dengan mengawali mereka dengan garis bawah.
dsimcha

7
Anda menggunakan self dalam metode yang berbeda dari deklarasi mereka: def foo (self) tetapi self.foo (). Saya menemukan campuran definisi eksplisit ini tetapi hal-hal di balik layar implisit tidak terlalu cantik.
LennyProgrammers

4

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

Mengapa downvote?
missingfaktor

Saya bukan downvoter, tapi bisakah Anda menjelaskan mengapa Anda pikir OO dibaut? Python selalu memiliki OO, itu adalah bagian inti dari bahasa.
Daenyth

Lihat jawaban @ mipadi.
missingfaktor


4

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 .


Jadi kurangnya kontrol akses itu buruk ... tetapi pelingkupan eksplisit dari penulisan variabel ke namespace non-lokal juga buruk?
ncoghlan

@ncoghlan: 1 - fitur itu standar dalam banyak bahasa modern, tergantung pada bagaimana Anda mengkonfigurasi proyek Anda. 2 -Ini di bawah kendali programmer. 3 - tidak yakin apa yang hebat tentang itu - Anda dapat dengan mudah mengontrol ruang lingkup Anda dengan beberapa pengaturan proyek dalam sebagian besar bahasa yang dikompilasi / IDE. Jika 'kita semua menyetujui orang dewasa', kita harus dapat membuat keputusan sendiri dan menyesuaikan ruang lingkup sesuai dengan tingkat kenyamanan khusus kita.
Vektor

2
Masalahnya adalah orang-orang yang meminta "kontrol akses yang dipaksakan" meminta kami untuk mengambil salah satu dari hal-hal yang membuat Python menjadi bahasa lem yang hebat: memang sulit bagi pengembang untuk mengontrol bagaimana kode mereka nantinya digunakan. Seberapa banyak pelat ketel dalam pola C ++ dan Java yang hanya bekerja di sekitar kontrol akses yang dipaksakan? Saya pasti dapat memahami orang-orang yang memilih untuk tidak menggunakan Python karena alasan itu, tetapi penerapan statis tidak akan pernah menjadi pengganti untuk pengujian yang ketat.
ncoghlan

1
@ncoghlan - bagi saya hal-hal hebat tentang Python adalah keanggunan sintaksis dan kesempurnaan - ekspresif. Dan seperti yang saya katakan, pelingkupan kurang berkaitan dengan programer yang mengacaukan hal-hal yang seharusnya tidak mereka lakukan dengan struktur kode dan organisasi - jadi konsep 'menyetujui orang dewasa' diperdebatkan. Saya bekerja pada proyek yang kompleks, bukan utilitas dan skrip sederhana - kode harus dimodulasi dan terstruktur dengan cermat - pengubah akses adalah salah satu cara terpenting untuk memastikan hal itu.
Vektor

1
Dan review kode, pelatihan dan analisis penggandaan adalah yang lain. Bagi saya, kontrol akses yang dipaksakan jatuh ke dalam ember yang sama dengan pengetikan statis: mereka memang membantu dalam memberikan beberapa kepercayaan tambahan dalam kebenaran (tetapi tidak cukup untuk menghindari kebutuhan untuk pengujian ekstensif), tetapi dengan biaya tinggi dalam produktivitas pengembangan. (Pada tingkat praktis, kontrol akses atribut kelas juga tidak cocok dengan model objek Python di mana metode hanyalah fungsi biasa yang diambil dari kelas. Batas "dalam / luar" untuk kelas tidak benar-benar ada, sehingga tidak bisa dipaksakan)
ncoghlan

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

Apa yang mengilhami untuk menyebutkan kelebihannya? Pertanyaan untuk masalahnya. Ngomong-ngomong, apa maksudmu itu hanya berguna untuk pemrograman aplikasi? Pemrograman apa lagi yang ada? Khususnya apa yang tidak baik untuk itu?
tshepang

5
Saya mendaftar keuntungan karena saya pikir mereka lebih besar daripada yang kontra. Pernahkah Anda mencoba mengimplementasikan modul kernel linux dengan python.
dan_waterworth

3

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.


1
Anda serius mengedit kode C atau Java untuk mengubah level blok beberapa kode tanpa mengubah lekukannya?
Ben

4
@Ben Untuk sementara, ya ...
alternatif

1
@ben sama di sini.
Christopher Mahan

2
Saya menggunakan trik mengubah if something()ke if False and something(). Trik lain adalah "berkomentar" menggunakan string multi-line.
Martin Vilcans

1
@ Martin Tentu Saja! if False ...
Christopher Mahan

3

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.


Wow, sepertinya sangat teknis, apakah Anda memiliki bahan referensi, contoh, posting blog atau artikel tentang masalah ini? Saya bertanya-tanya apakah saya akan terkena kasus-kasus seperti itu dalam waktu dekat.
vincent

Aron memberi ceramah di SciPy 2012 . The dlopenbarang-barang di kami collfs perpustakaan. Repositori itu juga berisi trik zipimport tambahan yang terinspirasi oleh caching path Asher Langton. Kami sedang mengerjakan distribusi dan kertas yang lebih baik.
Jed

3
  • 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.


+1. Spec untuk memori dan model threading sudah tepat. Tetapi FWIW, pengumpul sampah Jawa yang berada di utas (dan kebanyakan hal lain tentang GC) bukan merupakan aspek dari bahasa Java atau spesifikasi VM per se, tetapi merupakan masalah implementasi JVM tertentu. Namun, Sun / Oracle JVM utama didokumentasikan secara luas mengenai perilaku dan konfigurasi GC, sejauh ada banyak buku yang diterbitkan pada tuning JVM. Secara teori, seseorang dapat mendokumentasikan CPython dengan cara yang sama, terlepas dari spesifikasi bahasa.
Andrew Janke

2
  • 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 #)

5
Secara pribadi saya berpikir bahwa ketidakcocokan antara 2.x dan 3.x adalah salah satu keuntungan terbesar Python. Tentu, itu juga merugikan. Tetapi keberanian pengembang untuk memundurkan kompatibilitas juga berarti bahwa mereka tidak harus membawa cambuk tanpa henti. Lebih banyak bahasa membutuhkan perbaikan seperti itu.
Konrad Rudolph

0

"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.))


0

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.


// spawn bunch of threads // pass queue que ke semua thread que.extend ([x untuk x in lots_of_sx]) que.wait () # Tunggu semua lots_of_sx diproses oleh utas.
Zoran Pavlovic

0

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

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.