python 是去年四月开始到去年九月利用课余时间自学的。因为在平时工作中鲜有用途，因此之后几乎再没更新过了。
之前写过大约十篇左右浅显的笔记，大部分也是从廖雪峰那里自学后记述的。都放在为知上。现在准备搬到简书上来，也当重温一遍吧。
图灵丛书里面的python那本还是不错的，很多基础的语法还是从那里面看下来的。

个人看法

python是一门较为友好的语言，比起objective c要简单的多。因为有许许多多的第三方库作支持，在我们熟悉基础语法的情况下，python作为胶水可以做很多跨语言，跨平台的实现。

实践

自学期间从一开始热情满满，到之后觉得python就目前的工作而言，无用武之地，颇有些心灰意冷。
公司在职期间，用到python的也就3次

• 在windows平台导出了一个.exe 用来作控制台，对于那时候比较多的设备端调试，要用到诸如PC端下载工具、设备管理器,常用文件夹,笔记文档,支付相关文档之类的很多文件夹。相比起Mac端有Alfred这样的神器而言，windows端实在是乏善可陈。
  具体用到的第三方库和类我已经记不大清了，之后的笔记中会有补完。

  • 实现方式：在本地磁盘的某路径下创建一个excel文档(python有专门的创建/读写excel的库)，对上述的特定文件/文件夹/.exe路径作相应的保存。通过python自带的库打开对应路径的文件。
  • 页面布局。python没有像MFC或我们iOS/Android下的控件拖曳(貌似也有，当时我还没找到？)，直接通过代码来绘制GUI.
  • 打包和导出成应用。python的源码运行是可以跨平台的，但是我们想封装成对应的可执行文件,(windows下的.exe, Mac下的.app)需要专门的py库，执行起来是有一定繁琐的。
  • 最后使用应用的感受：一个c++/MFC的简单应用生成出来也许只要几百KB的东西，python打包出来需要20多M。原因还是在于C/C++是接近底层的语言。而python需要经过一层解释器转化成C，所以打包的时候大部分的大小都在这个依赖库中去实现。由于当时写这些应用更多的是为了熟悉python练手，真正应用生产当初还是会使用MFC作为首选。

• 另一个应用是SN号的生成和转化。在POS的数据传输过程中，经常会用到数据值之间的转化(ascii转hex, 转string等等)，当时简单的做了一个exe应用用来将连接USB后得到的SN号进行数据类型转化并输出，提升工作效率。这里不作赘述。

• 最后一项还蛮意外的，就是两个月前发生的。公司的蓝牙回联测试，老外发了一份.py过来，说国外客户那边通过这个执行文件可以绕过bluetooth 2.0配对，直接通过mac地址去回联设备。因为我那一阵子经常得瑟穿着一件 python 的T恤，领导直接将代码和工程丢给我，让我去搭建环境。一下子懵逼了，几乎快一年没有碰python，很多基础语法全部忘光，还要在一台老掉牙的windows设备上，一个晚上搭建开发环境，复现问题。我几乎是一路冷汗按下去做出来的。还好，最后结果还不坏（没让我去深入研究python的工程代码已经算万幸）

感慨

• python在国外非常流行。我的很多国外的同学，都对此有所耳闻，甚至已经成了python的票友，在科研甚至工作中用上了python。用他们的话说，在这个全民抠腚(coding)的时代，python这条大蟒蛇还是具备这个让编程日趋平民化的魅力和条件的。
• 然而在国内，大约是北上广这些地方python的工资很高，也很流行。相对于已经开始走下坡路的iOS/Android应用开发，python仍然乘着前端兴起的浪潮大行其道。可是在福州，python仍是一门讳莫如深的语言，像swift一样被企业束之高阁。我曾听同事提起到他在上家公司的遭遇：

他的一位前同事将部分服务端代码改为python，被领导劈头盖脸大骂，言之凿凿的说到别人已经用其他语言写好了（抱歉，前端的情况我并不很了解，复述时不免出现偏差），你为甚么还要重写一遍？等你走了，谁还会改这个代码？

非常现实的问题摆在面前。大多数程序员都是价格导向的。虽然我们需要也推崇钻研和匠人精神，只是脚踏实地的生活着，任何一个人能在没有氛围和环境的情况下去学习一门暂时还用不上的语言吗。

最后

整理python的笔记，也是为了让东西不要放在本机而是存在网络上相对安全。不过就目前而言，学习python的意义远没有学习js的动力来的大。

码代码是一门手艺活，也需要有原动力来撺掇。
如是。