python-devel-tools

[wrobell]

On Sat, May 01, 2004 at 05:50:04PM +0200, Jakub Piotr C?apa wrote:
> wrobell wrote:
> >On Sat, May 01, 2004 at 04:56:01PM +0200, Jakub Piotr C?apa wrote:
> >>wrobell wrote:
> >>>On Sat, May 01, 2004 at 04:22:13PM +0200, Jakub Piotr C?apa wrote:
> >>>>
> >>>>Póki to jest standardowe zachowanie we wszystkich innych systemach to 
> >>>>raczej nie możemy nic zrobić. Wyślij maila na python-dev i zmien 
> >>>>standard. Na razie możemy naprawić to jakoś inaczej. Może w site 
> >>>>wrzucić coś co wywali "", jeśli skrypt leży w którymś z systemowych 
> >>>>katalogów na binarki?
> >>>
> >>>to, że ktoś nam robi problemy (nawet jesli nazwiesz to standardem), nie
> >>>znaczy, ze mamy sie tego kurczowo trzymac
> >>>
> >>
> >>Kurczowo nie, ale wywalenie tego zespuje wiecej niz naprawi.
> >
> >mozesz uzasadnic? bo jak na razie jest na odwrot
> >
> >ach... i jesli to jest standard, to gdzie jest on opisany i przez
> >kogo ustandaryzowany (hint: .doc word-a nie jest standardem, tu
> >cytat o nieomylnosci much)
> 
> Standardu byc nie musi - po prostu wzorcowa (i jedyna) implementacja tak 
> ma, wiele programów na tym polega (wszystkie dajace sie uruchomic bez 
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
to nie jest prawda! uzytkownik na tym polega! nie program.

> instalacji), wielu developerow z tego korzysta (choc to akurat slbszy 
> argument).

> >>Pomijac jedynie .py dla programow lezacych w %{_bindir}.
> >
> >uzytkownik moze miec skrypt w dowolnym podkatalogu $HOME. i w tym 
> >podkatalogu
> >wszystko co mu sie zywnie podoba, co moze konfliktowac z nazwami modulow
> >python-a. jakie masz w tym momencie rozwiazanie tego problemu?
> 
> To niech sie martwi sam. Jak sobie ustawi smieci w LD_PRELOAD to tez nie 

problem w tym, ze uzytkownik nic sobie tutaj sam nie ustawia. program
probuje byc madry i mu to nie wychodzi

> bedzie mu dzialalo jak trzeba. Jak wrzuci sobie ~/bin/pkg-config, 
> ~/bin/gcc albo dowolny inny plik o nazwie takiej jak standardowe 
> systemowe narzedzie, to tez nie bedzie mu dzialac.

wtedy wystarczy ustawic sobie odpowiednio PATH. nie podales
mi rozwiazania na w/w problem, hint: mozna ustawic PYTHONPATH,
ale trzeba ustawic na sciezke systemowa (/usr/{lib,share}/python2.3),
co pokazuje jak bardzo aktualne zachowanie pythona jest chore

> >>>no wlasnie. wobec tego python nie powinien importowac na podstawie
> >>>rozszerzenia .py (czym teraz nas uszczesliwia) :-P
> >>>
> >>
> >>Jest roznica - import a wykonywanie. Od wykonywania jest #!.
> >
> >import == linkowanie, sprawdz jak sie linker C zachowa,
> >albo loader jar-ow Javy, gdy biblioteka nie bedzie ELF-owa lub plik
> >.jar nie bedzie jar-em (lub zip-em). gdyby pythona zachowanie bylo
> >nieproblematyczne, nie byloby o co kruszyc kopii, ale problemow wiecej
> >niz korzysci a w dodatku zachowanie inne (przez co mniej intuicyjne)
> >niz w przypadku innych jezykow programowania
> 
> Ok. Naprawic Pythona, by nie probowal importowac czegos, co nie jest 
> pythonowym programem jak najbardziej warto.
co nie jest pythonowym _modulem_ (jak rozroznisz modul od programu, np.:
skrypt w pythonie pdb.py i modul pdb.py w sciezce systemowe?)

ciekaw jestem rozwiazania

>  Usunięcie "" z sys.path to 
> nie jest naprawianie, a brzydki hack zupelnie niekompatybilny z 
> wiekszoscia oprogramowania.
niekompatybilny z jakim oprogramowaniem?

wstawianie "" to jest brzydki workaround, ktory w dodatku psuje
importowanie modulow


    wrobell <wrobell w pld-linux.org>