🚀 go-pugleaf

Czesc,

> 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

Dnia Tue, 10 May 2005 22:10:49 +0200, Qertoip <qer1@o2.pl> napisał:

> 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

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

-- 
Jarek Zgoda
http://jpa.berlios.de/ | http://www.zgodowie.org/

Qertoip <qer1@o2.pl> wrote:
> 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

Dnia Tue, 10 May 2005 23:24:52 +0200, Jarek Zgoda napisał(a):

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

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

Dnia Tue, 10 May 2005 21:50:21 GMT, JZ napisał(a):

> 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

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.

> 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

JZ wrote:
> 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.

Qertoip wrote:
> Dnia Tue, 10 May 2005 23:24:52 +0200, Jarek Zgoda napisał(a):
> 
> 
>>>>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.

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

RobertSzefler napisał(a):
>> 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.
Tylko ciekawi mnie dlaczego to jest "Najwiekszy problem Pythona" (vide 
subject).


Pozdrawiam
Beorn

Tomasz Bieruta wrote:

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

... W dole szumi rzeka, w górze fruwa ptak
A RobertSzefler sobie idzie i śpiewa sobie tak:

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

-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>

> najwyraźniej *nie rozumieją*, sugeruję to olać, a dla nich proponuję 
> przegryźć się przez parę książek o inżynierii oprogramowania i teorii 
> obliczeń.                          ^^^^^^^^^^^^^^^^^^^^^^^^^ 

i to jest to magiczne słowo, którego niektórzy nie rozumieją:)

Dnia Wed, 11 May 2005 09:45:34 +0200, RobertSzefler napisał(a):

> 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

Dnia Wed, 11 May 2005 09:49:02 +0200, Daniel Mróz napisał(a):

> 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

Daniel Mróz wrote:
> RobertSzefler napisał(a):
> 
>>> 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.
> 
> Tylko ciekawi mnie dlaczego to jest "Najwiekszy problem Pythona" (vide 
> subject).

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.

Grzegorz Staniak wrote:
> ... W dole szumi rzeka, w górze fruwa ptak
> A RobertSzefler sobie idzie i śpiewa sobie tak:
> 
> 
>>>>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

Zupełnie nie rozumiem, o co Ci chodzi. Z drugiej strony fakt, że gdyby 
ilość typów była z góry ograniczona, tzn. byłby skończony ich zbiór, to 
pewnie statyczną analizę dałoby się z punktu widzenia teoretycznego 
zrobić, ale nie zastanawiałem się nad tym głębiej. Co to ma do rzeczy?

> def costam(a):
> 	return a
> 
> ?

No właśnie o to chodzi. 'a' jest nietypowane.

> Innymi słowy: co ma do tego system typów akurat Pythona? To jest ogólny
> problem języków typowanych dynamicznie.

Python jest przykładem dla problemu jęz. typowanych dynamicznie. 
Oczywiście (zapewne, bo nie wiem z pierwszej ręki) to samo jest w Ruby, 
Perlu, Smalltalku...

JZ wrote:
> Dnia Wed, 11 May 2005 09:45:34 +0200, RobertSzefler napisał(a):
> 
> 
>>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. 

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

RobertSzefler wrote:

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

Czemu nikt do tej pory typechecka nie wspomniał? Sprawdza te typy całe
bez problemu, można go podłączyć do dowolnego IDE i po krzyku.

Aha, dwie sprawy.

1. Zmienił się trochę moduł compiler, z którego korzysta typecheck.
2. Do IDE trzeba go podłączyć samemu, albo poprosić o to producenta.

Ktoś z potrzebujących ma ochotę na pracę nad tym, czy poczekacie
na gotowe?

http://cvs.sourceforge.net/viewcvs.py/python/python/nondist/sandbox/typecheck/

darek

Dnia Wed, 11 May 2005 10:22:40 +0200, RobertSzefler napisał(a):

>> 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. 
> 
> No tak, ale to jest błąd po stronie programisty, a nie IDE/języka. 

To nie jest blad programisty, bo taki kod mozna stworzyc i ma to tez jakies
uzasadnienie.
 
> Chodzi o to, że w Pythonie nie można zrobić w drugą stronę.

