如果高中棒球社女經理讀過使徒提姆的部落格~~

她就會馬上開始學Python......也許吧? :P

據說"如果高中棒球社女經理讀過杜拉克的管理學"是前陣子日本暢銷書排行榜排名第一名,

既然管理學可以,Python應該也可以吧, "import 管理學"什麼的我們Python應該也有吧?

嗯嗯 是不是乾脆把我的部落格名稱也改一改~~ 之後就可能會突然爆紅也不一定? XD

==

老實說像我這麼發懶的部落格作者,

是根本不奢望會有讀者的,

說來說去這部落格不過就是個一時自娛娛人的消遣跟筆記罷了,

但是即使如此,

突然發現部落格去年居然只更新兩格,

也是有種感受到被歲月的巨輪無情的從身上碾過的感覺~~

"啊啊啊~~ 老的無話可說了嗎?"

"好歹出來寫篇Python真是太讚了 然後出來喊個兩聲表示還活著也好吧?"

"連廢文都沒有了嗎?"

==

不然就把這一篇改成2011年我們來學Python好了~~

反正從一起頭這篇就註定是個廢文不如就這樣廢下去好了~~

所以從現在開始就把這格的主題定調為 "2011大家學python" 好了~~

(咦 高中棒球社女經理到哪去了? 真是隨便啊! 還有學PYTHON根本就不廢啊!!! ~~ )

啊啊不管了~~ 事實上啊~~ 嚴肅的看待"學python"這件事本身就是很奇怪的一件事~~

好像非得拿本書認真的讀完Python語法才叫在學~~

這樣一點都不對啊~~ Python不是這樣學的~~ 學Python應該是要很愉快的啊!

這就好像教完所有文法再開始叫你講英語一樣來學英語~~

因為一點用也沒有所以一點也不愉快~~

你如果要當Python特許教師也許可以這麼學~~ (不過... 有這種職業嗎?...)

但是正常人不應該是這樣學的~~

很好~~ 既然你都看我的廢話看到這邊了~~

(真是驚人的毅力啊~~ 你完全有成功人士的資質啊!!!)

看來你就是"2011大家學python"這格廢文的目標讀者群~~

我就特別對待你~~


教你史上最快學習Python的方法~~


絕對保證你聽也沒聽過~~

~~ ~~ ~~

因為我也是隨便講講的!!!

(什麼,,,不想學了? 我偏偏就想教啦, 就跟你說我這格是老人湊字數的你到現在還聽不懂喔?
你就完成一個孤單寂寞老人的心願這樣也不行喔? 你你你~~~
)

對~~~ 就是你 ~~~

不管了~~~ 聽我說第一步~~

聽清楚了喔~~

就是先把你手上的什麼XXX Python 然後封面還有動物樣子的書先放下...

(疑這個捏他太深奧了嗎? 啊啊啊 等一下會不會接到書商打電話來抗議啊? 反正他們應該早就賣不好了應該沒什麼差吧 點點點)

別人怎麼教你的我不管~~ 既然你上了我們Python神教的好船~~

我們就不會眼睜睜的看你沉入書海~~

這年頭也不知道吹什麼風 Programmer家裡的書櫃都快變成動物圖鑒了~~

我們是來學寫程式的不是來當圖書館還是動物園管理員的~~

好了我廢話真多 (真是極度自覺啊!)

再來再來

開始第二個心法~~

那就是~~

抄

疑? ㄟㄟㄟ???

怎麼可以呢 從小到大我們的尊敬的老師父母兄弟姐妹親朋好友阿公阿媽還有隔壁班的阿花都跟我們說這樣是不行的啊~~~

俗話說的好~~ 天下文章一大抄~~

程式碼~~ 更是要抄~~

熟讀唐詩三百首~~ 不會作詩也會吟~~

抄太難聽的話 就改成謄~~

就是像打開習字帖, 然後像永字八法般的練法~~

打開你的編輯器 找個有興趣的程式 把別人的程式碼抓過來 開始改~~

看不懂的就查 查不到的就想 想不出的就問 問不到的就再認真看認真查認真問~~

反正你已經閒到在看我的文章 肯定是很閒的 不如就認真點抄...

光明正大的抄 快樂的寫寫寫~~

就把他當作是老師全班只准你一個人openbook的去考試吧! (這真是太爽了 乖小孩不要學)

~~

再來再來就是要登堂入室了~~

這就不能只是抄了~~

