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
_______________________________________________________ złota zasada - kto się nie zna, niech się nie wypowiada
