Tek Bir ChatGPT Hatası 15 Milyon Wondan Fazla Gelir Kaybına Yol Açtı

(asim.bearblog.dev)

1 puan yazan GN⁺ 2024-06-10 | 2 yorum | WhatsApp'ta paylaş

Para kazanmayı yeni açan bir startup, abonelik ödemelerinde bir arıza yaşadı; ancak sorun içeride yeniden üretilemediği için 5 gün boyunca nedenin bulunması gecikti
Arıza, ChatGPT’nin ürettiği Prisma/TypeScript→Python/SQLAlchemy dönüşüm biçiminin kopyalanmasıyla başladı: UUID üretme fonksiyonu yerine varsayılan değer gibi sabit kodlanmış bir ID dizesi eklenmişti
AWS ECS üzerinde 8 task ve her birinde 5 instance yapısı nedeniyle kullanıcılar en fazla 40 benzersiz ID havuzundan biriyle karşılaşıyordu; gündüzleri sık dağıtımlar sorunu gizliyordu
Gece dağıtımlar durunca her sunucunun tek ID’si tükendi ve sonrasında yeni abonelik denemeleri unique ID çakışması nedeniyle başarısız oldu
Günde 50 şikâyet, 5 gün ve aylık 40 $ abonelik ücreti baz alındığında kaybın aylık 10.000 $ olduğu tahmin ediliyor; test, loglama ve uyarı eksikliği ile kod kopyalama, arızaya müdahaleyi büyüttü

Para Kazanma Açılır Açılmaz Ortaya Çıkan Abonelik Arızası

Startup, Mayıs ayında ilk kez para kazanmayı açtı ve lansmandan sonraki 1 saat içinde ilk müşterisini kazandı
Ertesi sabah Gmail’de 40’tan fazla kullanıcı şikâyeti birikmişti
- Kullanıcılar aboneliği tamamlayamıyordu
- Abonelik düğmesine basınca sonsuz yükleme spinner’ı göründüğünü bildiriyorlardı
Yeni bir hesap oluşturup kendileri kontrol ettiler, ancak içeride abonelik normal çalıştığı için nedeni yeniden üretemediler
Mesai saatlerinde neredeyse hiç şikâyet yoktu; arıza çoğunlukla gece boyunca birikiyordu

Zaman Baskısı Altında Para Kazanma Uygulaması

Mayıs, YC S23 batch’inin başladığı dönemdi ve ekip, lansmandan sonra hangi yönün en doğru olduğundan emin değildi
YC group partner’ı Dalton, yön belirlemek için ücretli aboneleri metrik olarak kullanmalarını ve düşündükleri aylık fiyatı iki katına çıkarmalarını önerdi
Nihai fiyat aylık 40 $ olarak belirlendi
Proje başlangıçta full-stack NextJS idi; ancak para kazanma çalışmasının öncesi ve sonrasında Python/FastAPI’ye geçiş yürütüldü
- Geçiş sürecinde ChatGPT’den yararlanıldı
- Stripe entegrasyonu da tamamlandı
Sonraki 5 gün boyunca uyku ciddi biçimde azaldı ve her gün 30–50 şikâyet e-postasıyla ilgilenmek gerekti

ChatGPT’nin Ürettiği Model Dönüşüm Biçimi

Backend migrasyonu sırasında veritabanı modelleri Prisma/TypeScript’ten Python/SQLAlchemy’ye taşındı
Model dönüşümü sıkıcıydı ve ChatGPT’nin bunu iyi yaptığını düşündükleri için neredeyse tüm migrasyonda kullanıldı
Üretilen kod kopyalanıp yapıştırıldıktan sonra çalıştığı doğrulandı; production’da da normal göründüğü için bu şekilde devam edildi
O sırada veritabanına insert işlemleri hâlâ Next API tarafından yapılıyordu; Python backend ise yalnızca veritabanını okuyordu
Abonelik özelliği uygulanırken ilk kez Python’dan DB record’ları insert edilmeye başlandı
- Yeni SQLAlchemy modeli elle oluşturuldu, ancak mevcut modellerde ChatGPT’nin ürettiği biçim aynen kopyalandı
- Tüm modellerin ID üretim biçimine aynı sorun girmiş oldu

