关于冗余括号问题我和主流正好意见相左，我是看见不好读了就会加括号，偶尔算符的左右空格也会吃掉一个体现重要性

小表达式抽提可以选择 local def ，目前内部没优化不提取也有道理（虽然我觉得对 Py 应重视架构上的开销，如惰性计算和分块计算，少在意代码质量的开销）
不过，编译原理里是有『公共子表达式』优化的，如果出现太多次/耗时长，会自动提升为局部变量。

缓存看起来的确不多次，但 bisect 隐藏了 lt 算符的调用次数，和 str.split 也隐藏了 GC 分配压力，最好还是在意下兼容性 class 抽象开销的问题

s[:-1] 等价 chomp 也只能说是我太主流了，毕竟 Perl 和 Visual Basic 一堆设计混乱，分不清是文本文件处理 DSL 还是泛向语言的，是真的不会写……(｡•́︿•̀｡)

关于缓存会不会提升效率，你可以自己测一下。
local def 没有用的。开销主要在函数调用上。「如果出现太多次/耗时长，会自动提升为局部变量。」——你确定你看的是编译原理而不是 JIT 的设计与实现？

编译优化也包含在编译原理里啊， CSE, common-subexpression-elimination ，这是公共基础优化之一啊，一般不需要运行时 perf 信息作判断也可以执行
local def 不是为性能 是为代码质量

https://github.com/duangsuse-valid-projects/Share/blob/master/Others/fill_template.py 我也是2空格。 不用 tab 是觉得语义不好，而且很多默认/强制4空格渲染的；不用4空格是嫌浪费行长，无意义

那个…… 提几个建议
1.不要再起 n:str 了，红姐也有这种习惯，换 s:str 或 name:str 吧，激进一点也可以叫 sKey
同理激进命名也可以前置 mainf 的 f, 并精确为 fpOrigin
2.retrun tuple 的时候可以加括号；局部赋值 unpack 时也可以
3.Entry.__lt__(other:str) 序运算符解析了其上 value ，也可以在 ctor 里缓存下
4.s.split(' ',limit=1) 可以抽提下
5.我知道 write_main 里面你 .value[:-1] 是 .rstrip('\n') 的意思+必然存在断言，但即便你能断言，原本的逻辑最好还是注释下，编程中这类“优化”还挺多的，得注意

https://t.iss.one/dsuses/4401
重写了一部分，还没起床就不折腾了…… 搞不清 bisect 和这个程序是做什么的就在乱写，差点把 find_entry() -> int（

重写的部分当然比较激进，常量是动态计算的，然后用了 k, e, ek 这些简写法(差点用成 k, for k1in...) posEqEntry 也是不常规的名字（没办法了）

不过我重写的控制流还好，把
i = get_i0()
while True:
x = xs[i]
if p1(x):
if p2(x): return v1(i)
else: i += 1
else: break
return v2(i)
简化成
i = get_i0()
for (i, x) in enumerate(xs):
if not p1(x): break # take_while
if p2(x): return v1(i)
return v2(i)
一言以蔽之就是（好吧不行）
entry = func(_split2)
key = func.fst<<entry
value = func.snd<<entry
next(filterMap(value, p2<<key, take_while(p1<<key, islice(enumerate(xs),i0) ) ))
（其实只需要分析下 i in range(0,len(xs)) 就知道，刚才我差点以为自己重构错了，pos 不是 step=1 递增）

但是没有删全局变量（毕竟我不了解问题，或许可以作参数顺序/提升至class ）

依云大佬你的代码质量还是要注意下吧…… 没事可以重写下自己的代码，重视简洁性和定义力、可移植性，慎用控制流，少写换行、重复求值计算，靠这些“反优化”逼自己把可读性提上去，用这种方法没有语言的代码写不好看的😊

夸语言不好吗，PEP8 的这种方法或许能很易懂的实现许多小应用，但碰到计算机图形学什么的还管用吗
很多语言也不像 py 用下划线区分可见性的
这个是说局部计算的，PEP8 连 class name 和 not in operator 的都有，太宽泛了

就 sKey 而言是我写过分了（显而易见 key 经常是 str），比如 key:int （同名不同型，不希望重赋值）但你要 for in 的话我可能推荐 for sKey in keys: （例子而已）

Py 是动态类型不在意重赋值与量的可变性，但是 Kotlin 和 Rust 里这个问题是不可回避的，而且同名变量重 let 成不同类型属于不良实践（Kt 里则根本不能覆盖变量名），这是一种 变通(workaround)解法，所以说例子没举好

如果我举绘图里 wBox, hBox ， padX, padY 这样的例子，相信不会有人说是复辟匈牙利命名法

这么说吧 我是对的 我不打算听你的话 我就是无敌的 你用来支持观点的例子在我看来都是菜鸡

https://github.com/duangsuse-valid-projects/MontagePY/blob/master/montage1_c.py#L16
菜鸡？那么你可以举个相对的实践了。

wBox 很正常啊，写成 bWidth 才有点像匈牙利命名法

这个代码风格真的很棒！

请不要艾特我了谢谢

别提代码风格，看看解决了什么类型的问题吧

要命。有什么好处呢？总是赢，不肯选择和接受别人的观点
我要是一直这样，走不到今天

一句话不说是最好的，闷声发大财
人们总是选择相信他们相信的东西，排斥不相信的东西，连看都不屑

即便三年前的我也知道要想改变一个东西，你得先融入它，证明自己懂它，才有资格批评它；
现在我看见别人对他们讨厌的东西，选择屏蔽掉，视若未见。

显而易见 key 经常不是 str。它经常是整数、UUID、函数等

sKey 显然是用于 s* 或者属于 s* 的 key，比如 secret key

是的。现在想想有这种混淆可能

其实我不喜欢 w32 那种 pfn_xxx 的命名，我的法子是自己弄出来的，可以理解为民科，只要别讨厌我就好了≥﹏≤

「而且同名变量重 let 成不同类型属于不良实践」？你是在哪里看到 Rust 有这种说法的？