Jak ktos kocha typy to niech siegnie po Boo 
http://boo.codehaus.org/ albo Pyrex
http://www.cosc.canterbury.ac.nz/%7Egreg/python/Pyrex/ 

--
JZ

JZ wrote:
> Dnia Wed, 11 May 2005 10:22:40 +0200, RobertSzefler napisał(a):
> 
> 
>>>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. 
>>
>>No tak, ale to jest błąd po stronie programisty, a nie IDE/języka. 
> 
> 
> To nie jest blad programisty, bo taki kod mozna stworzyc i ma to tez jakies
> uzasadnienie.

Po to powstały systemy typów, żeby tego nie robić. Ogromna większość 
programistów uważa coś takiego za błąd ideologiczno-inżynieryjny, chyba 
przyznasz.

>>Chodzi o to, że w Pythonie nie można zrobić w drugą stronę.
> 
> 
> Jak ktos kocha typy to niech siegnie po Boo 

Boo != Python, poza tym Boo to jakiś koszmarny żart, kolejny amatorski 
projekt, pewnie umrze w fazie beta (czy czasami nie zrobili go jacyś 
niemcy, hehe?)

> http://boo.codehaus.org/ albo Pyrex
> http://www.cosc.canterbury.ac.nz/%7Egreg/python/Pyrex/ 

a co ma wspólnego pyrex z typami?

Dnia Wed, 11 May 2005 11:08:09 +0200, RobertSzefler napisał(a):

> Boo to jakiś koszmarny żart, 

A moglbys wyjasnic dlaczego?

>> http://www.cosc.canterbury.ac.nz/%7Egreg/python/Pyrex/ 
> 
> a co ma wspólnego pyrex z typami?

Zajrzyj na strone to sie dowiesz.

--
JZ

JZ wrote:
> Dnia Wed, 11 May 2005 11:08:09 +0200, RobertSzefler napisał(a):
> 
> 
>>Boo to jakiś koszmarny żart, 
> 
> 
> A moglbys wyjasnic dlaczego?

No kiedy to powstało? Rok temu? Mniej? Ja osobiście nie uważam Boo za 
pełnoprawny język, jakaś taka hybryda pythona z javą. Może jednak fakt, 
przymiotnik "koszmarny" jest tu niepotrzebny.

>>>http://www.cosc.canterbury.ac.nz/%7Egreg/python/Pyrex/ 
>>
>>a co ma wspólnego pyrex z typami?
> 
> 
> Zajrzyj na strone to sie dowiesz.

Poczytam, zobaczę. Ale pyrex z tego co wiem to helpery do pisania 
rozszerzeń pythona, więc w rdzeniu języka nic nie zmieniają.

... W dole szumi rzeka, w górze fruwa ptak
A RobertSzefler sobie idzie i śpiewa sobie tak:

>>>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
> 
> Zupełnie nie rozumiem, o co Ci chodzi. 

O to, że problem nie wynika akurat konkretnie ze specyfiki systemu typów
Pythona, tylko raczej z ogólnych cech wszystkich języków typowanych
dynamicznie. Oczywiście, o ile w ogóle zdecydujemy się nazywać "problemem"
coś, co jest po prostu własnością tej grupy języków.

[---]
>> Innymi słowy: co ma do tego system typów akurat Pythona? To jest ogólny
>> problem języków typowanych dynamicznie.
> 
> Python jest przykładem dla problemu jęz. typowanych dynamicznie. 
> Oczywiście (zapewne, bo nie wiem z pierwszej ręki) to samo jest w Ruby, 
> Perlu, Smalltalku...

Mhm. W tym momencie system typów w danym języku ma drugorzędne znaczenie.

-- 
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>

Grzegorz Staniak wrote:
> ... W dole szumi rzeka, w górze fruwa ptak
> A RobertSzefler sobie idzie i śpiewa sobie tak:
> 
> 
>>>>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
>>
>>Zupełnie nie rozumiem, o co Ci chodzi. 
> 
> 
> O to, że problem nie wynika akurat konkretnie ze specyfiki systemu typów
> Pythona, tylko raczej z ogólnych cech wszystkich języków typowanych
> dynamicznie. Oczywiście, o ile w ogóle zdecydujemy się nazywać "problemem"
> coś, co jest po prostu własnością tej grupy języków.

