Naufraghi nella rete » python

Dietro Dive Into Python 3

Matteo — Mon, 02 Feb 2009 09:04:27 +0000

Oggi ho notato il sito diveintopython3.org.

Incuriosito dal footer:

This site is optimized for Lynx just because fuck you.
I’m told it also looks good in graphical browsers.
© 2001-4, 2009 ℳark Pilgrim, CC-BY-3.0

Sono andato a guardare nei sorgenti della pagina ed ho trovato questa interessante riflessione:

- As I write this, the year is 2009, and the internet is STILL a battleground of so-called “intellectual property” disputes. Some people would have you believe that without proper financial incentives, music, literature, and software would disappear. After all, who would make music if they can’t make money on it? Who would write? Who would program?

I know the answer. The answer is that musicians will make music, not because they can make money, but because musicians are the people who can’t not make music. Writers will write because they can’t not write. Most of the people you think of as artists are really just showmen. They collect a paycheck and go home at 5 o’clock. That’s not art, that’s commerce.

I’ve been programming since 1983 and releasing my code under Free Software licenses since 1993. I’ve been writing and publishing under Free Content licenses since 2000. I can’t imagine not doing this. If you can imagine yourself not doing what you’re doing, do something else. Do whatever it is you can’t not do. -->

iPhone TPM? Linguaggi interpretati all’arrembaggio!

Matteo — Mon, 21 Jul 2008 11:02:58 +0000

La voglia è tanta… ma questa cosa del TPM rende mooolto più facile la tattica della “volpe e l’uva”!

Da sviluppatore è proprio inconcepibile avere un oggetto, con un sistema operativo, un SDK, ottima documentazione, e… non poter provare un programma sul MIO dispositivo senza avergli fatto fare una giratina virtuale per prendere una firma a Cupertino (99€/anno per lo scomodo)!!

Poi un pensiero: «Perché mai iPhone è uscito senza Java?»

Ma è facile, perché con Java basta avere una Virtual Machine firmata per far girare tutti i programmi del mondo, e ciao ciao AppStore! Stessa cosa per Python-Ruby-Perl!

Quindi TPM mio caro, non hai un gran futuro! (spero!, non ho indagato a fondo, ma credo che il controllo sia per processo e non per… boh, sul linking dinamico o che sò)

A volte mi trovo a non riuscire a spiegare quale sia e quanto sia profondo il limite di questa scelta di Apple per la “libertà” del compratore.

Molti rispondono «Ma quando mai avrò bisogno di scrivere un programma per il mio cellulare?», però anche se non è evidente, quello che sta vendendo Apple, nel mondo delle auto sarebbe come comprare una bella macchina, pagarla più del suo prezzo (perché la tecnologia equivalente la trovate a giro anche a molto meno) e come “bonus” per la spesa maggiorata, poter fare il pieno solo da Agip!

La comprereste?

Cython rocks

Matteo — Fri, 02 May 2008 00:30:13 +0000

Ho cominciato a lavorare sul serio all’università, in laboratorio si macinano proteine, tante, ed il povero Python non regge il passo.

Durante la sosta forzata mi sono baloccato con OCaml, e devo dire che è un linguaggio interessante, anche se per ora non sono ancora riuscito a realizzare un qualcosa di funzionante :/ !

Uscito da gesso e riabilitazione, ho cominciato a studiare le “nuove” reti neurali (deep neural networks), e ne ho implementata una in poche paginate in Python.

Però la velocità è quella che è… allora è partito il pellegrinaggio:

Ho riscritto il tutto in OCaml, ma c’è un bug che non fa convergere nulla… e non lo trovo!
Ho provato pypy, per vedere se il mio codice era abbastanza RPython… ma non lo era
Ho provato ShedSkin, ma anche per lui il mio codice non era abbastanza statico.

Allora mi sono arreso, l’inferenza ancora non è gratuita, e mi sono “abbassato” a buttare giù tipi e gestire la memoria, in Cython!

