Python'un sakıncaları nelerdir? [kapalı]

Python bugünlerde tüm öfke gibi gözüküyor ve haksız yere değil - çünkü gerçekten çözülmesi gereken yeni bir soruna sahip olmak gerçekten hoş bir dil. Ancak, bilge bir adamın bir zamanlar söylediği gibi (ona bilge bir adam diyerek, sadece kimin söylediğini bilmiyordum; o kadar akıllı olup olmadığından emin değilim), bir dili gerçekten tanımak sözdizimi, tasarım vb. avantajlar, aynı zamanda sakıncaları. Hiçbir dil mükemmel değildir, bazıları diğerlerinden daha iyidir.

Öyleyse, sizce ne olacak, Python'un nesnel sakıncaları.

Not: Burada bir dil karşılaştırması istemiyorum (yani C #, Python'dan daha iyidir çünkü ... yadda yadda yadda) - daha fazla hangi dil özelliklerinin kötü bir şekilde tasarlandığına dair bir objektif (bir seviyeye kadar) fikrinden daha fazlası bazılarınız içinde bu konuda eksiksiniz. Karşılaştırma için başka bir dil kullanması gerekiyorsa, ancak yalnızca aksi takdirde detaylandırılması zor olan bir noktayı göstermek için (yani anlama kolaylığı için)

Python'u düzenli olarak biraz kullanıyorum ve genel olarak çok iyi bir dil olduğunu düşünüyorum. Bununla birlikte, hiçbir dil mükemmel değildir. Şahsen benim için önem sırasına göre sakıncaları:

1. Yavaş. Gerçekten çok yavaş demek istiyorum. Çoğu zaman bu önemli değil, ama kesinlikle performans açısından kritik olan bu bitler için başka bir dile ihtiyacınız olacak.

2. İç içe geçmiş işlevler, dış kapsamdaki değişkenleri değiştiremeyeceğiniz için emilir. Düzenleme: Kütüphane desteği nedeniyle hala Python 2 kullanıyorum ve bu tasarım kusuru beni rahatsız ediyor, ancak görünüşe göre Python 3'te yerel olmayan bir açıklama nedeniyle düzeltildi . Kullandığım liblerin taşınmasını bekleyemem, böylece bu kusur tarihin kül yığınına gönderilebilir.

3. Kütüphane / jenerik kod için faydalı olabilecek bazı özellikler eksik ve IMHO sağlıksız uç noktalara giden basitlik. Düşünebileceğim en önemlisi, kullanıcı tanımlı değer türleri (bunların metaclass magic ile oluşturulabileceğini tahmin ediyorum, ancak hiç denemedim) ve ref function parametresidir.

4. Metalden uzak. Diş açma ilkellerini veya çekirdek kodunu yazmanız mı gerekiyor? İyi şanslar.

5. Python'un sunduğu dinamizm için bir tradeoff olarak anlamsal hataları yakalama kabiliyetine aldırış etmemekle birlikte, kodu gerçekten çalıştırmak zorunda kalmadan sözdizimsel hataları ve saçma sapan değişkenler gibi aptalca şeyleri yakalamanın bir yolu olmasını diliyorum.

6. Belgelendirme, güçlü kurumsal destekleri olan PHP ve Java gibi diller kadar iyi değildir.

Python'un bildirimi ve bir değişkenin kullanımı arasında ayrım yapamamasından nefret ediyorum. Bunun gerçekleşmesi için statik yazmaya gerek yoktur. “Bu kasıtlı olarak beyan ettiğim bir değişken ve yeni bir isim vermek niyetindeyim , bu bir yazım hatası değil ” demenin bir yolu olabilir .

Ayrıca, Python değişkenlerini genellikle bir kez yazma stilinde kullanırım, yani değişkenleri değişmez olarak görürüm ve bunları ilk görevlendirmelerinden sonra değiştirmem. Liste anlama gibi özellikler sayesinde, bu gerçekten inanılmaz derecede kolaydır ve kod akışının takip edilmesini daha kolay hale getirir.

Ancak bu gerçeği belgeleyemiyorum. Python'da hiçbir şey, üzerine yazma veya değişkenleri yeniden kullanma biçimimi engellemiyor.

Özetle, dilde iki anahtar kelimeye sahip olmak istiyorum: varve let. Bunlardan herhangi biri tarafından bildirilmeyen bir değişkene yazarsam, Python bir hataya neden olmalıdır. Ayrıca, letdeğişkenler salt okunurken, vardeğişkenler “normal” olarak bildirilir.

Bu örneği düşünün:

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

Türlerin hala örtük olduğuna dikkat edin (ancak letdeğişkenler varhala dinamik bir şekilde yazılabilirken değişkenler yeni bir değere geri döndürülemeyeceklerinden statik olarak yazılmış tüm amaçlar ve amaçlar içindir ).

Son olarak, tüm yöntem argümanları otomatik olarak let, yani salt okunur olmalıdır. Genelde, aşağıdaki deyim dışında bir parametreyi değiştirmek için iyi bir neden yoktur:

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

Bu biraz farklı bir deyim ile değiştirilebilir:

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

Asıl şikayetim, küresel tercüman kilidi (birçok "Python GIL'in İçi" konuşması).

Bununla birlikte, kullanımı çok kolay olan çok işlemli bir arayüz vardır, ancak aynı sayıda işlem ve iş parçacığı için bellek kullanımında daha ağır olacak veya çok fazla paylaşılan veriniz varsa zor olacaktır. Bununla birlikte, bunun yararı, birden fazla işlemle çalışan bir programınız olduğunda, birden çok makineye ölçeklenebilir, iş parçacıklı bir programın yapamayacağı bir şeydir.

Belgelerin eleştirisine gerçekten katılmıyorum, orada tüm ana dilleri olmasa da mükemmel ve daha iyi olduğunu düşünüyorum.

Ayrıca pylint çalıştıran çalışma zamanı hatalarının çoğunu yakalayabilirsiniz .

Muhtemelen , belli çalışma zamanı hataları sınıflarını ortaya çıkarabilen statik yazım eksikliği, ördek yazmanın sağladığı esnekliğe değmez.

Python'un nesne yönelimli kısımlarının bir çeşit "cıvatalanmış" olduğunu düşünüyorum. Açıkça açıkça her bir yönteme “kendini” geçirme ihtiyacı, OOP bileşeninin açıkça planlanmadığını belirten bir semptom ; Aynı zamanda Python'un başka bir cevapta eleştirilen bazen de sinsi kapsam belirleme kurallarını gösterir.

Düzenle:

Python'un nesne yönelimli kısımlarının "cıvatalanmış" olduğunu söylerken, OOP tarafının zaman zaman tutarsız hissettiğini kastediyorum. Örneğin, Ruby'yi alın: Ruby'de her şey bir nesnedir ve tanıdık obj.methodsözdizimini kullanarak (elbette aşırı yüklenmiş operatörler hariç) bir yöntem çağırırsınız ; Python'da her şey bir nesnedir, fakat bir işlev olarak çağırdığınız bazı yöntemler; yani, __len__bir uzunluk döndürmek için aşırı yüklüyorsunuz, ancak diğer dillerde len(obj)daha bilinen (ve tutarlı) yerine, onu kullanarak arayın obj.length. Bu tasarım kararının arkasında sebepler olduğunu biliyorum ama onlardan hoşlanmıyorum.

Ayrıca, Python'un OOP modeli her türlü veri korumasından yoksundur, yani özel, korumalı ve herkese açık üyeler yoktur; Onları kullanarak _ve __yöntemlerin önünde taklit edebilirsiniz , ama biraz çirkin. Benzer şekilde, Python da OOP’un mesaj gönderme yönünü tam olarak anlamadı.

Python hakkında sevmediğim şeyler:

1. Threading (Daha önce de bahsedildiğini biliyorum, ancak her yazıda bahsetmeye değer).
2. Çok satırlı adsız işlevler için destek yok ( lambdayalnızca bir ifade içerebilir).
3. (Gibi basit ama güçlü giriş okuma fonksiyonu / sınıfın olmaması cinveya scanfC ++ ve C veya ScannerJava).
4. Tüm dizeler varsayılan olarak unicode değildir (ancak Python 3'te sabitlenmiştir).

Değişken veri türleriyle varsayılan argümanlar.

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

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

Genellikle bazı ince böceklerin sonucudur. Varsayılan bir argüman gerektiğinde (her işlev çağrısı için kullanılacak tek bir nesne oluşturmak yerine) yeni bir liste nesnesi oluşturması daha iyi olacağını düşünüyorum.

Düzenleme: Çok büyük bir sorun değil, ancak bir şey belgelerde belirtilmesi gerektiğinde, bu genellikle bir sorun olduğu anlamına gelir. Bu gerekli olmamalı.

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

Özellikle de bunun varsayılan olması gerektiğinde. Beklediğinizle eşleşmeyen ve çok sayıda koşul için kullanışlı olmayan garip bir davranış.

Python'un bir geliştirme dili kadar esnek kılan özelliklerinden bazıları, C ++ ve Java gibi dillerde derleme ve bağlantı işlemi tarafından yürütülen "tüm program" statik analizinde kullanılanların büyük dezavantajları olarak da görülüyor.

• Yerel değişkenlerin örtük beyanı

Yerel değişkenler normal atama bildirimi kullanılarak bildirilir. Bu, başka herhangi bir kapsamdaki değişken bağlamaların, derleyici tarafından alınacak açık ek açıklamalar gerektirdiği anlamına gelir (dış kapsamlar için genel ve yerel olmayan bildirimler, örneğin kapsamlar için erişim erişimi gösterimi). Bu, programlama sırasında ihtiyaç duyulan kazan plakası miktarını büyük ölçüde azaltır, ancak derleyicinin açık değişken bildirimleri gerektiren dillerde işlenen kontrolleri yapmak için üçüncü taraf statik analiz araçlarına (pyflakes gibi) ihtiyaç duyulduğu anlamına gelir.

• "Maymun yama" desteklenir

Modüllerin içeriği, sınıf nesneleri ve hatta yerleşik ad alanı çalışma zamanında değiştirilebilir. Bu oldukça güçlüdür ve birçok yararlı tekniğe izin verir. Ancak, bu esneklik Python'un statik olarak yazılmış OO dilleri için ortak bazı özellikler sunmadığı anlamına gelir. En önemlisi, örnek metotlara "self" parametresi dolaylı olmaktan ziyade açıktır ("metotlar" bir sınıf içinde tanımlanması gerekmediğinden, sınıf değiştirilerek daha sonra eklenebilir, yani özellikle pratik değildir. Örnek referansını dolaylı olarak iletmek için) ve nitelik erişim kontrolleri, kodun sınıfın "içinde" veya "dışında" olup olmadığına (kolayca sınıf tanımı yürütülürken var olduğu için) dayalı olarak uygulanamaz.

• Metalden uzak

Bu, diğer birçok yüksek seviye dil için de geçerlidir, ancak Python çoğu donanım detayını soyutlama eğilimindedir. C ve C ++ gibi sistem programlama dilleri, doğrudan donanım erişimini ele almak için hala çok daha uygundur (ancak, Python, CPython eklenti modülleri veya daha kolay bir şekilde ctypeskütüphane yoluyla olanlarla oldukça mutlu bir şekilde konuşacaktır ).

1. Her ne olursa olsun, {} / begin-end yerine kod blokları için girinti kullanmak.
2. Her yeni modern dilin kendine özgü bir kapsamı vardır, ancak Python'u yoktur (aşağıya bakınız).
3. Kaotik dokümanlar (mükemmel olan Perl5 belgeleriyle karşılaştırın).
4. Boğaz-ceket (bunu yapmanın tek bir yolu var).

Kırık kapsam için örnek; tercüman oturumundan konuşma metni:

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

globalve nonlocalbu tasarım aptallığını düzeltmek için anahtar kelimeler tanıtıldı.

Python'un nesne yönelimli this.method()ve yordamsal / işlevsel method(this)sözdizimi kombinasyonunu çok rahatsız edici buluyorum :

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

Bu özellikle kötüdür, çünkü çok sayıda işlev (yöntemlerden ziyade) yalnızca küresel ad alanına dökülür : listeler, dizeler, sayılar, yapıcılar, metaprogramlama, hepsi alfabetik olarak sıralanmış büyük bir listede karıştırılmıştır.

En azından, F # gibi işlevsel diller, tüm işlevlerin modüllerde düzgün bir şekilde adlandırılmış:

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

Yani hepsi birlikte değil. Ayrıca, bu kütüphane boyunca takip edilen bir standarttır, bu yüzden en azından tutarlı.

İşlev vs yöntem şeyini yapmanın nedenlerini anlıyorum ama hala bunları bu şekilde karıştırmanın kötü bir fikir olduğunu düşünüyorum. En azından ortak işlemler için yöntem sözdizimini izlerseniz çok daha mutlu olurum:

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

Yöntemlerin değişip değişmediği, nesnede yöntem olarak kullanılmasının çeşitli avantajları vardır:

• Veri türündeki "genel" işlemleri aramak için tek yer: diğer kütüphaneler / etc. veri türlerine yapabilecekleri başka süslü şeyler de olabilir, ancak "varsayılan" işlemlerin tümü nesnenin yöntemlerindedir.
• ModuleArarken tekrarlamaya gerek yok Module.method(x). Yukarıdaki işlevsel Liste örneğini alırsak, neden sürekli tekrar tekrar söylemem Listgerekiyor? Bunun bir olduğunu bilmeli Listve Navigation.map()üzerinde bu fonksiyonu çağırmak istemiyorum ! x.map()Sözdizimini kullanmak onu KURU ve tutarsız tutar.

Ve elbette , bunu yapmanın herşeyi küresel isim alanına yerleştirme yöntemine göre avantajları var. Şu anki yolun işleri halledemediği bir şey değil. len(lst)Hiçbir şey isim alanı olmadığından, oldukça hoş ( ) bile var ! İşlevleri (varsayılan davranış vb.) Yöntemlerde kullanmanın avantajlarını biliyorum, ancak yine de hoşuma gitmiyor.

Sadece dağınık. Ve büyük projelerde, dağınıklık en büyük düşmanınızdır.

Homoconicity eksikliği .

Python, "with" anahtar kelimesini eklemek için 3.x beklemek zorunda kaldı. Herhangi bir homoikonik dilde, önemsizce bir kütüphaneye eklenmiş olabilir.

Cevaplarında gördüğüm diğer birçok konu 3 tipten biri:

1) Takımla sabitlenebilecek şeyler (örn. Pyflakes) 2) Uygulama detayları (GIL, performans) 3) Kodlama standartlarıyla sabitlenebilecek şeyler (örn. İnsanların orada olmasını istemeyen özellikler)

