IronPython: .Net üzerinde Python - Bölüm - 3

0
zekzekus
IronPython: dot Net üzerinde Python - 1
IronPython: dot Net üzerinde Python - 2
Yazının özgün haline bu adresten ulaşabilirsiniz.

IronPython içinde bir sınıf oluşturup bunu "System.Object" sınıfından türettiğinizde, IronPython .NET sistemine bir çağrı yapar ve dinamik olarak yeni bir CLR sınıfı oluşturur. IronPython sınıfınıza bir isim atar ve sınıfı kendi "IronPython.NetTypes.System" sınıfına yerleştirir. (Tabii ki Beta versiyon üzerinde çalıştığımızı gözününde bulundurmalısınız. IronPython'ı geliştirenler bu isimuzayı adlarını değiştirebilirler.) Sanırım Poe "Rüya içinde Rüya" gibi bir şeyler yazmıştı. Bu durumda bizde .NET içinde .NET uyguluyoruz. Ya da öyle bir şey işte.

.NET'in Asıl Gücüne Ulaşmak

Evet IronPython'ı kullanarak .NET sınıfları oluşturabileceğime ve bunları kullanabileceğime ikna olmuş durumdayım (sizin de ikna olduğunuzu umuyorum). Şimdi bunun ne anlama geldiğine bir bakalım. "System.Forms" isimuzayından kısa bir örnek yapmaya ne dersiniz? Bu Windows grafik kullanıcı arabirimleri oluşturmanıza imkan veren isimuzayıdır. Lafı dolandırmıyorum ve işte örneğimiz:


import clr
clr.AddReference("System.Windows.Forms")
from System.Windows.Forms import *

class MyForm(Form):
    def __init__(this):
        Form.__init__(this)
        this.Text = "Class Names"
        this.Click += this.ClickHandler
    def ClickHandler(this, f, a):
        t = this.GetType()
        MessageBox.Show(t.FullName)

f = MyForm()
Application.Run(f)

Python'ın en sevdiğim programlama dillerinden biri olduğundan bahsetmiştim değil mi? Sebebini şimdi hatırladım. Bu kod bir pencere oluşturur ve pencerenin "Click" olayını, sınıfımızın adını gösteren bir mesaj kutusu oluşturacak şekilde yönetir.

Çeşitli .NET sınıflarını nasıl kullandığıma dikkat edin. Bu tıpkı normal Python kodu gibi ama bir farkla: Bu durumda kullandığım sınıfların hepsi "System.Windows.Forms.dll" kütüphanesinde yaşıyor. Bu kütüphanedeki sınıfları kullanmaya başlamadan önce IronPython'a bu kütüphaneyi tanıtmam gerekiyor. Bu kütüphane .NET'in standart sistemindeki kütüphanelerden biri olduğundan bu yana, tek yapmam gereken, ".dll" uzantısı olmadan kütühanenin ismini programıma dahil etmek.


clr.AddReference("System.Windows.Forms")

"AddReference" fonksiyonunu kullanabilmek için .NET kütüphanelerini programa dahil etme esnasındaki zor ve karmaşık işleri yapan "clr" modülünü programıma dahil ettim.

Şimdi IronPython bu kütüphane ile ilgili bilgiye sahip ve artık içinden istediğim herhangi bir şeyi programıma dahil edebilirim. Şu anda örneği basit tutmak istediğimden kütüphanedeki herşeyi dahil ediyorum:


from System.Windows.Forms import *

Bu satır bana ihtiyacım olan "Forms", "Application", ve "MessageBox" sınıflarını kullanma olanağını verir.

Ardından pencere için kendi sınıfımı tanımlıyorum. Sınfımı "Form" sınıfından türettim ve bir yapılandırıcı fonksiyon ile pencere tıklama olayını karşılayacak fonksiyonu yazdım. Yapılandırıcı, pencerenin "Text" özelliğine karakter tipinde bir atama yapıyor, hemen ardından kendi tanımladığım "ClickHandler" fonksiyonunun, penecerenin "Click" olayında ateşleneceğini belirtiyor. Bundan daha basit olamazdı! Sözdizimine dikkat:


this.Click += this.ClickHandler

Benim "ClickHandler" fonsiyonum da sınıfın tipini alıyor ve tipin tam ismini bir mesaj kutusunda görüntülüyor. Bu kadar basit!

Gömülü Veritipleri ve Python

Bazı gömülü Python veri tipleri hem Pythonda oldukları gibi hemde .NET sisteminde oldukları gibi gerçekleştirilmişlerdir. "String" veri tipi böyle bir örnektir. Eğer "import System" komutunu çalıştırırsanız, Pythondaki "string" değişkenleriniz .NET "string" sınıfının elemanlarını da uygulayabilir. "String" sınıfını kullanmak için "System" isimuzayını programa dahil ederek başlayın. Ardından IronPython konsolunda bir "string" tipinde değişken oluşturmayı deneyin:


>>> import System
>>> a = 'hello there everybody'

"dir(a)" komutunu çalıştırarak değişkenin kullanılabilir fonksiyonlarını listeleyebilirsiniz:


>>> dir(a)
['Capitalize', 'Center', 'Clone', 'Compare', 'CompareOrdinal', 'CompareTo',
 'Concat', 'Contains', 'Copy', 'CopyTo', 'Count', 'Decode', 'Empty', 'Encode', 'EndsWith',
 'Equals', 'EqualsRetBool', 'ExpandTabs', 'Finalize', 'Find', 'Format', 'GetEnumerator',
 'GetHashCode', 'GetLength', 'GetSlice', 'GetType', 'GetTypeCode', 'Index', 'IndexOf',
 'IndexOfAny', 'Insert', 'Intern', 'IsAlnum', 'IsAlpha', 'IsDecimal', 'IsDigit',
 'IsInterned', 'IsLower', 'IsNormalized', 'IsNullOrEmpty', 'IsNumeric', 'IsSpace',
 'IsTitle', 'IsUpper', 'Join', 'LJust', 'LStrip', 'LastIndexOf', 'LastIndexOfAny',
 'Length', 'Lower', 'Make', 'MemberwiseClone', 'Modulus', 'Multiply', 'Normalize',
 'NotEquals', 'PadLeft', 'PadRight', 'RFind', 'RIndex', 'RJust', 'RSplit', 'RStrip',
 'Remove', 'Replace', 'Split', 'SplitLines', 'StartsWith', 'Strip', 'Substring',
 'SwapCase', 'Title', 'ToBoolean', 'ToByte', 'ToChar', 'ToCharArray', 'ToDateTime',
 'ToDecimal', 'ToDouble', 'ToInt16', 'ToInt32', 'ToInt64', 'ToLower', 'ToLowerInvariant',
 'ToSByte', 'ToSingle', 'ToString', 'ToType', 'ToUInt16', 'ToUInt32', 'ToUInt64',
 'ToUpper', 'ToUpperInvariant', 'Translate', 'Trim', 'TrimEnd', 'TrimStart',
 'Upper', 'ZFill', '__class__', '__cmp__', '__contains__', '__eq__', '__getitem__',
 '__getslice__', '__init__', '__len__', '__mod__', '__module__', '__mul__',
 '__ne__', '__new__', '__repr__', 'capitalize', 'center', 'count', 'decode', 'encode',
 'endswith', 'expandtabs', 'find', 'index', 'isalnum', 'isalpha', 'isdecimal',
 'isdigit', 'islower', 'isnumeric', 'isspace', 'istitle', 'isupper', 'join', 'ljust',
 'lower', 'lstrip', 'replace', 'rfind', 'rindex', 'rjust', 'rsplit', 'rstrip', 'split',
 'splitlines', 'startswith', 'strip', 'swapcase', 'title', 'translate', 'upper',
 'zfill']
>>>

Bu liste hem Python fonksiyonlarını (küçük harfle ya da altçizgi karakteri ile başlayanlar) hem de .NET "string" sınıfı fonksiyonlarını (büyük harflerle başlayanlar) içermektedir. İşte bir .NET fonksiyon çağrısı:


>>> a.Capitalize()
'Hello there everybody'

Ve burada da bir Python fonksiyon çağrısı:


>>> a.title()
'Hello There Everybody'

GetType() fonksiyonunu çağırırsanız, değişkenin .NET tipini öğrenebilirsiniz:


>>> a.GetType()
System.String

Aşağıdaki kodun gösterdiği gibi, sayı tipi değişkenleri de .NET tipleri olarak kullanabilirsiniz:


>>> n = 100
>>> n.GetType()
System.Int32
>>> x = 3.1415
>>> x.GetType()
System.Double

Python'a özgü veri tipleride .NET sistemine yapılan çağrılarda parametre olarak kullanılabilirler. Mesela "Form" sınıfının "Controls" özelliği, "AddRange" isimli bir fonksiyon içerir. Python'a özgü bir liste tipindeki veriyi "AddRange" fonksiyonu için parametre olarak kullandığım aşağıdaki kodu bir inceleyin:


import clr
clr.AddReference("System.Windows.Forms")
from System.Windows.Forms import *

class MyForm(Form):
    def __init__(self):
        Form.__init__(self)
        
        Button1 = Button()
        Button1.Top = 10
        Button1.Left = 10
        Button1.Text = "One"
        
        Button2 = Button()
        Button2.Top = 50
        Button2.Left = 10
        Button2.Text = "Two"

        ctrls = [Button1, Button2]
        self.Controls.AddRange(ctrls)
        
f = MyForm()
Application.Run(f)

Bu kod problemsiz bir şekilde çalışır. Eğer "AddRange" fonksiyonunun çevrimiçi yardım belgelerine bakacak olursanız, onun "Control" tipindeki nesnelerden oluşan "array" tipinde bir parametre beklediğini görürsünüz. Python'un liste veri tipi (bu koddaki "ctrls" değişkeni gibi), IronPython için benzersiz olan "IronPython.Runtime.List" adıyla gerçekleştirilmiştir. Bu kontrollerden oluşan bir "array" tipindeki değişkenden biraz farklı bir durumdur.

Peki "AddRange" fonksiyonuna Python'un liste veri tipinde bir parametreyi nasıl geçirebiliyoruz? Basit: IronPython, bir fonksiyonun hangi tipte veri beklediğini kontrol eden ve gelen veriyi ilgili tipe dönüştüren çok güçlü bir mekanizmaya sahip. Bu mekanizma sizi bir sürü gereksiz işlemden kurtarmaktadır. (Ve IronPython geliştiricilerinin bu özelliği eklemek için çok uğraştıklarını tahmin ediyorum. Dolayısı ile onlara teşekkür etmeliyiz.)

Yine de bir .NET "array" tipi değişken oluşturmak isterseniz, IronPython bunu yapmanıza izin veren bir sözdizimine de sahip. Önceki koddaki "ctrls" satırını değiştirebileceğiniz sözdizimine örnek aşağıda:


ctrls = System.Array[System.Windows.Forms.Control]( (Button1, Button2) )

Bu da "Control" nesnelerini içeren bir "array" değişken oluşturur ve isterseniz bu değişkenide "AddRange" fonksiyonuna parametre olarak geçmeyi tercih edebilirsiniz. Sözdizimine dikkat; değişkenin "System.Array" tipinde olacağını belirtiyorum, ardından tutacağı elemanların veritipini köşeli parantezler içinde belirtiyorum ve son olarak da "Button1" ve "Button2" nesneleri ile değişkenin ilk yapılandırılmasını yaparak tamamlıyorum.

Konunu tam olarak anlaşılabilmesi için, bir "array" tipi değişkenin sonuçta Python'daki liste tipinden nasıl farklı olduğundan biraz bahsetmeliyim. CLR "array" tipini doğal olarak destekler. Bu destek .NET sisteminin "Array" ismindeki sınıfı ile çok yakından ilgilidir. Doğal .NET dillerinde (özellikle C# ve VB.NET), direkt olarak "Array" sınıfının örneklerini oluşturmazsınız. Bunun yerine, bu diller, sizin CLR "array" tipinde veriler tanımlamanızı sağlayacak olan kendi özel yapılarını kullanırlar. Mesela VB.NET dilinde "Control" nesnelerinden oluşan bir "array" değişkeni şu şekilde tanımlayabilirsiniz:


Dim c(2) As Control

Bu 2 hücreli bir "array" değişken tanımlar. Eğer "c.GetType().FullName" komutunu çalıştırırsanız, "System.Windows.Forms.Control[]" ismini görürsünüz. Bu .NET sınıfı olan "Array"den türetilmiş bir CLR "array" tipi değişkenidir. Ve bu Python liste tipinden tamamen değişik bir şeydir.

Maalesef kullandığım sistemin beta versiyon olmasından dolayı, henüz "array" dönüştürme işlemi tam olarak problemsiz sayılmaz.


Yine de Python!

Eğer gerçekten Python ile ilgileniyorsanız, "getattr" fonksiyonu ile dinamik olarak nesne elemanlarına ulaşabilme gibi özelliklerden haberdarsınızdır. Bu fonksiyon IronPython içindede mevcut ve .NET sınıfları üzerinde de işini yapıyor. Şuna bir bakın:


>>> import System
>>> import clr
>>> clr.AddReference("System.Windows.Forms")
>>> from System.Windows.Forms import *
>>>
>>> btn = Button()
>>> btn.Height = 30
>>> hasattr(btn, 'Height')
True
>>> getattr(btn, 'Height')
30
>>> setattr(btn, 'Height', 50)
>>> btn.Height
50

Tabii ki hala aktif olan "delattr" fonksiyonu .NET sınıflarından türetilmiş sınıflarda işe yaramıyor. Şunu belirtmeliyim ki, önceden mevcut bir sınıfın mevcut bir özelliğini silmek sistemin yapısına ciddi zararlar vermeden, pek mümkün değildir.

Reprinted from DevSource.com, a Ziff Davis Media property, all rights reserved, Ziff Davis Media, 28 East 28th St., New York, NY, USA

Görüşler

0
FZ
Bu ne hız! Elinize sağlık! :)
0
FZ
Teknik bir eleştiri: a.Capitalize() ve a.title() gibi iki metod çağrısı görünüyor, biri .NETten biri Python'un standardından gelen. Benim takıldığım şey ise şu, bir nesnenin üzerindeki metodun ismi bir fiil olmalı daima diye düşünüyorum. Birinci örnekte bu dediğim geçerli, a nesnesine hangi işlemin uygulanacağı söyleniyor, isim kökenli bir fiil kullanmak sureti ile, ikinci örnekte ise yine nesneye üzerinde iş yapan bir metod olmakla birlikte "title" lafı bir fiil değil. Burada ince bir tutarsızlık olduğunu düşünüyorum. Metod ismi olacaksa mutlaka fiil, özellik ismi olacaksa da mutlaka isim olsun diyorum ben, bu çakılsın, buna daima uyulsun şeklinde. Bilmem diğer OOPciler buna ne der?
0
newman
Tek sorun su: "title" kelimesinin fiil anlami da var (entitle demek), daha pekcok benzerleri gibi...
0
FZ
"entitle"ı biliyorum da "title"ı fiil olarak pek görmedim, buradan yola çıkarak diyebilirim ki, eğer fiil olarak kullanılma frekansı çok düşük ise o zaman akla gelen ilk şey isim olarak kullanılması durumu olacaktır ki bu da yine ufak bir karışıklığa yol açıyor. Her şey bir yana, tamam sonunda parantez var, metod filan olduğu oradan anlaşılabilir denir belki ama a.title'a kadar olan kısmı görünce benim ilk, ikinci ve üçüncü aklıma gelen şey "a nesnesinin title özelliğini öğreniyor olacağım" oluyor ve bunu da metod tarzı bir şey değil özellik türünden bir şey olarak düşünüyorum. Denebilir ki, misal C# dilinde "property" denir ama içi basbayağı bir metodun içi gibi olabilir, buna da diyecek lafım şu olurdu herhalde: Önemli olan içi değil, yüzey, kabuk görüntüsü, birNesne.Ad dediğimde, o Ad'ı getirmek için arka planda 50 satırlık karmaşık bir iş yapıyor olabilir, o bir implementasyon meselesidir, ben Ad'a özellik dedim nesneye yönelik modelleme yaparken, metod demem asla.
0
newman
boyle durumlarda en iyi kaynak (dil icin) www.m-w.com
Ozellik ile metod arasinda bu kadar kesin cizgiler koymak cok iyi bir yaklasim degil bence. Hatta cizginin belirsizlestirilmesi daha iyi bir fikir olabilir. Seni Sussman amcamizin videolarina havale ediyorum :)
0
FZ
Ben de en büyük sıkıntılarımızdan birinin keskin kriterler koymaktan kaçınmak olduğunu düşünüyorum bazı bakımlardan. Madem ki işimiz yazılım ve madem ki köklerini formel sistemlerden alıyor o halde bazı şeyleri didik didik etmenin, çözümlemeye çalışmanın bir sakıncası olmasa gerek diye düşünüyorum. Öte yandan görüldüğü gibi ortada keskin bir kriter olunca, birisi kalkp gayet güzel onunla uyumlu argüman öne sürebiliyor, "ama bakın 'title' aynı zamanda bir fiildir, dolayısı ile sorun yoktur" diyebiliyor ki bence muğlaklık yerine böyle bir net cevap çok daha tercih edilir.