Adesso, avendo reimplementato solo la classe Layer, l’apprendimento ha una velocità decente, il codice resta leggibile, non ho “esportato” il bug della versione in OCaml ed ho spazio per ulteriori ottimizzazioni senza perdere le comodità di Python!

Yuppie!

Ho trovato un buggettino a cElementTree!

Matteo — Tue, 18 Dec 2007 20:10:07 +0000

Giorni fa ho trovato il mio primo bug in un codice sorgente “serio”!

Playing with PyInstaller I have found that the final part of _elementtree.c:

Index: Modules/_elementtree.c

===================================================================
— Modules/_elementtree.c      (revisione 59540)
+++ Modules/_elementtree.c      (copia locale)
@@ -2780,7 +2780,10 @@
       );
-    PyRun_String(bootstrap, Py_file_input, g, NULL);

+    if (PyRun_String(bootstrap, Py_file_input, g, NULL) == NULL) {

+        m = PyErr_Occurred();

+        return;

+    }
    elementpath_obj = PyDict_GetItemString(g, "ElementPath");

execute a bit of python code without checking the return value.
That can lead to weird things playing with import hooks,
for example an assert like this can fail:

Index: Lib/test/test_elemettree.py

===================================================================

— Lib/test/test_elemettree.py (revisione 0)

+++ Lib/test/test_elemettree.py (revisione 0)

@@ -0,0 +1,21 @@

+#! /usr/bin/env python

+

+def importHook(*args, **kwargs):

+    if ‘xml.etree’ in args:

+        raise ImportError

+    else:

+        return __real__import__(*args, **kwargs)

+

+import os

+import __builtin__

+__real__import__ = __builtin__.__import__

+__builtin__.__import__ = importHook

+

+try:

+    import xml.etree.cElementTree as cET

+except ImportError:

+    pass

+else:

+    out = os.popen("python -c ‘import xml.etree.cElementTree as cET; print dir(cET)‘").read().strip()

+    assert str(dir(cET)) == out, (str(dir(cET)), out)

+

Quite a novice with python internals, so comments are welcome.

Fredrik conferma, a parte il fatto che il

m = PyErr_Occurred();

è superfluo, ed il bug verrà fixato in Python 2.6.

Lavoro

Matteo — Sat, 04 Nov 2006 09:39:14 +0000

Ho cominciato a lavorare! Lavoro per la [Develer](http://www.develer.com/), azienda di sviluppo software e non solo, credo di aver capito specializzata nel non specializzarsi.

Sono stato assegnato ad un progetto interno un po’ noioso che consiste nell’adattare [Achievo](http://www.achievo.org/) per consentire la visione delle statistiche delle ore lavorate anche ai clienti, limitando l’accesso ai soli progetti a cui i clienti sono interessati.

Nel farlo ho notato che Achievo è un po’ limitato nell’interfaccia di gestione delle ore lavorate, prevede l’inserimento di un giorno e di un numero di ore.

Lavorando con orari liberi in Develer, il totale ore è spesso la somma di strani intervalli, tipo *10:30-12:30 + 13:50-19:20*

E qua Python viene in aiuto fornendo gli strumenti per creare un banale parser:

importdatetime, time
def parse_hhmm(val):

    return datetime.datetime(*time.strptime(val, "%H:%M")[:-2])
def parse_hinterval(val):

    val1, val2 = val.split("-")

    d1 = parse_hhmm(val1)

    d2 = parse_hhmm(val2)

    if d2 < d1:

        d2 += datetime.timedelta(1)

    return d2 – d1
def parse_wtime(val):

    vals = val.replace(" ","").split("+")

    res = datetime.timedelta(0)

    for ival in vals:

        if "-" in ival:

            res += parse_hinterval(ival)

        else:

            res += parse_hinterval("00:00-%s" % ival)

    return res
if __name__=="__main__":

    print parse_wtime("10:06-13:06 + 14:16-17:47 + 18:08-20:33")

    print parse_wtime("9:47-13:08 + 14:08-19:00")

Che eseguito restituisce:

>>> 

8:56:00

8:13:00

>>>

Un po’ di documentazione: 6.10.2 timedelta Objects.