Python 4.0, Python 3.0'dan neden farklı?
[CSDN editörünün notu] Ne kadar PHP'nin her zaman dünyanın en iyisi olacağını ya da Java'nın sonsuza dek yenilmez olacağını umursak da, ya da C dilinin her zaman en iyi dil olacağını umuyoruz.
Ancak bugün Baidu Dizinini araştırdım ve Python dizininin Java ve PHP dizinlerinin toplamından daha yüksek olduğunu buldum.
Python'un sürüm yinelemesi de ıslık çalıyor, peki yeni sürüm 4.0 ile 3.0 arasındaki fark nedir? Bugün Python Yazılım Vakfı'nın yönetim kurulu üyesi ve CPython'un çekirdek geliştiricisi olan Nick Coghlan'ın bir makalesini paylaşıyorum, umarım ilgilenirsiniz.
Yazarın bugün Baidu Index'teki arama sonuçları
Python fikri ile yeni temasa geçen bazı kişiler, geriye dönük uyumlu olmayan modifikasyonlar önereceklerdir.Bu öneriler, mevcut yasal Python 3 kodu için net bir taşıma planı sağlamaz ve zaman zaman Python 4000 fikrinden bahseder. Sonuçta, Python 3.0'da bu tür bir değişikliğe izin verdik. Python 4.0'da neden izin verilmiyor?
Bu sorunu birçok kez duydum (çok endişelenen biri dahil ve şöyle dedi: "Geriye dönük uyumluluğu bir kez bozdunuz, bunu tekrar yapıp yapmayacağınızı nasıl bilebilirim?"), Sanırım Cevabımı yazın ve gelecekte birisi sorarsa, bu makaleyi okumasına izin verebilirim.
Python 4.0 için mevcut beklentiler nelerdir?
Şu anki beklentim: Python 4.0 sadece "Python 3.9'dan sonraki bir sürüm". Bu kadar. Dilde köklü değişiklikler ve geriye dönük uyumluluk sorunları yoktur.Python 3.9'dan 4.0'a kadar, Python 3.3'ten 3.4'e (veya 2.6'dan 2.7'ye) kadar güvenli olmalıdır. Hatta uygulamanın ikili arayüzünün (PEP 384 tarafından sunulan işlev) sürüm yükseltildiğinde kararlı kalacağını umuyorum.
Dil özelliklerinin mevcut yayın hızına göre (yaklaşık 18 ayda bir), bu, 2023'te Python 3.10 yerine Python 4.0 görebileceğimiz anlamına geliyor.
Peki Python nasıl gelişmeye devam edecek?
Birincisi ve en önemlisi, PEP sürecinde herhangi bir değişiklik olmayacak ve geriye dönük uyumlu değişiklikler önerilmeye devam edecek ve Python uygulamalarının kullanımını geliştirmek için yeni modüller (asyncio gibi) ve dil özellikleri (verim gibi) eklenecektir. Özellikleri.
Zamanla, Python 3, işlevler açısından Python 2'ye gittikçe daha fazla öncülük edecek.Python 2 kullanıcıları, aynı işlevleri üçüncü taraf modüller aracılığıyla veya Python 3'ün geriye doğru taşınmasıyla elde edebilseler bile, Python 3'ü yakalayamayacaklar. Özellikleri.
Farklı yorumlayıcı uygulamaları ve uzantıları arasındaki rekabet, PyPy'nin JIT derleyici oluşturma ve yazılım işlem belleğine yönelik girişimlerinin yanı sıra bilimsel ve veri analizi toplulukları ve dizi odaklı programlamanın keşfi de dahil olmak üzere Python'u geliştirmenin farklı yollarını keşfetmeye devam edecek. Modern CPU'lar ve GPU'lar tarafından sağlanan vektörleştirme işlevlerinden tam olarak yararlanın).
Diğer sanal makine çalışma zamanlarıyla (JVM ve CLR gibi) entegrasyonun da, özellikle eğitim alanında, Python'u daha popüler bir gömülü komut dosyası dili haline getirebilecek şekilde zaman içinde gelişmesi beklenmektedir. Daha büyük uygulamalarda çalıştırın.
Geriye dönük olarak uyumlu olmayan bazı değişiklikler için PEP 387, Python 2 serisinde uzun yıllardır kullanılan ve bugün hala geçerli olan makul bir yöntem sunar: yani, belirli bir işlevin büyük bir soruna neden olacağını düşünüyorsanız, değiştirebilirsiniz. Kullanımdan kaldırıldı olarak işaretlendi ve sonunda silindi.
Ancak, geliştirme ve yayınlama sırasında meydana gelen diğer birçok değişikliğin Python 3 serisinde kullanımdan kaldırılmış olarak işaretlenmesi olası değildir:
Buradaki ana vurgu Python paket deposu üzerindedir. Bu, CPython çekirdek geliştirme ekibi ile Python Paketleme Otoritesi arasındaki işbirliğinin sonucudur ve Python 3.4+, emin olmasanız bile standart kitaplığa modül ekleme zorluğunu azaltan pip yükleyici ile birlikte gelir. Nispeten yavaş dil güncelleme döngüsüne uyum sağlayacak kadar kararlıdırlar.
"Geçici API" konsepti (PEP 411 tarafından tanıtıldı), kitaplıklar ve API'ler oluşturmaya yardımcı olacak standart geriye dönük uyumluluk garantileri sağlamadan önce daha geniş geri bildirim almak için bir "geçiş dönemi" belirlemenize olanak tanır.
Birikmiş eski davranışların çoğu, Python 3 dönüştürme işlemi sırasında kesin olarak çözülmüştür.Şimdi Python'un yeni işlevleri ve standart kitaplık için gereksinimler, Python 1.x ve Python 2.x'inkilerden çok daha katıdır.
"Tek kaynaklı" Python 2/3 kitaplıkları ve çerçeveleri geniş çapta kabul görmektedir ve bu da, bu özellikler yeni ve daha iyi özelliklerle değiştirilse bile, Python 3'te "kullanımdan kaldırılmış özellik belgelerinin" kullanımını büyük ölçüde teşvik etmektedir. Bu durumlarda, belgede ayarlanan kullanımdan kaldırma bildirimi, yeni kodun kullanması gereken yöntemi önerecek, ancak programda bir kullanımdan kaldırma uyarısı oluşturmayacaktır. Bu şekilde, mevcut kod (Python 2 ve Python 3'ü destekleyen kod dahil) değişmeden kalabilir (karşılık gelen fiyat: yeni kullanıcıların mevcut kod tabanını koruma göreviyle karşı karşıya kaldıklarında biraz daha fazla bilgi edinmeleri gerekebilir. biraz).
İngilizceden tüm dillere
Python 3'ün şu an olduğu kadar yıkıcı olması amaçlanmadığını da belirtmekte fayda var. Python 3'te geriye dönük uyumlu olmayan tüm değişiklikler arasında, kod taşınabilirliğini ciddi şekilde engelleyen zorlukların çoğu, PEP 3100'deki bir noktaya atfedilebilir:
Tüm dizelerin Unicode olmasına ve ayrı bir bayt () türüne sahip olmasına izin verin. Yeni dize türü 'dize' olarak adlandırılacaktır.
PEP 3100, Python 3'teki tartışmalı olmayan tüm değişiklikleri özetler, bu nedenle ayrı bir PEP oluşturmaya gerek yoktur. Bu özel değişiklik tartışmasız olarak kabul edilir çünkü Python 2 ile olan deneyimimiz Web ve GUI çerçevelerinin yazarlarının doğru olduğunu gösterir, yani bir uygulama geliştiricisi olarak Unicode'un akıllıca kullanılması tüm metin verilerinin sağlanması anlamına gelir. , Mümkün olduğunca ikiliden sistem metin işlemine dönüştürülebilir ve daha sonra çıktı alındığında ikiliye geri dönüştürülebilir.
Maalesef Python 2, geliştiricileri programları bu şekilde yazmaya teşvik etmez, bu da ikili veri ile metin arasındaki sınırları büyük ölçüde bulanıklaştırır ve geliştiricilerin kodu bırakın, ikisi arasında ayrım yapmasını zorlaştırır.
Bu nedenle, web ve GUI çerçeve yazarları Python 2 kullanıcılarına "Unicode metin kullanmalarını söylemelidir. Aksi takdirde, Unicode girişini işlerken zor ve izlemesi zor hatalarla karşılaşacaksınız".
Python 3 farklıdır: "ikili" ve "metin" arasında daha büyük bir ayrım yaparak normal uygulama kodunu yazmayı kolaylaştırır, ancak aynı zamanda ikili ve metin verileri arasındaki ayrımı daha az netleştirir.
Pythonun Unicode desteğindeki bu devrim, hesaplamalı metin işlemlerinin aktarımı hakkında daha geniş bir arka planı hedefliyor: yalnızca İngilizce ASCII'den (resmi olarak 1963'te tanımlanmıştır) "ikili veri + kodlama beyanı" modeline (20. yüzyılın 80'leri dahil). On yılın sonlarında, C / POSIX dil ortamı ve Windows kod sayfası sisteminin tanıtımı) ve orijinal 16 bit Unicode standart sürümü (1991'de piyasaya sürüldü) nispeten kapsamlı bir modern Unicode kod noktası sistemine (ilk olarak 1996'da, birkaç yılda bir tanımlanmıştır) En son büyük bir güncelleme var).
Neden bundan bahsetmeliyim? "Varsayılan olarak Unicode kullan" şeklindeki değişiklik Python 3'teki en yıkıcı ve geriye dönük uyumlu değişiklik olduğundan ve diğer (belirli dil özelliklerine daha bağımlı olan) değişikliklerden farklı olduğundan, yalnızca metin verilerinin nasıl temsil edileceği ve işleneceği ile ilgilidir. Çok çeşitli değişikliklerin küçük bir kısmı.
Python 3 dönüşümü, Python'un ilk günlerine kıyasla bazı dile özgü sorunları ortadan kaldırdığından, yeni dil özelliklerinin eşiği çok arttı ve mevcut devam eden çalışmayla karşılaştırılabilecek şekilde, sektörü etkileyen bir transplantasyon ölçeği yok. Metin modelleme için "kodlanmış ikili veriler" den Unicode'a geçin.
Bu yüzden gelecekte Python 3 gibi geriye dönük uyumluluğa neden olabilecek ve paralel desteğe ihtiyaç duyan herhangi bir değişiklik olacağını düşünmüyorum. Aksine, normal değişim yönetimi sürecinde gelecekteki herhangi bir dil evrimine adapte olabileceğimizi umuyorum.Bu şekilde ele alınamayan herhangi bir teklif, topluluğa ve çekirdek geliştirme ekibine yüksek seviyeler getireceği için reddedilecektir. Kabul edilemez maliyet.
Orijinal: https://opensource.com/life/14/9/why-python-4-wont-be-python-3
Yazar: Nick Coghlan, CPython çekirdek geliştiricileri, Python Yazılım Vakfı yönetim kurulu üyeleri. Çeşitli Python geliştirme tekliflerinin yazarı ve ortağıdır (PEP 343 dahil: Python 2.5'e ifade ve içerik yöneticisi eklenmiş, PEP 453: Python 3.4 ile birlikte paketlenmiş pip yükleyici) ve BDFL olarak Guido van Rossum adına birçok PEP uygulamasını yöneten ajan.
Çevirmen: Crescent Moon, Kurgu: Hu Weiwei
"Belgeler için çağrı"
CSDN halka açık hesabı, "on binlerce teknik insanla büyüme" kavramına bağlıdır. Teknik insanların ilk kez ilgilendikleri endüstri odak olaylarını teknik insanların benzersiz bakış açılarından tanımlamak için yalnızca "inek başlıkları" ve "konuşma" sütunlarını kullanmakla kalmaz, aynı zamanda "Teknoloji Başlıkları" sütunu, sektördeki popüler teknolojilerin ve uygulamaların derinlemesine bir yorumunu sunarak, tüm geliştiricilerin teknolojik trendlere ayak uydurmasına, uyanık bir teknolojik anlayışı sürdürmesine ve sektör eğilimleri ve teknolojileri hakkında daha kapsamlı bir anlayışa sahip olmasına olanak tanır.
Yüksek kaliteli makaleleriniz veya sektörün sıcak olayları, teknoloji trendleri hakkında içgörüler veya derinlemesine uygulama uygulamaları, senaryolar vb. Hakkında yeni içgörüleriniz varsa, gönderimler için lütfen CSDN ile iletişime geçin. İletişim: WeChat (guorui_1118, lütfen gönderim + ad + şirket pozisyonunu not edin), e-posta (guorui@csdn.net).
