At an abstract level, each instance of a conventional class has a __dict__ member that is a conventional Python dictionary, andinstance attributes are created and manipulated by manipulatingthis dictionary; the dictionary key is the attribute name and thevalue is the attribute's value. __slots__ eliminates thisdictionary and instead has a fixed list of attributes that instancesof the class know about. All of this is in the documentation . What thedocumentation won't tell you is how the machine level

Presented in the traditional illustrated form:

class A(object):     __slots__ = ('a',)class B1(A):     __slots__ = ('b1',)class B2(A):     __slots__ = ('b2',)

Now try to define a class C that inherits from both B1 and B2,and you will get:

TypeError: Error when calling the metaclass bases
multiple bases have instance lay

I've written before about how I emulate C structs in Python . This is only an emulation, and one of thedifferences between the two, one that is sometimes important, is thatelements in such a Python struct do not have an order.

Where this comes up for me is that every so often I want to useintrospection of a Python struct to automatically map between the Pythonstruct and some flat ordering of the fields, such as a file or a networkprotocol message. With no inherent order to the

I recently read an Ars Technica article on the history of Linuxgraphics ,which contained the bald-faced line:

What made X so special, of course, is legendary. X was the firstgraphical interface to embrace a networked, distributed solution.[...]

Wrong. This is one of X's attributes, but it is not what made X specialand successful. As I have touched on before ,what made X so special is that it did not suck, it was portable, and oh

I've mentioned in passing before ( here and here ) that we have had a long-standingproblem where our ZFS ARC sizes would basically collapse; the ARC wouldspontaneously decide to limit itself to 2 GBytes or so despite themachines having 8 GBytes and being basically unused apart from NFSfileservice. In the end, I believe I've figured out why this happenedto us. The short answer is kernel memory fragmentation.

(At this point I will pause to mention that we are running more or lessSolaris

There are two general ways of handling out of date cache entries: cacheinvalidation, where you explicitly mark them invalid or remove them, andhaving validators, so that you check to see whether an entry is valid asyou retrieve it from the cache.

Cache invalidation has a number of advantages. First, it's clearlysuperior to validators if you're running into the size limits of yourcache, because it immediately frees up now-dead entries instead ofleaving them around to steal space from the live entries

In a comment on my first entry in this series ,nothings wrote:

And if you're writing from scratch, writing a static baked system issurely easier than writing a dynamic system with caching. So: betterperformance, and easier to write.

Actually, I disagree about which option is simpler.

First off, I think it's clear that a simple dynamic system withoutcaching is easier to write than a static system. Both systems needsomething to render pages from content text, templates, and so on

A commentator on my first entry on this asked agood question:

Where do you draw the distinction between a baked site and a cachedsite? They're both a snapshot of a dynamic site. They both suffer frompotentially stale cache. They both require an invalidation mechanismfor the publishers.

I think there are two important differences.

First, a baked site is effectively a permanent cache. The word'permanent' is the important thing, because it means that youabsolutely have to get invalidation right because there is

I'm not a deep expert on this field, so I'm not going to claim that thisis a complete taxonomy of how dynamic sites implement caches. Theseare just the three sorts of caches that I've seen mentioned fairlyfrequently. As it happens, DWiki uses all three so I can give examples.

Query caches cache the results of expensive database queries and otherlookups that are (hopefully) frequently used. DWiki uses a query cacheto save the result of the filesystem walk it does to determine