🚀 go-pugleaf

Borneq <borneq@antyspam.hidden.pl> writes:

> Dopiero zamierzam zainteresować się pythonem. Jest on językiem
> interpretowanym czy kompilowanym?

Język nie zna pojęć interpretowany czy kompilowany.
Pytanie jaką implementacją się chcesz zainteresować?
Jeśli tą najbardziej popularną implementacją w C, czyli CPythonem, 
to kod jest _kompilowany_ do byte codu, który to jest następnie
_interpretowany_.

$ python2.5 -m py_compile test.py
$ file test.pyc
test.pyc: python 2.5 byte-compiled

Jednak kompilacja na ogół odbywa się automatycznie, także nie ma
potrzeby wykonywania jej ręcznie (jak powyżej).

Jak wybierzesz implementacje Pythona na JVM (Jython) lub CLR
(IronPython), to wówczas Python jest _kompilowany_ do byte codu
tychże maszyn wirtualnych, a że owe maszyny posiadają JIT,
to także _kompilowany_ do kodu natywnego.

> Jak z prędkością?

W przypadku CPythona łatwość usuwania wąskich gardeł przy pomocy 
rozszerzeń w C daje spore możliwości. Dobrym przykładem wydajności
jest np. Mercurial (http://mercurial.selenic.com/).

RW

On Sun, 15 May 2011 19:08:34 +0200 Rob Wolfe <rw@smsnet.pl> wrote:

> > Jak z prędkością?
> 
> W przypadku CPythona łatwość usuwania wąskich gardeł przy pomocy 
> rozszerzeń w C daje spore możliwości. Dobrym przykładem wydajności
> jest np. Mercurial (http://mercurial.selenic.com/).

Dodam tylko, że tworzenie od podstaw modułów rozszerzeń jest całkiem
proste. Istnieje także cyton, wariant pythona w którym łącznie kodu
z C jest jeszcze prostsze: http://docs.cython.org/.

Do tego wszystkiego w std. pythonie jest moduł ctypes, który umożliwia
wywoływanie dowolnych funkcji z bibliotek dzielonych, więc
teoretycznie można zapomnieć o C.

w.

W dniu 2011-05-15 19:08, Rob Wolfe pisze:
> Borneq<borneq@antyspam.hidden.pl>  writes:
>
>> Dopiero zamierzam zainteresować się pythonem. Jest on językiem
>> interpretowanym czy kompilowanym?
>
> Język nie zna pojęć interpretowany czy kompilowany.

teoretycy by się burzyli, ale zwykle pytanie tzw "praktyków" o 
kompilowanie ma dwa podteksty:
a) szybkościowy. Tu by dodał, że np kod bliski maszynowemu ale często 
przełączalny do dynamicznie rozwiązawanych subalgorytmów (np. typowo 
dynamiczna gospodarka zmiennymi) jest hamowany tak mocno, że w praktyce 
ma szybkośc interpretera.
b) poziom sprawdzeń na etapie kompilacji. Może być rygorystycznie 
sprawdzany ale "kompilowany" (w cudzysłowie lub bez zależnie od 
upodobań) nie do maszynowego jak oczekuje pytający, tylko do p-kodu 
podlegającemu interpretacji w maszynie wirtualnej. Tu należało byś 
ściśle mówić o typowaniu.

Chyba różnica językowa jest tu problemem.

Aha, jeszcze
c) czyli stopień zabezpieczenia kodu źródłowego przez disasemblerami, 
czyli niemożność przywrócenia z wersji wykonywalnej do w miarę czytelnej 
źródłowej. Ja wiem, różnica jest ilościowa (w wielkości pracy) a nie 
jakościowa (da się/nie da), ale czasem jest to sens pytania.

On 2011-05-15, Rob Wolfe <rw@smsnet.pl> wrote:
> Usunięcie błędów kompilacji nie dowodzi niczego. Ogarnięcie kodu 
> w sensie zrozumienia meritum w językach statycznie typowanych bywa
> strasznie trudne z powodu niesamowitego rozdęcia (częsty przypadek w
> Javie).
> Oczywiście jest też masa beznadziejnego kodu napisana w Pythonie,
> ale jest go przynajmnie naście jeśli nie dziesiąt razy mniej.

Ale nie z powodu dynamicznego typowania. W Adzie i Haskellu
beznadziejnego kodu jest jeszcze mniej.

-- 
Secunia non olet.
Stanislaw Klekot

On 05/16/2011 09:38 AM, Stachu 'Dozzie' K. wrote:
> Ale nie z powodu dynamicznego typowania. W Adzie i Haskellu
> beznadziejnego kodu jest jeszcze mniej.

Haskell to rozumiem, ale poważnie żyje jeszcze ktoś, kto pisze w Adzie?

Pozdrawiam,
Adam

On 16.05.2011 22:18, Rob Wolfe wrote:

>
> Ok, mamy różne pojęcie o tym jaki błąd jest oczywisty. ;)
> Tak, interfejsów statycznie nie da się sprawdzić w Pythonie.
> Wspominałem też o testach, które by tu pasowały jak ulał.

Pokrycie testami 100% kodu ze wszystkim ścieżkami jest dosyć trudne.


Przykład ze stosunkowo małego systemiku:
Była sobie struktura danych, która pierwotnie zawierała kilka wartości 
("kilka" jak wiadomo to przedział <0..3> ) ;) i była zwyczajną listą. Na 
pewnym etapie tych wartości skokowo przybyło i żeby się nie gubić co 
jest gdzie, podjęto decyzję że zamiast listy będzie słownik. Wykonano 
mały refactoring.
Gdzieś była funkcja, która musiała przejechać się po wartościach z 
otrzymanej struktury. Pierwotnie iterowała po liście, teraz iterowała po 
values() ze słownika. Testy odpalone i było git.

Po jakimś czasie zanotowano pad. Co się okazało? W innym miejscu była 
sobie zapomniana funkcja generująca w pewnych (rzadkich) przypadkach 
defaulty dla struktury. I ona dalej generowała listę. Ta funkcja też 
była pokryta testem, ale był to inny zestaw testów i też przez 
zapomnienie nie został przerobiony. I dla niego poprawnym wynikiem była 
wygenerowana lista, a nie dict. :(

Banalny błąd. Powiesz że coś takiego nie powinno się zdarzać.  Ale 
niestety czasami się zdarza.




> Są też asercje. Można kontrolować interfejsy w runtime'ie itp.

Kontrolowanie w runtime ma tę wadę, że odbywa się w runtime ;).
Dla usera jest w zasadzie obojętne, czy dostanie kawał traceback-a, czy 
okienko dialogowe z informacją "Funkcja foo_shmoo_bar_extended otrzymała 
nieprawidłowy parametr wywołania: powinien być <type 'dict'>, jest <type 
'list'>".
Ważne że program nie bangla.


