[tip] 使用yolk管理python套件.

yolk是一個可以查詢pypi套件及本機所安裝的python套件資訊的實用工具.

python自從這幾年引入setuptools,cheese shop等新技術之後,
安裝新套件變的相當容易.
大多時候我想新安裝套件除了透過作業系統的套件管理之外,
幾乎只要透過easy_install來安裝即可.
除了少部份仍未支援setuptools的pypi套件外,
大部份列在chesse shop裡的套件基本上都可以透過easy_install的方法安裝.

但是安裝變的容易了, setuptools裡卻沒有附上簡單的命令可以協助使用者管理套件,
包括版本的控管及升級, python套件安裝的數量等等資訊, 都要由系統管理者來自行紀錄.
實在不是一個很好的作法. 然而yolk這個好用的工具正可以填補這個缺陷,

首先當然是先安裝yolk, 最簡單的方法是用easy_install安裝.

easy_install -Z yolk

沒有easy_install這個程式的話 (會有人沒有裝嗎? @_@ )
則可以用你常用的套件管理程式安裝setuptools,
或請把下面的script抓下來並執行,就會安裝setuptools了:
http://peak.telecommunity.com/dist/ez_setup.py

(如果你跟我一樣也使用gentoo, 可以用overlay裡的pythonhead來安裝,
我建議你可以順便安裝g-pypi, 這是由同一作者所寫可以直接由pypi裡的套件產生ebuild的工具.
安裝g-pypi就會連yolk一起安裝了.)

幾個我常用的命令說明如下:
(請注意以下指的套件, 在python2.5之前是只限於用setuptools,easy_install安裝的python套件,
若使用python2.5+則是全部的套件都可以管理.)

yolk -l
列出這台機器所安裝的套件.
yolk -U
列出這台機器可以更新的套件及最新的版本.
yolk -F nose -T svn
將nose這個套件的最新svn版本抓下來放在./nose_svn
yolk -M nose
列出nose這個套件的meta資訊(版本,說明,版權等)
yolk -D ezpyinline
列出可以抓到ezpyinline這個套件的位址.
yolk -H nose
打開瀏覽器並連到nose這個套件的官方網站.

台灣opensource社群活動行事曆

YurenJu目前正在維護台灣OpenSource社群活動行事曆, 台灣各地其實到處都有各種開放原始碼的社群聚會, 只是有時這些活動的時間不大容易記住, 也很容易排定的時間上有所衝突, 有個可以一目瞭然的行事曆的確是好的多.

目前我已在維護的kalug及python星球上加入連結,
其他社群的朋友如果想加入到自己的網站上的話,
只要插入下面這一段HTML碼就可以了.

<div>
<iframe style=" border-width:0 " width="240"
frameborder="0"
src="http://www.google.com/calendar/embed?src=p09uh8cg4uvt2ij4obf45cltsk%40group.calendar.google.com&chrome=NONE&mode=AGENDA&hl=zh_TW&height=350"
height="350">
</iframe>
<a target="_blank"
href="http://www.google.com/calendar/render?cid=p09uh8cg4uvt2ij4obf45cltsk%40group.calendar.google.com">
<img border="0"
src="http://www.google.com/calendar/images/ext/gc_button1_en.gif"/></a>
</div>

另外yurenju也在號召有興趣共同參與更新行事曆的朋友, 如果您的組織有經常性的活動的話, 可以跟yurenju聯絡.

[rant] 三星硬碟三年保固.... 根本只是個噱頭....

只怪我當初沒做好功課, 兩年前被賣場的人唬了...

兩年多前對硬碟保固極度無知的我, 當時聽信賣場人員的SamSung硬碟堅持三年保固的說法,

傻傻的買了一顆80G的三星SitePoint硬碟給我老爸當主硬碟...想說可能比較有保障.

前幾天無預警掛了之後 就準備拿來去換顆"良品". 所以開始查說是在那邊維修.

根據我硬碟上的保固貼紙, 就去查到了建達國際的網站,

