如果把优雅换成 best practice 大家会不会容易接受点？或者用“地道、接地气”？

V2EX里出现“优雅”的发问比知乎早很多
https://www.google.com/search?q=site:v2ex.com/t%20%E4%BC%98%E9%9B%85&gws_rd=ssl

=====

Coffee 的内嵌语法无疑是最优美的，拼接的糙活儿都给你做了。
反斜杠只是解决了将一行字符串分成多行，没有解决拼接的问题。
Array.push 方法在语法层面利用数组特性避免了连接符号，但是带来的开销是非常慢（真的非常慢，现代浏览器都会对静态字符串做优化 http://jsperf.com/string-concatenation/79 ）
multiline利用注释和Function.toString做的小把戏，如果有一些预处理（UglifyJS）会影响结果。

最佳实践都是日常积累而来，如果光问个结论可能不会让自己收获多少，也许这就是人们反感“优雅的XXX”的原因。

@leafonsword 抓去完成之后的处理只会影响CPU，在机器处理能力足够的情况下，比IO要几个量级。
至于每个抓取批次等待所有任务完成的等待，这没有让程序Block在IO wait中，也就是你用request-futures的动因，在这个等待循环中，你还可以做别的事情，比如提取之前抓遇到的数据一个一个处理，或者打印进度条。

有效果，不会等待上一次。
requests-futures返回的是一个future对象，不是等待请求完成

https://github.com/vinta/awesome-python
用过里面一些库，专注各个方面。

如果怀疑“有没有必要”，那就没有必要。不确定的优化在出现问题之后再做。
并发不会达到几万，如果达到请打脸时透露下你们的架构和业务。
使用redis一般是任务队列缓存，从你的使用方式来看也是。这种情况下从插入到显示肯定会有延迟，可以从产品端解决（本地脚本静态插入，或者读取列面时和请求队列里的任务针对当前用户是作者的情况做简单合并，目的都是为了让作者察觉不到）。
列表缓存需要产品优化，归根到底得考虑缓存的模型，一般而言量少更新频繁，从这连点下手，要求产品做出妥协。一切为了速度。

谈笑有鸿儒，往来无白丁

@zeiyso 这个UI更专业。
这个配置让我的老牛封路更准，基本成了标配……

“引领业界” 话有点大。只是将原来的JAVA换成NodeJS，该有个坑还是有，该有的学习成本只会增加。
机遇和风险并存。不过对于阿里这样的“百年之虫”，能够经得起折腾吧。

阿根廷2：1德国

@Sunyanzi 是的，这个属性只能证明对于网站经营的预期是多少。

$ whois macgoo.com | grep -e 'Registrar Registration Expiration Date\|Creation Date'
Creation Date: 17-nov-2006
Creation Date:2006-11-18 00:00:00
Registrar Registration Expiration Date:2015-11-18 00:00:00

已无法访问，当时是以个人博客的形式存在。博客辗转几载，除了写的人没换，程序，域名都换了。
这个域名一直保留至今的意义在于让我记住我的这些成长……至少记得每年还得交60￥。

whois XXXXX | grep 'Expiration Date'

os.popen("echo {a..x}{b..y}").read().split()

[a+b for a, b in itertools.product(string.lowercase[:-2], string.lowercase[1:-1])]

这种比较会不会只能证明 Because I can.
Pythonic的楼上已经有了，规规矩矩的。总之要实现语言不支持的特性时，import this

一个web端的？

打球

再看了眼，proc只有在netlink失败后才会作为备选方案解析。

static int tcp_show(struct filter *f, int socktype)
{
FILE *fp = NULL;
char *buf = NULL;
int bufsize = 64*1024;

dg_proto = TCP_PROTO;

if (getenv("TCPDIAG_FILE"))
return tcp_show_netlink_file(f);

if (!getenv("PROC_NET_TCP") && !getenv("PROC_ROOT")
&& inet_show_netlink(f, NULL, socktype) == 0)
return 0;

/* Sigh... We have to parse /proc/net/tcp... */

@liwei
@est

多谢告知。感谢已送。
ss.c 里的统计信息似乎还是读取/proc/* 。是我下了错误的版本吗？
$ uname -a
Linux dt 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

$ sudo apt-get source iproute

~/iproute2-3.12.0/misc$ grep -A13 'static FILE \*generic_proc_open' ss.c
static FILE *generic_proc_open(const char *env, const char *name)
{
const char *p = getenv(env);
char store[128];

if (!p) {
p = getenv("PROC_ROOT") ? : "/proc";
snprintf(store, sizeof(store)-1, "%s/%s", p, name);
p = store;
}

return fopen(p, "r");
}

@Livid ss也是读取的/proc/net/中的统计信息。如果你不需要pid相关信息的话，我觉得psutil更易用更容易定制

https://github.com/giampaolo/psutil/blob/master/psutil/_pslinux.py#L362

自己改写逻辑？按时间倒排增量？
psutil 只是解析 /proc/net/* 中的内容，以枚举器的形式返回。/proc 在内存中，IO问题相对来说没有disk那么严重