If there are not enough gardeners, even the most beautiful and well-groomed park will eventually turn into an impenetrable wilderness. The larger and more ambitious a project is, the messier it will become when there are not enough resources.

Lines of code: production / tests

GenroPy has a very large codebase, but it is in dire need of resources to support its growth.

GenroPy is a huge project: more than 50,000 lines of Python code and nearly 20,000 lines of Javascript code. It is truly a monument to the productivity and the passion of its authors, considering that the mailing list count just 12 people. There are no separate user and development mailing lists.

Who are these developers?

• Softwell (Italy) is the largest GenroPy shop. They are the original authors of GenroPy. It’s the company of Giovanni Porcari, the marvelous genius behind GenroPy. I say it without any malice, he is truly a great developer and a wonderful guy. There are also his sons, Francesco and Saverio, who are as bright as their father. Michele Bertoldi, another great developer, also works in Softwell when he’s not busy at the E-Health Lab at Politecnico di Milano. Paolo Camera and Filippo Astolfi complete the core GenroPy team at Softwell.
• GoodSoftware (Australia) is the second GenroPy shop worldwide. Jeff Edwards runs it. He’s a pretty nice guy too. The last time we spoke (a couple of weeks ago), he wasn’t yet successful in his quest to hire more programmers – so I assume he’s still the only GenroPy developer operating outside Italy.
• Med Media (Italy) is the last GenroPy shop. The programmers there are three students, who are graduating in Biomedic Engineering (MsC) and are about to start working on their thesis. These students started with both Python and GenroPy in november 2010.

This is the whole GenroPy community, worldwide.

For comparison, let’s look at Django 1.3: more than 66,000 lines of Python in production, but also more than 51,000 lines of test code. The developers mailing list has 6,342 subscribers, the users mailing list has three times as much.

How many production lines does each developer supports? How many production lines are there for each test line?

I’ll leave calculating the bus factor of the two projects as an exercise to the reader.

These principles are:

• Single responsibility – an object should have only a single responsibility.
• Open/closed – software entities should be open for extension, but closed for modification.
• Liskov substitution – objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
• Interface segregation – many client specific interfaces are better than one general purpose interface.
• Dependency inversion – depend upon abstractions, do not depend upon concretions.

Unfortunately, GenroPy violates all of them in some important parts of its design or implementation. In the rest of this article, I’ll show examples where it happens.

Single responsibility

This principle states that “every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.“

What is a responsibility? Robert C. Martin, who introduced this principle, defines a responsibility as a reason to change: a class or module should have one, and only one, reason to change. As an example, consider a module that compiles and prints a report. Such a module can be changed for two reasons. First, the content of the report can change. Second, the format of the report can change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules.

GenroPy is plagued with many violations of the single responsibility principle. Most of its high-level classes are jacks of all trades.

For example, let’s look at the GnrApp class from the gnr.app.gnrapp module. It’s stated purpose is to open a GenroPy application instance and work as a façade to its high-level services (mostly for database access in batch processes). Why does it need to know how configuration files are organized on the various platforms (load_gnr_config method)? Why does it contain code to assemble the application menu (init method), an user-interface detail? Why does it contain code to load and save localization files (buildLocalization, updateLocalization)? Why does it know how to send emails (sendmail)? Finally, why does it implement methods to authenticate users using xml data, sql tables or python methods (auth_py, auth_xml, auth_sql)? All of these responsibilities should be in their own separate classes or, in the latter case, clusters of classes.

auth_py is particularly interesting for being totally misleading and almost not useful at all. It doesn’t allow you to authenticate a user in your own code. Your code get only a single parameter, the username, and you can return a new username, a new user id or new tags (GenroPy’s tags are roughly equivalent to Zope roles or LDAP groups). Your code doesn’t get the password at all, so it has no way to really authenticate the user. Why is there such a method? It’s used to implement a single feature, that is only slightly related to authentication, passepartout users: it lets you as a developer impersonate another user to help during debugging.

Let’s look at some other classes:

GnrDboPackage from gnr.app.gnrdbo is the base class for packages (GenroPy’s packages are roughly equivalent to Zope products). It acts as a façade to many services common to all packages, such as counters or user management. Why each and every package in an application needs its own counters and users table is beyond my comprehension. I never dared to ask.

