Python rpm'y i pliki *.py *.pyc *.pyo

[wrobell]

On Tue, Sep 10, 2002 at 01:46:59PM +0200, Mateusz Korniak wrote:
> On Tuesday 10 September 2002 13:21, wrobell wrote:
> > On Tue, Sep 10, 2002 at 01:04:57PM +0200, Mateusz Korniak wrote:
> > > > A rzeczywiście. Nigdy nie wpadłem na pomysł, żeby w ten sposób to
> > > > zrobić... Tylko trzeba to nieszczęsne -O zapodać.
> > >
> > > To nie jest 'nieszczesne'. Użytkownik powinien miec świadomość kiedy chce
> > > używać -O ( co może zmienić zachowanie programu (pomijając wątpliwy efekt
> > > przyspieszenia)), a kiedy nie. Oczywiście prawidłowe (bez błędów) *.py
> > > powinny działać tak samo w obu przypadkach .. ale to może być tylo
> > > teoria.
> > >
> > > > 2. W przypadku braku .pyc i _podania_ -O oraz braku .pyo i nie podania
> > > > -O, powinien zaimportować dostępną wersję.
> > >
> > > IMHO nie powinien. (patrz wyżej)
> >
> > No to się  nie zgadzamy. To tak jakbyś  musiał jakieś chocki
> > klocki odstawiać,  żeby uruchomić programy w  C skompilowane
> > raz z -O2, a  raz z -Os, albo w przypadku Javy  bez -O lub z -O.
> >
> Ta analogia jest zła IMHO.  
> Przenosząc ją na grunt gcc, Twoje rozwiązanie pozwalałoby kompilatorowi gcc 
> wybierać/losować czy ma kompilować poszczególne pliki źródłow używając 
> -DNODEBUG albo i nie, i tak nonsensownie posklejany kod dystrybuować. 
> 
> Zauważ że jeśli gcc wygeneruje kod który działa inaczej* pod różnymi trybami 
> opytmalizacji to jest to błąd kompliatora. Natomiast gdy program dziala 
> inaczej* przy użyciu lub nie NODEBUG to na ogół jest to wina programisty.
> 
> I wola programisty C/C++ powinno być czy kod  jest kompilowany z -DNODEBUG czy 
> bez, a gcc powinno konsekwentnie podążać za wola programisty.
Mówimy o *uruchamianiu*! Nie kompilacji.

Nie możesz tego, jak to napisałeś, "przenieść na grunt gcc". Można to
odnieść np.: do funkcji exec. Wyobrażasz sobie systuację gdy dla różnych
optymalizacji musiałbyś używać funkcji execO1, execO2, itp?

Albo Java na ten przykład. Klasy Javy możesz kompilować z optymalizacją
lub bez (opcja -O). Jakkolwiek został skompilowany dany kod, to możesz
go uruchomić za pomocą wirtualnej maszyny, bez żadnych specjalnych
kombinacji.

> I teraz analogicznie, wolą programisty Pythona jest czy chce uruchamiać 
> programy z asercjami i mieć zdefiniowane __debug__ w kodzie na 1/0, czy nie  
> ( -O), a python powinien konsekwentnie podążąć za tą wolą.
> 
> Ufff, czy teraz się zgadzamy ? :)
Nie.

Programy w C kompilujemy pod daną architekturę i z optymalizacją -O2.
Programy w Pythonie, jeśli istnieje taka możliwość, też powinny być
dystrybuowane w postaci zoptymalizowanej.

> Jeśli nawet nie to i tak ma to mniejsze znaczenie (bo python działa tak ja 
> chce i sądze ze dobrze) wobec drugiego pytania. Czemu dalej dystrybuować 
> *.pyc/ *.pyo a nie tak jak mi się wydaje sensowniej *.py/ *.pyo ? 
Źródła dystrybujemy w .src.rpm.

> * działa inaczej - rozumiem generuje inne wyniki dla tych samych danych, a nie 
> zużywa inną ilość zasobów.
Nie zauważyłem, żeby .pyo generowały inne wyniki niż .pyc dla tych
samych danych.  Jakiś przykład?

    wrobell <wrobell w ite.pl>