Diğer yandan, keskin kriterler koymanın güzelliği nedir, bizi daha da tembelleştirmesi (programcılar olarak en tembel insanın en erdemlisi olduğunu biliriz, öyle değil mi?), bir kez iyice ince eleyip sık dokursak, tıpkı matematikçilerin ve bazı mühendislerin yaptığı gibi daha sonra düşünmemize gerek kalmaz, çok değerli düşünme ve problem çözme enerjimizi çözülmemiş şeylere odaklarız.
0
newman
Ama ben kesin kriterler koymayalim demiyorum: fakat koydugumuz kriterler dogal ve dogru olmali. Sadece onerilen kriterin boyle olmadigini dusunuyorum. Ote yandan muglaklik her zaman kotu bir sey degil: bazen gerekli. Mesela polymorphism, operator overloading, multiple inheritance, vs. Bunlarin hepsinde kasitli bir muglaklik var.
0
Tarık
"polymorphism, operator overloading, multiple inheritance, vs." siz uygulama esnasında muğlak olarak kabul ediyorsunuz ama onlar arkaplanda gayet kesin kurallarla birbirinden ayrılıyor. Çok biçimlilik ve operatör aşırı yükleme dilin teknik yeterliklerini geliştirmek için düşünülmüş konular, bunları nesnelerin yalın metodlarına, özelliklerine muğlak isimler vermekle aynı kefeye koymak, örneklemek bana mantıklı gelmiyor. Tek isim altında farklı işler yapıyorsa belirgin ve farklı bir isim kullanılabilir. Ama bunu her metod için bu şekilde uygulamak ne kadar doğru?
0
FZ
Burada kast ettiğim şey, hani yanlış anlama olmasın, biçimsel (formel) sistem filan dedim, sonra "overloading" filan geçti, ben dilin kendine içkin kurallardan ziyade farkında iseniz "best practices" gibi bir kategoriden bahsediyorum. Dil tarafından dayatılmayan ama mesela benim bir kenara yazacağım ve sonra da hiç düşünmeden uygulayacağım ve sonuç olarak işimi(zi) kolaylaştıracağını düşündüğüm kurallar silsilesi.
0
newman
Vallahi didismek icin degil :), ama her nasilsa bu onuda cok farkli dustuk: Ben "best practice" bahsettigin ayrimi toptan ortadan kaldirmak oldugunu dusunuyorum. Ama bundan benim "kesin kurallar" istemedigim filan cikariliyor. Proje bazinda, bu proje sahiplerini ilgilendirir. Genel kutuphaneler icin ne dusundugumu yazdim. Yani demek istiyorum ki, eger boyle bir kural istiyorsak, ben "hicbir "field"in aslinda basit bir degisken oldugunu varsayamazsin" diye bir kural oneriyorum :), fiil olmasini zorlamaya karsiyim. Mesela sin, cos, tan, log... Bunlari ne yapacagiz? Bunlar fiil degil. Bunlar ozel ve belirli seyler ve istisna demeyelim. Oyle degil bence.
0
Tarık
Zaten ilk başta gayet yalın olarak tartışıyorduk sonra sanırım benimde katkılarımla işin içine farklı şeylerde girdi :) Evet kastettiğim şey sizinkiyle aynı, işi daha anlaşılır hale getirerek fuzuli geriye dönüşler yaşamamak. Yani ben kesin ifadelerle çalışırsam daha iyi anlıyorum, en kaba tabirle "aaa bu neydi" demiyorum.
0
newman
Dilin arka planinda kurallar elbette olacak. Ama kullaniciya bakan yonuyle muglaklik var: bu da tam vurgulamak istedigim konu.

