Posts tagged: PYTHON

Django Docs in Plucker format

Update: 2005-11-13: A lot has happened with Django in the past two weeks; here’s an updated Plucker version of the docs (337K) for the 74 people who downloaded the last one. To judge by the change in file sizes, Django is sixty-two percent more documented than before! Or somebody slipped one of Wilson’s desktop backgrounds in there. I’m just going to keep popping this post to the top when I have a new version, rather than allowing outdated stuff to sit around.
Update 2005-12-10: Posted a new version (375K). Someday I’ll make this a daily cronjob…
Update 2005-12-29: Updated again (398K).
Update 2006-11-16: Now (finally) a nightly cronjob – see the announcement post for more or just grab it now: http://dpaste.com/static/djangodocs.pdb

Original post, 2005-10-30: Along the lines of the Python Library Reference in Plucker format I posted in July, here’s the latest Django documentation (208KB). (Plucker is an offline reader for the Palm.) I know using a non-WiFi, non-cellphone PDA is terribly retro these days, but that’s the kind of old-world guy I am.

Ajaxy regex tester in Python: retest

Ajaxy regex tester in Python: retest

retest I wish I’d known about retest when I posted about regular expressions recently. It’s a great little utility from Christof Hoeke that uses Python’s re module and SimpleHTTPServer power to give you an interactive regex tester right in your web browser. He says he’s only tested it on Windows XP, but it worked great for me on OS X 10.4.3.


Brendon commented on Sun Feb 18 18:29:06 2007:

Another good Regular Expression tester to check out is ReJax:

Python question: a better urlparse?

Is there a more sophisticated equivalent of urlparse.urlparse() somewhere that knows enough to break out username and password components? Ideally it would return a dict, with keys like ‘scheme’ and ‘host’ and ‘user’, instead of a tuple. Something like PHP’s parse_url().


Paul Jimenez commented on Mon Dec 12 13:09:22 2005:

I wrote http://mail.python.org/pipermail/python-dev/2005-November/058301.html about urlparse being broken not too long ago, though I have yet to present my replacement. What kind of API do you think a better urlparse() should have? Keep in mind a good solution should deal with not only http://user:password@host:port/path?query#fragment, but also tel:1-234-567-8910 and news:newsgroup and news:msgid@newsgroup. I suspect the problem with a dict instead of a tuple is standardization of keys. Or maybe that’s fine. I’d be interested in your opinion.

A minimal wiki in Django

A minimal wiki in Django

TheWiki I built a proto-wiki in Django as an exercise for learning how to make a custom template filter. It’s absurdly easy, it turns out. Per the docs I added a templatetags module; here’s all the code in it – wikitags.py:

from django.core import template
register = template.Library()

@register.filter
def wikify(value):
    "Makes WikiWords"
    import re
    wikifier = re.compile(r'\b(([A-Z]+[a-z]+){2,})\b')
    return wikifier.sub(r'<a href="/\1/">\1</a>', value)

Then, in my page template:

{% load wikitags %}
<h1>{{ page.title }}</h1>
<div class="body">
    {{ page.content|wikify }}
</div>
...

I wrote about 60 lines of Python code in total. There are much smaller wiki engines, of course, but given the flexibility and expandability offered by Django I think that’s pretty good.

TurboGears progress, or, bring on the CRUD

A while back I posted a link-festooned introduction to TurboGears. In the last six weeks, there’s been evidence of a lot of progress; because TurboGears makes excellent use of already existing projects, it also benefits from the developer momentum in those projects.

Recently it looks like there’s been a special focus on adding CRUD (create, read, update, delete) functionality. At this point it’s pretty well known that this is a core strength of Django, and I think Django’s admin tools will probably remain the gold standard for a long time. As the TurboGears community ponders CRUD options, I wonder if the idea of adapting Django’s admin itself will come up. (Django is a BSD-licensed project, so there’s no licensing obstacle.) I don’t know enough about the differences between Django’s ORM and SQLObject to say whether this idea is feasible.