rolling distro is a post from: FLLOG

def foo(*args, **kwargs):
    import pdb; pdb.set_trace()
    print args

if __name__ == "__main__":
    foo('argument 1', 'argument 2', 'argument 3')

(Pdb) args
args = ('argument 1', 'argument 2', 'argument 3')
kwargs = {}
(Pdb) p args
('argument 1', 'argument 2', 'argument 3')

Ja spodziewałem się czegoś innego a mianowicie tylko i wyłącznie krotki (tuple) z argumentami. Dopiero po pewnym czasie kiedy w trójkę gapiliśmy się na to kumpel zrozumiał gdzie jest problem. Wystarczy w pdb wpisać „h” i zerknąć na listę komend, gdzie znajdzie się args. Pdb najzwyczajniej w świecie wywołuje swoją wewnętrzną komendę zamiast wyświetlić to co znajduje się w args. Dlaczego to zostało tak zrobione? Właściwie powinienem zadać pytanie, dlaczego *args jest tak lansowane? Co prawda takie zachowanie będzie zagadką tylko raz ale komuś może zająć dużo czasu odkrycie, że to nie jest błąd.
Aby tego uniknąć można zamiast *args użyć innej nazwy ale tak już się przyjęło i gdzie nie spojrzę na kod to widzę *args a nie *params. Dobrze też uważać i nie tworzyć sobie w pdb zmiennych, które nazywają się tak jak komendy debuggera. Należy wystrzegać się zwłaszcza „c” lub „q”, ale to też jednorazowe pomyłki.
A tak w ogóle to:

:W0142: *Used * or ** magic*
Used when a function or method is called using `*args` or `**kwargs` to dispatch arguments.
This doesn’t improve readability and should be used with care.

*args, args i pdb is a post from: FLLOG

$ python2.7 timeit_string_format.py
+ , [1.085777997970581, 1.028688907623291, 1.0265541076660156]
% , [1.659928798675537, 1.6647131443023682, 1.6848421096801758]

$ python3.2 timeit_string_format.py
+ ,  [1.2642889022827148, 1.3161091804504395, 1.2756080627441406]
% ,  [1.154999017715454, 1.201200008392334, 1.1763830184936523]
format ,  [2.1013739109039307, 1.9700350761413574, 1.9505469799041748]

$ pypy-c1.7 timeit_string_format.py
+ , [0.008589029312133789, 0.0017871856689453125, 0.0018048286437988281]
% , [0.14042305946350098, 0.13074803352355957, 0.1352391242980957]

$ pypy-c1.8 timeit_string_format.py
+ , [0.01731586456298828, 0.004745960235595703, 0.0049970149993896484]
% , [0.15033602714538574, 0.12151813507080078, 0.13396596908569336]

Wersja 3.2 przyspieszyła przy składaniu stringów używając % ale znowu łączenie + zwolniło. No a pypy po prostu śmiga. Wyniki ładnie dosyć obrazują „rozgrzewanie” maszyny wirtualnej, pierwszy wynik dla obu wersji pypy odstaje dosyć wyraźnie od pozostałych. Dziwi mnie spadek wydajności wersji 1.8, nie wiem czy powinienem to zgłosić. Programiści podczas prezentacji na PyConie mówili, że jeśli coś jest wolniej to jest to błąd.
To tylko ciekawostka bo tak naprawdę liczy się przede wszystkim czytelność i tylko jeśli to naprawdę jest wąskie gardło aplikacji to można się zastanawiać nad optymalizacją.

Szybkie stringi 2 is a post from: FLLOG

PyCon US 2012 is a post from: FLLOG

text_var_one = 'I am text'
int_var_two = 100
str_variable = 'Some text is written ' + text_var_one + \
               ', next some number is ' + str(int_var_two)

Dosyć nieczytelne w wypadku długich łańcuchów i wolniejsze wg. mnie niż

text_var_one = 'I am text'
int_var_two = 100
str_variable = 'Some text is written %s, next some number is %d' % \
               (text_var_one, int_var_two)

Nie wiem, skąd u mnie takie przeświadczenie bo po sprawdzeniu okazało się, że druga konstrukcja (ta bardziej pro) jest wolniejsza i to znacznie. Jeśli chcesz wiedzieć dlaczego to czytaj dalej.

Różnica prędkości obu sposobów jest ponad dwukrotna. Trzeba to czymś podeprzeć więc pokazuję kod którym to testowałem. Do testów przydaje się moduł timeit.

def method_one():
    for i in xrange(100000):
        'This is: ' + 'var1' + ', this is: ' + str(2)