Problem w sensie problem obliczeniowy. Naturalne jest, że programiści 
chcieliby mieć rozwiązanie tego problemu (ja bym chciał!) ale to jest 
niemożliwe ze względu na konstrukcję systemu typów w Pythonie, która 
jest przykładem itd itd ;)

> 
> [---]
> 
>>>Innymi słowy: co ma do tego system typów akurat Pythona? To jest ogólny
>>>problem języków typowanych dynamicznie.
>>
>>Python jest przykładem dla problemu jęz. typowanych dynamicznie. 
>>Oczywiście (zapewne, bo nie wiem z pierwszej ręki) to samo jest w Ruby, 
>>Perlu, Smalltalku...
> 
> 
> Mhm. W tym momencie system typów w danym języku ma drugorzędne znaczenie.

No (nie tylko) dla mnie system typów w języku ma znaczenie podstawowe i 
dużą część sukcesu python (podobnie z resztą, jak Java) zawdzięcza jego 
dobrej strukturze.

Dnia Wed, 11 May 2005 11:40:27 +0200, RobertSzefler napisał(a):

>>>Boo to jakiś koszmarny żart, 
>> 
>> A moglbys wyjasnic dlaczego?
> 
> No kiedy to powstało? 

Bez sensu. Boo, Emerle albo IronPython to mlode jezyki *dlatego* że CLR i
cala technologia .NET jest młodą technologią. 

> Ja osobiście nie uważam Boo za pełnoprawny język, jakaś taka hybryda
> pythona z javą. 

Bez sensu. Z tego że coś ci się wydaje podobne do innego języka nie wynika
że to nie jest pełnoprawny język. A jeśli Boo do czegoś jest podobny to
raczej do Pythona i C#. Wypowiadasz bardzo pochopne zbyt radykalne opinie.
No cóż, porywczość młodzieńcza ma swoje prawa. :)

>>>a co ma wspólnego pyrex z typami?
>> 
>> Zajrzyj na strone to sie dowiesz.
> 
> Poczytam, zobaczę.

Ręce opadają...

--
JZ

JZ wrote:
> Dnia Wed, 11 May 2005 11:40:27 +0200, RobertSzefler napisał(a):
> 
> 
>>>>Boo to jakiś koszmarny żart, 
>>>
>>>A moglbys wyjasnic dlaczego?
>>
>>No kiedy to powstało? 
> 
> 
> Bez sensu. Boo, Emerle albo IronPython to mlode jezyki *dlatego* że CLR i
> cala technologia .NET jest młodą technologią. 
> 
> 
>>Ja osobiście nie uważam Boo za pełnoprawny język, jakaś taka hybryda
>>pythona z javą. 
> 
> 
> Bez sensu. Z tego że coś ci się wydaje podobne do innego języka nie wynika
> że to nie jest pełnoprawny język. A jeśli Boo do czegoś jest podobny to
> raczej do Pythona i C#. Wypowiadasz bardzo pochopne zbyt radykalne opinie.
> No cóż, porywczość młodzieńcza ma swoje prawa. :)

Nie porywczość młodzieńcza tylko gorzkie doświadczenie programisty, 
który nie jeden amatorski projekt widział...

>>>>a co ma wspólnego pyrex z typami?
>>>
>>>Zajrzyj na strone to sie dowiesz.
>>
>>Poczytam, zobaczę.
> 
> Ręce opadają...

No czemu? Kiedyś była o tym zajawka chyba na Daily Python, to luknąłem, 
ale tam nic nie było takiego, co by mnie powaliło na kolana. A na pewno 
nic, co by miało coś wspólnego z typowaniem w pythonie.

JZ wrote:

>>>>a co ma wspólnego pyrex z typami?
>>>
>>>Zajrzyj na strone to sie dowiesz.
>>
>>Poczytam, zobaczę.
> 
> 
> Ręce opadają...

No tak drastycznie bym się o pyrexie nie wyraził, ale szału nie ma ;) 
Jego funkcjonowanie sprowadza się do implementacji C(++) w pythonie, 
czyli tak na prawdę nic nie zmienia w systemie typów pythona per se, 
tylko dodaje inny, zewnętrzny system typów (z resztą, jak wiadomo, 
bardzo ograniczony). W szczególności, nie ma tam nic o żadnej kontroli 
typów pythonowskich (fakt, jakaś tam jest automagia na styku świata 
pythona i C++ - wyrzuca TypeError jak coś mu nie pasuje - ale to jakieś 
takie dziwne jest raczej). Poza tym jego składnia jest jak na razie 
biedna, no fakt, development version. Do tego sporo się zmienia w 
semantyce i tak na prawdę to jest znowu C++ w przebraniu pajtonowskiej 
składni. Takie moje zdanie.

