In the spirit of letting the code speak for itself (and to save me the trouble of composing prose), I created an interactive demo page which should illustrate the basic aspects.

Any feedback would be much appreciated.

The jQuery folks are nice enough to provide a raw XML dump of their API documentation (http://api.jquery.com).
I wrote a quick macro to parse that data and store it as tiddlers:
http://svn.tiddlywiki.org/Trunk/contributors/FND/plugins/jQueryDocsImportMacro.js
Demo:
http://fnd.lewcid.org/tmp/jQueryAPI.html

http://groups.google.com/group/tiddlywikidev/browse_thread/thread/4974fa9717f669ab

Holger (of py.test fame) was interested in this technique, so I posted my experience to the py-dev mailing list — which I figured was worth copying here:

The goal is to use a common package name (here: “foo”) for multiple independent modules or packages (“alpha” and “bravo” – to be accessed as foo.alpha and foo.bravo, respectively).

It’s actually rather simple:
The individual components must be contained in a directory named after the virtual namespace, with an __init__.py containing nothing but the following statement:
__import__("pkg_resources").declare_namespace(__name__)
To make Python aware of the local package (e.g. for running tests out of the repository), something like the following is required in a root-level __init__.py:
path = os.path.abspath(VIRTUAL_NAMESPACE)
sys.modules[VIRTUAL_NAMESPACE].__dict__["__path__"].insert(0, path)
This is illustrated here:
http://gist.github.com/231862

Disclaimer: I’m far from being an expert, just sharing what we’ve learned so far (it’s an ongoing effort).

While there are other options, this currently appears to be the most compatible approach (as confirmed by Tarek).

Update: Some further insights made me tweak the approach to module-path mangling.

Over the course of several discussions with Mike, we’ve come up with some simple idioms which we hope will make our code a little prettier:

var entries = ["foo", "bar", "baz"];

$("<ul />").
	append($.map(entries, function(item, i) {
		return $("<li />").text(item)[0];
	})).
	appendTo(container);

$.fn.create = function(html) {
	return this.append(html).children(":last");
};

$("<div />").
	create("<h2 />").addClass(className).text(heading).end().
	create("<p />").text(body).end().
	appendTo(container);

I’ve created a simple demo page (source) to better illustrate and explain this new approach, contrasting it with my previous code.

While I’m sure this sort of thing has been done before, it doesn’t seem to be common knowledge — at least nobody in the jQuery IRC channel had any ideas when I first asked.

Any comments (including YDICW, if necessary) would be appreciated.

• programming languages do matter; choice can hugely affect the end result
• whitespace enforcement the “best worst feature” (other languages’ worst features are much more severe)
• Unicode handling is a pain
• lambdas
  • should just be called functions (increases acceptance)
  • cannot contain statements
  • binding issues in loops
• threading is haphazard (GIL is evil) — however: CPython implementation issue, addressed in v2.6 – “it’s different, not necessarily insufficient (e.g. using underlying OS)”
• confusing packaging situation (setuptools, Easy Install, distutils, eggs, buildout, PyPI, virtualenv) – “solved, but people disagree” – “Easy Install sucks, too magic” – “not a Python-specific, but OS-level task” – problem is hard to solve, as there’s a variety of different usage scenarios
• infinity, NaN support (IEEE 754)
• floating point printing (0.1 becomes 0.10000000000000001) — fixed in v3.1
• division — fixed in v3.0
• decorators (“@ is scary, unfamiliar syntax”)
• argument list splicing (e.g. zip(*l)) – “unfamiliar syntax”
• some modules only exist on certain platforms
• positive aspects
  • everything is an object
  • object instantiation (no new keyword – i.e. just like calling a function)
  • generator expressions (from Haskell)
  • chained comparisons (0 < = x < n) - though largely unknown, and allows 0 < x > a or 0 < x in L
  • Iverson’s convention (x < y evaluates to 0/False or 1/True) - "open to abuse"
  • access control (public, private etc.) – not enforced (“advisory [bicycle] locks”) – likely more a social than a technical problem
  • fractions (from v2.6)
  • power (x**2)
  • explicit > implicit (unlike this in JavaScript, for example)
• “Python sucks because sometimes it has to run on Windows”

slides available

Obviously some points were quite controversial (whitespace FTW!) – which is what made the session so interesting.

1. retitled What Sucks About Python in the official program

• minimal, no-API approach; no need for boilerplates
  however, a lot of optional framework-y functionality is provided
• convention over configuration (automatic discovery of test_*.py, def test_*, class Test*)
• py.test overrides AssertionError built-in, then re-runs statement to provide details — avoid assertions with side-effects!
• skip tests only for platform and dependency issues; use @py.test.mark.xfail for “expected to fail”
• funcargs introduced in v1.0 to replace traditional setup methods for fixtures (user & provider, loose coupling); allows for more flexible grouping
• print captured by default, only shown on failure
• internally makes use of its own hook architecture (i.e. many features implemented as plugins)
• yielded tests are deprecated (due to internal ambiguity); recommended to use pytest_generate_tests instead
• interesting plugins: coverage and PyLint integration
• can be used to run non-Python tests (e.g. for JavaScript)
• supports distributed testing (load balancing with multiple CPUs or remote machines, testing on multiple platforms)
• might be renamed (“I wish I’d named it differently”)

Holger Krekel has also published his slides (PDF), which are well worth a look.

While I still don’t consider myself an expert – especially when it comes to truly distributed collaboration – I did manage to pass on some basic knowledge to those around me just getting started.

In the process I came up with a very concise introduction – and even though it’s almost trivial, the following illustration of the basic workflow might be worth sharing (ASCII art ahead):

                                                       repository (remote)
                                                            ^      |
                                                            |      |
                                                           push   pull
                                                            |      |
                                                            |      V
working copy --add--> index (staging area) --commit--> repository (local)
               \                                  /
                \------------commit -a-----------/

Useful Commands:

• status
• log [-p] [--stat]
• diff [-w] [--color-words]
• checkout <treeish> <file> (reverting)
• init
• clone

My configuration is available on GitHub – this might serve as a reference for further exploration (e.g. aliases).

• name
  When asked about about the name (which had confused us), humorously dodged the question multiple times. Not entirely sure why…
• reinventing the wheel
  Bespin makes heavy use of canvas, essentially reinventing the rendering of text and layout (using their Thunderhead toolkit).
  While contentious with regards to accessibility and web standards, this is necessary due to performance reasons.
  (Note: Not JavaScript is the bottleneck here, but the DOM is.)
• offline capability
  Currently Bespin should be considered a “hosted application”, requiring a server-side component.
  Personally, I don’t like the idea of relying on the “cloud” for my primary editor.
  While the Bespin team is planning to use Titanium eventually, Joe said it shouldn’t be too hard to integrate TiddlyWiki‘s file-saving code (similar to the XWiki integration), essentially creating a stand-alone HTML application.
• tools integration
  Since Bespin runs in the browser, it might be hard to integrate external tools (e.g. PyLint).
  I’m concerned that this might mean the respective server must support such applications, stripping away another bit of developer independence…
• active community
  There’s already an active community of hackers making use of and contributing to the project.
  (We’re also considering using Bespin as a front-end for TiddlyWeb.)
• Ubiquity as Firefox extension API
  On a slightly unrelated note, it has been suggested that Ubiquity might be integrated into Firefox, which in turn could lead to a pure-JavaScript API for extensions (currently writing Firefox extensions involves a lot of overhead, e.g. creating XML documents). That would of course be most welcome!

• XNA (Microsoft’s game development toolkit for Windows and Xbox 360) live demo was fun, and it seemed fairly easy to get started
• Python is suitable for game development (e.g. OpenGL with pyglet), though with obvious performance limitations
• Agile methodologies would be even more suitable in game development than in traditional IT, but apathy and lacking/flawed feedback loops (publishers and retailers are harmful intermediaries) seem to prevent widespread adoption^[1]
• Open Source is mostly shunned in game development, often due to apathy and ignorance (there are a few positive examples though, like Lua); extreme short-term thinking prevents the realization of FOSS’s long-term benefits; standardization is actively subverted by platform vendors^[2]
• my overall impression is that the gaming industry is pretty messed up, largely because it’s dominated by vendors rather than consumer interests

1. apparently, the gaming industry doesn’t perceive itself as part of the IT industry – while it sits somewhere between traditional IT and the movie/entertainment business, it tends to prefer the latter (which is also reflected in the semantics, e.g. “game studio”)
2. instead of licensing game engines (e.g. Epic Games’ Unreal Engine), why are there no collaborative development efforts – similar to the way Apache now provides a superior alternative to IIS

The uncompressed source is available on GitHub (also for my previous TinyURL bookmarklet).

1. I’d be happy for him to merge these changes back into WTFramework, thus rendering this fork obsolete
2. created using Bookmarklet Builder