🚀 go-pugleaf

W dniu 2011-05-14 21:35, Borneq pisze:
> Dopiero zamierzam zainteresować się pythonem. Jest on językiem
> interpretowanym czy kompilowanym? Jak z prędkością?

Oczywiście, że interpretowany! W dodatku z dynamicznym typowaniem. 
Prędkość... hm... tu nie o to chodzi! Tu chodzi o to, by napisać szybko, 
elegancko i odpalić, zająć się czymś innym i jak skończy cieszyć się 
wynikami. W takich zadaniach widzę ten język. Choć są tacy co takie 
języki wykorzystują do generowania stron html  w czasie rzeczywistym (ta 
praktyka nie jest gorsza od używania PHP, jednak obie są równie zboczone 
(w sęsie koncepcyjnym)). Zasadniczo wąskim gardłem tego typu języków 
jest to, że przed użyciem każdej zmiennej konieczne jest określenie jej 
typu (dynamiczne typowanie). Choć z drugiej strony to dynamiczne 
typowanie i automatyczne odśmiecanie pamięci to duża wygoda przy 
programowaniu.

W dniu 2011-05-14 22:29, Szyk pisze:

> Choć z drugiej strony to dynamiczne
> typowanie i automatyczne odśmiecanie pamięci to duża wygoda przy
> programowaniu.

W sztywno typowanym (choć z odśmiecaniem) języku robiłem upgrade o 
'duży' numer wersji sporego frameworku pod wielką moją aplikacją. Po 
usunięciu błędów kompilacji zostały DWA proste wyjątki na runtime i trzy 
moduły 100 linii w sposób oczywisty niskopoziomowe więc do koncepcyjnych 
ręcznych zmian.

Dynamiczne typowanie na pewno jest wygodne (i to bardzo) na etapie 
'pierwszego' pisania, ale refactoringu to horror.

Przychylam się do wizji i czasem ją realizuję: 'kernel' w sztywnym i 
skryptowanie funkcjonalności zmiennych czy dodatkowych w dynamicznym

PS. Z szacunkiem dla języka Python, to naprawdę przymyślany i świadomie 
projektowany język.

On 2011-05-15, Jacek Czerwinski <x@y.z.pl> wrote:
[...]
> PS. Z szacunkiem dla języka Python, to naprawdę przymyślany i świadomie 
> projektowany język.

Z wyjątkiem trójki, gdzie kretyńsko wsadzili wszędzie UTF-8 (np. gdy
argument wiersza poleceń nie jest UTF, to nawet nie masz jak chwycić
wyjątku).

-- 
Secunia non olet.
Stanislaw Klekot

Jacek Czerwinski <x@y.z.pl> writes:

> W dniu 2011-05-14 22:29, Szyk pisze:
>
>> Choć z drugiej strony to dynamiczne
>> typowanie i automatyczne odśmiecanie pamięci to duża wygoda przy
>> programowaniu.
>
> W sztywno typowanym (choć z odśmiecaniem) języku robiłem upgrade o
> duży' numer wersji sporego frameworku pod wielką moją aplikacją. Po
> usunięciu błędów kompilacji zostały DWA proste wyjątki na runtime i
> trzy moduły 100 linii w sposób oczywisty niskopoziomowe więc do
> koncepcyjnych ręcznych zmian.

Czy robiłeś coś podobnego z frameworkiem Pythonowym i napotkałeś jakieś
niesamowite problemy?

> Dynamiczne typowanie na pewno jest wygodne (i to bardzo) na etapie
> pierwszego' pisania, ale refactoringu to horror.

Działają mi na nerwy tego typu opinie. Brałem udział w refactoringu
róznych rzeczy w róznych językach, typowanych dynamicznie i statycznie
i nie zauważyłem, aby ten akurat element był tu jakoś specjalnie
istotny.
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.

>
> Przychylam się do wizji i czasem ją realizuję: 'kernel' w sztywnym i
> skryptowanie funkcjonalności zmiennych czy dodatkowych w dynamicznym

Robię tak, gdy chodzi o poprawienie wydajności, ale statyczne typowanie
nie ma tu dla mnie najmniejszego znaczenia.

>
> PS. Z szacunkiem dla języka Python, to naprawdę przymyślany i
> świadomie projektowany język.

I dzięki temu jest szansa, że zwykly śmiertelnik może zrozumieć
o co w danym programie chodzi, a to już ogromny sukces.

RW

W dniu 2011-05-15 19:23, Rob Wolfe pisze:
> Jacek Czerwinski<x@y.z.pl>  writes:
>

> Działają mi na nerwy tego typu opinie. Brałem udział w refactoringu
> róznych rzeczy w róznych językach, typowanych dynamicznie i statycznie
> i nie zauważyłem, aby ten akurat element był tu jakoś specjalnie
> istotny.
Dla mnie jest.
Dodałbym możliwość wspomagania refaktoringu / nie w narzędziach.
> Usunięcie błędów kompilacji nie dowodzi niczego.
Hmmmm.
Wybacz, nie ucz tego studentów, ale sporo dowodzi w dobrym języku (dla 
mnie chociaż nie wyłącznie Java >=5).
W pełni się zgodzę na gruncie np. C, kompilacja nie dowodzi niczego.
Zastrzegam, moja własna opinia programisty z "przemysłu" a nie hiper 
korporacji/uniwerków.

> 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).
jest to słuszne stwierdzenie.

Bym porównał (w szerokim sensie) do niemieckiego, może tekstu nie 
rozumiesz, nudny, bez polotu, rozbierasz na atomy i rozumiesz 
(przeciwstawiając angielskiemu: bez błysku intuicji (i znajomości 
idiomów) nie ruszysz)

W dniu 15.05.2011 20:39, Jacek Czerwinski pisze:

> Wybacz, nie ucz tego studentów, ale sporo dowodzi w dobrym języku (dla
> mnie chociaż nie wyłącznie Java >=5).

Wybacz ale w twoim wypadku wypowiedź o tym że java rzadzi niczym nie 
zaskakuje, ale jezeli już chesz sie wypowiadać w temacie jezykw 
typowanych statycznie vs. typowanych dynamicznie i nie masz ochoty 
obrazać swoich czytelników zdobądź się na to by uzyc arumentu.

-- 
Piotr Siudak
siudak@xz.pl

On 15.05.2011 19:23, Rob Wolfe wrote:
> Jacek Czerwinski<x@y.z.pl>  writes:
>> Dynamiczne typowanie na pewno jest wygodne (i to bardzo) na etapie
>> pierwszego' pisania, ale refactoringu to horror.
>
> 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).

Masz rację i nie masz ;)
Oczywiście brak błędów kompilacji w żaden sposób nie dowodzi że kod 
jesgt poprawny. Niemniej przy dużym refaktoringu pozwala wyłapać 
oczywiste błędy. Jeśli kompilator krzyczy że jest niezgodność typów to 
nie ma bata, coś musi być spieprzone.

W pythonie wszystko pozornie zabangla bardzo ładnie, tylko czasami 
będziemy się dowiadywać, że "list object has no attribute keys" lub coś 
podobnego ;)

Bardzo lubię pythona za łatwość w pisaniu kodu, ale czasami przydałaby 
się możliwość właczenia sztywniejszej kontroli kodu. (W erlangu jest coś 
podobnego, choć osobiście z tego nie jeszcze korzystałem).

Pzdr
]J.

On 16 Maj, 09:34, zbro...@tlen.pl wrote:
> On 15.05.2011 19:23, Rob Wolfe wrote:
>
> > Jacek Czerwinski<x...@y.z.pl>  writes:
> >> Dynamiczne typowanie na pewno jest wygodne (i to bardzo) na etapie
> >> pierwszego' pisania, ale refactoringu to horror.
>
> > 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).
>
> Masz rację i nie masz ;)
> Oczywiście brak błędów kompilacji w żaden sposób nie dowodzi że kod
> jesgt poprawny.

Otoz to.

> Niemniej przy dużym refaktoringu pozwala wyłapać
> oczywiste błędy. Jeśli kompilator krzyczy że jest niezgodność typów to
> nie ma bata, coś musi być spieprzone.

Oczywiste bledy w Pythonie mozna wylapac rownie latwo.

> W pythonie wszystko pozornie zabangla bardzo ładnie, tylko czasami
> będziemy się dowiadywać, że "list object has no attribute keys" lub coś
> podobnego ;)

Nic podobnego. Tego typu proste bledy sa do wylapania uzywajac
statycznej analizy bez zadnego problemu.

$ cat test.py
lst = []
lst.keys()
$ pylint -E test.py
************* Module test
E:  2: Instance of 'list' has no 'keys' member

>
> Bardzo lubię pythona za łatwość w pisaniu kodu, ale czasami przydałaby
> się możliwość właczenia sztywniejszej kontroli kodu. (W erlangu jest coś
> podobnego, choć osobiście z tego nie jeszcze korzystałem).

Statyczna analiza, ogarniecie tematu oraz testy, testy, testy...
to jest doskonale polaczenie.
Chyba ze dwa pokolenia programistow musza wyginac,
aby przestala obowiazywac zlota zasada: "it compiles, ship it!". ;)

RW

On 16.05.2011 15:49, Rob Wolfe wrote:
> Nic podobnego. Tego typu proste bledy sa do wylapania uzywajac
> statycznej analizy bez zadnego problemu.
>
> $ cat test.py
> lst = []
> lst.keys()
> $ pylint -E test.py
> ************* Module test
> E:  2: Instance of 'list' has no 'keys' member

Takie też?

def a(b):
     print b.keys()

x = []
a(x)


Tyle w temacie statycznej analizy.

Pzdr
J.

zbrodel@tlen.pl writes:

> On 16.05.2011 15:49, Rob Wolfe wrote:
>> Nic podobnego. Tego typu proste bledy sa do wylapania uzywajac
>> statycznej analizy bez zadnego problemu.
>>
>> $ cat test.py
>> lst = []
>> lst.keys()
>> $ pylint -E test.py
>> ************* Module test
>> E:  2: Instance of 'list' has no 'keys' member
>
> Takie też?
>
> def a(b):
>     print b.keys()
>
> x = []
> a(x)
>
>
> Tyle w temacie statycznej analizy.

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ł.
Są też asercje. Można kontrolować interfejsy w runtime'ie itp.

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, a w podziękowaniu dostaję segmentation fault.
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ę.

RW

