Zapraszam - nieco o abstrakcji klas i interfejsach

Szkoda że diagram jest mało czytelny, jak dla mnie (ale jestem już trochę zmęczony, co i tak czasem mojej niewiedzy nie tłumaczy)

http://soiland.no/software/abstract
:D
Tylko należy uważać, żeby nie nadpisać __init__(self, *args) z klasy Abstract.

Super. To tak jak by w Javie korzystać z adnotacji do oznaczania metod abstrakcyjnych.

Uczepiliście się tych interface i abstract, jak gdyby bez tego nie można było programować. A jednak... Można. Patrząc na pythona, całkiem owocnie. Szukajcie dalej, wad... aż poznacie zalety tego języka. Pewnie ktoś na forum pythona pisze.. "JA pie... PHP to taki beznadziejny język... Mają interfejsy i klasy abstrakcyjne. My ich nie potrzebujemy i dajemy sobie rade <chuckle>(moja ulubiona emotka ze skype ) "

Poszukajcie może jakiś zalet? W czym Python jest lepszy od PHP. Mnie przypadły do gusty namespace, znormalizowany styl programowania - sprawia, że każdy kod czyta się dobrze.

Od czasu trwania tego wątku przypominam sobie Pythona. (Jakiś czas temu pisałem w nim). Zainstalowałem django, jestem nim zauroczony. Język ma potencjał, zatrzymam się przy nim na dłużej. Aktualnie po godzinach PYTHON.

Dawać sobie radę nie znaczy pisać w lepszy sposób, nadal mnie zastanawia jak może w pythonie działać CORBA bez interfejsów, pewnie interfejsy są ładowane niejawnie.

co do zalet mi się podoba dziedziczenie wielobazowe, ale jestem noga w pythonie więc nie wypowiem się nic więcej.

Potencjał tak, jak najbardziej ma i ma przyszłość.

Pamiętaj, że wszystko sprowadza się do sekwencji z 0 i 1. I jak to będzie zinterpretowane to już inna sprawa.

Pojawił się poważny argument trafiający w teoretycznie najsilniejszą stronę Pythona - obiektowość i jedyną odpowiedzią są subiektywne opinie - "mi nie potrzeba", "da się przeżyć", "można obejść".

Panowie, ja nie szukam sobie języka tylko po to by później obchodzić coś na około, ponieważ nie można tego zrobić w bardziej naturalny sposób. Co mi po tym, że mam dostęp do prototypu klasy i mogę podmienić "w locie" metodę. To samo mogę również zrobić korzystając z Java Script-owego Object.prototype, ale czy to znaczy, że język ten jest lepszy? Oczywiście, że nie.

Całe to tłumaczenie przypomina mi pewnego, pragnącego by pozostać anonimowym premiera IV RP - zamiast powiedzieć, tak popełniliśmy błąd (bądź bardziej dosadnie, daliśmy d..) to słyszymy, że wszystko jest w jak najlepszym porządku i cały czas budujemy podwaliny dla lepszego kraju. To nic, że wszyscy znają prawdę, premier ma swoje zdanie i cały kraj takie musi mieć. Panowie, może zamiast się upierać, przy tym, że się da i nie trzeba, pora przyznać, że Python ustępuje w tej kwestii pola chociażby PHP bądź pokazać, że da się inaczej - może patrząc na problem z drugiej strony, a nie tworząc protezę (czytaj wszystkie sposoby z wyjątkiem bądź adnotacją).

zwróć uwagę że Python jest rozwijany z zachowaniem wstecznej zgodności (PHP4 - PHP5 nie.) i raz stworzony dawno temu model obiektowy, nie może być przebudowany bez złamania wstecznej zgodności - częściowo zrobi to Python 3000 dla którego myślą nad m.in. wprowadzeniem Abstract Base Classes itp. Poza tym Python nie chce być Javą. Ma być proste, ładne i działające

Riklaunim powtarzasz to co inni tylko trochę inaczej...

@splatch: To olej Pythona. Czy naprawdę myślisz, że mi zależy, żeby wszyscy się go uczyli i nim zachwycali? Nie chcę dyskutować o tym, że lubie język pomimo to, że czegoś tam mu brakuje. Jeżeli Ci ten brak przeszkadza to to olej. To tak jakbym lubił piwo a Ty byś na mnie naskakiwał, że ma alkohol i dlatego Ty nie będziesz go pił. Jak już się przekonałeś, że Ci się nie podoba to po prostu nie wchodź na ten topic więcej. Python różni się od PHP. I jeżeli jest różnica to na pewno jest grupa zwolenników jednego i drugiego rozwiązania. Ja wole to z Pythona, może dlatego, że używając Pythona nauczyłem się i przyzwyczaiłem z tego korzystać. Program tym różni się od państwa i premierów, że można z niego nie korzystać (o ile oczywiście nie jest to MS-cośtam i z niczym nie jest kompatybilne ). No, to tyle...

