In the Python community, whenever discussing web development, there is always the elephant in the room: Zope. The granddaddy of the web frameworks. Often thought of as something to be avoided at all costs, Zope is little discussed.
Which is interesting, considering that one of the more discussed (perhaps not the most; that award is probably taken by Django, and second place most likely by Flask) modern Python web frameworks, Pyramid, can trace its lineage directly back to Zope (and, indeed, the number of zope.* packages it uses is nonzero).
It’s pretty much accepted in many circles at this point that Zope is essentially “a bad word”; a failure; a complex mess, with no remaining lessons to give; essentially, with no remaining redeeming value making it worthy of consideration.
This is a great shame; Zope has a lot to teach
Some things are created with the best of intentions.
C’s wide character support, for example. It was introduced as an amendment to the ISO C90 standard, and intended to add support for dealing with multilingual text to the C standard. It added a new character type – “wide characters” to the C standard, provided by the type wchar_t, which was intended to provide one character per character – as opposed to the legacy “char” which simply cannot provide this.
Some systems ran with this. For example, when the Windows NT team were designing the Win32 API, they standardized on Unicode everywhere. All the system functions which dealt with strings took and returned Unicode strings. They acknowledged that nobody would port their legacy applications if they didn’t provide any backwards compatibility, so they also provided non-Unicode versions of all these functions, but internally they just called through to the Unicode versions.
Posted in Languages
Tagged C, Unicode
So, it’s been over a year since my last post? Well, I didn’t give an SLA when I created this blog, and I didn’t give a defined set of topics that would be covered either. Anyhow, this is going to be a little higher level than my previous programming posts.
The Python Object Model
At the core of the Python object model are two types: type and object. They have a curious relation: type is derived from object, and object is an instance of type. In fact, type is also an instance of type. To look through the object model, we are going to walk through the process of creating a new class step by step, by invoking the type method (Python class definitions are just syntactic sugar for this):
EForge is a project of mine – a project to build a better project management system. The aim is quite simple: Combine the best features of systems like Trac, RedMine and SourceForge, with the best features of systems like GitHub and Gitorious.
Its not a simple process by a long shot. There is a long road ahead of us.
But we just moved one small – but oh so very important – step closer. EForge is moving to its first release, 0.5.
What is EForge today?
Its rare that computing creates something as elegant as the Futex: A simple and highly elegant system on top of which all the important synchronization primitives can be built, which has minimal overhead, and which is screamingly fast.
Its even better when they work everywhere at the same efficiency – that is, whether placed in the process’ local memory, or a shared memory segment. And its such a shame that nobody has implemented them outside of Linux.
UDI is the Uniform Driver Interface. It provides a standard, high performance interface for operating system device drivers, and is standardised at all the important levels – both API and ABI. This means you can take a driver – regardless of if you have the source for it or not – and use it with any UDI supporting system. There is only one problem.
And that is that, unfortunately, UDI has been almost completely ignored
Once upon a time…
Things were nice and simple; all characters were the same size, and that size was 8-bits. Things were easy to handle, for the most part. Much of C’s string handling is rooted in this era, with functions like isalpha inexorably tied to the English language.
Of course, since then the world has changed.
Things got ugly: Multi-byte character sets
Now, these aren’t all bad; many can be considered, for most things, like the one byte per character sets that preceded them. They maintain the invariant that the contents of a multi-byte character cannot be interpreted as a single byte character. This does of course make your coding take more space, but makes legacy programs work.
Some encodings, however, are not so kind. A good example of this is Shift-JIS. Shift-JIS reuses the single byte character space in the second bytes of multi-byte characters. This means that, if you do strchr(‘e’), you might not actually find an E.
Now things are getting really messy, because C doesn’t provide standard functions for dealing with these character sets. The other problem is that dealing with the thousands of character sets in existence is rather complex.