Muglak isimler vermek ne demek? Ben boyle birsey demedim.
0
Tarık
"Çizginin belirsizlestirilmesi daha iyi bir fikir" düşüncesinin altında yatan mantık nedir? Türkçe olarak biraz bahsedebilirmisiniz?
0
newman
"Fiil" ile "fonksiyon" aslinda tam ortusen kavramlar degil. "Fonksiyon"lara bir nesne gozuyle bakmak daha dogru kanimca. Cunku fiiller daha cok "yan etkileri" olan fonksiyonlara karsilik gelir. Matematik veya mantiktaki, veya benim kavram olarak cok sevdigim fonksiyonel programlamadaki fonksiyonlar boyle degil. Daha cok bir bellek hucresine kaydetmenin zor oldugu dinamik, ama "nesne" olarak gorulmesi gereken bir sey. Ayrica "object.x" yerine "object.x()" olur mu, diye de sormaliyiz kendimize. Neyse, kisaca boyle. Umarim derdimi biraz aciklayabildim. Acik degilse itiraz edin, bir daha deneyeyim.
0
Tarık
Evet programcı tarafından dediğiniz şekilde bir düstur edinilmesi, hem kodu sonradan okuyacak muhtemel programcılara, hemde kodun yazarının kendisine daha faydalı olur. Daha faydalı olur derken aslında kesinlikle gerekli olduğu kanaatindeyim. Heleki büyük projelerde anlaşılabilirlik çok önemli hale geliyor.