SqlTable from gnr.sql.gnrsqltable is the class that lets you access database tables. It knows how to perform select, update, delete and lock operations on a single database table. It also creates record bags (these are the GenroPy’s equivalent of data transfer objects that are sent to the user interface) and how to write record clusters (set of related records, e.g. in master/detail schemas), it even decides what fields to display when a record appears in a combo box or list in the user interface. SqlTable implements a wide range of responsibilities from database access to UnitOfWork tasks, to details of the user interface.

There are many other examples, the worst offender is probably GnrWsgiSite from gnr.web.gnrwsgisite.

Open/closed

This principle states that “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification“; that is, such an entity can allow its behavior to be modified, but without altering its source code.

The standard way to query a database in GenroPy is this:

def somePageMethod(self, param1):
        tbl = self.db.table('pkgname.tablename')
        qry = tbl.query(where='$param1 = :param1', param1=param1)
        sel = qry.selection()
        return sel.output('baglist')

Here self is the webpage, which allows you to access the database object using its db attribute. Using it, you get a reference to the SqlTable object. Once you have a database table, you can query it. Once you have built a query, you ask for its results and you get a SqlSelection object.

As usual, these selection object do many things: you can filter, change, re-order or even aggregate data. Once you’re done, you can transform them to many formats using the output() method. This method is implemented by looking up implementation methods in the SqlSelection class itself.

For example, the code above will eventually call the following out_baglist method:

def out_baglist(self, outsource, recordResolver=False, caption=False):
"""add???

:param outsource: add???
:param recordResolver: boolean. add???. Default value is ``False``
:param caption: boolean. add???. Default value is ``False``
:returns: add???
"""
result = Bag()
for j, row in enumerate(outsource):
    row = dict(row)
    pkey = row.pop('pkey', None)
    spkey = 'r_%i' % j
    result.setItem(spkey, Bag(row), _pkey=pkey)
return result

(By the way, notice that (a) this method has two parameters that are not used at all, a leftover from a previous feeble refactoring without a test case safety net, and that (b) “add???” is a placeholder for documentation yet to be written. There are 2605 methods in the current GenroPy’s codebase that have placeholders instead of real documentation)

SqlSelection has all sorts of output methods:

• out_bag
• out_baglist
• out_count
• out_data
• out_dictlist
• out_distinct
• out_distinctColumns
• out_fullgrid
• out_generator
• out_grid
• out_json
• out_list
• out_listItems
• out_pkeylist
• out_recordlist
• out_records
• out_selection
• out_tabtext
• out_xls
• out_xmlgrid

These methods range from transforming selections into other internal data structures, like bags and lists of dictionaries, up to to exporting to full-blown external formats like JSON or even Excel files.

(There are also obviously violations of the single responsibility and the dependency inversion principles, but we’re concerned with the open/closed one here)

How are you supposed to add a new output methods? You add it either to the source code of the class or you “monkeypatch” it at runtime. That’s a serious design flaw, in my opinion.

Liskov substitution

This principle has been succinctly formulated in a 1994 paper as follows:

Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects of type S where S is a subtype of T.

Liskov substitution is a particular definition of a (semantic) subtyping relation, sometimes called strong behavioral subtyping, introduced by Barbara Liskov in 1987.

In order to satisfy the Liskov substitution principle, some strict requirements on signatures of methods must be verified:

• Contravariance of method arguments in the subtype.
• Covariance of return types in the subtype.
• No new exceptions should be thrown by methods of the subtype, except where those exceptions are themselves subtypes of exceptions thrown by the methods of the supertype.

Static programming languages can enforce these constraints at compile time. In Python, you have to enforce them manually when you design code.

There are additional, behavioral conditions that a subtype must meet to satisfy the Liskov substitution principle:

• Preconditions cannot be strengthened in a subtype.
• Postconditions cannot be weakened in a subtype.
• Invariants of the supertype must be preserved in a subtype.
• History constraint (the “history rule”). Objects are regarded as being modifiable only through their methods (encapsulation). Since subtypes may introduce methods that are not present in the supertype, the introduction of these methods may allow state changes in the subtype that are not permissible in the supertype. The history constraint prohibits this.