>
> Chodzi mi o to, że w praktyce nie zauważyłem, aby statyczne
> typy pomagały. Wręcz przeciwnie, muszę się narzeźbić jak debil,
> aby zadowolić kompilator,

Ja nie neguję, że w pythonie pisze się łatwiej i szybciej. I przyjemniej ;)
Za to przy refactoringu bywa na odwrót.



> Natomiast często słyszę jak to w Pythonie można zrobić głupią literówkę
> i szukać naście dni. To jest kompletna bzdura i z tym walczę.

Pewnie że bzdura. Niemniej w pythonie _można_ zrobić literówkę i przy 
dużym braku szczęścia objawi się na produkcji.

Pzdr
J.

W dniu 2011-05-15 19:08, Rob Wolfe pisze:
> Jak wybierzesz implementacje Pythona na JVM (Jython) lub CLR
> (IronPython), to wówczas Python jest _kompilowany_ do byte codu
> tychże maszyn wirtualnych, a że owe maszyny posiadają JIT,
> to także _kompilowany_ do kodu natywnego.

> W przypadku CPythona łatwość usuwania wąskich gardeł przy pomocy
> rozszerzeń w C daje spore możliwości. Dobrym przykładem wydajności
> jest np. Mercurial (http://mercurial.selenic.com/).

Ja ściągnąłem pythona z www.python.org - według tego co napisane w 
podręczniku "Zanurkuj w Pythonie", czy to jest CPython. Rozszerzania w C 
to dobra sprawa.
Czy jest jakiś debugger do Pythona?

On 19 Maj, 22:27, Borneq <bor...@antyspam.hidden.pl> wrote:
> W dniu 2011-05-15 19:08, Rob Wolfe pisze:
>
> > Jak wybierzesz implementacje Pythona na JVM (Jython) lub CLR
> > (IronPython), to wówczas Python jest _kompilowany_ do byte codu
> > tychże maszyn wirtualnych, a że owe maszyny posiadają JIT,
> > to także _kompilowany_ do kodu natywnego.
> > W przypadku CPythona łatwość usuwania wąskich gardeł przy pomocy
> > rozszerzeń w C daje spore możliwości. Dobrym przykładem wydajności
> > jest np. Mercurial (http://mercurial.selenic.com/).
>
> Ja ściągnąłem pythona zwww.python.org- według tego co napisane w
> podręczniku "Zanurkuj w Pythonie", czy to jest CPython. Rozszerzania w C
> to dobra sprawa.
> Czy jest jakiś debugger do Pythona?

Np. http://docs.python.org/library/pdb.html?highlight=debuger

Większość edytorów/środowisk ma wsparcie do debugowania - ja używam
wing.
BTW: Ale tak szczerze to mógłbyś bardziej zgłębić zasoby www.python.org
- tam jest wszystko, a nawet więcej :P
Dobre miejsce do startu: http://wiki.python.org/moin/BeginnersGuide.

Pzdr.

On Sat, 21 May 2011 18:41:00 +0000 (UTC)
"Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> wrote:

> Idiom w programowaniu to wyrażenie (lub krótka konstrukcja w języku
> programowania) mające znaczenie tylko w danym języku, na ogół trudne do
> przełożenia na inny język za pomocą jednej instrukcji. Na przykład
> idiomem w Pythonie jest konstruowanie tablicy za pomocą
> "[?? for x in ??]", co się w Perlu przekłada jako "map { ?? } ??".

To "coś" nazywa się list comprehension i jest konstrukcją języka,
natomiast to co wołasz z Perla to funkcja, która istnieje również w
Pythonie. List comprehension to nic innego jak tworzenie listy w pętli:

result = []
for i in ??:
    result.append(i)

bez konieczności wywoływania funkcji/bloku na każdym elemencie. Nie
bardzo więc pasuje tu definicja idiomu. To raczej lukier składniowy.

> W przypadku programowania, większość kodu to instrukcje warunkowe,
> pętle, wywołania funkcji, ewentualnie definicje klas lub innych typów.
> Idiomy pojawiają się dość rzadko i zwykle dają się przełożyć na krótkie
> konstrukcje w innym języku, o ile język docelowy reprezentuje podobny
> paradygmat programowania (np. [?? for x in ??] wymaga dużo kodu
> w C (inny paradygmat), ale w Perlu to już wywołanie jednej funkcji
> wbudowanej).

Fajowo. Szkoda, że nie podałeś jak to się ma do statycznie typowanego
języka, jakim jest C, a zamiast tego sięgnąłeś po dynamicznie
typowanego Perla :)

> Biorąc pod uwagę że program składa się tylko w małej części z idiomów,
> a w dużej części z pozostałych, typowych dla danego paradygmatu
> instrukcji, oraz że idiomy się tłumaczy raczej na krótkie sekwencje,
> program w Perlu i taki sam w Pythonie będą miały podobną długość.

I różną czytelność.

> Tak więc zwięzłość składni, która wyraża się właśnie obecnością idiomów,
> nie przekłada się specjalnie na długość kodu.

W tym cały urok Pythona. Nie dość, że kod w nim pisany jest
stosunkowo zwięzły, to na dodatek franca jest czytelniejsza niż
niejeden inny podobnego typu język.

Po tej całej dyskusji odnoszę wrażenie, że nie miałeś za dużo do
czynienia z Pythonem.

-- 
      -^-  _        coś tam w tle sobie gra, np:
   _ /O)_\//        Bush - Synapse
  (_(|__(_(_) grf.  

On 2011-05-22, Roman Dobosz <gryf_esm-no@spam-o2.pl> wrote:
> On Sat, 21 May 2011 18:41:00 +0000 (UTC)
> "Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> wrote:
>
>> Idiom w programowaniu to wyrażenie (lub krótka konstrukcja w języku
>> programowania) mające znaczenie tylko w danym języku, na ogół trudne do
>> przełożenia na inny język za pomocą jednej instrukcji. Na przykład
>> idiomem w Pythonie jest konstruowanie tablicy za pomocą
>> "[?? for x in ??]", co się w Perlu przekłada jako "map { ?? } ??".
>
> To "coś" nazywa się list comprehension i jest konstrukcją języka,
> natomiast to co wołasz z Perla to funkcja, która istnieje również w
> Pythonie.

Ależ oczywiście. I użycie tej konstrukcji jest w Pythonie idiomem, który
w Perlu wyraża się nieco inną konstrukcją programistyczną. Dokładnie to
chciałem pokazać: że da się przetłumaczyć, że podobna długość i że inny
typ konstrukcji.

> List comprehension to nic innego jak tworzenie listy w pętli:
>
> result = []
> for i in ??:
>     result.append(i)
>
> bez konieczności wywoływania funkcji/bloku na każdym elemencie. Nie
> bardzo więc pasuje tu definicja idiomu. To raczej lukier składniowy.

Erm. Idiomem jest między innymi taki właśnie lukier.

>> W przypadku programowania, większość kodu to instrukcje warunkowe,
>> pętle, wywołania funkcji, ewentualnie definicje klas lub innych typów.
>> Idiomy pojawiają się dość rzadko i zwykle dają się przełożyć na krótkie
>> konstrukcje w innym języku, o ile język docelowy reprezentuje podobny
>> paradygmat programowania (np. [?? for x in ??] wymaga dużo kodu
>> w C (inny paradygmat), ale w Perlu to już wywołanie jednej funkcji
>> wbudowanej).
>
> Fajowo. Szkoda, że nie podałeś jak to się ma do statycznie typowanego
> języka, jakim jest C, a zamiast tego sięgnąłeś po dynamicznie
> typowanego Perla :)

Fajowo, tylko że C reprezentuje trochę inny paradygmat programowania,
jeśli nie zauważyłeś.

>> Biorąc pod uwagę że program składa się tylko w małej części z idiomów,
>> a w dużej części z pozostałych, typowych dla danego paradygmatu
>> instrukcji, oraz że idiomy się tłumaczy raczej na krótkie sekwencje,
>> program w Perlu i taki sam w Pythonie będą miały podobną długość.
>
> I różną czytelność.

Zależy kto pisze. Widziałem kod w Pythonie mniej czytelny od kodu
w Perlu.

>> Tak więc zwięzłość składni, która wyraża się właśnie obecnością idiomów,
>> nie przekłada się specjalnie na długość kodu.
>
> W tym cały urok Pythona. Nie dość, że kod w nim pisany jest
> stosunkowo zwięzły, to na dodatek franca jest czytelniejsza niż
> niejeden inny podobnego typu język.

#define "podobnego typu"

> Po tej całej dyskusji odnoszę wrażenie, że nie miałeś za dużo do
> czynienia z Pythonem.

A ja po twojej wypowiedzi, że ty nie miałeś za dużo do czynienia
z czymkolwiek innym.

-- 
Secunia non olet.
Stanislaw Klekot

On 2011-05-22, jacek2v <jacek2v@gmail.com> wrote:
> On 21 Maj, 20:41, "Stachu 'Dozzie' K."
><doz...@go.eat.some.screws.spammer.invalid> wrote:
>
>> Eeee... Że co? Co ma siła typowania do statyczności typowania?
>
> "Siła" to inaczej mówiąc, że lepiej jak jest typowanie niż jak go
> niema.

Eeee... Nie? C ma słabsze typowanie niż C++, od którego silniejsze
typowanie ma Haskell.

>> Parse error, znaczy błąd składni. Teraz widzę nawet jaki. Proponuję
>> używać więcej znaków interpunkcyjnych.
>
> Aha :) Zapomniałeś włączyć w kompilatorze logikę rozmytą? :)