A co do Python3k to mam obawy. Czytałem gdzieś, że wyrażenia lambda oraz np. funkcja map mają być zlikwidowane (choć gdzie indziej bardzo aktualnie, że powoli odchodzi się od tej decyzji)! Język tymsamym zacznie być specjalny już tylko skłądnią (zobaczymy co jeszcze się zmieni). I wtedy to chyba trzeba będzie zrobić forka Python2k i rozwijać takim jakim jest...

Zachowanie godne premiera Jarosława K., nie przyzna się do błędu tylko zaatakuje układ.

Gratuluję.

Bo to nie jest błąd. Nigdy mi tego nie brakowało i nigdy tego nie potrzebowałem. A Twoje argumenty kierujesz w złym kierunku. One nie powinny trafić do nas, bo skoro nigdy nam interfejsy ani metody abstrakcyjne nie były potrzebne to znaczy, że takich nie potrzebujemy, a nie, że nie wiemy, że potrzebujemy. Twoje argumenty powinieneś skierować do twórców Pythona, bo to w żadnym wypadku nie jest winą nikogo tutaj, że ich w Pythonie nie ma. I nie jest to nic karygodnego, że pomimo tych "braków" wciąż lubimy i chwalimy Pythona.
A poza tym skoro Ci tego brakuje, to zamiast narzekać, usiądź i to napisz (Python to OS) albo przestań naskakiwać na mikołaja, że rozdaje prezenty w boże narodzenie, pomimo, że wielkanoc ma interfejsy oraz metody abstrakcyjne... a poza tym autobusy maja 7 biegów a pająki 8 nóg.

celne no ok python ma jedną wadę (no 2 jak liczyć abstrakcje i interfejsy oddzielnie) ale nie czepiajcie sie tego w kółko... ja osobiście na razie tylko php męczę, ale za pythona sie zabieram powoli (tylko dive into python rozszyfruje bo w niektórych momentach jest 'pomazana' i to w pdfie...) i jak pobieżnie przeglądałem to same konstrukcje językowe są całkiem przyjemne tak jak i te wcięcia gwarantujące że każdy tak samo kod zinterpretuje

btw. ten topic chyba już sie sam wypalił bo wszystkie za i przeciw zostały użyte jak zauważyłem, a teraz trwa powielanie już wykrytych braków pythona...

W odpowiedzi co dostaje? Mi tego nie potrzeba. Ja chce sobie pojechac zwyklym samochodem, a Ty mi mowisz, ze starcza Ci rower. Mowie, ze wole samochod, a Ty, ze jak nie chce rowerem to mam isc pieszo.

Ja pytam o jakies alternatywne rozwiazanie, ktore nie jest proteza, nie pada odpowiedz a tylko zarzut, ze sie Was czepilem i ze mam sie doslownie odwalic i pojsc zawracac dupe komus innemu, co nie zmienia faktu, ze to Wy jestescie tutejszymi specjalistami od Pythona i to do Was kieruje pytanie i interesuje mnie Wasza odpowiedz a nie laskawe skierowanie do tworcow Pythona.


Pokazcie, ze da sie inaczej niz proteza badz przyznajcie, ze Python ma jeszcze braki w tej kwestii i nie mowcie mi, ze Wam tego nie potrzeba, bo g** mnie obchodzi to, ze wam starcza rower. Chce samochodu.

To pisz w PHP albo Javie. To takie proste.

Przecież, że interfejsów ani metod abstrakcyjnych Python nie ma to już wiemy od dawna (conajmniej od jednej strony tego topicu). Ja się naprawdę nie wykłócam, że Python to ma.

Czyli obsługa obiktowości po prostu kuleje...

Ty splatch usilnie próbujesz powiedzieć że Python jest do dupy bo nie ma abstrakcji i interfejsów. Ja napisałem że jedyna wada jeżeli chodzi o abstrakcję to jest to że nie posiada słów kluczowych "abstract" i "interface", ale bez żadnych problemów stworzysz i interfejsy i klasy abstrakcyjne. To tak jakbyś chciał zbudować dom i twierdził że jest to do dupy bo zamiast rozrobionej zaprawy dostajesz cement, piasek i wodę.

