楼主这个问题很蛋疼，撇开其技术实现，2段代码所完成的功能都截然不同。

第一段是CGI输出HTML，然后用HTML的meta跳转来重定向到/index.html。
懂HTTP的都知道，其实不需要这么麻烦，直接输出这个就行了：
print 'Location: /index.html'

第二段代码是用WSGI生成HTML，而且是直接读取index.html的内容来输出的，没有进行重定向。

从楼主的描述来看，你应该是没有处理/index.html这个URL。
我猜你应该是用一个Python script处理了所有请求，然后直接重定向到/index.html；但是/index.html也是被这个script处理的，于是再次重定向到/index.html；于是你就蛋疼地一直重定向了…

技术上来说，你的要求完全不需要用Python来处理，直接改app.yaml用静态文件处理就行了：
handlers:

- url: /(index.html)?
static_files: index.html
upload: index.html

这个和你的实现有关，你得了解什么是App Caching

简单来说，你import hook后，只要这个instance没有消亡或清除App Caching，hook是可以重用而无需再次载入的

而hook.py中又import了apiproxy_stub_map，并且hook了其中的服务，因此这个hook是持续存在的，直到instance消亡或清除App Caching

此外main函数也是会被cache的，因此重用main函数时，它之外的语句不会重复执行

如果你import的位置不对，就有可能造成多次hook，也有可能造成没有hook，我也不知道你代码是咋样的，只能点到此了

楼主的表述真的很难懂…

没猜错的话，你是要把if NowDay==KCB.time[0] and NowTime==KCB.time[-1] and NowWeek in KCB.week改成GQL查询条件吧

简单来说就是不行，因为datastore不支持复杂的查询，只能将一个属性作为一个整体来查询，不能查询time[-1]这种

因此你只能这样：
KCBs = db.GqlQuery("SELECT * FROM kcb WHERE week = :1 ORDER BY date DESC LIMIT 1000", NowWeek)
for KCB in KCBs:
if NowDay==KCB.time[0] and NowTime==KCB.time[-1]:
#...

week是一个ListProperty，查询的时候直接用=就行了，IN的语义不是你理解的这样的

最后提醒一下，不是有特殊需求的话不要用GQL，因为查询较复杂时，构造非常不方便，而且性能很差。所有GqlQuery对象都能用等价且更方便高效的Query代替。

要在main()里调用import hook并重设时间

不过如果不记录urlfetch次数和总时间，那就不需要重设时间，只import即可

https://bitbucket.org/keakon/doodle/src/86e5d334e718/blog.py#cl-64

服务名是'urlfetch'

你可以先注册Gmail账号，然后注册app id。因为app id会为Gmail账号的用户名保留，但前提是你的用户名不含特殊字符，例如小数点。

这是Google员工前天说的。

你可以用logging来记录时间，urlfetch属于service，可以参考这个来hook：
https://bitbucket.org/keakon/doodle/src/9830de2a181b/hook.py

twitter 客户端确实没什么办法加快，不过web端的可以弄成ajax，在用户不知情的情况下去fetch

latency越低越好（一般应该低于1000ms，我的不到100ms），QPS越高越好（不过钱也花得多）

支持PubSubHubbub的话，订阅后自己抓＝＝

发信人只能是当前用户或这个app的管理员，这个是GAE的限制

“创建分类时保存之后 一会分类就会消失”是指sidebar吗？
我设置了10分钟的缓存，过10分钟才会完全更新。
但是在后台创建和编辑文章时应该不会有问题，可以选择所有分类。

第一个是你没有设置正确的管理员邮箱（ADMIN_EMAIL），这个邮箱必须是这个app的管理员的邮箱。

第二个在之前更新的版本已经修正了。把blog.py里出错的那行代码删掉就行了。

第三个是格式不对的问题，目前我是把feed关闭的，所以没有测试这个问题…刚才我已经修正了，下载或check out最新的code即可。

谢谢指出这些问题。

我传了个新版本上去。原版本删了一个页面，但是URL映射里没有删，所以会报错。

你报的这个错看上去和Doodle无关，因为我的代码里没有调用过fetch.py。很显然是你把andy-wallproxy和Doodle集成时才出的错。

如果不是很熟悉YUI的话，建议你在app.yaml里将fetch.py分离出去。

@deepice 报的什么错贴出来吧，不然我怎么知道…

@pudd
这个问题可以用JavaScript解决，也就是预加载图片。
纯HTML+CSS也能做到，底部写个div来下载图片，但是隐藏显示就行了。

@pudd
速度还不错，很漂亮，建议导航栏加个title属性，不加文字说明的话，有些图标不知道代表什么。

这里css sprites的应用感觉并不恰当，还记得它的本意吗————减少HTTP连接数，加快下载速度。
可是你的all.jpg有500多k，我花了5秒才下载完，这时候一直都只能显示load.gif。
事实上让用户第一时间看到第一张图，在用户还在摸索你的导航条时偷偷完成其他几张图的下载更合适。

另外，blog的响应速度很慢，感觉应该是被数据库拖慢了。

这个是旧的，下个月主机到期就会自动转到GAE了，因为有些文章还在整理中，所以地址就懒得公布了

演示在这里（版本比较旧）：http://acgpedia.appspot.com/blog/

@disinfeqt

就我本身来说，我没有采用上述的任何一种技术，因为我觉得简单就是最好的。我甚至完全不考虑IE浏览器，我自己的博客就是HTML5 + CSS3。

小图像下载本身就很快，拼在一起并没有让我感觉到更快。对用户来说，它们是次要的，关注的重点应该是内容本身。

而data URI会增大CSS体积这个缺点对我来说是致命的。这种次要内容绝对不应该影响到用户正常浏览网页，而CSS在下载和解析过程中对浏览器的独占性决定了它必须尽可能简化和轻量。
单个5kb的文件看上去是可以接受，但整个网站会用到多少个这种图片呢？如果就3、4个，增加几个HTTP链接又不会怀孕；如果10几20个，我想这个CSS也就不可接受了。
而且从维护上来说，看到一堆乱码一样的东西，人脑是不可能读懂这是什么图片的。

举个很现实的例子，我手机用的是GSM，网速慢得要死，所以我是不显示图片的。可你如果放在CSS里，我就被迫去下载这些我不关注的玩意了。

我还见过一些体验很差的网站，打开后先展示一个框架，然后下载半天资源，过了30秒才给你展示最重要的文字内容。
我想你必然更愿意在3秒内看到主要内容，然后花27秒去下载其他资源。至少在这个等待过程中，你可以看到想看的内容，而不是一个空白的框架。

我认为它真正有意义的地方是用来生成验证码。这个玩意不需要在服务器端生成和维护一张临时图片，这对于不能更改文件系统的GAE来说是很有意义的。