大高雄Linux使用者協會

mako template是我除了django預設的template之外，
唯一真的有在product上使用過的template，
mako對於我來說的優點是其簡單非XML的語法，
此外mako無需任何C/pyrex extension，屬於純python的實作，
非常適合在無需django及host上沒有C compiler時單獨安裝。

現在有網友替mako template做了一個django-mako的plugin，
使用mako跟django整合又更容易了。

連結:
mako:
http://www.makotemplates.org/ (LICENSE: MIT)

django-mako:
http://code.google.com/p/django-mako/ (LICENSE: apache 2.0)

distutils跟setuptools有些什麼什麼好又有些什麼什麼不好,
其實不少python使用者是心知肚明的,
不過一般來說python programmer除了喜歡pythonic之外,
發佈套件也通常都會遵守發佈python package的標準格式,
發佈setuptools的eggs跟distutils的source tarball
雖然每個python user遵循標準程序的原因未必相同,
不過這似乎已是一種不得不的慣例.

最近在distutils跟setuptools之外出現了新選擇:
Tarek Ziadé的distribute跟Ian Bicking的pyinstall

比較完整也比較吸引我眼球的是Ian Bicking的pyinstall,
一來Ian Bicking的東西向來簡單好用,
二來pyinstall的確解決了一些煩雜的問題,
三來Ian Bicking的社群影響力較大,成為新標準的可能性極高.

pyinstall大致相容於setuptools的easy_install並且提供了一些新的功能跟補強,
我自己認為pyinstall最重要的東西,
是在unix上提供了一個足以取代egg格式的新格式: bundle,
bundle格式有兩個我認為很重要的特點:
第一個就是dependencies include,所有相依的套件全都被放在同一個bundle檔案裡.
第二個是source based.
bundle有點像是一整個相依的freebsd ports或gentoo
ebuild加上其distfiles集合在一起的source整合格式,
所有的source跟編譯及安裝規則都放在同一個檔案裏面,在安裝的同時才進行編譯(.pyc and .so)
所以不像binary格式的eggs需要依版本分2.4的eggs跟2.5的eggs,只要下載同一個檔案就可以安裝了.
當然source based distro/package system的好壞見仁見智, 也會有些限制.
不過至少編譯時間過久這個缺點對於python來講應該是不存在的.
因為大部分的python packages依靠c的部份不多, 另外產生.pyc檔也並不會太慢.

此外pyinstall除了支援同一作者的virtualenv外,
對於整個python環境也有提出了一個解決方法 -- Requirements
事實上對於easy_install base安裝的工具最害怕的就是: 下一次裝不知道其相依的套件還會不會是相同版本.
因為安裝最新版未必是我們最希望的事情, 因為很有可能最新版將我們需要的功能給改變了,我會比較希望能夠有一個版本的控制
Requirements不僅可以由撰寫Requirements file來限制整個相依性的版本,
還可以用pyinstall.py --freeze=require.txt的方法,將整個開發環境的所有python版本套件版號都紀錄下來
方便你移到所以需要新安裝的機器上. 如果再結合上bundle, 幾乎就是非常完美的佈署方案.

pyinstall目前只有0.1.1版, 而且似乎還會有更多加強, 不過我認為這個工具的方便性跟應用的潛力非常大, 值得作個推荐.

更詳細的資訊請參考:

pyinstall:
http://www.openplans.org/projects/topp-engineering/blog/2008/09/24/pyinstall-a-new-hope/
http://pypi.python.org/pypi/pyinstall

distribute:
http://tarekziade.wordpress.com/2008/09/24/distribute-a-setuptools-fork/
http://mail.python.org/pipermail/distutils-sig/2008-September/010031.html
http://bazaar.launchpad.net/~tziade/distribute/trunk/files

http://www.djangoproject.com/weblog/2008/sep/03/1/

Django 1.0 released！

1.0是Django project一個很重要的里程碑，因為一直以來官方對於Django 1.0有個很重要的承諾，就是在1.0之後的所有版本都將維持向前相容性，就是不論是到1.x多少版，都將維持對1.0版本程式的相容性而不會再作任何會打破相容性的重大變動。這也是為什麼1.0版本會遲遲不推出的原因。

不過1.0 release的這一天終於來了，
根據Django官方網頁的說法，自從上一個穩定版Django 0.96.2以來，到這次的1.0版本發佈，已經有超過三十五萬行的Django程式碼被修正或改變，足見改變之大。(改動350000行的python, orz)