sztosz a ty nadal swoje...
Czy nie doszliśmy już do tego, że nie można się ciągle cofać, bo dojdziemy do kodu maszynowego?
Więc takie 'nie użyteczne' byty jak abstrakcje i interfejsy, są właśnie takim krokiem na przód, i są przydatne, że można je próbować symulować... no cóż przecież i tak wszystko skończy jak instrukcja procesora.
Przecież chyba każdy powinien znać przykłady kiedy tworzymy interfejs i jest on bardzo użyteczny.
Przypomniało mi się C (może jeszcze za mało go używam), założenie po co nam typ string, przecież to ciąg znaków... [może to zły przykład, ale mnie to irytuje najbardziej w C {jak na razie}]

A ja właśnie nie rozumiem po co typ String . Jak dla mnie bardzo naturalne jest uważanie napisu za ciąg znaków, a nie typ atomowy (czy jak to się tam nazywa w naszym języku). Przecież to to samo co wektor znaków. Podobne zresztą podejście ma python, który string tratuje jako wektor.

Wiesz i to jest krok wstecz, jestem za możliwością dokładnego zarządzania pamięci i wycieki pamięci to wina przy opisie "jak to ma działać". Ale pewne organizacje danych są jak najbardziej przydatne, bo używać wektora do obsługi ciągów znakowych mogę zawsze użyć (no prawie, co jest czasem irytujące) ale aby pisać samemu obsługę tego to trochę mija się z celem, bo po pierwsze aby zrobić to porządnie trzeba mieć czas, po drugie wiedzę. Więc jak masz już to w języku zaimplementowane, to nie bawisz się w tworzenie tylko zajmujesz się czymś co jest bardziej przydatne.

(przypomniał mi się przykład, konkursu na najszybszy 'program' między narodowy, osoby pisały w proceduralnych bo szybsze, bez komentarzy itp. a ostatecznie wygrał polak który napisał w pełni obiektowo z komentarzami wcięciami, a dlaczego bo się nie bawił w wymyślanie koła tylko to co było faktycznym problemem...)

Chyba każdy sensowny język traktuje napis tekst wektor. Zmienne przechowujące tekst są tak często stosowane, że szanujące się języki dodatkowo oprócz wektora dają ułatwienia w postaci właśnie stringa. Po to są stringi aby nie trzeba było porównywać strcmp czy jak to się tam nazywało, brrr, że już nie wspomnę o przypisaniu.

jak dla mnie to po prostu znaczy tyle:

Btw. własnie napisałem w Pythonie w pełni działający deterministyczny skończony automat, tyle, że jeszcze nie ma interpretatora (tzn. dane wejściowe trzeba podawać jako struktury Pythona). Interpreter napisze kiedy indziej. Zajęło mi to dokładnie 180 linijek. Teraz czas na automaty ze stdout (Mealy-Automat), ale jako, że już mam tyle gotowe pewnie będzie to sprawa może kolejnych 100 linijek. Btw. jakbyście chcięli troszkę (bez)użytecznego kodu Pythona to mogę podesłać. Zawsze fajnie sobie objeżeć jak można coś takiego napisać.

ROTFL, albo Ci się naprawdę nudzi albo masz takie zadanie na uczelni

Panowie, znalazłem bardzo dobry artykuł o Python, Ruby i ogólnie językach dynamicznych.
Jak ktoś ma godzinkę wolnego i zna angielski to naprawdę polecam!
W tym artykule jest odpowiedz na prawie wszystkie argumenty które padły o Pyhtonie:
http://www.hacknot.info/hacknot/action/showEntry?eid=93

Nie widzę sensu dyskutowania z osobami, które nie odróżniają interfejsu od klasy abstrakcyjnej. Panowie, róbcie co chcecie, z mojej strony jest to póki co koniec udziału w tym wątku, chyba, że pojawi się kolejne absurdy, typu znakomita, naturalna obiektowość w Pythonie.

Pozdrawiam i życzę miłej zabawy.

Akurat jeśli chodzi o interfejsy to mam co najmniej wystarczającą wiedzę, żeby odróżniać je od klas abstrakcyjnych. Wystarczy przejrzeć mój wykład ze zlotu programistów

@Splatch: To czy ty jedziesz samochodem, czy rowerem, tyczy sie twojego postrzegania na pewne rzeczy. Dla ciebie java jest Samochodem, wszystko pozostałe hulajnogą. Dla mnie nie. Mówiąc, że nie ma interface i abstract, to oop kuleje. Jak dla mnie nie kuleje. Proste

@Jabol: Chętnie zobaczę twój kod. PW?