基本上你抄久了 大概也已經到了不用參考別人的程式 就可以自己動手從無到有開始寫的境界了~~

這個時候就可以開始看書看文章,寫自己喜歡的程式~~

之後再學些別的東西讀點不相關的東西跟學些其他自己感興趣的程式語言都有所幫助~~

總之就是個落花流水皆文章的階段~~

等到了這個階段開始也就可以開個部落格寫些廢文騙個字數了 (疑??? 幹嘛又自婊???)

===

"""
廢話真的是很多 而且為什麼總共只寫了三步啊!!! 而且第三步分明就是在騙字數啊~~

什麼因為寫太多廢話連自己都覺得煩了??? 這什麼理由到底負不負責任啊~~

責任編輯到底是誰啊~~ 這麼廢的文章也敢PO出來喔~~
"""

以上是來自某讀者內心的OS,

可是本格宗旨就是插科打渾的未必就是胡言亂語,

語重心長的也未必就是真知灼見,

總而言之就是力求一種精神錯亂的頹廢美學~~

反正網路流行騎牆派 哪裡鄉民多 哪裡就有真理

我們廢話黨是不在乎的~~ (那來的廢話黨你不是Python教的嗎?)

總之一個人神智錯亂的時候 廢話都很多 尼采不也整天嚷嚷的說什麼超人來了嗎?

好歹我也沒寫什麼什麼什麼如是說的寫了一大本~~ 頂多只是幻想著高中棒球社女經理會讀一下我的部落格而已~~

啊 經理 對不起我是個阿宅~~ 我還有二次元complex 沒藥醫的!

====

總而言之 2011年我終於有了我的第一格! (真是個明智的收尾)

而且除了Python很讚這種廢話我還真的吐不出什麼象牙~~

說到底TIOBE都已經衝到第六五名的這種Python程式語言還有什麼好廣告的?

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

到現在還不知道Python的優點還只記得Python的缺點分明就是你的問題~~

你不來用是你賠又不是我賺~~ 我一點都沒有成就感啊~~

嗯嗯 我再小神晶下去應該有讀者要發飆了 (疑? 真的有讀者啊? 你們辛苦了...)

再次廣告一下我部落格的右下角有著"本站文章自High居多, 請勿嚴肅看待"的標語

這不是寫著玩的 因為我純粹是自HIGH自爽~~

你們萬一讀了心跳加速~~ 人家我也是不負責的唷(心)....

===

嗯嗯~~ 咳咳~~

感謝各位的收看 咱們2012見... (疑!!!!??? 這個人都懶到有自覺了啊~~ )

啊對了

如果你真的是高中棒球社女經理 其實我們聊些別的也可以~~ (傻笑~~ 被打飛~~)

===

(完)

[tips] python2與python 3的list comprehensions之差異

剛好看到這篇
http://yz.mit.edu/wp/2010/01/14/bitten-by-python-scoping/
想起之前也有遇到類似的問題~

其實主要就是python2的list comprehensions有個副作用,
就是會重設scope內的變數, 比如以下這個程式

def t1(): 
    x=5
    [0 for x in [1,2,3]]
    print x

t1() 

3

這邊的x會被重設為3, 有點像是殘餘的loop變數的感覺~
有些人會玩弄這個副作用來達到一些不想讓人看懂的lambda技巧就是了:P

但相對來說後來引進的generator語法就沒有這個問題, 所以這個問題其實也可以使用list(x for x in [1,2,3])這個方法來解決.

def ts2():
    x=5
    list(x for x in [1,2,3])
    print x

ts2()

5

另外也可以置換變數比如改成使用a來取代x(當然a是會被assigned).

當然還有另外一個方法則是使用python 3, 就完全沒有這個問題了 :D

[tips] crc32 in python

python 2.X的crc32實作上跟一般的C實作上在整數有號無號的處理上略有不同, 所以使用python 2.X與一般C實作算出的crc32(如sfv)比對時,通常需要特別的方法,

這邊列出一個透過zlib.crc32快速得到所需要結果的方法：

import zlib

def crc32(st):
    crc = zlib.crc32(st)
    if crc > 0:
      return "%x" % (crc)
    else:
      return "%x" % (~crc ^ 0xffffffff)

ex1 = "12345"
ex2 = "1kcaseztsa12345azy"

print "%x" % zlib.crc32(ex1)
print crc32(ex1)
print "%x" % zlib.crc32(ex2)
print crc32(ex2)

或如果你有ctypes的話:

import zlib
import ctypes

