Here is an italian introduction on SqueakGtk.

It explains the basic usage and style used for the plugin and how to contribute by wrapping C functions.

I’ve been developed for 2 years in Python and enjoyed all its features: from the large set of libraries to the great multiplatform support, from power to flexibility. I always done my work using Python.

A time i discovered prototype languages, first of all Io. I started understanding its phiylosophy but i didn’t find it either mature or useful for common tasks.

However, by reading language philosphies, i discovered that many of them try to inherit and use a Smalltlak mind. Then i tried out the most known and used open source implementation: Squeak.

The first time i used Squeak, i din’t get loving it but after a series of reuses and revalutations, i realized that  it could become my own language then get rid of Python. Its features are great, and i would explain why i’ve switched to Smalltalk Squeak from Python:

  • Philosphy: everything is an object, reflective, also conditional and iterational statments
  • Usage: it’s simple, well organized and with a unique world/IDE integration
  • Documentation: there’s not so much documentation, but existing functions are good examples
  • Fun: it’s fun to learn it and use it for many tasks, it implicity sets a rigid and well structured development line for your applications
  • Easily extendible: Squeak language subset, called Slang, is a great tool for creating plugins, in fact i’m contributing on the GtkPlugin, and some libraries extend also particular behaviours
  • The world: strong debugging, efficient threading support, nice versioning and packaging system and easy to mantain because of senders/implementation checkers.
  • Storage use: it can be used as an OO database itself, and it’s easy to port your application on different platforms without dependencies problems by transferring the image and a single executable file.
  • No filesystem problems: it doesn’t touch filesystem for packaging, so there are no problems and you can switch image/VM easily

On generic tasks:

  • GUI: it’s not really good for creating GUI apps, Morphic is not the best choice to do it. There’s a wxSqueak implementation which works fine, also we’re seriously working on GtkPlugin.
  • Web: Seaside is the best web choice for both Squeak and Visual Works. It’s innovative, a great idea and it’s much supported by the community with many existing tool implementations (e.g. Comet).
  • Console: it’s not really indeed to be used for console development, but it’s possible to do it.
  • Network: Python got Twisted Matrix which is a big and mature-level project and it’s not comparable with Squeak network support, but it offers a large number of components and abstract classes to let you build efficient networking applications.
  • Database: there’re various database supports: Postgres, Sqlite, Mysql, ODBC, but it’s missing a common interface to them. However, usually in Smalltalk you can use a good OODB (like GOODS, OmniBase, Magma) or the image itself as storage.

All these features, most of all Slang and the image, even the set of library is inferior to the Python one, i’ve switched to Smalltalk Squeak.

This extension uses py2html to highlight code. Before this library, i tried SilverCity, which new versions are bugged, so i decided to use py2html instead.
This library is pretty simple, maybe it could be done better, but it's good enough for highlighting purposes.

Here's the markdown extension:

import py2html
import os
import tempfile

class HighlighterExtension:
    style = py2html.py_style
    for key, value in style.iteritems():
        value[0] += ' '
    def __init__ (self):
        self.CODE_RE = '\[\[\[(.*?)\]\]\]'

    def extendMarkdown(self, md): = md
        escape_idx = md.inlinePatterns.index(ESCAPE_PATTERN)+1
        md.inlinePatterns.insert(escape_idx, HighlighterPattern(self.CODE_RE, self))

class HighlighterPattern(BasePattern):
    def __init__(self, pattern, ext):
        BasePattern.__init__(self, pattern)
        self.ext = ext
    def handleMatch(self, m, doc):
        code =
        fd, fname = tempfile.mkstemp()
        f = file(fname, 'w')
        result = py2html.file2HTML(fname, 0,, True)
        place_holder =
        return doc.createTextNode(place_holder)

The regexp pattern allows to use this syntax in the markdown text:

python code

PlugBoard is born because of the need to create several plugin-based projects. These projects, currenly got a plugin management system many times different between each other and not much organized. So, we decided to create a shared plugin system to use in all kinds of environments (daemons, GTK, Wx, Twisted an so on).

Actually, we chose zope interfaces to gain a good abstraction level for both framework components and its based applications.

The framework tries to offer as much utilities as possible to create a plugin-based application and at the same time to be as much flexible as possible, so that the framework could be applied to all kinds of projects, as described before.

The framework phylosophy let the application base everything on plugins, then plugins will be the core of the application as well, even the programmer decide to let the core be pluggable.

Release notes:

  • Fixed adaption registering
  • Added new documentation
  • Added a new builtin context resource DictContextResource
  • Minor fixes

Python Egg:
Mailing list:

Thanks for any contribute you give to this project, hoping this work can be useful for the community :)

I've been using SQLObject in web environments since several months, up to a week ago when i discovered SQLAlchemy.

I didn't try the new SQLObject 2, but i guess, reading the release notes, it hasn't been changed its base.

SQLObject can be simple to use and understand for newbies, but SQLAlchemy can be really powerful in many situations:

  • First of all, SQLAlchemy gained a powerful and really flexible Python-to-SQL syntax, which SQLObject is missing, and a great database engine management. This means you are not forced to perform object-oriented based operations.
  • SQLObject provides an unique way to serialize tables, while SQLAlchemy mapping gives you more choice to render tables: for example you can map a select and (really great) make changes to that select to be committed.

