python-devel-tools

[Jakub Piotr Cłapa]

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

>>>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. Usunięcie "" z sys.path to 
nie jest naprawianie, a brzydki hack zupelnie niekompatybilny z 
wiekszoscia oprogramowania.

-- 
z wyrazami szacunku,
Jakub Piotr Cłapa