Not:OOP cu değilim ama arada kullanıyorum iyi oluyor :)

0
newman
Aslinda ben daha once soyle bir teklif gormustum: butun field ve degisken isimleri bir fonksiyon cagrisi olsun. Ontanimli "implementasyon" da simdiki gibi olsun. Biraz C#'in Property'leri gibi yani. Bunun hiza olumsuz etkisi olmaz mi? Eger derleyici bunlari inline kod haline getirirse hayir. Ote yandan bu fiil-isim ayrimi Ingilizcede Turkcedeki kadar kati degil. Sozluklerde olaniyla olmayaniyla, isimlerim onemli bir kismi fiil olarak da kullaniliyor. Turkcedeki son ekler vs. bunu engelledigi icin bize bu cok tuhaf gelebilir, ama durum bu.
0
dfix
Fena fikir değil benimde başka bir önerim var object pascal notasyonunda tüm classlar 'T' harfiyle başlar bence bütüm class isimleri bu şekilde başlamalı yüzde yüz OOP olan dillerde pek sorun olmasada C++ gibi dillerde tipin ilk bakışta class mı struct mi yoksa bir record tip mı olduğunu anlama ve algılamak güç. Hangi dili kullanırsam kullanıyım Class deklerasyonlarında class adını 'T' harfiyle başlatıyorum belki bir alışkanlık belki bir takıntı..
Görüş belirtmek için giriş yapın...

