🚀 go-pugleaf

Zbigniew pisze:
> Witam,
> 
> mam taki prosty kod:
> 
>     import sys
> 
>     if __name__ == "__main__":
>         print 'Platform: %s' % sys.platform
>         print 'Ala ma kota - test'
>         ALA
> 
> Oczywiście program nie zadziała:
>     Traceback (most recent call last):
>       File "ala.py", line 9, in <module>
>         ALA
>     NameError: name 'ALA' is not defined
> 
> Czy znacie jakąś możliwość analizy (celowo nie używam słowa
> 'kompilacja') kodu pod względem poprawności ZANIM zostanie
> uruchomiony?
Co więcej, zanim zostanie uruchoniony I URUCHOMIONE wszystkie ścieżki. 
Kiedyś, dawno temu miałem program Środki Trwałe w interpretowanym 
Clipperze - niektóre ścieżki się wykonywały raz do roku i to pod 
warunkiem że 'x'. Horror.

> Jak sobie radzicie z tego typu problemami w kodzie produkcyjnym
> złożonym z wielu modułów?
Z całym szacunkiem dla skryptów: wielkie programy piszemy w języku 
kompilowanym i to mocno typowanym np. Java 5. Mimo, że to "wiek 
skryptów", co kompilacja to kompilacja.

W interpreterze nie jest to nigdy rozwiązywalne, co pokazują funkcje 
zwykle nazywane eval (oraz cała ta miękka otoczka).

Co nie znaczy, że nie sympatyzuję i nie używam skryptów, nawet chętnie 
je wbudowuję w kompilowane apliakcje (C/Java), ale w filozofii mały 
skrypt w dużej kompilowanej całości.

Cholera znów doradziłem komuś jak rabin.

At Sat, 18 Jul 2009 06:31:17 -0700 (PDT), Zbigniew wrote:

> Czy znacie jakąś możliwość analizy (celowo nie używam słowa
> 'kompilacja') kodu pod względem poprawności ZANIM zostanie
> uruchomiony?

pylint na przyklad

> Jak sobie radzicie z tego typu problemami w kodzie produkcyjnym
> złożonym z wielu modułów?

Pisze i regularnie odpalam testy. Jesli jakis nietrywialny fragment
kodu nie jest urchamiany przez choc jeden test, to uwazam to za blad
w swoim kodzie. Oczywiscie moj kod jest pelen takich bledow :)

-- 
Radomir Dopieralski, http://sheep.art.pl

Zbigniew <zbika73@googlemail.com> writes:

> Witam,
>
> mam taki prosty kod:
>
>     import sys
>
>     if __name__ == "__main__":
>         print 'Platform: %s' % sys.platform
>         print 'Ala ma kota - test'
>         ALA
>
> Oczywiście program nie zadziała:
>     Traceback (most recent call last):
>       File "ala.py", line 9, in <module>
>         ALA
>     NameError: name 'ALA' is not defined
>
> Czy znacie jakąś możliwość analizy (celowo nie używam słowa
> 'kompilacja') kodu pod względem poprawności ZANIM zostanie
> uruchomiony?

W Emacsie mam podłączoną taką kontrolę w locie z użyciem
Pyflakes [1]_. Błędna linia jest podświetlona na czerwono
i u dołu widzę komentarz: "undefined name 'ALA'"
Z poziomu konsoli to wygląda tak:
$ pyflakes test_err.py
test_err.py:7: undefined name 'ALA'

Chyba każdy edytor ma możliwość podłączenia takiej kontroli,
a więc czym prędzej do dzieła.

.. [1] http://www.divmod.org/trac/wiki/DivmodPyflakes

RW

Dnia sobota, 18 lipca 2009 15:31, Zbigniew napisał(a):

> Czy znacie jakąś możliwość analizy (celowo nie używam słowa
> 'kompilacja') kodu pod względem poprawności ZANIM zostanie
> uruchomiony?
pylint - python code static checker and UML diagram generator
pychecker - Finds common bugs in Python source code
pyflakes - passive checker of Python programs
...

Polecam pylint, jeśli nie można, to pyflakes.

> 
> Jak sobie radzicie z tego typu problemami w kodzie produkcyjnym
> złożonym z wielu modułów?
>
Testy (tutaj pydoc unittest).

-- 
Arkadiusz Kindziuk

At Sat, 18 Jul 2009 16:00:03 +0200, Jacek Czerwinski wrote:

> Zbigniew pisze:
>> Jak sobie radzicie z tego typu problemami w kodzie produkcyjnym
>> złożonym z wielu modułów?

> Z całym szacunkiem dla skryptów: wielkie programy piszemy w języku 
> kompilowanym i to mocno typowanym np. Java 5. Mimo, że to "wiek 
> skryptów", co kompilacja to kompilacja.

Kontrola typow nie wylapie wszystkich bledow, co doskonale pokazuje
jezyk C ze swoim powszechnym "off by one". Oczywiscie, mozna dodawac
kolejne testy, zaczynajac od tych najbardziej ogolnych az do bardzo
specyficznych dla danego zastosowania i stylu pisania. Tylko z jakiej
racji ma to robic kompilator, ktory nie jest w najlepszej pozycji do
testowania kodu? Lepiej zrobic to programem, ktory naprawde moze
przetestowac fragment kodu, uruchomic go dla istotnych danych,
zweryfikowac poprawnosc wynikow.

Jesli brakuje dyscypliny, to zawsze mozna sobie napisac skrypt "kompiluj",
ktory odpali testy, sprawdzi pokrycie nimi kodu, a nastepnie odmowi
dalszej wspolpracy jesli jedno albo drugie bedzie niezadawalajace.
Niektorzy nawet lubia takie cos sobie do commit hooka dopisywac.

-- 
Radomir Dopieralski, http://sheep.art.pl

At Sat, 18 Jul 2009 16:43:57 +0200, Arkadiusz 'nare' Kindziuk wrote:

> Dnia sobota, 18 lipca 2009 15:31, Zbigniew napisał(a):
>
>> Czy znacie jakąś możliwość analizy (celowo nie używam słowa
>> 'kompilacja') kodu pod względem poprawności ZANIM zostanie
>> uruchomiony?
> pylint - python code static checker and UML diagram generator
> pychecker - Finds common bugs in Python source code
> pyflakes - passive checker of Python programs
> ...
>
> Polecam pylint, jeśli nie można, to pyflakes.
>
>> 
>> Jak sobie radzicie z tego typu problemami w kodzie produkcyjnym
>> złożonym z wielu modułów?
>>
> Testy (tutaj pydoc unittest).

Kolega mial chyba na mysli doctest? Albo epydoc? (ale to do dokumentacji)

Osobiscie bardzo polecam nowy py.test, z parametrami do testow i
setup/teardown dla kazdego parametru osobno. Ma tez plugin do doctest.

-- 
Radomir Dopieralski, http://sheep.art.pl

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

>> Czy znacie jakąś możliwość analizy (celowo nie używam słowa
>> 'kompilacja') kodu pod względem poprawności ZANIM zostanie
>> uruchomiony?
> Co więcej, zanim zostanie uruchoniony I URUCHOMIONE wszystkie
> ścieżki. Kiedyś, dawno temu miałem program Środki Trwałe w
> interpretowanym Clipperze - niektóre ścieżki się wykonywały raz do
> roku i to pod warunkiem że 'x'. Horror.
>
>> Jak sobie radzicie z tego typu problemami w kodzie produkcyjnym
>> złożonym z wielu modułów?
> Z całym szacunkiem dla skryptów: wielkie programy piszemy w języku
> kompilowanym i to mocno typowanym np. Java 5. Mimo, że to "wiek
> skryptów", co kompilacja to kompilacja.

Python jest i kompilowany (do bajtkodu):

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

i ma też mocne typy:

$ python -c "1 + 'a'"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'

Zapewne argumentujesz, że statyczne typowanie to jest panaceum
na wszelkie zło.

Naprawdę chciałbym żeby tak było, a przynajmniej w tych mainstreamowych
językach. Jednak przestałem się już oszukiwać jakiś czas temu.
Statyczne typowanie daje takie same gwarancje, jak jazda w oponach zimowych
po idealnie gładkiej tafli lodu. Niby "zimowe", ale co z tego?
Mówiąc bez metafor nie daje absolutnie żadnej gwarancji co do
poprawności programu.
Jedynym punktem odniesienia są testy i jeszcze raz testy.

> W interpreterze nie jest to nigdy rozwiązywalne, co pokazują funkcje
> zwykle nazywane eval (oraz cała ta miękka otoczka).

Jak ktoś się bawi zapałkami, to może się poparzyć. To samo dotyczy
wskaźników czy rzutowań w innym znanym nam języku.

> Co nie znaczy, że nie sympatyzuję i nie używam skryptów, nawet chętnie
> je wbudowuję w kompilowane apliakcje (C/Java), ale w filozofii mały
> skrypt w dużej kompilowanej całości.

Ta filozofia pokutuje w narodzie, choć nie ma żadnego uzasadnienia. 
Rozdęcie statycznie typowanego kodu do granic możliwości bynajmniej 
niczego nie ułatwia (w domyśle Java, absolutny lider w tym temacie).
Zgrabne, łatwe w ogarnięciu i testowaniu biblioteki Pythona
są zaletą, a nie wadą.
Choćby zachwalana przez Ciebie Java nie ma czegoś tak użytecznego
jak funkcje wyższego rzędu. Tworzenie interfejsu i ich implementacji
dla najdrobniejszej nawet funkcjonalności, to jest dopiero porażka
i utrudnienie w rozwijaniu projektu. Któregoś dnia odpalasz swoje
IDE (tak w Javie bez IDE ani rusz), widzisz tysiące interfejsów
i zachodzisz w głowę po jaką cholerę mi tyle tego badziewia?
Poza tym ten wszechobecny "boilerplate" i "Copy-Paste pattern".
Polecam ten artykuł:
http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html

> Cholera znów doradziłem komuś jak rabin.

Twoje drugie "ja" nie daje za wygraną. ;)

RW

W dniu 18.07.2009 18:04, Radomir Dopieralski pisze:

> Kolega mial chyba na mysli doctest? Albo epydoc? (ale to do dokumentacji)

pydoc to polecenie, które pokazuje dokumentację modułów (coś w stylu man 
do pythona)

M.

Radomir Dopieralski pisze:
> At Sat, 18 Jul 2009 16:00:03 +0200, Jacek Czerwinski wrote:
> 
>> Zbigniew pisze:
>>> Jak sobie radzicie z tego typu problemami w kodzie produkcyjnym
>>> złożonym z wielu modułów?
> 
>> Z całym szacunkiem dla skryptów: wielkie programy piszemy w języku 
>> kompilowanym i to mocno typowanym np. Java 5. Mimo, że to "wiek 
>> skryptów", co kompilacja to kompilacja.
> 
> Kontrola typow nie wylapie wszystkich bledow, co doskonale pokazuje
> jezyk C ze swoim powszechnym "off by one". 
To już wiem dlaczego pokochałem nowe pętle Javy 5 z iteratorami ;)
Czy ja w jakimkolwiek stopniu odnosiłem się do dziadka C?

Pewnie że nie wyłapie, ale wyłapie 98% literówek, a to było 
spostrzeżeniem P.P.

 > Oczywiscie, mozna dodawac
> kolejne testy, zaczynajac od tych najbardziej ogolnych az do bardzo
> specyficznych dla danego zastosowania i stylu pisania. 
Z szacunkiem do testów (powiedzieć by wypadało, że to epoka testów), ale 
czasem mi sie wydaje że przybliżamy do czegoś, co już przerabialiśmy, do 
religijnej wiary w dowodzenie poprawności z całą otoczką. Małymi 
literami potem uznano nieprzydatność w każdym realnej wielkości projekcie.

Automatyczne testy nie są jedyną metodą pro-niezawodnościową (późną porą 
mam przed oczami weryfikacje przez drugą czepialską parę oczu), ale to 
już odchodzimy trochę od wątku. W każdym razie porządny język (tu nie 
dzielę sztywno na kompilowanie i interpretowane (choć nadal punktuję na 
rzecz kompilowanych), i tu szanuje Pythona) ukazuje czytelniej w 
przeglądzie miejsca z problemem. Dziadowski język bardziej je chowa.

Im bardziej na kolanie i na tempo, tym bardziej się przydaje twardy 
kompilowany język - łatwiej i stawia przed oczy moje bzdury nie tylko na 
poziomie "prostego kodowania" ale aż do <neologizm>dolnego poziomu 
projektowego</neologizm> (np. strzelę: niedostępność takiej informacji , 
lub tak opakowanej, jakiej potrzebuję).
Na pewno w interpreterze bym nie kodował o godzinie 23:10 ;)

--------------
Rob Wolfe pisze:

 >
 > Python jest i kompilowany (do bajtkodu):
W kwestii formalnej kompilacja ma różne 'kolory'. Kompilacja do 
jakichkolwiek bajtów ale w semantyce np. zmiennych na sposób 
interpretera da tem sam poziom wykrywania literówek w zmiennych.
Gdzieś w kręgu grooviego było to wytłumaczone dla blondynek: kompilujemy 
do tej samej JVM (co duża siostra) a zmienne mamy 'na sposób 
interpretera'. W sensie pytania taka kompilacja niewiele lub nic nie daje.

Co do bezwzględnej wiary w testy akcentuję tu trochę inaczej (było wyżej).

Nie neguję reszty postu Rob'a. Python jest jednym z elegantszych 
języków, skuteczny w wyrażaniu "ilości linii sursu/ideę". (Dodałbym 
promowanie jednego najlepszego sposobu "jak to zrobić" a nie fesnantu) 
Tak rozumiana skuteczność języka polepsza "ludzkie" elementy 
niezawodności, m.in. jak się już rzekło z przeglądem kodu. No ale 
przegląd to nieco inne (wyższe) obszary niż literówki.

Dnia sobota, 18 lipca 2009 18:04, Radomir Dopieralski napisał(a):

>>>
>> Testy (tutaj pydoc unittest).
> 
> Kolega mial chyba na mysli doctest? Albo epydoc? (ale to do
> dokumentacji)
>
Nie, przyzwyczajenia z konsoli.
http://docs.python.org/library/pydoc.html
Wyświetli dokumentację o bibliotece do unitestów z standartowej 
biblioteki pythona.
 
> Osobiscie bardzo polecam nowy py.test, z parametrami do testow i
> setup/teardown dla kazdego parametru osobno. Ma tez plugin do doctest.
>

O, nie znałem, będzie trzeba się zapoznać. Debianowa paczka:
| python-codespeak-lib - The pylib library containing py.test, 
| greenlets and other niceties
i homepage http://codespeak.net/py/dist/

Sam do unittestów męczę standartową bibliotekę + czasami nosetests do 
odpalania (w ide mam podpięte tylko testuj cały program, bieżący 
katalog, testy do edytowanego pliku).

-- 
Arkadiusz Kindziuk

On 18 Lip, 15:31, Zbigniew <zbik...@googlemail.com> wrote:
> Jak sobie radzicie z tego typu problemami w kodzie produkcyjnym
> złożonym z wielu modułów?

Osobiście rozbijam kod na małe, testowalne jednostki i katuję unittest
+ coverage.py zintegrowane z PyDevem żeby zobaczyć które ścieżki nie
zostały przetestowane -- przechodzi testy, albo nie ma commitu. Proste
błędy -- takie jak wymieniłeś -- wyłapie bez problemu dowolny static
checker/analyzer z wymienionych.

--
pozdrawiam,
SMG.

At Sat, 18 Jul 2009 23:06:23 +0200, Jacek Czerwinski wrote:

> Radomir Dopieralski pisze:
>> At Sat, 18 Jul 2009 16:00:03 +0200, Jacek Czerwinski wrote:
>>> Zbigniew pisze:

> > Oczywiscie, mozna dodawac
>> kolejne testy, zaczynajac od tych najbardziej ogolnych az do bardzo
>> specyficznych dla danego zastosowania i stylu pisania. 
> Z szacunkiem do testów (powiedzieć by wypadało, że to epoka testów), ale 
> czasem mi sie wydaje że przybliżamy do czegoś, co już przerabialiśmy, do 
> religijnej wiary w dowodzenie poprawności z całą otoczką. Małymi 
> literami potem uznano nieprzydatność w każdym realnej wielkości projekcie.

Pijesz do Dijkstry? Z tego co pamiętam, to on raczej nie był zwolennikiem
testów. Pozwolę sobie zacytować:


    Program testing can be a very effective way to show the presence of
    bugs, but it is hopelessly inadequate for showing their absence. 
    -- EWD, The Humble Programmer (1972)

Zatem odrzucamy matematyczny dowód poprawności, odrzucamy testy i co nam
zostanie? "Mój program jest poprawny bo mój edytor/kompilator tak mówi"?

Z mojego osobistego doświadczenia testy jak najbardziej są przydatne, i to
właśnie im większy projekt, tym bardziej. Rozwiązują one między innymi
właśnie problem literówek, ale także problem psucia odległych fragmentów
kodu poprzez modyfikację kodu od którego są one zależne -- oraz problem
paraliżu wynikającego ze strachu przed takimi modyfikacjami.

> Automatyczne testy nie są jedyną metodą pro-niezawodnościową (późną porą 
> mam przed oczami weryfikacje przez drugą czepialską parę oczu), ale to 
> już odchodzimy trochę od wątku.

Oczywiście, że nie jedyną, ale ośmielę się zaryzykować tezę, że w opisanej
sytuacji (używanie pythona do pisania dużego projektu) jedną z najbardziej
przydatnych.

> W każdym razie porządny język (tu nie 
> dzielę sztywno na kompilowanie i interpretowane (choć nadal punktuję na 
> rzecz kompilowanych), i tu szanuje Pythona) ukazuje czytelniej w 
> przeglądzie miejsca z problemem. Dziadowski język bardziej je chowa.
>
> Im bardziej na kolanie i na tempo, tym bardziej się przydaje twardy 
> kompilowany język - łatwiej i stawia przed oczy moje bzdury nie tylko na 
> poziomie "prostego kodowania" ale aż do <neologizm>dolnego poziomu 
> projektowego</neologizm> (np. strzelę: niedostępność takiej informacji , 
> lub tak opakowanej, jakiej potrzebuję).
> Na pewno w interpreterze bym nie kodował o godzinie 23:10 ;)

Odnoszę wrażenie, że jednak nie trzymasz się trochę tematu. Kolega zapytał
o narzędzia pozwalające łatwiej wyłapywać błędy przy pisaniu w pythonie,
tak aby można było rozwijać średniej wielkości i duże projekty.
Automatyczne testy należą do najbardziej pomocnych w tej sytuacji
narzędzi. Nie uważam, żeby odpowiedź "użyj innego języka" była na miejscu,
szczególnie na tej grupie dyskusyjnej.
-- 
Radomir Dopieralski, http://sheep.art.pl

At Sat, 18 Jul 2009 23:49:06 +0200, Arkadiusz 'nare' Kindziuk wrote:

> Dnia sobota, 18 lipca 2009 18:04, Radomir Dopieralski napisał(a):
>
>>>>
>>> Testy (tutaj pydoc unittest).
>> 
>> Kolega mial chyba na mysli doctest? Albo epydoc? (ale to do
>> dokumentacji)
>>
> Nie, przyzwyczajenia z konsoli.
> http://docs.python.org/library/pydoc.html
> Wyświetli dokumentację o bibliotece do unitestów z standartowej 
> biblioteki pythona.
>  
>> Osobiscie bardzo polecam nowy py.test, z parametrami do testow i
>> setup/teardown dla kazdego parametru osobno. Ma tez plugin do doctest.
>>
>
> O, nie znałem, będzie trzeba się zapoznać. 

Upewnij się, że używasz wersji co najmniej 1.0.0b6
Poprzednie wersje to taki nose z odrobina magii.

-- 
Radomir Dopieralski, http://sheep.art.pl

On 2009-07-18, Rob Wolfe <rw@smsnet.pl> wrote:
> Zbigniew <zbika73@googlemail.com> writes:
>
>> [...]
>>
>> Czy znacie jakąś możliwość analizy (celowo nie używam słowa 'kompilacja')
>> kodu pod względem poprawności ZANIM zostanie uruchomiony?
>
> W Emacsie mam podłączoną taką kontrolę w locie z użyciem Pyflakes [1]_.
> Błędna linia jest podświetlona na czerwono i u dołu widzę komentarz:
> "undefined name 'ALA'" Z poziomu konsoli to wygląda tak: $ pyflakes
> test_err.py test_err.py:7: undefined name 'ALA'
>
> Chyba każdy edytor ma możliwość podłączenia takiej kontroli, a więc czym
> prędzej do dzieła.
>
> .. [1] http://www.divmod.org/trac/wiki/DivmodPyflakes

Pyflakes ma kilka wad.

Po pierwsze nie rozróżnia wiadomości na błędy i ostrzeżenia. Jest to wyjątkowo
denerwujące przy pracy z emacsowym Flymake, który może inaczej oznaczać błędy
(czyli coś, co nie powinno mieć miejsca) od ostrzeżeń (które czasem można
zignorować). Jest to też denerwujące gdybyśmy chcieli np. wykorzystać Pyflakes
jako pre-commit hook w SVN.

Poza tym Pyflakes ma dość małe możliwość. Małe zwłaszcza w stosunku do Pylint,
który możliwościami wprost zwala z nóg. Ale coś za coś. Pylint jest ciężki w
konfiguracji i stosunkowo wolny. Nie działa zbyt sprawnie z emacsowym Flymake
(ja co prawda tak pracuję, ale niedługo będę się rozglądał za jakimś
alternatywnym rozwiązaniem), ale można go sobie zawsze podpiąć pod jakiś skrót
klawiaturowy i wywoływać na żądanie.

Dnia niedziela, 19 lipca 2009 22:11, Tomasz Elendt napisał(a):


> Po pierwsze nie rozróżnia wiadomości na błędy i ostrzeżenia. Jest to
> wyjątkowo denerwujące przy pracy z emacsowym Flymake, który może
> inaczej oznaczać błędy (czyli coś, co nie powinno mieć miejsca) od
> ostrzeżeń (które czasem można zignorować). Jest to też denerwujące
> gdybyśmy chcieli np. wykorzystać Pyflakes jako pre-commit hook w SVN.
> 

To akurat da się
| OUTPUT
|       Found warnings including unused importes, undefined variables 
|       and unnecessary reimports, are printed on standard output.  
|       Found errors including compile or encoding errors, are printed 
|       on standard error.
|
| EXIT STATUS
|       The exit status is 0 when no warnings or errors are found. When 
|       errors are found the exit status is 2.
|       When warnings (but no errors) are found the exit status is 1.

Jeśli emacs nie da rady wykorzystać stdour/stderr albo kodu wyjścia w 
ostateczności możesz napisać jednolinijkowe skrypty pyflakes-errors i 
pyflakes-warnings.


-- 
Arkadiusz Kindziuk

Radomir Dopieralski pisze:
> At Sat, 18 Jul 2009 23:06:23 +0200, Jacek Czerwinski wrote:
> 


>> Automatyczne testy nie są jedyną metodą pro-niezawodnościową (późną porą 
>> mam przed oczami weryfikacje przez drugą czepialską parę oczu), ale to 
>> już odchodzimy trochę od wątku.
> 
> Oczywiście, że nie jedyną, ale ośmielę się zaryzykować tezę, że w opisanej
> sytuacji (używanie pythona do pisania dużego projektu) jedną z najbardziej
> przydatnych.
> 
W tych okolicznościach (interpreter + literówki), w sumie w innych 
okolicznościach - też masz rację.
Skromnie tylko dodam, że na interfejsach pomiędzy modułami (częściami, 
podprojektami, whatever) mocna specyfikacja to podstawa. A moim skromnym 
zdaniem 'twarde' języki umożliwiają itd ... już wiesz.

>> Na pewno w interpreterze bym nie kodował o godzinie 23:10 ;)
> 
> Odnoszę wrażenie, że jednak nie trzymasz się trochę tematu. Kolega zapytał
> o narzędzia pozwalające łatwiej wyłapywać błędy przy pisaniu w pythonie,
> tak aby można było rozwijać średniej wielkości i duże projekty.
> Automatyczne testy należą do najbardziej pomocnych w tej sytuacji
> narzędzi. Nie uważam, żeby odpowiedź "użyj innego języka" była na miejscu,
> szczególnie na tej grupie dyskusyjnej.

Fakt, takie tam filozofowanie wieczorową porą.

Tomasz Elendt napisał(a):

> Pyflakes ma kilka wad.
>
> Po pierwsze nie rozróżnia wiadomości na błędy i ostrzeżenia. Jest to wyjątkowo
> denerwujące przy pracy z emacsowym Flymake, który może inaczej oznaczać błędy
> (czyli coś, co nie powinno mieć miejsca) od ostrzeżeń (które czasem można
> zignorować). Jest to też denerwujące gdybyśmy chcieli np. wykorzystać Pyflakes
> jako pre-commit hook w SVN.

Aby miec taka funkcjonalnosc w Emacie wystarczy trywialna modyfikacja
w Pyflakes.
W pliku "messages.py" dodajesz slowo "WARNING" do komunikatu,
ktory uwazasz za niekrytyczny.
Osobiscie uwazam wszystkie zglaszane przez Pyflakes za wazne
i nie potrzebuje rozroznienia na bledy i warningi.

> Poza tym Pyflakes ma dość małe możliwość. Małe zwłaszcza w stosunku do Pylint,
> który możliwościami wprost zwala z nóg. Ale coś za coś. Pylint jest ciężki w
> konfiguracji i stosunkowo wolny. Nie działa zbyt sprawnie z emacsowym Flymake

Otoz to, dlatego do kontroli w locie uzywam Pyflakes, a do kontroli
odpalanej
ekstra Pylint.

> (ja co prawda tak pracuję, ale niedługo będę się rozglądał za jakimś
> alternatywnym rozwiązaniem), ale można go sobie zawsze podpiąć pod jakiś skrót
> klawiaturowy i wywoływać na żądanie.

I tak tez robie i polecam.

RW

On Jul 18, 4:00 pm, Jacek Czerwinski <x...@y.z.pl> wrote:
> > Jak sobie radzicie z tego typu problemami w kodzie produkcyjnym
> > złożonym z wielu modułów?
>
> Z całym szacunkiem dla skryptów: wielkie programy piszemy w języku
> kompilowanym i to mocno typowanym np. Java 5. Mimo, że to "wiek
> skryptów", co kompilacja to kompilacja.

Sorry, jak chcesz, żeby kompilacja zapewniała ci jako taki poziom
bezpieczeństwa, to musi to być ADA.
Po drugie Python jest językiem mocno typowanym. Nie jest językiem
statycznie typowanym. Wbrew pozorom to są niezależne rzeczy.

> W interpreterze nie jest to nigdy rozwiązywalne, co pokazują funkcje
> zwykle nazywane eval (oraz cała ta miękka otoczka).

Znów -- to akurat nie zależy od tego czy język jest intepretowany, czy
kompilowany (JIT).

Bart Ogryczak pisze:
> On Jul 18, 4:00 pm, Jacek Czerwinski <x...@y.z.pl> wrote:
>>> Jak sobie radzicie z tego typu problemami w kodzie produkcyjnym
>>> złożonym z wielu modułów?
>> Z całym szacunkiem dla skryptów: wielkie programy piszemy w języku
>> kompilowanym i to mocno typowanym np. Java 5. Mimo, że to "wiek
>> skryptów", co kompilacja to kompilacja.
> 
> Sorry, jak chcesz, żeby kompilacja zapewniała ci jako taki poziom
> bezpieczeństwa, to musi to być ADA.
Wiesz, dla mnie starego C progranersa Java5/6 to już miodzo. Najwyżej da 
tak ślicznie wystawione na exception.
> Po drugie Python jest językiem mocno typowanym. Nie jest językiem
> statycznie typowanym. Wbrew pozorom to są niezależne rzeczy.
Rzeczywiście, ładnie to przypomniałeś.
> 
>> W interpreterze nie jest to nigdy rozwiązywalne, co pokazują funkcje
>> zwykle nazywane eval (oraz cała ta miękka otoczka).
> 
> Znów -- to akurat nie zależy od tego czy język jest intepretowany, czy
> kompilowany (JIT).
Są dwie rzeczy, jedna to pewien skrót myślowy kompilowany = to, to i to 
(Java,Ada,C++,Pascal) else interpretowany. W innej części wątku 
przywołąłem przykład grooviego, który jest 'przetwarzany' (aka 
kompilowany) na kod JVM a semantykę zmiennych ma typowo interpreterową.

Niedawno sobie sam to na nowy sposób uświadomiłem, jak dyskutowaliśmy 
parsery dokonujące analizy na bardzo małych maszynkach. Oświeciło mnie, 
że stare Basicy z numerami linii, ale w mniejszym stopniu interpretery w 
ogóle mają mały, lekki 'kontekst' (w w/w basicu wielkości jednej linii, 
np. nie posiadający koncepcji nawet procedury - i tylko dlatego parsing 
dał się zrobić na 1KB RAM ZX81).
W każdym razie kontekst języka 'kompilowanego' (w sensie powyżej czyli 
masło maślane ;) ) obejmuje jednostkę kompilacji (np. z importami) i tak 
są sprawdzane zmienne (identyfikatory). Jest to dość ładny wspólny 
mianownik sporej części języków. W sumie nie ma dużego znaczenia DO 
CZEGO jest kompilowany, tylko jak.

W interpreterach (choćby kompilowanych do jakiejś postaci) kontekst 
parsera-kompilatora jest znacznie mniejszy, a rozwiązanie zależności 
zmiennych jest przesunięte na runtime.

To przydługo, żeby uchwycić różne odcienie słowa 'kompilacja'. I masz 
rację, że chwytanie tego 'na intuicje' albo zgodnie z popularnym 
/marketingowym rozumieniem może (nie musi) prowadzić do niezrozumienia.

Nie wiem czy odnosiłeś się do samego Eval. jak na interpreterach jest to 
naturalne przedłużenie języka, na kompilowanych (C) jest niemozliwe 
(jako naturalna implementacja) czy trudne i z kosztami (Java), a zawsze 
jako 'wrzód na zdrowym ciele'

On Jul 20, 7:03 pm, Jacek Czerwinski <x...@y.z.pl> wrote:
> > Sorry, jak chcesz, żeby kompilacja zapewniała ci jako taki poziom
> > bezpieczeństwa, to musi to być ADA.
>
> Wiesz, dla mnie starego C progranersa Java5/6 to już miodzo. Najwyżej da
> tak ślicznie wystawione na exception.

No cóż, jak na mój gust czyste C w ogóle nie jest językiem wysokiego
poziomu.

[...]
> >> W interpreterze nie jest to nigdy rozwiązywalne, co pokazują funkcje
> >> zwykle nazywane eval (oraz cała ta miękka otoczka).
>
> > Znów -- to akurat nie zależy od tego czy język jest intepretowany, czy
> > kompilowany (JIT).
>
> Są dwie rzeczy, jedna to pewien skrót myślowy kompilowany = to, to i to
> (Java,Ada,C++,Pascal) else interpretowany.

Widzisz, tutaj Java zupełnie nie pasuje. Bo wcale nie musi być
kompilowana. Wręcz kompilowana to jest od bardzo niedawna. Klasycznie,
to była "kompilowana" do bytecode, intepretowanego przez maszynę
wirtualną. Dokładnie tak samo rzecz ma się z Pythonem. .pyc to
bytecode intepretowany przez runtime. Przy czym granica między opcode
a bytecode jest dosyć śliska.

Bart Ogryczak pisze:
> On Jul 20, 7:03 pm, Jacek Czerwinski <x...@y.z.pl> wrote:

>> Są dwie rzeczy, jedna to pewien skrót myślowy kompilowany = to, to i to
>> (Java,Ada,C++,Pascal) else interpretowany.
> 
> Widzisz, tutaj Java zupełnie nie pasuje. Bo wcale nie musi być
> kompilowana. Wręcz kompilowana to jest od bardzo niedawna. 

Tym niemniej nawet ta wpół interpretowana Java analizuje zmienne w 
sposób typowy dla języków kompilowanych (tzw w czasie kompilacji a nie 
wykonywania).
Odwrotnie kompilatory PHP, Pythona, Grooviego - nawet gdyby to było do 
przewydajnej VM lub maszynowego, mają charakter (zachowują semantykę 
języka) specyficzną dla interpreterów.


Dalej pisałem, że nie tyle chodzi o target kompilacji, ile o sposób 
potraktowania kontekstu jednostki kompilacji (i zmiennych o jakich mowa 
w wątku) na sposób taki lub siaki.

Ty wiesz o co chodzi, ja wiem o co chodzi a słowo kompilacja ma różne 
odcienie. Ja się przyzwyczaiłem do (trochę potocznego) znaczenia "język 
kompilowany" jak zaprezentowałem.

At Mon, 20 Jul 2009 21:15:33 +0200, Jacek Czerwinski wrote:

> Bart Ogryczak pisze:

> Tym niemniej nawet ta wpół interpretowana Java analizuje zmienne w 
> sposób typowy dla języków kompilowanych (tzw w czasie kompilacji a nie 
> wykonywania).

Dajze juz spokoj. Java sprawdza nazwy kompilatorem, w Pythonie masz
do tego osobne narzedzia w rodzaju pylinta, czesto potezniejsze. 
Ot i cala roznica. Nie bardzo widze jak ona wplywa na nadawanie sie
do duzych projektow. No chyba ze masz problemy z zaprowadzeniem
dyscypliny w zespole, ale tego problemu jezyk nie rozwiaze.

-- 
Radomir Dopieralski, http://sheep.art.pl

On 2009-07-19, Arkadiusz 'nare' Kindziuk <nare@europe.earth.net> wrote:
> Dnia niedziela, 19 lipca 2009 22:11, Tomasz Elendt napisał(a):
>
>
>> Po pierwsze nie rozróżnia wiadomości na błędy i ostrzeżenia. Jest to
>> wyjątkowo denerwujące przy pracy z emacsowym Flymake, który może
>> inaczej oznaczać błędy (czyli coś, co nie powinno mieć miejsca) od
>> ostrzeżeń (które czasem można zignorować). Jest to też denerwujące
>> gdybyśmy chcieli np. wykorzystać Pyflakes jako pre-commit hook w SVN.
>> 
>
> To akurat da się
>| OUTPUT
>|       Found warnings including unused importes, undefined variables 
>|       and unnecessary reimports, are printed on standard output.  
>|       Found errors including compile or encoding errors, are printed 
>|       on standard error.
>|
>| EXIT STATUS
>|       The exit status is 0 when no warnings or errors are found. When 
>|       errors are found the exit status is 2.
>|       When warnings (but no errors) are found the exit status is 1.

Dzięki. Nie widziałem nigdzie dokumentacji na stronie projektu.

Undefined variable nie jest w moim rozumowaniu warningiem ale errorem, gdyż
wywali błąd w czasie wykonywania skryptu (a nieużywany import czy zmienna nie).
Oczywiście są czasem przypadki wątpliwe, gdzie ciężko (przynajmniej na drodze
analizy statycznej kodu) określić czy zmienna jest zdefiniowana czy nie.

Zrobię najwyżej tak jak zaproponował Rob Wolfe - zmodyfikuję treści
komunikatów. Choć nie podoba mi się grzebanie w żródłach albo obrabianie stdout
- uważam, że Pyflakes powinien mieć większe możliwości konfiguracyjne.