class io.BytesIO([initial_bytes])
A stream implementation using an in-memory bytes buffer.

raw_file 是文件流，如果 open 时如果是 rb 的， buffering=-1 的，则使用内置的 chunked buffer ，这是针对你参数的结果。

从 file.read(1)上看，都是从 file 流里取 1 个字节。从效率上看， BytesIO 是内存访问， raw_file 是 buffer+Filesystem io 的结果，所以貌似慢一点。

但这都不是正确的打开方式，要效率高就要 chunk 读，减少 FS IO 和循环次数。 BytesIO 更大的意义在抽象层次上， fs 和 buffer 都能通过 file io 访问，是不是 test 的时候简单一点？

如果错误请指正，欢迎探讨。 -)

通信协议不是项目负责人定的吗？再不济，前后端和负责人一起讨论。哪有开发过程中前后端通信约束都没有，后端应该给什么，前端要什么都不定，那还做什么项目？！前后端负责人都炒掉算了。

主题就是粗体字，楼主真能写！

轻耦合，高内聚。
往这 2 个靠准没错

《禁室培欲》宿舍版

第一句话是对的，后面的话无法验证第一句

周六发现developer.apple.com和github刷不出来，打电话去电信骂了他们一通; 周日他们上门服务，我人在外头，打电话交流，我说你们是不是搞个什么国际加速的，要加钱的，工作人员说我误解了，是什么香港线路在调整...

我误解了吗？！

@typcn swift安全锁是什么东东？

男人应该从内而外的保养。试试看朵尔，非软文

@laoyur 其实git-flow的概念还是蛮简单的:
git flow会有以下分支概念:
master
develop
feature
release
hotfix


master是主分支，就是程序当前stable版本分支
develop是开发分支
feature分支是特性分支，由develop branch而来（git flow feature start xxx），结束后（git flow feature finish）合并进develop
release是发布分支，develop到一定程度需要发布版本了，那么通过git flow release start xxx， 生成一个发布分支，在分支上修改版本号啥的，或者按照生产环境再测试一下，然后git flow release finish xxx, 它会将修改合并进develop和master，并生成tag.
hotfix没怎么用过，避免错误就不说了。

多人协作的话，一般在远程版本库保留master和develop分支即可，每个开发者在本地可以创建feature分支进行开发，然后push进develop，到时由主管项目人员进行release步骤即可。

我就是这么用的，挺简单方便的，希望对你有帮助

我来安利git-flow

"点评极客"，乍一看以为是“吐槽极客”，不是挑战谁最会吐槽，谁最会点评吗？！
看内容才发现我脑洞开反了。

90年代听四大天王，现在听王杰，伍佰

徐家汇公园

GlobalSign怎么样？

我有一点疑惑，现代语言，撇开执行效率，开发者看中的就是语法和标准库，swift的语法个人感觉还是挺合理的，比golang要好，但是标准库就有问题了:
https://developer.apple.com/library/prerelease/ios//documentation/General/Reference/SwiftStandardLibraryReference/index.html
这种标准库只能说是基本类库，不能和golang相比。
在ios/osx上，库是依靠原来的cocoa/cocoa touch支撑起来的。
那开源后的swift，纵有合理的语法，没有丰富的标准库，对其在linux上的前景表示疑虑。

@Axurez 为什么是弱类型？你指C的隐式参数类型提升吗？