SQLAlchemy got many features that SQLObject is currently missing, or better, they've a different phylosophy. Eventough they've these big differences, migrating to SQLAlchemy isn't a pain, because of the mapping feature.

Take an eye on it ;)

I added a basic documentation to let you know what PlugBoard would like to be here.
In the while, i released the 0.1.1 version because of some typos in the first release due to nightly distractions ;)

PlugBoard is an Application Framework made in Python built on top of setuptools and zope interfaces which help the developer create a plugin-based application.
The framework itself is very extensible and let the application be extensible too as well. An application is made up of a plugin resource (get all available plugins in the application), a context resource (organize plugins into different contexts) and an engine to let plugins communicate each other into different environments (such as PlugBoard, Gtk, Wx, Qt, Twisted, and so on) and provide some useful utilities.

Many times i needed to create a plugin-based application, usually using GTK, and now i decided to create a definitive framework for my projects. Hope this would be an helper project for you all and you find it useful.

There's no example actually, just a few lines of code in tests: consider this a start point versus better and more complete relases of this program.

You can find all informations you need at the project page.

This code is not much good, it's wrote on the fly, but well working.

class Descriptor(object):
    _doing_get = _doing_set = _doing_del = False
    def __init__(self, name, fget=None, fset=None, fdel=None, value=None):
        self._name, self._fget, self._fset, self._fdel, self._value = name, fget, fset, fdel, value

    def __check_attribute(self):
        except AttributeError:
            raise AttributeError, self._name

    def _common(self, instance, action, *args):
        method = getattr(self, "_f"+action)
        actname = "_doing_"+action
        if not method or getattr(self, actname):
            raise "manual"
        setattr(self, actname, True)
            ret = method(instance, *args)
            setattr(self, actname, False)
        return ret

    def __get__(self, instance, owner):
            return self._common(instance, "get")
        except "manual":
            return self._value

    def __set__(self, instance, value):
            self._common(instance, "set", value)
        except "manual":
            self._value = value

    def __delete__(self, instance):
            self._common(instance, "del")
        except "manual":
            del self._value

class DescriptorsMeta(type):
    def __new__(cls, name, bases, dict):
        descriptors = {}
        for fname, func in dict.items():
            if (fname.startswith('set_') or fname.startswith('get_') or fname.startswith('del_')) and callable(func):
                    action, varname = fname.split('_', 1)
                    if not descriptors.has_key(varname):
                        descriptors[varname] = {}
                    descriptors[varname]['f'+action] = func
        for varname, actions in descriptors.items():
            if dict.has_key(varname):
                actions['value'] = dict[varname]
            dict[varname] = Descriptor(varname, **actions)
        return type.__new__(cls, name, bases, dict)

This metaclass searches for methods called set_* or get_* or del_* and creates a descriptor for that variable name.

__metaclass__ = DescriptorsMeta
class Test:
    var = "initial value"
    def set_var(self, value):
        self.var = value
    def get_var(self):
        return self.var
    def del_var(self):
        del self.var
        return "deleted"

test = Test()
assert test.var == "initial value"

test.var = "another value"
assert test.var == "another value"

test.set_var("set trough method") # recursive
assert test.get_var() == "set trough method"

del test.var

Before starting to write my hopinions on both Nevow and TurboGears templating systems, i have to say that i didn't create important websites with Nevow or TurboGears yet... then my approach to these technologies are not great.

I discovered TurboGears before Nevow, and i was wondering how TurboGears is simple. In the while, i dislike Kid... maybe because it "seems" to separate code from html and it's a pain for long template pages, mainly for maintenance, or maybe because i didn't like much ZPT.

Later on, i followed Subway, because it was simpler that TurboGears (maybe not so much on documentation) and used Cheetah which is clearly to me.

Django has the same templating system, more boring, than TurboGears and Subway.

At the beginning, i always refused to use a template which separates html from code, and i think the reason was that i didn't find a well-organized backend for this kind of template... then i always believed that a template in which you can run basic Python code could be more efficient.

However, some days ago i discovered Nevow. It's more complex than the above frameworks but its templating system is simply... great.
It really separates code from html. There is a big difference between using a raw "for" against a sequence render, and other Nevow directives. It could appear a bit equal to the previous explained templates, but it's not, for many reasons, and maintenance is one of the them that is enough to drop this kind of templating systems.
Another word i would like to spend on Nevow is that, since it's based on Twisted, you can attach how many services you want to side to your web server.

Personally, i found Nevow complex but powerful and currently satisfies me. Although it seems to be the right choice for me, nothing forbids me to drop it in the future and return back to TurboGears or Subway.

After that, i'm going to explore Mantissa...

Kiwi is a PyGTK framework for building graphical applications loosely based on MVC Model-View-Controller (MVC) and Allen Holub's Visual proxy [1]. Think of Kiwi as a high-level, object-oriented layer built on PyGTK.

Its design is based on real-world experience using PyGTK to develop large desktop applications, which use many concepts common to most graphical applications: multiple windows and dialogs, forms, data persistence, lists and high-level classes that support domain objects directly.

Personally major changes are:
- UI testing framework
- Dialogs handling
- Logging helpers
- Win32 installation, documentation, and various fixes

This release got many changes and new features enhancements, visit the homepage to try it out.

Next Page »