On Tuesday, January 20, 2015 at 2:00:18 PM UTC+1, Wojciech Muła wrote:
> On Monday, January 19, 2015 at 2:51:09 PM UTC+1, M.M. wrote:
> > > Żeby programiści pythona łatwo się wdrożyli. :)
> >
> > A tak poważnie, rozpoznawanie instrukcji blokowej (czy jak to się
> > zwie w Pythonie) po samych wcięciach, nie jest wystarczająco
> > upierdliwe, żeby tę składnie porzucić? W meta-kodzie zgadzam się
> > że tak jest czytelniej, ale tak? To się nie miesza w oczach?
>
> Mnie to nie przeszkadza, kwestia gustu.
Może na dłuższą metę też bym się przyzwyczaił, na razie
nie lubię.


> Chociaż dla długich bloków i dużej liczby wcięć przestaje być
> czytelnie - ale wtedy i tak znaczy, że coś jest nie tak z kodem,
> niezależnie od języka.
Niby w 'językach klamerkowych' też się robi wcięcia. Jednak jak coś
się w pośpiechu zepsuje, to ostatecznie decydują klamerki. Czy coś
z kodem jest nie tak? Niekoniecznie. Rozbijanie na małe funkcje
dużego, ale prostego kodu, pisanego na szybko, często do
jednokrotnego użycia, moim zdaniem to strata czasu. W takich
sytuacjach ta klamerka jakoś dodaje mi pewności siebie.

Pozdrawiam

do góry

W dniu wtorek, 20 stycznia 2015 15:36:05 UTC+1 użytkownik M.M. napisał:
> On Tuesday, January 20, 2015 at 2:00:18 PM UTC+1, Wojciech Muła wrote:
> > On Monday, January 19, 2015 at 2:51:09 PM UTC+1, M.M. wrote:
> > > > Żeby programiści pythona łatwo się wdrożyli. :)
> > >
> > > A tak poważnie, rozpoznawanie instrukcji blokowej (czy jak to się
> > > zwie w Pythonie) po samych wcięciach, nie jest wystarczająco
> > > upierdliwe, żeby tę składnie porzucić? W meta-kodzie zgadzam się
> > > że tak jest czytelniej, ale tak? To się nie miesza w oczach?
> >
> > Mnie to nie przeszkadza, kwestia gustu.
> Może na dłuższą metę też bym się przyzwyczaił, na razie
> nie lubię.
>
>
> > Chociaż dla długich bloków i dużej liczby wcięć przestaje być
> > czytelnie - ale wtedy i tak znaczy, że coś jest nie tak z kodem,
> > niezależnie od języka.
> Niby w 'językach klamerkowych' też się robi wcięcia. Jednak jak coś
> się w pośpiechu zepsuje, to ostatecznie decydują klamerki. Czy coś
> z kodem jest nie tak? Niekoniecznie. Rozbijanie na małe funkcje
> dużego, ale prostego kodu, pisanego na szybko, często do
> jednokrotnego użycia, moim zdaniem to strata czasu. W takich
> sytuacjach ta klamerka jakoś dodaje mi pewności siebie.
>
da mnie (mimo ze jestem srednio zaawansowanym z grubsza programista) klamerki bywają
ciegle od czasu do czasu przyczyną błedów (kompilacji)

dluzsze bloki tez mi sie zdarzają,
(zarowno dluzsze i takie z nawet
3-ma 4-rema 9ale 4 raczej max wiecej chyba nie ma) zagniezdzeniami klamer)
chyba dletego ze jak sie optymalizuje
kod to wole miec wiekszy kawalek w jednym miejscu i tez czesta wylaczam
bloki kodu przez if(0) co daje dodatkowe klamry - klamry nie sa wtedy wygodne;
ostatnio rozwalazlem wersje c bez klamer, gdzie blok sie konczy srednikiem ; czy
czyms takim - moze to by lepiej dzialalo...