İlgili Yazılar

IronPython: .Net üzerinde Python - Bölüm - 2

zekzekus

Makalenin 1. bölümü için tıklayınız. Yazının özgün haline bu adresten ulaşabilirsiniz.

Python .NET ile buluşuyor.

Eğer hem Python hem de .NET'e aşinaysanız bazı problemleri hemen farkedebilirsiniz. Yeni başlayanlar için belirtelim Python, .NET içinde tam karşılığı olmayan -bahsettiğimiz liste tipi gibi- gömülü veri tiplerine sahiptir.

Merak etmeyin; bütün bunlar halledilmiş durumda. Ama önce bir örnek yapalım. IronPython, aynı klasik Python yorumlayıcısı gibi çalışan bir konsol programı ile birlikte gelir.

Web Sitesi Performans İyileştirmeleri

muhuk

Yakın zamanda telvee'nin biraz daha hızlı yüklenebilmesi için django_compressor kullanarak ve arkaplan resimlerini düzenleyerek iyileştirmeler yaptım. İşin güzel yanı bunları gerçekleştirirken geliştirme ortamında veya tasarımda köklü değişiklikler yapmamın gerekmemesiydi. Detaylardan aşağıda bahsedeceğim. Daha önce konunun teorik kısmına kısaca değinmek istiyorum.