def crc32_c(st):
    return "%x" % ctypes.c_uint32(zlib.crc32(st)).value

ex1 = "12345"
ex2 = "1kcaseztsa12345azy"

print "%x" % zlib.crc32(ex1)
print crc32_c(ex1)
print "%x" % zlib.crc32(ex2)
print crc32_c(ex2)

註： python 3.0以上沒有這個問題.

不縮排就搗蛋!

louis今天跟我討論XPCOM文件上這一段應該是要很簡單的C++ snippet,

基本上我XPCOM不熟, C++尚可,

拿來文件上的Code大概長的像這樣:

NS_IMETHODIMP SampleFactory::QueryInterface(const nsIID &aIID,void **aResult)
{
    if (aResult == NULL) {
    return NS_ERROR_NULL_POINTER;
    }
    *aResult = NULL;
    if (aIID.Equals(kISupportsIID)) {
    *aResult = (void *) this;
    }
    else
    if (aIID.Equals(kIFactoryIID)) {
    *aResult = (void *) this;
    }
    if (aResult != NULL) {
    return NS_ERROR_NO_INTERFACE;
    }
    AddRef();
    return NS_OK;
}

看來看去實在是讓我皺眉頭...

哪有aResult等於NULL也return

不等於NULL也return

然後return完後面還有code的道理

反正這code看起來就是怪怪的, 但一下子卻看不出怪在哪...

因為...

...

這沒縮排又排的亂七八糟的code我是要怎麼讀啦!!!???

...

反正就是看的很難過 有股想把code拿去倒掉的衝動

後來才發現真正的文件裡長的是這樣:

NS_IMETHODIMP
SampleFactory::QueryInterface(const nsIID &aIID,
                              void **aResult)
{
  if (aResult == NULL) {
    return NS_ERROR_NULL_POINTER;
  }
  *aResult = NULL;
  if (aIID.Equals(kISupportsIID)) {
    *aResult = (void *) this;
  }
  else if (aIID.Equals(kIFactoryIID)) {
    *aResult = (void *) this;
  }

  if (*aResult == NULL) {
    return NS_ERROR_NO_INTERFACE;
  }
  AddRef();
  return NS_OK;
}

我咧 這一縮排 會不會感覺差太多

連這段code snippet不用註解 要表達什麼都能看的清清楚楚.

雖然我不是很熟XPCOM, 也清楚看的出:

1. 在aIID是SupportsIID或FactoryIID的情況下

*aResult不會是NULL 而如果不是SupportsIID或FactoryIID就該回傳NS_ERROR_NO_INTERFACE;

2. 原先的code把倒數第六行if (*aResult == NULL)誤值成if (aResult == NULL) 是錯的...

跟之前不知在寫什麼時不同, 馬上就看出問題點在哪...

==

我還是常聽到有人說什麼python強制縮排怎樣怎樣的...

我只想說,

人要衣裝

佛要金裝

Code要給我排整齊啦!

[tips] 針對特定model改變django ORM預設delete()行為的方法

Django ORM裡的預設delete行為是去模擬ON DELETE CASCADE, 主要是為了保證資料的一致性, 但是雖然在自帶的admin介面裡會提示是否要刪除其他相關聯的資料, 不過仍然可能會對某些需求帶來一些困擾, 而且到目前為止並沒有一個標準的方法來更改這個機制, 這邊我提供一個簡單的方法將model的ON DELETE CASCADE行為改為RESTRICT, 就是在需要不同機制的model裡去override orm原本的delete行為 :

 
    def delete(self):
        s = CollectedObjects()
        self._collect_sub_objects(s)
        if len(s.items()) == 1:
            super(self.__class__, self).delete()
        else:
            pass

這可確保當沒有任何關聯物件時才會刪除, 否則只會安靜的pass,
this hack probably need django 1.0+.

[link] django-mako

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)

挺不錯的pyinstall

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

Django 1.0 released !!

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

[tips] rewrite debian/ubuntu 's lighttpd conf script from perl to python

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"

[link] 有吵有糖吃... Django 1.0 is coming...

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

[link] django's problem.

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真的很不錯就是了. :)

[tips] evaluate python dictionaries from file safely.

有時候程式設計師總是會有點奇怪的潔癖,
例如這個讀設定檔的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
    def _convert(node):
        if isinstance(node, _ast.Str):
            return node.s
        elif isinstance(node, _ast.Dict):
            return dict((_convert(k), _convert(v)) for k, v
                        in zip(node.keys, node.values))
        elif isinstance(node, _ast.Name):
            if node.id in _safe_names:
                return _safe_names[node.id] 
        raise ValueError('malformed string')
    return _convert(node_or_string)
    