Nie. Ty zapomniałeś użyć prawidłowo interpunkcji.

>> Eeee... Nie? A dostajesz w zamian kontrolę typów. Proponuję przyjrzeć
>> się dowolnemu programowi dowolnego języka ze statycznym typowaniem
>> i policzyć, ile kodu, tak na literki, jest przeznaczone na deklaracje
>> typów.
>
> Liczyłem. Jak Twoje wyniki? Wg moich sporo więcej :P

To twój program składał się chyba wyłącznie z deklaracji. U mnie nie
wychodzi nawet 10% kodu.

>> Tam, gdzie wymagania niezawodnościowe są dużo wyższe, to akurat się unika
>> testowania, zastępując je formalną automatyczną weryfikacją. Testy nie
>> są tak niezawodne jak próbujesz przedstawiać, nie dają gwarancji
>> poprawności programu. Zautomatyzowana weryfikacja (przy której
>> weryfikacja typów to tylko preludium do wstępu) za to daje.
>
> A co to "formalną automatyczną weryfikacją"?

Proponuję poszukać w takim razie materiałów.

> Nie uważam, że testy dają 100% niezawodności, ale dają (znacznie
> wyższy poziom niezawodności) vs. (włożony nakład pracy na ich
> przygotowanie) niż (typowanie) vs. (włożony nakład pracy na pisanie
> kodu).

To może tak wyglądać w małych projektach, gdzie jesteś w stanie
naprodukować i utrzymywać testy dla mniej więcej większości kodu.
W większych projektach przy refaktoryzacji okazuje się że system typów
przynajmniej pokazuje, gdzie jeszcze trzeba poprawić kod, co jest IMO
bardzo dużym zyskiem (tym większym, im większy projekt), a uzupełnienie
kodu o deklaracje typów nie zwiększa jakoś specjalnie jego długości.

>> > Sugerujesz, że oddajesz aplikację nawet jej nie przeklikawszy?
>>
>> Nie. Ale może się zdarzyć że testy, które przygotowałeś, nie pokryją
>> wszystkich możliwych sytuacji. Kompilator jest za to dokładniejszy.
>
> I na pewno się tak zdarzy, gwarantuję :) Użytkownicy są
> nieobliczalni :D

Nie chodzi o to jak obliczalni są użytkownicy, tylko czy ty jesteś
w stanie pokryć testami wszystkie możliwe ścieżki wykonania. Nie jesteś.

> A kompilator jest i Python :) Zapewne miałeś na myśli, że kompilator
> sprawdzi typy, ale jak już mówiłem, moim zdaniem złudne to poczucie
> sprawdzenia. A ja wolę nie mieć złudzeń :)

To po co testujesz? To ci daje złudne poczucie że twój program działa.
A to co kompilator w statycznie typowanym języku sprawdzi, to jest
prawdziwe sprawdzenie. Niewystarczające do uznania kodu za prawidłowy (o
czym wie każdy piszący w językach statycznie typowanych), ale prawdziwe.