GenroPy’s database adapters violate the Liskov substitution principle: they raise database-specific exceptions, leaking their implementation details through an abstraction that should abstract them.

In addition, the way GenroPy implements triggers, in particular  trigger_onUpdating(self, record_data, old_record), makes it very hard not to violate the Liskov substitution principle in your own code.

Interface segregation

Once an interface has become too fat, it needs to be split into smaller and more specific interfaces so that any client of that interface will only know about the methods that pertain to them. No client should be forced to depend on methods it does not use.

GenroPy is full of fat classes, the worst offender is the “Bag“ class itself, the basic building block of most GenroPy’s technologies: database access, database schema definition, user interface, data transfer between the server and the browser – all are based on GenroPy’s bags.

Bags need a serious redesign, their public interface is huge – 78 methods – for a class whose only responsibility should be to manage ordered lists of keys/values pairs and associated attributes.

Bags are so fundamental to GenroPy that a complete discussion of their problems, and a possible redesign, will require an article on its own.

Dependency inversion

The principle basically states that:

• High-level modules should not depend on low-level modules. Both should depend on abstractions.
• Abstractions should not depend upon details. Details should depend upon abstractions.

GenroPy doesn’t respect these rules at all. The antipattern used to implement SqlSelection‘s output() method obviously violates dependency inversion rules. GenroPy employs this bad solution in other places, notably in the central Bag class.

Another obvious violation is in many methods of the core classes – GnrWsgiSite, GnrApp or GnrDbPackage – that act as façade for methods and features defined in packages. Since packages are by definition optional (you need to explicitly list the packages you want to load in the application configuration file), GenroPy core classes (high-level modules) are very fragile: they directly depend on the low-level details of potentially optional modules.

Conclusions

This article is not an attack to GenroPy. My aim is not to kill the project, but to help it grow. I had plans to attack these issues, introduce a comprehensive test suite and refactor code smells. I cannot contribute to the project anymore, so someone else – most probably GenroPy’s core developers – will need to address these issues.

GenroPy codebase has some serious flaws. Many of them are a result of its origins and the non-conventional background of its authors. These are also its strengths: for the tasks it’s been designed for (business applications), GenroPy can be insanely productive.

Some level of defects and design flaws are normal in a project that hasn’t reached version 1.0. These issues, however, are important and need to be fixed in order for the project to gain users and supporters outside its current, very small community.

In the last year and half, I have been the largest GenroPy user outside Softwell, the company that created the framework. There is a lot I learned about it and its community. There were many areas that I wished to improve with my contributions.

Some of these problem areas are critically important for the viability of the project and need to be fixed soon. Since I cannot directly help anymore, I will summarize them on this blog in a series of articles for several reasons:

• I do not wish to see my name associated with a project and a codebase that I consider suboptimal and that I cannot fix.
• I wish to help people who are evaluating GenroPy for their projects, since some of these issues took time to discover and were not obvious from the start.
• I hope someone will pick up from where I left and fix these things. I still see a lot of potential in this project, once these issues are solved.

Note: Critical reviews are always problematic, so I will only accept comments that discuss the technical aspects of my articles about GenroPy.

• Carl Friedrich Bolz (Microsoft Research) parla di PyPy e dei tracing JIT compilers.
• Ancora sul supporto a Python 3 in PyPI.

Javascript

• Essential Javascript Design Patterns (libro scaricabile) – pattern di design in Javascript (Creational, Constructor, Singleton, Module, Revealing Module, Observer, Prototype, Command, DRY, Facade, Factory, Mixin,Decorator) e jQuery (Lazy Initialization, Composite, Wrapper, Facade, Observer, Iterator, Strategy, Proxy, Builder, Prototype, Flyweight).
• Easy WebSocket.
• AppCelerant introduce Titanium+Plus.
• IDE/Code Editors nel browser: ACE, Cloud9, Eclipse Orion, SourceKit, CodeMirror.
• Javascript Augmented Reality Toolkit.

Analisi dei dati