def safe_read_dict_from(file):    
    """
    Safe evaluate a dictionary from a file.
    """
    try:        
        with open(file,'r') as f:
            source = f.read()
            node = compile(source, "<unknown>", "eval", _ast.PyCF_ONLY_AST)

            if isinstance(node.body, _ast.Dict):
                return safe_eval_literal(node.body)
            else:
                raise
    except:
        raise
    
if __name__ == '__main__':
    try:
        dict_we_want = safe_read_dict_from('dict.file')
    except Exception,e:
        print e 

用法: 只要在你的dict.file裡加上一個python dictionary即可, 就可以用這個module讀入dict.file,為了安全性考量,也只讀入字串.

[tips] add bzr sftp support when you have no compiler on target platform (pure python )

bzr depends on paramiko to provide sftp support. While paramiko itself is pure python, its dependency pycrypto is not. PyCrypto have lots of C-extenstion and you'll need a compiler to install it. However since we only use part of pycrypto (to have sftp support for bzr), we could just add some stub files to prevent the [deploy] problem.

I have made a modified pure python version pycrypto and packaged it with paramiko 1.7.3, so after you installed bzr (use standard python setup.py or easy_install), you just extract paramiko-1.7.3-bzr-sftp-purepy.tgz
at your python site-package directory (make sure you don't have paramiko and pycrypto already exists, if you do, you don't need to install this package anyway) and happy bzr...!

This also makes bzr only depend on python so you could easily deploy it on a machine which doesn't have c compiler and still have sftp support.

Warning: this pacakage only add bzr sftp support and provides nothing besides this, and these COULD break other python packages which also used paramiko and pycrypto, so don't use it if you don't really need it. And the only tests I've done is on my own (embedded linux) machine, Basically it's just for my own use, I have warned you.

[funny] [links] [kuso] Python がイマイチ人気にならないたった一つの理由

http://d.hatena.ne.jp/seiunsky/20080417/1208454191

話說不小心點到這... 原本還想認真看看理由的... 結果... @@


1. 日本Python的入門書不好 !?


* 「最初（に読むPython本）はみんPyだよねー」

==> 「最初はみんなおっぱいだいすきからスタートする」

2. 著名書商 O'reilly 也很糟糕 ?!


* 「おれ、今Pyチューで勉強してるんだ！」

==> こんなセリフを女子に聞かれたら間違いなく「おっぱいにチューして何の勉強をしているの！へんたい！」と思われるのですから、これは本当に卑猥ですね。

3. PyPy實作不好 !?

* 「おれ、いま PyPy の開発してるんだ！」
* 「ただの人間には興味ありません。PyPy 開発に興味のある人は私のところに来なさい！以上！」
* 「PyPyを高速で動かす方法を思いついた！」

接下來就開始把python跟おっぱい扯在一起的大爆走了 XD (pychinko, Dive Into Python... 原來Python是完全的成人向啊...orz)

[tips] using pyrex to do the argv[0] trick in linux using python.

A trick to rename python process in output of 'top' and 'ps'.

set_argv.c:

#include 
#include 
#include 

int get_argc(){
    int argc;
    char **argv;
    Py_GetArgcArgv(&argc, &argv);
    return argc;
}

void set_argv_via_number(int num,char *str){
    int argc;
    char **argv;
    Py_GetArgcArgv(&argc, &argv);
    strncpy(argv[num], str , strlen(str));
    memset(&argv[num][strlen(str)], '\0', strlen(&argv[num][strlen(str)]));
}


set_processname.pyx:

#Warning: this module is not safe and may involve some dirty hacks.
import sys,dl,glob
cdef extern int get_argc()
cdef extern void set_argv_via_number(int num,char *buf)
def set_argv0(thename):
    set_argv_via_number(0,thename)

def set_argv(thename):
    argc = get_argc()
    print argc
    for i in xrange(argc+1):
        if i==0:
            set_argv0(thename)
        else:
            pass
def set_name(thename):
    if sys.platform == 'linux2':
        # Set process name.  Only works on Linux >= 2.1.57.
        try:
            libc_loc = glob.glob("/lib/libc.so*")[0]
            libc = dl.open(libc_loc)
            libc.call('prctl', 15, thename, 0, 0, 0) # 15 is PR_SET_NAME
        except:
            pass    