trzebby wogole opracowac jakis nowy pomysl, bo od gadania z roznymi debilami z
zagranicy czuje ze oslabla
mi głowa, trzeba by sobie udowodnic ze stary fir costam jeszcze umie (fir stary
(ostatnio czuje sie polamany jak
emeryt z deuchlandu) i bez formy a robota nawet nie zaczeta, nie jest dobrze)

do góry

On Tuesday, January 20, 2015 at 4:05:29 PM UTC+1, firr wrote:
> W dniu wtorek, 20 stycznia 2015 15:36:05 UTC+1 użytkownik M.M. napisał:
> > On Tuesday, January 20, 2015 at 2:00:18 PM UTC+1, Wojciech Muła wrote:
> > > On Monday, January 19, 2015 at 2:51:09 PM UTC+1, M.M. wrote:
> > > > > Żeby programiści pythona łatwo się wdrożyli. :)
> > > >
> > > > A tak poważnie, rozpoznawanie instrukcji blokowej (czy jak to się
> > > > zwie w Pythonie) po samych wcięciach, nie jest wystarczająco
> > > > upierdliwe, żeby tę składnie porzucić? W meta-kodzie zgadzam się
> > > > że tak jest czytelniej, ale tak? To się nie miesza w oczach?
> > >
> > > Mnie to nie przeszkadza, kwestia gustu.
> > Może na dłuższą metę też bym się przyzwyczaił, na razie
> > nie lubię.
> >
> >
> > > Chociaż dla długich bloków i dużej liczby wcięć przestaje być
> > > czytelnie - ale wtedy i tak znaczy, że coś jest nie tak z kodem,
> > > niezależnie od języka.
> > Niby w 'językach klamerkowych' też się robi wcięcia. Jednak jak coś
> > się w pośpiechu zepsuje, to ostatecznie decydują klamerki. Czy coś
> > z kodem jest nie tak? Niekoniecznie. Rozbijanie na małe funkcje
> > dużego, ale prostego kodu, pisanego na szybko, często do
> > jednokrotnego użycia, moim zdaniem to strata czasu. W takich
> > sytuacjach ta klamerka jakoś dodaje mi pewności siebie.
> >
> da mnie (mimo ze jestem srednio zaawansowanym z grubsza programista) klamerki
bywają ciegle od czasu do czasu przyczyną błedów (kompilacji)
>
> dluzsze bloki tez mi sie zdarzają,
> (zarowno dluzsze i takie z nawet
> 3-ma 4-rema 9ale 4 raczej max wiecej chyba nie ma) zagniezdzeniami klamer)
> chyba dletego ze jak sie optymalizuje
> kod to wole miec wiekszy kawalek w jednym miejscu i tez czesta wylaczam
> bloki kodu przez if(0) co daje dodatkowe klamry - klamry nie sa wtedy wygodne;
ostatnio rozwalazlem wersje c bez klamer, gdzie blok sie konczy srednikiem ; czy
czyms takim - moze to by lepiej dzialalo...
Hmmmm to mamy odwrotne doświadczenia. Ja taki kod produkuję w innych
sytuacjach niż podczas optymalizacji. Produkuję np. gdy nie wierzę że
w przyszlości da się łatwo wykorzystać, gdy np. wolę cały moduł wywalić i
napisać na nowo. Albo gdy program ma być uruchomiony doslownie jeden raz.
Wtedy mam procedury po 200 linijek. No i też wtedy klamerki ratują mi
życie, a przynajmniej tak mi się wydaje.
Pozdrawiam

do góry

On Tuesday, January 20, 2015 at 2:45:37 PM UTC+1, M.M. wrote:
> > W pythonie jest bibliotek od cholery, mała szansa, że czegoś nie ma.
> > Poza tym python ma podobną wydajność, jak ruby, czy perl. Javascript
> > na v8 jest szybszy, ale js to słaby język i szkoda na niego czasu.
>
> Mnie się niedawno zamieliły na dysku 3 wersje programu. Prosta
> aplikacja, ale duże xml trzeba do bazy sql przerzucić.
> Gdy schodziłem na coraz niższy poziom, to w 3ciej wersji miałem
> xmle wrzucone do struktury mniej/więcej takiej:
> struct Tag {
> QString name;
> QString tag;
> }
> QVector< QVector< Tag > > xml;
>
> I takie rozwiązanie też nie daje rady. Żałuję że od razu nie
> skroiłem aplikacji na miarę. Nauczkę tego typu mam już któryś
> raz w życiu, ale zawsze jest pokusa żeby użyć czegoś wysokopoziomowego,
> choćby w stringu trzymać inty, aby nie rzeźbić N struktur danych.