Dnia Wed, 11 May 2005 13:09:11 +0200, RobertSzefler napisał(a):

> tak na prawdę to jest znowu C++ w przebraniu pajtonowskiej 
> składni. 

No bo jest. Pyrex sluzy do latwiejszego pisania modulow w c do pythona. :)

--
JZ

JZ wrote:
> Dnia Wed, 11 May 2005 13:09:11 +0200, RobertSzefler napisał(a):
> 
> 
>>tak na prawdę to jest znowu C++ w przebraniu pajtonowskiej 
>>składni. 
> 
> 
> No bo jest. Pyrex sluzy do latwiejszego pisania modulow w c do pythona. :)

No to w takim razie O/T

Dnia Tue, 10 May 2005 23:50:21 +0200, JZ <fake@spamerom.niet> napisał:

[...]

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

Są jeszcze granty PSF -- sprawa dopiero raczkuje, ale IMO wygląda obiecująco.

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 11 May 2005 09:45:34 +0200, RobertSzefler <rszeflerUSUNTO@murator.com.pl> napisał:

[...]

> System typów Pythona jest po prostu równoważny z pełną maszyną Turinga

Ale bardziej przypomina model von Neumanna.  Zauważyłeś, że w Pythonie
bardzo łatwo jest napisać wszystko to, co w assemblerach?  Łącznie z kodem
polimorficznym (tym z wirusów, nie z OOP) :>

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 11 May 2005 09:49:02 +0200, Daniel Mróz <beorn@alpha.pl> napisał:

[...]

> Tylko ciekawi mnie dlaczego to jest "Najwiekszy problem Pythona" (vide
> subject).

Jak już tu ktoś kiedyś napisał, największym problemem Pythona jest to,
że wszyscy go używają, tylko mało kto się do tego przyznaje :)

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 11 May 2005 10:12:34 +0200, JZ <usenet@zabiello.com> napisał:

[...]

> Wlasnie. Tytul powinien byc: najwiekszy problem javowca ktory zobaczylpo raz pierwszy pythona. :)

Pythona można zintegrować z Javą.  IMO to bardzo sensowny tandem:
Java jako core, Python do skryptów.

-- 
http://www.piotr.dembiński.prv.pl

Piotr Dembiński wrote:
> Dnia Wed, 11 May 2005 09:45:34 +0200, RobertSzefler 
> <rszeflerUSUNTO@murator.com.pl> napisał:
> 
> [...]
> 
>> System typów Pythona jest po prostu równoważny z pełną maszyną Turinga
> 
> 
> Ale bardziej przypomina model von Neumanna.  Zauważyłeś, że w Pythonie
> bardzo łatwo jest napisać wszystko to, co w assemblerach?  Łącznie z kodem
> polimorficznym (tym z wirusów, nie z OOP) :>

True. Jednak 'domyślnie' działa jak standardowo zaimplementowana maszyna 
Turinga. To jednak dyskusja na temat wyższości świąt jednych nad innymi 
;) Chodziło mi o to, że ma pełny model obliczeń, w związku z tym nie 
można wnioskować statycznie.

Dnia Wed, 11 May 2005 14:28:32 +0200, Piotr Dembiński napisał(a):

> Pythona można zintegrować z Javą.  IMO to bardzo sensowny tandem:
> Java jako core, Python do skryptów.

Przeciez juz jest jython.

--
JZ

Dnia Wed, 11 May 2005 09:47:59 +0200, RobertSzefler <rszeflerUSUNTO@murator.com.pl> napisał:

[...]

> Straszny jest brak zrozumienia wśród pythonowców dla Twojego
> problemu/postulatów.

Wszystko przez tę intuicyjność składni.  Gdyby Pythona trzeba się było
uczyć zaczynając od wykucia na blachę stu słów kluczowych, byłoby
pewnie inaczej :)

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