Asıl Neden ve Gündüz Neden Görünmediği

Temel hata, UUID üreten bir fonksiyon veya lambda geçirmek yerine tek bir sabit kodlanmış ID dizesi geçirmekti
Belirli bir backend instance’ında bir kullanıcı bu ID ile aboneliği tamamladığında, aynı instance’taki sonraki abonelik denemeleri benzersiz ID çakışması üretiyordu
Backend mimarisi bu sorunu daha uzun süre gizledi
- AWS’de 8 ECS task çalıştırılıyordu
- Her task 5 backend instance’ı çalıştırıyordu
- Kullanıcı potansiyel olarak 40 farklı ID’den birine ulaşabiliyordu
Gündüzleri main branch’e günde 10–20 kez doğrudan commit atılıyor ve her seferinde yeni bir backend dağıtımı gerçekleşiyordu
- Her dağıtımda müşterilerin kullanabileceği 40 yeni ID oluşuyordu
Gece commit ve dağıtımlar durunca her sunucunun tek ID’si hızla tükendi
- Başta abonelik yapılabilen sunucu sayısı 40’a yakındı, ancak zaman ilerledikçe neredeyse 0’a yaklaştı

Kayıp Ölçeği ve Sonraki Adımlar

Kayıp, 50 emails/day x 5 days x $40/month hesabıyla aylık 10.000 $ gelir kaybı olarak tahmin edildi
- Bu hesap yalnızca şikâyet gönderen kullanıcıları baz alıyor
Nedeni bulmak için 5 gün, sayısız e-posta, yüzlerce Sentry log’u, bir Stripe mühendisiyle uzun bir Discord konuşması ve beş kritik dosyanın incelenmesi gerekti
Neden keşfedildikten sonra Adam hızlıca düzeltmeyi gönderdi
Sonrasında güçlü unit/integration testleri, uyarılar ve loglama eklendi
Bu olay; insan hatası, yetersiz test, kod kopyalama ve main’e doğrudan push birleştiğinde, tek satırlık küçük bir hatanın bile büyük gelir kaybına yol açabileceğini gösteriyor

2 yorum

znjadong 2024-06-11

Şey, yapay zeka tarafından otomatik üretilen kod mutlaka gözden geçirilmeli; onu neden doğrudan olduğu gibi kullanıyorsunuz?

GN⁺ 2024-06-10

Hacker News görüşleri

İzleme eksikliği 10 bin doları uçurmuş. Uygulama veritabanı istisnalarını sürekli ve büyük miktarda üretiyormuş ama kimse bildirim almamış
Böyle bir uyarı olsaydı soruşturma 5 gün değil 5 dakika sürerdi. Uyarı sistemini düzeltmedilerse aslında hiçbir şeyi düzeltmemişlerdir
- Evet. Log mesajında ID'nin benzersiz olmadığı yazıyor olurdu, bu da hata ayıklama süresini çok azaltırdı
  Her şey sorunsuz çalışırken programlama kolaydır, zor olan kısmı sorunları ele alma tarafıdır
- Bu tür şeyler giderek daha yaygın hale geliyor. Şirketler ve kurucular, seçtikleri bulut sağlayıcısının her şeyi sihirli şekilde halledeceğine inanıp altyapıyı düşünmüyor
  Ücretli müşteriler gelmeye başladığı andan itibaren logging, monitoring, alerting, güvenlik vb. konularda bilgi ve deneyimi olan birine ihtiyaç var. DevOps amatörce ele alınmamalı
- Testlerin olmaması kötü, yapay zekanın ürettiği şeyi üç kez kontrol etmeden kullanmak da riskli
  Ama veritabanında hata loglama ve uyarı olmaması asıl çılgınca kısım. Bu 20 yıllık legacy code değil, yeni bir ürün; ayrıca DB hatalarının veri doğrulama gibi kullanıldığı dönemin kodu da değil
