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

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

不过我重写的控制流还好，把
while True:
x = xs[i]
if p1(x):
if p2(x): return v1
else: i += 1
else: break
return v2
简化了（其实只需要分析下 i in range(0,len(xs)) 就知道）
但是没有删全局变量（毕竟我不了解问题，或许可以作参数顺序/提升至class ）

补充：写错了？

你们无法理解我也很正常啊，因为我是 C/C++/Kotlin/TypeScript/Python 经常换着写的人，怎么可能

#python #tech #pl #ce

多用linter 别乱讲话
至于n改name是有道理的 但这个并不影响我相关项目的代码质量
同时尤其在解释器 转译器方面你使用name这样的名字只会增加阅读困难 类似于某些语言中在符号很有限的情况/tutorial中 会尽可能使用极短缩写

我也曾不用pep8 但不管它怎么不合理 我得让我的代码过第一关 而不是连看都不看就被reject

1. linter 的规则不是人写的？从来如此，便对么
2. 如果你真的重视命名的语义，就不会觉得无关代码质量
3. 不会。你把惯常使用的语言结构 AST 总结出来（我就不举隔壁 Kotlin 友 mivik/kamet 的例子了，自己的就行），里面会有几个 .name ？何况这个东西只是存了交给作用域工具去取值/表达式而已，不经常引用，无简写意义
如果你觉得有，看看自己的代码用了几个 def

极短的缩写也不该混淆 n 和 name 啊，尤其是教程/新人向示例代码里，为了简短而截断命名，根本就是舍本逐末，不是所有人都有那么强的直觉

我重写错了就算了吧，大佬下次改进就好了(｡･ω･｡)
return (a, b) 我觉得不会被看成函数调用吧，毕竟 FCall = Name '(' Args ')' 而不是 Keyword '('...
除非阅读者把一切归于『语法』，根本不懂区分调用/访问/操作符
return 简写多个值容易误会 Python 支持多返回值一样（虽然貌似是这样），总觉得不太值得

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

小表达式抽提可以选择 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 才有点像匈牙利命名法

这个代码风格真的很棒！

请不要艾特我了谢谢

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