On 2011-05-16, Rob Wolfe <rw@smsnet.pl> wrote:
> zbrodel@tlen.pl writes:
>
>> On 16.05.2011 15:49, Rob Wolfe wrote:
>>> Nic podobnego. Tego typu proste bledy sa do wylapania uzywajac
>>> statycznej analizy bez zadnego problemu.
>>>
>>> $ cat test.py
>>> lst = []
>>> lst.keys()
>>> $ pylint -E test.py
>>> ************* Module test
>>> E:  2: Instance of 'list' has no 'keys' member
>>
>> Takie też?
>>
>> def a(b):
>>     print b.keys()
>>
>> x = []
>> a(x)
>>
>>
>> Tyle w temacie statycznej analizy.
>
> Ok, mamy różne pojęcie o tym jaki błąd jest oczywisty. ;)

A teraz sobie porównaj jak takie błędy się wychwytuje w Adzie, C++ albo
w Javie.

> Tak, interfejsów statycznie nie da się sprawdzić w Pythonie.
> Wspominałem też o testach, które by tu pasowały jak ulał.
> Są też asercje. Można kontrolować interfejsy w runtime'ie itp.

Można. Ale powinno to być wykonane podczas kompilacji -- bo się da.

> Chodzi mi o to, że w praktyce nie zauważyłem, aby statyczne
> typy pomagały.

A ile tego (języków ze statycznym typowaniem) używałeś i przy jak dużych
projektach?

> Wręcz przeciwnie, muszę się narzeźbić jak debil,
> aby zadowolić kompilator, a w podziękowaniu dostaję segmentation fault.

Urban legend.

-- 
Secunia non olet.
Stanislaw Klekot

On May 17, 9:35 am, "Stachu 'Dozzie' K."
<doz...@go.eat.some.screws.spammer.invalid> wrote:
> On 2011-05-16, Rob Wolfe <r...@smsnet.pl> wrote:
>
>
>
>
>
>
>
>
>
> > zbro...@tlen.pl writes:
>
> >> On 16.05.2011 15:49, Rob Wolfe wrote:
> >>> Nic podobnego. Tego typu proste bledy sa do wylapania uzywajac
> >>> statycznej analizy bez zadnego problemu.
>
> >>> $ cat test.py
> >>> lst = []
> >>> lst.keys()
> >>> $ pylint -E test.py
> >>> ************* Module test
> >>> E:  2: Instance of 'list' has no 'keys' member
>
> >> Takie też?
>
> >> def a(b):
> >>     print b.keys()
>
> >> x = []
> >> a(x)
>
> >> Tyle w temacie statycznej analizy.
>
> > Ok, mamy różne pojęcie o tym jaki błąd jest oczywisty. ;)
>
> A teraz sobie porównaj jak takie błędy się wychwytuje w Adzie, C++ albo
> w Javie.

W C++ bardzo często nieistniejące, a wiadomości o błędach siegają
wielu ekranów nic nie znaczącego bełkotu kompilatora.


> > > Tak, interfejsów statycznie nie da się sprawdzić w Pythonie.
> > Wspominałem też o testach, które by tu pasowały jak ulał.
> > Są też asercje. Można kontrolować interfejsy w runtime'ie itp.
>
> Można. Ale powinno to być wykonane podczas kompilacji -- bo się da.

1. Jak ktoś chce, to może i w Pythonie, np.: http://threecheck.sourceforge.net/

2. Jeśli iść tą drogą, to Java czy C++ sprawdzają bardzo mało.
Porównaj z np. Haskell'em. Dla fanatyków jest Epigram (http://www.e-
pig.org/). Tam każdy program poprawnie otypowany jest na 100%
poprawny. Trochę może ci zająć napisanie programu liczącego 100-tną
cyfrę rozwinięcia PI, no ale jak już napiszesz...

>
> > Chodzi mi o to, że w praktyce nie zauważyłem, aby statyczne
> > typy pomagały.
>
> A ile tego (języków ze statycznym typowaniem) używałeś i przy jak dużych
> projektach?

Takie argumenty raczej nie prowadzą do merytorycznej

---
Łukasz Rekucki

On 2011-05-17, Łukasz Rekucki <lrekucki@gmail.com> wrote:
>> >> def a(b):
>> >>     print b.keys()
>>
>> >> x = []
>> >> a(x)
>>
>> >> Tyle w temacie statycznej analizy.
>>
>> > Ok, mamy różne pojęcie o tym jaki błąd jest oczywisty. ;)
>>
>> A teraz sobie porównaj jak takie błędy się wychwytuje w Adzie, C++ albo
>> w Javie.
>
> W C++ bardzo często nieistniejące, a wiadomości o błędach siegają
> wielu ekranów nic nie znaczącego bełkotu kompilatora.

Parse error. Nieistniejące co? I przykład poproszę.

> 2. Jeśli iść tą drogą, to Java czy C++ sprawdzają bardzo mało.
> Porównaj z np. Haskell'em.

Znam, widziałem. Haskell jest znany z bardzo silnego systemu typów (co
ma zresztą więcej języków funkcyjnych). Ale nie mówimy o tym jak silny
jest system typowania, tylko czy statyczny.

A ty odłóż apostrof, bo sobie nim krzywdę zrobisz.
http://poradnia.pwn.pl/lista.php?id=6142

>> > Chodzi mi o to, że w praktyce nie zauważyłem, aby statyczne
>> > typy pomagały.
>>
>> A ile tego (języków ze statycznym typowaniem) używałeś i przy jak dużych
>> projektach?
>
> Takie argumenty raczej nie prowadzą do merytorycznej

Chcę ocenić wiedzę dyskutanta, skoro już powiedział że "on nie widział
tego w praktyce".

-- 
Secunia non olet.
Stanislaw Klekot

On 17 Maj, 09:35, "Stachu 'Dozzie' K."
<doz...@go.eat.some.screws.spammer.invalid> wrote:
> On 2011-05-16, Rob Wolfe <r...@smsnet.pl> wrote:
>
>
>
>
>
>
>
>
>
> > zbro...@tlen.pl writes:
>
> >> On 16.05.2011 15:49, Rob Wolfe wrote:
> >>> Nic podobnego. Tego typu proste bledy sa do wylapania uzywajac
> >>> statycznej analizy bez zadnego problemu.
>
> >>> $ cat test.py
> >>> lst = []
> >>> lst.keys()
> >>> $ pylint -E test.py
> >>> ************* Module test
> >>> E:  2: Instance of 'list' has no 'keys' member
>
> >> Takie też?
>
> >> def a(b):
> >>     print b.keys()
>
> >> x = []
> >> a(x)
>
> >> Tyle w temacie statycznej analizy.
>
> > Ok, mamy różne pojęcie o tym jaki błąd jest oczywisty. ;)
>
> A teraz sobie porównaj jak takie błędy się wychwytuje w Adzie, C++ albo
> w Javie.
>

Wiem jak w C++ i Javie. Juz pisalem w skrocie: "it compiles, shipt
it!".
Co z tego wynika, ze mi kompilator powie, ze typ sie zgadza?
Zupelnie nic. Czy nie jest czasem tak, ze operacje na tym typie
moga sie nie powiesc? Czy np. w przypadku polimorfizmu
moze zostac wywolana zupelnie inna metoda, niz sie spodziewales?
I milion innych rzeczy... No, ale sie skompilowalo! Great!

> > Tak, interfejsów statycznie nie da się sprawdzić w Pythonie.
> > Wspominałem też o testach, które by tu pasowały jak ulał.
> > Są też asercje. Można kontrolować interfejsy w runtime'ie itp.
>
> Można. Ale powinno to być wykonane podczas kompilacji -- bo się da.
>

Da sie kosztem, ktory imho jest kompletnie nie do przyjecia.

> > Chodzi mi o to, że w praktyce nie zauważyłem, aby statyczne
> > typy pomagały.
>
> A ile tego (języków ze statycznym typowaniem) używałeś i przy jak dużych
> projektach?
>

C++ i Javy, w projektach sporych mysle (ok 500 kloc).
Moge odwrocic pytanie. Jak duzy soft pisales w jezyku dynamicznie
typowanym
i jakim, aby twierdzic, ze sa do pisania duzych systemow gorsze?
Ludzie czesto argumentuja, ze w przypadku duzych systemow z "legacy"
kodem
bez statycznego typowania, to tylko szalency by probowali cos robic.
Mam do czynienia z takim systemem  i napatrzylem sie dosc
na cudowne mozliwosci statycznego typowania.
Nie zabieralbym glosu w tej sprawie, gdyby nie to ze bralem udzial tez
w projektach czysto pythonowych (ostatnio ok 50 kloc) i nie tesknilem
ani przez moment za statycznym typowaniem.

> > Wręcz przeciwnie, muszę się narzeźbić jak debil,
> > aby zadowolić kompilator, a w podziękowaniu dostaję segmentation fault.
>
> Urban legend.

Ok, dyskusja zmierza w kierunku dobrze znanym. Oba obozy sa mocno
okopane
i nic nie wskazuje, abym ja kogos przekonal albo ktos mnie.
Takze z mojej strony EOT.

RW

On 2011-05-17, Rob Wolfe <rw@smsnet.pl> wrote:
>> > Ok, mamy różne pojęcie o tym jaki błąd jest oczywisty. ;)
>>
>> A teraz sobie porównaj jak takie błędy się wychwytuje w Adzie, C++ albo
>> w Javie.

> Wiem jak w C++ i Javie. Juz pisalem w skrocie: "it compiles, shipt
> it!".
> Co z tego wynika, ze mi kompilator powie, ze typ sie zgadza?
> Zupelnie nic.

Chodzi o coś zupełnie innego. Typowy błąd początkujących programistów:
branie implikacji za równoważność.

"Jeśli program jest dobry, to typy się zgadzają."
Odwracając implikację:
"Jeśli typy się nie zgadzają, to program nie jest dobry."

> Czy nie jest czasem tak, ze operacje na tym typie
> moga sie nie powiesc? Czy np. w przypadku polimorfizmu
> moze zostac wywolana zupelnie inna metoda, niz sie spodziewales?
> I milion innych rzeczy... No, ale sie skompilowalo! Great!

Owszem, great. Kompilator odwalił za ciebie brudną robotę ze wstępnym
sprawdzeniem poprawności i wybronił cię przed koniecznością uruchamiania
programu tylko po to, żebyś znalazł hasz tam gdzie miała być krotka.

>> > Tak, interfejsów statycznie nie da się sprawdzić w Pythonie.
>> > Wspominałem też o testach, które by tu pasowały jak ulał.
>> > Są też asercje. Można kontrolować interfejsy w runtime'ie itp.
>>
>> Można. Ale powinno to być wykonane podczas kompilacji -- bo się da.

> Da sie kosztem, ktory imho jest kompletnie nie do przyjecia.

A kto ci tak nakłamał że jest nie do przyjęcia?

>> > Chodzi mi o to, że w praktyce nie zauważyłem, aby statyczne
>> > typy pomagały.
>>
>> A ile tego (języków ze statycznym typowaniem) używałeś i przy jak dużych
>> projektach?

