记得 celery 也是 >_<

unicodeobject 对应实现为：
static PyObject *
unicode__sizeof__(PyUnicodeObject *v)
{
return PyInt_FromSsize_t(sizeof(PyUnicodeObject) +
sizeof(Py_UNICODE) * (v->length + 1));
}

看了下代码，关于这个__sizeof__方法不同对象提供的方法不同，其中你要的 stringobject 的实现：

static PyObject *
string_sizeof(PyStringObject *v)
{
Py_ssize_t res;
res = PyStringObject_SIZE + v->ob_size * v->ob_type->tp_itemsize;
return PyInt_FromSsize_t(res);
}

其中 v->ob_size 是实际长度（ byte ），
PyStringObject_SIZE 相当于 sizeof(PyStringObject)，
tp_itemsize 为 sizeof(char)

代码版本： CPython 2.7.x

@justou 官方邮件组说不同平台返回结果可能不同

@xinali 你没看懂我意思么，意思就是说你这么算 unicode 长度是不对的， len 和__sizeof__ 不是一个概念。

@serial 建议你好好去阅读这些 driver 的源码（因为你总是说他们基于 httplib ，你呼它出来谈谈，问问它在这些 driver 实现里干啥呢），还有 IO 阻塞与否跟编程语言没多大关系的， OS 、各类服务 driver 不支持的话，众多编程语言一起哭吧。
Python 如果会讲话肯定会吐槽：“ C/C++原生撸 driver 本来就特么没有给俺做 none blocking 实现，怪我咯？”

建议你好好读一读 CSAPP 看看到底啥是 IO 多路复用，不理解再辩。

__sizeof__是 2.6+版本支持的，但不作为生产环境用途， 与之相关功能说明请参考文档中的： sys.getsizeof ，它不是用来计算 string 长度的！

@serial 同学，非阻塞 vs 异步是俩种概念额…… 不明白为啥又把各路框架、性能扯到可移植性来了。
@FrankHB 这里说的 native 指的是 x86 汇编…没深入研究过 SIMD 指令集，极端的说，比起虚拟机语言，操作指令集让性能更可控而已

歪了楼，极端点讲，一门基于虚拟机的语言与 C 、汇编相比能否充分压榨机器的极限，坦率的讲我个人觉得现有的编译技术够呛可以做到满分。

你再模拟，跟 C 、汇编这类贴近机器硬件的语言相比，大部分相同的功能操作也是要多出几个指令、周期的，不管跑在纯 Runtime 环境还是 JIT 编译后的，很难做到完美的优化你的机器指令！

因此，用虚拟机语言撸代码，还是别想着这些东西了，编译过程的优化你根本没法控制，个人 /团队做项目按时交付能愉快地给老板们创造价值才是王道。 不说了，睡觉明儿早起继续搬砖了。

@serial 关于"并发 IO === 渣"的推论很有趣，立论不太对吧。
CPython 本质上是使用 C 实现的 fs 操作部分，渣，你要说渣在何处嘛。
还有你说的异步支持， IO 多路复用的部分例如 select 模块也是用 C 实现的呀，代码你可以去瞅瞅呀，凭啥说渣呢，你要这么说 Twisted 超级脚手架就不开心了，已哭晕在厕所…
我实在想不通你举几个例子就论证人家渣是啥根据。你不能看到“苹果园果树打了农药” 就到处去跟人家说 “任何树上的苹果都被喷了农药”呀，要根据情况去论证和检验下嘛。

做好离职准备，找领导谈谈，谈不好就撤

@clino 同意这位同志的语录：你如果很在乎性能就不应该用纯 python,至少要用 python 配合其他语言来做

“ python 都能做，做的都很垃圾 --- CPU 计算慢， IO 并发低，特别是标准库写的特别差” 请问这是啥事实，有论证么？
某些同志凭感官就抛出 [事实] 二字也真是醉了。

@serial 照你这么说 Youtbue 、 Quora 、 Dropbox 、 NASA … 哭晕在厕所了。 OpenStack 应该用 C 重撸了……

直接操作寄存器、 x86 指令码快更 native ，你们倒是 coding 去啊，呵呵呵。

@xinali Celery+Flower

Tumblr 创始人 David Karp 的家 http://toutiao.com/a6187962724281352705/

万棵王食

食儿来～