Ojej, ależ się ten topic zestarzał, już 3 strony w tył. A teraz mała niespodzianka! Python posiada wsparcie dla interfejsów i metod abstrakcyjnych! Tylko, że nie wbudowane, trzeba sobie takowe napisać, lub ściągnąć bibliotekę skąś! I nie jest to takie wsparcie jak to za pomocą dekoratorów jak ktoś tutaj proponował. Chodzi o całkowicie akceptowalne chyba rozwiązanie, czyli o tzw. Metaklasy. W pythonie wszystko jest obiektem. Nawet klasy są instancjami typu klasa. Można to jednak zmienić, klasy mogą być instancjami innych typów, np. typu Interfejs. Oczywiście nie ma takiego typu wbudowanego w Pythona, można go jednak stworzyć. Po przykład zapraszam tutaj: http://wiki.zope.org/zope3/ZopeGuideInterfaces
http://svn.zope.org/Zope3/branches/3.3/src...amp;view=markup
Wiem, że trzeba troszkę wyczucia w Pythonie, żeby zrozumieć to co tutaj napisałem (dla ludzi piszących w PHP z jego łopatologicznym podejściem do typów taka abstrakcja może być przytłaczająca, ale po pewnym czasie staje się naturalna - jeżeli piszecie w C, to troszkę tak jak pointer do pointera, który można przecież przechowawywać w int, jak i na odwrót...).
Po więcej informacji zapraszam na google. Sam dowiedziałem się o tym mechaniźmie raczej niedawno, więc nie wyrzucajcie sobie, że nie znaleźliście nic sami na ten temat. Zresztą główny guideline głosi "jeżeli nie wiesz, że ich potrzebujesz, to znaczy, że ich nie potrzebujesz".

Pozdrawiam wzsystkich sceptyków.

EDIT:
- ok, w Zope implementacja nie jest na podstawie metaklas (widać w kodzie źródłowym), ale jak widać da się to zrobić elegancko.
- na pewno dałoby się to zrobić za pomocą metaklas, jak i zresztą o wiele więcej.
Tutaj wychodzi też kolejna cecha Pythna, którą odziedziczył z Lispa. Koncept Down-Up - budujemy aplikacje, ale równiż środowisko programowaina, od dołu do góry.

"jeżeli nie wiesz, że ich potrzebujesz, to znaczy, że ich nie potrzebujesz"
Aha, dlatego wiele osób mówi że nie potrzebuje obiektowego, bo może napisać w proceduralnym... tylko że by to zrobiła szybciej i tak samo wydajniej a bardziej rozszerzalniej w obiektowym to już nie ważne...

Jabol to co napisałeś nie zmienia faktu, że nie ma tego w języku. A jak już ktoś napisał, zamiast przyznać że nie ma, co oznacza że nie jest w pełni obiektowy, bo za przeproszeniem, obiektowość jest przejściem na wyższy poziom abstrakcji a interfejsy i abstrakcie to ułatwiają. To szukacie jakiś protez, co z tego że można coś takiego stworzyć, jak tego nie ma w języku.
Python ma wiele ciekawych rozwiązań, ale ma też pewne braki, nie można uparcie mówić że jest najlepszy pod każdym względem, bo to pokazuje ślepotę osoby która tak pisze.
Tez nie rozumiem czemu ciągle wracacie do PHP i innych rzeczy w nim, bo przecież mowa jest o braku interfejsów i abstrakcji w Pythonie, i tylko do tego się ograniczmy. Choć w sumie wszystko co było do napisania, zostało już napisane.

@Sedziwoj:(...).. W Javie i C++ i (tym bardziej) w PHP też nie ma abstrakcyjnych klas ani interfejsów! W C++ wszystko sprowadza się do asemblera i jak już masz skompilowany kod to wszystko działa bez uwzględniania stylu programowania (bo asembler jest językiem imperatywnym, i nieważne z jakiego został kompilowany). W PHP całe te Twoje abstrakcje itp. też kończą najpierw jako struktury danych z języków imperatywnych a potem wszystko przekłada się na asembler. W Javie jest podobnie, ale się nie wypowiadam bo nie znam się na szczegółach implementacji. (przepraszam za ironie)
(...) nie rozumiesz podejścia Down-Up. Najpierw należy dostosować język do swoich potrzeb a dopiero potem z niego korzystać. (...) (podejście Down-Up znane jest z Lispa). Te przykłady z Zopa do których podałem linki to nie jakieś głupie protezy - to są w pełni funkcjonalne interfejsy. Jakby w PHP nie napisano obsługi interfejsów też ich by tam nie było i nie byłyby integralną częścia języka. W Pythonie tak samo - tyle, że ich obsługa została napisana w Pythonie (tak - python tak jak Lisp ma w sobie coś z Meta-Języka) i jest oddzielnym pakietem. (...) To tak jakbyś napisał, że C nie ma wsparcia dla ciągów znakowych, bo nie ma wbudowanego typu string i trzeba robić jakieś głupie protezy korzystając z wektorów. Albo, że w C++ nie można odpalać innych programów bo nie do tego wbudowanej składni jak w sh, tylko trzeba korzystać z jakiś głupich funkjci-protez .(...)

