python-devel-tools

Jakub Piotr Cłapa loc w toya.net.pl
Sob, 1 Maj 2004, 19:43:42 CEST


wrobell wrote:
> 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
> 
A jak odrozniasz program gcc od skryptu gcc - oba sa w sciezce 
systemowej. Nie rozrozniasz - po prostu nie robisz czegos takiego. 
Python nie wymaga rozroznienia na skrypty i biblioteki, więc po co je robić?

Rozwiązania widzę dwa:
- programy pythonowe w bin czynimy symlinkami do bibliotek (tak jak 
sugerował Jajcuś)
- w globalnych ustawieniach (cos takiego jak site chyba sie nada, nie?) 
wywalamy "" z sys.path, jeśli skrypt rezyduje w systemowym bindir

Nie mozemy po prostu wywalić "" z sys.path, bo cały świat ma inaczej. 
Rule of Least Surprise. Jesli juz to musimy zrobić tak, żeby wywalało 
się z hukiem (czyli na pewno nie zamiana kolejności sys.path) i by było 
wiadomo od razu o co chodzi. Rule of Repair.

Tak czy siak sprawa jest warta obgadania z developerami Pythona.

-- 
z wyrazami szacunku,
Jakub Piotr Cłapa



Więcej informacji o liście dyskusyjnej pld-devel-pl