@msg7086 看来我们的思路比较接近，你现在 wpm 能达到多少？如果全是字母，没有大写的话，我也就 40 多点，遇到特殊字符和中间的数字还经常敲错，感觉遇到瓶颈了

@wclebb 你回答了很多，看出来很用心，但是槽点不对：）

delete 太远了，放过去右手覆盖的字母就太少了
——你没看出我的槽点：你这么喜欢把左手放 control ，那为什么不干脆把右手放 delete ……
---->是我没看出槽点么？我的意思是： control 用得多且距离近，所以我左手小指默认位置放在这里了， delete 用得少且距离远，如果放在那个默认位置，离右手要覆盖的很多键就远了。

已经形成一种反射，如果看到 cd 食指和中指就自动放到 c 和 d 键了，如果看到 df ，食指和中指就自动放到 f 和 d 键了
——是的，这是习惯；但我们不一样，我们是「真的不看，不看，不看」键盘的。
---->我从没说我敲 cd 或者 df 的时候需要看键盘。实际上我以现在的方式敲键盘，大部分键是不看的，数字、特殊符号需要看，不看就敲错了。


我的 control 键在 Caps Lock 的位置，所以原来左手的默认位置相当于比标准的位置左移了一格。
——我就纳闷你说的键位这么奇葩……也不知道你说的是 Windows 还是 Mac
---->这个键位还真不奇葩: https://www.google.com.sg/search?q=site:v2ex.com/t+Caps+Lock&gws_rd=cr,ssl&ei=1nL7VZ7LBePwmAWBkrGYBg

@freewarcraft 对于 B 键，我也一样有疑惑， B 键对于左右手的起始位置而言是一样的，为啥用划到左手的范围呢？大部分人是右手更灵活吧。难道是因为老外左撇子多么？ ：）

哦，原来正文写错了，我的 control 键在 Caps Lock 的位置，所以原来左手的默认位置相当于比标准的位置左移了一格。

@wclebb 特地过来感谢一下，你很用心的回复了好几次，也很耐心的看了我的困扰。

有些你有疑问的，我回答一下：

—— control 我很少用，也不知道有什么用，感谢苹果把 command 放空格旁边，这样我可以直接用大拇指打出来了。
vim+tmux 写程序，把 control 配置成组合键了，很多时候都用到 control ，比如选择自动补全、切换 vim 窗口、 tmux 的 bind-key 等等。

——如果是，那也没办法啊，只能说习惯呗，如果是这样， delete 怎么不见你说把右手小拇指放 delete 键呢？毕竟非标准指法的人，最容易打错字。
delete 太远了，放过去右手覆盖的字母就太少了

——反而觉得食指和中指效率慢，因为你只是专门给食指放了 c 和 d 各自的位置，但它能兼任周围的键位吗？我也可以说 d 和 f 很快呢……
已经形成一种反射，如果看到 cd 食指和中指就自动放到 c 和 d 键了，如果看到 df ，食指和中指就自动放到 f 和 d 键了

其实你说得对，主要是我还没习惯，小指的运用不够熟练（不知道和小指比较短有没有关系 :( ），而且如果没注意，一旦敲急了，就恢复原来的指法了。

现在已经在练习纠正了，希望纠正之后突破瓶颈。

最后再次感谢:)

ajax 是另外一次请求，你需要发看看 ajax 发了什么请求，然后直接发那个请求就好了。
当然对于 ajax 请求，服务器还可能验证其他的，比如 cookie 、 ua 之类的

看了大家回答， google 了一圈，推荐标准指法（或者稍微有点微调）的不少，还是练练试试看吧，不知道阵痛过去会不会好一点。

仔细想了一下，目前主要的问题还是，两只手的小指用得很少，基本左手小指就只敲 ESC Tab Control Shift 和 Q ，右手小指主要敲 Delete 和 Enter

@bestsanmao 刚才我发的网址也是推荐这么按，但是不少键盘右边没有 ctrl ，而且就算有右边的 ctrl 都比较偏

@Strikeactor 就是想标准应该是有道理的，不知道熬过这段时间会不会柳暗花明，才想到这里看看有没有过来人：）

有个疑问，为啥需要先打包再解包？

给你找到一个比较优雅的答案： http://stackoverflow.com/questions/2158395/flatten-an-irregular-list-of-lists-in-python

我是 sof 搬运工:)

flatten 返回的一个 list ，然后递归的时候又把这个返回值作为 list 的元素，所以。。。

没有核心技术也没有好玩的东西，上午听完饭都没吃就走了，下次去之前真得好好看看日程表。

另外， operator==接受的参数一般是对象的引用而不是指针。

你原来的代码比较的是两个指针是否相等，也就是比较两个指针是否指向同一个对象，而不是比较对象中的 x,y 值是否相等。改为*(*it ) == *point 才是调用重载的==进行比较。

大概看了一下原来的代码， childrenList 每次都是新生成点对象的，对象当然和原来的 openlist 的对象不一样，所以你的 openlist 会一直变大。

数据说话：

In [18]: d={i:2*i for i in xrange (1000000 )}

In [19]: %timeit 10000 in d
10000000 loops, best of 3: 97.9 ns per loop

In [20]: d={str (i ):2*i for i in xrange (1000000 )}

In [21]: %timeit "10000" in d
10000000 loops, best of 3: 92 ns per loop

看到数据有点吃惊，但转念一想 dict 查找或者插入都先是 hash ， hash 之后都是 int 了，比较也是比较的 hash 后的值（除了冲突的时候），所以就再比较一下 str 和 int 计算 hash 的效率：

In [24]: %timeit hash (12312093810298310928301 )
10000000 loops, best of 3: 81.7 ns per loop

In [25]: %timeit hash ("12312093810298310928301")
10000000 loops, best of 3: 78.5 ns per loop

如果有冲突，就需要值比对了，理论上来说这时候就需要对 str 进行比较了，应该比较慢了，但是还没有好的方法去寻找两个 hash 值一样的 str ，所以暂时无法测试

a byte of python 不是就有 2 和 3 的版本么？没有混在一起讲吧

+1

两大难事之一呀

虚惊一场，是我自己一个脚本的bug -_-!!! 太傻了
https://github.com/WKPlus/toolkit/commit/057a25d1d5ff8c2e2245dc0855aceb9a17b902f9

我原来还以为员工恶作剧，jack是指jack ma呢。。