• Analisi dei dati bayesiana contro il test dell’ipotesi nulla nel metodo scientifico moderno.
• Video sorveglianza intelligente – un trend in crescita, la riduzione dei costi dell’hardware attraverso il ricorso a software più intelligente.

Giochi e mondi virtuali

• Social Mechanics in Games (vedi anche questo).
• Neptune 3D – rendering foto-realistico, in real-time, di scene naturali complesse con milioni di fili d’erba e alberi illuminati realisticamente. (Interessanti anche le altre pubblicazioni di Kévin Boulanger).

Miscellanea

• Piracy is the Future of Television – lo dice il MIT.
• Un anno da informatico a Londra – quasi rimpiango di non esserci andato nel 2008 come avevo in programma di fare.
• Psicologia ed incapsulamento nel design del software.
• On the Engineering of SaaS – come cambiano le pratiche dell’ingegneria con il cloud computing. Molto interessante.
• SSD e analisi forense.
• Software open source per la sanità.

Il mondo è un posto pericoloso, non a causa di chi compie azioni malvagie ma per quelli che osservano senza dire nulla.

Albert Einstein

Privacy

• BlackHat Europe 2010 - Changing Threats To Privacy From TIA to Google.
• L’insistenza di Facebook che gli utenti usino il loro nome e cognome è problematica per gli attivisti dei diritti umani che hanno bisogno di lavorare anonimamente, per sfuggire alle ritorsioni dei regimi oppressivi.
• Privacy e Cloud Computing in Italia.

Python

• smewt – un media manager semantico, scritto in Python e QT4.
• EuroPython 2011 – Call for papers.
• Pattern – un package per catturare dati testuali (Google, Twitter, Wikipedia, Web spider & parser), analizzarli (shallow parser, wordnet, n-gram search, similarità, latent semantic analysis) e visualizzazione di grafi.
• Funzioni statistiche basate sulla GPU.
• Come migrare via da Google App Engine.
• Unicode in Python.

Sicurezza

• XSS Prevention Cheat Sheet.
• Python Security.

Ruby

• Concorrenza in Ruby.
• MacRuby 0.9 è arrivato.

Web

• Specifiche HTML5, Web Developer Edition – senza tutte le informazioni che interessano solo chi scrive browsers.
• Top Web Frameworks, usando l’API di StackOverflow.
• Uno screencast sulla costruzione di applicazioni multi-device, usando SproutCore 1.5.
• WireIt – una libreria per costruire editor di grafi in Javascript.

Varie

• Fate of The World – un gioco che simula l’impatto sociale e ambientale del cambiamento climatico nei prossimi 200 anni. Da un lato, è interessante l’uso del gioco come mezzo di comunicazione politica, dall’altro sono convinto che la simulazione prenderà sempre più campo per l’analisi ed anche la divulgazione di sistemi complessi.
• OpenData a Torino.
• Ottimizzare codice OpenCL, un caso di studio.
• Inception in C.
• Tutto quello che dovresti sapere sulla crittografia, in 1 ora.

Agile

• Il movimento agile in Europa è ancora subalterno culturalmente rispetto a quello americano, sebbene per molti aspetti sia più avanti ed innovativo. E’ ora di organizzarsi meglio per avere un ruolo culturale più forte.
• Una prospettiva interessante su TDD e BDD nelle startup. Un’azienda non ancora affermata e strutturata, una startup, deve esplorare il mercato alla ricerca di una nicchia che può garantirti il successo e, quindi, massimizzare il profitto. In questo momento nell’evoluzione dell’azienda, le risorse sono limitate e la qualità del prodotto non è così importante quando il muoversi rapidamente nello spazio di prodotti/soluzioni per trovare il proprio posto. Il TDD/BDD potrebbe in questi casi essere deleterio, più che di aiuto.
• Come scrivere codice testabile usando la Dependency Injection.
• SOLID vs. YAGNI.
• Screencasts su SOLID.
• Scrivere contratti agili.

Algoritmi

• Come visualizzare il comportamento e quindi la complessità degli algoritmi di programmazione dinamica.
• Complexity Zoo.
• Misurare l’evidenza statistica in decibels.
• Flocking.