Trudno ocenić złożoność problemu bez znajomości struktury XML-i,
rozmiaru danych itd. Do pythona są wrappery na popularne biblioteki
do XML, które są pisane w C, więc tam narzutu pamięciowego nie
ma wiele. Jak robiłeś listy list obiektów na poziomie pythona,
to rzeczywiście mógł zeżreć dużo pamięci.

W mojej poprzedniej pracy mieliśmy skrypt w phpie, który coś wrzucał
do bazy danych. Działał dobrze przez długi czas, aż któregoś dnia przestał.
Okazało się, że na skutek zwiększenia ilości wrzucanych danych zżerał
całą pamięć serwera, czyli kilka GB, i malowniczo zdychał. Po moich
drobnych usprawnieniach w najgorszym momencie zużywał kilkaset MB.

BTW w Pythonie można ograniczyć rozmiar własnych obiektów używając
__slots__, tu dość spektakularny przykład:
http://tech.oyster.com/save-ram-with-python-slots/

w.

do góry

On Tuesday, January 20, 2015 at 3:36:05 PM UTC+1, M.M. wrote:
> > Mnie to nie przeszkadza, kwestia gustu.
> Może na dłuższą metę też bym się przyzwyczaił, na razie
> nie lubię.

Wydaje mi się, że to właśnie kwestia przyzwyczajenia. Trochę inaczej
się wtedy patrzy na kod.

> > Chociaż dla długich bloków i dużej liczby wcięć przestaje być
> > czytelnie - ale wtedy i tak znaczy, że coś jest nie tak z kodem,
> > niezależnie od języka.
> Niby w 'językach klamerkowych' też się robi wcięcia. Jednak jak coś
> się w pośpiechu zepsuje, to ostatecznie decydują klamerki. Czy coś
> z kodem jest nie tak? Niekoniecznie. Rozbijanie na małe funkcje
> dużego, ale prostego kodu, pisanego na szybko, często do
> jednokrotnego użycia, moim zdaniem to strata czasu. W takich
> sytuacjach ta klamerka jakoś dodaje mi pewności siebie.

Ale wiesz, że prowizorka jest najtrwalsza? :) Jasne, w językach
klamerkowych to wyznaczają bloki i wtedy możesz pisać jak chcesz.
Np. w C i C++ nie podoba mi się, że można pominąć klamerki, co
może powodować niefajne błędy, jak np. heartbleed w openSSLu.

w.

do góry

W dniu wtorek, 20 stycznia 2015 17:59:22 UTC+1 użytkownik M.M. napisał:
> On Tuesday, January 20, 2015 at 4:05:29 PM UTC+1, firr wrote:
> > W dniu wtorek, 20 stycznia 2015 15:36:05 UTC+1 użytkownik M.M. napisał:
> > > On Tuesday, January 20, 2015 at 2:00:18 PM UTC+1, Wojciech Muła wrote:
> > > > On Monday, January 19, 2015 at 2:51:09 PM UTC+1, M.M. wrote:
> > > > > > Żeby programiści pythona łatwo się wdrożyli. :)
> > > > >
> > > > > A tak poważnie, rozpoznawanie instrukcji blokowej (czy jak to się
> > > > > zwie w Pythonie) po samych wcięciach, nie jest wystarczająco
> > > > > upierdliwe, żeby tę składnie porzucić? W meta-kodzie zgadzam się
> > > > > że tak jest czytelniej, ale tak? To się nie miesza w oczach?
> > > >
> > > > Mnie to nie przeszkadza, kwestia gustu.
> > > Może na dłuższą metę też bym się przyzwyczaił, na razie
> > > nie lubię.
> > >
> > >
> > > > Chociaż dla długich bloków i dużej liczby wcięć przestaje być
> > > > czytelnie - ale wtedy i tak znaczy, że coś jest nie tak z kodem,
> > > > niezależnie od języka.
> > > Niby w 'językach klamerkowych' też się robi wcięcia. Jednak jak coś
> > > się w pośpiechu zepsuje, to ostatecznie decydują klamerki. Czy coś
> > > z kodem jest nie tak? Niekoniecznie. Rozbijanie na małe funkcje
> > > dużego, ale prostego kodu, pisanego na szybko, często do
> > > jednokrotnego użycia, moim zdaniem to strata czasu. W takich
> > > sytuacjach ta klamerka jakoś dodaje mi pewności siebie.
> > >
> > da mnie (mimo ze jestem srednio zaawansowanym z grubsza programista) klamerki
bywają ciegle od czasu do czasu przyczyną błedów (kompilacji)
> >
> > dluzsze bloki tez mi sie zdarzają,
> > (zarowno dluzsze i takie z nawet
> > 3-ma 4-rema 9ale 4 raczej max wiecej chyba nie ma) zagniezdzeniami klamer)
> > chyba dletego ze jak sie optymalizuje
> > kod to wole miec wiekszy kawalek w jednym miejscu i tez czesta wylaczam
> > bloki kodu przez if(0) co daje dodatkowe klamry - klamry nie sa wtedy wygodne;
ostatnio rozwalazlem wersje c bez klamer, gdzie blok sie konczy srednikiem ; czy
czyms takim - moze to by lepiej dzialalo...
> Hmmmm to mamy odwrotne doświadczenia. Ja taki kod produkuję w innych
> sytuacjach niż podczas optymalizacji. Produkuję np. gdy nie wierzę że
> w przyszlości da się łatwo wykorzystać, gdy np. wolę cały moduł wywalić i
> napisać na nowo. Albo gdy program ma być uruchomiony doslownie jeden raz.
> Wtedy mam procedury po 200 linijek. No i też wtedy klamerki ratują mi
> życie, a przynajmniej tak mi się wydaje.


ja raczej nie mam sklonnosci do dlugich funkcji, moj naturalny 'styl' to takie
10-centymetrowki, 20-stki
30-stki (gdzies tak pewnie do 70-tek
ale wiecej chyba krotkich)

200 linijek to nie sa jeszcze jakos specjalnie dlugie, to pewnie gdzies tak ze 4
ekrany (w malej czcionce) czyli nie tak duzo

do góry

On Tuesday, January 20, 2015 at 6:38:16 PM UTC+1, firr wrote:
> W dniu wtorek, 20 stycznia 2015 17:59:22 UTC+1 użytkownik M.M. napisał:
> > On Tuesday, January 20, 2015 at 4:05:29 PM UTC+1, firr wrote:
> > > W dniu wtorek, 20 stycznia 2015 15:36:05 UTC+1 użytkownik M.M. napisał:
> > > > On Tuesday, January 20, 2015 at 2:00:18 PM UTC+1, Wojciech Muła wrote:
> > > > > On Monday, January 19, 2015 at 2:51:09 PM UTC+1, M.M. wrote:
> > > > > > > Żeby programiści pythona łatwo się wdrożyli. :)
> > > > > >
> > > > > > A tak poważnie, rozpoznawanie instrukcji blokowej (czy jak to się
> > > > > > zwie w Pythonie) po samych wcięciach, nie jest wystarczająco
> > > > > > upierdliwe, żeby tę składnie porzucić? W meta-kodzie zgadzam się
> > > > > > że tak jest czytelniej, ale tak? To się nie miesza w oczach?
> > > > >
> > > > > Mnie to nie przeszkadza, kwestia gustu.
> > > > Może na dłuższą metę też bym się przyzwyczaił, na razie
> > > > nie lubię.
> > > >
> > > >
> > > > > Chociaż dla długich bloków i dużej liczby wcięć przestaje być
> > > > > czytelnie - ale wtedy i tak znaczy, że coś jest nie tak z kodem,
> > > > > niezależnie od języka.
> > > > Niby w 'językach klamerkowych' też się robi wcięcia. Jednak jak coś
> > > > się w pośpiechu zepsuje, to ostatecznie decydują klamerki. Czy coś
> > > > z kodem jest nie tak? Niekoniecznie. Rozbijanie na małe funkcje
> > > > dużego, ale prostego kodu, pisanego na szybko, często do
> > > > jednokrotnego użycia, moim zdaniem to strata czasu. W takich
> > > > sytuacjach ta klamerka jakoś dodaje mi pewności siebie.
> > > >
> > > da mnie (mimo ze jestem srednio zaawansowanym z grubsza programista) klamerki
bywają ciegle od czasu do czasu przyczyną błedów (kompilacji)
> > >
> > > dluzsze bloki tez mi sie zdarzają,
> > > (zarowno dluzsze i takie z nawet
> > > 3-ma 4-rema 9ale 4 raczej max wiecej chyba nie ma) zagniezdzeniami klamer)
> > > chyba dletego ze jak sie optymalizuje
> > > kod to wole miec wiekszy kawalek w jednym miejscu i tez czesta wylaczam
> > > bloki kodu przez if(0) co daje dodatkowe klamry - klamry nie sa wtedy wygodne;
ostatnio rozwalazlem wersje c bez klamer, gdzie blok sie konczy srednikiem ; czy
czyms takim - moze to by lepiej dzialalo...
> > Hmmmm to mamy odwrotne doświadczenia. Ja taki kod produkuję w innych
> > sytuacjach niż podczas optymalizacji. Produkuję np. gdy nie wierzę że
> > w przyszlości da się łatwo wykorzystać, gdy np. wolę cały moduł wywalić i
> > napisać na nowo. Albo gdy program ma być uruchomiony doslownie jeden raz.
> > Wtedy mam procedury po 200 linijek. No i też wtedy klamerki ratują mi
> > życie, a przynajmniej tak mi się wydaje.
>
>
> ja raczej nie mam sklonnosci do dlugich funkcji, moj naturalny 'styl' to takie
10-centymetrowki, 20-stki
> 30-stki (gdzies tak pewnie do 70-tek
> ale wiecej chyba krotkich)
>
> 200 linijek to nie sa jeszcze jakos specjalnie dlugie, to pewnie gdzies tak ze 4
ekrany (w malej czcionce) czyli nie tak duzo

W normalnym kodzie, o którym wiem, że będę go pielęgnował przez
długi czas, to 20 linijek na procedurę wydaje mi się dużo, no
powiedzmy, że 20 linijek to dopuszczalny max.

Pozdrawiam

do góry

On Mon, 19 Jan 2015 05:51:08 -0800 (PST), "M.M." <m...@g...com>
wrote:
> A tak poważnie, rozpoznawanie instrukcji blokowej (czy jak to się
> zwie w Pythonie) po samych wcięciach, nie jest wystarczająco
> upierdliwe, żeby tę składnie porzucić? W meta-kodzie zgadzam się
> że tak jest czytelniej, ale tak? To się nie miesza w oczach?

Mi się nie miesza, ale to zależy od tego ile kto razy zagnieżdża.

RW

do góry

On Mon, 19 Jan 2015 08:49:56 +0100, "AK" <n...@n...com> wrote:
> W sprawie Cythona slawek ma 100% racji.
> Pomieszanie z poplataniem (wlacznie z delikatnie mowiac "falujaca"
miedzy
> (sub)wersjami stabilnoscia, a nawet kompilowalnoscia).

Ale przyspieszenie kodu bywa spore.

RW

do góry