這次總算是讓我可以使用Django的新版本了，畢竟用了0.95.x跟0.96.x實在是很久了，而Django的SVN trunk對於真的要上線的系統畢竟還是個比較危險的使用方式。不過美中不足的是debian lenny似乎還是會來不及將Django 1.0包進debian linux系統，看來以後安裝上線系統又要多費一番功夫。

想知道更詳細的改變內容跟新增功能請看Django 1.0 release notes

Today I want to port lighttpd on another platform which basically a debian sarge system but without perl and dpkg package system on it. Since it's a debian based platform so I start from porting debian's binary lighttpd package, however I've found there're some perl script lays in /usr/share/lighttpd which are used when lighttpd startup.

While I can easily dump the result of perl script into a textfile,
and then startup my lighttpd correctly, I thought "maybe port it to python is not a bad idea." (since my target platform has python!), so here is the effort:
create-mime.assign.py

#!/usr/bin/python
#
# This script directly translate from debian's lighttpd perl script:
# create-mime.assign.pl
#
# Author: timchen119.at.nospam.gmail.com
# License: Public Domain
#
import sys

try:
 f = open("/etc/mime.types",'r')
 extensions = {}
 print "mimetype.assign = ("
 for line in f:
     line = line.strip()
     if line.startswith('#'): continue
     if line != "":
         splitlist = line.split()
         if len(splitlist) < 2: continue
         mime = splitlist[0]
         for ext in splitlist[1:]:
             if ext in extensions.keys(): continue
             extensions[ext] = 1
             print '".%s" => "%s",' % (ext,mime)
 f.close()
 print ")"
except Exception,e:
 print e
 sys.exit(1)

include-conf-enabled.py

#!/usr/bin/python
#
# This script directly translate from debian's lighttpd perl script:
# include-conf-enabled.pl
#
# Author: timchen119.at.nospam.gmail.com
# License: Public Domain
#

import os,glob

confdir = "/etc/lighttpd/"
enabled = "conf-enabled/*.conf"

os.chdir(confdir)

for file in sorted(glob.glob(enabled)):
 print 'include "%s"' % file

use-ipv6.py

#!/usr/bin/python
#
# This script directly translate from ubuntu's lighttpd perl script:
# use-ipv6.pl
#
# Author: timchen119.at.nospam.gmail.com
# License: Public Domain
#

import socket

##this sometimes not accurate. (like in vserver mode)
#if socket.has_ipv6:
#

try:
 if socket.socket(socket.AF_INET6,socket.SOCK_STREAM,0):
     print 'server.use-ipv6 = "enable"'
except:
 pass

All of these files can be found in http://kalug.linux.org.tw/~tim/lighttpd-debian-python-script/
Well something quite interesting happened when I port the debian's create-mime.assign.pl into python, It's that my python script's final result is not equivalent to perl one and has more mime types than its :

--- perlmime.txt    2008-07-14 15:29:23.000000000 +0800
+++ pymime.txt    2008-07-14 15:29:33.000000000 +0800
@@ -114,6 +114,11 @@
".dvi" => "application/x-dvi",
".rhtml" => "application/x-httpd-eruby",
".flac" => "application/x-flac",
+".pfa" => "application/x-font",
+".pfb" => "application/x-font",
+".gsf" => "application/x-font",
+".pcf" => "application/x-font",
+".pcf.Z" => "application/x-font",
".mm" => "application/x-freemind",
".gnumeric" => "application/x-gnumeric",
".sgf" => "application/x-go-sgf",
@@ -193,6 +198,11 @@
".pk" => "application/x-tex-pk",
".texinfo" => "application/x-texinfo",
".texi" => "application/x-texinfo",
+".~" => "application/x-trash",
+".%" => "application/x-trash",
+".bak" => "application/x-trash",
+".old" => "application/x-trash",
+".sik" => "application/x-trash",
".t" => "application/x-troff",
".tr" => "application/x-troff",
".roff" => "application/x-troff",
@@ -282,6 +292,7 @@
".tgf" => "chemical/x-mdl-tgf",
".mcif" => "chemical/x-mmcif",
".mol2" => "chemical/x-mol2",
+".b" => "chemical/x-molconn-Z",
".gpt" => "chemical/x-mopac-graph",
".mop" => "chemical/x-mopac-input",
".mopcrt" => "chemical/x-mopac-input",

