搓是搓得起来，至于搓起来几张，送进去会不会打圈卡纸就不知道了。。。

有点F#的感觉，本质是右结合运算然后玩高阶函数还真是想的出来啊。。。

root='/'
改为你about.png 所在路径

方法多了
1. 调用GUI部分使用MethodInvoker把委托给GUI线程调用，这个耦合比较重，不过对知识点没啥要求。（当然处理部分可以BackgroundWorker, Thread, TPL等等）。
2. Reactive Extensions，这个写习惯了就相当方便，要求你换换脑子。

ST3插件全部放到plugin_host进程(一个python环境+IPC)中加载，启动后要过一会插件才能用。

Version 2.0.2
Release Date: 8 July 2013
Sublime Text 3 beta is now available from http://www.sublimetext.com/3
-----> Removed expiry date <-----
Backported various fixes from Sublime Text 3
Improved minimap click behavior. The old behavior is available via the minimap_scroll_to_clicked_text setting
Added copy_with_empty_selection setting, to control the behavior of the copy and cut commands when no text is selected

@thedevil5032
@xingzhi
是可选，因为python3源文件默认编码是utf-8： http://www.python.org/dev/peps/pep-3120/
如果源文件需要是由其它编码保存的话，仍然需要指定encoding

Data model

@lvii
我先建议你换成多线程模型，net-snmp的python绑定与gevent的兼容性未知，当然net-snmp的python绑定是否完全线程安全也未知，如果不是线程安全，也好做，使用多进程模型即可。

相当基本过程（多线程）, 伪代码：

def worker_proc(equip_id, q):

oids = oids_for_equip_id(equip_id)
for oid in ords:
snmp_walk(oid)

data = pre_process_data()
q.put(data)

end


import threading

# Consumer queue
q= Queue()
def data_consumer(q):
# 这里可以考虑维护个buffer_list, 维持一个超时时间
# 在超时或者buffer_list的大小超过阈值时, bulk insert到数据库
data = q.get()
save_to_db(data)


# bookkeeping
threads = []
# Workers
for equip_id in equips:
t = threading.Thread(target=worker_proc, args=(equip_id,q))
t.start()
threads.append(t)

@lvii 我没有说被动啊，你的需求其实是客户端啊，因为是你主动请求设备的数据。。。
最后那个OID那里，耗时长的原因是传输速度慢而不是数据量极大吧，数据量极大写起来就比较麻烦，如果只是传输速度慢（同时数据量也小）完全可以依赖上下文切换切到其它任务去。

还有两点：
1. 没有必要对一台设备的7次请求都分别做成线程, 直接顺序请求7次就可以了，单台设备的请求封在一个线程内（一个线程获取设备的7个OID）
2. 还有如果你的joinall()调用时机也不对，joinall()就是等待所有线程完成，你对单台设备的7次请求就等待其完成，跟做成顺序执行7次（无线程）没有什么区别，反而可能由于上下文切换速度还慢点，如果不需要同步，开了之后不用等待，只有程序退出的时候可能你需要所有操作完成join一下。

@shoumu
那是不是在用32位的python开64位的程序？

先检查3个前提条件吧，你给的信息太少了：
1. Windows only
2. 安装(并注册)有Debugger(VS, Debugging Tools for Windows, etc)
3. 目标程序无反制措施

简单的话使用Run length encoding吧，无论是速度还是压缩率都可以。更高效算法也有，要运算量或实现难度来换。

这种pull式获取传感器信息的，还是很好做，首先就不用考虑写一个高性能服务器需要做的活，因为这就是个客户端，实在不行在N台机器上开N个客户端分别获取不同组的信息最后统一写入到数据库（也可以写一个任务分配服务器来完成任务派发）。

再就是客户端编写，开N个线程其实也没啥，因为你点数不多（100多个），间隙也比较长（10s），那2s多的过程大部分都耗在传输上了（还有可能是结点部分处理相当相当慢，如果是数据量相当大导致的慢，我的假设没用，这段文本也就对你毫无用途了）。

数据库写入肯定是需要时间的，你可以另外开一个线程/进程/whatever干这种事情，写入速度要看你的数据量，数据量大还有更多的课题要做，几句话肯定说不完。

如果不需要考虑数据恢复的问题，可以在客户端内部维护一个list, 以一定的时间间隙，将这个list整个拿出来, 原来的list引用到另外一个新空list上（还考虑同步问题，暴力法就是用锁，当然锁都是要你命一万的），然后把整个list的数据bulk insert到数据库里。另外可以用message queue来完成数据写入工作：客户端发送采集到的数据到mq里（生产者）， 一个单独的进程获取mq的数据，完成写入工作（消费者），这种模型简单不易出错。

@hooluupog
那种叫introsort吧，C++ STL上的 sort() 一般都是这种实现，稳定的 stable_sort() 还是用的 mergesort, 不过由于是实现相关的，不知道什么时候会变。

python 现在用 timsort (java现在也是，稳定排序，mergesort的一种)
go/pkg/sort就是很明显的quicksort

排序算法跟实现有关。v8对于小数组用了简单的排序算法，是稳定排序。其它数组用的quicksort
Firefox早期用quicksort, 现在用mergesort

这种都是小巫了，如果有兴趣，请Google "X Macros"。。。

61.139.2.69:53
202.98.96.68:53

#define NODE_EXT_STRING(x) &x ## _module,
最后面有逗号