IronPython 1.0 Yayınlandı

zekzekus

5 Eylül 2006 tarihinde Python programlama dilinin Microsoft .NET Platformu üzerinde çalışan sürümünün 1.0 versiyonunun hazır olduğu açıklandı ve kaynak kodları ya da runtime kütüphaneleri olarak indirilmeye hazır. Buradan projenin ana sayfasına ulaşabilirsiniz.

Django Girls etkinliklerinden öğrendiklerimiz

elifkus

Kodlama saati yazısını görünce ben de Django Girls’ü ve İstanbul’daki etkinliklerimizden ve öğrendiklerimizden bahsedeyim dedim.

Amerika’da ve Dünya’da yazılımcıların kadın oranını arttırmak için birçok organizasyon ve etkinlik var. Django Girls, bunlardan biri. Ola Sitarska and Ola Sendecka adında iki Polonyalı kadın yazılımcı tarafından başlatılmış, 1 veya 2 günlük bir programlama etkinliği....

Django ORM ve SQLAlchemy üstünde Elixir karşılaştırması

muhuk

Django'yu işimde, Elixir'i (bu yazıdaki her Elixir'i Elixir+SQLAlchemy olarak okuyunuz) kendi projemde kullanıyorum. Dört veya beş yıl önce SQLObject ile başlayıp Unicode sorunları nedeniyle bende büyük hayal kırıklığı yaratan ORM macerama bir ay kadar önce FZ'nin önerisi üzerine bir şans daha verdim. Özellikle benim gibi aşırı titiz biri için SQL programlama belli bir karmaşıklıktan sonra işkence olabiliyor. ORM'ler de zamanla gelişmiş ve çok daha stabil hale gelmiş. Karşılaştırmasını yapacağım iki bileşen de yaygın kullanılan iyi projeler. Burada yazacaklarım tamamen benim fikirlerim, eğer hatalarım olursa veya farklı düşünceleriniz varsa lütfen yorum olarak paylaşınız.