@disinfeqt

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

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

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

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

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

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

@chone

1.我们使用的图像大部分就是压缩过的，如果base64后再gzip会变得更小，那么这个图像压缩算法就太傻了。
拿http://www.google.com/images/logo.gif来说，原大小是11430字节，base64后是15240，再gzip是11473。
而且你测试下就知道，多一次compress和decompress的操作，肯定会对性能造成影响，更何况你还是用在CPU不给力的手机设备上。

2.如果要缓存，就必须每个图片写一个css。而获取这个文件本身就相当于多了一个HTTP请求，没有起到减少HTTP请求这个目的。

4.这个是和1相关的。一般的css文件只有几k到几十k，是很容易下载完的，不需要等待太久。而你加上了图像后，css变成了几百k甚至上m，这对用户来说就很慢了。因为我可以忍受图片暂时不显示，但不能忍受整个网页都暂时不能显示。

不知道楼上2位是否真的将data URI投入实际使用，至少在我看来有几个严重问题：
1.base64编码会增大1/3体积。
2.无法让浏览器缓存图像，只能缓存引用它的文件。
3.在HTML上不能复用，要复用只能放在CSS和JavaScript里。
4.你如果把背景图片写在CSS或JavaScript里，你在下载完CSS和JavaScript之前，浏览器是完全停止解析和渲染的，而常规的引用外部图片的方式是可以并行下载的。

直接在后台找到对应的Member实体，修改username属性即可

Disqus不支持HTML，想设置字体样式发个图贴个视频贴段代码都不知道咋弄

我的经验是：同一件事给我5天去做，我会在第5天上午完成；给我2天做，我会在第2天吃完中饭后完成；给我1天做，我会在下班前一小时完成；给我2小时，我会提前半小时完成。

其实编程用不了多少时间，大部分是花在闲逛和准备工作上。

我是2个都用，样式也不用改＝。＝
http://img.ly/2v5R

不会用https的就不要说自己用的是GR…

至少也要用logging吧…

pycharm和pydev都能调试的

用webmasters tools：
https://www.google.com/webmasters/tools/change-address?hl=zh-CN&siteUrl=你的网址

tornado是需要去下载的，可以在GAE上用，不过性能一般。

GFW是按ISP来的。有的可能只被电信墙，有的是网通，同理还有教育网等杂七杂八的…

有时候会卡几秒才能打开页面

另外就是Rails生成了很多用不到而且很大的js文件，打开新网页非常拖网速

Windows的话可以看这里：
C:\Python25\Doc\Python25.chm

或者直接在线看：
http://python.org/doc/

其实PEP也是个好东西，讲解非常详细，附带很多例子：
http://python.org/dev/peps/

@Sunyanzi

self只是一个编程习惯，类似于其他语言的this。不同的是self不是关键字，因此你写成other也没关系，只要你不会弄混淆…
你如果深入去了解的话，就会发现元类的方法使用的是cls，而不是self，这也是习惯问题。

而且诸如C++等语言在很多情况下是可以省略this的，但Python不行。你深入去了解的话，会发现它的方法是用descriptor实现的，设计得非常优雅，不过也导致了必须写self：
http://www.keakon.cn/bbs/thread-1863-1-1.html

@是一种decorator语法，本质上来说就是高阶函数：
http://www.keakon.cn/bbs/thread-1081-1-1.html

至于你说的.write() .error() .redirect()，这是webapp的Response类里面定义的方法，这些方法名是可以随意写的，你用dir()可以审查一个对象的各个属性和方法。

Python的文档其实不少了，真要说的话，就语言本身来说，它的文档是我接触过的语言中最完善的，甚至比Java和PHP做得还好。
只不过你加上“中文”文档这个限制，那就自然少之又少了。

你不升级Discuz!不就行了，又没强制你用QQ登录…

数据转换其实很简单的，用myphpadmin导出成xml格式，然后写个转换函数和配置文件就行了

我就把Discuz!的数据转到我的blog了，具体的代码你可以看bulkloader开头的那些文件：
https://bitbucket.org/keakon/doodle/src

用logging把site['city_tag']和self.root记录下来，或者直接debug

然后手动运行一遍

代码本身没错，我想应该是数据的问题

话说为什么存储要用XML格式，使用起来非常麻烦

没有提供设置，只能自己去改源码

打开main.py，SignupHandler的get里把chtml的值改成''

post里把这段代码

# Verification: reCAPTCHA
到
template_values['recaptcha_error_message'] = '请重新输入 reCAPTCHA 验证码'

删掉

加一行template_values['recaptcha_error'] = 0，注意缩进

本地试验成功，没去部署过

不知道是否提供API，先注册看看