def method_two():
    for i in xrange(100000):
        'This is: %s, this is: %d' % ('var1', 2)

if __name__ == '__main__':
    import timeit
    print timeit.repeat(stmt='method_one()',
                        setup='from __main__ import method_one',
                        number=100)
    print timeit.repeat(stmt='method_two()',
                        setup='from __main__ import method_two',
                        number=100)

Każda funkcja zostanie zawołana 100 razy w 3 próbach, obie same wykonają pętlę 100000.

$ python timeit_string_format.py
[6.49452805519104, 6.4961841106414795, 6.490808963775635]
[13.923700094223022, 13.944485902786255, 13.96959900856018]

Wyniki mówią same za siebie ale dlaczego tak jest. Aby to sprawdzić trzeba użyć modułu dis ze standardowej biblioteki Pythona. Jeśli masz jakiekolwiek wątpliwości z jakiego powodu coś jest szybsze od innego cośa to odpal dis.dis(). Ten moduł zabiera trochę magii z programowania ale przecież dobrze wiemy, że ani magii ani jednorożców nie ma, bo liczą się liczby i fakty.

import dis

def dis_method_one():
    'This is: ' + 'var1' + ', this is: ' + str(2)

def dis_method_two():
    'This is: %s, this is: %d' % ('var1', 2)

dis.dis(dis_method_one)
dis.dis(dis_method_two)

Specjalnie pominąłem instrukcję for bo tylko zaciemniłaby obraz. Oto wyniki dis.dis().

12            0 LOAD_CONST               5 ('This is: var1')
              3 LOAD_CONST               3 (', this is: ')
              6 BINARY_ADD
              7 LOAD_GLOBAL              0 (str)
             10 LOAD_CONST               4 (2)
             13 CALL_FUNCTION            1
             16 BINARY_ADD
             17 POP_TOP
             18 LOAD_CONST               0 (None)
             21 RETURN_VALUE 

16           0 LOAD_CONST               1 ('This is: %s, this is: %d')
             3 LOAD_CONST               4 (('var1', 2))
             6 BINARY_MODULO
             7 POP_TOP
             8 LOAD_CONST               0 (None)
            11 RETURN_VALUE

Co z miejsca rzuca się w oczy, pierwsza funkcja (ta szybsza) ma o wiele więcej instrukcji więc wygląda, że powinna być wolniejsza lecz nie jest. Konieczne jest dokładniejsze przeanalizowanie tego przypadku. Łatwo zauważyć, że oba listingi dzielą się na trzy części, dwie z nich są wspólne dla obu funkcji więc można założyć, że to nie tutaj jest pies pogrzebany. Pierwsza część to dwie instrukcje LOAD_CONST, co prawda różnią się ilością parametrów ale na korzyść (przynajmniej jeśli chodzi o ich ilość) szybszej funkcji.
Niektórzy mogą zauważyć, że Python sprytnie sobie dodał dwa stringi w pierwszej instrukcji LOAD_CONST. Zamiana stringa i inta miejscami dodaje nam jeszcze jedną operację BINARY_ADD ale nadal jest to szybsze. Taka zmiana jest niepożądana z prostego faktu, rezultat końcowy obu funkcji będzie się różnił.
Druga część wspólna to końcówka czyli instrukcje od POP_TOP. Mięso jest pomiędzy tymi dwoma częściami oraz w źródłach Pythona. Niestety trzeba tam zajrzeć bo więcej się już nie dowiemy. Na warsztat bierzemy plik Python/ceval.c, ze źródeł (w moim wypadku była to wersja 2.7.2), gdzie znajdują się BINARY_ADD oraz BINARY_MODULO. Celowo pomijam LOAD_GLOBAL, LOAD_CONST i CALL_FUNCTION z szybszej funkcji ponieważ jest ona szybsza i mnie to nie interesuje (przynajmniej do czasu sprawdzenia czy wywołanie funkcji w Pythonie naprawdę jest takie kosztowne). Poniżej kod odpowiadający za obie funkcje i jak się przekonacie również nie odpowie na pytanie dlaczego brzydsze jest szybsze.

case BINARY_MODULO:
            w = POP();
            v = TOP();
            if (PyString_CheckExact(v))
                x = PyString_Format(v, w);
            else
                x = PyNumber_Remainder(v, w);
            Py_DECREF(v);
            Py_DECREF(w);
            SET_TOP(x);
            if (x != NULL) continue;
            break;