> C++ i Javy, w projektach sporych mysle (ok 500 kloc).
> Moge odwrocic pytanie. Jak duzy soft pisales w jezyku dynamicznie
> typowanym
> i jakim, aby twierdzic, ze sa do pisania duzych systemow gorsze?

30kloc, przy zmieniającym się frameworku o który projekt był oparty.
Wyszukiwanie miejsc gdzie trzeba poprawiać kod żeby był zgodny
z frameworkiem było bardzo uciążliwe, bo trzeba było po prawie każdej
poprawce uruchamiać aplikację ponownie.

> Ludzie czesto argumentuja, ze w przypadku duzych systemow z "legacy"
> kodem
> bez statycznego typowania, to tylko szalency by probowali cos robic.

Ludzie może i tak, ale ja niekoniecznie. Tylko nie lubię gdy ktoś
próbuje wmawiać publice że statyczne typowanie jest psu na budę, kiedy
widziałem że pomaga.

> Mam do czynienia z takim systemem  i napatrzylem sie dosc
> na cudowne mozliwosci statycznego typowania.

Please elaborate.

-- 
Secunia non olet.
Stanislaw Klekot

Witam, moje 20gr troszkę w obronie Pythona :)

On 17 Maj, 15:22, "Stachu 'Dozzie' K."
<doz...@go.eat.some.screws.spammer.invalid> wrote:
> Chodzi o coś zupełnie innego. Typowy błąd początkujących programistów:
> branie implikacji za równoważność.
>
> "Jeśli program jest dobry, to typy się zgadzają."
> Odwracając implikację:
> "Jeśli typy się nie zgadzają, to program nie jest dobry."

Bardziej poprawnie powinno być: jeśli typy się zgadzają to jest  duża
szansa, że kompilator skompiluje :)

> Owszem, great. Kompilator odwalił za ciebie brudną robotę ze wstępnym
> sprawdzeniem poprawności i wybronił cię przed koniecznością uruchamiania
> programu tylko po to, żebyś znalazł hasz tam gdzie miała być krotka.

A co to za różnica, że uruchomię zamiast skompiluję? Jeden "ruch"
mniej :)
Jak użyjesz stringów zamiast napisania/użycia klas to żadne typowanie
nie obroni :)

> 30kloc, przy zmieniającym się frameworku o który projekt był oparty.
> Wyszukiwanie miejsc gdzie trzeba poprawiać kod żeby był zgodny
> z frameworkiem było bardzo uciążliwe, bo trzeba było po prawie każdej
> poprawce uruchamiać aplikację ponownie.

No tu problem leży gdzieś indziej - parafrazując klasyka: Puchatka :).
Framework jak trochę nazwa sugeruje powinien być w miarę niezmienny bo
wtedy i Święty Typ Najwyższy nie pomoże :)

> Ludzie może i tak, ale ja niekoniecznie. Tylko nie lubię gdy ktoś
> próbuje wmawiać publice że statyczne typowanie jest psu na budę, kiedy
> widziałem że pomaga.

Dla każdego coś innego :)

A tak poza tym wątkiem to często się zapomina, że Python to nie tylko
skryptowy język, ale język obdarzony niesamowicie zwięzłą, a
jednocześnie czytelną składnią. Polecam porównanie http://shootout.alioth.debian.org/.
Krótszy i przez to łatwiejszy do ogarnięcia kod oznacza mniej
czytania, mniej miejsc do popełnienia błędów itd.
Szczerze mówiąc lubiłem Javę, ale nie podobało mi się w niej łatwe
przekraczanie 80 znaków w linii :) Potem zobaczyłem C# i wpadłem w
przerażenie :D

Pzdr.

On 2011-05-17, jacek2v <jacek2v@gmail.com> wrote:
>> Chodzi o coś zupełnie innego. Typowy błąd początkujących programistów:
>> branie implikacji za równoważność.

>> "Jeśli program jest dobry, to typy się zgadzają."
>> Odwracając implikację:
>> "Jeśli typy się nie zgadzają, to program nie jest dobry."

> Bardziej poprawnie powinno być: jeśli typy się zgadzają to jest  duża
> szansa, że kompilator skompiluje :)

Bardziej poprawnie od którego? Bo jakoś nie widać do czego pijesz.

>> Owszem, great. Kompilator odwalił za ciebie brudną robotę ze wstępnym
>> sprawdzeniem poprawności i wybronił cię przed koniecznością uruchamiania
>> programu tylko po to, żebyś znalazł hasz tam gdzie miała być krotka.

> A co to za różnica, że uruchomię zamiast skompiluję? Jeden "ruch"
> mniej :)

1. Uruchomienie może być bardziej kłopotliwe niż sam proces budowania
   (dla webaplikacji to może być skopiowanie na serwer testowy,
   przeładowanie serwera, otwarcie przeglądarki i dokopanie się do
   ekranu którego kod chcesz sprawdzić).
2. Kompilacja, jako operacja wykonywana na kodzie źródłowym przez
   automat, jest dokładniejsza od kontrolnego uruchomienia aplikacji.
   Sprawdzisz za jednym zamachem wszystkie możliwe ścieżki wykonania
   w blokach kontrolnych?

Ekstrapolując twoje proponowane podejście "jeden ruch mniej", może
darujmy sobie testowanie aplikacji? Kolejny ruch mniej.

> Jak użyjesz stringów zamiast napisania/użycia klas to żadne typowanie
> nie obroni :)

Eeeee... że co?

>> 30kloc, przy zmieniającym się frameworku o który projekt był oparty.
>> Wyszukiwanie miejsc gdzie trzeba poprawiać kod żeby był zgodny
>> z frameworkiem było bardzo uciążliwe, bo trzeba było po prawie każdej
>> poprawce uruchamiać aplikację ponownie.

> No tu problem leży gdzieś indziej - parafrazując klasyka: Puchatka :).
> Framework jak trochę nazwa sugeruje powinien być w miarę niezmienny bo
> wtedy i Święty Typ Najwyższy nie pomoże :)

Ano nie pomoże. Ale statyczna kontrola typów by sporo ułatwiła.

> A tak poza tym wątkiem to często się zapomina, że Python to nie tylko
> skryptowy język, ale język obdarzony niesamowicie zwięzłą, a
> jednocześnie czytelną składnią.

A co to ma do rzeczy? Mówimy o statycznym systemie typów, a nie o tym
czy składnia jest zwięzła. Zresztą zwięzłość składni nie ma specjalnego
wpływu na długość kodu w większych projektach.

> Polecam porównanie http://shootout.alioth.debian.org/.
> Krótszy i przez to łatwiejszy do ogarnięcia kod oznacza mniej
> czytania, mniej miejsc do popełnienia błędów itd.
> Szczerze mówiąc lubiłem Javę, ale nie podobało mi się w niej łatwe
> przekraczanie 80 znaków w linii :)

To nie wina języka, że programiści się nie mieszczą w 80 kolumnach,
tylko powszechnie przyjętych konwencji, prawie wymuszanych przez
bibliotekę standardową (bo weź używaj kontenerów bez tych konwencji).
A najbardziej programistów, bo w ogóle nie myślą o tym jak kod zmieścić
na 80 znakach (bo przecież od dawna mamy monitory panoramiczne).

-- 
Secunia non olet.
Stanislaw Klekot

On 05/15/2011 08:39 PM, Jacek Czerwinski wrote:
> Wybacz, nie ucz tego studentów, ale sporo dowodzi w dobrym języku (dla
> mnie chociaż nie wyłącznie Java >=5).

Polecam poniższy esej Bruce'a Eckela (autora m.in. Thinking in Java):
https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk&pli=1

Pozdrawiam,
Adam

W dniu 2011-05-17 21:03, Stachu 'Dozzie' K. pisze:
> On 2011-05-17, jacek2v<jacek2v@gmail.com>  wrote:

>> Szczerze mówiąc lubiłem Javę, ale nie podobało mi się w niej łatwe
>> przekraczanie 80 znaków w linii :)
>
> To nie wina języka, że programiści się nie mieszczą w 80 kolumnach,
> tylko powszechnie przyjętych konwencji, prawie wymuszanych przez
> bibliotekę standardową (bo weź używaj kontenerów bez tych konwencji).
> A najbardziej programistów, bo w ogóle nie myślą o tym jak kod zmieścić
> na 80 znakach (bo przecież od dawna mamy monitory panoramiczne).

Ja tam zawsze "wyjętą z pudełka" Eclipse przestawiam na 120zn. Ale 
zgubiłem się, nie wiem czy jestem za, czy przeciw ;)

On 17 Maj, 21:03, "Stachu 'Dozzie' K."
<doz...@go.eat.some.screws.spammer.invalid> wrote:
> On 2011-05-17, jacek2v <jace...@gmail.com> wrote:
>
> >> Chodzi o coś zupełnie innego. Typowy błąd początkujących programistów:
> >> branie implikacji za równoważność.
> >> "Jeśli program jest dobry, to typy się zgadzają."
> >> Odwracając implikację:
> >> "Jeśli typy się nie zgadzają, to program nie jest dobry."
> > Bardziej poprawnie powinno być: jeśli typy się zgadzają to jest  duża
> > szansa, że kompilator skompiluje :)
>
> Bardziej poprawnie od którego? Bo jakoś nie widać do czego pijesz.
Właściwie do obu - a jak chcesz wybrać jednego to do drugiego :)
"Poprawne" ponieważ oba stwierdzenia nic nie mówią o sile "typowania".

> > A co to za różnica, że uruchomię zamiast skompiluję? Jeden "ruch"
> > mniej :)
>
> 1. Uruchomienie może być bardziej kłopotliwe niż sam proces budowania
>    (dla webaplikacji to może być skopiowanie na serwer testowy,
>    przeładowanie serwera, otwarcie przeglądarki i dokopanie się do
>    ekranu którego kod chcesz sprawdzić).
Nigdy i tak musisz uruchomić, taki jest cel programowania, czym
szybciej masz możliwość weryfikacji poprzez uruchomienie tym lepiej.
Mi. do tego dążą metodyki agile. Przeładowywanie serwera nie jest
konieczne - automat. Skopiowanie na serwer - automat. Otwarcie
przeglądarki - automat po kliknięciu na link.
Mhh, pojawiło mi się pytanie, czy kiedykolwiek robiłeś webaplikację w
oparciu o języki pokroju Python?

> 2. Kompilacja, jako operacja wykonywana na kodzie źródłowym przez
>    automat, jest dokładniejsza od kontrolnego uruchomienia aplikacji.
>    Sprawdzisz za jednym zamachem wszystkie możliwe ścieżki wykonania
>    w blokach kontrolnych?
I tak to trzeba robić - może nie wszystkie ścieżki, ale testy/skrypty
testowe trzeba zrobić i puszczać po każdej integracji - unit testy i
testy symulacji użytkownika. A potem i tak najlepiej "napuścić"
testera :)

> Ekstrapolując twoje proponowane podejście "jeden ruch mniej", może
> darujmy sobie testowanie aplikacji? Kolejny ruch mniej.
Dziwna ekstrapolacja - poza zbiór dopuszczalnych wyników :)

> > Jak użyjesz stringów zamiast napisania/użycia klas to żadne typowanie
> > nie obroni :)
>
> Eeeee... że co?
Prosty przykład: kod pocztowy. Można napisać klasę, a można trzymać w
stringu.

> >> 30kloc, przy zmieniającym się frameworku o który projekt był oparty.
> >> Wyszukiwanie miejsc gdzie trzeba poprawiać kod żeby był zgodny
> >> z frameworkiem było bardzo uciążliwe, bo trzeba było po prawie każdej
> >> poprawce uruchamiać aplikację ponownie.
> > No tu problem leży gdzieś indziej - parafrazując klasyka: Puchatka :).
> > Framework jak trochę nazwa sugeruje powinien być w miarę niezmienny bo
> > wtedy i Święty Typ Najwyższy nie pomoże :)
>
> Ano nie pomoże. Ale statyczna kontrola typów by sporo ułatwiła.
Wydaje mi się, że przy zmiana framework raczej przeszkadza. Kiedyś
spotkałem się z podobnym przypadkiem w Pascalu. Typowanie wymagało
dużo "bezrozumnego" poprawiania kodu.


> > A tak poza tym wątkiem to często się zapomina, że Python to nie tylko
> > skryptowy język, ale język obdarzony niesamowicie zwięzłą, a
> > jednocześnie czytelną składnią.
>
> A co to ma do rzeczy? Mówimy o statycznym systemie typów, a nie o tym
> czy składnia jest zwięzła. Zresztą zwięzłość składni nie ma specjalnego
> wpływu na długość kodu w większych projektach.
Napisałem "A tak poza wątkiem" - wybiórcze czytanie? :)
Nie będę polemizował czy zwięzłość kodu ma coś do rzeczy z jego
ilością :) - bo dla mnie to oczywista oczywistość :)
BTW: tematem wątku jest "interpretowany czy kompilowany", a drugie
pytanie autora to "jak z prędkością?" :)

>
> > Polecam porównaniehttp://shootout.alioth.debian.org/.
> > Krótszy i przez to łatwiejszy do ogarnięcia kod oznacza mniej
> > czytania, mniej miejsc do popełnienia błędów itd.
> > Szczerze mówiąc lubiłem Javę, ale nie podobało mi się w niej łatwe
> > przekraczanie 80 znaków w linii :)
>
> To nie wina języka, że programiści się nie mieszczą w 80 kolumnach,
> tylko powszechnie przyjętych konwencji, prawie wymuszanych przez
> bibliotekę standardową (bo weź używaj kontenerów bez tych konwencji).
> A najbardziej programistów, bo w ogóle nie myślą o tym jak kod zmieścić
> na 80 znakach (bo przecież od dawna mamy monitory panoramiczne).
Możliwe, ale Visual Studio generuje spagetti po pierwszym
kliknięciu :)

Jacek

On 18 Maj, 06:23, Jacek Czerwinski <x...@y.z.pl> wrote:
> W dniu 2011-05-17 21:03, Stachu 'Dozzie' K. pisze:
>
> > On 2011-05-17, jacek2v<jace...@gmail.com>  wrote:
> >> Szczerze mówiąc lubiłem Javę, ale nie podobało mi się w niej łatwe
> >> przekraczanie 80 znaków w linii :)
>
> > To nie wina języka, że programiści się nie mieszczą w 80 kolumnach,
> > tylko powszechnie przyjętych konwencji, prawie wymuszanych przez
> > bibliotekę standardową (bo weź używaj kontenerów bez tych konwencji).
> > A najbardziej programistów, bo w ogóle nie myślą o tym jak kod zmieścić
> > na 80 znakach (bo przecież od dawna mamy monitory panoramiczne).
>
> Ja tam zawsze "wyjętą z pudełka" Eclipse przestawiam na 120zn. Ale
> zgubiłem się, nie wiem czy jestem za, czy przeciw ;)

lol

On 2011-05-19, jacek2v <jacek2v@gmail.com> wrote:
>> >> Chodzi o coś zupełnie innego. Typowy błąd początkujących programistów:
>> >> branie implikacji za równoważność.
>> >> "Jeśli program jest dobry, to typy się zgadzają."
>> >> Odwracając implikację:
>> >> "Jeśli typy się nie zgadzają, to program nie jest dobry."
>> > Bardziej poprawnie powinno być: jeśli typy się zgadzają to jest  duża
>> > szansa, że kompilator skompiluje :)
>> Bardziej poprawnie od którego? Bo jakoś nie widać do czego pijesz.
> Właściwie do obu - a jak chcesz wybrać jednego to do drugiego :)
> "Poprawne" ponieważ oba stwierdzenia nic nie mówią o sile "typowania".

Oczywiście że nie mówią. Mówią o statyczności typowania, bo o tym
dyskutujemy w tej gałęzi. Nadal nie rozumiem co ma do rzeczy "silność"
systemu typów.

>> > A co to za różnica, że uruchomię zamiast skompiluję? Jeden "ruch"
>> > mniej :)
>> 1. Uruchomienie może być bardziej kłopotliwe niż sam proces budowania
>>    (dla webaplikacji to może być skopiowanie na serwer testowy,
>>    przeładowanie serwera, otwarcie przeglądarki i dokopanie się do
>>    ekranu którego kod chcesz sprawdzić).
> Nigdy i tak musisz uruchomić,

Parse error.

> taki jest cel programowania, czym
> szybciej masz możliwość weryfikacji poprzez uruchomienie tym lepiej.

Nikt ci nie zabrania uruchamiać aplikacji do woli. Etap weryfikacji
typów podczas kompilacji to po prostu dodatkowe sprawdzenie, które
dochodzi ci praktycznie za darmo.

> Mi. do tego dążą metodyki agile. Przeładowywanie serwera nie jest
> konieczne - automat. Skopiowanie na serwer - automat. Otwarcie
> przeglądarki - automat po kliknięciu na link.

A potem przeklikuj się ręcznie przez wszystkie formularze żeby sprawdzić
ich poprawność. Albo napisz automat, który będzie automatyzować klikanie
pól (uwaga na AJAX!). Ot, taki dodatkowy kłopot.

>> 2. Kompilacja, jako operacja wykonywana na kodzie źródłowym przez
>>    automat, jest dokładniejsza od kontrolnego uruchomienia aplikacji.
>>    Sprawdzisz za jednym zamachem wszystkie możliwe ścieżki wykonania
>>    w blokach kontrolnych?
> I tak to trzeba robić - może nie wszystkie ścieżki, ale testy/skrypty
> testowe trzeba zrobić i puszczać po każdej integracji - unit testy i
> testy symulacji użytkownika. A potem i tak najlepiej "napuścić"
> testera :)

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*.

>> Ekstrapolując twoje proponowane podejście "jeden ruch mniej", może
>> darujmy sobie testowanie aplikacji? Kolejny ruch mniej.
> Dziwna ekstrapolacja - poza zbiór dopuszczalnych wyników :)

Właśnie. Do tego prowadzi twój pomysł z opuszczaniem kolejnych kroków
budowania softu: do opuszczenia zbioru dopuszczalnych wyników.

>> Ano nie pomoże. Ale statyczna kontrola typów by sporo ułatwiła.
> Wydaje mi się, że przy zmiana framework raczej przeszkadza. Kiedyś
> spotkałem się z podobnym przypadkiem w Pascalu. Typowanie wymagało
> dużo "bezrozumnego" poprawiania kodu.

Ale przynajmniej wiedziałeś gdzie się zmieniło API. Przy typowaniu
dynamicznym nie masz tej informacji podczas kompilacji.

>> > A tak poza tym wątkiem to często się zapomina, że Python to nie tylko
>> > skryptowy język, ale język obdarzony niesamowicie zwięzłą, a
>> > jednocześnie czytelną składnią.
>> A co to ma do rzeczy? Mówimy o statycznym systemie typów, a nie o tym
>> czy składnia jest zwięzła. Zresztą zwięzłość składni nie ma specjalnego
>> wpływu na długość kodu w większych projektach.
> Napisałem "A tak poza wątkiem" - wybiórcze czytanie? :)
> Nie będę polemizował czy zwięzłość kodu ma coś do rzeczy z jego
> ilością :) - bo dla mnie to oczywista oczywistość :)

Proponuję popisać w paru innych językach (np. w Javie), wtedy zobaczysz
jaki jest wpływ samej składni na długość kodu. Bo większość operacji
w przeciętnym kodzie źródłowym tłumaczy się wprost na inne języki,
a idiomów używa się sporadycznie.

-- 
Secunia non olet.
Stanislaw Klekot

On 20 Maj, 10:24, "Stachu 'Dozzie' K."
<doz...@go.eat.some.screws.spammer.invalid> wrote:
> Oczywiście że nie mówią. Mówią o statyczności typowania, bo o tym
> dyskutujemy w tej gałęzi. Nadal nie rozumiem co ma do rzeczy "silność"
> systemu typów.

Wydawało mi się, że cały czas o tym mówisz - o wyższości języka z
typowaniem, czyli o jego "sile" . Ale możliwe, że Cię źle
zrozumiałem :)

> >> > A co to za różnica, że uruchomię zamiast skompiluję? Jeden "ruch"
> >> > mniej :)
> >> 1. Uruchomienie może być bardziej kłopotliwe niż sam proces budowania
> >>    (dla webaplikacji to może być skopiowanie na serwer testowy,
> >>    przeładowanie serwera, otwarcie przeglądarki i dokopanie się do
> >>    ekranu którego kod chcesz sprawdzić).
> > Nigdy i tak musisz uruchomić,
>
> Parse error.

Mhh, a ja zawsze myślałem, że programy się pisze by je uruchamiać. No
cóż, ale istnieje też trend zwany "sztuka dla sztuki" :)

> Nikt ci nie zabrania uruchamiać aplikacji do woli. Etap weryfikacji
> typów podczas kompilacji to po prostu dodatkowe sprawdzenie, które
> dochodzi ci praktycznie za darmo.

Nie za darmo. Trzeba wszędzie pisać explicite typ, a to sporo kodu
więcej.

> > Mi. do tego dążą metodyki agile. Przeładowywanie serwera nie jest
> > konieczne - automat. Skopiowanie na serwer - automat. Otwarcie
> > przeglądarki - automat po kliknięciu na link.
>
> A potem przeklikuj się ręcznie przez wszystkie formularze żeby sprawdzić
> ich poprawność. Albo napisz automat, który będzie automatyzować klikanie
> pól (uwaga na AJAX!). Ot, taki dodatkowy kłopot.