W dniu wtorek, 20 stycznia 2015 18:38:16 UTC+1 użytkownik firr napisał:
> W dniu wtorek, 20 stycznia 2015 17:59:22 UTC+1 użytkownik M.M. napisał:
> > On Tuesday, January 20, 2015 at 4:05:29 PM UTC+1, firr wrote:
> > > W dniu wtorek, 20 stycznia 2015 15:36:05 UTC+1 użytkownik M.M. napisał:
> > > > On Tuesday, January 20, 2015 at 2:00:18 PM UTC+1, Wojciech Muła wrote:
> > > > > On Monday, January 19, 2015 at 2:51:09 PM UTC+1, M.M. wrote:
> > > > > > > Żeby programiści pythona łatwo się wdrożyli. :)
> > > > > >
> > > > > > A tak poważnie, rozpoznawanie instrukcji blokowej (czy jak to się
> > > > > > zwie w Pythonie) po samych wcięciach, nie jest wystarczająco
> > > > > > upierdliwe, żeby tę składnie porzucić? W meta-kodzie zgadzam się
> > > > > > że tak jest czytelniej, ale tak? To się nie miesza w oczach?
> > > > >
> > > > > Mnie to nie przeszkadza, kwestia gustu.
> > > > Może na dłuższą metę też bym się przyzwyczaił, na razie
> > > > nie lubię.
> > > >
> > > >
> > > > > Chociaż dla długich bloków i dużej liczby wcięć przestaje być
> > > > > czytelnie - ale wtedy i tak znaczy, że coś jest nie tak z kodem,
> > > > > niezależnie od języka.
> > > > Niby w 'językach klamerkowych' też się robi wcięcia. Jednak jak coś
> > > > się w pośpiechu zepsuje, to ostatecznie decydują klamerki. Czy coś
> > > > z kodem jest nie tak? Niekoniecznie. Rozbijanie na małe funkcje
> > > > dużego, ale prostego kodu, pisanego na szybko, często do
> > > > jednokrotnego użycia, moim zdaniem to strata czasu. W takich
> > > > sytuacjach ta klamerka jakoś dodaje mi pewności siebie.
> > > >
> > > da mnie (mimo ze jestem srednio zaawansowanym z grubsza programista) klamerki
bywają ciegle od czasu do czasu przyczyną błedów (kompilacji)
> > >
> > > dluzsze bloki tez mi sie zdarzają,
> > > (zarowno dluzsze i takie z nawet
> > > 3-ma 4-rema 9ale 4 raczej max wiecej chyba nie ma) zagniezdzeniami klamer)
> > > chyba dletego ze jak sie optymalizuje
> > > kod to wole miec wiekszy kawalek w jednym miejscu i tez czesta wylaczam
> > > bloki kodu przez if(0) co daje dodatkowe klamry - klamry nie sa wtedy wygodne;
ostatnio rozwalazlem wersje c bez klamer, gdzie blok sie konczy srednikiem ; czy
czyms takim - moze to by lepiej dzialalo...
> > Hmmmm to mamy odwrotne doświadczenia. Ja taki kod produkuję w innych
> > sytuacjach niż podczas optymalizacji. Produkuję np. gdy nie wierzę że
> > w przyszlości da się łatwo wykorzystać, gdy np. wolę cały moduł wywalić i
> > napisać na nowo. Albo gdy program ma być uruchomiony doslownie jeden raz.
> > Wtedy mam procedury po 200 linijek. No i też wtedy klamerki ratują mi
> > życie, a przynajmniej tak mi się wydaje.
>
>
> ja raczej nie mam sklonnosci do dlugich funkcji, moj naturalny 'styl' to takie
10-centymetrowki, 20-stki
> 30-stki (gdzies tak pewnie do 70-tek
> ale wiecej chyba krotkich)
>
> 200 linijek to nie sa jeszcze jakos specjalnie dlugie, to pewnie gdzies tak ze 4
ekrany (w malej czcionce) czyli nie tak duzo

fajnie jest wogole przeliczac kody na dlugosc (10 linijek nieco mniej niz 10 cm 0,
wtedy takie typowe moduly czyli zwoje/scrolle maja po kilka metrów

to jest o tyle sensowne ze wlasnie
wygoda uzywania i tez wlasnie rozwoj podzialu wiaze sie niejako z fizykalnymi
cechami, nie inaczej

do góry