Python’un kalıcı gücünü ve dilin iyileştirebileceği 3 yolu analiz etme

Kısacası, gelecekte biraz daha modern ve görkemli ve yine de topluluk desteği ve geliştirici katılımı konusunda dağınık bir anlayışa sahip, ancak belki de geçmişte olduğu kadar çılgın ve kinci olmayan bir Python bekliyorum (bunu yaşayanlar). Python 2’den Python 3’e travmatik geçiş, neden bahsettiğimi biliyor olabilir.)

Python’un ömrünün bu aşamasına ulaşmak için, anlamlı bir şekilde ele alınan birkaç önemli potansiyel sorunu görmemiz gerektiğini düşünüyorum. Niyet ederek “potansiyel” diyorum, çünkü gündeme getireceğim tüm konuların, acı noktaları kadar fırsat barındırdığını düşünüyorum.

Olası sorun 1: Takımlar kafa karıştırıcı

Başlangıçta distutils (Python’da paket oluşturmanın eski yolu) vardı ve sorunsuz çalıştılar. Onu ne kadar zorlarsak, ihtiyacımız olanı yapmadığı yerleri o kadar çok keşfettik.

Şimdi, yeni Python geliştiricilerinin karşı karşıya kaldıkları şey, bir nedenden dolayı “env” ile biten birçok araç ve teknolojidir (Pyenv, Pyvenv, Virtualenv, Pipenv vb. ve ayrıca Twine, PIP, Flit ve Poetry gibi şeyler). Python programlarının en basit türlerinden başka bir şey inşa etmek istiyorlarsa kafalarını toplamaları gerekir.

Gerçekte, bunların hiçbiri o kadar karmaşık değil; hepsinin bir işi var ve işini iyi yapıyor. Ancak yeni bir programcı olarak geldiğinizde, bir blog gönderisini okuyabilir ve bu teknolojiler arasında belirli bir yol bulabilir ve başka bir yerde okuyabilir ve tamamen yeni bir yol edinebilirsiniz, ta ki sonunda, bir şey yapmadan önce hepsinin ne yaptığını bilmeniz gerektiğini anlayana kadar. sizin için neyin doğru olduğuna dair bir seçim. Ve bu sorunlu.

JavaScript veya Düğüm gibi dilleri rahatsız eden aynı sorun: Deneyimsizler için, aralarından seçim yapabileceğiniz bir sürü teknoloji var ve etrafta dolaşmak çok kolay.

Olası bir çözüm:

Python bunun bir sorun olduğunu biliyor, bu yüzden önümüzdeki birkaç yıl içinde bir şeyler göreceğimize inanıyorum. yeni başlayanlar için daha sorunsuz bir deneyim yaratmak için bazı temel araçlara odaklanın. Bu araçların, dile çok daha güzel bir giriş sağlayan bir şeyde birleştiğini göreceğiz.

Python’da test yapmak için pytest’in resmi olmayan altın standart haline gelmesiyle aynı şekilde, girişimci geliştiriciler getirmeye devam ettikçe paketleme ve paket yükleme (ve oradaki tüm lojistik) konusundaki araçlarımızla benzer bir noktaya ulaşacağız. Bu terminoloji çorbasından kurtularak dili yeni başlayanlar için daha ulaşılabilir hale getirmenin yeni yolları.

Potansiyel sorun #2: Standart kitaplıkta şişkinlik

Python’un ilk günlerinde, dil, “piller dahil” sözünü taşımak için popülerlik kazandı: Her Python kurulumunda aldığınız standart bir paket kitaplığı vardır, bu nedenle ne yazarsanız yazın, bu paketlerin dahil edilmesi garanti edilir. . Arkadaşınıza çalıştırması için bir şey vermek isteseydiniz, herhangi bir özel kuruluma ihtiyaçları olmazdı – sadece Python’a ihtiyacınız var ve işe yarayacak.

Artık, böylesine büyük bir standart kütüphaneye sahip olma fikrinin kendi yolunu çizdiği ve onu sürdürmekle görevli çekirdek Python geliştiricilerinin boynunda bir albatros olduğuna dair büyüyen bir fikir var, özellikle de standart kütüphanede bir sürü şey olduğunu düşündüğünüzde. 1980’lerin eski protokollerine kadar uzanıyor.

Olası bir çözüm:

PEP 594 öneriyor standart kitaplıktan bu “bitmiş pilleri” öldürmek, bu, çalışma zamanı veya gerçekten önemli kitaplıklar gibi daha önemli şeylere harcanacak çabayı sağlar. Bunu bir adım daha ileri götürerek, bir geleceğimiz olduğunu da görebiliyorum. merkezi olmayan standart kitaplıkböylece bir geliştiricinin farklı bir datetime veya pathlib sürümü kullanması gerekiyorsa, örneğin, python çalışma zamanında belirli bir sürümle takılmaları gerekmez.

Potansiyel sorun #3: GIL

Pek çok Python geliştiricisi muhtemelen Global Interpreter Lock’un (veya GIL) ne olduğunu bilmiyor ve şanslılar. Çok derine inmeden basitleştirmek için, temel olarak Python programınızda aynı anda yalnızca tek bir şeyin olabileceği anlamına gelir; Örneğin birden fazla iş parçacığınız olsa bile, ilerleme kaydetmek için GIL’i tutmanız gerektiğinden yalnızca biri ilerleme kaydedebilir. Açık nedenlerden dolayı (bir seferde birden fazla şeyi çalıştırmak istemek gibi), GIL bir süredir Python’un başına bela olmuştur.

Olası bir çözüm:

GIL’in artık teorik bir bakış açısıyla var olmasına gerek yokken, yakın zamanda geçeceğini sanmıyorum. Bunun tartışılmaya devam edeceğini düşünüyorum, çünkü her zaman GIL’e gerçekten çok derin dikkat gösterecek ve üzerinde çalışmaya devam etmek isteyecek bir Python inekleri (ki bunu sevgiyle söylüyorum) olacak çünkü derinden teknik olduğu için . Ondan etkileniyorlar. Ama işin diğer tarafı çok teknik olduğu için, gereken derin sistemik düşünce nedeniyle GIL’i çıkarmak gerçekten zor olurdubu olmasını engelledi.

GIL’i kaldırmanın bir profesyoneli, oluşturabileceğiniz programlar açısından bazı çok güçlü yeni Python “süper güçlerinin” kilidini açabilmesidir, ancak bu, çoğu Python kullanıcısı için gerçekten alakalı olmaz çünkü bunlar, oluşturmayan programlar oluşturuyorlar. paralel giden şeylere bağlıdır. GIL ile ilgili sorunların çoğu, alt yorumlayıcılar veya asyncio gibi çözümler gibi başka yollarla da ele alınabilir.

Python’un geleceğiyle ilgilenenler için, bu üç sorun alanına (ve toplulukta etraflarındaki tartışmalara) göz kulak olmak gerçekten önemli olacaktır.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak.