Największy problem Pythona.
Qertoip
Na początek uczciwie zaznaczę, że jestem w Pythonie początkujący. Nie
licząc różnych "wprawek", napisałem około 1000 wierszy działającego kodu
(wątki, sockety, XML). Inną część tej samej aplikacji (również: wątki,
sockety, XML) piszę w .NET (VS2003).
Tym samym miałem okazję porównać swoją produktywność na tych dwóch
platformach. Podkreślę - nie tyle językach, co *platformach*.
Zauważyłem, że choć Python jest bardziej ekspresywny niż C#, to jednak
wydajność tworzenia oprogramowania jest istotnie większa w tym drugim...
Spostrzegłem, że składają się na to dwie prozaiczne rzeczy:
- bardzo słaba (w porównaniu do MSDN) dokumentacja bibliotek Pythona
- niemożność wylistowania składowych obiektu (w VS: Ctrl+Space) wraz z
podręczną dokumentacją dla każdej składowej (metody, atrybuty). Osoby
piszące w nowoczesnych IDE wiedzą o co mi chodzi.
To drugie wynika z faktu, że w Pythonie rzadko kiedy da się statycznie
ustalić typ obiektu (jeśli się da, najlepsze pythonowe IDE potrafią
wylistować składowe).
Niby pierdółki... ale *naprawdę* ma to zasadniczy wpływ na wydajność.
Jestem głodny Waszych uwag na ten temat.
Czy da się jakoś zniwelować powyższe problemy?
Jak porównujecie swoją wydajność w Pythonie do wydajności w innych
nowoczesnych językach?
--
Pozdr.
Piotrek
Przemek Wiśniewski
zgadzam sie w 100%;
--
Przemek Wiśniewski
Mateusz Sołtysek
> - niemożność wylistowania składowych obiektu (w VS: Ctrl+Space) wraz z
> podręczną dokumentacją dla każdej składowej (metody, atrybuty). Osoby
> piszące w nowoczesnych IDE wiedzą o co mi chodzi.
To zleży jakiego ID używasz, opcję o której mówisz posiadają takie
edytory jak: PythonWin czy też (Eclipse + pydev) - innych nie pamiętam.
Co do dokumentacji, to nie wiem co myśleć dla mnie zawsze była
wystarczająca i jakiś takich większych zastrzeżeń nie mogę zgłosić.
Pozdrawiam
Mateusz
JZ
> - niemożność wylistowania składowych obiektu (w VS: Ctrl+Space)
Ty chyba żartujesz. Prawie wszystkie edytory do Pythona to potrafią. Chyba
nie widziałeś Wing IDE w akcji... Podpowiadać podobnie potrafi zarówno
PythonWin, Eclipse+pydev, SPE, Boa Constructor itp. Poza tym WingIDE,
PythonWin i Eclipse+pydev maja b. dobry wizualny debugger nie liczac
mozliwosci sprawdzenia czegos od reki w interpreterze, co jest zupelnie
poza zasiegiem takiego c#.
> To drugie wynika z faktu, że w Pythonie rzadko kiedy da się statycznie
> ustalić typ obiektu (jeśli się da, najlepsze pythonowe IDE potrafią
> wylistować składowe).
Tego nie porafi chyba tylko jakis obskurny Notatnik, albo SciTe (ktory
trzeba odpowiednio skonfigurowac).
> Jak porównujecie swoją wydajność w Pythonie do wydajności w innych
> nowoczesnych językach?
Probowalem ja, probowal kolega, napisac w C# aplikacje ktora cos pobiera z
netu. Nawet nie ma porownania. Python byl znacznie prostszy, z glowy od
reki napisalem pare linijek. Generalnie z moich wieloletnich doswiadczen z
roznymi jezykami zauwazylem ze podczas pracy z pythonem prawie w ogole nie
musze zagladac do manuala. No chyba zeby uzyc jakies nowej biblioteki.
Latwo sie zapamietuje skladnie i wywolania wszystkich funkcji a IDE
dopelnia reszty podpowiedziami. Kod Pythona jest nie tylko bowiem spojny
ale takze b. krotki i b. czytelny. No bo pobranie stronki www to przeciez 2
linijki, podobnie proste sa inne operacje, np. na plikach. Nawet Bruce
Eckel wyznal ze musi zagladac do manuala aby sobie czasem przypomniec
skladnie operacji na plikach w javie, a w pythonie tego nie musi robic mimo
ze zna go krocej.
--
JZ
Przemek Wiśniewski
Mozna zrobic prosta przegladarke kodu zrodlowego (drzewka klas itp). Nie
da sie zrobic skutecznych narzedzi do refaktoryzacji, bo kod zawiera za
malo informacji i dodatkowo python pozwala typy tworzyc dynamicznie.
Mozna co najwyzej regexpami podmieniac na chybil trafil nazwy metod i
klas, trudno wylapac bledy powstale w wyniku takiej zabawy. Wszystkie
narzedzia do pythona wygladaja malo powaznie.
Na sile mozna w pythonie tworzyc spore rzeczy (np: zope i plone), bardzo
latwo spore rzeczy kompletnie spieprzyc (np: zope i plone).
--
Przemek Wiśniewski
Przemek Wiśniewski
[..]
Ty jestes maniakiem pythona i cherrypy. Twoje zdanie sie nie liczy :P
--
Przemek Wiśniewski
Grzegorz Staniak
A Przemek Wiśniewski sobie idzie i śpiewa sobie tak:
>> To zleży jakiego ID używasz, opcję o której mówisz posiadają takie
>> edytory jak: PythonWin czy też (Eclipse + pydev) - innych nie pamiętam.
>> Co do dokumentacji, to nie wiem co myśleć dla mnie zawsze była
>> wystarczająca i jakiś takich większych zastrzeżeń nie mogę zgłosić.
>
> Mozna zrobic prosta przegladarke kodu zrodlowego (drzewka klas itp). Nie
> da sie zrobic skutecznych narzedzi do refaktoryzacji,
http://bicyclerepair.sourceforge.net/
> bo kod zawiera za malo informacji
A introspekcja ze wstydu kurczy się i pufff! - znika w obłoku logiki.
> i dodatkowo python pozwala typy tworzyc dynamicznie.
> Mozna co najwyzej regexpami podmieniac na chybil trafil nazwy metod i
> klas, trudno wylapac bledy powstale w wyniku takiej zabawy. Wszystkie
> narzedzia do pythona wygladaja malo powaznie.
Uwaga na nisko przelatujące kwantyfikatory.
[---]
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Adam Przybyla
>
> Na początek uczciwie zaznaczę, że jestem w Pythonie początkujący. Nie
> licząc różnych "wprawek", napisałem około 1000 wierszy działającego kodu
> (wątki, sockety, XML). Inną część tej samej aplikacji (również: wątki,
> sockety, XML) piszę w .NET (VS2003).
>
> Tym samym miałem okazję porównać swoją produktywność na tych dwóch
> platformach. Podkreślę - nie tyle językach, co *platformach*.
>
> Zauważyłem, że choć Python jest bardziej ekspresywny niż C#, to jednak
> wydajność tworzenia oprogramowania jest istotnie większa w tym drugim...
>
> Spostrzegłem, że składają się na to dwie prozaiczne rzeczy:
> - bardzo słaba (w porównaniu do MSDN) dokumentacja bibliotek Pythona
help(os)
w ten sposb mozesz sprawdzic wszystko co wiemy o danym obiekjcie/module.
> - niemożność wylistowania składowych obiektu (w VS: Ctrl+Space) wraz z
dir(obiekt) - listuje metody i dane
> podręczną dokumentacją dla każdej składowej (metody, atrybuty). Osoby
> piszące w nowoczesnych IDE wiedzą o co mi chodzi.
A IDE ci panie pod dostatkiem, nie porownuj tego z konsola,
choc ja np lubei konsole.
>
> To drugie wynika z faktu, że w Pythonie rzadko kiedy da się statycznie
> ustalić typ obiektu (jeśli się da, najlepsze pythonowe IDE potrafią
> wylistować składowe).
>
> Niby pierdółki... ale *naprawdę* ma to zasadniczy wpływ na wydajność.
>
> Jestem głodny Waszych uwag na ten temat.
> Czy da się jakoś zniwelować powyższe problemy?
> Jak porównujecie swoją wydajność w Pythonie do wydajności w innych
> nowoczesnych językach?
... nie porownuj "obrazkow", bo IDE jest wiele, jak chcesz
miec cos z duza iloscia podpowiedzi, to wybierz te najbardziej bajerzaste.
Z powazaniem
Adam Przybyla
RobertSzefler
> Na początek uczciwie zaznaczę, że jestem w Pythonie początkujący. Nie
> licząc różnych "wprawek", napisałem około 1000 wierszy działającego kodu
> (wątki, sockety, XML). Inną część tej samej aplikacji (również: wątki,
> sockety, XML) piszę w .NET (VS2003).
Ja osobiście w dotnecie dotarłem do etapu hello world i tam poległem,
dokładnie z tego samego powodu, dla którego Ty wolisz C#... Mi się
wydaje, że to jest jednak w większym stopniu kwestia
przyzwyczajeń/doświadczeń/traum.
> Tym samym miałem okazję porównać swoją produktywność na tych dwóch
> platformach. Podkreślę - nie tyle językach, co *platformach*.
>
> Zauważyłem, że choć Python jest bardziej ekspresywny niż C#, to jednak
> wydajność tworzenia oprogramowania jest istotnie większa w tym drugim...
>
> Spostrzegłem, że składają się na to dwie prozaiczne rzeczy:
> - bardzo słaba (w porównaniu do MSDN) dokumentacja bibliotek Pythona
To fakt, nie jest z tym najlepiej. Nie ukrywam, że zdarza mi się np.
zerkać do sorców żeby wykumać, jak to wszystko jest poskładane i co się
dzieje w "corner cases".
> - niemożność wylistowania składowych obiektu (w VS: Ctrl+Space) wraz z
> podręczną dokumentacją dla każdej składowej (metody, atrybuty). Osoby
> piszące w nowoczesnych IDE wiedzą o co mi chodzi.
Ja nie wiem, ostatnio jadę pod windą w Notepad2 a tradycyjnie joe'm (od
którejś tam wersji ma fajne podświetlanie składni Pythona). Mi inspektor
obiektów nie jest z reguły potrzebny, chociaż wiadomo, co osoba to inne
preferencje.
> To drugie wynika z faktu, że w Pythonie rzadko kiedy da się statycznie
> ustalić typ obiektu (jeśli się da, najlepsze pythonowe IDE potrafią
> wylistować składowe).
Nie ma problemu z inspekcją metod klasy i atrybutów klasowych. Natomiast
fakt, w praktyce sprawdzenie atrybutów w teorii i praktyce jest poza
runtimem właściwie niemożliwe. Jakimś tam lekarstwem na to są sloty w
składni 2.4, ale to półśrodek. Python jest językiem młodym i ciągle
ewoluującym, a ta sprawa właśnie (bardziej statyczna obiektowość) jest
co chwilę poruszana wśród jego tfurców, bodajże nawet sam BDFL Guido się
do tego skłania.
Zobaczymy, co nadejdzie z Py3K. Chociaż ja osobiście wolałbym dobrze i
wydajnie zaimplementowaną maszynę wirtualną dla 2.4, no ale cóż...
> Niby pierdółki... ale *naprawdę* ma to zasadniczy wpływ na wydajność.
Kwestia gustu, acz oczywiście rozumiem i po części podzielam Twoje obiekcje.
> Jestem głodny Waszych uwag na ten temat.
> Czy da się jakoś zniwelować powyższe problemy?
Kwestia paradygmatu inżynieryjnego i organizacji pracy w grupie. Uwierz
mi, brak statycznych prototypów dla klas nie jest największym problemem
przy współpracy grupowej. Są poza tym różne podejścia próbujące to w
pewnym sensie niwelować (PyProtocols chociażby).
To w ogóle taki temat trochę szeroki, bo trzebaby najpierw zdefiniować,
czym na prawdę jest atrybut obiektu i czy ma konkretny związek z klasą
obiektu - Guido i spółka przyjęli, że tak nie jest, większość reszty
świata, szczególnie z korzeniami w C, jest innego zdania...
> Jak porównujecie swoją wydajność w Pythonie do wydajności w innych
> nowoczesnych językach?
Ja mogę z osobistego doświadczenia porównać to schematycznie tak:
Angielski > Polski > Python > C ~ C++ > asembler x86 ;) > Java > Perl
>>>>> PHP
od najwydajniejszych dla swojej klasy zastosowań do najmniej wydajnych
;) co przekłada się bezpośrednio na jakość "ideologiczną" języka.
RobertSzefler
> Zobaczymy, co nadejdzie z Py3K. Chociaż ja osobiście wolałbym dobrze i
> wydajnie zaimplementowaną maszynę wirtualną dla 2.4, no ale cóż...
Btw, mają zabrać lambdy podobno, map, filter i inne helpery funkcyjne...
aaargh!
RobertSzefler
> http://bicyclerepair.sourceforge.net/
To jakiś chyba niezgorszy wypas, dziex za link
> A introspekcja ze wstydu kurczy się i pufff! - znika w obłoku logiki.
Czasami analiza statyczna jest konieczna, w tym sęk... Szczególnie jeśli
kiero projektu jest zatwardziałym dżawowcem ;)
>>i dodatkowo python pozwala typy tworzyc dynamicznie.
>>Mozna co najwyzej regexpami podmieniac na chybil trafil nazwy metod i
>>klas, trudno wylapac bledy powstale w wyniku takiej zabawy. Wszystkie
>>narzedzia do pythona wygladaja malo powaznie.
>
>
> Uwaga na nisko przelatujące kwantyfikatory.
que?
Grzegorz Staniak
>> http://bicyclerepair.sourceforge.net/
>
> To jakiś chyba niezgorszy wypas, dziex za link
Pierwsze trafienie z http://www.google.com/search?q=python+refactoring ;)
Intregrowalny przynajmniej z Idle, emacsem i vimem, założenia masz opisane na
http://c2.com/cgi-bin/wiki?PythonRefactoringBrowser, więcej info na
http://c2.com/cgi-bin/wiki?BicycleRepairMan
>> A introspekcja ze wstydu kurczy się i pufff! - znika w obłoku logiki.
>
> Czasami analiza statyczna jest konieczna, w tym sęk...
Ale wiesz, to jeszcze nie znaczy, że refaktoryzacja jest niemożliwa, a jedyne
co można zrobić to "regexpami podmieniac na chybil trafil nazwy metod".
> Szczególnie jeśli kiero projektu jest zatwardziałym dżawowcem ;)
Naprostować go. ;)
[---]
>>>klas, trudno wylapac bledy powstale w wyniku takiej zabawy. Wszystkie
>>>narzedzia do pythona wygladaja malo powaznie.
>>
>>
>> Uwaga na nisko przelatujące kwantyfikatory.
>
> que?
"Poważny wygląd" to oczywiście DGCC, ale słowo "wszystkie" jest za mocne. Co
jest niepoważnego w Eclipse?
http://www.python.org/moin/EclipsePythonIntegration
Przyglądałeś się Komodo?
http://www.activestate.com/Products/Komodo/?utm_source=home&utm_medium=banner&utm_campaign=komodo_home_page
http://www.activestate.com/Products/Komodo/more_information.plex
http://www.activestate.com/Products/Download/featuretour.plex?id=Komodo&pageid=KomodoMain
JZ
> Ty jestes maniakiem pythona i cherrypy. Twoje zdanie sie nie liczy :P
Argumentum ad hominem sie nie liczy. Ja podalem konkretne, merytoryczne
argumenty.
--
JZ
Przemek Wiśniewski
Czy Ty wszsytko odbierasz ze smiertelna powaga?
--
Przemek Wiśniewski
JZ
> Mozna zrobic prosta przegladarke kodu zrodlowego (drzewka klas itp). Nie
> da sie zrobic skutecznych narzedzi do refaktoryzacji, bo kod zawiera za
> malo informacji i dodatkowo python pozwala typy tworzyc dynamicznie.
To nie dotyczy w ogole Pythona jako takiego ale ogolnie jezykow
dynamicznych. Nie mozna wszystkiego miec. Kazde rozwiazanie ma swoje zalety
i wady. To odwieczny spor zwolennikow statycznej kompilacji i definicji
typow ze zwolennikami podejscia dynamicznego. Czesto osoby 'spaczone' praca
z java czy c++ tworza potem potworki jezykowe w Pythonie lub Ruby bo nie
moga pozbyc sie swoich nawykow ktore tu nie maja specjalnie sensu. To tez
moze tez przeszkoda w skutecznym poslugiwaniu sie takim jezykiem jak
Python. Dla mnie to b. intuicyjny jezyk i prawie w ogole nie musze zagladac
do manuali czego nie powiedzialbym np. o php (ktorego znam wiele lat
dluzej). Jezyk C porzucilem kupe lat temu, od Javy odrzucily mnie
(paradoksalnie) opinie Bruce Eckela, javowego guru no i koszmarna
nadmiarowosc kodu Javy. Nie przekreslam javy, ale jest na pewno mniej sexy
niz jezyki dynamiczne. ;)
> Na sile mozna w pythonie tworzyc spore rzeczy (np: zope i plone), bardzo
> latwo spore rzeczy kompletnie spieprzyc (np: zope i plone).
Plone nie jest spieprzony. To dobry projekt, ma doskonale zalozenia
obiektowego podejscia do CMS'a. Problemem jest Zope2 (na ktorym Plone sie
opiera). Zope2 ktory ma niekonsekwentne API, trudno w tym sie faktycznie
polapac.
Widziales jednak Zope3? Jest znacznie lepiej zaprojektowany. Zalozyli duza
skale zastosowan, stad powprowadzali np. interfejsy, adaptory itp. Polecam
prawie 500 stronicowa ksiazke dostepna online. http://tinyurl.com/74byh
--
JZ
JZ
> Czy Ty wszsytko odbierasz ze smiertelna powaga?
Akurat nie mialem nastroju. Spoko;)
--
JZ
RobertSzefler
> Widziales jednak Zope3? Jest znacznie lepiej zaprojektowany. Zalozyli duza
> skale zastosowan, stad powprowadzali np. interfejsy, adaptory itp. Polecam
> prawie 500 stronicowa ksiazke dostepna online. http://tinyurl.com/74byh
No, to akurat jest argument za spieprzeniem. Vide J2EE: "firmowy"
introduction Suna ma 1k+ stron :O
Qertoip
> Dnia Tue, 10 May 2005 11:14:12 +0200, Qertoip napisał(a):
>
>> - niemożność wylistowania składowych obiektu (w VS: Ctrl+Space)
>
> Ty chyba żartujesz. Prawie wszystkie edytory do Pythona to potrafią.
Nie żartuję. Ty nie rozumiesz problemu.
def f( a ):
return a
obj = f( "" )
obj.???
Żadne IDE tego nie podpowie, bo typu nie da się ustalić statycznie.
Napisałem przecież, że *jeśli* się da wydedukować typ, to najlepsze IDE
potrafią wylistować składowe. Niestety z reguły się nie da.
> Chyba nie widziałeś Wing IDE w akcji...
Używam Eclipse + pydev do projektów oraz Wing IDE do wprawek.
> Kod Pythona jest nie tylko bowiem spojny ale takze b. krotki i b.
> czytelny.
Prawda... za wyjątkiem kilku upierdliwości, jak np. self.__metoda()
> Nawet Bruce Eckel wyznal ze musi zagladac do manuala aby sobie czasem
> przypomniec skladnie operacji na plikach w javie
To prawda, że obsługa plików w Javie są bardzo skomplikowana, ale to
margines jej zastosowań.
Chcę podkreślić, że nie przychodzę tutaj jako adwokat języków statycznie
typowanych, w szczególności C# - za krótko posługuję się dynamicznym
typowaniem, żeby ocenić sprawę obiektywnie. Chcę tylko poznać opinię
doświadczonych Pythonowców, nauczyć się *naturalnie* pisać w Pythonie i
podzielić się spostrzeżeniami.
--
Pozdr.
Piotrek
Qertoip
Dzięki za wyważoną opinię.
--
Pozdr.
Piotrek
Przemek Wiśniewski
> Dnia Tue, 10 May 2005 11:51:07 +0200, JZ napisał(a):
>
>
>>Dnia Tue, 10 May 2005 11:14:12 +0200, Qertoip napisał(a):
>>
>>
>>>- niemożność wylistowania składowych obiektu (w VS: Ctrl+Space)
>>
>>Ty chyba żartujesz. Prawie wszystkie edytory do Pythona to potrafią.
>
>
> Nie żartuję. Ty nie rozumiesz problemu.
> def f( a ):
> return a
>
> obj = f( "" )
> obj.???
>
> Żadne IDE tego nie podpowie, bo typu nie da się ustalić statycznie.
> Napisałem przecież, że *jeśli* się da wydedukować typ, to najlepsze IDE
> potrafią wylistować składowe. Niestety z reguły się nie da.
To akurat nie problem, kompilator Ocamla potrafi zgadywac typ funkcji na
podstawie argumentow, dobre ide tez by moglo - jedyne wymaganie to
takie, zeby kiedys ten typ jakos okreslic. Chodzi o to, ze klasa moze
sie zmieniac w czasie dzialania programu.
--
Przemek Wiśniewski
Przemek Wiśniewski
>
>>Na sile mozna w pythonie tworzyc spore rzeczy (np: zope i plone), bardzo
>>latwo spore rzeczy kompletnie spieprzyc (np: zope i plone).
>
>
> Plone nie jest spieprzony. To dobry projekt, ma doskonale zalozenia
> obiektowego podejscia do CMS'a. Problemem jest Zope2 (na ktorym Plone sie
> opiera). Zope2 ktory ma niekonsekwentne API, trudno w tym sie faktycznie
> polapac.
Za nic mnie nie przekonasz, juz umoczylem w tym paluchy i nie chce nigdy
wiecej.
> Widziales jednak Zope3? Jest znacznie lepiej zaprojektowany. Zalozyli duza
> skale zastosowan, stad powprowadzali np. interfejsy, adaptory itp. Polecam
> prawie 500 stronicowa ksiazke dostepna online. http://tinyurl.com/74byh
To i tak za malo, o javie pisza znacznie szerzej.
--
Przemek Wiśniewski
Qertoip
>>>>- niemożność wylistowania składowych obiektu (w VS: Ctrl+Space)
>>>
>>>Ty chyba żartujesz. Prawie wszystkie edytory do Pythona to potrafią.
>>
>> Nie żartuję. Ty nie rozumiesz problemu.
>> def f( a ):
>> return a
>>
>> obj = f( "" )
>> obj.???
>>
>> Żadne IDE tego nie podpowie, bo typu nie da się ustalić statycznie.
>> Napisałem przecież, że *jeśli* się da wydedukować typ, to najlepsze IDE
>> potrafią wylistować składowe. Niestety z reguły się nie da.
>
> To akurat nie problem, kompilator Ocamla potrafi zgadywac typ funkcji na
> podstawie argumentow, dobre ide tez by moglo - jedyne wymaganie to
> takie, zeby kiedys ten typ jakos okreslic.
Nie problem? Zauważ, że sprowadza się to do "statycznego uruchomienia"
kodu. Może przykład wybrałem za prosty - podam inny, lepiej obrazujący o co
chodzi:
def f( a ):
return a
p = True
if p:
obj = f( 1 )
else:
obj = f( "" )
obj.???
> Chodzi o to, ze klasa moze sie zmieniac w czasie dzialania programu.
Owszem, to jest gwóźdź do trumny :) (w tej kwestii)
--
Pozdr.
Piotrek
Przemek Wiśniewski
>>To akurat nie problem, kompilator Ocamla potrafi zgadywac typ funkcji na
>>podstawie argumentow, dobre ide tez by moglo - jedyne wymaganie to
>>takie, zeby kiedys ten typ jakos okreslic.
>
>
> Nie problem? Zauważ, że sprowadza się to do "statycznego uruchomienia"
> kodu. Może przykład wybrałem za prosty - podam inny, lepiej obrazujący o co
> chodzi:
>
> def f( a ):
> return a
>
> p = True
> if p:
> obj = f( 1 )
> else:
> obj = f( "" )
>
> obj.???
No tak, tu masz racje. Nie wzialem tego pod uwage.
--
Przemek Wiśniewski
JZ
Nie na temat. Nie chodzi o licytacje ilosci stron dokumentacji, ale o to,
ze Zope3 jest lepiej zaprojektowany od Zope2. A ta ksiazka to ladnie
pokazuje. Nic wiecej.
--
JZ
Darek Suchojad
Cześć,
> Na sile mozna w pythonie tworzyc spore rzeczy (np: zope i plone), bardzo
> latwo spore rzeczy kompletnie spieprzyc (np: zope i plone).
O co z tym Zopem i Plonem chodzi? Często-gęsto podkreślasz
jakie to są słabe narzędzia, okej, Twoja sprawa, mów co chcesz.
Ale czemu ich w ogóle użyłeś, skoro wiedziałeś, że nie będą nadawały
się do Twojego projektu?
darek
Piotr Dembiński
[C# i Python]
> Jestem głodny Waszych uwag na ten temat.
IMO Python to taki imperatywny, trochę 'wykastrowany' Lisp,
dlatego wiele rzeczy, o których tutaj piszesz jest niemożliwe
do zrobienia.
Z drugiej strony, czy w C# można tworzyć i dokompilowywać kawałki
kodu w trakcie działania programu?
--
http://www.piotr.dembiński.prv.pl
Piotr Dembiński
[...]
> Wszystkie narzedzia do pythona wygladaja malo powaznie.
heh, ja sobie podpiąłem pod okienko z Pythonem tę stopę z Monty Pythona,
która pojawia się na koniec animacji :>
--
http://www.piotr.dembiński.prv.pl
Piotr Dembiński
[...]
> http://bicyclerepair.sourceforge.net/
Ale to prawie nic nie potrafi :)
>> bo kod zawiera za malo informacji
>
> A introspekcja ze wstydu kurczy się i pufff! - znika w obłoku logiki.
Jedyna pewna metoda to testy.
--
http://www.piotr.dembiński.prv.pl
Piotr Dembiński
[refaktoryzacja]
> Czasami analiza statyczna jest konieczna, w tym sęk...
Analiza statyczna tak, ale nie w językach dynamicznie typowanych.
>
>>> i dodatkowo python pozwala typy tworzyc dynamicznie.
>>> Mozna co najwyzej regexpami podmieniac na chybil trafil nazwy metod i
>>> klas, trudno wylapac bledy powstale w wyniku takiej zabawy. Wszystkie
>>> narzedzia do pythona wygladaja malo powaznie.
>>
>>
>> Uwaga na nisko przelatujące kwantyfikatory.
>
> que?
<wziut>
--
http://www.piotr.dembiński.prv.pl
Piotr Dembiński
[...]
> Dla mnie to b. intuicyjny jezyk i prawie w ogole nie musze zagladac
> do manuali
Ta intuicyjność może być zmorą, jak chcesz napisać coś, co operuje
na kodzie Pythonowym bez żadnych założeń co do tego kodu.
--
http://www.piotr.dembiński.prv.pl
Jarek Zgoda
> - niemożność wylistowania składowych obiektu (w VS: Ctrl+Space) wraz z
> podręczną dokumentacją dla każdej składowej (metody, atrybuty). Osoby
> piszące w nowoczesnych IDE wiedzą o co mi chodzi.
A my to znamy od drugiej mańki -- dir(obj) wypisuje zawartość obiektu.
> To drugie wynika z faktu, że w Pythonie rzadko kiedy da się statycznie
> ustalić typ obiektu (jeśli się da, najlepsze pythonowe IDE potrafią
> wylistować składowe).
Zawsze się da, type(obj) zwraca klasę typu obiektu.
> Niby pierdółki... ale *naprawdę* ma to zasadniczy wpływ na wydajność.
Eric3 ma wszystko to, czego nie widziałeś. Po prostu masz ograniczoną
percepcję rzeczywistości.
> Jestem głodny Waszych uwag na ten temat.
Moim zdaniem nie wiesz, o czym piszesz. Troll?
(Nie było mnie ze 2 tygodnie i pewnie inni już doszli do tego samego,
ale NMSP)
--
Jarek Zgoda
http://jpa.berlios.de/ | http://www.zgodowie.org/
Tomasz Bieruta
> Zauważyłem, że choć Python jest bardziej ekspresywny niż C#, to jednak
> wydajność tworzenia oprogramowania jest istotnie większa w tym drugim...
hmm, a jak dlugo programujesz w C# ?
> Spostrzegłem, że składają się na to dwie prozaiczne rzeczy:
> - bardzo słaba (w porównaniu do MSDN) dokumentacja bibliotek Pythona
> - niemożność wylistowania składowych obiektu (w VS: Ctrl+Space) wraz z
> podręczną dokumentacją dla każdej składowej (metody, atrybuty). Osoby
> piszące w nowoczesnych IDE wiedzą o co mi chodzi.
Wing IDE, Spy, ... cala masa. Osobiscie uwazam, ze dokumentacja pythona jest
lepsza niz MSDN :-)
> To drugie wynika z faktu, że w Pythonie rzadko kiedy da się statycznie
> ustalić typ obiektu (jeśli się da, najlepsze pythonowe IDE potrafią
> wylistować składowe).
>
> Niby pierdółki... ale *naprawdę* ma to zasadniczy wpływ na wydajność.
to akurat zaden argument, to o czym piszesz to tylko toolsy ulatwiajace
lekko prace. Osobiscie praktycznie nieuzywam zadnych tego typu edytorow
(poprostu mi przeszkadza cos takiego). A pracowalem juz z produktami
Borlanda, ktory (sam chyba przyznasz) ma najlepsze narzedzia IDE (a
szczegolnie helpa).
Gdy pobawisz sie troche z pythonem, uzyjesz mix-ins, metaclassy itp. to
zauwazysz roznice i potencjal pythona.
Ostatnio zainteresowalem sie zope3, poczytaj troche o architekturze. Z
poczatku wydaje sie trudna (malo dokumentacji), ale nie jest tak zle.
Pozdrawiam
Tomek
Qertoip
> Dnia Tue, 10 May 2005 11:14:12 +0200, Qertoip <qe...@o2.pl> napisał:
>
> [C# i Python]
>
>> Jestem głodny Waszych uwag na ten temat.
>
> IMO Python to taki imperatywny, trochę 'wykastrowany' Lisp,
O nawiasy na pewno ;)
> Z drugiej strony, czy w C# można tworzyć i dokompilowywać kawałki
> kodu w trakcie działania programu?
Tak.
--
Pozdr.
Piotrek
Piotr Dembiński
[...]
> To akurat nie problem, kompilator Ocamla potrafi zgadywac typ funkcjina podstawie argumentow, dobre ide tez by moglo - jedyne wymaganieto takie, zeby kiedys ten typ jakos okreslic.
#v+
from posix import environ
class FallbackClass:
pass
class MyClass:
pass
if '__main__' == __name__:
try:
cname = environ['PYCLASS']
except KeyError:
cname = 'FallbackClass'
o = eval('%s()' % cname)
print o, type(o), id(o)
#v-
> Chodzi o to, ze klasa moze
> sie zmieniac w czasie dzialania programu.
Plus każdy obiekt może mieć swoje własne, również dodawane
w trakcie działania programu, metody i pola.
--
http://www.piotr.dembiński.prv.pl
Piotr Dembiński
[...]
> dir(obiekt) - listuje metody i dane
W danym punkcie działania programu -- przy określonym stanie środowiska :)
[...]
> ... nie porownuj "obrazkow", bo IDE jest wiele, jak chcesz
> miec cos z duza iloscia podpowiedzi, to wybierz te najbardziejbajerzaste.
Z mniej bajerzastych, to pod emacsem też jest jakiś object browser
dla Pythona. No i semantic.
--
http://www.piotr.dembiński.prv.pl
Qertoip
> Qertoip napisał(a):
>
>> - niemożność wylistowania składowych obiektu (w VS: Ctrl+Space) wraz z
>> podręczną dokumentacją dla każdej składowej (metody, atrybuty). Osoby
>> piszące w nowoczesnych IDE wiedzą o co mi chodzi.
>
> A my to znamy od drugiej mańki -- dir(obj) wypisuje zawartość obiektu.
Nie o to chodzi. Nie zrozumiałeś problemu. Ja chcę edytując kod źródłowy
nacisnąć kropkę (lub Ctrl+Space) i mieć *zawsze* listę składowych w
podręcznym okienku, a w drugim dokumentację do aktualnie podświetlonej
składowej. Jeśli to nie wystarczy, zamieszczę screenshota :)
>> To drugie wynika z faktu, że w Pythonie rzadko kiedy da się statycznie
>> ustalić typ obiektu (jeśli się da, najlepsze pythonowe IDE potrafią
>> wylistować składowe).
>
> Zawsze się da, type(obj) zwraca klasę typu obiektu.
Dajesz odpowiedź na całkiem inny problem.
type( obj ) można użyć w czasie *wykonania* a nie podczas edycji źródła.
Zwróć uwagę na słowo "statycznie" w moim poście. Przykład niemożności
statycznego ustalenia typu podałem w innym poście w tym wątku.
> Po prostu masz ograniczoną percepcję rzeczywistości.
> [...]
> Moim zdaniem nie wiesz, o czym piszesz. Troll?
Licz się ze słowami.
--
Pozdr.
Piotrek
Jarek Zgoda
>>>- niemożność wylistowania składowych obiektu (w VS: Ctrl+Space) wraz z
>>>podręczną dokumentacją dla każdej składowej (metody, atrybuty). Osoby
>>>piszące w nowoczesnych IDE wiedzą o co mi chodzi.
>>
>>A my to znamy od drugiej mańki -- dir(obj) wypisuje zawartość obiektu.
>
> Nie o to chodzi. Nie zrozumiałeś problemu. Ja chcę edytując kod źródłowy
> nacisnąć kropkę (lub Ctrl+Space) i mieć *zawsze* listę składowych w
> podręcznym okienku, a w drugim dokumentację do aktualnie podświetlonej
> składowej. Jeśli to nie wystarczy, zamieszczę screenshota :)
Zgłoś ten problem do producenta IDE, nie do samego języka. Język
udostępnia API do uzyskania takich informacji.
>>>To drugie wynika z faktu, że w Pythonie rzadko kiedy da się statycznie
>>>ustalić typ obiektu (jeśli się da, najlepsze pythonowe IDE potrafią
>>>wylistować składowe).
>>
>>Zawsze się da, type(obj) zwraca klasę typu obiektu.
>
> Dajesz odpowiedź na całkiem inny problem.
> type( obj ) można użyć w czasie *wykonania* a nie podczas edycji źródła.
> Zwróć uwagę na słowo "statycznie" w moim poście. Przykład niemożności
> statycznego ustalenia typu podałem w innym poście w tym wątku.
W Pythonie nie ma rozróżnienia czasu wykoniania od czasu
"nie-wykonania", ponieważ jest językiem interpretowanym i nie ma w nim
możliwości przeprowadzenia "częściowej kompilacji" (tego używają różne
IDE do ustalenia RTTI).
Zgłoś ten problem do producenta IDE, nie do samego języka. Język
udostępnia API do uzyskania takich informacji.
>>Po prostu masz ograniczoną percepcję rzeczywistości.
>>[...]
>>Moim zdaniem nie wiesz, o czym piszesz. Troll?
>
> Licz się ze słowami.
Po prostu nie wiesz, o czym piszesz. Na 100%. Chyba jesteś zwykłym trollem.
Qertoip
Napisałem:
> Nie o to chodzi. Nie zrozumiałeś problemu. Ja chcę edytując kod źródłowy
> nacisnąć kropkę (lub Ctrl+Space) i mieć *zawsze* listę składowych w
> podręcznym okienku, a w drugim dokumentację do aktualnie podświetlonej
> składowej. Jeśli to nie wystarczy, zamieszczę screenshota :)
A teraz dla wszystkich proponujących dir( obj ) zamieszczam screenshota:
http://www.wlodarek.top100.net.pl/ObjectMembersList.png
"Bajer", "pierdółka"?
Owszem.
Ten bajer ma jednak to do siebie, że zaoszczędza mnóstwo czasu, jeśli
człowiek nie ma używanej biblioteki w małym palcu. Czyli prawie zawsze przy
obecnych potężnych bibliotekach (batteries included).
I dlatego podnoszę tę kwestię w kontekście języków dynamicznie typowanych,
gdzie nie da się jej w pełni zrealizować. Niestety :(
--
Pozdr.
Piotrek
Piotr Dembiński
[ciap]
> Ja mogę z osobistego doświadczenia porównać to schematycznie tak:
>
> Angielski
'do the thing'
> Polski
'wiśta, wio!'
> Python > C ~ C++ > asembler x86 ;) > Java >> Perl >>>>> PHP
klik, klik, tap tap tap tap klik tap klik ...
> od najwydajniejszych dla swojej klasy zastosowań do najmniej wydajnych
> ;) co przekłada się bezpośrednio na jakość "ideologiczną" języka.
Graham określił to, o czym piszesz jako 'moc języka'. To jest chyba
określenie intuicyjne. Generalnie ja to widzę tak, że języki,
które mają introspekcję, dają większą moc programiście w wyrażaniu
tego, co chce stworzyć.
Idąc za tym intuicyjnym określeniem, ja bym umieścił obok siebie
Pythona, lispy i assemblery. Co do perla i PHP to nie znam, może się
zmieszczą. Najniżej byłaby faszystowska Ada :>
--
http://www.piotr.dembiński.prv.pl
JZ
> Ta intuicyjność może być zmorą, jak chcesz napisać coś, co operuje
> na kodzie Pythonowym bez żadnych założeń co do tego kodu.
No zawsze musisz wczesniej wiedziec co chcesz napisac. A do wiekszych
aplikacji bez dobrego projektu tego co to ma byc i jak dzialac daleko nie
zajedziesz. Python tylko ulatwia sam proces kodowania. Zmniejsza
czestotliwosc przerywania pracy w celu wertowania nieliczonych stron
dokumentacji do bibliotekl czy API. Dokumentacja do javy, he, he, he.
--
JZ
Jarek Zgoda
> Idąc za tym intuicyjnym określeniem, ja bym umieścił obok siebie
> Pythona, lispy i assemblery. Co do perla i PHP to nie znam, może się
> zmieszczą. Najniżej byłaby faszystowska Ada :>
Jeżeli ADA jest "faszystowska", to jakim przymiotnikiem określisz COBOL?
Moim zdaniem "kurewski" jest najodpowiedniejszy (przy założeniu że ADA
jest "faszystowska").
Jarek Zgoda
> A teraz dla wszystkich proponujących dir( obj ) zamieszczam screenshota:
> http://www.wlodarek.top100.net.pl/ObjectMembersList.png
>
> "Bajer", "pierdółka"?
Zgłoś się do producenta Twojego IDE, że tego jeszcze nie ma. I odczep
się od języka. Python nie ma z tym nic wspólnego. Trollu.
Qertoip
>> Nie o to chodzi. Nie zrozumiałeś problemu. Ja chcę edytując kod źródłowy
>> nacisnąć kropkę (lub Ctrl+Space) i mieć *zawsze* listę składowych w
>> podręcznym okienku, a w drugim dokumentację do aktualnie podświetlonej
>> składowej. Jeśli to nie wystarczy, zamieszczę screenshota :)
>
> Zgłoś ten problem do producenta IDE, nie do samego języka. Język
> udostępnia API do uzyskania takich informacji.
Ciągle nie dostrzegasz problemu. Producenci IDE mają związane ręce.
Mogą zrealizować (i zrealizowali) mój postulat tylko *częściowo*.
Problem polega na tym, że:
_nie_zawsze_da_się_ustalić_typ_obiektu_bez_interpretacji_programu_
To prosty paradoks: gdyby się dało, Python nie byłby językiem dynamicznie
typowanym.
Patrz też posty Przemka Wiśniewskiego i Piotra Dembińskiego, zwłaszcza ten
z 2005-05-10 21:59:16.
>>>Po prostu masz ograniczoną percepcję rzeczywistości.
>>>[...]
>>>Moim zdaniem nie wiesz, o czym piszesz. Troll?
>>
>> Licz się ze słowami.
>
> Po prostu nie wiesz, o czym piszesz. Na 100%.
Wiem doskonale o czym piszę.
> Chyba jesteś zwykłym trollem.
Powtarzam, licz się ze słowami.
--
Pozdr.
Piotrek
JZ
>> A teraz dla wszystkich proponujących dir( obj ) zamieszczam screenshota:
>> http://www.wlodarek.top100.net.pl/ObjectMembersList.png
>>
>> "Bajer", "pierdółka"?
>
> Zgłoś się do producenta Twojego IDE, że tego jeszcze nie ma. I odczep
> się od języka. Python nie ma z tym nic wspólnego. Trollu.
Akuraqt to co pokazal kolega na screenshocie to nic az tak rewelacyjnego.
Wing IDE pokazuje podobne podpowiedzi. Problem lezy glebiej.
Kiedys czytalem fajny artykul o tym ze generalnie programisci dziela sie na
tych zorientowanych na jezyk i tych zorientowanych na edytor, narzedzie do
tworzenia kodu. Im bardziej spuchniety od tych wszystkich definicji, typow
i innych gadow kod, tym lepszego edytora-pomagacza trzeba programiscie aby
sie nie zgubil jak w lesie. W Delphi, C, C# czy Javie bez takiego Eclipse,
Visual Studio czy innego Borlanda to praktycznie nie da sie pisac. Dlatego
uzytkownicy takich narzedzi czuja sie zagubieni jak zobacza Pythona czy
Rubiego, gdzie dynamika i prostota jezyka powoduje ze posiadanie dobrego
IDE (mimo ze pozyteczne) nie jest az tak *kluczowe*. Mozliwosci tych
jezykow oszczedzaja znacznie wiecej czasu niz by sie to z pozoru moglo
wydawac. Zanim taka kobyla IDE sie odpali, skompiluje i wypluje bledy ktore
potem trzeba szukac w 15x wiekszym kodzie, to czesto szybciej w jezyku
dynamicznym sie sprawdzi od reki w interpreterze.
Dzis wysmarowalem w pare minut dwa skrypty pythona przetwarzajace pliki.
Tylko raz zajrzalem do manuala odnosnie biblioteki shutil bo ktora rzadko
uzyw. Nawet wole nie myslec ile musialbym sie meczyc aby to samo zrobic w
Javie czy C#. Czlowiek ktory mi zlecal to zadanie nie mogl sie nadziwic co
mi tak szybko poszlo. :))
--
JZ
Grzegorz Staniak
A Qertoip sobie idzie i śpiewa sobie tak:
> A teraz dla wszystkich proponujących dir( obj ) zamieszczam screenshota:
> http://www.wlodarek.top100.net.pl/ObjectMembersList.png
>
> "Bajer", "pierdółka"?
>
> Owszem.
>
> Ten bajer ma jednak to do siebie, że zaoszczędza mnóstwo czasu, jeśli
> człowiek nie ma używanej biblioteki w małym palcu. Czyli prawie zawsze przy
> obecnych potężnych bibliotekach (batteries included).
Akurat w przypadku bibliotek prawdopodobieństwo wsytąpienia problemów takich
jak poprzednio opisywane jest dość niewielkie.
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Piotr Dembiński
[...]
>> IMO Python to taki imperatywny, trochę 'wykastrowany' Lisp,
>
> O nawiasy na pewno ;)
O nawiasy to Haskell :)
>> Z drugiej strony, czy w C# można tworzyć i dokompilowywać kawałki
>> kodu w trakcie działania programu?
>
> Tak.
o
--
http://www.piotr.dembiński.prv.pl
JZ
> Ciągle nie dostrzegasz problemu. Producenci IDE mają związane ręce.
> Mogą zrealizować (i zrealizowali) mój postulat tylko *częściowo*.
Twoj postulat w tym wypadku nie ma sensu w srodowisku jezykow dynamicznych.
Masz przyzwyczajenia z jezykow statycznych, ktore powoduja ze widzisz to
jako wade to, ze Python nie jest Java czy C. :) Troche sie pobawisz
Pythonem to zmienisz zdanie. Ja na poczatku to nie moglem przelknac np.
braku klamr dla blokow. Nie wyobrazalem sobie jak kod bez nich moze byc
czytelny. A teraz to sie z tego smieje, bo to co wydawalo mi sie wada
okazalo sie ostatecznie zaleta.
--
JZ
Piotr Dembiński
> Piotr Dembiński napisał(a):
>
>> Idąc za tym intuicyjnym określeniem, ja bym umieścił obok siebie
>> Pythona, lispy i assemblery. Co do perla i PHP to nie znam, może się
>> zmieszczą. Najniżej byłaby faszystowska Ada :>
>
> Jeżeli ADA jest "faszystowska", to jakim przymiotnikiem określisz COBOL?
> Moim zdaniem "kurewski" jest najodpowiedniejszy (przy założeniu że ADA
> jest "faszystowska").
COBOL to język dla księgowych, tak słyszałem :>
--
http://www.piotr.dembiński.prv.pl
Piotr Dembiński
> Qertoip napisał(a):
>
>> A teraz dla wszystkich proponujących dir( obj ) zamieszczam screenshota:
>> http://www.wlodarek.top100.net.pl/ObjectMembersList.png
>>
>> "Bajer", "pierdółka"?
>
> Zgłoś się do producenta Twojego IDE, że tego jeszcze nie ma. I odczep
> się od języka. Python nie ma z tym nic wspólnego. Trollu.
Trochę ma.
--
http://www.piotr.dembiński.prv.pl
Piotr Dembiński
> Dnia Tue, 10 May 2005 21:17:22 +0200, Jarek Zgoda napisał(a):
>
>> Qertoip napisał(a):
>>
>>> - niemożność wylistowania składowych obiektu (w VS: Ctrl+Space) wrazz podręczną dokumentacją dla każdej składowej (metody, atrybuty).Osoby piszące w nowoczesnych IDE wiedzą o co mi chodzi.
>>
>> A my to znamy od drugiej mańki -- dir(obj) wypisuje zawartość obiektu.
>
> Nie o to chodzi. Nie zrozumiałeś problemu. Ja chcę edytując kod źródłowy
> nacisnąć kropkę (lub Ctrl+Space) i mieć *zawsze* listę składowych w
> podręcznym okienku, a w drugim dokumentację do aktualnie podświetlonej
> składowej. Jeśli to nie wystarczy, zamieszczę screenshota :)
Już wcześniej napisałem: emacs plus object browser.
--
http://www.piotr.dembiński.prv.pl
Jarek Zgoda
>>> Idąc za tym intuicyjnym określeniem, ja bym umieścił obok siebie
>>> Pythona, lispy i assemblery. Co do perla i PHP to nie znam, może się
>>> zmieszczą. Najniżej byłaby faszystowska Ada :>
>>
>> Jeżeli ADA jest "faszystowska", to jakim przymiotnikiem określisz COBOL?
>> Moim zdaniem "kurewski" jest najodpowiedniejszy (przy założeniu że ADA
>> jest "faszystowska").
>
> COBOL to język dla księgowych, tak słyszałem :>
Ale to programiści COBOL-a zarabiają najwięcej. ;)
Jarek Zgoda
> Ciągle nie dostrzegasz problemu. Producenci IDE mają związane ręce.
> Mogą zrealizować (i zrealizowali) mój postulat tylko *częściowo*.
>
> Problem polega na tym, że:
> _nie_zawsze_da_się_ustalić_typ_obiektu_bez_interpretacji_programu_
Ty w ogóle nie kumasz, jak działa "code completion". Wróć do źródła, np.
obejrzyj sobie źródła Eclipse. Jak pojmiesz co to jest "partial
compilation" i dlaczego w Pythonie trzeba to robić inaczej, to pogadamy.
Potem podnoś swoje obiekcje.
> To prosty paradoks: gdyby się dało, Python nie byłby językiem dynamicznie
> typowanym.
>
> Patrz też posty Przemka Wiśniewskiego i Piotra Dembińskiego, zwłaszcza ten
> z 2005-05-10 21:59:16.
Niby rozumiesz, ale w ogóle nie rozumiesz. Albo kpisz, albo o drogę pytasz.
>>Chyba jesteś zwykłym trollem.
>
> Powtarzam, licz się ze słowami.
Nie, nie "chyba". Na 100% jesteś trollem. Sio.
Climbus
> czestotliwosc przerywania pracy w celu wertowania nieliczonych stron
> dokumentacji do bibliotekl czy API. Dokumentacja do javy, he, he, he.
Pythonowe API jest dużo słabiej udokumentowane niż Javowe. A jak
porównać jeszcze wielkość tych bibliotek to Python nie ma szans.
Mniejsza częstotliowść zaglądania do dokumentacji wiąze się z tym że
python nie ma prawie bibliotek klasy enterprise. Poprogramuj w Zopie bez
zaglądania do dokumentacji:)
Pozdr
Climbus
Adam Przybyla
> Dnia Tue, 10 May 2005 21:17:22 +0200, Jarek Zgoda napisał(a):
>
>> Qertoip napisał(a):
>>
>>> - niemożność wylistowania składowych obiektu (w VS: Ctrl+Space) wraz z
>>> podręczną dokumentacją dla każdej składowej (metody, atrybuty). Osoby
>>> piszące w nowoczesnych IDE wiedzą o co mi chodzi.
>>
>> A my to znamy od drugiej mańki -- dir(obj) wypisuje zawartość obiektu.
>
> Nie o to chodzi. Nie zrozumiałeś problemu. Ja chcę edytując kod źródłowy
> nacisnąć kropkę (lub Ctrl+Space) i mieć *zawsze* listę składowych w
> podręcznym okienku, a w drugim dokumentację do aktualnie podświetlonej
> składowej. Jeśli to nie wystarczy, zamieszczę screenshota :)
To powinno Ci pomoc:
gormenghast:/home/adam>echo $PYTHONSTARTUP
/usr/local/sbin/rc.py
gormenghast:/home/adam>cat $PYTHONSTARTUP
try:
import readline
except ImportError:
print "No Redaline"
else:
import rlcompleter
readline.parse_and_bind("tab: complete")
import os
histfile=os.path.join(os.environ["HOME"],".pyhist")
try:
readline.read_history_file(histfile)
except (AttributeError,IOError):
pass
try:
import atexit
except ImportError:
pass
else:
atexit.register(readline.write_history_file,histfile)
del os,histfile
gormenghast:/home/adam>
Z powazaniem
Adam Przybyla
Qertoip
> Dnia Tue, 10 May 2005 22:55:21 +0200, Qertoip napisał(a):
>
>> Ciągle nie dostrzegasz problemu. Producenci IDE mają związane ręce.
>> Mogą zrealizować (i zrealizowali) mój postulat tylko *częściowo*.
>
> Twoj postulat w tym wypadku nie ma sensu w srodowisku jezykow
> dynamicznych.
Widzę głos poparcia! No właśnie: od początku o tym piszę, że taki postulat
w dynamicznie typowanych językach nie jest w pełni realizowalny.
> Masz przyzwyczajenia z jezykow statycznych,
Mam. Dlatego też zaangażowałem się w niemały, niebanalny projekty w
Pythonie. Piszę rozproszony interpreter uproszczonego OCCAM2 (zero
centralizacji).
> ktore powoduja ze widzisz to jako wade to, ze Python nie jest Java czy C. :)
Przeciwnie. Inszość postrzegam jako zaletę, bo pozwala mi spojrzeć na
programowanie z innej strony.
Ale chyba nie chcesz powiedzieć, że ta "inna strona" ma same zalety,
żadnych wad?
> Ja na poczatku to nie moglem przelknac np. braku klamr dla blokow.
To akurat podoba mi się od samego początku. Wreszcie jest porządek i
zwięzłość.
--
Pozdr.
Piotrek
JZ
> Pythonowe API jest dużo słabiej udokumentowane niż Javowe. A jak
> porównać jeszcze wielkość tych bibliotek to Python nie ma szans.
Takze jak porownac wielkosc kodu C++ albo Javy to Python tez "nie ma szans"
bo jest od 5 do 15 razy mniejszy. :))
> Mniejsza częstotliowść zaglądania do dokumentacji wiąze się z tym że
> python nie ma prawie bibliotek klasy enterprise.
Jakies bzdury piszesz. Np. ktora biblioteka pythona nie jest "klasy
enterprise" i co to niby ma znaczyc? Pythonowe batteries included, czyli
biblioteka standardowa jest przeciez klasy enterprise, tzn. nadaje sie do
ciezkich, biznesowych zastosowan. Uchodzi za bardzo stabilna, potezna i
przejrzysta. Masz np. jakies uwagi do modulu re? :) A to ze sa inne
projekty mniej lub bardziej dojrzale to inna sprawa. Tak jest wszedzie i w
kazdym jezyku.
--
JZ
JZ
> Poprogramuj w Zopie bez zaglądania do dokumentacji:)
Zope2, bo jego masz pewnie glownie na mysli, ma zle zaprojektowane API.
Kazdy to wie. Dopiero Zope3 to zmienia. Poza tym Zope nie jest przeciez
czescia standardowej biblioteki Pythona. To tylko jedna z aplikacji wiec
porownywanie go do standardowych bibliotek Javy jest glebokim
nieporozumieniem.
--
JZ
baklarz
> > Python tylko ulatwia sam proces kodowania. Zmniejsza
>> czestotliwosc przerywania pracy w celu wertowania nieliczonych stron
>> dokumentacji do bibliotekl czy API. Dokumentacja do javy, he, he, he.
>
> Pythonowe API jest dużo słabiej udokumentowane niż Javowe. A jak
> porównać jeszcze wielkość tych bibliotek to Python nie ma szans.
;-)
--
Tomasz Drobiszewski
Climbus
> Zgłoś się do producenta Twojego IDE, że tego jeszcze nie ma. I odczep
> się od języka. Python nie ma z tym nic wspólnego. Trollu.
>
Trochę chyba się nie rozumiecie. Jak ktoś już wspomniał, Python nie ma
szans na przewidywanie typów. Jak dosatajesz coś z funkcji to nie wiesz
co to jest i po kropce nie ma szans abys dostał podpowiedź. W Javie masz
deklaracje i wiadomo co wyjdzie z tej funkcji, więc ide wie co
popowiedzieć. Tworzy to pewną stabilność kodowania ale zmniejsza
elastyczność. Duży program nigdy nie będzie elastyczny więc stosowanie
elastcznego języka (Python) trochę tu nie pasuje.
Wszystko to są sprzeczki dla sprzeczek. Python nie podskoczy Javie w
większych zastosowaniach, java nie podkoczy do pythona w mniejszych
elastycznych programach. Jest pewien obszar w którym oba te rozwiązania
mogą ze sobą konkurować.
Pythonowcy jak i inni PHPowcy zazwyczaj nie mają pojęcia o modelowaniu
aplikacji a pisanie unitestów to wg nich strata czasu. W javie
przynajmniej w czasie kompilacji część kodu zostanie sprawdzona.
Progrmuję na codzień w Pythonie i jestem z tego zadowolony bo to bardzo
fajny i miekki język, ale czasami wymiękam jak muszę jakieś
niestandardowe słabo udokumentowane biblioteki używać, które często są w
fazie alfa a pisza ze stable albo prawie stable.
--
Climbus
Qertoip
>>>Chyba jesteś zwykłym trollem.
>>
>> Powtarzam, licz się ze słowami.
>
> Nie, nie "chyba". Na 100% jesteś trollem. Sio.
Do tej pory starałem się prowadzić dyskusję z Tobą merytorycznie,
przymykając oko na Twoje wycieczki. Teraz skończyła mi się cierpliwość.
Będzie niemerytorycznie.
W ogóle nie starasz się zrozumieć problemu, jesteś nieobiektywny, piszesz
obok tematu. Fanatyzm to ostatnia rzecz, jakiej potrzebuje inżynieria
oprogramowania.
--
Pozdr.
Piotrek
JZ
>> Twoj postulat w tym wypadku nie ma sensu w srodowisku jezykow
>> dynamicznych.
>
> Widzę głos poparcia! No właśnie: od początku o tym piszę, że taki postulat
> w dynamicznie typowanych językach nie jest w pełni realizowalny.
Bo, jak napisalem, taki postulat jest tu *bez sensu*. Skoro sie tym
zgadzasz, to dlaczego stawiasz zarzut, ze ktos nie realizuje bezsensownych
postulatow?? To chyba dobrze, ze nie realizuje czegos co nie ma sensu,
prawda?
>> Masz przyzwyczajenia z jezykow statycznych,
>
> Mam. Dlatego też zaangażowałem się w niemały, niebanalny projekty w
> Pythonie.
Mozesz miec problemy jak od razu wchodzisz w duzy projekt w nowym jezyku
nie czujac jeszcze jego filozofii.
> Ale chyba nie chcesz powiedzieć, że ta "inna strona" ma same zalety,
> żadnych wad?
Zawsze sa jakies wady i zalety. Ja od paru lat uzywam pythona i zalety
zdecydowanie przewazaja cos co bym uznal za wade. Python jest rozwijany w
sposob o niebo lepszy od PHP czy innych jezykow, gdzie ktos arbitralnie
sobie cos tam wymysla. Bo jak ktos ma jakis pomysl na ulepszenie Pythona to
po prostu pisze nowy PEP i jak zbierze pozytywne opinie dodaje go do listy
http://python.org/peps/. Bardzo mi sie taka droga rozwoju jezyka podoba.
--
JZ
JZ
>> Pythonowe API jest dużo słabiej udokumentowane niż Javowe. A jak
>> porównać jeszcze wielkość tych bibliotek to Python nie ma szans.
> Python nie ma też szans w zabijaniu farm serwerów w porównaniu z java
> ;-)
ROTFL :))
--
JZ
JZ
> Progrmuję na codzień w Pythonie i jestem z tego zadowolony bo to bardzo
> fajny i miekki język, ale czasami wymiękam jak muszę jakieś
> niestandardowe słabo udokumentowane biblioteki używać, które często są w
> fazie alfa a pisza ze stable albo prawie stable.
Sam widzisz, ze twoj zarzut nie dotyczy standardowych bibliotek pythona,
ale jskichs trzeciorzednych modulow ktore ktos napisal lepiej albo gorzej.
W zwiazku z tym, ze domyslam sie co masz na mysli, ja bym na twoim miejscu
inaczej postawil problem: "potrzebuje modulu ktory realizuje to i owo, i
nie ma go w stanardowej bibliotece pythona, a te ktore znalazlem sa slabej
jakosci, w fazie alfa, beta itp. Java mi daje do tego bardziej dojrzale
biblioteki ale jest z kolei bardziej skomplikowana i nie ma szans abym
zdazyl od reki tego uzywac." Zycie jest niestety skomplikowane.
--
JZ
Climbus
> Zope2, bo jego masz pewnie glownie na mysli, ma zle zaprojektowane API.
> Kazdy to wie. Dopiero Zope3 to zmienia.
W zopie3 jesteś w stanie pisać bez zaglądania do dokumentacji? niesądze
> Poza tym Zope nie jest przeciez
> czescia standardowej biblioteki Pythona. To tylko jedna z aplikacji wiec
> porownywanie go do standardowych bibliotek Javy jest glebokim
> nieporozumieniem.
Co masz na myśli mówiąc standardowa biblioteka javy? j2se, j2ee czy j2me?
Nie porównuje standardwych bibliotek.
Standardowa biblioteka o niczym nie świadczy, liczy się ogół dostępnych
rozwiązań. Czym jest system system operacyjny bez oprogramowania jak nie
zabawką?
Climbus
> Takze jak porownac wielkosc kodu C++ albo Javy to Python tez "nie ma szans"
> bo jest od 5 do 15 razy mniejszy. :))
Nie porównuje ilości lini tylko ilość dostępnych funkcjonalnośći.
>>Mniejsza częstotliowść zaglądania do dokumentacji wiąze się z tym że
>>python nie ma prawie bibliotek klasy enterprise.
> Jakies bzdury piszesz. Np. ktora biblioteka pythona nie jest "klasy
> enterprise" i co to niby ma znaczyc? Pythonowe batteries included, czyli
> biblioteka standardowa jest przeciez klasy enterprise, tzn. nadaje sie do
> ciezkich, biznesowych zastosowan. Uchodzi za bardzo stabilna, potezna i
> przejrzysta.
Ta jasne, powiedz to Robertowi:) Z tego co sobie przypominam to w xmlrpc
są jakieś niedoróbki, dokumentacja też nie jest wspaniała, a
przynajmniej ja nie mogę się w niej znaleźć.
> A to ze sa inne
> projekty mniej lub bardziej dojrzale to inna sprawa. Tak jest wszedzie i w
> kazdym jezyku.
Ale tych dobrych w pathonie narazie jest mało w porównaniu z javą.
Przynajmniej takich, które zostały wypróbowane w dużych korporacjach.
JZ
>> Zope2, bo jego masz pewnie glownie na mysli, ma zle zaprojektowane API.
>> Kazdy to wie. Dopiero Zope3 to zmienia.
>
> W zopie3 jesteś w stanie pisać bez zaglądania do dokumentacji? niesądze
W ogole prawie nic w nim nie napisze, bo dopiero zaczalem czytac na jego
temat. Ale Zope3 to nie standardowa biblioteka Pythona ale konkretna,
calkiem zlozona aplikacja. Tylko ze podejrzewam iz sam jeden Zope3 jest
mniej zlozony niz dowolna z wielu technologii javy, np. J2SE czy JavaBeans,
Struts itp.
> Co masz na myśli mówiąc standardowa biblioteka javy? j2se, j2ee czy j2me?
Na przyklad. Java bez nich jest zupelnie bezuzyteczna. Tak jak Python bez
swojej biblioteki standardowej.
> Nie porównuje standardwych bibliotek.
A to dlaczego? Porownujesz standardowe biblioteki sunowskie z jakims
trzeciorzednym modulem napisanym przez Johna Browna? I to ma byc dobre
porownanie?
> Standardowa biblioteka o niczym nie świadczy, liczy się ogół dostępnych
> rozwiązań.
Tak, to prawda. Wszystko zalezy o *jakie* rozwiazania ci chodzi. Bo jesli o
te dotyczace wiekszosci codziennych zadan, przetwarzanie tekstow, plikow,
przewalanie czegos z i do internetu to Python ma doskonale i znacznie
lepsze rozwiazania od Javy.
> Czym jest system system operacyjny bez oprogramowania jak nie
> zabawką?
Python nie jest systemem operacyjnym. Jest jezykiem wyposazonym w bardzo
dobra, bogata biblioteke standardowa w ktorej zrobisz wiekszosc rzeczy.
--
JZ
Climbus
>>Nie porównuje standardwych bibliotek.
>
> A to dlaczego? Porownujesz standardowe biblioteki sunowskie z jakims
> trzeciorzednym modulem napisanym przez Johna Browna? I to ma byc dobre
> porownanie?
Jeżeli jakiś język ma być użyteczny to potrzebuję całego kompletu:
biblioteka standardowa, dobre bibilioteki zewnętrzne oraz narzędzia.
Sama biblioteka standardowa jest prawie bezuzyteczna w poważnych
zastasowaniach. Tak samo nawet najlepszy system operacyjny jest do kitu
jak nie ma dostępnego oprogramowania.
Dlatego porównuje ogół zagadnienia.
> Tak, to prawda. Wszystko zalezy o *jakie* rozwiazania ci chodzi. Bo jesli o
> te dotyczace wiekszosci codziennych zadan, przetwarzanie tekstow, plikow,
> przewalanie czegos z i do internetu to Python ma doskonale i znacznie
> lepsze rozwiazania od Javy.
Tak masz rację. Ma niektóre zrozwiązania które się nadają do czegoś
więcej niz do skryptologii, ale wraz ze wzrostem skomlikowania projektu
szala przechyla sie na stronę javy (i to szybciej niż myślisz).
> Python ... jest jezykiem wyposazonym w bardzo
> dobra, bogata biblioteke standardowa w ktorej zrobisz wiekszosc rzeczy.
cytat: "wiekszosci codziennych zadan, przetwarzanie tekstow, plikow,
przewalanie czegos z i do internetu"
Tak masz rację
JZ
>> Takze jak porownac wielkosc kodu C++ albo Javy to Python tez "nie ma szans"
>> bo jest od 5 do 15 razy mniejszy. :))
>
> Nie porównuje ilości lini tylko ilość dostępnych funkcjonalnośći.
Licza sie tylko te funkcjonalnosci jakie potrzebujesz. Ilosc nie ma
znaczenia. Czasem jest wrecz przeszkoda, bo nie wiadomo co wybrac.
>> A to ze sa inne projekty mniej lub bardziej dojrzale to inna sprawa. Tak
>> jest wszedzie i w kazdym jezyku.
>
> Ale tych dobrych w pathonie narazie jest mało w porównaniu z javą.
> Przynajmniej takich, które zostały wypróbowane w dużych korporacjach.
Owszem i co z tego? Python nie ma takiego wsparcia marketingowego jak Sun
czy M$. Ale jest tez sporo duzych firm ktore korzystaja z Pythona, np.
Google, Industrial Light and Magic, rozne organizacje rzadowe, pozarzadowe
i wojskowe.
--
JZ
JZ
> Jeżeli jakiś język ma być użyteczny to potrzebuję całego kompletu:
> biblioteka standardowa, dobre bibilioteki zewnętrzne oraz narzędzia.
> Sama biblioteka standardowa jest prawie bezuzyteczna w poważnych
> zastasowaniach.
Moze wpierw zdefiniuj owe tajemnicze "powazne zastosowania" bo ja nie wiem
o czym piszesz.
> Tak samo nawet najlepszy system operacyjny jest do kitu
> jak nie ma dostępnego oprogramowania.
Zle postawiony problem. Najlepszy system bez dobrego oprogramowania do
realizacji *moich potrzeb* jest bezuzyteczny. Co mi po wielosci softu ktory
w moim konkretnym wypadku bedzie bezuzyteczny? Poza tym moze byc nawet
odwrotnie. Moze byc kiepski jezyk a dobre oprogramowanie. Np. PHP i
Invision Power Board, najlepsze forum jakie znam.
> Dlatego porównuje ogół zagadnienia.
Nie ma czegos takiego jak ogol. Zawsze sa konkrety. Inaczej rozmywa sie
cale twoje porownywanie, bo w praktyce zawsze masz do czynienia z
konkretami a nie z wszystkimi mozliwymi zastosowaniami. Uwazam, ze do
*naprawde* wiekszosci zastosowan java nie ma wcale lepszych od pythona
rozwiazan. A wiekszosc zastosowan to nie przeciez zadne ciezkie serwery
klastrowe i przetwarzanie rozproszone.
--
JZ
Qertoip
> Dnia Tue, 10 May 2005 23:33:08 +0200, Qertoip napisał(a):
>
>>> Twoj postulat w tym wypadku nie ma sensu w srodowisku jezykow
>>> dynamicznych.
>>
>> Widzę głos poparcia! No właśnie: od początku o tym piszę, że taki postulat
>> w dynamicznie typowanych językach nie jest w pełni realizowalny.
> Bo, jak napisalem, taki postulat jest tu *bez sensu*.
Wcześniej napisałeś:
"Prawie wszystkie edytory do Pythona to potrafią. Chyba nie widziałeś Wing
IDE w akcji... Podpowiadać podobnie potrafi zarówno PythonWin,
Eclipse+pydev, SPE, Boa Constructor itp."
Tak więc twórcy wiodących edytorów uważają postulat (podpowiadanie jak na
screenshot'cie) za słuszny!
> Skoro sie tym zgadzasz, to dlaczego stawiasz zarzut, ze ktos nie
> realizuje bezsensownych postulatow??
Świadomie, żartobliwie nadinterpretowałem Twoją wypowiedź.
> To chyba dobrze, ze nie realizuje czegos co nie ma sensu, prawda?
Ma sens, tylko nie da się w pełni zrealizować z oczywistych przyczyn.
>>> Masz przyzwyczajenia z jezykow statycznych,
>>
>> Mam. Dlatego też zaangażowałem się w niemały, niebanalny projekty w
>> Pythonie.
>
> Mozesz miec problemy jak od razu wchodzisz w duzy projekt w nowym jezyku
> nie czujac jeszcze jego filozofii.
Projekt jest hobbystyczno-uczelniany, dlatego nie grożą mi problemy.
Jednym z jego podstawowych celów jest właśnie nauka filozofii Pythona.
> Ja od paru lat uzywam pythona i zalety zdecydowanie przewazaja cos co bym
> uznal za wade.
Nie przeczę! Od początku nauki dostrzegam wiele pozytywnych aspektów.
Za wcześnie jednak, abym mógł stwierdzić że (wady or zalety) przeważają.
--
Pozdr.
Piotrek
JZ
> Tak więc twórcy wiodących edytorów uważają postulat (podpowiadanie jak na
> screenshot'cie) za słuszny!
Podpowiadanie - tak. Ale nie *tego* co postulowałeś, bo to akurat nie ma
sensu dla jęz. dynamicznych.
> Ma sens, tylko nie da się w pełni zrealizować z oczywistych przyczyn.
Nie da się zrealizowac bo to nie ma specjalnie sensu *dla języków
dynamicznych*.
--
JZ
RAJ
COBOL?
> >> Moim zdaniem "kurewski" jest najodpowiedniejszy (przy założeniu że ADA
> >> jest "faszystowska").
> >
> > COBOL to język dla księgowych, tak słyszałem :>
>
> Ale to programiści COBOL-a zarabiają najwięcej. ;)
Pewnie maja duzy dodatek za szkodliwe warunki i ryzyko zawodowe.
> Jarek Zgoda
--
Pozdrawiam
RAJ
http://strategie.gildia.com
Grzegorz Staniak
A Climbus sobie idzie i śpiewa sobie tak:
>> Zgłoś się do producenta Twojego IDE, że tego jeszcze nie ma. I odczep
>> się od języka. Python nie ma z tym nic wspólnego. Trollu.
>
> Trochę chyba się nie rozumiecie. Jak ktoś już wspomniał, Python nie ma
> szans na przewidywanie typów.
... chyba, że przejdzie opcjonalne typowanie statyczne:
http://www.artima.com/weblogs/viewpost.jsp?thread=85551
[---]
> Progrmuję na codzień w Pythonie i jestem z tego zadowolony bo to bardzo
> fajny i miekki język, ale czasami wymiękam jak muszę jakieś
> niestandardowe słabo udokumentowane biblioteki używać, które często są w
> fazie alfa a pisza ze stable albo prawie stable.
Ale to raczej nie jest cecha języka.
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Grzegorz Staniak
>> http://bicyclerepair.sourceforge.net/
>
> Ale to prawie nic nie potrafi :)
Bo dopiero powstaje. Numer wersji zauważyłeś? Tym niemniej, skutecznie
falsyfikuje tezę, jakoby Python uniemożliwał tworzenie narzędzi do
refaktoryzacji kodu, a jedyną możliwość w tym zakresie stanowiło "podmienianie
nazw zmiennych regexpami na oślep".
>>> bo kod zawiera za malo informacji
>>
>> A introspekcja ze wstydu kurczy się i pufff! - znika w obłoku logiki.
>
> Jedyna pewna metoda to testy.
Tym niemniej, introspekcja dostarcza dość informacji, by nie trzeba było
opierać się na "podmienianiu nazw regexpami".
Przemek Wiśniewski
> przejrzysta. Masz np. jakies uwagi do modulu re? :) A to ze sa inne
Z tym modulem re jako enterprajsem to wystrzeliles w kosmos :)
--
Przemek Wiśniewski
Przemek Wiśniewski
> Przemek Wiśniewski wrote:
>
> Cześć,
>
>
>>Na sile mozna w pythonie tworzyc spore rzeczy (np: zope i plone), bardzo
>>latwo spore rzeczy kompletnie spieprzyc (np: zope i plone).
>
>
> O co z tym Zopem i Plonem chodzi? Często-gęsto podkreślasz
> jakie to są słabe narzędzia, okej, Twoja sprawa, mów co chcesz.
>
> Ale czemu ich w ogóle użyłeś, skoro wiedziałeś, że nie będą nadawały
> się do Twojego projektu?
Nie wiedzialem, nie spodziewalem sie ze plone nie nadaje sie do niczego
wiecej niz tylko zainstalowanie i podmiana skorek.
--
Przemek Wiśniewski
JZ
>> przejrzysta. Masz np. jakies uwagi do modulu re? :) A to ze sa inne
>
> Z tym modulem re jako enterprajsem
Chcesz powiedziec, ze to modul gowniany i niedopracowany? Nie rozsmieszaj
mnie. Chyba roznimy sie definicja slowa enterprise.
--
JZ
Przemek Wiśniewski
> Dnia Tue, 10 May 2005 22:42:50 +0200, Jarek Zgoda napisał(a):
>
>>>A teraz dla wszystkich proponujących dir( obj ) zamieszczam screenshota:
>>>http://www.wlodarek.top100.net.pl/ObjectMembersList.png
>>>
>>>"Bajer", "pierdółka"?
>>Zgłoś się do producenta Twojego IDE, że tego jeszcze nie ma. I odczep
>>się od języka. Python nie ma z tym nic wspólnego. Trollu.
>
>
> Wing IDE pokazuje podobne podpowiedzi. Problem lezy glebiej.
>
> Kiedys czytalem fajny artykul o tym ze generalnie programisci dziela sie na
> tych zorientowanych na jezyk i tych zorientowanych na edytor, narzedzie do
> tworzenia kodu. Im bardziej spuchniety od tych wszystkich definicji, typow
> i innych gadow kod, tym lepszego edytora-pomagacza trzeba programiscie aby
> sie nie zgubil jak w lesie. W Delphi, C, C# czy Javie bez takiego Eclipse,
Nasz lokalny guru/autorytet pythona, sir Adam Karpierz sam przytaczal
wizje wizualnego srodowiska i dzialajacego w nim jezyka jako narzedzia
przyszlosci.
> Visual Studio czy innego Borlanda to praktycznie nie da sie pisac. Dlatego
> uzytkownicy takich narzedzi czuja sie zagubieni jak zobacza Pythona czy
Bzdury piszesz, bo nie uzywasz na codzien takiego Eclipsa. Nikt sie
zgubiony nie czuje. Chodzi o to, ze dobre IDE, ktore po jednym kliku
odwala kupe nudnej roboty to cos naprawde pozytecznego.
> Rubiego, gdzie dynamika i prostota jezyka powoduje ze posiadanie dobrego
> IDE (mimo ze pozyteczne) nie jest az tak *kluczowe*. Mozliwosci tych
> jezykow oszczedzaja znacznie wiecej czasu niz by sie to z pozoru moglo
Ja wole mozliwosci IDE i jezyk bez zadnych ulatwiaczy, z prostymi
regulami. Wez dla porownania HTML(SGML) i XML - html ma mase ulatwiaczy,
np: mozna opuszczac cudzyslowy w argumentach, olewac wielkosc liter,
mozna liczyc na tolerancje przegladarki. Dlugo nie bylo sensownych
graficznych edytorow HTMLa, pierwszy byl Dreamweaver. Za to xml jest
bardziej zwarty, mniej tolerancyjny, za to latwiej z nim cokolwiek zrobic.
> wydawac. Zanim taka kobyla IDE sie odpali, skompiluje i wypluje bledy ktore
> potem trzeba szukac w 15x wiekszym kodzie, to czesto szybciej w jezyku
> dynamicznym sie sprawdzi od reki w interpreterze.
Bzdura.
> Dzis wysmarowalem w pare minut dwa skrypty pythona przetwarzajace pliki.
> Tylko raz zajrzalem do manuala odnosnie biblioteki shutil bo ktora rzadko
> uzyw. Nawet wole nie myslec ile musialbym sie meczyc aby to samo zrobic w
> Javie czy C#. Czlowiek ktory mi zlecal to zadanie nie mogl sie nadziwic co
> mi tak szybko poszlo. :))
Ilosc zagladniec do manuala jako wyznacznik lepszosci jest wrecz smieszna.
--
Przemek Wiśniewski
RobertSzefler
> Dnia Wed, 11 May 2005 00:53:27 +0200, Qertoip napisał(a):
>
>
>>Tak więc twórcy wiodących edytorów uważają postulat (podpowiadanie jak na
>>screenshot'cie) za słuszny!
>
>
> Podpowiadanie - tak. Ale nie *tego* co postulowałeś, bo to akurat nie ma
> sensu dla jęz. dynamicznych.
Oczywiście, że ma sens. Każdy obiekt ma typ, więc można ten typ
wywnioskować. To, że nie można go wywnioskować w ogólności statycznie,
wynika z tego, że system typów Pythona jest na tyle rozbudowany i
ogólny, że problem statycznego wnioskowania o typach jest
*nierozstrzygalny*. System typów Pythona jest po prostu równoważny z
pełną maszyną Turinga, więc nie można statycznie dowodzić twierdzeń o
równoważności czy stopie. Oczywiste jest też, że niektórzy
programiści/filozofowie informatyki uznają to za wadę.
>>Ma sens, tylko nie da się w pełni zrealizować z oczywistych przyczyn.
>
>
> Nie da się zrealizowac bo to nie ma specjalnie sensu *dla języków
> dynamicznych*.
Vide powyżej. Twoja argumentacja jest: bez sensu bo bez sensu dla jęz.
stat. Problem jest jasno postawiony i jednoznaczny, tyle że
nierozstrzygalny ze względu na język.
RobertSzefler
Cytując Forresta Gumpa: ten głupi, kto głupio robi.
Straszny jest brak zrozumienia wśród pythonowców dla Twojego
problemu/postulatów. Ja się z tym, co piszesz, w całości zgadzam, mimo
że prywatnie uważam Pythona za jeden z absolutnie najlepiej
zaprojektowanych języków. Jeśli inni pythonowcy tego nie rozumieją, bo
najwyraźniej *nie rozumieją*, sugeruję to olać, a dla nich proponuję
przegryźć się przez parę książek o inżynierii oprogramowania i teorii
obliczeń.
Daniel Mróz
>> Nie da się zrealizowac bo to nie ma specjalnie sensu *dla języków
>> dynamicznych*.
> Vide powyżej. Twoja argumentacja jest: bez sensu bo bez sensu dla jęz.
> stat. Problem jest jasno postawiony i jednoznaczny, tyle że
> nierozstrzygalny ze względu na język.
subject).
Pozdrawiam
Beorn
RobertSzefler
>>To drugie wynika z faktu, że w Pythonie rzadko kiedy da się statycznie
>>ustalić typ obiektu (jeśli się da, najlepsze pythonowe IDE potrafią
>>wylistować składowe).
>>
>>Niby pierdółki... ale *naprawdę* ma to zasadniczy wpływ na wydajność.
>
>
> to akurat zaden argument, to o czym piszesz to tylko toolsy ulatwiajace
> lekko prace. Osobiscie praktycznie nieuzywam zadnych tego typu edytorow
> (poprostu mi przeszkadza cos takiego). A pracowalem juz z produktami
> Borlanda, ktory (sam chyba przyznasz) ma najlepsze narzedzia IDE (a
> szczegolnie helpa).
BS. Najlepsze IDE, jakie dotychczas używałem, to Eclipse, dalej jest Vis
Studio, dalej IDE Borlanda. Fakt, ja osobiście preferuję joe'a, ale
pisanie, że to są toolsy *lekko ułatwiające pracę* jest grubym nadużyciem.
> Gdy pobawisz sie troche z pythonem, uzyjesz mix-ins, metaclassy itp. to
> zauwazysz roznice i potencjal pythona.
off-topic
> Ostatnio zainteresowalem sie zope3, poczytaj troche o architekturze. Z
> poczatku wydaje sie trudna (malo dokumentacji), ale nie jest tak zle.
Widziałeś Spring+Hibernate? To wyskocz teraz.
RobertSzefler
> Dnia Tue, 10 May 2005 13:37:51 +0200, RobertSzefler
> <rszefle...@murator.com.pl> napisał:
>
> [refaktoryzacja]
>
>> Czasami analiza statyczna jest konieczna, w tym sęk...
>
>
> Analiza statyczna tak, ale nie w językach dynamicznie typowanych.
Rozwala mnie Twoja logika
Grzegorz Staniak
>>>Tak więc twórcy wiodących edytorów uważają postulat (podpowiadanie jak na
>>>screenshot'cie) za słuszny!
>>
>> Podpowiadanie - tak. Ale nie *tego* co postulowałeś, bo to akurat nie ma
>> sensu dla jęz. dynamicznych.
>
> Oczywiście, że ma sens. Każdy obiekt ma typ, więc można ten typ
> wywnioskować. To, że nie można go wywnioskować w ogólności statycznie,
> wynika z tego, że system typów Pythona jest na tyle rozbudowany i
> ogólny, że problem statycznego wnioskowania o typach jest
> *nierozstrzygalny*.
Naprawdę? A gdyby tych typów było trzy na krzyż, czy to by w jakikolwiek
sposób zmieniło sytuację w przypadku języka typowanego _dynamicznie_? Choćby
biorąc przypadek tego
def costam(a):
return a
?
Innymi słowy: co ma do tego system typów akurat Pythona? To jest ogólny
problem języków typowanych dynamicznie.
Przemek Wiśniewski
Tak, masz jakas spaczona definicje.
--
Przemek Wiśniewski
RobertSzefler
>>> bo kod zawiera za malo informacji
>>
>>
>> A introspekcja ze wstydu kurczy się i pufff! - znika w obłoku logiki.
>
>
> Jedyna pewna metoda to testy.
Kompletna herezja. Testy *nigdy* nie są pewną metodą ze względu
chociażby na nierozstrzygalność problemu stopu na maszynie Turinga.
Jedyną pewną metodą jest konstrukcja języka umożliwiająca statyczne
typowanie i ścisłe wymuszanie typów.
climbus
> najwyraźniej *nie rozumieją*, sugeruję to olać, a dla nich proponuję
> przegryźć się przez parę książek o inżynierii oprogramowania i teorii
i to jest to magiczne słowo, którego niektórzy nie rozumieją:)
RobertSzefler
>
>> Takze jak porownac wielkosc kodu C++ albo Javy to Python tez "nie ma
>> szans"
>> bo jest od 5 do 15 razy mniejszy. :))
>
> Nie porównuje ilości lini tylko ilość dostępnych funkcjonalnośći.
No tu poniekąd obydwaj macie rację. Ilość linii jest b. ważna, bo
znacznie ułatwa utrzymywanie, debugowanie, rozwijanie kodu. Natomiast
funkcjonalność enterprise przy dużych projektach jest jeszcze ważniejsza
- lepsza np. bezpieczna syrenka niż ferrari z ryzykiem wybuchu silnika
10% (z góry mówię że nie mam nic do ferrari, wręcz przeciwnie, hehe)
>>> Mniejsza częstotliowść zaglądania do dokumentacji wiąze się z tym że
>>> python nie ma prawie bibliotek klasy enterprise.
>>
>> Jakies bzdury piszesz. Np. ktora biblioteka pythona nie jest "klasy
>> enterprise" i co to niby ma znaczyc? Pythonowe batteries included, czyli
>> biblioteka standardowa jest przeciez klasy enterprise, tzn. nadaje sie do
>> ciezkich, biznesowych zastosowan. Uchodzi za bardzo stabilna, potezna i
>> przejrzysta.
>
>
> Ta jasne, powiedz to Robertowi:) Z tego co sobie przypominam to w xmlrpc
> są jakieś niedoróbki, dokumentacja też nie jest wspaniała, a
> przynajmniej ja nie mogę się w niej znaleźć.
Zgłaszam się do tablicy. Ogólnie większość prostej funkcjonalności w
bibliotece std Pythona jest zrobiona dobrze, ale są jeszcze tu i tam
jakieś krzaczki. Tyle, że ta cała bibliotek to jest na prawdę *prosta*,
podstawowa funkcjonalność. Enterprise to jest właśnie Zope, Twisted,
PEAK etc etc, czyli rzeczy trochę nie bardzo doszlifowane.
>> A to ze sa inne
>> projekty mniej lub bardziej dojrzale to inna sprawa. Tak jest wszedzie
>> i w
>> kazdym jezyku.
>
>
> Ale tych dobrych w pathonie narazie jest mało w porównaniu z javą.
> Przynajmniej takich, które zostały wypróbowane w dużych korporacjach.
Otóż to.
RobertSzefler
> Dnia Wed, 11 May 2005 00:07:16 +0200, Climbus napisał(a):
>
>
>>>Takze jak porownac wielkosc kodu C++ albo Javy to Python tez "nie ma szans"
>>>bo jest od 5 do 15 razy mniejszy. :))
>>
>>Nie porównuje ilości lini tylko ilość dostępnych funkcjonalnośći.
>
>
> Licza sie tylko te funkcjonalnosci jakie potrzebujesz. Ilosc nie ma
> znaczenia. Czasem jest wrecz przeszkoda, bo nie wiadomo co wybrac.
Jeśli ilość -> 0, użyteczność wraz z nią.
Wolałbym mieć problem wyboru wśród dobrych, niż wśród kiepściutkich, na
prawdę...
>>>A to ze sa inne projekty mniej lub bardziej dojrzale to inna sprawa. Tak
>>>jest wszedzie i w kazdym jezyku.
>>
>>Ale tych dobrych w pathonie narazie jest mało w porównaniu z javą.
>>Przynajmniej takich, które zostały wypróbowane w dużych korporacjach.
>
>
> Owszem i co z tego? Python nie ma takiego wsparcia marketingowego jak Sun
> czy M$. Ale jest tez sporo duzych firm ktore korzystaja z Pythona, np.
> Google, Industrial Light and Magic, rozne organizacje rzadowe, pozarzadowe
> i wojskowe.
W guglach to parę skryptów na krzyż. IL&M to chyba do skryptowania
renderingu wykorzystują i to dobry przykład, idealne zastosowanie dla
Pythona. A org. rząd., pozarząd. to chyba kpina. Wojskowe co innego, ale
czy jesteś pewien, że oni tego używają ;) ;) ;)
RobertSzefler
regexy to standard we wszystkich językach gdzieś od końca lat 70... w
tym sensie nie jest to enterprise. Soft enterprise = helpery, frameworki
do pisania logiki biznesowej dużych, skomplikowanych aplikacji.
JZ
> Tak, masz jakas spaczona definicje.
Definicje sa kwestia umowna. Twoja jest tak samo spaczona jak kazda inna.
Od strony filozoficznej nie ma czegos takiego jak "prawdziwa" definicja
czegokolwiek. Zamiast operowac wiec takimi przymiotnikami lepiej zdefiniuj
co rozumiesz przez jakosc kodu na poziomie "enterprise"
--
JZ
RobertSzefler
> Dnia Wed, 11 May 2005 00:22:58 +0200, Climbus napisał(a):
>
>
>>Jeżeli jakiś język ma być użyteczny to potrzebuję całego kompletu:
>>biblioteka standardowa, dobre bibilioteki zewnętrzne oraz narzędzia.
>>Sama biblioteka standardowa jest prawie bezuzyteczna w poważnych
>>zastasowaniach.
>
>
> Moze wpierw zdefiniuj owe tajemnicze "powazne zastosowania" bo ja nie wiem
> o czym piszesz.
Rozbudowana aplikacja webowa, proste
>
>
>>Tak samo nawet najlepszy system operacyjny jest do kitu
>>jak nie ma dostępnego oprogramowania.
>
>
> Zle postawiony problem. Najlepszy system bez dobrego oprogramowania do
> realizacji *moich potrzeb* jest bezuzyteczny. Co mi po wielosci softu ktory
> w moim konkretnym wypadku bedzie bezuzyteczny? Poza tym moze byc nawet
> odwrotnie. Moze byc kiepski jezyk a dobre oprogramowanie. Np. PHP i
> Invision Power Board, najlepsze forum jakie znam.
>
>
>>Dlatego porównuje ogół zagadnienia.
>
>
> Nie ma czegos takiego jak ogol. Zawsze sa konkrety. Inaczej rozmywa sie
> cale twoje porownywanie, bo w praktyce zawsze masz do czynienia z
> konkretami a nie z wszystkimi mozliwymi zastosowaniami. Uwazam, ze do
> *naprawde* wiekszosci zastosowan java nie ma wcale lepszych od pythona
No nie wiem nie wiem... AspectJ, Strust, Hibernate, Spring, Eclipse...
> rozwiazan. A wiekszosc zastosowan to nie przeciez zadne ciezkie serwery
> klastrowe i przetwarzanie rozproszone.
Dlatego, że implementacje innych języków/softu enterprise są w stanie
zrobić na jednej maszynie to, do czego np. python+zope potrzebuje
klastra, hehehehe.
RobertSzefler
> Dnia 10.05.2005 Climbus <climbu...@barwa.pl> napisał/a:
>
>>>Python tylko ulatwia sam proces kodowania. Zmniejsza
>>>czestotliwosc przerywania pracy w celu wertowania nieliczonych stron
>>>dokumentacji do bibliotekl czy API. Dokumentacja do javy, he, he, he.
>>
>>Pythonowe API jest dużo słabiej udokumentowane niż Javowe. A jak
>>porównać jeszcze wielkość tych bibliotek to Python nie ma szans.
>
> Python nie ma też szans w zabijaniu farm serwerów w porównaniu z java
> ;-)
Co Ty, w KFC pracowałeś? ;)
JZ
> Każdy obiekt ma typ, więc można ten typ wywnioskować.
Tia, np. typ Object w javie :)) Mozna w javie napisac kod ktory bedzie
przyjmowal typ ogolny Object i okreslal go szczegolowo w trakcie pracy i na
tej podstawie zwracal Object ktory musi byc przerzutowany na wlasciwy typ
docelowy. Oszczedza to ilosc kodu bo pozwala pisac ta sama metode do
obslugi tych samych zadan dla parametru posiadajacego rozne typy. Natomiast
Eclipse i inne cuda tak samo rozkraczą sie w podpowiedziach do takiej
metody tak samo jak w wypadku Pythona.
--
JZ
JZ
> Tylko ciekawi mnie dlaczego to jest "Najwiekszy problem Pythona" (vide
> subject).
Wlasnie. Tytul powinien byc: najwiekszy problem javowca ktory zobaczyl po
raz pierwszy pythona. :)
--
JZ
RobertSzefler
No ja na przykład nie uważam tego za duży problem, ale mimo to chyba
jeden z większych problemów, czy raczej kontrowersji w pythonie.
RobertSzefler
> Dnia Tue, 10 May 2005 22:42:50 +0200, Jarek Zgoda napisał(a):
>
>>>A teraz dla wszystkich proponujących dir( obj ) zamieszczam screenshota:
>>>http://www.wlodarek.top100.net.pl/ObjectMembersList.png
>>>
>>>"Bajer", "pierdółka"?
>>
>>Zgłoś się do producenta Twojego IDE, że tego jeszcze nie ma. I odczep
>>się od języka. Python nie ma z tym nic wspólnego. Trollu.
>
>
> Akuraqt to co pokazal kolega na screenshocie to nic az tak rewelacyjnego.
> Wing IDE pokazuje podobne podpowiedzi. Problem lezy glebiej.
>
> Kiedys czytalem fajny artykul o tym ze generalnie programisci dziela sie na
> tych zorientowanych na jezyk i tych zorientowanych na edytor, narzedzie do
Ja jestem zorientowany na edytor, joe rules
> tworzenia kodu. Im bardziej spuchniety od tych wszystkich definicji, typow
> i innych gadow kod, tym lepszego edytora-pomagacza trzeba programiscie aby
> sie nie zgubil jak w lesie. W Delphi, C, C# czy Javie bez takiego Eclipse,
> Visual Studio czy innego Borlanda to praktycznie nie da sie pisac. Dlatego
Nie prawda! Napisałem i zdebugowałem w życiu wiele tysiący linii kodu w
C, C++ i Javie bez żadnego IDE.
> uzytkownicy takich narzedzi czuja sie zagubieni jak zobacza Pythona czy
> Rubiego, gdzie dynamika i prostota jezyka powoduje ze posiadanie dobrego
Eee... a Ruby to w ogóle język? ;)
> IDE (mimo ze pozyteczne) nie jest az tak *kluczowe*. Mozliwosci tych
> jezykow oszczedzaja znacznie wiecej czasu niz by sie to z pozoru moglo
> wydawac. Zanim taka kobyla IDE sie odpali, skompiluje i wypluje bledy ktore
No tak, jak się ma tonę nielegalnego softu na kompie, to słabo chodzi
hihihi.
> potem trzeba szukac w 15x wiekszym kodzie, to czesto szybciej w jezyku
> dynamicznym sie sprawdzi od reki w interpreterze.
Ale sam fakt, że wyłapie, jest nie do przecenienia.
> Dzis wysmarowalem w pare minut dwa skrypty pythona przetwarzajace pliki.
> Tylko raz zajrzalem do manuala odnosnie biblioteki shutil bo ktora rzadko
> uzyw. Nawet wole nie myslec ile musialbym sie meczyc aby to samo zrobic w
> Javie czy C#. Czlowiek ktory mi zlecal to zadanie nie mogl sie nadziwic co
> mi tak szybko poszlo. :))
No to właśnie nikt nie mówi, że python jest do dupy. To przykład na to,
że nie jest. Ja bym mógł jednak podać przykład dużego softu w pythonie z
kilkoma niesławnymi kawałkami kodu z zewnątrz, który nie wyszedł...
chyba wiesz, o co chodzi ;)
JZ
> A org. rząd., pozarząd. to chyba kpina. Wojskowe co innego, ale czy
> jesteś pewien, że oni tego używają ;) ;) ;)
A Zope cos ci mowi? Korzysta z niego np. NATO.
--
JZ
RobertSzefler
No tak, ale to jest błąd po stronie programisty, a nie IDE/języka. Jeśli
chcesz robić nietypowane sygnatury, to w każdym języku możesz to jakoś
wymusić (np. C: void *, standard nawet w bibl. std.) Chodzi o to, że w
Pythonie nie można zrobić w drugą stronę.
baklarz
>>>Pythonowe API jest dużo słabiej udokumentowane niż Javowe. A jak
>>>porównać jeszcze wielkość tych bibliotek to Python nie ma szans.
>>
>> Python nie ma też szans w zabijaniu farm serwerów w porównaniu z java
>> ;-)
>
> Co Ty, w KFC pracowałeś? ;)
Nie, wykłócałem się o z szefem o zakup następnych GB ramu ;-)
--
Tomasz Drobiszewski