- Dağıtımdan hemen sonra uyumaya gitmek burada bir tehlike işareti gibi görünüyor. Sabah 9 civarı dağıtım yapıp mesai saatleri boyunca sorunları izlemeleri gerekirdi
- Anlaşılan ChatGPT izleme gerektiğini söylememiş
Blog yazısı 404 veriyor, bu yüzden Web Archive bağlantısını bırakıyorum
https://web.archive.org/web/20240610032818/https://asim.bear...
Yazar önemli bir düzeltme eklemiş: buradaki pratiklerin çok kötü ve utanç verici düzeyde olduğunu, sonrasında da sağlam unit/integration testleri ile uyarı/loglama eklediklerini söylüyor. Sonuçta bunun insan hatası olduğunu ve dönüp bakınca açıkça önlenebilir bir olay olduğunu belirtiyor
Ayrıca bunun şirketin ilk birkaç haftasında, büyük zaman baskısı altında yaşandığını; production ortamındaki bug'ın yeniden üretilebilirliğinin tuhaf olduğu komik bir hikaye olarak görülmesini istediğini eklemiş
- Çok fazla olumsuz tepki aldığı için silmiş olabilir
  Aptalca bir hata ama insanlar, ister birey ister grup olsun, aptalca hatalar yapar
- Görünüşe göre subdomain gibi bir şeyi değiştirmiş ve yazı hâlâ yayında
  https://0912i390129ionkjan.bearblog.dev/how-a-single-chatgpt...
- archive.org sayfası şu anda yüklenmiyor ama Google cache hâlâ bir kopya sunuyor
  https://webcache.googleusercontent.com/search?q=cache%3Ahttp...
Hata hemen fark ediliyordu. Ekibe saygım var ama bunun ChatGPT ile pek ilgisi yok; daha çok ekibin yeterince aşina olmadığı bir programlama modeli kullanmasıyla ilgili
Kod incelemesinden geçmiş olsa bile, 5 dakikada kurulabilecek izleme araçları bile büyük olasılıkla bunu yakalardı
- Adil olmak gerekirse, bu hatayı aramak için özellikle bakmasaydım muhtemelen ben de göremezdim. Yine de izleme ya da en temel manuel testler bile olsaydı anında yakalanacağı doğru
- Ekip ne veritabanı loglarından ne de uygulama loglarından temel seviyede sorun giderebilmiş gibi görünüyor. Bu basit bir hataydı; tablo üzerindeki örtük kilitler gibi geçici hatalar olduğunda ne yapacaklarını düşününce endişeleniyorum
- Bu masum bir hata değil; başlık kasıtlı olarak clickbait ve arama motoru optimizasyonu için yazılmış. ChatGPT hata yaptı imasıyla kaygı uyandıran tıklamalar hedefleniyor
  “LLM kullanırken programlama hatası yapıldı ve kalite güvencesi yapılmadığı için 10 bin dolara mal oldu” başlığı, yöneticilerde “ChatGPT batırırsa bizim riskimiz ne olur?” gibi bir tepki oluşturmaz. LinkedIn'de bu yazıyı paylaşan orta ve üst düzey yöneticilerden tonla olacaktır
  LLM'ler “hata” yapamaz. Deterministik değildir, akıl yürütemez, düşünemez ya da mantık işletemez. İstatistiksel olasılık kullanan çok gösterişli bir kelime salatası üreticisidir; ürettiği şeyin doğru ya da isabetli olacağına dair garanti yoktur, dolayısıyla tanım gereği buna hata demek de tam oturmaz
  Düzeltme: Yazı bariz nedenlerle ciddi şekilde downvote aldıktan sonra sıralamada birden yükseldi; bu da moderatör tarafından öne çıkarılmış gibi görünüyor: https://hnrankings.info/40627558/
  Kurallara göre başlığı değiştirilmesi gerekecek kadar clickbait olan bir yazının moderatör tarafından öne çıkarılması komik. Üstelik yazarın bir Y Combinator şirketinde çalışıyor gibi görünmesi de herhalde tamamen tesadüftür: https://news.ycombinator.com/item?id=40629998