Libri

• Computer Vision: Algorithms and Applications.
• HackerBooks – i libri citati da Stack Overflow ed Hacker News.
• Scrivere libri per programmatori.

• “We need tools that can help people have their idea faster” – Aditi Muralidharan

Python

• profilestats è un decoratore per la profilazione a livello di singola funzione, supporta kcachegrind (tool di visualizzazione).
• pystatsd – un client per Graphite, un server di cattura e graficazione delle statistiche.
• In Febbraio, Python è salito al 4° posto nel TIOBE, l’indice di popolarità dei linguaggi di programmazione. Prima ci sono solo Java, C e C++. Sarà ora di buttarsi su Scala?
• pytools raccoglie cose che mancano nella Python standard library, ma (secondo gli autori) dovrebbero esserci.
• Cirrus costruisce un’infrastruttura AWS da un file di configurazione yaml.
• Portare il codice da Python 2 a Python 3.
• csc-utils – utilities dal progetto Commonsense Computing del MIT. Molto interessanti.
• Fusil – una libreria per il fuzzing.
• picalo – analisi dei dati e data mining.

Javascript

• Dojo 1.6 supporterà il caricamento asincrono dei moduli, usando lo standard AMD (vedi CommonJS AMD API) comune a RequireJS, Nodules (i.e. Node.JS) e Backdraft. La nuova versione di Dojo supporterà il vecchio sistema di caricamento dei moduli per compatibilità all’indietro, ma il futuro richiederà l’adozione del nuovo standard.ù
• Rivalutare il ruolo degli hash negli URL.
• Bookmarklet ed infrastruttura per la profilazione delle pagine nei browser mobili.

Data

• Keynotes e talks dalla O’Reilly Strata Conference (YouTube).
• Why Your Startup Needs a Visual Dashboard – Una retrospettiva interessante sui metodi di misura e di management
• Una barca di papers interessanti presentati da Google al NIPS 2010. (Altri papers di Google, giusto per gradire)

Algoritmi

• minhasing – un metodo per cercare cose simili in un database o, più in generale, una metrica per calcolare la distanza fra insiemi di attributi. A prima vista, mi sembra che si potrebbero usare tecniche analoghe ai bloom filters per impiegarla in database distribuiti.

Miscellanea

• Nerd Fort – coworking nella San Fernando Valley, Southern California. Non abbiamo sufficiente concentrazione di lavoratori tecnologici qui in Italia? Sarebbe bello avere posti del genere. Si potrebbe anche sposare bene con il turismo. (In ogni caso, mi piace il loro modo di fare comunicazione.)
• Design di un’icona.
• 12000 richieste/secondo con Nginix, PHP e Memcached.
• Una istruttiva storia di brevetti.
• Lo stile cognitivo di Unix. Interessante, mi ha fatto venir voglia di scrivere un tool per l’interrogazione di man in linguaggio naturale: un po’ come la nuova versione di Mathematica.
• La città del cybercrimine in Romania.

Ebooks

• Marsilio editore vende i propri libri elettronici a 4,99 euro. Peccato usi Adobe DRM. (via manteblog)
• Una raccolta di links sugli ebooks ed il self-publishing (via @TomBolini)

• @caludio: “Undocumented and overengineered code have the same evil root “

Python

• Read the docs – un servizio che raccoglie documentazione in reStructuredText (un formato popolare nel mondo Python), rendendola facilmente cercabile. Si integra con Mercurial, Git, Subversion e Bazaar per aggiornare la documentazione al commit.
• dana – Distributed (Asynchronous) Numerical Adaptive computing framework. Un framework, basato su numpy e scipy, per costruire simulazioni numeriche distribuite. Le applicazioni princinpali sono nel campo delle neuroscienze computazionali e nelle reti neurali artificiali.
• ladon – uno framework per rendere metodi python accessibili in vari protocolli, più che altro orientati al web. Può essere utile per implementare web services multiprotocollo.
• Python 3 Wall of Shame – lista di progetti da PyPy che supportano o meno la nuova versione del linguaggio. I creatori di Python hanno una roadmap che prevede l’adozione della nuova versione in cinque anni, ora siamo a metà. Non siamo messi male come appare da questa pagina. Molti progetti, come ad esempio Django, supporteranno Python 3 già dai prossimi rilasci previsti quest’anno.
• flake8 – Pyflakes + pep8 insieme. Un code checker per python.
• zfec – erasure codec in Python, Haskell e C. Può servire in tutti i casi in cui si vuole costruire un sistema ridondante, come il RAID-5, che sia in grado di resistere alla perdita di parte dei dati.

