koddla

Yazılımcıları bilgi ile güçlendirir.

Python’da neden list.join(string) yerine string.join(list) kullanıyoruz?

.join kullanıyorsanız, bu yöntem kafanızı karıştırıyor olabilir. Listeyi aşağıdaki gibi birleştiriyor olmak daha mantıklı gelebilir – yani liste üzerinden .join uygulamak ve birleştirme dizesini argüman olarak vermek:

my_list = ["Hello", "world"]
print(my_list.join("-"))
# Çıktı: "Hello-world"

Normalde ise aşağıdaki gibi yapıyoruz:

my_list = ["Hello", "world"]
print("-".join(my_list))
# Çıktı: "Hello-world"

Peki böyle olmasının özel bir nedeni var mı?


Bunun nedeni, join’in generic bir metod olması. Yani herhangi bir yinelenebilir öğenin birleştirilebilir olmasıdır (örneğin, liste, dizi, dict, set). Ancak birleşen öğelerin içeriği ve “birleştirici” dizeler olmalıdır.

Mesela:

'_'.join(['hello','world'])
'_'.join(('hello','world'))
hello_world

Dizeler dışında bir şey kullanmak aşağıdaki hataya neden olur:

TypeError: sıra öğesi 0: beklenen str örneği, int bulundu


Bu yöntem ile ilgili tartışma 1999’da başladı ve Eylül 2000’de piyasaya sürülen Python 1.6’ya dahil edildi (ve Unicode’ı destekledi). Python 2.0 Ekim 2000’de piyasaya sürüldü.

  • Bu tartışmada önerilen dört seçenek vardı:
    • str.join(seq)
    • seq.join(str)
    • seq.reduce(str)
    • join yerleşik bir işlev olarak
  • Guido sadece list ve tuple için değil, tüm dizileri/yinelemeleri desteklemek istedi.
  • seq.reduce(str) yeni gelenler için zordu.
  • seq.join(str) dizilerden str/unicode’a beklenmeyen bir bağımlılık oluşturur.
  • join() yerleşik bir işlev olarak join() yalnızca belirli veri türlerini destekleyecekti. Bu nedenle, yerleşik bir ad alanı kullanmak iyi olmayacaktı. Eğer join() birçok veri türünü destekleyecek olsaydı da, optimize edilmiş bir uygulama oluşturmak zor olacaktı. __add__ yöntemini kullanarak uygulasaydık o zaman O(n²) işlem yükü getirecekti.
  • Ayırıcı dize () atlanmamalıdır. Açık örtük olmaktan iyidir.sep

Bunun yanında düşünülmesi gereken bazı şeyler de vardı:

  • Unicode desteği geliyordu, ama nihai değildi. O zamanlar UTF-8, UCS2/4’ün yerini almak üzere olan en olası şeydi. UTF-8 dizelerinin toplam arabellek uzunluğunu hesaplamak için karakter kodlama kuralının bilinmesi gerekir.
  • O zamanlarda Python, bir kullanıcının yinelemeli bir sınıf oluşturabileceği ortak bir arabirimi kuralına zaten karar vermişti. Ancak Python, yerleşik türlerin genişletilebilmesini Python 2.2’ye kadar desteklemedi.

Guido’nun tarihi kararı sonuçta str.join(seq) olması yönünde oldu:

Komik görünüyor, ama doğrusu bu gibi! Barry, devam et…
Guido van Rossum

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Back to top