>> >> A i tak mogą się prześlizgnąć błędy w rzadko używanych formularzach,
>> >> o których nikt nie pamięta i co do których nikt nie pomyślał żeby
>> >> napisać testy. A automat (kompilator) by po prostu sprawdził poprawność
>> >> *wszędzie*.
>>
>> > Ale i tak kompilator nie wyłapie znacznej większości błędów, a
>> > świadomość, że trzeba testować jest lepsza niż życie w błędnym
>> > przekonaniu, że coś samo się sprawdzi i będzie ok.
>>
>> Ależ świadomość nadal jest. Weryfikacja typu nie wychwyci błędu
>> logicznego. Za to wychwyci dużo typowych błędów, co już samo w sobie
>> pomaga.
>
> Weryfikacja typu wychwyci jedynie błąd typu i nic więcej.
> Moja praktyka jest taka, że zawsze błąd typu jest wykrywany po
> pierwszym uruchomieniu poprawianego kodu.

To chyba w jakichś malutkich projektach. Gdy program robi się duży,
z jednej funkcji którą zmieniasz może korzystać fafnaście innych
modułów. Potem weź szukaj tych modułów i przekopuj się przez kod, żeby
ujednolicić typ danych, na którym ten kod operuje.

> I tak każdy moduł/funkcja/
> metoda przez programistę jest dziesiątki (jeśli nie setki razy)
> uruchomiany/debugowany. Trzeba sobie uświadomić, że kod jest pisany po
> to by był uruchomiony. Nie wyobrażam sobie by programista zrobi commit
> kodu nie uruchomiwszy go, zakładając, że pisze nieomylnie.

Nie wyobrażam sobie żeby programista był w stanie sprawdzić dokładnie
cały duży projekt, wszystkie wywoływane w nim funkcje.

> Żeby uprzedzić argumenty o zmiennych warunkach wykonania i że ścieżka
> wykonania jest niedeterministyczna, chciałby zwrócić Twoją uwagę, że
> Python nie jest językiem "nie typowanym" jest językiem "dynamicznie
> typowanym", czyli typowanie ma, tylko nie jest ono podawane explicite.

Bzdurzysz, chłopcze. To powinno brzmieć: "Python [...] jest językiem
"dynamicznie typowanym", czyli typowanie ma, tylko jest ono sprawdzane
dopiero przy uruchomieniu". Nie podawane exlicite typy to są w SML-u,
a mimo to język jest statycznie i silnie typowany.

>> Ty zacząłeś. Ja tylko pociągnąłem twoją ścieżkę dalej, żeby pokazać do
>> czego prowadzi i że to nic dobrego.
>
> Będę się upierał, że Ty zacząłeś :), na potwierdzenie przytaczam cytat
> z Twojej wypowiedzi: "Ekstrapolując twoje proponowane podejście "jeden
> ruch mniej", może darujmy sobie testowanie aplikacji?"
> Twoja "ekstrapolacja"  była nadinterpretacją mojej wypowiedzi.

Nie. Była rozszerzeniem twojego rozumowania: "usuńmy kolejny element
który kosztuje".

>> > A jak zmienisz klasę na niższą lub wyższą w ścieżce dziedziczenia, to
>> > też się zorientuje - zwłaszcza, że bardzo często używa się
>> > rzutowania?
>>
>> Zależy czy ta wyższa czy niższa jest niezbędna, czy też nie. W ogóle nie
>> rozumiem pytania i problemu, który byś chciał pokazać. Please elaborate.
>
> class c1{
>    public int m1(int a) {
>        a = a + 1;
>        return(a);
>    }
> }
> class c2 extends c1{
>    public int m1(int a) {
>        a = a + 2;
>        return(a);
>    }
> }
> public class jsimple{
>     public static void main (String[] args) {
> 	c1 o1 = new c2();
> 	System.out.println (o1.m1(3));
>     }
> }
> result: 5
>
> I co z tego, że typ c1? :(

Chłopcze, a może tak byś doczytał o polimorfizmie dynamicznym zamiast
pokazywać nieistniejące problemy? W Javie wiadomo od zawsze, że
adresy wszystkich metod są rozwiązywane at runtime. Inaczej w C++, gdzie
musisz powiedzieć jawnie, które metody są rozwiązywane podczas
kompilacji.

Nawiasem mówiąc, jak ktoś piszący w Pythonie może nie umieć utrzymać
jednolitego systemu wcinania kodu i miesza spacje z tabulatorami? O_o

>> Tak więc zwięzłość składni, która wyraża się właśnie obecnością idiomów,
>> nie przekłada się specjalnie na długość kodu.
>> Powiem ci że parę lat temu też uważałem że ilość idiomów pozytywnie
>> wpływa na ilość kodu i jego konserwowalność, ale z doświadczeniem się
>> z tego przekonania wyrasta.
>
> Zajrzyj na shootout.alioth.debian.org, przekonasz się jak to się
> przekłada na ilość kodu w rzeczywistości. Strona ta zawiera porównanie
> programów (szybkość, zużycie pamięci, ilość linii kodu) rozwiązujących
> ten same problemy w różnych językach programowania. W tej chwili coś
> nie działa ta strona - może jakieś prace trwają i nie mogę przytoczyć
> konkretnego przykładu :). Ale jeśli dobrze pamiętam to wielkość kodu
> java vs python oscyluje między 5:1 do 10:1. Oczywiście nie tylko
> "idiomy" zmniejszają ilość kodu w python. Jest jeszcze brak nawiasów,
> typowania explicite, krótka notacja - chyba wszystko wymieniłem.

Tylko to wszystko są fistaszki. Rzeczy istotne dla skrócenia kodu, to:
  * dobrze przemyślane API bibliotek (w tym: biblioteki standardowej)
  * konstrukcje nieprzekładalne na języki innego paradygmatu (słyszał
    o domknięciach?)
  * zwyczaje programistyczne różnych środowisk (javistów, pythonistów
    itd.)

-- 
Secunia non olet.
Stanislaw Klekot

On Mon, 23 May 2011 08:53:02 +0000 (UTC)
"Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> wrote:

> >> program w Perlu i taki sam w Pythonie będą miały podobną długość.
> > I różną czytelność.
> Zależy kto pisze. Widziałem kod w Pythonie mniej czytelny od kodu
> w Perlu.

Jasne. Niemniej jednak kod w Pythonie *z reguły* jest czytelniejszy
niż *typowy* kod w Perlu.

> >> Tak więc zwięzłość składni, która wyraża się właśnie obecnością idiomów,
> >> nie przekłada się specjalnie na długość kodu.
> > W tym cały urok Pythona. Nie dość, że kod w nim pisany jest
> > stosunkowo zwięzły, to na dodatek franca jest czytelniejsza niż
> > niejeden inny podobnego typu język.
> #define "podobnego typu"

Interpretowany, obiektowy, dynamicznie typowany. Np. Python, Perl,
Ruby.

> > Po tej całej dyskusji odnoszę wrażenie, że nie miałeś za dużo do
> > czynienia z Pythonem.
> A ja po twojej wypowiedzi, że ty nie miałeś za dużo do czynienia
> z czymkolwiek innym.

