d********g
发帖数: 10550 | 1 下面这个捉急的片段，看有多少是用C风格/思路来写Python的，另外还有无法忍受的错
误/不推荐做法：
def strip_non_ascii(self, string):
''' Returns the string without non ASCII characters'''
s = ""
nonascii = 0
for c in string:
if ord(c) < 128:
s += c
else:
nonascii = 1
return (s, nonascii)
for fname in files:
(file, nonascii) = self.strip_non_ascii(fname)
if file == 'something':
continue
if nonascii == 1:
filepath = path + '/' + file + '*'
else:
... 阅读全帖 |
|
d********g
发帖数: 10550 | 2 你这个和我给他review的基本一样，不过这个case比较字符串大小比全等操作更优化
s = ''.join([c for c in orig_str if ord(c) < 128])
nonascii = len(orig_str) != len(s)
return (s, nonascii) |
|
d********g
发帖数: 10550 | 3 那代码里除了风格，别的常识错误太多了
第一file是内置函数，string是内置库。是可以强制赋值成别的对象，但是这种用法你
不捉急吗？那个组本来是做硬件的，Python用来写API，要不是我看到了顺手把关一下
，这种质量的code ship之后产品就卖出来了，还得WSN去折腾报告bug
第二个不用T/F而用0/1，这太明显的C霸王硬上弓了，捉急呀
第三字符串直接循环相加，虽然有些实现比如CPython是有优化的，但不是所有。这要
是循环十万遍，那可是要生成十万零一个字符串对象的（不说垃圾收集）
第四path join不用os.path.join()，直接字符串相加，这……就算100%肯定是在Linux
上运行，也不能这么山寨吧。我太为他捉急了
第五写Python的确实看不惯啰啰嗦嗦的写法。filepath那个就算这种错误的字符串操作
，也可以简化成这样：
filepath = '{0}/{1}{2}'.format(path, ascii_fname, '*' if nonascii else '')
或者：
filepath = '{0}/{1}{2}'.format(path, ... 阅读全帖 |
|
d********g
发帖数: 10550 | 4 算了吧，你自己先得学艺精。我都提到了其中一个答案是“带点C遗风的Pythonic写法
”：
filepath = '{0}/{1}{2}'.format(path, ascii_fname, nonascii and '*' or '')
这个写法：
nonascii and '*' or ''
看看和你自己问的C问题是不是有点类似？你理解了吗？
发信人: finalguy (o(∩∩)o), 信区: Programming
标 题: 神奇的逻辑关系
发信站: BBS 未名空间站 (Sat May 18 21:41:01 2013, 美东)
今天读一段code，不是很明白一个地方。具体就是
if (A && B || C) {
}
这样的逻辑写法我从来不用，看了也不是很懂。求高手指点，究竟在A，B，C那几个为
真的情况下会进入这个block？ |
|
d********g
发帖数: 10550 | 5 这C码工明显不知道自己在干什么，要知道的话style绝不会C风格，Python的风格关乎
效率。别的不说，就是C来写，那个判断nonascii的循环，用得着多次赋值1么？逻辑是
没错，我看着都蛋疼，就算小学生读了谭浩强的大毒草来写C，也不至于写成这样吧 |
|