Kłopot?, ja uważam, że bez tego to bugów będzie jak "mrówków" :)
Niezależnie od języka programowania, testy trzeba pisać i wykonywać.
Automatyczne zwłaszcza w większych aplikacjach lub o wyższych
wymaganiach co do niezawodności/wydajności są wręcz niezbędne - czyli
tam gdzie jest większy budżet.
Sugerujesz, że oddajesz aplikację nawet jej nie przeklikawszy?

> 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.

> >> Ekstrapolując twoje proponowane podejście "jeden ruch mniej", może
> >> darujmy sobie testowanie aplikacji? Kolejny ruch mniej.
> > Dziwna ekstrapolacja - poza zbiór dopuszczalnych wyników :)
>
> Właśnie. Do tego prowadzi twój pomysł z opuszczaniem kolejnych kroków
> budowania softu: do opuszczenia zbioru dopuszczalnych wyników.

To był Twój pomysł, aby nie testować - nie dokręcaj kota ogonem :)

> >> Ano nie pomoże. Ale statyczna kontrola typów by sporo ułatwiła.
> > Wydaje mi się, że przy zmiana framework raczej przeszkadza. Kiedyś
> > spotkałem się z podobnym przypadkiem w Pascalu. Typowanie wymagało
> > dużo "bezrozumnego" poprawiania kodu.
>
> Ale przynajmniej wiedziałeś gdzie się zmieniło API. Przy typowaniu
> dynamicznym nie masz tej informacji podczas kompilacji.

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?

> Proponuję popisać w paru innych językach (np. w Javie), wtedy zobaczysz
> jaki jest wpływ samej składni na długość kodu. Bo większość operacji
> w przeciętnym kodzie źródłowym tłumaczy się wprost na inne języki,
> a idiomów używa się sporadycznie.

Pisałem w asseblerze x86, Pascalu, Javie, Clipperze, Visual Basicu,
trochę w :C, Perlu i jeszcze paru językach :) Jakoś tak wydaje mi się,
że mam pojęcie przekrojowe :)
Ostatniego Twojego zadanie nie zrozumiałem, sorry :)

On 2011-05-21, jacek2v <jacek2v@gmail.com> wrote:
> On 20 Maj, 10:24, "Stachu 'Dozzie' K."
><doz...@go.eat.some.screws.spammer.invalid> wrote:
>> Oczywiście że nie mówią. Mówią o statyczności typowania, bo o tym
>> dyskutujemy w tej gałęzi. Nadal nie rozumiem co ma do rzeczy "silność"
>> systemu typów.
>
> Wydawało mi się, że cały czas o tym mówisz - o wyższości języka z
> typowaniem, czyli o jego "sile" .

Eeee... Że co? Co ma siła typowania do statyczności typowania?

>> >> > A co to za różnica, że uruchomię zamiast skompiluję? Jeden "ruch"
>> >> > mniej :)
>> >> 1. Uruchomienie może być bardziej kłopotliwe niż sam proces budowania
>> >>    (dla webaplikacji to może być skopiowanie na serwer testowy,
>> >>    przeładowanie serwera, otwarcie przeglądarki i dokopanie się do
>> >>    ekranu którego kod chcesz sprawdzić).
>> > Nigdy i tak musisz uruchomić,
         ^^^
>> Parse error.
>
> Mhh, a ja zawsze myślałem, że programy się pisze by je uruchamiać.

Parse error, znaczy błąd składni. Teraz widzę nawet jaki. Proponuję
używać więcej znaków interpunkcyjnych.

A uruchomienie programu do testów może być (i zwykle jest) bardziej
kłopotliwe niż kompilacja.

>> Nikt ci nie zabrania uruchamiać aplikacji do woli. Etap weryfikacji
>> typów podczas kompilacji to po prostu dodatkowe sprawdzenie, które
>> dochodzi ci praktycznie za darmo.
>
> Nie za darmo. Trzeba wszędzie pisać explicite typ, a to sporo kodu
                                                          ^^^^^^^^^^
> więcej.

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.

>> > Mi. do tego dążą metodyki agile. Przeładowywanie serwera nie jest
>> > konieczne - automat. Skopiowanie na serwer - automat. Otwarcie
>> > przeglądarki - automat po kliknięciu na link.
>>
>> A potem przeklikuj się ręcznie przez wszystkie formularze żeby sprawdzić
>> ich poprawność. Albo napisz automat, który będzie automatyzować klikanie
>> pól (uwaga na AJAX!). Ot, taki dodatkowy kłopot.
>
> Kłopot?, ja uważam, że bez tego to bugów będzie jak "mrówków" :)
> Niezależnie od języka programowania, testy trzeba pisać i wykonywać.
> Automatyczne zwłaszcza w większych aplikacjach lub o wyższych
> wymaganiach co do niezawodności/wydajności są wręcz niezbędne - czyli
> tam gdzie jest większy budżet.

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.

> 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.

>> 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.

Powiedziałbym że to raczej odwrotnie jest: zaufanie testowaniu daje ci
w błędne przekonanie, że program zawsze dobrze działa i inna weryfikacja
jest niepotrzebna.

>> >> Ekstrapolując twoje proponowane podejście "jeden ruch mniej", może
>> >> darujmy sobie testowanie aplikacji? Kolejny ruch mniej.
>> > Dziwna ekstrapolacja - poza zbiór dopuszczalnych wyników :)
>>
>> Właśnie. Do tego prowadzi twój pomysł z opuszczaniem kolejnych kroków
>> budowania softu: do opuszczenia zbioru dopuszczalnych wyników.
>
> To był Twój pomysł, aby nie testować - nie dokręcaj kota ogonem :)

Ty zacząłeś. Ja tylko pociągnąłem twoją ścieżkę dalej, żeby pokazać do
czego prowadzi i że to nic dobrego.

>> >> Ano nie pomoże. Ale statyczna kontrola typów by sporo ułatwiła.
>> > Wydaje mi się, że przy zmiana framework raczej przeszkadza. Kiedyś
>> > spotkałem się z podobnym przypadkiem w Pascalu. Typowanie wymagało
>> > dużo "bezrozumnego" poprawiania kodu.
>>
>> Ale przynajmniej wiedziałeś gdzie się zmieniło API. Przy typowaniu
>> dynamicznym nie masz tej informacji podczas kompilacji.
>
> 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.

>> Proponuję popisać w paru innych językach (np. w Javie), wtedy zobaczysz
>> jaki jest wpływ samej składni na długość kodu. Bo większość operacji
>> w przeciętnym kodzie źródłowym tłumaczy się wprost na inne języki,
>> a idiomów używa się sporadycznie.
>
> Pisałem w asseblerze x86, Pascalu, Javie, Clipperze, Visual Basicu,
> trochę w :C, Perlu i jeszcze paru językach :) Jakoś tak wydaje mi się,
> że mam pojęcie przekrojowe :)

Bo wiesz, jakoś nie widzę tego po tobie.

> Ostatniego Twojego zadanie nie zrozumiałem, sorry :)

Rozumiem że chodzi o to:
#v+
Bo większość operacji w przeciętnym kodzie źródłowym tłumaczy się wprost
na inne języki, a idiomów używa się sporadycznie.
#v-

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 { ?? } ??".

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).

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ść.

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.

-- 
Secunia non olet.
Stanislaw Klekot

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.
>
>
> 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ą? :)

> A uruchomienie programu do testów może być (i zwykle jest) bardziej
> kłopotliwe niż kompilacja.

Ale konieczne.

> 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

> >> > Mi. do tego dążą metodyki agile. Przeładowywanie serwera nie jest
> >> > konieczne - automat. Skopiowanie na serwer - automat. Otwarcie
> >> > przeglądarki - automat po kliknięciu na link.
>
> >> A potem przeklikuj się ręcznie przez wszystkie formularze żeby sprawdzić
> >> ich poprawność. Albo napisz automat, który będzie automatyzować klikanie
> >> pól (uwaga na AJAX!). Ot, taki dodatkowy kłopot.
>
> > Kłopot?, ja uważam, że bez tego to bugów będzie jak "mrówków" :)
> > Niezależnie od języka programowania, testy trzeba pisać i wykonywać.
> > Automatyczne zwłaszcza w większych aplikacjach lub o wyższych
> > wymaganiach co do niezawodności/wydajności są wręcz niezbędne - czyli
> > tam gdzie jest większy budżet.
>
> 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ą"?
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).

> > 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
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ń :)

> >> 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. 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.
Ż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.

> Powiedziałbym że to raczej odwrotnie jest: zaufanie testowaniu daje ci
> w błędne przekonanie, że program zawsze dobrze działa i inna weryfikacja
> jest niepotrzebna.

Nigdy nie osiągniemy "zawsze" :P Możemy jedynie dążyć do tego :)

> 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.

> > 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? :(

> >> Proponuję popisać w paru innych językach (np. w Javie), wtedy zobaczysz
> >> jaki jest wpływ samej składni na długość kodu. Bo większość operacji
> >> w przeciętnym kodzie źródłowym tłumaczy się wprost na inne języki,
> >> a idiomów używa się sporadycznie.
>
> > Pisałem w asseblerze x86, Pascalu, Javie, Clipperze, Visual Basicu,
> > trochę w :C, Perlu i jeszcze paru językach :) Jakoś tak wydaje mi się,
> > że mam pojęcie przekrojowe :)
>
> Bo wiesz, jakoś nie widzę tego po tobie.
A to mnie nie dziwi, bo mnie w ogóle nie widzisz :P. Ale jeśli się
podzieliłeś opinią o mnie, to pozwól, że i ja się podzielę swoją.
Myślę, że nie używałeś zbytnio Pythona, a swoją wiedzę czerpiesz z
teorii.

> Rozumiem że chodzi o to:
> #v+
> Bo większość operacji w przeciętnym kodzie źródłowym tłumaczy się wprost
> na inne języki, a idiomów używa się sporadycznie.
> #v-

Tak, tu się zgadzamy - to znaczy to jest ostatnie zdanie :)

> 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 { ?? } ??".

A teraz mój wredny wtręt: nie tablicy, a listy. Różnica niewielka,
ale ... :)

> 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).

Wybacz, nie zgadzam się z Tobą. Przy tej definicji idiomy i tym
podejściu to każda instrukcja, każdego języka jest idiomem !!!!
Oczywiście wszystko odnosząc do assemblera :)
Moim zdaniem języki programowania powstały po to by się pisało łatwo,
krótko i ... przyjemnie :) Nie po to by programy działały szybciej.

> 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ść.