Czyli zgadłem.

-- 
      -^-  _ 
   _ /O)_\// 
  (_(|__(_(_) grf.

On 2011-05-23, Roman Dobosz <gryf_esm-no@spam-o2.pl> wrote:
> On Mon, 23 May 2011 08:53:02 +0000 (UTC)
> "Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> wrote:
>
>> >> program w Perlu i taki sam w Pythonie będą miały podobną długość.
>> > I różną czytelność.
>> Zależy kto pisze. Widziałem kod w Pythonie mniej czytelny od kodu
>> w Perlu.
>
> Jasne. Niemniej jednak kod w Pythonie *z reguły* jest czytelniejszy
> niż *typowy* kod w Perlu.

Czy też raczej: typowy autor kodu w Pythonie pisze kod czytelniejszy niż
typowy autor kodu w Perlu. W większej części dlatego, że w Perlu często
piszą ludzie nie umiejący pisać w Perlu (czy programować w ogóle), choć
uważają inaczej.

>> >> Tak więc zwięzłość składni, która wyraża się właśnie obecnością idiomów,
>> >> nie przekłada się specjalnie na długość kodu.
>> > W tym cały urok Pythona. Nie dość, że kod w nim pisany jest
>> > stosunkowo zwięzły, to na dodatek franca jest czytelniejsza niż
>> > niejeden inny podobnego typu język.
>> #define "podobnego typu"
>
> Interpretowany, obiektowy, dynamicznie typowany. Np. Python, Perl,
> Ruby.

Żeby Python miał być czytelniejszy od Rubyego? Pierwsze słyszę.

>> > Po tej całej dyskusji odnoszę wrażenie, że nie miałeś za dużo do
>> > czynienia z Pythonem.
>> A ja po twojej wypowiedzi, że ty nie miałeś za dużo do czynienia
>> z czymkolwiek innym.
>
> Czyli zgadłem.

Not much.

-- 
Secunia non olet.
Stanislaw Klekot

On Mon, 23 May 2011 14:25:57 +0000 (UTC)
"Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> wrote:

> > Jasne. Niemniej jednak kod w Pythonie *z reguły* jest czytelniejszy
> > niż *typowy* kod w Perlu.
> Czy też raczej: typowy autor kodu w Pythonie pisze kod czytelniejszy niż
> typowy autor kodu w Perlu. W większej części dlatego, że w Perlu często
> piszą ludzie nie umiejący pisać w Perlu (czy programować w ogóle), choć
> uważają inaczej.

To też, ale sama składnia Perla nie zachęca do brnięcia w małpy,
nawiasy, średniki, dolary, strzałki złożone z '-' i '>' czy
podkreślniki.

> >> #define "podobnego typu"
> > Interpretowany, obiektowy, dynamicznie typowany. Np. Python, Perl,
> > Ruby.
> Żeby Python miał być czytelniejszy od Rubyego? Pierwsze słyszę.

O rany. De gustibus non est disputandum. Dla mnie kod napisany w
Rubym jest mniej czytelny niż w Pythonie. Ok?

> >> > Po tej całej dyskusji odnoszę wrażenie, że nie miałeś za dużo do
> >> > czynienia z Pythonem.
> >> A ja po twojej wypowiedzi, że ty nie miałeś za dużo do czynienia
> >> z czymkolwiek innym.
> > Czyli zgadłem.
> Not much.

Oh really. Pisałeś coś o projekcie z 30kloc w języku dynamicznie
typowanym. To niekoniecznie jest duży projekt.

-- 
      -^-  _
   _ /O)_\//
  (_(|__(_(_) grf.

On 23 Maj, 10:53, "Stachu 'Dozzie' K."
<doz...@go.eat.some.screws.spammer.invalid> wrote:
> > "Siła" to inaczej mówiąc, że lepiej jak jest typowanie niż jak go
> > niema.
>
> Eeee... Nie? C ma słabsze typowanie niż C++, od którego silniejsze
> typowanie ma Haskell.

Nie, last one tłumaczę :)  Mówię o sytuacji: typowanie JEST albo NIE
MA.

> Nie. Ty zapomniałeś użyć prawidłowo interpunkcji.

Brakuje argumentów? Nie jest moim celem zmienianie Twojego poglądu,
chciałem tylko porozmawiać, aby też samemu mieć szerszy pogląd. Jak
Cię to obraża, nudzi, wkur... albo co innego mniej przyjemnego to daj
znać to skończymy - po co się przerzucać prztyczkami? Ani mnie to
bawi, ani nic dobrego mi, albo Tobie przyniesie.

> To twój program składał się chyba wyłącznie z deklaracji. U mnie nie
> wychodzi nawet 10% kodu.

Mhh, versus 0% w Python to sporo. Przy 10 000 linii to 1000 linii
kontra 0 linii :)

> > A co to "formalną automatyczną weryfikacją"?
>
> Proponuję poszukać w takim razie materiałów.

Miłe:)

> > Nie uważam, że testy dają 100% niezawodności, ale dają (znacznie
> > wyższy poziom niezawodności) vs. (włożony nakład pracy na ich
> > przygotowanie) niż (typowanie) vs. (włożony nakład pracy na pisanie
> > kodu).
>
> To może tak wyglądać w małych projektach, gdzie jesteś w stanie
> naprodukować i utrzymywać testy dla mniej więcej większości kodu.
> W większych projektach przy refaktoryzacji okazuje się że system typów
> przynajmniej pokazuje, gdzie jeszcze trzeba poprawić kod, co jest IMO
> bardzo dużym zyskiem (tym większym, im większy projekt), a uzupełnienie
> kodu o deklaracje typów nie zwiększa jakoś specjalnie jego długości.

Może są takie Twoje doświadczenia, moje są takie, że daje "złudne
poczucie poprawności".

> To chyba w jakichś malutkich projektach. Gdy program robi się duży,
> z jednej funkcji którą zmieniasz może korzystać fafnaście innych
> modułów. Potem weź szukaj tych modułów i przekopuj się przez kod, żeby
> ujednolicić typ danych, na którym ten kod operuje.

Może nie stosujesz unit testów?

> > I tak każdy moduł/funkcja/
> > metoda przez programistę jest dziesiątki (jeśli nie setki razy)
> > uruchomiany/debugowany. Trzeba sobie uświadomić, że kod jest pisany po
> > to by był uruchomiony. Nie wyobrażam sobie by programista zrobi commit
> > kodu nie uruchomiwszy go, zakładając, że pisze nieomylnie.
>
> Nie wyobrażam sobie żeby programista był w stanie sprawdzić dokładnie
> cały duży projekt, wszystkie wywoływane w nim funkcje.

A co ma jedno do drugiego? Widocznie masz inne podejście do pisania
programów  niż ja. Ja uważam, że interfejsy powinny się nie zmieniać,
a jak już musimy je zmienić to z bardzo dużą uwagą - "wolna
amerykanka" jest przeważnie zabójcza.

> Bzdurzysz, chłopcze. To powinno brzmieć: "Python [...] jest językiem
> "dynamicznie typowanym", czyli typowanie ma, tylko jest ono sprawdzane
> dopiero przy uruchomieniu". Nie podawane exlicite typy to są w SML-u,
> a mimo to język jest statycznie i silnie typowany.

O co Ci chodzi, chcesz rozmawiać merytorycznie, czy próbować łapać za
słóweczka. Wspominałeś o C++, a co tu ma do tego SML?

> Chłopcze, a może tak byś doczytał o polimorfizmie dynamicznym zamiast
> pokazywać nieistniejące problemy? W Javie wiadomo od zawsze, że
> adresy wszystkich metod są rozwiązywane at runtime. Inaczej w C++, gdzie
> musisz powiedzieć jawnie, które metody są rozwiązywane podczas
> kompilacji.

Chłopcze, chciałeś dowodu i go dostałeś. Nie płacz teraz, że to
wszyscy wiedzieli, jak wcześniej nie potrafiłeś tego zrozumieć.
Trzymaj fason :)
Jest typowanie i nic nie daje.

> Nawiasem mówiąc, jak ktoś piszący w Pythonie może nie umieć utrzymać
> jednolitego systemu wcinania kodu i miesza spacje z tabulatorami? O_o

No args ?

> > Zajrzyj na shootout.alioth.debian.org, przekonasz się jak to się
> > przekłada na ilość kodu w rzeczywistości. Strona ta zawiera porównanie
> > programów (szybkość, zużycie pamięci, ilość linii kodu) rozwiązujących
> > ten same problemy w różnych językach programowania. W tej chwili coś
> > nie działa ta strona - może jakieś prace trwają i nie mogę przytoczyć
> > konkretnego przykładu :). Ale jeśli dobrze pamiętam to wielkość kodu
> > java vs python oscyluje między 5:1 do 10:1. Oczywiście nie tylko
> > "idiomy" zmniejszają ilość kodu w python. Jest jeszcze brak nawiasów,
> > typowania explicite, krótka notacja - chyba wszystko wymieniłem.
>
> Tylko to wszystko są fistaszki. Rzeczy istotne dla skrócenia kodu, to:
>   * dobrze przemyślane API bibliotek (w tym: biblioteki standardowej)
>   * konstrukcje nieprzekładalne na języki innego paradygmatu (słyszał
>     o domknięciach?)
>   * zwyczaje programistyczne różnych środowisk (javistów, pythonistów
>     itd.)