# 2 dil ile ilgili bir sorun değil, IMO # 1 ve # 3 ciddi bir sorun değil.

Python, çok etkileyici olduğu için en sevdiğim dildir, ancak yine de sizi çok fazla hata yapmaktan alıkoyuyor. Hala beni rahatsız eden birkaç şey var:

• Gerçek anonim işlev yok. Lambda, tek ifadeli işlevler için kullanılabilir ve withifade, Ruby'de bir kod bloğu kullanacağınız birçok şey için kullanılabilir. Ancak bazı durumlarda, işleri olması gerekenden biraz daha sakar yapar. (Java’da olduğu kadar sakar olmaktan uzak, ama yine de ...)

• Modüller ve dosyalar arasındaki ilişkide bazı karışıklıklar. Komut satırından "python foo.py" çalıştırmak "import foo" dan farklıdır. Python 2.x içindeki göreceli ithalat da sorunlara neden olabilir. Yine de Python'un modülleri, C, C ++ ve Ruby'nin ilgili özelliklerinden çok daha iyidir.

• Açık self. Bunun nedenlerinden bazılarını anladığım halde, her gün Python kullanmama rağmen, onu unutma hatası yapma eğilimindeyim. Bununla ilgili bir başka sorun da, bir sınıfı bir sınıftan çıkarmak için biraz can sıkıcı hale gelmesidir. Açık kişisel, başkalarının şikayet ettiği sınırlı kapsamla ilgilidir. Python'daki en küçük kapsam, fonksiyon kapsamıdır. İşlevlerinizi gerektiği gibi küçük tutarsanız, bu başlı başına bir sorun değildir ve IMO genellikle daha temiz kodlar verir.

