🚀 go-pugleaf

On Nov 4, 7:40 am, "William Bonawentura" <n...@ipartners.pl> wrote:
> Użytkownik "ds" <ad...@email.pl> napisał w wiadomościnews:iasdub$di1$1@news.onet.pl...
>
> > William Bonawentura wrote:
>
> >> Z tego co wiem pliki .pyc są przenośne - tak jak i .class w Javie.
> >> Problemem może być tylko różnica wersji Pythona, ale chyba tworząc
> >> aplikację w 2.6 masz i na serwerze 2.6.
>
> > Sprawdziłem, są przenośne. A jest coś takiego jak reverse engineering dla
> > .pyc? Bo to też ciekawe zagadnienie - oczywiście jeśli licencja pythona
> > zezwala na nieudostępnianie źródeł...
>
> Licencja Pythona jest niezaraźliwa. Ideą "pyc" (i pyo) jest właśnie
> udostępnianie wersji instalacyjnej bez źródeł. Jest to tylko kompilacja do
> bytekodu (zastąpienie słów kluczowych chunkami) więc dekompilacja w pełni
> zdradza algorytm oraz nazwy.

Nie to nie jest idea .pyc! Te pliki nie mają być przenośne - są
specyficzne dla wersji Pythona czy architektury systemu (np. 64bit vs
32bit), a porównywanie ich z .class to duże nadużycie. Jedynym celem
tych plików jest przyśpieszenie wczytywania się programów, tak żeby
nie trzeba było parsować wielkich bibliotek za każdym razem. PEP 3147
nie służy upiększeniu sposoby ich przetrzymywania, lecz rozwiązuję
realny problem trzymania plików .pyc dla różnych wersji Pythona z
jedną kopią źródeł - Ubuntu aktualnie robi X symlinków, aby to
osiągnąć.

Wrzucanie aplikacji na serwer w postaci samych .pyc to zbędna
komplikacja. Wielkość kodu to naprawdę ostatnia rzecz, która powinna
cię martwić w aplikacji.