Hehehe.

Mr Stach, albo "chłopcze" jak wolisz, sam sprowadziłeś dyskusję do
tego poziomu. Jak już chyba ktoś kiedyś wspomniał, nastała następująca
sytuacja: okopaliśmy się i d. z okopów nie ruszymy :). Starałem się
zrozumieć Twój punkt widzenia. Starałem się osiągnąć jakiś
merytoryczny poziom dyskusji, ale się nie udało. Pierd... za uszami
nie ma sensu. Zatem: EOT

Miłego Dnia
Jacek

On 2011-05-24, jacek2v <jacek2v@gmail.com> wrote:
> On 23 Maj, 10:53, "Stachu 'Dozzie' K."
><doz...@go.eat.some.screws.spammer.invalid> wrote:
>> > "Siła" to inaczej mówiąc, że lepiej jak jest typowanie niż jak go
>> > niema.
>>
>> Eeee... Nie? C ma słabsze typowanie niż C++, od którego silniejsze
>> typowanie ma Haskell.
>
> Nie, last one tłumaczę :)  Mówię o sytuacji: typowanie JEST albo NIE
> MA.

To nie używaj pojęć słabe/silne typowanie, kiedy o tym mówisz, bo
wprowadzasz niejasności.

>> To twój program składał się chyba wyłącznie z deklaracji. U mnie nie
>> wychodzi nawet 10% kodu.
>
> Mhh, versus 0% w Python to sporo. Przy 10 000 linii to 1000 linii
> kontra 0 linii :)

Przy 10k linii 1000 linii to niedużo, zwłaszcza że pozwala na dodatkowe
sprawdzenie programu i powoduje, że pierwsze uruchomienie kontrolne nie
służy do znalezienia miejsca, gdzie nadal używasz krotki, podczas gdy
reszta kodu ma hasz, tylko zajmujesz się poważniejszymi błędami.

>> > Nie uważam, że testy dają 100% niezawodności, ale dają (znacznie
>> > wyższy poziom niezawodności) vs. (włożony nakład pracy na ich
>> > przygotowanie) niż (typowanie) vs. (włożony nakład pracy na pisanie
>> > kodu).
>>
>> To może tak wyglądać w małych projektach, gdzie jesteś w stanie
>> naprodukować i utrzymywać testy dla mniej więcej większości kodu.
>> W większych projektach przy refaktoryzacji okazuje się że system typów
>> przynajmniej pokazuje, gdzie jeszcze trzeba poprawić kod, co jest IMO
>> bardzo dużym zyskiem (tym większym, im większy projekt), a uzupełnienie
>> kodu o deklaracje typów nie zwiększa jakoś specjalnie jego długości.
>
> Może są takie Twoje doświadczenia, moje są takie, że daje "złudne
> poczucie poprawności".

Może dlatego tak odbierałeś system typów, że nie wiedziałeś wcześniej
jak go traktować. To teraz będziesz wiedział: jako pierwszą,
zautomatyzowaną, statyczną weryfikację, która jeszcze nie mówi że
program jest poprawny (a jedynie wcześnie odfiltruje programy, które
poprawne nie są i których nie ma sensu uruchamiać przed poprawieniem).

>> To chyba w jakichś malutkich projektach. Gdy program robi się duży,
>> z jednej funkcji którą zmieniasz może korzystać fafnaście innych
>> modułów. Potem weź szukaj tych modułów i przekopuj się przez kod, żeby
>> ujednolicić typ danych, na którym ten kod operuje.
>
> Może nie stosujesz unit testów?

Może nie pokryjesz stu procent kodu testami jednostkowymi? A może nawet
jeśli pokryjesz, to nie pokryjesz stu procent ścieżek programu?