case BINARY_ADD:
            w = POP();
            v = TOP();
            if (PyInt_CheckExact(v) && PyInt_CheckExact(w)) {
                /* INLINE: int + int */
                register long a, b, i;
                a = PyInt_AS_LONG(v);
                b = PyInt_AS_LONG(w);
                /* cast to avoid undefined behaviour
                   on overflow */
                i = (long)((unsigned long)a + b);
                if ((i^a) < 0 && (i^b) < 0)
                    goto slow_add;
                x = PyInt_FromLong(i);
            }
            else if (PyString_CheckExact(v) &&
                     PyString_CheckExact(w)) {
                x = string_concatenate(v, w, f, next_instr);
                /* string_concatenate consumed the ref to v */
                goto skip_decref_vx;
            }
            else {
              slow_add:
                x = PyNumber_Add(v, w);
            }
            Py_DECREF(v);
          skip_decref_vx:
            Py_DECREF(w);
            SET_TOP(x);
            if (x != NULL) continue;
            break;

Znowu szybsza jest funkcja, która na taką nie wygląda. We have to go deeper! Przeanalizuję teraz pierwszy przypadek szybszej funkcji. Na pierwszy ogień idą dwa stringi ‘This is: var1′ oraz ‘, this is: ‘ więc instrukcja PyString_CheckExact() zwróci True dla obu więc zawołane zostanie string_concatenate(). Za drugim razem również zostanie zawołane string_concatenate() gdyż str(2) tworzy string, w innym wypadku nie można by było ich połączyć. Reasumując, pierwsza funkcja wykonuje jedynie łączenie stringów bez ich analizy.
Teraz druga funkcja, która woła jedynie BINARY_MODULO przekazując string oraz krotkę (tuple). Krotka zostanie przypisana do zmiennej w a string do zmiennej v gdyż w takiej kolejności zostały włożone na stos. PyString_CheckExact() dla zmiennej v, które nota bene jest makrem, zwraca True i zmienne zostają przekazane do funkcji PyString_Format() z pliku Objects/stringobject.c. Tej funkcji nie będę załączał z powodu jej rozmiaru, trzeba zerknąć samemu. W tym miejscu string jest skanowany na obecność odpowiednich znaczników formatowania, robione są testy na poprawność wywołania, testy zgodności parametrów z formatowaniem itd. itp. Nie podjąłem się dokładniejszej analizy tego kodu ale dobrze widać gdzie jest ten nieszczęsny pies. Sama ta funkcja PyString_Format() waży ok. 500 linii kodu.
Konkluzja jest prosta jeśli zależy nam na szybkości a nie interesuje nas czytelność można postawić na „+” i tak łączyć stringi. Natomiast gdy stawiamy na czytelność a na drugim miejscu jest wydajność to bierzemy „%”. Oczywiście argument dotyczący czytelności jest subiektywny i to tylko moje zdanie.
Sprawa wygląda trochę inaczej przy łączeniu długich stringów, w takim przypadku operator „+” nadal jest szybszy ale różnica trochę topnieje.
P.S.
Dzisiaj po wielu miesiącach udało mi się przenieść blog na rootnode.net. Pojawią się zmiany wyglądu bo ten przestał mi się już podobać.

O szybkich stringach w pythonie is a post from: FLLOG

import android

droid = android.Android()
droid.webViewShow('file:///sdcard/sl4a/scripts/gasoline_ui.html')
while True:
    dist = droid.eventWaitFor('dist').result['data']
    gas = droid.eventWaitFor('gas').result['data']
    res = float(gas) / float(dist) * 100
    droid.dialogCreateAlert('Wynik kalkulacji', 'Spalanie: %s' % res)
    droid.dialogSetNeutralButtonText("Ok")
    droid.dialogShow()
    result = droid.dialogGetResponse().result
    droid.dialogDismiss()

Początek jest na tyle prosty, że nie ma co pisać. W pętli dzieje się cała mechanika, python czeka w niej na zdarzenia uruchamiane przez użytkownika w wymienionym wcześniej pliku html (o nim później). Wartości przypisywane są do odpowiednich zmiennych a potem wynik jest wypluwany w formie okna dialogowego. Żadnych trudności, wszystko proste i przyjemne.
A teraz plik html.

<html>
  <head>
    <link type="text/css" rel="stylesheet" href="/test.css">
    <title>Kalkulator spalania</title>
    <script>
      var droid = new Android();

      var calc = function() {
      var dist = document.getElementById('dist').value;
      var gas = document.getElementById('gas').value;
      droid.eventPost("dist", dist);
      droid.eventPost("gas", gas);
      };
    </script>
  </head>
  <body>
    <form onsubmit="calc(); return false;">
      <label for="dist">Ile przejechałeś?</label>
      <input type="text" id="dist" />
      <br />
      <label for="gas">Ile zatankowałeś?</label>
      <input type="text" id="gas" />
      <input type="submit" value="Calc" />
    </form>
  </body>