So I start to dig why this happened, and I've found a strange perl regex filter all these mimetypes out, I believe it's a minor bug in original perl program. (or it does implicitly doing something meaningful? well I can't figure it out.)

--- create-mime.assign.pl    2008-07-14 15:35:58.000000000 +0800
+++ create-mime.assign.pl.new    2008-07-14 15:36:07.000000000 +0800
@@ -7,7 +7,7 @@
chomp;
s/\#.*//;
next if /^\w*$/;
-  if(/^([a-z0-9\/+-.]+)\s+((?:[a-z0-9.+-]+[ ]?)+)$/) {
+  if(/^([A-Za-z0-9\/+-.~%]+)\s+((?:[A-Za-z0-9.+-~%]+[ ]?)+)$/) {
  foreach(split / /, $2) {
    # mime.types can have same extension for different
    # mime types

replace this line and this will produce same results as mine.

usage:
just copy these py scripts to /usr/share/lighttpd
and change these lines if you're using debian based system

#### external configuration files
## mimetype mapping
#include_shell "/usr/share/lighttpd/create-mime.assign.pl"
include_shell "/usr/share/lighttpd/create-mime.assign.py"

## load enabled configuration files,
## read /etc/lighttpd/conf-available/README first
#include_shell "/usr/share/lighttpd/include-conf-enabled.pl"
include_shell "/usr/share/lighttpd/include-conf-enabled.py"

根據這篇Roadmap的說法, Django 1.0 會在7月alpha, 8月rc, 9月release. 雖然不知道到底準不準時, 但是"準備好了就會出來"這種話我已經聽膩了... XD

http://metajack.wordpress.com/2008/06/11/the-problem-with-django/

基本上我還滿贊同這篇文章的觀點,
事實上我甚至覺得大部分正在開發中的軟體專案都應該建立一個以時程為主的release週期, (即regular release)
而非是現在主要是以功能完成度為主的週期.
因為開發者通常都過於樂觀還有自信太強,
常常低估了完成軟體的時間, 對於沒做過的功能不管聽起來再怎麼簡單都最好還是保守點比較好,
像django的1.0也實在是拖太久了 難怪ticket#2070會被拿出來鞭... 一個http streaming upload 的patch前前後後改了兩年多還是沒進trunk...真不知道是該說追求完美還是太龜毛了... :(

像Ubuntu這樣的release週期我就覺得滿不錯的, 儘管每次的新版變動不會太大, 然後或多或少都會有bug, 但是至少是在建立一個正向循環並且能鼓勵新的開發者投入.

當然還是要說Django真的很不錯就是了. :)

有時候程式設計師總是會有點奇怪的潔癖,
例如這個讀設定檔的module就是這一類的產物,
說真的python有內建csv,ini跟xml之類的parser,
3rd party的parser也到處都是, 特定情況下其實execfile,exec,eval也都沒什麼錯,如果設定檔可以用.py結尾, 直接import 就可以了,再加上其實python 2.6就要支援direct modify ast tree了...實在看不出有什麼必要硬要用python的parser來讀進設定檔,不過話說回來如果只是想要安全的從檔案裡取出一個dictionary,這個小巧的module倒也不失為一個好方法.

# -*- coding: utf-8 -*-
#!/usr/bin/env python
"""
    safe_dict
    ~~~
    The `safe_dict` module helps you read a dictionary from a file using python syntax.
       
    The key and values in dictionary are string only.
    
    File `dict.file` (file which we read dict from) should only contain an anonymous dictionary.
    
    Support only Python 2.5+.
    
    reference:
        http://docs.python.org/dev/library/_ast
        http://dev.pocoo.org/hg/sandbox/file/08541da989dd/ast/ast.py
        http://pyside.blogspot.com/2008/03/ast-compilation-from-python.html
    ~~~
    :Author: http://timchen119.blogspot.com
    :license: Python License
"""

from __future__ import with_statement
import _ast 
#need python 2.5+

def safe_eval_literal(node_or_string):
    """
    Safe evaluate a literal.
    """
    _safe_names = {'None': None, 'True': True, 'False': False}
    if isinstance(node_or_string, basestring):
        node_or_string = compile(node_or_string, "<unknown>", "eval" , _ast.PyCF_ONLY_AST)
    if isinstance(node_or_string, _ast.Expression):
        node_or_string = node_or_string.body