🚀 go-pugleaf

On 2010-10-28 18:50, ds wrote:
> Czy jest jakiś sposób na oddzielenie plików .pyc z katalogów projektu?
> 
> Chodzi o to aby pliki .pyc tworzyły się poza drzewem aplikacji, ewentualnie 
> w jakimś podkatalogu.

Ma być w 3.2: http://www.python.org/dev/peps/pep-3147


-- 
mrg

marrgol wrote:

> 
> Ma być w 3.2: http://www.python.org/dev/peps/pep-3147
> 

Dobrze że będzie. Czyli muszę się przyzwyczaić na razie :)

Generalnie to się robi ciekawy problem - bo co się wydarzy gdy admin nie 
dopilnuje a użytkownik wepchnie np zdjęcie i quota na serwerze nie pozwoli 
na utworzenie pliku .pyc?

-- 
Pozdrawiam
ds

On 2010-10-29, ds <adres@email.pl> wrote:
> marrgol wrote:
>
>> 
>> Ma być w 3.2: http://www.python.org/dev/peps/pep-3147
>> 
>
> Dobrze że będzie. Czyli muszę się przyzwyczaić na razie :)
>
> Generalnie to się robi ciekawy problem - bo co się wydarzy gdy admin nie 
> dopilnuje a użytkownik wepchnie np zdjęcie i quota na serwerze nie pozwoli 
> na utworzenie pliku .pyc?

Wtedy python będzie kompilować skrypt przy każdym uruchomieniu.
A myślisz że jak to niby działa gdy nie masz prawa zapisu do katalogu,
w którym są moduły, jak to ma miejsce właściwie zawsze?

-- 
Secunia non olet.
Stanislaw Klekot

Stachu 'Dozzie' K. wrote:

>> Generalnie to się robi ciekawy problem - bo co się wydarzy gdy admin nie
>> dopilnuje a użytkownik wepchnie np zdjęcie i quota na serwerze nie
>> pozwoli na utworzenie pliku .pyc?
> 
> Wtedy python będzie kompilować skrypt przy każdym uruchomieniu.
> A myślisz że jak to niby działa gdy nie masz prawa zapisu do katalogu,
> w którym są moduły, jak to ma miejsce właściwie zawsze?

Fakt.

-- 
Pozdrawiam
ds

On Oct 28, 6:50 pm, ds <ad...@email.pl> wrote:
> Czy jest jakiś sposób na oddzielenie plików .pyc z katalogów projektu?
>
> Chodzi o to aby pliki .pyc tworzyły się poza drzewem aplikacji, ewentualnie
> w jakimś podkatalogu.
>
> Wcześniej mi to nie przeszkadzało ale teraz przy dużym projekcie (portal) w
> django zaczyna mi to przeszkadzać (subiektywnie - mam wrażenie bałaganu).

Jeśli chodzi o wrażenie bałaganu, to przecież np. w PyDev .pyc po
prostu nie widać.
A jeśli chcesz mieć "prawdziwy porządek" na serwerze, to twórz .egg.


Użytkownik "ds" <adres@email.pl> napisał w wiadomości 
news:iadprv$dbb$1@news.onet.pl...
> marrgol wrote:
>
>>
>> Ma być w 3.2: http://www.python.org/dev/peps/pep-3147
>>
>
> Dobrze że będzie. Czyli muszę się przyzwyczaić na razie :)
>
> Generalnie to się robi ciekawy problem - bo co się wydarzy gdy admin nie
> dopilnuje a użytkownik wepchnie np zdjęcie i quota na serwerze nie pozwoli
> na utworzenie pliku .pyc?
>

IMHO powinieneś:

1) Założyć w swoim projekcie źródłówym filtr na pliki .pyc w svn
2) Wersję instalacyjną (na serwer) robić z samych plików .pyc bez .py 

William Bonawentura wrote:

> IMHO powinieneś:
> 
> 1) Założyć w swoim projekcie źródłówym filtr na pliki .pyc w svn
> 2) Wersję instalacyjną (na serwer) robić z samych plików .pyc bez .py

1. Tak robię (używam gita, nie dokładam .pyc do repo)
2. Mógłbyś rozwinąć? Mam serwer na itl, nie pogubi się bez plików 
źródłowych?

-- 
Pozdrawiam
ds


Użytkownik "ds" <adres@email.pl> napisał w wiadomości 
news:iar2d2$iiu$1@news.onet.pl...
> William Bonawentura wrote:
>
>> IMHO powinieneś:
>>
>> 1) Założyć w swoim projekcie źródłówym filtr na pliki .pyc w svn
>> 2) Wersję instalacyjną (na serwer) robić z samych plików .pyc bez .py
>
> 1. Tak robię (używam gita, nie dokładam .pyc do repo)
> 2. Mógłbyś rozwinąć? Mam serwer na itl, nie pogubi się bez plików
> źródłowych?
>

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.

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

-- 
Pozdrawiam
ds


Użytkownik "ds" <adres@email.pl> napisał w wiadomości 
news: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. 

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.

On Nov 3, 8:42 pm, ds <ad...@email.pl> wrote:
> 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?

Da się, .pyc zachowuje nawet nazwy zmiennych i komentarze.

>Bo to też ciekawe zagadnienie - oczywiście jeśli licencja pythona
> zezwala na nieudostępnianie źródeł...

Python jest Open Source, a nie GNU.