- İlginç olan, bu hatayı bulan bir başka varlığın da ChatGPT-4o olmasıydı. Görselli sohbetleri paylaşamıyorum ama hatalı kodun görüntüsünü yapıştırıp “kodda sorun ne” diye sordum, şunları söyledi
  Birincil anahtar için UUID üretiminde str(uuid.uuid4()) değil, doğrudan çağrılabilir uuid.uuid4 kullanılmalı; çünkü SQLAlchemy değeri üretirken fonksiyonu çağırır dedi. Tarih varsayılanı için server_default=text("(now())") beklendiği gibi çalışmayabilir, bunun yerine func.now() kullan dedi; ayrıca uuid ile SQLAlchemy'nin text importlarının da kontrol edilmesini ve zaman dilimi işleme için DateTime(timezone=True) kullanımının düşünülmesini önerdi
  Sonrasında düzeltilmiş kod olarak id = Column(String, primary_key=True, default=lambda: str(uuid.uuid4()), unique=True, nullable=False) önerdi ve burada lambda: eklenmesi sorunu çözdü
- Python deneyiminiz neredeyse yoksa uuid.uuid4() ifadesini Prisma gibi yerlerdeki şema tanımı sanabilirdiniz. O yüzden bu bug'ın kendisi şaşırtıcı değil; ben de aynı hatayı yapabilirdim
  Yine de tek bir kubectl logs ile hemen bulunabilirdi. Bir de Next.js ve Prisma'dan Python'a geçmek mi? Neden?
Hatanın kendisi anlaşılır. ChatGPT olmadan kod yazılsa bile nispeten kolay gözden kaçabilecek gibi duruyor
Ama ilk başarısızlıktan sonra neden yakalanmadığını anlamıyorum. Bu şirkette loglama yok muydu? Backend'in UUID'yi yeniden kullanmaya çalıştığı şey, hataya bakınca hemen ortaya çıkmalıydı
- Müşteri şikayet edene kadar hata olduğunun bile farkına varılmamış. Müşteriden önce hangi hatanın oluştuğunu sizin bilmeniz gerekir; loglama, uyarılar, herhangi bir tür izleme olsaydı yardımcı olurdu
- Asıl sorun bu. Hızlı ilerleyen bir projeyse, bir noktada yine böyle bir prodüksiyon hatası çıkma ihtimali yüksek. Umarım bir dahaki sefer teşhis 5 gün sürmez
- Bu bug'ı anlamak için 5 gün harcanmış olması epey çılgınca
- Birden fazla Stripe aboneliği gibi özel durumların normal birim testlerinde atlanması gayet mümkün. Yazıda anlatıldığı gibi kabul testleriyle yeniden üretmek de kolay olmayabilirdi; bu yüzden odağı ChatGPT'ye çevirmek hem yazar hem de başkaları açısından biraz abartılı
  String yerine çağrılabilir nesne verilmesi gereken bir fonksiyona yanlışlıkla string vermek yaygın bir durumdur. ORM kullanılmasaydı bu spesifik sorun belki önlenirdi ama bu da ORM'lere karşı kişisel önyargım olabilir. Veritabanı dışındaki bağlamlarda da benzer bug'lar rahatlıkla ortaya çıkabilir
  Bu bug'ı kesin yakalardım diye konuşan insanlar ya benden çok daha iyi mühendisler ya da daha büyük ihtimalle kendi yetenekleri konusunda biraz yanılıyorlar
  Ama log olmaması ya da loglara bakılmamış olması gerçekten anlaması güç. ECS kullanılıyorsa Duplicate Key istisnası ek ayar gerekmeksizin CloudWatch'a iletilmiş olmalıydı; iletilmedi mi, yoksa iletildi de gece boyunca hangi istisnanın oluştuğuna kimse bakmadı mı merak ediyorum