W Python "idiomów" wg Twojej definicji używa się cały czas. Po co
pisać ciągle te same kawałki kodu?
Ale chyba odeszliśmy od głównego wątku "typowania" :)

> 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.

Pzdr.
Jacek

On 22.05.2011 11:10, jacek2v wrote:
> 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).
>

Ale dlaczego "versus"?
Statyczne typowanie nie zastępuje testów, ale daje dodatkoą weryfikację.
Program ze zgodnymi typami nie musi być poprawny, natomiast program w 
którym typy się nie zgadzają, poprawny nie będzie. Tyle i tylko tyle.

Co do testów - w innym poście tego wątku podałem przykład, będący nieco 
uproszczonym przypadkiem z życia wziętym, gdzie po refaktoringu i zmiany 
API jednej z bibliotek, do produkcji trafił kawałek niepoprawnego kodu 
mimo że testy przechodziły bezbłednie.
Akurat tutaj kontrola typów na etapie kompilacji załatwiłaby sprawę. 
Przy czym nie tweirdzę że jest to panaceum na wszystko.


> 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? :(

Znaczy chcesz pokazać, że jak się spieprzy projekt struktury klas, to 
już nic nie pomoże? Z tym jestem się w stanie zgodzić.

Przy dobrze zaprojektowanych klasach powyższy problem nie wystąpi, a na 
źle zaprojektowane klasy lekarstwem nie jest ani kontrola typów, ani testy.

Pzdr
J.

W dniu 2011-05-22 19:29, zbrodel@tlen.pl pisze:
> On 22.05.2011 11:10, jacek2v wrote:
>> 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).
>>
>
> Ale dlaczego "versus"?
> Statyczne typowanie nie zastępuje testów, ale daje dodatkoą weryfikację.
> Program ze zgodnymi typami nie musi być poprawny, natomiast program w
> którym typy się nie zgadzają, poprawny nie będzie. Tyle i tylko tyle.

Ślicznie powiedziane, jestem za a nawet powiem że 'niepoprawnego' w tym 
sensie programu po prostu nie będzie.

>
> Co do testów - w innym poście tego wątku podałem przykład, będący nieco
> uproszczonym przypadkiem z życia wziętym, gdzie po refaktoringu i zmiany
> API jednej z bibliotek, do produkcji trafił kawałek niepoprawnego kodu
> mimo że testy przechodziły bezbłednie.
> Akurat tutaj kontrola typów na etapie kompilacji załatwiłaby sprawę.
> Przy czym nie tweirdzę że jest to panaceum na wszystko.

To mam na myśli, a bylem jednym z wrzucających tak drażliwy temat. 
Aktualizację biblioteki o "duży" numer wersji mocne typy baaaaardzo 
ułatwiają. Zwykle zmiany funkcjonalności nie są szokujące, ale formalne 
są spore.

On 22 Maj, 19:29, zbro...@tlen.pl wrote:
> On 22.05.2011 11:10, jacek2v wrote:
>
> > 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).
>
> Ale dlaczego "versus"?
versus - miałem na myśli "odnosząc do", czyli testy dają więcej efektu
w stosunku do włożonej pracy

> Statyczne typowanie nie zastępuje testów, ale daje dodatkoą weryfikację.
> Program ze zgodnymi typami nie musi być poprawny, natomiast program w
> którym typy się nie zgadzają, poprawny nie będzie. Tyle i tylko tyle.

Tak to też wcześniej napisałem. Miałem na myśli, że nakład pracy na
pisanie kodu z typowaniem nie opłaca się :)

> Co do testów - w innym poście tego wątku podałem przykład, będący nieco
> uproszczonym przypadkiem z życia wziętym, gdzie po refaktoringu i zmiany
> API jednej z bibliotek, do produkcji trafił kawałek niepoprawnego kodu
> mimo że testy przechodziły bezbłednie.
> Akurat tutaj kontrola typów na etapie kompilacji załatwiłaby sprawę.
> Przy czym nie tweirdzę że jest to panaceum na wszystko.

Tak.

> > 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? :(
>
> Znaczy chcesz pokazać, że jak się spieprzy projekt struktury klas, to
> już nic nie pomoże? Z tym jestem się w stanie zgodzić.

To był przykład dla mojego adversarza, aby łatwiej mu było zrozumieć
co miałem na myśli :)
Nie "nic", unit test pomoże. Ale ile się trzeba napisać by te
typowanie zapisać :)

> Przy dobrze zaprojektowanych klasach powyższy problem nie wystąpi, a na
> źle zaprojektowane klasy lekarstwem nie jest ani kontrola typów, ani testy.

Oczywiście, jak się DOBRZE napisze kod to na pewno będzie DOBRY :)
Nie o to mi chodziło, chodzi o "opłacalność typowania" w kontekście
jakości aplikacji.

Pzdr.

On 24.05.2011 12:55, jacek2v wrote:
> Tak to też wcześniej napisałem. Miałem na myśli, że nakład pracy na
> pisanie kodu z typowaniem nie opłaca się :)

Mam wrażenie, że ten "nakład pracy" jest demonizowany. Programuję 
równolegle w Javie i w Pythonie i akurat konieczność deklarowania typów 
mnie nie boli.

Bonusem jest za to, że kod z deklaracjami typów jest bardziej 
"samodokumentujący" się. Porównaj:

def find_user(users, properties):

z tym:

public User findUser(List<User> users, Map<String, String> properties)



> To był przykład dla mojego adversarza, aby łatwiej mu było zrozumieć
> co miałem na myśli :)
> Nie "nic", unit test pomoże. Ale ile się trzeba napisać by te
> typowanie zapisać :)

Unit test pomoże albo nie. Problem z unit testami jest taki, że podobnie 
jak programy, mogą nie być do końca poprawne, w końcu pisane są przez 
ludzi. Zwłaszcza przy refaktoringu rodzi się niebezpieczeństwo, że nie 
zmodyfikujemy odpowiednio właściwych testów. I co teraz? Napisać 
metatesty sprawdzające poprawność testów?


Pzdr
J.

On 24 Maj, 14:56, zbro...@tlen.pl wrote:
> Mam wrażenie, że ten "nakład pracy" jest demonizowany. Programuję
> równolegle w Javie i w Pythonie i akurat konieczność deklarowania typów
> mnie nie boli.

Nie chcę się spierać, jednego boli, a drugiego nie :) - to też zależy
od preferencji osobistych. Mnie to strasznie wkur..., że muszę
deklarować typy, uważam to za stratę czasu. A to, że nie ma typowania
dopinguje mnie do pisania unit testów, oraz uważniejszego pisania
kodu :) - człowiek potrzebuje czasami trochę motywacji :)
Co do demonizowania to nie wiem czy patrzyłeś na shootout (http://
shootout.alioth.debian.org/u64q/python3.php kolumna code), co prawda
ilości kodu nie wynika tylko z posiadania, czy też braku typowania,
ale jest jedną ze składowych. Liczby też nie oddają dokładnie skali,
dobrze jest popatrzeć na kod. Jako, że wspominasz, że piszesz obecnie
i w Java i Pythonie to będziesz miał w miarę obiektywne spojrzenie.

> Bonusem jest za to, że kod z deklaracjami typów jest bardziej
> "samodokumentujący" się. Porównaj:
>
> def find_user(users, properties):
>
> z tym:
>
> public User findUser(List<User> users, Map<String, String> properties)

Niby nie wiele, ale ... :) razy 2 kodu.
To prawda typowanie w nagłówkach ma dodatkowy bonus bo się w części
"samodokumentuje". Oczywiście można zrobić tak:
def find_user(lst_users, dict_properties): lub tak: def
find_user(users=[], properties={}):
Widziałem też taką konwencję (ta pierwsza) w językach typowanych np.
Pascalu (bodajże Borland to promował) i w Javie.

BTW: Nie lubię "_" w nazwach :) i nie wiem czy przekonam się do nich w
Python :). Dlatego wolę tak:
def findUser(lstUsers, dictProperties):

> Unit test pomoże albo nie. Problem z unit testami jest taki, że podobnie
> jak programy, mogą nie być do końca poprawne, w końcu pisane są przez
> ludzi. Zwłaszcza przy refaktoringu rodzi się niebezpieczeństwo, że nie
> zmodyfikujemy odpowiednio właściwych testów. I co teraz? Napisać
> metatesty sprawdzające poprawność testów?

Myślę, że demonizujesz, ale i masz sporo racji :). Ani typowanie, ani
super/mega testy nie uchronią od błędów w oprogramowaniu. Jedynie mogą
minimalizować prawdopodobieństwo ich wystąpienia. Mi chodzi o to, że
zysk z używania typowania jest nieproporcjonalnie mały w stosunku do
nakładów pracy na jego używanie.
W moim przekonaniu najlepszym sposobem zmniejszenia ilości błędów jest
wielkość kodu źródłowego oraz jego "modularyzacja". Temu służyło
przejście od assemblera do języków wyższych poziomów (mniej kodu
źródłowego), potem moduły/pakiety i programowanie obiektowe
("modularyzacja"). Następnym elementem, który znacząco zmniejsza
(oczywiście moim zdaniem :)) ilość błędów to "łatwość" przejścia od
pisania kodu do jego wykonania. Czym mniej kroków, czym mniej czasu
czekamy na uruchomienie, tym częściej programiście chce się to
robić :). Często dzielimy kod, ekstrahując obecnie robioną
funkcjonalność po to tylko by nie kompilować/uruchamiać całości
aplikacji, z powodu długiego uruchomienia, lub dużej ilości formularzy
do przeklikania - wielokrotnie sam doświadczyłem i widziałem u innych.
De facto robimy w ten sposób unit testy - ale to już inna historia.

Pzdr.
Jacek

On 25.05.2011 10:01, jacek2v wrote:

> To prawda typowanie w nagłówkach ma dodatkowy bonus bo się w części
> "samodokumentuje". Oczywiście można zrobić tak:
> def find_user(lst_users, dict_properties): lub tak: def
> find_user(users=[], properties={}):

Wiem że można, ba, wiedziałem że taki argument padnie ;).
Osobiście w swojej karierze spotkałem się z wypasionymi dokumentami 
określającymi konwencje nazewnicze, których celem było właśnie 
"przemycenie" definicji typu w nazwie argumentu.
Tylko skoro już przemycamy typ argumentu, to fajnie, jak by nam 
kopilator (albo dowolny inny tool) sprawdził zgodność typów przy 
wywołaniach ;)





> BTW: Nie lubię "_" w nazwach :) i nie wiem czy przekonam się do nich w
> Python :). Dlatego wolę tak:
> def findUser(lstUsers, dictProperties):

W pythonie jednak dużo częściej stosuje się konwencję z podkreśleniami, 
a ja staram się dostosować.