</html>

Najważniejszą częścią tego pliku jest javascript, który również tworzy obiekt API i poprzez jego metody komunikuje się z pythonem, odpowiedzialna jest za to funkcja eventPost(). Nie jest to zbyt skomplkowane. Jak już ma oba pliki to najlepiej je popchnąć na urządzenie używając adb (rozważam opisanie instalacji i konfiguracji w osobnym poście) poleceniem

adb push plik.py /sdcard/sl4a/scripts/
adb push plik.html /sdcard/sl4a/scripts/

Po tej operacji SL4A umożliwi odpalenie programu z listy skryptów.


Nie jest to piękne rozwiązanie ale umożliwia to zabawę pythonem, do czasu aż API nie będzie wspierać natywnych okienek lub nie pojawi się PyQT lub PyGTK trzeba będzie tak pisać lub przerzucić się na javę.

Py4A czyli piszemy aplikację na androida. is a post from: FLLOG

Py4A – Python w Androidzie is a post from: FLLOG

• Gnome 3
• rpm 4.9
• systemd
• gdb 7.3
• gcc 4.6

Fedorą można pobrać stąd, mam taką nadzieję, że link nadal będzie działał pomimo iż publikuję go przed wydaniem to nie powinien się zmienić.

Fedora 15 is a post from: FLLOG

pierwsza_zmienna_od_długiej_nazwie                = 1
druga                                             = 2
trzecia_zmienna                                   = 3
czwarta_zmienna_o_długiej_nazwie_i_jeszcze_trochę = 4

Piękne, prawda? Ostatnią dodałem specjalnie najdłuższą aby pokazać bzdurność takiej konstrukcji. Po jej dodaniu musiałem przesunąć inne znaki przypisania w zmiennych wpisanych wcześniej!! Cóż za prostota rozwiązania.

dict = {
'pierwsza'                                          : 1,
'druga'                                             : 2,
'trzecia_zmienna'                                   : 3,
'czwarta_zmienna_o_długiej_nazwie_i_jeszcze_trochę' : 4
}

Kolejny cudowny przykład.
Uważam to za błąd w każdym języku ponieważ to zaciemnia tylko kod i wymusza liczenie spacji a potem przerabianie całej konstrukcji w wypadku gdy dodaje się zmienną o dłuższej nazwie. Taka metoda musi być popularna wśród szachistów gdzie ruchy należy planować odpowiednio przed.
Proszę nie piszcie tak. Szachiści również.

Przedszkole w edytorze is a post from: FLLOG

pip install pep8 pyflakes

Natomiast flymake-cursor już trzeba ręcznie skopiować i zapisać jako flymake-cursor.el na ścieżce z plikami el. Ja zapisałem w /usr/share/emacs/site-lisp. Kolejny krok to modyfikacja pliku konfiguracyjnego .emacs. Należy dokleić do niego poniższy kod.

(add-hook 'find-file-hook 'flymake-find-file-hook)
(when (load "flymake" t)
  (defun flymake-pyflakes-init ()
    (let* ((temp-file (flymake-init-create-temp-buffer-copy
               'flymake-create-temp-inplace))
       (local-file (file-relative-name
            temp-file
            (file-name-directory buffer-file-name))))
      (list "pycheckers"  (list local-file))))
   (add-to-list 'flymake-allowed-file-name-masks
             '("\.py\'" flymake-pyflakes-init)))
(load-library "flymake-cursor")
(global-set-key [f10] 'flymake-goto-prev-error)
(global-set-key [f11] 'flymake-goto-next-error)

Ostatni krok to stworzyć plik o nazwie pycheckers gdzieś w PATH oraz ustawić go jako wykonywalny. W tym miejscu można skonfigurować sobie pep8, przydatne gdy wcięcia kodu nie są wielokrotnością 4.

#!/bin/bash

pyflakes "$1"
pep8 --ignore=E221,E701,E202 --repeat "$1"
true

Tyle wystarczy, pozostaje restart Emacsa lub M-x eval-buffer w otwartym buforze z plikiem .emacs i już można korzystać.
Całość to właściwie opis ze strony http://www.saltycrane.com/blog/2010/05/my-emacs-python-environment/ i polecam zajrzeć do źródła gdzie można znaleźć parę innych smaczków do emacsa.

devs y u no pep8 in Emacs is a post from: FLLOG