- Amazon'da bu tür süreç hataları yüzünden hata düzeltme, yani postmortem süreci var: https://aws.amazon.com/blogs/mt/why-you-should-develop-a-cor...
  Böyle durumlarda neden tespitin geciktiğini ve neden teşhisin uzun sürdüğünü sormak faydalıdır
İnsanların yazdığı kodda da aynı hatayı defalarca gördüm. Özellikle React / TypeScript / JavaScript tarafında birinin lambdayı unutması sık olur
Blog yazısı sorunun kök nedenini düzgün açıklayamadan doğrudan ChatGPT’yi suçlamaya geçmiş gibi hissettiriyor. Acele çalışıp büyük değişiklikleri ya da ekip arkadaşı incelemesi olmayan commit’leri main’e atarsanız böyle şeyler olur
Asıl sorun şu: acele edip kestirme yollara başvurur, yeterli test ve ekip arkadaşı kod incelemesi yapmazsanız hata çıkar. Farklı kayıt seçeneklerini deneyen testler bile olsa muhtemelen hemen bulunurdu
- ChatGPT’ye dair zihinsel modelim, asla terfi edemeyecek junior mühendis olması. Bir gün kovulacak biri gibi, ama sonsuz hızda yazabildiği için çok dikkatli kullanılırsa faydalı olabilir
  Böyle birini finansal açıdan kritik kodun yakınına koyarsanız benzer sorunlar yaşanır; üstelik neredeyse hiç test olmadan o kodu dağıtmaya karar veren kişinin muhakemesini de sorgularım
- Bu tür sorunlar birçok yerde yaygın. Örneğin Vue bileşen özelliklerinde varsayılan değer olabilir; ama nesne ya da dizi döndüren bir fonksiyon yerine varsayılan değer olarak literal nesne veya dizi kullanırsanız büyük sorun çıkar
  Bunun için bir lint kuralı olmamasına şaşırdım
- ChatGPT sadece dikkati dağıtan bir unsur. Kodu neyin ürettiğinden çok, o kodla ne yaptığınız önemli
- Kodu ChatGPT yazdı, push etti ve sonrasında incelemeyi de ChatGPT yaptı demek ki. /s
  Umarım öyle değildir
“Proje aslında full-stack NextJS idi ama önce her şeyi Python/FastAPI’ye migrate etmek istedim” kısmı göz açıcı
Müşterisi bile olmayan bir startup’ın nasıl yeniden yazımı meşrulaştırdığını anlayamıyorum
- Aynısını düşündüğüm için deli olduğumu sanmıştım. Bu kadar erken aşamada yeniden yazmanın mantıksız olduğunu düşünüyordum ama yorumlarda kimse değinmiyor sanmıştım
  Müşteri olsun olmasın, bu kadar erken bir noktada esasen Node’dan Python’a yatay geçişi neden yaptıklarını anlamıyorum. Yüzlerce müşterileri olup Go gibi bir şeye geçmek isteseler bir nebze anlayabilirdim, ama o durumda bile hâlâ soru işaretli olurdu