Agile

• Riflessioni su 10 anni di agile. Si spera che si supereranno le etichette ed i particolarismi, inglobando l’agile nella disciplina informatica fino a smetterne di parlarne un po’ come è successo con la programmazione ad oggetti. Non più come una cosa esotica, ma come humus su cui far crescere qualcosa di nuovo.

Javascript

• Anatomia dei Modelli in Ext JS 4.

Conferenze e Talks

• Voglio assistere a REST in peace al Codemotion 2011. La conferenza si annuncia enorme, con sei tracks contemporanee. Sarebbe stato meglio spezzarla in più giorni.
• (auto-promozione) Il 16 febbraio, farò una breve introduzione a GIT, alle 19:00 in MedMedia, via Salvemini 4, Jesi (AN). E’ un evento dell’XPUG marche, ma l’ingresso è libero.

NoSQL

• CouchOne e Membase si fondono. Sono rispettivamente lo sponsor di CouchDB e quello di Memcached. Non sapevo che esistesse Mobile Couchbase per iOS, ne potrei far proprio buon uso.
• Tre modi diversi di usare Riak, un database NoSQL.
• Google rilascia un paper su Megastore, il database di AppEngine. Analisi interessanti qui e qui. Interessante l’uso di un algoritmo basato su Paxos per il raggiungimento del consenso ed il fatto che possa essere configurato in modo più o meno affidabile, un po’ come si può fare anche con Cassandra.
• Quando usare NoSQL? Qualcuno sta compilando una lista di casi d’uso.

Altro

• Augmented Reality + Machine Learning. Applicazione interessante.
• La Cina sta costruendo una città per il cloud computing. Ad una conferenza sui mondi virtuali nel 2007 a cui ho partecipato, un rappresentante del governo cinese aveva annunciato la creazione di una città per i mondi virtuali. Non so che fine ha fatto… forse le riciclano in base alla moda del momento.

  Queste iniziative un effetto della bolla speculativa nel settore immobiliare in atto da anni in Cina – sul mattone si concentrano la mentalità da piano quinquennale del partito unico, la sua propensione per la grandiosità e tanti palazzinari con ottimi contatti con le gerarchie di partito.

• 4-Hour Profitable Project: Viral Marketing Explained.
• Un generatore di curriculum vitae da github.
• Perché Arduino ha vinto? Un bel progetto nato in Italia.

Educazione

• Una società prevede l’esplosione dei corsi online per il 2015: “The number of college students taking online college courses will equal the number of students who attend classes in a traditional classroom by 2015“. Altri dicono che non sarà così e si raggiungerà un plateau.
• Trends che influenzeranno i prossimi anni (report PDF): ebooks e mobile (entro un anno), augmented reality e game-based learning (2-3 anni), gesture-based computing, learning analytics (4-5 anni). Vale per la situazione USA, speriamo non dover aspettare troppo qui da noi.
• Come imparare una nuova lingua rapidamente.
• Un indice di lezioni universitarie d’informatica disponibili online.

Con un po’ di fantasia, potremmo scrivere così:

def tbDetail(self, parent, **kwargs):
    tb = parent.toolbar(**kwargs)
    tb.button('New Detail', action=fire('master.save')|fire('detail.record.pkey'))

Per chiarezza, togliamo un po’ di magia dal parametro action:

def tbDetail(self, parent, **kwargs):
    tb = parent.toolbar(**kwargs)
    tb.button('New Detail', action=self.onNewDetail)

def onNewDetail(self, do):
    do | fire('master.save') | fire('detail.record.pkey')

Può sembrare che stia piegando la sintassi di Python per i miei torbidi scopi, in realtà sto facendo ricorso ad un ben noto strumento della programmazione funzionale. In particolare, la struttura dati che viene passata a onNewDetail è una monade.