Pzdr
J.

On 25 Maj, 13:31, zbro...@tlen.pl wrote:
> On 25.05.2011 10:01, jacek2v wrote:
>
> > To prawda typowanie w nagłówkach ma dodatkowy bonus bo się w części
> > "samodokumentuje". Oczywiście można zrobić tak:
> > def find_user(lst_users, dict_properties): lub tak: def
> > find_user(users=[], properties={}):
>
> Wiem że można, ba, wiedziałem że taki argument padnie ;).
> Osobiście w swojej karierze spotkałem się z wypasionymi dokumentami
> określającymi konwencje nazewnicze, których celem było właśnie
> "przemycenie" definicji typu w nazwie argumentu.
> Tylko skoro już przemycamy typ argumentu, to fajnie, jak by nam
> kopilator (albo dowolny inny tool) sprawdził zgodność typów przy
> wywołaniach ;)

Do Javy był tool co sprawdzał konwencje nazewnicze (ale nie zgodność
typów :)), możliwe, że Pythona też jest - jeszcze żadnego nie
namierzyłem.
BTW: Mimo to, bez krótkiego opisu funkcji: "do czego ona jest" nie
obejdzie się.

> > BTW: Nie lubię "_" w nazwach :) i nie wiem czy przekonam się do nich w
> > Python :). Dlatego wolę tak:
> > def findUser(lstUsers, dictProperties):
>
> W pythonie jednak dużo częściej stosuje się konwencję z podkreśleniami,
> a ja staram się dostosować.

Wiem, ale jeszcze minie trochę czasu (parę lat?:)) zanim wrócę do
"podłóg" :) - kiedyś wypleniłem w sobie "_" i jakoś trudno wrócić.
Zawsze to jeden znak więcej :D

Pzdr.
Jacek

On Wed, 25 May 2011 01:01:55 -0700 (PDT)
jacek2v <jacek2v@gmail.com> wrote:

> lub tak: def find_user(users=[], properties={}):

To nie jest do końca dobry sposób:

>>> def foo(a, l=[]):
...     l.append(a)
...     return l
... 
>>> foo(1)
[1]
>>> foo(2)
[1, 2]
>>> foo(3)
[1, 2, 3]
>>> 

W pewnych warunkach, argumenty domyślne będące mutowalnymi obiektami
mogą zachowywać się w sposób nie taki, jaki wydawać by się mogło że
powinny. W takim przypadku lepiej inicjalizować Nonem i w docstringu
opisać czym dany argument jest.

-- 
      -^-  _        coś tam w tle sobie gra, np:
   _ /O)_\//        Hocico - cuando la maldad despierta
  (_(|__(_(_) grf.  

On Wed, 25 May 2011 07:09:55 -0700 (PDT)
jacek2v <jacek2v@gmail.com> wrote:

> Do Javy był tool co sprawdzał konwencje nazewnicze (ale nie zgodność
> typów :)), możliwe, że Pythona też jest - jeszcze żadnego nie
> namierzyłem.

Wiem, ze to nie do końca to czego oczekujesz, ale częściowo pomagają
narzędzia typu pep8[1], pyflakes[2] i pylint[3]. Zwłaszcza pep8
opierniczy za każde odstępstwo od PEP8[4]. Nie sprawdzą typów, a
jedynie styl i błędy wynikające ze statycznej analizy kodu.

> BTW: Mimo to, bez krótkiego opisu funkcji: "do czego ona jest" nie
> obejdzie się.

Uważam, że dokumentowanie kodu (modułów, klas i funkcji) to dobry
zwyczaj. Parę słów komentarza w docstringu nie boli, a po paru latach
spełnia swoje zadanie, bez konieczności analizowania ciała
modułu/klasy/funkcji.

[1] http://pypi.python.org/pypi/pep8
[2] http://pypi.python.org/pypi/pyflakes
[3] http://www.logilab.org/857
[4] http://www.python.org/dev/peps/pep-0008/

-- 
      -^-  _        coś tam w tle sobie gra, np:
   _ /O)_\//        Hocico - Without a God
  (_(|__(_(_) grf.  

On 25 Maj, 20:20, Roman Dobosz <gryf_esm...@spam-o2.pl> wrote:
> On Wed, 25 May 2011 01:01:55 -0700 (PDT)
>
> jacek2v <jace...@gmail.com> wrote:
> > lub tak: def find_user(users=[], properties={}):
>
> To nie jest do końca dobry sposób:
>
> >>> def foo(a, l=[]):
>
> ...     l.append(a)
> ...     return l
> ...
>
> >>> foo(1)
> [1]
> >>> foo(2)
> [1, 2]
> >>> foo(3)
> [1, 2, 3]
>
> W pewnych warunkach, argumenty domyślne będące mutowalnymi obiektami
> mogą zachowywać się w sposób nie taki, jaki wydawać by się mogło że
> powinny. W takim przypadku lepiej inicjalizować Nonem i w docstringu
> opisać czym dany argument jest.

Rzeczywiście można sobie kuku zrobić :) Te zakresy zmienny to raczej
do poprawki - i przy okazji "self" mogliby "wykarczować" :)
Dzięki.

J.

On 25 Maj, 21:20, jacek2v <jace...@gmail.com> wrote:
> On 25 Maj, 20:20, Roman Dobosz <gryf_esm...@spam-o2.pl> wrote:
>
>
>
>
>
>
>
>
>
> > On Wed, 25 May 2011 01:01:55 -0700 (PDT)
>
> > jacek2v <jace...@gmail.com> wrote:
> > > lub tak: def find_user(users=[], properties={}):
>
> > To nie jest do końca dobry sposób:
>
> > >>> def foo(a, l=[]):
>
> > ...     l.append(a)
> > ...     return l
> > ...
>
> > >>> foo(1)
> > [1]
> > >>> foo(2)
> > [1, 2]
> > >>> foo(3)
> > [1, 2, 3]
>
> > W pewnych warunkach, argumenty domyślne będące mutowalnymi obiektami
> > mogą zachowywać się w sposób nie taki, jaki wydawać by się mogło że
> > powinny. W takim przypadku lepiej inicjalizować Nonem i w docstringu
> > opisać czym dany argument jest.
>
> Rzeczywiście można sobie kuku zrobić :) Te zakresy zmienny to raczej
> do poprawki - i przy okazji "self" mogliby "wykarczować" :)
> Dzięki.

Chociaż po chwili namysł to nie problem zakresu zmiennej, tylko jakiś
błąd inicjacji parametru ?

On 25 Maj, 20:28, Roman Dobosz <gryf_esm...@spam-o2.pl> wrote:
> On Wed, 25 May 2011 07:09:55 -0700 (PDT)
>
> jacek2v <jace...@gmail.com> wrote:
> > Do Javy był tool co sprawdzał konwencje nazewnicze (ale nie zgodność
> > typów :)), możliwe, że Pythona też jest - jeszcze żadnego nie
> > namierzyłem.
>
> Wiem, ze to nie do końca to czego oczekujesz, ale częściowo pomagają
> narzędzia typu pep8[1], pyflakes[2] i pylint[3]. Zwłaszcza pep8
> opierniczy za każde odstępstwo od PEP8[4]. Nie sprawdzą typów, a
> jedynie styl i błędy wynikające ze statycznej analizy kodu.

Właśnie o to chodziło, dzięki. Takie narzędzia przydatne dla większych
zespołów, co by "dyscyplinę kodu" trzymać :)

J.

On 05/25/11 21:25, jacek2v wrote:
> On 25 Maj, 21:20, jacek2v <jace...@gmail.com> wrote:
>> On 25 Maj, 20:20, Roman Dobosz <gryf_esm...@spam-o2.pl> wrote:
[...]
>>> W pewnych warunkach, argumenty domyślne będące mutowalnymi obiektami
>>> mogą zachowywać się w sposób nie taki, jaki wydawać by się mogło że
>>> powinny. W takim przypadku lepiej inicjalizować Nonem i w docstringu
>>> opisać czym dany argument jest.
>>
>> Rzeczywiście można sobie kuku zrobić :) Te zakresy zmienny to raczej
>> do poprawki - i przy okazji "self" mogliby "wykarczować" :)
>> Dzięki.
> 
> Chociaż po chwili namysł to nie problem zakresu zmiennej, tylko jakiś
> błąd inicjacji parametru ?

To nie żaden błąd tylko naturalna konsekwencja tego, że wszystko jest
obiektem. Funkcja też. Jest singletonem, instancją klasy function.
Domyślne parametry są jej atrybutami.

Interpreter nie może w żaden sposób zgadnąć czy te atrybuty są mutowalne
czy nie. Nawet gdyby mógł to pozostała by kwestia, czy przy każdym
odpaleniu zrobić płytkie czy głębokie kopiowanie (i też pojawiłyby się
pewnie skutki uboczne).

Przyjęte rozwiązanie jest najprostsze i najłatwiejsze do zrozumienia.
Trzeba tylko pamiętać, że funkcje, klasy (w tym przypadku można nawet
pomajstrować z typem tego obiektu za pomocą metaklas), docstringi itp są
singletonowymi obiektami. Dowód poniżej:

>>> def foo(bar=[], baz='test'):
...     print bar, baz

>>> type(foo)
<type 'function'>

>>> foo
<function foo at 0x7f377e5e1758>

>>> foo.func_defaults
([], 'test')

>>> foo.func_code
<code object foo at 0x7f377e5dfa80, file "<stdin>", line 1>

>>> foo.__call__
<method-wrapper '__call__' of function object at 0x7f377e5e1758>

>>> foo.__call__()
[] test


Pozdrawiam,
Wojciech Malinowski

Roman Dobosz wrote:

> [1] http://pypi.python.org/pypi/pep8
> [2] http://pypi.python.org/pypi/pyflakes
> [3] http://www.logilab.org/857

Dzięki za te linki. Zawsze lepiej widzieć we własnym kodzie co jest nie tak.
Zastanawia mnie tylko czemu nadal utrzymywane jest ograniczenie długości 
linii.

Pozdrawiam
Dsue

On 2011-05-26, Dsue <dsue@na.onecie> wrote:
> Roman Dobosz wrote:
>
>> [1] http://pypi.python.org/pypi/pep8
>> [2] http://pypi.python.org/pypi/pyflakes
>> [3] http://www.logilab.org/857
>
> Dzięki za te linki. Zawsze lepiej widzieć we własnym kodzie co jest nie tak.
> Zastanawia mnie tylko czemu nadal utrzymywane jest ograniczenie długości 
> linii.

a) Linia długa na 150 znaków brzydko wygląda.
b) Linię długą na 150 znaków czyta się źle.
c) Jeśli masz linię na 150 znaków, to znak że zbyt dużo robisz w tej
   linii. To obniża czytelność kodu.