Wbrew pozorom (open source, grupy dyskusyjne itepe), Python został
zaprojektowany przez profesjonalistę, a jego poprzednik (jezyk ABC) --
przez zespół profesjonalistów z duńskiego Narodowego Instytutu
Badań nad Matematyką i Informatyką.

> Jeśli inni pythonowcy tego nie rozumieją, bo najwyraźniej *nie rozumieją*,sugeruję to olać, a dla nich proponuję przegryźć się przez parę książeko inżynierii oprogramowania i teorii obliczeń.

Tak swoją drogą to wiele spośród obecnych technik inżynierii oprogramowania
ma swoje źródła w językach takich jak Python.  Przykładowo, Python właściwie
zmusza programistę do pisania automatycznych testów jednostkowych, a to jest
zbieżne z TDD.  Brak kompilatora wyłapującego najprostsze błędy to czasami
dobra rzecz :)

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 11 May 2005 10:00:37 +0200, climbus <jkulesza@murator.com.pl> napisał:

>
>> najwyraźniej *nie rozumieją*, sugeruję to olać, a dla nich proponuję
>> przegryźć się przez parę książek o inżynierii oprogramowania i teorii
>> obliczeń.                          ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> i to jest to magiczne słowo, którego niektórzy nie rozumieją:)

Pewnie dlatego, że większości programistów i.o. kojarzy się ze stosami
papierowych dokumentów i cotygodniowymi raportami z postępu prac.

-- 
http://www.piotr.dembiński.prv.pl

> ma swoje źródła w językach takich jak Python.  Przykładowo, Python 
> właściwie
> zmusza programistę do pisania automatycznych testów jednostkowych, a to 
> jest
> zbieżne z TDD.

Z tym zmuszaniem to byłbym ostrozny. Ilu programistów Pythona pisze 
testy? obawiam się że niewiele, niestety

Zazwyczaj jest podejście takie, że python jest językiem intuicyjnym i te 
bzdury w postaci projektowania i testów są zbędne. Po co tracić na to 
czas? trzeba odrazu kodować, kodować ... :)

> Pythona można zintegrować z Javą.  IMO to bardzo sensowny tandem:
> Java jako core, Python do skryptów.

I to jest to. Przyszłość programowania.
Myślałem o Pythonie jako języku do modelowania aplikacji. Szybko napisać 
model w pytonie zobaczyc czy o to chodzi a później to przewalić na javę. 
Można też pisac testy w pythonie.

Dnia Tue, 10 May 2005 23:35:23 +0200, Adam Przybyla <adam@gliwice.pl> napisał:

[...]

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

[pycompleter]

Jest Interactive Python: http://ipython.scipy.org.

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 11 May 2005 09:51:20 +0200, RobertSzefler <rszeflerUSUNTO@murator.com.pl> napisał:

[...]

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

Jeśli chodzi o bazy danych, to ja się nastawiam na zapoznanie z db4o.
Szkoda tylko, że nie ma wersji dla Pythona.

-- 
http://www.piotr.dembiński.prv.pl

Witam,

Ciesze sie, ze ozywiles grupe :-) dawno nie dzialo sie tutaj tyle, hehe. 
Szerze to nawet nie wiem juz na jaki temat jest dyskusja, bo rozproszylo sie 
to dosc znacznie, ale co tam. Ja w kazdym razie nie mam wyboru, moj szef 
kazal mi pisac w pythonie i koniec, nie ma dyskusji - strategia firmy. Gdy 
zaczynalem (wczesnie bylo delphi, java, perl, itp.), wydawalo mi sie to 
straszne, jednak bardzo szybko zauwazylem ciekawostki (nowe mozliwosci 
programowania objektowego), ktorych nie mialem w j. kompilowanych.

Pozdrawiam
Tomek

Dnia Wed, 11 May 2005 20:01:04 +0200, Tomasz Bieruta <bieruta@gmx.net> napisał:

> Witam,
>
> Ciesze sie, ze ozywiles grupe :-) dawno nie dzialo sie tutaj tyle, hehe.
> Szerze to nawet nie wiem juz na jaki temat jest dyskusja, bo rozproszylo sie
> to dosc znacznie, ale co tam.