- Üstelik bariz görünen bug’ı fark edemeyecek kadar deneyimsiz oldukları bir dilde yeniden yazım yapıyorlardı
- Benim durumumda, şu an üzerinde çalıştığım gerçek bir projede bu, C# iyi bir dil ve runtime ile web framework’ü de fena değil ama geliştirme hızını düşürüyor ve acı noktaları durmadan birikiyor diye olabilir
  Mesela bir sürü DTO nesnesi üretmem gerekiyor ama AutoMapper kullandığım sürüm kombinasyonu ve proje ayarlarında çalışmıyor; Entity Framework ile JSON serialization/deserialization da sağladığından çok daha fazla acı veriyor
  Elbette bunlar kademeli olarak çözülebilir. Dokümantasyona derin dalarak, biraz hack’leyerek, paketleri yükseltip ayarları baştan yazarak halledilebilir. Ama insan metaforik bir benzin bidonunu alıp her şeyi yakmak ve ikinci sistemi daha iyi yapmak istiyor. Tabii pratikte daha iyi olmuyor; sadece başka acı noktaları çıkıyor ve ilk sistemin yaptığı her şeyi ya hiç yapamıyor ya da doğru yapamıyor olabilir
  İşte de legacy ya da uğraştırıcı sistemleri gördüğümde hep aynı dürtü geliyor. “Yeniden yaz” diye bağıran beyni yenmek için aktif ve sürekli çaba gerekiyor. Bazen yeniden yazım ya da container kullanımı gibi mimari değişiklikler işe yarıyor, ama çoğu zaman alevlerin içine yürümek ya da bitmeyen bir işe saplanmakla sonuçlanıyor
  Sistemin işletimini ya da diğer geliştiricilerin developer experience’ını iyileştireceğine dair yüksek güven olmadığı sürece, o dürtüye teslim olmamak iyi oluyor
- Bu olayda ChatGPT’nin tek başarısızlığı, yeteneği sayesinde lansman öncesi yeniden yazımın runway harcamak için makul ve kolay bir iş olduğu yanılsamasını yaratmasıydı
ChatGPT aslında uygulamanın kazandığı parayı mümkün kılan taraftı. ChatGPT olmasa bunu hayata geçirecek beceriye sahip değillerdi
Kodlama, debug, logging ve monitoring yapamayan yetersizlik 10 bin doları yaktı; bu hikâyede ChatGPT’nin net etkisi pozitif
- github.com/reworkd adresindeki bu ekibin projelerine bakınca ürünün ve ekibin olgunluk seviyesi hemen görülüyor. Emoji güdümlü geliştirme yapıyorlar
  Tüm commit mesajlarında emoji var. Maymun, muz, roket, havai fişek; yok yok
- Özellikle aylık 20 dolarlık maliyet açısından bakınca daha da öyle
- 10 bin dolar çerez parası. Elon bugün ortaya çıkan xAI hatası yüzünden 500 milyar dolar kaybedebilir
  https://grook.ai/share?id=e269e88a7b1a71eff4f176c864b30161&x...
- Uygulama zaten daha önce hayata geçirilmişti, yani beceri var gibi görünüyor
  Aslen full-stack NextJS idi ve backend’i Python/FastAPI’ye migrate ederken Prisma/Typescript veritabanı modellerini Python/SQLAlchemy’ye çeviriyorlarmış. Bu iş sıkıcı olduğu için ChatGPT’nin bunda epey iyi olduğunu görüp neredeyse tüm migration’da kullanmışlar
  Zaten ChatGPT olmasaydı bu öncü migration girişimine kalkışmazlardı; dolayısıyla net etkinin pozitif olduğunu söylemek zor. Mevcut stack’te daha iyi hata loglama olabilir, olmayabilir de; ayrıca kodu kendileri yazdıkları için yapıyı daha iyi biliyor olup buna daha az ihtiyaç duymaları da mümkündü
  Gelir modelini açmadan önce “tüm kodu ikinci kez yeniden yazma” kararının kendisi de ilginç tabii
“Buradaki pratiklerin kötü olduğunu ve bunun önlenebilir olduğunu önce söylemek istiyorum. Bu, çok büyük zaman baskısı olan başka bir dönemin olayı. Lütfen bunu hesaba katarak okuyun” ifadesi var
Bu tür kısıtlar yüzünden yazılım abonelikleri ürkütücü geliyor
- Yazarın bu hikâyeyi paylaşması, özellikle de böyle bir önsözle paylaşması gerçekten saygı uyandırıcı. Başkalarının hangi hataları yaptığını bilmek çok faydalı ama insanın kendi hatasını kamuya açık anlatması epey utanç verici olabilir
- Aboneliklerden hoşlanmasanız da, eskiden kullanıcı koltuğu başına yüzlerce dolarlık lisans satın alınan dünya da harika değildi
- Legacy abonelik koduyla uğraştım; gerçekten epey dağınık olabiliyor
  Race condition yüzünden kullanıcıdan iki kez ücret çektiğimiz bile oldu. O yüzden para ile ilgili timeout ya da hata görünce, artık önce ödemenin gerçekleştiğini varsayıp sonra yeniden kontrol edecek kadar paranoyak oldum