沒想到不查還好, 一查才發現.... 根本就是被騙了...

沒錯 是三年保固 不過不是免錢的保固,

買了硬碟30天過後, 硬碟壞了就不會換新品給你了, 就是換良品.

第一年過了之後即使在保固期內, 送修就開始要收費了,

那所謂三星的三年保固跟一年保固又有啥不同呢?

講難聽一點就是過了三年他連理都不理你了. 要送修? 直接買新品吧...

建達國際對於出貨只要滿一年的硬碟.....要收500元的手續費...

這手續費還真高. 也不會換個新品給你, 就是會換個良品(就是以前大概壞過被修好的吧)

那現在市場上主流根本也沒有在賣80G的IDE硬碟了,

想送修時順便換個大一點的硬碟的話,

這建達國際從80GB"升級"到250G 還要再加1500元...

然後呢 這保固期限也並沒有延長...

是"延續原送修硬碟之剩餘保限".... 我實在不明白這啥道理?

昏倒, 我重買一顆全新的 WD 250 GB, 7200rpm ,

8M緩衝的硬碟也不過2200多還有新的三年保固呢... 這擺明了不想讓你換.

唉 認栽了 買到爛貨就算了...還得享受這種三流服務...

以後不再聽信這三星保固什麼鬼的了...

還是sony的保固好,

數位相機最重要的ccd壞了問也沒問就幫我修好也沒收半毛錢...

(註 建達國際也代理maxtor硬碟 所以 自求多福 :P)

Thread dying problem may fixed in django/flup.

一直都耳聞django的apache+mod_fastcgi+thread mode在高負載狀況下有問題,
甚至也有人將之歸結於python的thread實作有問題,
所以我一直以來都是使用prefork的方式來啟動fastcgi/wsgi,
上禮拜在替django作負載調試的時候,
也發現thread mode在超高壓力測試的情況下,的確會停止運作造成service unavailable
(concurrency > 1000)
因此才花時間找出真正的原因(至少在我這邊的原因),
應該是django所採用(其實不止django, pylons跟turbogears也有採用)
的FastCGI to WSGI adapter -- flup,
在threadpool的實作上有些許的小問題, 沒有對運作異常的thread拋出例外的情形加以處理,
才導致了發生問題的thread沒有再次進入threadpool,所以運作一陣子後會讓所有thread悄悄死去.

在修正了這個問題之後, 即使在concurrency > 1000的情況下仍然保持順暢運作,
也擺脫了使用modpython或prefork mode的fastcgi大量耗用伺服器記憶體的情形,
thread mode + FastCGI/WSGI 果然才是王道!

我已提交patch, 期待新版的flup收納之後, 讓python的web framework在thread mode下運作更順利.

[link] Py3K status.

Python 3000 Status Update 來自BDFL (GvR) 的消息, 說明目前python 3.0的發展狀況.

python 3.0的第一個alpha測試版本將延至今年八月底釋出. (還有兩個月!)
所以預定3.0的最終釋出版本也順延至2008年第二季後.

恩, 照這個估算2009才是python3.0正式的開始.
還有一年半的時間可以假裝這世界上沒有python 3.0 ;)

[rant] Ubuntu果然連這招也學會了...

我好害怕啊.... 咬我啊... :P

[link] Generate django project API docs

http://wolfram.kriesing.de/blog/index.php/2007/generate-django-project-api-docs


這篇講到如何用epydoc產生比admin裡的doc更完整的django API文件.
當然會包含自己專案裡面API的doc string.
very useful.

[link] Mark Shuttleworth on VCS. 馬克·沙特爾沃思先生談論版本控制系統

馬克·沙特爾沃思(Mark Shuttleworth)先生 -- 如果你不知道我在講誰的話....

就是世界第二位平民太空人,早期debian開發者跟Ubuntu創辦人啦...

在他的blog上談論了他對VCS的一系列看法.

Choose Lossless VCS tools if you have the luxury

Further thoughts on version control

Renaming is the killer app of distributed version control

我讀了一下他的觀點大概就像這樣...