• lenBir yöntem olmayı beklediğiniz gibi bazı küresel işlevler (gerçekte perde arkasında olduğu gibi).

• Önemli girinti. Düşüncenin kendisi değil, bence harika, ama bu kadar çok insanı Python'u denemekten alıkoyan tek şey olduğundan, belki de Python bazı (isteğe bağlı) başlangıç ​​/ bitiş sembolleriyle daha iyi olurdu. Bu insanları görmezden geldiğimde, çentik için de zorunlu bir büyüklükte yaşayabilirim.

• Bunun, JavaScript yerine, web tarayıcılarının yerleşik dili olmadığıdır.

Bu şikayetler arasında, dile ilk eklediğim, dile eklenmesi gerektiğini düşünüyorum. Diğerleri, sonuncusu hariç, oldukça küçüktür, eğer gerçekleşirse harika olurdu!

Python tam olarak olgun değildir: şu anda python 3.2 dili şu anda dağıtılan paketlerin çoğuyla uyumluluk sorunları yaşamaktadır (genellikle python 2.5 ile uyumludur). Bu, şu anda daha fazla geliştirme çabası gerektiren büyük bir dezavantajdır (gereken paketi bulun; uyumluluğu doğrulayın; daha uyumlu olabilecek iyi olmayan bir paket seçmeyi tartın; en iyi sürümü alın, günler alabilecek 3.2'ye güncelleyin; yararlı bir şey yapmaya başla).

Muhtemelen 2012'nin ortalarında bu bir dezavantajı daha az olacaktır.

Sanırım bir hayran çocuk tarafından reddedildi. Bir geliştirici tartışması sırasında, üst düzey geliştirici ekibimiz aynı sonuca vardı.

Bir ana anlamda vade, bir ekibin teknolojiyi kullanabileceği ve gizli riskler olmadan (uyumluluk sorunları dahil) çok hızlı bir şekilde çalışmaya ve koşmaya başlayabileceği anlamına gelir. 3. parti python paketleri ve birçok uygulama, bugün paketlerin çoğunluğu için 3.2'nin altında çalışmaz. Bu, eldeki sorunu çözmek yerine teknolojinin kendisini yeniden uygulayarak daha fazla entegrasyon, test çalışmaları, == daha az olgun teknoloji yaratır.

Haziran 2013 Güncellemesi: Python 3'ün hala vade sorunları var. Sık sık bir ekip üyesi gereken bir paketten bahseder ve sonra "sadece 2.6 dışındadır" deyin (bu durumlarda bazı durumlarda 2.6 ile yalnızca 2.6 olan paketi kullanmak için localhost soketi aracılığıyla bir geçici çözüm uyguladım. araçlarımız 3.2. Python 3'te saf piton wiki MoinMoin bile yazılmaz.

Python'un kapsamı çok bozuk; Python'da nesne yönelimli programlama çok garip.

Python ile ilgili düşüncelerim:

• Civatalı OOP (Bu konuda ayrıntılı bilgi için @ mipadi'nin cevabına bakınız)
• Lambdaların kırık uygulaması
• Kapsam sorunları
• Standart kütüphanede kalıcı koleksiyon yok
• Katıştırılmış DSL'lerde zayıf özellik

Python'daki erişim değiştiricileri zorunlu değildir - iyi yapılandırılmış, modüler kod yazmayı zorlaştırır.

Sanırım bu @ Mason'un kırılmış kapsamının bir parçası - genel olarak bu dilde büyük bir sorun. Okunması gereken kod için, kapsamın içinde neyin olabileceğini ve olması gerektiğini ve herhangi bir zamanda bir değerin ne olacağını anlamak oldukça zor görünüyor - Şu anda bu dezavantajlar nedeniyle Python dilinden geçmeyi düşünüyorum .

Sırf "hepimiz yetişkinlere izin veriyoruz" demek, hatalar yapmadığımız ve güçlü bir yapı içinde daha iyi çalışmadığımız anlamına gelmez, özellikle karmaşık projeler üzerinde çalışırken - girinti ve anlamsız alt çizgi yeterli görünmüyor .

1. Performans iyi değil ama pypy ile gelişti
2. GIL, kodu hızlandırmak için iş parçacığı kullanımını engeller (bu genellikle erken bir optimizasyon olmasına rağmen),
3. Yalnızca uygulama programlaması için kullanışlıdır,

Ancak bazı harika kullanım özelliklerine sahiptir:

1. RAD için mükemmel
2. C ile arabirim kurmak kolaydır (ve C için bir python yorumlayıcısı yerleştirmek için),
3. Çok okunabilir
4. Öğrenmesi kolay,
5. İyi belgelenmiştir,
6. Piller gerçekten dahil edilmiş, standart kütüphanesi çok büyük ve pypi hemen hemen her şey için modüller içeriyor
7. Sağlıklı bir topluma sahiptir.

Python'u tercih ediyorum ve aklıma gelen ilk dezavantaj, o zamanki gibi bir ifadeyi yorumladığınızda if myTest():, C veya Java ile yapmak zorunda kalmayacağınız tüm yürütülen bloğun girintisini değiştirmeniz gerekiyor. Aslında python'da if-cümlesi yerine yorum yapmak yerine bu şekilde yorum yapmaya başladım: `eğer True: #myTest () bu yüzden aşağıdaki kod bloğunu da değiştirmek zorunda kalmayacağım. Java ve C girintiliğe güvenmediğinden, C ve Java ile ifadeleri yorumlamayı kolaylaştırır.

Çoklu gönderim, kurulan tek gönderim tipi sistemle iyi bir şekilde bütünleşmiyor ve çok iyi performans göstermiyor.

Dinamik yükleme, POSIX benzeri anlambilimin meta veri yoğun işlemler için yıkıcı yavaşlamalara neden olduğu paralel dosya sistemlerinde büyük bir sorundur. Çeyrek milyon çekirdek saatini harcayan meslektaşlarım sadece Python'u (numpy, mpi4py, petsc4py ve diğer eklenti modülleriyle birlikte) 65k çekirdeğe yükledi. (Simülasyon önemli yeni bir bilim sonuçları verdi, bu yüzden buna değdi, ama Python'u bir kez yüklemek için bir varilden daha fazla petrolün yakılması bir problemdi.) Statik olarak bağlanamama bizi zorlu çarpıtmaya girmeye zorladı dlopenToplu dosya sistemi erişimini sağlamak için libc-rtld düzeltme ekini de dahil olmak üzere ölçekte makul yükleme süreleri .

• oldukça yaygın kullanılan 3. parti kütüphanelerden ve yazılımlardan oluşan bir grup oldukça pitonik değildir. Birkaç örnek: soaplib, openerp, reportlab. Eleştiri kapsam dışıdır, oradadır, yaygın olarak kullanılır, ancak piton kültürünü kafa karıştırıcı kılar (“Bir tane olmalı — ve tercihen sadece bir - bunu yapmanın açık bir yolu” yazan sloganı incitir). Bilinen pitonik başarılar (örneğin django veya trac) istisna gibi görünüyor.
• potansiyel olarak sınırsız soyutlama derinliği örneği, sınıf, metaclass kavramsal olarak güzel ve benzersiz. Ancak, ustalaşmak için tercümanı derinden tanımanız gerekir (hangi sırada python kodunun yorumlandığı vs.). Yaygın olarak bilinmez ve kullanılmaz (ya da doğru kullanılırsa), C # generics gibi benzer kara büyü, kavramsal olarak daha karmaşıktır (IMHO) orantılı olarak daha yaygın olarak bilinir ve kullanılır.
• bellek ve iş parçacığı modelini iyi anlamak için, python konusunda oldukça deneyimli olmalısınız, çünkü kapsamlı bir özellik yok. Sadece neyin işe yaradığını biliyorsunuzdur, belki tercümanın kaynaklarını veya deneyimli tuhaflıkları okuduğunuz ve nasıl düzelteceğinizi keşfettiğiniz için. Örneğin, java'nın yumuşak ve hayali referansları değil, yalnızca güçlü veya zayıf referanslar vardır. Java'nın çöp toplama işlemi için bir iş parçacığı varken, çöp toplamanın pythonda ne zaman gerçekleştiğine ilişkin resmi bir cevap yoktur; Eğer hiçbir python kodu çalıştırılmazsa, çöp toplama işleminin gerçekleşmeyeceğini gözlemleyebilir ve muhtemelen bellek ayırmaya çalışırken bazen bunun gerçekleştiğine karar verebilirsiniz. Kilitlenmiş bir kaynağın neden serbest bırakılmadığını bilmediğinizde zor olabilir (bu konudaki deneyimim freeswitch'teki mod_python idi).

Her neyse, python 4 yıldır ana dilim. Düşkün olmak, seçkinler veya monomanyaklar piton kültürünün bir parçası değil.

• Garip OOP:
  • len(s)yoluyla __len__(self)ve diğer "özel yöntemler"
  • Diğer özel yöntemlerle elde edilebilecek çok özel bir yöntem ( __add__ve __iadd__için +ve +=)
  • self ilk yöntem parametresi olarak
  • temel sınıf kurucusunu aramayı unutabilirsiniz
  • erişim değiştiricileri yok (özel, korumalı ...)
• sabit tanım yok
• Özel tipler için değişkenlik yok
• GIL
• Python ve C'nin bir karışımına yol açan ve yapımlarla ilgili sorunlara neden olan düşük performans (C kütüphaneleri, platform bağımlılıkları aranıyor ...)
• özellikle üçüncü şahıs kütüphanelerinde kötü dokümantasyon
• Python 2.x ve 3.x arasındaki uyumsuzluk
• zayıf kod analiz araçları (Java veya C # gibi statik olarak yazılmış diller için sunulanlarla karşılaştırıldığında)

“Taklit edilebilirlik” tam olarak güçlü bir nokta değil. AFAIK sayıları, harfleri ve karakterleri değişmez, diğer her şey (yani nesneler) değişkendir. Bunu, her şeyin değişmez olduğu Erlang veya Haskell gibi işlevsel dillerle karşılaştırın (varsayılan olarak, en azından).

Bununla birlikte, dokunulmazlık gerçekten de Python'un güçlü noktası olmayan eşzamanlılık * ile parlıyor, bu yüzden en azından sonuçta ortaya çıkıyor.

(* = Nitpickers için: En azından kısmen paralel olan eşzamanlılığı kastediyorum. Python'un değişmezliğin o kadar önemli olmadığı "tek iş parçacıklı" eşzamanlılıkla tamam olduğunu düşünüyorum. eşzamanlılık olmadan bile harika.))

Açıkça paralel yapılara sahip olmayı çok isterdim. Sık sık, çoğu gibi bir liste anlayışı yazarken

[ f(x) for x in lots_of_sx ]

Elemanların işleneceği sırayı umursamıyorum. Bazen, hangi sırayla iade edildiklerini bile umursamıyorum.

Fp saf Python iken CPython bunu iyi yapmasa bile, bunun gibi diğer uygulamaların kullanması için davranışlar tanımlanabilir.

Python'un çoğunlukla felsefi sebeplerden dolayı kuyruk çağrısı optimizasyonu yoktur . Bu, büyük yapılardaki kuyruk özyinelemesinin O (n) belleğe mal olabileceği anlamına gelir (tutulan gereksiz yığın nedeniyle) ve özyinelemeyi O (1) belleği elde etmek için bir döngü olarak yeniden yazmanızı gerektirir.