Pozdrawiam

Jabol ja nie wiem czy Ty nie wiesz o czym jest mówione, czy udajesz głupiego.
Wiesz wszytko opiera się na tym, gdyby najlepiej było od postaw to by wszyscy pisali w np. asemblerze, a to robi raczej niewielka grupa osób. Takie języki jak chociażby C to taka 'nakładka' na asemblera, tak samo jak C++ jest 'nakładką' na C...
Język udostępnia pewne podstawy, można je rozszerzać, ale niektóre elementy powinny być częścią języka. I ja bym do nich zaliczył interfejsy i abstrakcie, jeśli jakiś język chce być obiektowym.

@Sedziwoj: mówisz o wyższym poziomie abstrakcji, a sam nie potrafisz zrozumieć pewnej dość "wysokiej" idei. Python jest rozszerzalny, nie jest tak zamknięty jak większość języków programowania - pozwala na rozszerzanie samego języka poprzez opisywanie go w tymże języku (Meta język).

Poza tym mam wrażenie że wszyscy trochę nie za bardzo rozumiemy co to abstrakcja. Abstrakcja to coś ogólnego niemającego odpowiednika w żadnym konkretnym przedmiocie (zjawisku, przypadku, nazwijcie to jak chcecie), tak twierdzi Słownik PWN. Ale lepsze jest podejście filozoficzne lub językoznawcze, nie tak kategoryczne. Abstrakcja to "przypadek" uboższy w treść od konkretnego przedmiotu, ale o szerszym od niego znaczeniu. "Kot" to np. abstrakcja, pod warunkiem że nie mamy na myśli żadnego znanego nam dachowca, a wszystkie owe, mianując je ogólnym zbiorem/nazwą "kot".

W programowaniu do chodzimy też do abstrakcji, już samo pojęcie klas i ich instancji jest abstrakcją, doskonale odzwierciedlającą to co sami w języku tworzymy. Natomiast dodatkowe tworzenie tworów teoretycznie bardziej abstrakcyjnych (klasy abstrakcyjne, interfejsy) wcale nie świadczy o tym że język jest mniej lub bardziej obiektowy. Teoretycznie, ponieważ abstrakcja to proces tworzenia pojęć o szerszym znaczeniu, a "klasa" to szersze pojęcie niż "klasa abstrakcyjna".

Takie rozdrabnianie się na "klasy abstrakcyjne", "interfejsy", etc... bywa pomocne, ale nie jest niezbędne i wcale nie jest konieczne do tego aby pisać wydajniej, toż to przecież klika linijek zbędnego kodu więcej, bo kompilatorowi/interpreterowi poza sprawdzaniem, do niczego te twory nie są potrzebne.

A wracając do Pythona, to twierdzenie że Python bez "klas abstrakcyjnych" to nie język obiektowy, to tak jakby twierdzić, że samochód bez abs'u to nie samochód

Dobre podejście . Dodałbym jeszcze: słyży Ci tylko, jak nie umiesz hamować ;d

Fajnie że rozszeżalny, ale jeśli to nie ma być zabawa w asemblera to pewne rzeczy podstawowe powinien mieć.



Abstrakcja to zbędne linijki? może masz rację, po co tworzyć w jednym miejscu wspólny kod dla pary klas, jak w każdej można osobno to samo napisać... do tego można wymusić aby każda dziedziczące miały coś co powinny mieć, ale czego nie da się na tym poziomie opisać.

Ogólnie przecież programowanie obiektowe to przejście na wyższy poziom abstrakcji, więc brak paru poziomów jest tak jakby dziwny...
Do tego gdyby to było takie zbędne to by nikt o to się nie czepiał, widocznie nie jest, a mówienie że to nie zuboża języka... no tak brak obiektów w C go też nie zuboża.



Nie to samochód bez karoserii, też jeździ ale gorzej (aerodynamika), jak również tak trochę niezbyt wygląda