def set_processname(thename):
    space_padding_num = len(sys.argv[0])-len(thename)
    if space_padding_num < 0:
        #thename is longer than original name
        newname = thename[:len(sys.argv[0])]
    else:
        #thename is shorter. add padding.
        newname = thename + " " * space_padding_num

    set_name(newname)
    set_argv(newname)

compile.sh:
#!/bin/sh
CC=mipsel-linux-gcc

pyrexc set_processname.pyx
$CC -c -fPIC -I/usr/include/python2.5/ set_argv.c
$CC -c -fPIC -I/usr/include/python2.5/ set_processname.c
$CC -shared set_argv.o set_processname.o -o set_processname.so

[tips] building psyco on non-x86 platform. (ie. linux mips little endian)

The trick is to build psyco in ivm mode. The mode slower than the native mode(ivm mode involves a prolog generated-vm, you guess), however it's the only way to compile psyco on non-x86 system. And cross-compiling with distutils is not a trivial stuff, so I just compile it directly.

mipsel-linux-gcc -pthread -fno-strict-aliasing -DNDEBUG -fPIC -DALL_STATIC=1 -Ic/ivm -I/usr/include/python2.5 -c c/psyco.c -o build/temp.linux-mipsel-2.5/c/psyco.o
mipsel-linux-gcc -pthread -fno-strict-aliasing -DNDEBUG -fPIC -DALL_STATIC=1 -Ic/ivm -I/usr/include/python2.5 -c c/platform.c -o build/temp.linux-mipsel-2.5/c/platform.o
mipsel-linux-gcc -pthread -shared build/temp.linux-i686-2.5/c/psyco.o build/temp.linux-mipsel-2.5/c/platform.o -L/usr/lib -lpython2.5 -o build/lib.linux-i686-2.5/psyco/_psyco.so

This generates the C-module extension, and just copy all of py files to correct path and enjoy psyco speed-up! (well, not quite a case for me. It just use way too much memory on our embedded system. But I think maybe it'll useful in other project.)

ps: I should mentioned that I'm doing this on a uclibc linux system.

[tips] if as a pure function in python

http://okmij.org/ftp/Scheme/if-function.txt

here is a trick that we could rewrite a customized not-a-special-form IF in python.

iftrick.py:

#!/usr/bin/env python
def func_true():
    print "true!"

def func_false():
    print "false!"

def my_if(my_cond,then_func,else_func):
    eval((then_func, else_func)[not my_cond].func_code,vars())

condition = True

my_if(condition,func_true,func_false)

condition = False

my_if(condition,func_true,func_false)

===
#python iftrick.py 
true!
false!

Python: programming language of 2007!

January Headline: TIOBE declares Python as programming language of 2007!

"""
Python has been declared as programming language of 2007. It was a close finish, but in the end Python appeared to have the largest increase in ratings in one year time (2.04%). There is no clear reason why Python made this huge jump in 2007. Last month Python surpassed Perl for the first time in history, which is an indication that Python has become the "de facto" glue language at system level. It is especially beloved by system administrators and build managers. Chances are high that Python's star will rise further in 2008, thanks to the upcoming release of Python 3.
"""

well, the reason is so obvious to me...it's all about gravity thingy ;)

python耶~~

今天同事跑來問我mips上有否uc版本的python,
一問之下原來是某版子的tv tuner附的sample application是日本人用python寫的, 沒python的話沒辦法試.
也剛剛好我也才剛編完mips uc版本的python 2.5.1沒多久,
所以就剛好直接拿過去用.
不過嚇我一跳,
以前都是得主動出擊之外還要忍受冷嘲熱諷,
這可是第一次有embedded業務上的code是要求"必須"有python的.
:D

新手: 你怎麼飛的??? 答: import antigravity

這句可能會成為Python Programmers的本月(年?)最經典.

此句的出典為本月在駭客圈裡非常知名但原本推崇perl語言的XKCD網站漫畫 (xkcd的作者昨天學了python, 注意看的話會發現Tooltip上還寫著Perl, I'm Leaving you.):




隨即有網友作了T-shirt:



加上 TIOBE Programming Community Index 的本月頭條: December Headline: Python surpasses Perl for the first time in history.
這個月似乎python推廣的好消息不斷. (或是perl ain't cool anymore?!)

所以,

下次記得老闆要叫你"""飛給他看"""的時候,

python可是連反重力模組都幫你寫好了.

;)