>> > I tak każdy moduł/funkcja/
>> > metoda przez programistę jest dziesiątki (jeśli nie setki razy)
>> > uruchomiany/debugowany. Trzeba sobie uświadomić, że kod jest pisany po
>> > to by był uruchomiony. Nie wyobrażam sobie by programista zrobi commit
>> > kodu nie uruchomiwszy go, zakładając, że pisze nieomylnie.
>>
>> Nie wyobrażam sobie żeby programista był w stanie sprawdzić dokładnie
>> cały duży projekt, wszystkie wywoływane w nim funkcje.
>
> A co ma jedno do drugiego? Widocznie masz inne podejście do pisania
> programów  niż ja. Ja uważam, że interfejsy powinny się nie zmieniać,

Powinny. Co nie znaczy że nie mogą. I to nie znaczy również że nie będą
(a raczej właśnie będą, bo nie przewidzisz wszystkiego, tylko że
rzadziej niż reszta kodu).

> a jak już musimy je zmienić to z bardzo dużą uwagą - "wolna
> amerykanka" jest przeważnie zabójcza.

O widzisz! Brawo misiu! I tu właśnie przydaje się system typów. Przy
zmianie interfejsu system typów odciąża programistę.

>> Bzdurzysz, chłopcze. To powinno brzmieć: "Python [...] jest językiem
>> "dynamicznie typowanym", czyli typowanie ma, tylko jest ono sprawdzane
>> dopiero przy uruchomieniu". Nie podawane exlicite typy to są w SML-u,
>> a mimo to język jest statycznie i silnie typowany.
>
> O co Ci chodzi, chcesz rozmawiać merytorycznie, czy próbować łapać za
> słóweczka. Wspominałeś o C++, a co tu ma do tego SML?

To ty wciągnąłeś "typ nie podawany explicite" do dyskusji. Ja podałem
przykład języka typowanego statycznie (i z silnym systemem typów),
w którym nie podajesz typu przy wprowadzania zmiennej.

>> Chłopcze, a może tak byś doczytał o polimorfizmie dynamicznym zamiast
>> pokazywać nieistniejące problemy? W Javie wiadomo od zawsze, że
>> adresy wszystkich metod są rozwiązywane at runtime. Inaczej w C++, gdzie
>> musisz powiedzieć jawnie, które metody są rozwiązywane podczas
>> kompilacji.
>
> Chłopcze, chciałeś dowodu i go dostałeś. Nie płacz teraz, że to
> wszyscy wiedzieli, jak wcześniej nie potrafiłeś tego zrozumieć.

Twoim zdaniem to był jakiś problem z typowaniem statycznym. To
nieprawda, bo a) to nie jest problem, b) to nie dotyczy typowania
statycznego, tylko stosowanego w Javie mechanizmu odpowiadającego
metodom wirtualnym z C++ (czyli dynamic binding).

> Trzymaj fason :)
> Jest typowanie i nic nie daje.

Owszem, daje, i to całkiem sporo. A sytuacja analogiczna do tego, co
pokazałeś w swoim przykładzie, zdarza się bardzo rzadko.

>> Nawiasem mówiąc, jak ktoś piszący w Pythonie może nie umieć utrzymać
>> jednolitego systemu wcinania kodu i miesza spacje z tabulatorami? O_o
>
> No args ?

Nie. Spostrzeżenie, że mój rozmówca nie tylko ma problemy
z interpunkcją (przez co momentami trudno zrozumieć co pisze), ale
również z używaniem wiedzy teoretycznie nabytej podczas pisania
w Pythonie.

>> > Zajrzyj na shootout.alioth.debian.org, przekonasz się jak to się
>> > przekłada na ilość kodu w rzeczywistości. Strona ta zawiera porównanie
>> > programów (szybkość, zużycie pamięci, ilość linii kodu) rozwiązujących
>> > ten same problemy w różnych językach programowania. W tej chwili coś
>> > nie działa ta strona - może jakieś prace trwają i nie mogę przytoczyć
>> > konkretnego przykładu :). Ale jeśli dobrze pamiętam to wielkość kodu
>> > java vs python oscyluje między 5:1 do 10:1. Oczywiście nie tylko
>> > "idiomy" zmniejszają ilość kodu w python. Jest jeszcze brak nawiasów,
>> > typowania explicite, krótka notacja - chyba wszystko wymieniłem.
>>
>> Tylko to wszystko są fistaszki. Rzeczy istotne dla skrócenia kodu, to:
>>   * dobrze przemyślane API bibliotek (w tym: biblioteki standardowej)
>>   * konstrukcje nieprzekładalne na języki innego paradygmatu (słyszał
>>     o domknięciach?)
>>   * zwyczaje programistyczne różnych środowisk (javistów, pythonistów
>>     itd.)
>
> Hehehe.
>
> Mr Stach, albo "chłopcze" jak wolisz, sam sprowadziłeś dyskusję do
> tego poziomu. Jak już chyba ktoś kiedyś wspomniał, nastała następująca
> sytuacja: okopaliśmy się i d. z okopów nie ruszymy :).

Ano nie ruszymy. Podsumowałbym to tak: za typowaniem statycznym
przemawia wczesne odrzucenie kodu ewidentnie nieprawidłowego, za
dynamicznym skrócenie kodu o jakieś pomijalne wartości. I żaden z nas
nie chce uznać, że drugi ma rację.

> Starałem się
> zrozumieć Twój punkt widzenia. Starałem się osiągnąć jakiś
> merytoryczny poziom dyskusji, ale się nie udało.

Przykro mi że nie byłeś w stanie ze swojej strony osiągnąć odpowiedniego
technicznego poziomu, żeby prowadzić dyskusję.

> Pierd... za uszami
> nie ma sensu. Zatem: EOT

OK, EOT.

-- 
Secunia non olet.
Stanislaw Klekot

On 29 Maj, 10:00, jacek2v <jace...@gmail.com> wrote:
> On 29 Maj, 02:09, "Jordan Szubert" <use...@joru.us.to> wrote:
>
>
>
>
>
>
>
>
>
> > Dnia 28-05-2011 o 15:48:40 jacek2v <jace...@gmail.com> napisał(a):
>
> > > Ok. Twój dowód do mnie przemawia :) Aczkolwiek :) podejrzane jest :
> > > >>> issubclass(type(foo), type(object))
> > > False
>
> > Python 3.2 (r32:88445, Feb 20 2011, 21:30:00) [MSC v.1500 64 bit (AMD64)]  
> > on win32
> > Type "help", "copyright", "credits" or "license" for more information.>>> def foo():
>
> > ...     pass
> > ...
>
> > >>> type(foo)
> > <class 'function'>
> > >>> type(object)
> > <class 'type'>
> > >>> issubclass(type(foo),type(object))
> > False
> > >>> issubclass(type(foo),object)
> > True
> > >>> object
> > <class 'object'>
>
> > --
> > Jordan Szubert
>
> Ok. My fault :)

