On Sat, May 01, 2004 at 05:50:04PM +0200, Jakub Piotr C?apa wrote: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ć?
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
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
_______________________________________________________ złota zasada - kto się nie zna, niech się nie wypowiada