Wady Pythona -> narzędzia, które te wady mogą uczynić mniej uciążliwymi.
No i kilka podwątków o możliwościach Pythona.  IMO wszystko się w tym wątku
trzyma kupy :)

> Ja w kazdym razie nie mam wyboru, moj szef kazal mi pisac w pythoniei koniec, nie ma dyskusji - strategia firmy. Gdy zaczynalem (wczesniebylo delphi, java, perl, itp.), wydawalo mi sie to straszne, jednakbardzo szybko zauwazylem ciekawostki (nowe mozliwosci programowaniaobjektowego), ktorych nie mialem w j. kompilowanych.

Z ciekawości: gdzie pracują szefowie, którzy każą programować w Pythonie?

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 11 May 2005 20:25:11 +0200, Tomasz Bieruta <bieruta@gmx.net> napisał:

[...]

>> Z ciekawo¶ci: gdzie pracuj± szefowie, którzy ka¿± programowaæ w Pythonie?
>
> a co szukasz pracy :-) ?

Zbieram informacje :)

-- 
http://www.piotr.dembiński.prv.pl

Czesc,

>> Szerze to nawet nie wiem juz na jaki temat jest dyskusja, bo rozproszylo 
>> sie
>> to dosc znacznie, ale co tam.
>
> Wady Pythona -> narzędzia, które te wady mogą uczynić mniej uciążliwymi.
> No i kilka podwątków o możliwościach Pythona.  IMO wszystko się w tym 
> wątku
> trzyma kupy :)

a dzieki.


> Z ciekawości: gdzie pracują szefowie, którzy każą programować w Pythonie?

a co szukasz pracy :-) ?

Pozdrawiam
Tomek

Jarek Zgoda <jzgoda@gazeta.usun.pl> wrote in
news:d5r949$e13$1@nemesis.news.tpi.pl: 

> Qertoip napisał(a):
> 
>>>Chyba jesteś zwykłym trollem. 
>> 
>> Powtarzam, licz się ze słowami.
> 
> Nie, nie "chyba". Na 100% jesteś trollem. Sio.

Jarek, pomimo że zwykle prowadzisz merytoryczne dyskusje, to widzę że się 
okopałeś na z góry upatrzonych pozycjach i próbujesz personalnymi 
uszczypliwościami odpędzić "wroga". Przestań! Piotr wcale nie jest żadnym 
trolem. On po prostu na razie maca python, maca żeby się przytulić :)


-- 
Pozdrawiam,
Piotr Kuć 
mailto:kociak@kociak.prv.pl.TYLKO-ZAMIEN-OBA-kociak-NA-kuciak.INVALID

w <news:d5sdd4$l7p$1@news.supermedia.pl>
Daniel Mróz napisał(a):

>> 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. 
> Tylko ciekawi mnie dlaczego to jest "Najwiekszy problem Pythona"
> (vide subject).

Bo autor zapewne uwaza ze python niema innych problemow.;-)
Pozdrawiam

Dnia Fri, 13 May 2005 03:07:33 +0200, turbos10 <adres@antyspamowy.pl> napisał:

> w <news:d5sdd4$l7p$1@news.supermedia.pl>
> Daniel Mróz napisał(a):
>
>>> 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.
>> Tylko ciekawi mnie dlaczego to jest "Najwiekszy problem Pythona"
>> (vide subject).
>
> Bo autor zapewne uwaza ze python niema innych problemow.;-)

Python ma kilk problemów, wynikających z tego, że sam język nie został
nigdy porządnie zdefiniowany[1], tylko rozwija się żywiołowo.

Przykładowo w Pythonach 2.2 w górę:

   1.__add__(1)

zgłasza błąd, ale:

   1 . __add__(1)

wykonuje się poprawnie (white space matters :> )

Z innych quirks'ów:

   1,

tworzy jednoelementową krotkę (tuple).

Problemem w Pythonie jest intuicyjność języka: jeśli ktoś chce pisać
w nim programy, to podstawowe konstrukcje może opanować bardzo szybko.
Jednak pisząc (nawet proste) programy w Pythonie można się natknąć
na właśnie takie 'dziwne' konstrukcje.


[1]  Najdokładniejszą dokumentacją Pythona jest kod źródłowy CPythona.
      W 'Reference' kilku rzeczy po prostu nie ma.

-- 
http://www.piotr.dembiński.prv.pl