I ciągle mnie to dziwi, bo z jednej strony mówicie, że to jest niepotrzebne, a z drugiej udowadniacie, że możecie to tworzyć (przez 'protezy' co prawda)... zamiast zakończyć na tym że to jest Wam niepotrzebne.

To jakby kobiecie zarzucić brak brody, ona mówi że jest jej niepotrzebna, ale zawsze może mieć sztuczną.

Dobra, pewnie odpiszecie na tego posta, ale nie widzę sensu dyskusji. Do tego zarzucacie mi rzeczy nieprawdziwe, ja się staram i jak czegoś nie rozumiem/nie wiem w wypowiedziach innych to się tego dowiaduję.

Do tego Python ma wiele zalet (jak kobieta) i jakoś ich nikt nie umniejsza. (ale nie wnikajcie w to porównanie do kobiety, bo raczej ma wyrazić moje zdziwienie w upartym bronieniu że nie ma abs/int ale można sobie je zrobić)

Ja bym proponował nie kontynuować dyskusji o braków interfejsów, tylko skupić się na innych aspektach tego jakże bogatego języka.

Olejcie już temat "eee brakuje abstrakcji, eee nie ma interfejsów".

W środę we Wrocku będzie wykład o Pythonie: http://www.aasoc.pwr.wroc.pl/Wikka/OpenAcademy/ Zapraszam chętnych, sam też będę

Mnie niestety nie będzie, liczę na jakąś relacje z tego eventu

Ja wlasnie sie dowiedzialem, dzieki sztos, i jak mi sie zachce to pojde
Mialem zamiar poznac pythona i skoro w 2h mam sie dowiedziec o jego mozlowiosciach to na pewno warto pojsc.

Nie wysnuwaj tak rażących, daleko idących wniosków na podstawie języka. Taka
bo ja równie dobrze mogę powiedzieć, że zrozumienie idei separacji implementacji od definicji struktury jest tak dalekie programistom Pythona jak ich językowi do NORMALNEJ implementacji.


Równie "eleganckie" rozwiązanie możemy mieć użyciem Prototype w Java Script.
Idąc Twoim tokiem myślenia, można udowodnić, że PHP ma obsługę przestrzeni nazw i Aspektów czy też adnotacji, ponieważ dzięki Zend API można je bez problemu dodać. Fakt jest jeden - PHP nie miało i nie ma do tej pory wsparcia dla przestrzeni nazw, aspektów oraz adnotacji. Z tym, że programiści PHP nie twierdzą, że to jest zbyteczne, a przyznają się do braków języka.


Panowie, nie róbmy z tego od razu nie wiadomo jakiej koncepcji. Java Script jest podobnie jak Smalltalk językiem bazującym na prototypach i możemy z nich korzystać by dodawać nowe metody do predefiniowanych klas, ale nikt tego nie nazywa Down-Up a tym bardziej nie eksponuje jako wielkiej zalety.



Sprowadzasz języki tak jak liczby do jednej kategorii - zawsze niepodzielnych przez zero nie zwracając uwagi na to w jakich okolicznościach stosuje się dane liczby. Pójdźmy o krok dalej, każdy język to i tak ciąg zer i jedynek, impulsów elektrycznych. Po co pisać w Javie, C++ czy też Pythonie i korzystać z ich mechanizmów, piszmy od razu w Assamblerze, wszak każdy z oferowanych mechanizmów sprowadza się do tych samych instrukcji.
Cieszy mnie Twoje zafascynowanie wykładami na temat teorii języków programowania, ale wierz mi nie musisz nim tutaj emanować by udowodniać swoje tezy. Nie tędy droga.

Swoją drogą to znowu dajesz nieadekwatny przykład, bo Java daje możliwość dzielenia przez zero (wyrzuca wyjątek Infinity, czy tam daje integerowi wielkość infinity, czy jakoś tak?). To oczywiście taki żarcik tylko i nie zarzucajcie mi, że odpowiadam nieadekwatnie.

A tak swoją drogą to Smalltalk też był inspirowany Lispem (wg Wikipedii), więc nie dziwota, że struktury danych unifikują się w nim z językiem i jego implementacją. Co do JS to nie wiem więc się nie wypowiadam. I uważam, że niepoprawnie zarzucasz mi przesadzanie, jeżeli chodzi o możliwości rozszerzania Pythona w nim samym. Jeżeli w PHP da się zrobić przestrzenie nazw w taki sposób, że dla korzystających z tego mechanizmu będzie to transparentne, to znaczy, że istnieje taka możliwość i przestrzenie nazw w PHP istnieją. Ja nie widzę problemu w takiej implementacji. Bardziej patrze na funkcjonalność. Ale w sumie nie zajmuje się tym profesjonalnie, może moje podejście nie jest uznawane...