- Alternatif bunu kendin yazmak, ama o zaman da diğer her şeye kısıt geliyor
- Yeniden yazımı “büyük” zaman baskısı altında yapmak da alışılmadık
TypeScript ve Python ile yazılmış kod, Next.js gibi framework'ler, 8 AWS görevinin her birinde 5 instance çalıştırılırken gelir sadece 40 dolardı ve geliştirme süresi de yalnızca birkaç haftaydı, öyle mi?
İnsanın aklına gerçekten ne olduğu sorusu geliyor. Zaman kısıtı yüzünden kodun berbat halde olduğunu söyleyip düzeltmişler ama asıl daha kötü olan, diller arası refactoring'e ve hiçbir gerekçe olmadan dağıtık sistem kurmaya zaman harcamış olmaları
Bu, özelliklerle akıl dışı teknik karmaşıklığı aynı anda jonglörlük yapar gibi idare etmeye çalışan kendine zarar veren karmaşıklık. Ne düşündüklerini anlamak zor
Düzeltme: YC 2023 yaz dönemi şirketi ama ürün 2024 yazında da hâlâ bekleme listesinin arkasında gibi görünüyor. Muhtemelen Rust ile yeniden yazdıkları içindir
- Çünkü başlangıç sermayesi olarak 500 bin dolar var, bunun üstüne 1,2 milyon dolar daha eklenmiş ve yakıp bitirecek ücretsiz AWS kredileri de mevcut
Python'da toplamda 1000 satır bile yazmamış gibi görünüyor ama sorunu doğru tespit etmiş
Python'da Common Lisp'in değerlendirme stratejisini tam kopyalayamamasından kaynaklanan bir kusur var. İsteğe bağlı fonksiyon argümanlarının varsayılan değer ifadelerinde foo=obj.whatever() gibi bir argüman varsa, obj.whatever() fonksiyon çağrıldığı anda değil, fonksiyon tanımı işlenirken değerlendirilir
Muhtemelen verimlilik için bunun bilerek böyle yapıldığından şüpheleniyorum. Python'ın başka bir kusuru daha var: liste gibi yaygın nesneler için gerçek bir literal sözdizimi yok. [1, 2, 3] bir literal değil, daha çok bir constructor'a benziyor; her değerlendirildiğinde yeni bir liste oluşturup içini doldurması gerekiyor
Tasarımcı muhtemelen list=[] gibi bir parametrenin, argüman her atlandığında yeni bir boş liste oluşturmasını istememiştir. Lisp'te '(1 2 3) ve '() gerçek literal'lerdir ve her başvurulduğunda aynı nesneyi işaret eder. Programcı varsayılan değer ifadesi olarak (list 1 2 3) mü yoksa '(1 2 3) mü kullanacağına karar verebilir
İlki, [1, 2, 3] gibi her seferinde değiştirilebilir yeni bir nesne üretir; ikincisi ise neredeyse kesin olarak hep aynı nesneyi döndürür ve güvenilir, taşınabilir biçimde değiştirilemez. Modern popüler dillerin çoğu zaten Lisp'in özelliklerinin büyük bölümüne sahip, bu yüzden kaybedecek bir şey yokmuş gibi duran bir şaka bu
- Söylenen teknik olarak doğru ama blog yazısında olan şey bu değildi. Sorun fonksiyon tanımında değil, sınıf tanımının içindeydi
- foo=obj.whatever() ifadesinde obj.whatever()'ın fonksiyon çağrısı anında değil, fonksiyon tanımı işlenirken değerlendirildiği iddiası doğru görünmüyor
  .whatever() nesne başlatıldıktan sonra değişen iç duruma bağlıysa ne olacağını bilmiyorum