d) Niektórzy nadal drukują (!) kod źródłowy. Linia 150-znakowa łamie się
   w losowym miejscu, co się z wydruku *bardzo źle* czyta.
e) Większość tekstu w kodzie ciąży w kierunku lewego marginesu. Przy 150
   znakach w jednym wystającym wierszu skaczesz wzrokiem po zbyt dużej
   powierzchni ekranu.
f) Jeśli masz wiersz wystający na 150 znaków, to marnujesz miejsce
   ekranu z prawej strony. Znam pożyteczniejsze metody zapełnienia
   ekranu niż zużywanie ledwie 1/3 (albo i mniej) na kod.

-- 
Secunia non olet.
Stanislaw Klekot

Stachu 'Dozzie' K. wrote:

> a) Linia długa na 150 znaków brzydko wygląda.

Zgadzam się, chociaż:

def funkcja(bardzo_dlugi_parametr_1,
	bardzo_dlugi_parametr_2,
	bardzo_dlugi_parametr_3,
	bardzo_dlugi_parametr_4,
	bardzo_dlugi_parametr_5)

też nienajlepiej IMHO.

> b) Linię długą na 150 znaków czyta się źle.

jw.

> f) Jeśli masz wiersz wystający na 150 znaków, to marnujesz miejsce
>    ekranu z prawej strony. Znam pożyteczniejsze metody zapełnienia
>    ekranu niż zużywanie ledwie 1/3 (albo i mniej) na kod.

O i to jest argument. Mając na ekranie panel lewy z listą 
plików/obiektów/symboli i panel prawy z helpem na przykład, na srodku 
zostaje niezawiele miejsca. Tak, to mnie przekonuje.

Pozdrawiam
Dsue

On Thu, 26 May 2011 10:56:23 +0000 (UTC)
"Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> wrote:

> > Dzięki za te linki. Zawsze lepiej widzieć we własnym kodzie co jest nie tak.
> > Zastanawia mnie tylko czemu nadal utrzymywane jest ograniczenie długości 
> > linii.
> 
> a) Linia długa na 150 znaków brzydko wygląda.
> b) Linię długą na 150 znaków czyta się źle.
> c) Jeśli masz linię na 150 znaków, to znak że zbyt dużo robisz w tej
>    linii. To obniża czytelność kodu.
> d) Niektórzy nadal drukują (!) kod źródłowy. Linia 150-znakowa łamie się
>    w losowym miejscu, co się z wydruku *bardzo źle* czyta.
> e) Większość tekstu w kodzie ciąży w kierunku lewego marginesu. Przy 150
>    znakach w jednym wystającym wierszu skaczesz wzrokiem po zbyt dużej
>    powierzchni ekranu.
> f) Jeśli masz wiersz wystający na 150 znaków, to marnujesz miejsce
>    ekranu z prawej strony. Znam pożyteczniejsze metody zapełnienia
>    ekranu niż zużywanie ledwie 1/3 (albo i mniej) na kod.

g) Oglądanie linii 150 znakowych w przypadku diffa side-by-side jest
   uciążliwe (nie wspominając o porównywaniu trzech plików).
h) Wąskie teksty lepiej się czyta, co ma swoje zastosowanie chociażby
   w gazetach (gdzie strona podzielona jest na szpalty).

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

(26.05.2011 15:52), Roman Dobosz wrote:
> On Thu, 26 May 2011 10:56:23 +0000 (UTC)
> "Stachu 'Dozzie' K." <dozzie@go.eat.some.screws.spammer.invalid> wrote:
> 
>>> Dzięki za te linki. Zawsze lepiej widzieć we własnym kodzie co jest nie tak.
>>> Zastanawia mnie tylko czemu nadal utrzymywane jest ograniczenie długości 
>>> linii.
>>
>> a) Linia długa na 150 znaków brzydko wygląda.
>> b) Linię długą na 150 znaków czyta się źle.
>> c) Jeśli masz linię na 150 znaków, to znak że zbyt dużo robisz w tej
>>    linii. To obniża czytelność kodu.
>> d) Niektórzy nadal drukują (!) kod źródłowy. Linia 150-znakowa łamie się
>>    w losowym miejscu, co się z wydruku *bardzo źle* czyta.
>> e) Większość tekstu w kodzie ciąży w kierunku lewego marginesu. Przy 150
>>    znakach w jednym wystającym wierszu skaczesz wzrokiem po zbyt dużej
>>    powierzchni ekranu.
>> f) Jeśli masz wiersz wystający na 150 znaków, to marnujesz miejsce
>>    ekranu z prawej strony. Znam pożyteczniejsze metody zapełnienia
>>    ekranu niż zużywanie ledwie 1/3 (albo i mniej) na kod.
> 
> g) Oglądanie linii 150 znakowych w przypadku diffa side-by-side jest
>    uciążliwe (nie wspominając o porównywaniu trzech plików).
> h) Wąskie teksty lepiej się czyta, co ma swoje zastosowanie chociażby
>    w gazetach (gdzie strona podzielona jest na szpalty).
> 

Mógłby to ktoś przetłumaczyć i rzucić gdzieś Komuś Kto Ustala Coding
Standards w Drupalu? (wiem wiem, nie ta grupa). Tam sobie radośnie
ustalili że "linii nie łamiemy, choćby to było nie wiadomo jak długie
zapytanie SQL".

p. m.

On 25 Maj, 22:13, Wojciech Malinowski <vir...@wp.pl> wrote:
> To nie żaden błąd tylko naturalna konsekwencja tego, że wszystko jest
> obiektem. Funkcja też. Jest singletonem, instancją klasy function.
> Domyślne parametry są jej atrybutami.
>
> Interpreter nie może w żaden sposób zgadnąć czy te atrybuty są mutowalne
> czy nie. Nawet gdyby mógł to pozostała by kwestia, czy przy każdym
> odpaleniu zrobić płytkie czy głębokie kopiowanie (i też pojawiłyby się
> pewnie skutki uboczne).
>
> Przyjęte rozwiązanie jest najprostsze i najłatwiejsze do zrozumienia.
> Trzeba tylko pamiętać, że funkcje, klasy (w tym przypadku można nawet
> pomajstrować z typem tego obiektu za pomocą metaklas), docstringi itp są
> singletonowymi obiektami. Dowód poniżej:
>
> >>> def foo(bar=[], baz='test'):
>
> ...     print bar, baz
>
> >>> type(foo)
>
> <type 'function'>
>
> >>> foo
>
> <function foo at 0x7f377e5e1758>
>
> >>> foo.func_defaults
>
> ([], 'test')
>
> >>> foo.func_code
>
> <code object foo at 0x7f377e5dfa80, file "<stdin>", line 1>
>
> >>> foo.__call__
>
> <method-wrapper '__call__' of function object at 0x7f377e5e1758>
>
> >>> foo.__call__()
>
> [] test

Dzięki za wyjaśnienie. Muszę przyznać, że jak to wielokrotnie bywało
logika Pythona jest niezaprzeczalna, powalająca i miła memu sercu :)

On 05/26/11 21:00, jacek2v wrote:
> Dzięki za wyjaśnienie. Muszę przyznać, że jak to wielokrotnie bywało
> logika Pythona jest niezaprzeczalna, powalająca i miła memu sercu :)

Nie ma sprawy.

BTW Skoro nikt się nie pofatygował sprostować tego co napisałem to sam
sprostuję: funkcje nie są singletonami. Są normalnymi instancjami klasy
function.

Pozdrawiam,
Wojciech Malinowski

On 26 Maj, 21:16, Wojciech Malinowski <vir...@wp.pl> wrote:
> On 05/26/11 21:00, jacek2v wrote:
>
> > Dzięki za wyjaśnienie. Muszę przyznać, że jak to wielokrotnie bywało
> > logika Pythona jest niezaprzeczalna, powalająca i miła memu sercu :)
>
> Nie ma sprawy.
>
> BTW Skoro nikt się nie pofatygował sprostować tego co napisałem to sam
> sprostuję: funkcje nie są singletonami. Są normalnymi instancjami klasy
> function.

Myślę, że się nie pomyliłeś. To jest singleton w rozumieniu tylko
"jedna instancja danej klasy".

Dnia 27-05-2011 o 12:48:58 jacek2v <jacek2v@gmail.com> napisał(a):

> On 26 Maj, 21:16, Wojciech Malinowski <vir...@wp.pl> wrote:
>> On 05/26/11 21:00, jacek2v wrote:
>>
>> > Dzięki za wyjaśnienie. Muszę przyznać, że jak to wielokrotnie bywało
>> > logika Pythona jest niezaprzeczalna, powalająca i miła memu sercu :)
>>
>> Nie ma sprawy.
>>
>> BTW Skoro nikt się nie pofatygował sprostować tego co napisałem to sam
>> sprostuję: funkcje nie są singletonami. Są normalnymi instancjami klasy
>> function.
>
> Myślę, że się nie pomyliłeś. To jest singleton w rozumieniu tylko
> "jedna instancja danej klasy".

obawiam się, że albo Cię nie rozumiem, albo nie masz jednak racji: mi  
wychodzi, że funkcje są tej samej klasy, nie jest generowana oddzielna  
klasa dla każdej funkcji, a dopiero wtedy bym uznał określenie „singleton”  
za zasadne.


Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit  
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo():
...     pass
...
>>> def bar():
...     pass
...
>>> type(foo) is type(bar)
True
>>> foo.__class__ is bar.__class__
True
>>> type(foo)
<type 'function'>
>>>


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
...
>>> def bar():
...     pass
...
>>> type(foo)
<class 'function'>
>>> type(foo) is type(bar)
True
>>> foo.__class__ is bar.__class__
True
>>>

-- 
Jordan Szubert

On 27 Maj, 16:40, "Jordan Szubert" <use...@joru.us.to> wrote:
> Dnia 27-05-2011 o 12:48:58 jacek2v <jace...@gmail.com> napisał(a):
> obawiam się, że albo Cię nie rozumiem, albo nie masz jednak racji: mi  
> wychodzi, że funkcje są tej samej klasy, nie jest generowana oddzielna  
> klasa dla każdej funkcji, a dopiero wtedy bym uznał określenie "singleton"  
> za zasadne.

> Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit  
> (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.>>> def foo():
>
> ...     pass
> ...>>> def bar():
>
> ...     pass
> ...
>
> >>> type(foo) is type(bar)
> True
> >>> foo.__class__ is bar.__class__
> True
> >>> type(foo)
> <type 'function'>
>

Ok. Twój dowód do mnie przemawia :) Aczkolwiek :) podejrzane jest :
> issubclass(type(foo), type(object))
False
Pzdr.

Dnia 28-05-2011 o 15:48:40 jacek2v <jacek2v@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

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 :)