Z tym sprowadzaniem czegośtam do czegośtam to też nie całkiem się zgodzę. Przeszkadza Ci, że coś sie implementuje na poziomie podłoża aplikacji, a nie przeszkadza Ci, że o poziom wyżej (albo raczej niżej) zostało by to zaimplementowane w ten sam sposób. Asembler(czyli de facto kod maszynowy) to język o podejściu imperatywnym, bo nie ma jak na razie maszyn, które umiałyby myśleć. Dlatego wszystkie techniki sprowadzają się w końcu do jednego. Chodzi mi o to, że nie jest to dla programisty na określonym poziomie istotne na którym poziomie poniżej jego kod zostaje zinterpretowany oraz/lub zastosowany, skoro i tak jest to poziom poza jego domeną... (czyli inaczej mówiąc nie jest ważne, czy interfejs to nakładka, czy implementacja, bo i tak działa tak samo w obu przypadkach - zakładając, że rozszerzony język jest środowsikiem, a nie częścią aplikacji docelowej).

Też jestem za tym, abyśmy się nie kłócili:). Dlatego może dodam podstawę mojego myślenia. Interfejs to dla mnie nie część języka, a raczej technika programowania. Wg takiego myślenia można zrobić wsparcie dla interfejsów nawet w asemblerze i C ('struct PyTypeObject' w Pythonie to też np. swoisty interfejs, który poszczególne typy implementują). Jako części języka python tego rzeczywiście nie ma.

Jak już zacząłem temat rozszerzania Pythona w nim samym, to dodam może jeszcze parę słów o tym.
1. Istnieją metaklasy. O tym sobie szukajcie jak sami chcecie, ja nie mam o tym zielonego pojęcia, oprócz tego, że "jest to tak magiczne, że prawdopodbnie nigdy mi się nie przyda" i pozwalają zrobić praktycznie wszystko, rozszerzać Pythona bezgranicznie, pozostawiając go wciąż "pythonowym".
2. Klasy nowego typu. To już rzecz skolei bardzo użyteczna dla każdego Kiedyś klasa w Pythonie była klasą - typem danych. Klasa nowego typu jest typem - częścią języka. Otwiera to jak się domyślacie bardzo wielkie możliwości (teraz się zastanawiam jak wielkie muszą być możliwości metaklas:?). To tyle ode mnie . Reszte polecam dowiedzieć się samemu:
http://www.python.org/doc/newstyle.html

Pozdrawiam

No i jednak... poszedlem na wyklad z Pythona


Co bylo
* ogolny wstep o Pythonie: to ze jest obiektowy, interpretowany
* krotkie omowienie podstawowych typow zmiennych
* duck typing / dynamiczne typowanie (brak typow zmiennych)
* klasy
* funkcje, argumenty, pakowanie arg. do tablic, hashy
* bloki kodu/wciecia
* magia: zmiana metod obiektu, dolaczanie innych klas do obiektu


Jak bylo
Prelegent (czy jak mu tam, wykladowca? ):
* czasami nie potrafil wyjasnic zgadnien, albo robil to zbyt skomplikowanie
* czesc zagadnien rozumialem tylko dla tego ze znalem je z Rubiego
* trudne zagadnienia jak Generatory (nadal nie wiem co to jest, ale cos jak Bloki/Proc/lambdy z Rubiego), Dekoratory (Javo-adnotacjo-aspekty ) zostaly zbyt krotko omowione zeby je zrozumiec
* jak sie pomylil to sie nie denerwowal, po prostu poprawial i kontynuowal ('r' -- dla tych co byli )

Cool, ja walczę z dekoratorami. Musze je zrozumieć na jakimś przykładzie. W necie ciężko znaleźć dobrze omówione dekoratory, może dlatego i on źle to zrobił

Odpuście sobie dekoratory? One nie są prawie do niczego potrzebne. Zagadnienia typu dekoratory nie przydają się w zwykłym programowaniu.

A mi się bardzo podobało to jak zmieniał klasę obiektu, mając już jego instancję Nagle się okazało że "klasy abstrakcyjne" to coś, co zupełnie nie jest potrzebne Bo możesz dołączyć do jakiegoś obiektu inną klasę, a raczej jej metody a wszystkie zmienne (jak to się nazywa? Pijanym i pamięć już nie ta) które dany obiekt posiada nie zmieniają swoich wartości. Ja w tym widzę potencjał, zastanawiam się tylko czy:

zadziała?

A mi się nie podobało to jak gdzieś tam po kropce było 6 zamiast b i się interpreter zbuntował errorem, po czym od razu następne zagadnienie było bez słowa wyjaśnienia :|

Co do generatorów to pamiętam że mi się podobały, ale we Wrocławiu jestem skazany na pijaństwo i nie pamiętam jak to działa i czemu mi się podobało

Generator to tak jak iterator tylko nieistniejącej wartości. To taka różnica troszkę jak pomiędzy range i xrange. Iterator iteruje poprzez istniejący zestaw wartości a generator przy każdym kolejnym wywołaniu generuje nową wartość. Tylko nie rozumiem za bardzo w czym różnica, bo iteratory można budować za pomocą generatorów a generatory za pomocą iteratorów... ale jakoś tak to jest...

Że coś z manuala PHP zacytuję:

Czyli to nie tylko domena Pythona

Ale runkit i classkit to są rozszerzenia PECL, czyli idąc twoim tokiem rozumowania protezy

Jedna prosta rada. Weź rozpęd i pier* z całej siły łbem w ścianę. Tylko tyle mogę powiedzieć. Do tej pory spotkałem się tylko z jedną dużą aplikacją, w której klas abstrakcyjnych nie było, ponieważ ktoś, kto to pisał zdecydował się na Java Script Pages (taak, to nie pomyłka), w pozostałych przypadkach klasy abstrakcyjne jak i interfejsy były stosowane (Java, PHP). Zwróćcie uwagę - dlaczego Java jest tak rozpowszechniona w środowisku biznesowym. Nie tylko dlatego, że ma zaplecze marketingowe w postaci Suna, nie tylko dlatego, że jest do niej stos bardziej czy mniej użytecznego gotowego kodu, ale dlatego, że oferuje jasną składnię i standardowe mechanizmy (typy generyczne na modłę szablonów w C++, adnotacje na kształt dekoratorów w Pythonie). Wszystkie te rzeczy zostały włączone do "standardowej" Javy, ponieważ był przydatne. A przyznacie chyba, że takie zabiegi w językach kompilowanych nie są częste. Spójrzcie - Java ewoluuje, PHP ewoluuje, a Python co? A Python ma stadko zwolenników, którzy twierdzą, że to język idealny. Bzdura i tyle.

Proponuje żebyś sam pier* z całej siły łbem w ścianę, jeżeli nie potrafisz pewnego minimalnego "poziomu" zachować i powstrzymać się od "osobistych wycieczek".

Piszesz że Python nie ewoluuje. mam rozumieć że wszelkie zmiany od wcześniejszych wersji są niczym. Zastanawia mnie więc czemu twierdzisz że PHP ewoluuje? Bo się nie dorobił namespces? Bo wciąż są dodawane nowe rzeczy, ale nie jest robiony porządek choćby z nazewnictwem wbudowanych funkcji?

Zaś co do samej kwestii "klas abstrakcyjnych", poza samą teoretyczną czystością kodu wciąż nie widzę czym się różni klasa abstrakcyjna czy interfejs od innych klas. W Pythonie zaś, przy odrobinie wyobraźni i kreatywności można stworzyć taki mechanizm, który będzie tworzył bardzo dynamicznie obiekty odpowiadające dokładnie naszym potrzebom. Chcemy nagle ciężarówkę? Mamy ciężarówkę, chcemy tramwaj? Mamy tramwaj. Pomimo tego że nie ma klas ani ciężarówka, ani tramwaj, ani nawet nadrzędnej abstrakcyjnej "pojazd". Jest jedynie nie abstrakcyjny "pojazd" + do tego zbiór metod z których w czasie już działania aplikacji korzystamy. Żeby uciąć deskę, nie muszę być stolarzem, wystarczy że będę człowiekiem. Pewnie trudno to do objęcia rozumem, a już na pewno ciężkie w implentacji, ale dobrze zaimplentowane jest zgrabne i wydajne.

Mam wrażenie ~splatch, że ty próbujesz wciąż udowodnić że Python jest "Be", bo Java i PHP są lepsze. Jak chcesz to się babraj w swojej hierarchiczności i abstrakcjach, mnie to nigdy nie pociągało. Nigdzie nie twierdziłem że klasy abstrakcyjne są złe czy głupie, a jedynie że mi do niczego nie są potrzebne. To tak jak z muzyką, Hendrix znał 2 skale muzyczne, a był jednym z większych wirtuozów gitary.