"""
VCS最重要的功能就是renaming, 而bzr把renaming視為非常重要的功能,
不管你的目錄怎麼搬, branch怎麼merge, bzr就是玩不爛.

bzr就像raw-format, 什麼都紀錄所以速度較慢但是卻可以無損轉換成其他格式...
在不同的情形不同的狀況下, 都可能有不同的最佳VCS工具.
何況世界變化很快, 從tarball, RCS到CVS到SVN...
現在很明顯的又進入到了分散式VCS的戰國時代,
而過一陣子搞不好又有更新更好的工具.

所以... 就像你最寶貝的片子/照片(通常)會存個無損RAW檔一樣,
bzr什麼都給你記下來, 當你真的需要在特定環境作特定應用而bzr辦不到的時候,
可以很快轉換過去.

"""

當然底下的評論自然有darcs眾,水銀黨(hg)跟git幫要戰mark...
這個就跟我沒關係了...
我只是普通用戶一枚,
反正這個系列的文章可能還會繼續下去,
就等著隔山觀虎鬥, 爆米花買好, 戰的好記得出來拍手就好了.... XD

PEP 3104 Access to Names in Outer Scopes -- or the ture closures for py3k

http://www.python.org/dev/peps/pep-3104/

python 2.1以前, python是沿用C對scope的思維,
只有很簡單的global跟local的scope概念.
(and builtin)

python 2.1之後引進nested scoping,的確帶來了不少彈性,
不過比起一些更為彈性的語言來說, 對於scoping的控制
仍然無法稱作完善.
而PEP 3104引進了nonlocal這個關鍵字後,
總算讓在python使用closure顯得自然.

目前2.X的狀況:

 
Python 2.4.4 (#2, Apr  5 2007, 20:11:18) 
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def x():
...       t=9
...       def y():
...             print t
...             t = 10
...             print t
...       return y
... 
>>> z = x()
>>> z()
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 4, in y
UnboundLocalError: local variable 't' referenced before assignment

雖然 我們的用意是要讓t被enclosed, 但是卻沒辦法修改t.
注意到為什麼了吗?
由於在scope範圍內有了對t的assignment,
因此python會implicit的認為t是個local變數..
啊 可是我的第一個print t敘述裡的t要的不是被rebind過的t啊~~!

ㄟ.... 老師沒告訴你吗?
"Explicit is better than implicit." :D
所以py3k引入了nonlocal這個keyword,
以往只能用各種hack來解決的這個問題,
(最常用的一種是傳入list[0]),
會相對的使得closure的運用顯得不夠直覺.
在py3k底下則可以寫成這樣:
(現在print 改成 function ,,要括號,, 真容易打錯 :P )

Python 3.0x (p3yk:55958, Jun 13 2007, 18:39:18) 
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def x():
...       t=9
...       def y():
...             nonlocal t
...             print(t)
...             t=10
...             print(t)
...       return y
... 
>>> z = x()
>>> z()
9
10

加入了nonlocal這個declare之後,
是不是比以前清楚的多呢 :)

[link] 有愛連結: 以 New Gameday 數據解析王建民的投球特性

剛剛讀到這篇 Whither所寫的 漫步在綠海豚街上: 以 New Gameday 數據解析王建民的投球特性, 看到這篇文章用心的透過Gameday的XML數據分析王建民的投球. 着實又讓大家見識到所謂的"有愛"是怎麼回事 :D

MLB於2006年裝設了新版的gameday,除了將線上轉播帶進了一個新的時代,在棒球場上更裝設了30fps的高速攝影機以便能及時的分析到投打對決的實況, 然而目前只有九隊安裝高速攝影裝備, 很可惜洋基目前尚未裝設, 所以大大的減少了分析王建民投球數據的資料, 而該文便是在分析王建民於2007/05/16芝加哥白襪隊客場先發時所留下的XML數據. 內文有詳實的內容跟美觀的圖表, 透過科學化的角度分析投球內容 ,非常值得所有洋基/王建民的球迷一讀.