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:
filepath = path + '/' + file
这种流水code，就是要求用C写也不至于这么直白吧…… |
c*********e
发帖数: 16335 | 2 python和c
让我想起了vb和c#
【在 d********g 的大作中提到】
: 下面这个捉急的片段，看有多少是用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:
|
c****e
发帖数: 1453 | 3 as long as it works, why bother. "c style" is not expressive but usually
quite robust. |
n******t
发帖数: 4406 | 4 说句直白的，风格其实不能当饭吃。
程序员最重要的不是style,是知道自己在干什么。
【在 d********g 的大作中提到】
: 下面这个捉急的片段，看有多少是用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:
|
n***e
发帖数: 723 | 5 恩。。。
那个你能放个比较正确的写法么？
【在 d********g 的大作中提到】
: 下面这个捉急的片段，看有多少是用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:
|
c********l
发帖数: 8138 | 6 re，没看出有什么需要改进 的
【在 n***e 的大作中提到】
: 恩。。。
: 那个你能放个比较正确的写法么？
|
c*********n
发帖数: 182 | 7 def StripNonAscii(self, non_ascii_string):
striped_str = ''.join([c for c in non_ascii_string if ord(c) < 128])
return (striped_str, (striped_str == non_ascii_string))
这多干净 |
c********l
发帖数: 8138 | 8 强，长姿丝了
【在 c*********n 的大作中提到】
: def StripNonAscii(self, non_ascii_string):
: striped_str = ''.join([c for c in non_ascii_string if ord(c) < 128])
: return (striped_str, (striped_str == non_ascii_string))
: 这多干净
|
g*****g
发帖数: 34805 | 9 不懂python，但regex不就一行的事情吗，大多数语言都支持。
String.replaceAll("[^\x00-\x7F]", "") |
c*********e
发帖数: 16335 | 10 嘿嘿。。。
【在 g*****g 的大作中提到】
: 不懂python，但regex不就一行的事情吗，大多数语言都支持。
: String.replaceAll("[^\x00-\x7F]", "")
|
|
|
d********g
发帖数: 10550 | 11 这你就有所不知了，不同语言的特性决定了性能
Python里的字符串都是不可变的，不能重新assign，字面上的重新赋值实际上都是新开
一个对象
所以你看一个循环里 s += 'xxx'这种写法会生成多少个废对象？
【在 c****e 的大作中提到】
: as long as it works, why bother. "c style" is not expressive but usually
: quite robust.
|
d********g
发帖数: 10550 | 12 你这个和我给他review的基本一样，不过这个case比较字符串大小比全等操作更优化
s = ''.join([c for c in orig_str if ord(c) < 128])
nonascii = len(orig_str) != len(s)
return (s, nonascii)
【在 c*********n 的大作中提到】
: def StripNonAscii(self, non_ascii_string):
: striped_str = ''.join([c for c in non_ascii_string if ord(c) < 128])
: return (striped_str, (striped_str == non_ascii_string))
: 这多干净
|
d********g
发帖数: 10550 | 13 那代码里除了风格，别的常识错误太多了
第一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, ascii_fname, nonascii and '*' or '')
前一个是标准Pythonic写法，后一个是带点C遗风的Pythonic写法
用Java打个简单的比方吧，这种写法好比在Java里模拟C的指针操作，自己多加一层
layer。可以是可以，就是捉急，你要是看到公司有C码工在Java里这样乱搞难道不吐血？
短短的几段代码，能同时犯这么多错误，也不容易
【在 g*****g 的大作中提到】
: 不懂python，但regex不就一行的事情吗，大多数语言都支持。
: String.replaceAll("[^\x00-\x7F]", "")
|
d********g
发帖数: 10550 | 14 更省的办法是避免多次ord()调用
import string
ASCII_LETTERS = string.ascii_letters
s = ''.join([c for c in orig_str if c in ASCII_LETTERS])
不过意义不是很大
【在 d********g 的大作中提到】
: 你这个和我给他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 | 15 这C码工明显不知道自己在干什么，要知道的话style绝不会C风格，Python的风格关乎
效率。别的不说，就是C来写，那个判断nonascii的循环，用得着多次赋值1么？逻辑是
没错，我看着都蛋疼，就算小学生读了谭浩强的大毒草来写C，也不至于写成这样吧
【在 n******t 的大作中提到】
: 说句直白的，风格其实不能当饭吃。
: 程序员最重要的不是style,是知道自己在干什么。
|
c****e
发帖数: 1453 | 16 I know immutable. But it's python's complier's job to optimize this.
javascript used to be slow to s+=, now it's even faster than stringbuidler
because people like to write in that way.
I agree the way he wrote is not every FP. where|join can make code more
expressive. But my point is even his code is verbose, as long as it works it
could be fine. I don't know your concrete story, but don't laugh at
novince. He might just need a little bit practice and learn a few
conventions.
Back to the post, let's not start perf discussion on python.
【在 d********g 的大作中提到】
: 这你就有所不知了，不同语言的特性决定了性能
: Python里的字符串都是不可变的，不能重新assign，字面上的重新赋值实际上都是新开
: 一个对象
: 所以你看一个循环里 s += 'xxx'这种写法会生成多少个废对象？
|
f******y
发帖数: 2971 | 17 让python马工去写C，估计根本写不出来了。
【在 d********g 的大作中提到】
: 下面这个捉急的片段，看有多少是用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:
|
d********g
发帖数: 10550 | 18 你这样说也不对，如果啥都是compiler's job，怎么不搞一个自动写bit manipulation
的，智能把垃圾代码给搞高效一点，对吧？
it
【在 c****e 的大作中提到】
: I know immutable. But it's python's complier's job to optimize this.
: javascript used to be slow to s+=, now it's even faster than stringbuidler
: because people like to write in that way.
: I agree the way he wrote is not every FP. where|join can make code more
: expressive. But my point is even his code is verbose, as long as it works it
: could be fine. I don't know your concrete story, but don't laugh at
: novince. He might just need a little bit practice and learn a few
: conventions.
: Back to the post, let's not start perf discussion on python.
|
d********g
发帖数: 10550 | 19 算了吧，你自己先得学艺精。我都提到了其中一个答案是“带点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？
【在 f******y 的大作中提到】
: 让python马工去写C，估计根本写不出来了。
|
m*******l
发帖数: 12782 | 20 别互相贬低了,要我说, 我知道看到数字就头疼呢,例如你这个128...
【在 d********g 的大作中提到】
: 算了吧，你自己先得学艺精。我都提到了其中一个答案是“带点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，不是很明白一个地方。具体就是
|
|
|
w*********l
发帖数: 1337 | 21 不觉得。你这个每次+=都生成一个新的object不是一个显然的决定， 你是把internal
implementation拿来反过来指导用法。C没关系，反正什么都透明，学的OS跟
architecture已经基本上给你sense怎么写比较快。
manipulation
【在 d********g 的大作中提到】
: 你这样说也不对，如果啥都是compiler's job，怎么不搞一个自动写bit manipulation
: 的，智能把垃圾代码给搞高效一点，对吧？
:
: it
|
f******y
发帖数: 2971 | 22 谁这么写程序的，只能说他C写的也不怎么样。
【在 d********g 的大作中提到】
: 算了吧，你自己先得学艺精。我都提到了其中一个答案是“带点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，不是很明白一个地方。具体就是
|
i***r
发帖数: 1035 | |
d********u
发帖数: 5383 | 24 "风格关乎效率"的语言是没生命力的。说难听点儿，就是玩具。
【在 d********g 的大作中提到】
: 这C码工明显不知道自己在干什么，要知道的话style绝不会C风格，Python的风格关乎
: 效率。别的不说，就是C来写，那个判断nonascii的循环，用得着多次赋值1么？逻辑是
: 没错，我看着都蛋疼，就算小学生读了谭浩强的大毒草来写C，也不至于写成这样吧
|
d********g
发帖数: 10550 | 25 A && B || C都不理解，你怎么学的C啊
【在 f******y 的大作中提到】
: 谁这么写程序的，只能说他C写的也不怎么样。
|
p**o
发帖数: 3409 | 26 >>> from string import ascii_letters
>>> from operator import contains
>>> from functools import partial
>>> strip_nonascii = partial(filter,partial(contains,ascii_letters))
>>> strip_nonascii('a1b2c3d4e5')
'abcde'
这样写够"pythonic"不？lol
你管人家写成怎样，能work就行 |
p**o
发帖数: 3409 | 27 ''.join(c for c in orig_str if c in ASCII_LETTERS)
【在 d********g 的大作中提到】
: 更省的办法是避免多次ord()调用
: import string
: ASCII_LETTERS = string.ascii_letters
: s = ''.join([c for c in orig_str if c in ASCII_LETTERS])
: 不过意义不是很大
|
j******g
发帖数: 436 | 28 你为什么要吐血，和你有什么关系吗？这代码在他们的场景下有问题吗？你觉得这是代
码的问题，还是资源的问题？
Linux
【在 d********g 的大作中提到】
: 那代码里除了风格，别的常识错误太多了
: 第一file是内置函数，string是内置库。是可以强制赋值成别的对象，但是这种用法你
: 不捉急吗？那个组本来是做硬件的，Python用来写API，要不是我看到了顺手把关一下
: ，这种质量的code ship之后产品就卖出来了，还得WSN去折腾报告bug
: 第二个不用T/F而用0/1，这太明显的C霸王硬上弓了，捉急呀
: 第三字符串直接循环相加，虽然有些实现比如CPython是有优化的，但不是所有。这要
: 是循环十万遍，那可是要生成十万零一个字符串对象的（不说垃圾收集）
: 第四path join不用os.path.join()，直接字符串相加，这……就算100%肯定是在Linux
: 上运行，也不能这么山寨吧。我太为他捉急了
: 第五写Python的确实看不惯啰啰嗦嗦的写法。filepath那个就算这种错误的字符串操作
|
c*******y
发帖数: 1630 | 29 看那个python speed faq就行了，说这么多干嘛啊。
有些只是他不知道python的实现，不知道效率问题，给他发个link就行了。
http://wiki.python.org/moin/PythonSpeed/PerformanceTips
风格？效率高了，是不是pythonic，谁care啊。
【在 d********g 的大作中提到】
: 下面这个捉急的片段，看有多少是用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:
|
i***r
发帖数: 1035 | 30 加个括号不是更readable么
【在 d********g 的大作中提到】
: A && B || C都不理解，你怎么学的C啊
|
|
|
d********g
发帖数: 10550 | 31 用internal implementation来指导用法，C难道还能笑别人？随便一个简单例子：swap
指针地址来swap值，这比直接swap值要高效吧？
internal
【在 w*********l 的大作中提到】
: 不觉得。你这个每次+=都生成一个新的object不是一个显然的决定， 你是把internal
: implementation拿来反过来指导用法。C没关系，反正什么都透明，学的OS跟
: architecture已经基本上给你sense怎么写比较快。
:
: manipulation
|
d********g
发帖数: 10550 | 32 你这不就是in操作吗，一个道理
【在 p**o 的大作中提到】
: >>> from string import ascii_letters
: >>> from operator import contains
: >>> from functools import partial
: >>> strip_nonascii = partial(filter,partial(contains,ascii_letters))
: >>> strip_nonascii('a1b2c3d4e5')
: 'abcde'
: 这样写够"pythonic"不？lol
: 你管人家写成怎样，能work就行
|
d********g
发帖数: 10550 | 33 对，用generator会更省
【在 p**o 的大作中提到】
: ''.join(c for c in orig_str if c in ASCII_LETTERS)
|
j******g
发帖数: 436 | 34 为什么？swap值可以用register实现，swap地址，对应数据必须在内存里面。
swap
【在 d********g 的大作中提到】
: 用internal implementation来指导用法，C难道还能笑别人？随便一个简单例子：swap
: 指针地址来swap值，这比直接swap值要高效吧？
:
: internal
|
d********g
发帖数: 10550 | 35 Python的swap还可以这样呢：
a, b = b, a
这和C的指针swap一样，才是internal implementation指导用法的典型例子
【在 j******g 的大作中提到】
: 为什么？swap值可以用register实现，swap地址，对应数据必须在内存里面。
:
: swap
|
N********n
发帖数: 8363 | 36
这都啥馊主意啊，你咋知道只有俩指针IN THE PLAY？如果还第三个指针指
向其中任何一值你这SWAP指针岂不是漏了。您这两下子还点评C编程，LOL.
【在 d********g 的大作中提到】
: 用internal implementation来指导用法，C难道还能笑别人？随便一个简单例子：swap
: 指针地址来swap值，这比直接swap值要高效吧？
:
: internal
|
d********g
发帖数: 10550 | 37 这就奇怪了，你自己写的没几行的代码居然都不知道用了几个指针，那你最后还怎么
free呢？就您这两下子还玩指针呢，C是跟VB老师学的吧，LOL
【在 N********n 的大作中提到】
:
: 这都啥馊主意啊，你咋知道只有俩指针IN THE PLAY？如果还第三个指针指
: 向其中任何一值你这SWAP指针岂不是漏了。您这两下子还点评C编程，LOL.
|
j******g
发帖数: 436 | 38 我的看法是指针操作是很不好的行为。不过也不重要，很多时候能够省一半的开发时间
，比2x speedup重要的多了。就比如你举得例子吧，你也不会真正evaluate对整个系统
有多大的影响，去看instructions究竟发生了什么。
【在 d********g 的大作中提到】
: Python的swap还可以这样呢：
: a, b = b, a
: 这和C的指针swap一样，才是internal implementation指导用法的典型例子
|
z********0
发帖数: 9013 | 39 指针在C里谈不上Internal Implementation吧。。。
【在 d********g 的大作中提到】
: Python的swap还可以这样呢：
: a, b = b, a
: 这和C的指针swap一样，才是internal implementation指导用法的典型例子
|
N********n
发帖数: 8363 | 40
能SWAP VALUE谁没事SWAP指针？假如有多个指针SWAP VALUE一次就解决，用
你的方法方法还得把每个指针都SWAP一遍。自以为聪明结果搬石头咋自己脚，
连这都想不明白还指点C 编程，HOHO.
【在 d********g 的大作中提到】
: 这就奇怪了，你自己写的没几行的代码居然都不知道用了几个指针，那你最后还怎么
: free呢？就您这两下子还玩指针呢，C是跟VB老师学的吧，LOL
|
|
|
t****a
发帖数: 1212 | 41 上面一位朋友的帖子用函数式风格来写python
def StripNonAscii(self, non_ascii_string):
striped_str = ''.join([c for c in non_ascii_string if ord(c) < 128])
return (striped_str, (striped_str == non_ascii_string))
本质上就是转换string为list，do filtering，then apply join function on it。非
常典型的函数式风格。
python为了保持对fortran c系列冯诺伊曼式语言的兼容，保留了mutable方式的写法，
可能因此才会有楼主的例子中s += c这种低效code的出现，可叹。 |
f******y
发帖数: 2971 | 42 懒得跟一个写python的人争这些，继续写你的python好了。你认为那种写法好，你就那
么写python。
【在 d********g 的大作中提到】
: A && B || C都不理解，你怎么学的C啊
|
j******g
发帖数: 436 | 43 s+=c 表达的意思非常明确，理论上编译器应该对其优化的，不过可能python本身的局
限性决定的。
【在 t****a 的大作中提到】
: 上面一位朋友的帖子用函数式风格来写python
: def StripNonAscii(self, non_ascii_string):
: striped_str = ''.join([c for c in non_ascii_string if ord(c) < 128])
: return (striped_str, (striped_str == non_ascii_string))
: 本质上就是转换string为list，do filtering，then apply join function on it。非
: 常典型的函数式风格。
: python为了保持对fortran c系列冯诺伊曼式语言的兼容，保留了mutable方式的写法，
: 可能因此才会有楼主的例子中s += c这种低效code的出现，可叹。
|
m*******l
发帖数: 12782 | 44 任何没有优化的编译器应该说是不是一个合格的编译器
【在 j******g 的大作中提到】
: s+=c 表达的意思非常明确，理论上编译器应该对其优化的，不过可能python本身的局
: 限性决定的。
|
y*******g
发帖数: 6599 | 45 解释器呢
【在 m*******l 的大作中提到】
: 任何没有优化的编译器应该说是不是一个合格的编译器
|
d********g
发帖数: 10550 | 46 我写C的时候你写拼音，我写Python的时候你终于开始写C了。不知道你啥时候开始写
Python，呵呵
【在 f******y 的大作中提到】
: 懒得跟一个写python的人争这些，继续写你的python好了。你认为那种写法好，你就那
: 么写python。
|
q*c
发帖数: 9453 | 47 这么直白的语法， 多用了 120 bytes. 少死亡 120 脑细胞。
就看你觉得你的脑细胞值钱， 还是计算机的内存条值钱了。
一切玩弄奇技淫巧的玩意，开始能被一群 nerd 喧嚣一时， 但是
longrun 最后在 c & java 的易用性直白性王道面前， 都是土鸡瓦狗。
【在 d********g 的大作中提到】
: 下面这个捉急的片段，看有多少是用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:
|
q*c
发帖数: 9453 | 48 and his code is as simple and easy to understand as water.
so we drink water everyday, and for 1 MM years, and probably forever.
but no drink/wine/etc will ever last.
it
【在 c****e 的大作中提到】
: I know immutable. But it's python's complier's job to optimize this.
: javascript used to be slow to s+=, now it's even faster than stringbuidler
: because people like to write in that way.
: I agree the way he wrote is not every FP. where|join can make code more
: expressive. But my point is even his code is verbose, as long as it works it
: could be fine. I don't know your concrete story, but don't laugh at
: novince. He might just need a little bit practice and learn a few
: conventions.
: Back to the post, let's not start perf discussion on python.
|
q*c
发帖数: 9453 | 49 这些同学还在玩弄奇技淫巧因此洋洋得意的阶段。就像当年的手工作坊写小程序玩弄技
巧， 以陈序难懂为荣。
觉得自己的奇技淫巧比别人多了两样， 因此有某种隐晦的快感。 呵呵。
【在 d********u 的大作中提到】
: "风格关乎效率"的语言是没生命力的。说难听点儿，就是玩具。
|
q*c
发帖数: 9453 | 50 那样就没有 "Style" 了。
【在 i***r 的大作中提到】
: 加个括号不是更readable么
|
|
|
t****a
发帖数: 1212 | 51 呵呵，类比一下数学，这就好比已经有f(1)+f(2)+...+f(n)的表示法以后，人们还要使
用sum_i^n{f(i)}的表示法。不要恶意揣测啊。
前面有位朋友说的对啊，用简单的符号来表示以后，优化是编译器的责任，现在显然还
有距离。
【在 q*c 的大作中提到】
: 这些同学还在玩弄奇技淫巧因此洋洋得意的阶段。就像当年的手工作坊写小程序玩弄技
: 巧， 以陈序难懂为荣。
: 觉得自己的奇技淫巧比别人多了两样， 因此有某种隐晦的快感。 呵呵。
|
m*******l
发帖数: 12782 | 52 类比就是诡辩,
你这个类比根本不对
程式语言和非程式语言是矛盾的两个方面,不是互相替代的关系
是互补的,不是互赤
【在 t****a 的大作中提到】
: 呵呵，类比一下数学，这就好比已经有f(1)+f(2)+...+f(n)的表示法以后，人们还要使
: 用sum_i^n{f(i)}的表示法。不要恶意揣测啊。
: 前面有位朋友说的对啊，用简单的符号来表示以后，优化是编译器的责任，现在显然还
: 有距离。
|
g****n
发帖数: 40 | 53 高人！
【在 g*****g 的大作中提到】
: 不懂python，但regex不就一行的事情吗，大多数语言都支持。
: String.replaceAll("[^\x00-\x7F]", "")
|
d********g
发帖数: 10550 | 54 有些人脑子是不好使，这里说的Python不应该用C的思想来写，到你这变成Python和C来
PK了
好比川菜粤菜都好吃，你妈现在居然有人非要用泡椒做叉烧，还说凭什么叉烧不能用泡
椒，你尝出来味道不对是舌头的问题，反正最后拉出来都是屎，舌头要优化好，吃什么
都是香的，一切其它菜系在川菜的强大攻势前都是土鸡瓦狗。我看这脑细胞都死光了才
能这么说吧
【在 q*c 的大作中提到】
: 这么直白的语法， 多用了 120 bytes. 少死亡 120 脑细胞。
: 就看你觉得你的脑细胞值钱， 还是计算机的内存条值钱了。
: 一切玩弄奇技淫巧的玩意，开始能被一群 nerd 喧嚣一时， 但是
: longrun 最后在 c & java 的易用性直白性王道面前， 都是土鸡瓦狗。
|
d********g
发帖数: 10550 | 55 别五十步笑百步了，“玩弄奇技淫巧”的语言首推C，如果连这个都认识不到，那还是
怪入门错找了体育老师吧
【在 q*c 的大作中提到】
: 这些同学还在玩弄奇技淫巧因此洋洋得意的阶段。就像当年的手工作坊写小程序玩弄技
: 巧， 以陈序难懂为荣。
: 觉得自己的奇技淫巧比别人多了两样， 因此有某种隐晦的快感。 呵呵。
|
d********g
发帖数: 10550 | 56 我觉得连默认优先级都搞不清楚的，还是别编程比较好
【在 q*c 的大作中提到】
: 那样就没有 "Style" 了。
|
w*********l
发帖数: 1337 | 57 跟你说了有了OS跟Architecture的基础这个完全可以自己想出来 － 一个是一两条指令
做完，另一个要串拷贝。你那个＋＝生成新的有这么显然吗？
swap
【在 d********g 的大作中提到】
: 用internal implementation来指导用法，C难道还能笑别人？随便一个简单例子：swap
: 指针地址来swap值，这比直接swap值要高效吧？
:
: internal
|
p**o
发帖数: 3409 | 58 这叫 generator expression，
generator 指的是带yield的函数
【在 d********g 的大作中提到】
: 对，用generator会更省
|
f******y
发帖数: 2971 | 59 相反我认为C的东西很直白，可能对你来说有点复杂。
【在 d********g 的大作中提到】
: 别五十步笑百步了，“玩弄奇技淫巧”的语言首推C，如果连这个都认识不到，那还是
: 怪入门错找了体育老师吧
|
f******y
发帖数: 2971 | 60 我每次都加括号，编程编的好好的，从来不因为这个出bug。
你这么注重那些东西，应该是谭浩强教出来的吧。
【在 d********g 的大作中提到】
: 我觉得连默认优先级都搞不清楚的，还是别编程比较好
|
|
|
d********g
发帖数: 10550 | 61 A && B || C直白得令人发指，我不知道为什么对你来说那么复杂？笑死了
【在 f******y 的大作中提到】
: 相反我认为C的东西很直白，可能对你来说有点复杂。
|
d********g
发帖数: 10550 | 62 连顺序都搞不清楚的还能编得好？这基本功也太差了，a++和++a对你来说都一样吧。建
议你先去找谭浩强教教……
【在 f******y 的大作中提到】
: 我每次都加括号，编程编的好好的，从来不因为这个出bug。
: 你这么注重那些东西，应该是谭浩强教出来的吧。
|
f******y
发帖数: 2971 | 63 我也没说复杂，只是上来confirm一下。而且我在原问题里把逻辑简化成这个的，如果
你看到原来的code有很多层的判断放一起这种写法其实很差。
另外你一直抓着这个对你的编程有帮助吗？
【在 d********g 的大作中提到】
: A && B || C直白得令人发指，我不知道为什么对你来说那么复杂？笑死了
|
f******y
发帖数: 2971 | 64 发现你从头到尾整个贴里一直都在臆想，这个也算是行艺了吧？
【在 d********g 的大作中提到】
: 连顺序都搞不清楚的还能编得好？这基本功也太差了，a++和++a对你来说都一样吧。建
: 议你先去找谭浩强教教……
|
d********g
发帖数: 10550 | 65 A && B || C或者A and B or C我早就理解了，对我的编程当然没有任何帮助，对你的
编程应该还是有一定帮助的。你拒不接受好心人帮助，是什么心态呢？
【在 f******y 的大作中提到】
: 我也没说复杂，只是上来confirm一下。而且我在原问题里把逻辑简化成这个的，如果
: 你看到原来的code有很多层的判断放一起这种写法其实很差。
: 另外你一直抓着这个对你的编程有帮助吗？
|
f******y
发帖数: 2971 | 66 btw，后来我又去看那人的code，他已经自己加上括号了。他知道你在这里的行为肯定
很感动。。。
【在 f******y 的大作中提到】
: 我也没说复杂，只是上来confirm一下。而且我在原问题里把逻辑简化成这个的，如果
: 你看到原来的code有很多层的判断放一起这种写法其实很差。
: 另外你一直抓着这个对你的编程有帮助吗？
|
d********g
发帖数: 10550 | 67 你臆想的那也太多了，以为这世上就你一个人写C，呵呵。我原帖可是说的Python里不
能用C的思想/习惯来写，到了你这变成Python与C掐架了
【在 f******y 的大作中提到】
: 发现你从头到尾整个贴里一直都在臆想，这个也算是行艺了吧？
|
f******y
发帖数: 2971 | 68 我也没掐架啊，只是指出来让写C用python的习惯也不行。
【在 d********g 的大作中提到】
: 你臆想的那也太多了，以为这世上就你一个人写C，呵呵。我原帖可是说的Python里不
: 能用C的思想/习惯来写，到了你这变成Python与C掐架了
|
c*********n
发帖数: 182 | |
L***n
发帖数: 6727 | 70 写C没法用python的习惯吧，C不支持fp
【在 f******y 的大作中提到】
: 我也没掐架啊，只是指出来让写C用python的习惯也不行。
|
|
|
m*******l
发帖数: 12782 | 71 C supports Functions though
【在 L***n 的大作中提到】
: 写C没法用python的习惯吧，C不支持fp
|
g*******t
发帖数: 7704 | 72 代码的最重要的是维护容易， 那种精炼的语句都不适合维护， |
i***r
发帖数: 1035 | 73 其实，我觉得记得 PEDMAS差不多就够了，能够记得多自然是好事
但是几十个operator，也许你熟悉这几个，我熟悉那几个 ---- 看彼此的code还要
google一下不是？
懂C的来看python，还要google一下不是？
【在 d********g 的大作中提到】
: 连顺序都搞不清楚的还能编得好？这基本功也太差了，a++和++a对你来说都一样吧。建
: 议你先去找谭浩强教教……
|
m*******l
发帖数: 12782 | 74 pemdas
【在 i***r 的大作中提到】
: 其实，我觉得记得 PEDMAS差不多就够了，能够记得多自然是好事
: 但是几十个operator，也许你熟悉这几个，我熟悉那几个 ---- 看彼此的code还要
: google一下不是？
: 懂C的来看python，还要google一下不是？
|
i***r
发帖数: 1035 | 75 呵呵，见笑了
【在 m*******l 的大作中提到】
: pemdas
|