Si possono scrivere funzioni di ordine superiore, per combinare insieme computazioni e fornire strutture di controllo:

def onNewDetail(self, do):
    do | unless(get('master.saved'), fire('master.save')) | fire('detail.record.pkey')

L’operatore | (bind) modifica la monade (inizialmente vuota, passata nel parametro do), applicando la funzione che lo segue.

Qui uso le monadi a due livelli:

• nel codice Python, per costruire una semplice AST e generare codice Javascript.
• nel codice Javascript che verrà generato, per implementare la programmazione asincrona sotto forma di continuation monad basata sulle Promise di Dojo 1.5.

result = test and TrueValue or FalseValue

Usavo molto spesso quest’idioma al tempo di Zope 2.7 e Python 2.3, che ho ancora in produzione in un paio di clienti. Dal Python 2.5, non è più necessario, il linguaggio ha un suo operatore ternario:

result = TrueValue if test else FalseValue

Un esempio: costruiamo un VFS partendo da quattro directory, di cui le prime due montate alla radice del VFS mentre le ultime due montate in due distinte sottodirectory. Specifichiamo poi la ricetta per mescolare i files .txt:

from layers import VirtualFileSystem, concatenate_files

vfs = VirtualFileSystem()
vfs.add_layer('layer1')
vfs.add_layer('layer2')
vfs.add_layer('layer3_sub','sub')
vfs.add_layer('layer4_urka','urka')
vfs.set_recipe('.txt', concatenate_files)

fd = vfs.open_file('foo.txt','r')

Nel’esempio ho usato una ricetta predefinita, ma costruirne di proprie è facilissimo. Ecco l’implementazione di concatenate_files:

def concatenate_files(alternatives, mode=None, *args, **kwargs):
    """Concatenate files from the lowest to the higher layer in order.
    """
    return fileinput.input(alternatives, mode=mode, *args, **kwargs)

La parte più interessante però non è il filesystem virtuale, ma la possibilità di montare un VFS come package Python. Layers si occupa di mixare opportunamente funzioni, classi e metodi.

Se layer1/foo.py contiene questo codice:

class Foo(object):
    def method1(self):
        return 'layer1'
    def method2(self):
        return 'layer1'

Mentre layer2/foo.py contiene quest’altro codice:

class Foo(object):
    def method1(self):
        return 'layer2'

Allora posso posso scrivere questo:

from layers import LayeredPackage
lp = LayeredPackage('testpkg')
lp.add_layer('layer1')
lp.add_layer('layer2')
lp.install()

from testpkg import foo
f = foo.Foo()
print f.method1() # scrive layer2
print f.method2() # scrive layer1

In pratica, la classe Foo in foo.py del package virtuale testpkg si comporta come se fosse scritta così:

class Foo(object):
    def method1(self):
        return 'layer2'
    def method2(self):
        return 'layer1'

L’implementazione usa l’ereditarietà multipla, costruendo a run-time una nuova classe. L’implementazione reale di Foo è più o meno questa:

class Layer1Foo(object):
    def method1(self):
        return 'layer1'
    def method2(self):
        return 'layer1'

class Layer2Foo(object):
    def method1(self):
        return 'layer2'

class FinalFoo(Layer2Foo,Layer1Foo):
    pass

Quindi in layer2/foo.py posso anche usare super(Foo, self).method1() per chiamare l’implementazione di method1() del layer precedente.

A cosa serve Layers? Per ora a poco, il codice non è maturo (manca il supporto ai packages, può mixare solo i moduli). È nato come esperimento per replicare la semantica dei mixin di GenroPy, semplificandone l’implementazione.

In potenza, Layers (o i mixin di GenroPy) possono essere usati laddove i linguaggi statici usano IoC containers: quindi ovunque ci sia necessità di specializzare il codice per un particolare ambiente (es. per la personalizzazione durante l’installazione presso un dato cliente, durante i test per iniettare metodi e classi di Mockup, etc.).

Per ora, lo userò per imparare setuptools/Distribute e magari per dare un’occhiata a FUSE.