Ale...? :) - nigdy nie byłem fanem takiego drążenia języka prog., ale
jak już drążymy, to:
Python 2.7.1
>class Fooc(object):
>
>...     pass
>
> issubclass(type(Fooc), type(object))
>True
A przy funkcji było:
> False

Dnia 29-05-2011 o 12:20:01 jacek2v <jacek2v@gmail.com> napisał(a):

> On 29 Maj, 10:00, jacek2v <jace...@gmail.com> wrote:
>> On 29 Maj, 02:09, "Jordan Szubert" <use...@joru.us.to> wrote:
>>> Dnia 28-05-2011 o 15:48:40 jacek2v <jace...@gmail.com> napisał(a):
>>>> Ok. Twój dowód do mnie przemawia :) Aczkolwiek :) podejrzane jest :
>>>> >>> issubclass(type(foo), type(object))
>>>> False
>>>
>>> Python 3.2 (r32:88445, Feb 20 2011, 21:30:00) [MSC v.1500 64 bit  
>>> (AMD64)] on win32
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> def foo():
>>> ...     pass
>>> ...
>>> >>> type(foo)
>>> <class 'function'>
>>> >>> type(object)
>>> <class 'type'>
>>> >>> issubclass(type(foo),type(object))
>>> False
>>> >>> issubclass(type(foo),object)
>>> True
>>> >>> object
>>> <class 'object'>
>>>
>> Ok. My fault :)
>
> Ale...? :) - nigdy nie byłem fanem takiego drążenia języka prog., ale
> jak już drążymy, to:
> Python 2.7.1
>> class Fooc(object):
>>
>> ...     pass
>>
>> issubclass(type(Fooc), type(object))
>> True
> A przy funkcji było:
>> False

nadal wszystko OK, klasa jest klasa, funkcja nie jest klasa, a instancja  
klasy...
1,foo,object(),Fooc to nie klasy, a instancje...
klasy to object,type,type(foo),int,Fooc() etc.
oczywiście klasy tez są instancjami klasy type...

-- 
Jordan Szubert

On 29 Maj, 13:16, "Jordan Szubert" <use...@joru.us.to> wrote:
> >> issubclass(type(Fooc), type(object))
> >> True
> > A przy funkcji było:
> >> False
>
> nadal wszystko OK, klasa jest klasa, funkcja nie jest klasa, a instancja  
> klasy...
> 1,foo,object(),Fooc to nie klasy, a instancje...
> klasy to object,type,type(foo),int,Fooc() etc.
> oczywiście klasy tez są instancjami klasy type...

Ale z tego wynika, że dana funkcja nie jest instancją klasy, tylko
"nieklasy" (:)) funkcja. Inaczej mówiąc funkcja ma oddzielne drzewo
klas.
Nie wiem czy się nie zapętliłem :), późno już i takie dywagacje jakieś
jałowe się stają :). Ale dzięki za pomoc w rozplątywaniu, jak wypiję
trochę więcej piwa, to może to zrozumiem :)

Pzdr.

Dnia 30-05-2011 o 22:17:25 jacek2v <jacek2v@gmail.com> napisał(a):

> On 29 Maj, 13:16, "Jordan Szubert" <use...@joru.us.to> wrote:
>> >> issubclass(type(Fooc), type(object))
>> >> True
>> > A przy funkcji było:
>> >> False
>>
>> nadal wszystko OK, klasa jest klasa, funkcja nie jest klasa, a  
>> instancja klasy...
>> 1,foo,object(),Fooc to nie klasy, a instancje...
>> klasy to object,type,type(foo),int,Fooc() etc.
>> oczywiście klasy tez są instancjami klasy type...
>
> Ale z tego wynika, że dana funkcja nie jest instancją klasy, tylko
> "nieklasy" (:)) funkcja. Inaczej mówiąc funkcja ma oddzielne drzewo
> klas.

nie wynika, nie ma ani drzewa, ani oddzielnego...
>>> function=type(foo)
>>>
function to zwykła klasa dziedzicząca po object, podobnie jak int czy str,  
ale foo ani 1 ani "dupa" klasami ani trochę nie są, są jednie obiektami...
Fooc to klasa, ale jak zrobimy Fooc() to dostaniemy instancję, która klasa  
nie jest...
wiem, że często używa się błędnie określenia klasa na instancje, ale to  
błąd jest...

> Nie wiem czy się nie zapętliłem :), późno już i takie dywagacje jakieś
> jałowe się stają :). Ale dzięki za pomoc w rozplątywaniu, jak wypiję
> trochę więcej piwa, to może to zrozumiem :)

-- 
Jordan Szubert

On 31 Maj, 06:30, "Jordan Szubert" <use...@joru.us.to> wrote:
> Dnia 30-05-2011 o 22:17:25 jacek2v <jace...@gmail.com> napisał(a):
>
> > On 29 Maj, 13:16, "Jordan Szubert" <use...@joru.us.to> wrote:
> >> >> issubclass(type(Fooc), type(object))
> >> >> True
> >> > A przy funkcji było:
> >> >> False
>
> >> nadal wszystko OK, klasa jest klasa, funkcja nie jest klasa, a  
> >> instancja klasy...
> >> 1,foo,object(),Fooc to nie klasy, a instancje...
> >> klasy to object,type,type(foo),int,Fooc() etc.
> >> oczywiście klasy tez są instancjami klasy type...
>
> > Ale z tego wynika, że dana funkcja nie jest instancją klasy, tylko
> > "nieklasy" (:)) funkcja. Inaczej mówiąc funkcja ma oddzielne drzewo
> > klas.
>
> nie wynika, nie ma ani drzewa, ani oddzielnego...>>> function=type(foo)
>
> function to zwykła klasa dziedzicząca po object, podobnie jak int czy str,  
> ale foo ani 1 ani "dupa" klasami ani trochę nie są, są jednie obiektami...
> Fooc to klasa, ale jak zrobimy Fooc() to dostaniemy instancję, która klasa  
> nie jest...
> wiem, że często używa się błędnie określenia klasa na instancje, ale to  
> błąd jest...
>
> > Nie wiem czy się nie zapętliłem :), późno już i takie dywagacje jakieś
> > jałowe się stają :). Ale dzięki za pomoc w rozplątywaniu, jak wypiję
> > trochę więcej piwa, to może to zrozumiem :)

Ok. :) Proponuję EOT :)