Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

接触 Python 后的一点感受记录

Posted on 03/25/201806/23/2019 by 四火

python最近因为工作的关系开始学习 Python 了。以前从不曾正儿八经地学过,如果说工作学习经验带来改变的话,那么编程语言的学习就是个很好的例子。如果在十年前,我要学习 Python 的话大概会买本系统介绍的 Python 教程,然后一页一页慢慢看,估计能够啃完大半本,跳过一些自认为次要的特性。等到在项目中使用已经得是一两个月之后了吧。但是如今我显然不太会做一样的事情,我现在会拿着我那些熟悉的编程语言来比较,不同的特性上面,Python 是怎样的,是先进还是落后,适合解决什么问题,在哪些领域可以大行其道,但在遇到哪些问题的时候事倍功半。

想起以前接触过的编程语言里,事实上有一半都不能算系统地学过,大致上只是零散地入了门,就开始在项目中使用了。自然,也不可能花很多时间琢磨透了再使用,靠的是时间和经历一点点地积累。这个世界变化太快,已经没有时间把每一步都踩扎实。这就是现实,有时候也未必是件坏事。很多人觉得大学里对编程语言的学习不值一提,因为象牙塔和工业界完全是不同的概念。但是我倒觉得,如果只考虑同等长度的时间范畴,大学里的学习经历,才是更有影响力的那一个。工作快十年了,变化的东西太多,不变的也不少——看到一群程序员聚在一起进行语言的圣战,在几年前我可能会表达 “不同的工具有不同的应用场景” 这样看起来中立而不带无脑倾向的废话。不过现在我可能什么都不会说,但是饶有兴致地驻足观看这样的圣战,有时候是骂战。

首先,拿 Python 和以前学过的语言比较来看。我觉得和 Groovy 比较接近,特别是语言的动态性。我确信它的学习曲线也是比较简单的。在 Linux 平台上作为脚本语言很容易使用,往往不需要准备什么预装什么,这和其他脚本语言比起来,便有着不可替代的优势。单纯就语言层面上,Python 和 Bash 比起来它的代码组织性更好,和 Perl 比起来则没有那么多啰嗦的语法,代码更容易理解。仅由目前所掌握的这一点点知识来看,特别喜欢其中 yield 关键字的设计,让一些本来需要反复在不同方法上下文中切换的面条代码变得清晰和优雅,这也是我在其它语言中没有见过的。

下面的内容是作为一个初学者的一点点记录,觉得 Python 中有趣的几点,以及项目中使用的一些感受。

首先,关于缩进。这大概是第一个缩进具备实际意义的编程语言了,缩进不仅仅是用于帮助理解和美观需要了。对于痛恨满天遍地括号的程序员来说,似乎是一种解脱。

Tuple。Tuple 的最直接好处是不可变,它时常也被作为容器不同格式之间转换和过渡的媒介,再一个,正因为有了 Tuple,让函数 “看起来” 具备多个返回值也就变成了可能,以前在 Scala 中也使用过。印象中传统语言里面没有这样原生的东西,比如 Java 的 final 关键字除了不可变以外并不具备 Tuple 其它的特性。

可变参数:在 Java 中可变参数其实就是一个数组的语法糖,二者本质上没有什么区别。所以可以传一个数组给变参方法,数组会被准确解析成变参;反过来转换也一样——在变参方法中,变参一拿到手就已经是一个数组了,Python 为了变参更舒服地调用而设计了展开符号——*。**则是关键字参数,和*被解析成 [] 不同的是,**被解析成 {},这个我在别的语言里面似乎没有见到类似的。如果不是说方法定义,而是说方法调用,那么它似乎和 JavaScript ECMA 6 中的…类似,可以传递若干键值对(命名参数)。

尾递归优化(Tail Recursion Elimination, TRE)。这其实可以作为语言分类上的一个重要特性,Python 不支持尾递归优化,后续有机会再单写一篇来详细谈谈。

List Comprehension。我第一次接触它是在 Haskell 里(曾经写过一点点东西涉及到它)。它让代码的简洁程度到达一个新的级别,比如下面这样的两个例子:

[x * x for x in range(1, 100) if x % 2 == 1]
[m + n for m in ‘123' for n in 'abc']

从 yield 到 generator。yield 这个关键字不仅仅可以让函数多次返回,虽说这已经是一个颇为有趣的事情了,我在其他语言中我没有见到过。它还可以让函数变成 generator——其中一种简单的定义方法是,如果函数定义中包含 yield,那么它就成为了一个 generator,用于不断生成结果并返回。函数是顺序执行,遇到 return 语句或者最后一行函数语句就返回。而变成 generator 的函数,在每次调用 next() 的时候执行,遇到 yield 语句返回,再次执行时从上次返回的 yield 语句处继续执行。看这个例子:

def _odd_iter():
    n = 1
    while True:
        n = n + 2
        yield n

def m_of_three():
    iter = _odd_iter()
    while True:
        n = next(iter)
        if n%3 == 0:
            yield n

for n in m_of_three():
    if n < 100:
        print(n)
    else:
        break

例子中第一个 generator _odd_iter 用来返回从 1 开始的所有奇数,而 m_of_three 生成器用来过滤并返回其中 3 的倍数,最后一部分则是打印逻辑,打印 100 以内的结果。这个例子体现了 generator 的使用,也体现了它对无限序列的支持。

模块的灵活性和自解释能力。这也是我相当喜欢的一个特性。在 Python 中有这样的规约,一个下划线开头表示私有变量,两个下划线开头表示 Python 自身预定义的一些变量,这样的规约即保留了违背规约访问和使用这些变量的灵活性,也提供了很多预定义变量的可能。其中一个是模块的__init__.py,类似于 Java 的 package.java,但是提供了更多的特性,用以模块的自解释,比如标准注释、依赖、编码、文档注释和立即执行的 main 方法等等。

而实际开发的时候,借助 pip 和 virtualenv,可以说依赖和环境准备比多数语言都简单多了。

最后是 decorator,这个其实最早我实在 Groovy 中见到的,现在很多语言都支持注解,但是原生来看似乎 Python 是使用它支持特性最丰富的,这里不展开了。

在新的团队中,我们的项目比较特别,大部分的服务端代码都是用 Python 写的。我可以看到 Python 在开发效率上和环境搭建上的优势,从开发、测试、部署到调试,Python 都很易于使用,Linux 和命令行亲和力高,不需要很多额外的工具。总体来说,这一点在快速开发的场景下很吸引人。另一方面,Python 灵活和强调规约的特性,以及提供的元编程上丰富的支持,我以及好多次感到,在写代码的时候,可以用很简洁的代码,写出看起来有点复杂的特性。现在我接触的 Python 开源库还不多,随着学习的深入后续再慢慢研究和记录,但是有了 pip 等等通用的统一的包管理工具,这一切看起来似乎要比传统的 Java 和 C++要简单很多。

不过,Python 代码容易产生的问题不可谓不少。老实说,随着代码规模的增加,我更倾向于一个约束更强,类型系统严谨并且代码代码模板清楚统一的编程语言。Python 有些 “太过灵活”,无论是易读性还是分层/模块化,我都看到代码中有很多需要改善的地方。最常见的一个模式是,用 Python 写一堆有关联的类和方法,放在一个 py 文件里面,在开始的时候很不错,也避免了过度臃肿的类文件,但是很快,随着代码规模的增加,这个文件需要不断被拆分和重构,但是重构这件事情却不是那么容易推动的。程序员都知道,当我们说 “未来再扩展” 或者 “以后再改进” 的时候,这件事情多半是不会发生了——于是代码过度耦合就变成了一个问题。以往使用 Java 写代码的时候,项目组仿佛有约定俗成的理念,无论是分层还是类文件设计,往往在开始的时候都显得有些 “过度”,多层次的包、类设计,看起来似乎有些臃肿,但是随着代码规模的增加,好处就体现出来了,代码的单一职责这一要求维护得明显更好,在做某些修改的时候,需要评估的调查范围就小,代码修改也更清楚和易于评审者理解,修改者心里也更有谱。

显然这不能说孰好孰坏的问题,但是我对 Python 在中大规模项目(50 万行+)上的使用是有疑虑的。当然也许随着经验的积累我会有不同的看法。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(类型系统)
  2. 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(元编程)
  3. 一段集合操作的不同语言表达
  4. 从 Mac 下的包管理和安装工具说起
  5. 分析运行中的 Python 进程

11 thoughts on “接触 Python 后的一点感受记录”

  1. Jiajun Huang says:
    08/16/2019 at 4:42 PM

    Python 最大的问题的确是太灵活了。一个人拿起来做 demo 那速度是无可比拟的,但是一旦多人协作,然后项目历史悠久一点,问题就会显现出来。

    Reply
  2. 独酌逸醉 says:
    06/10/2018 at 9:29 PM

    个人觉得 Python 还是比较适合偏向于工具化的开发,项目一大,很难维护,测试覆盖不够的话,上线之后出现崩溃无法实时告警,我当初用 Django 做 Web 的时候,不得已在 url handler 上加了一个 decorator,全局添加 try…except 发生程序未捕捉的 except ,收集堆栈,然后告警。

    还有就是很多人引以为傲的依靠空格缩进来判定代码块,框架代码还好毕竟花时间优化,业务代码稍微长一点很正常,看起来真的头大。

    不过有一说一,Python 学习成本低、开发效率是真的高,创业团队还是可以使用 Python 技术栈的,等业务成熟以后再用 Java,Go 等逐渐替换掉。

    BTW,经常看你博客,提个小建议:在英文单词和中文之间加个空格,阅读体验更佳哦~

    Reply
    1. 四火 says:
      06/11/2018 at 11:35 AM

      谢谢。这个英文单词和中文之间的空格这个事情尚有争议,但是中文和英文之间至少应当保持间距这个我是认同的。不清楚有没有简便的方法,有空我会找一找。当然如果你有用过简便好用的 wordpress 插件也欢迎告诉我。

      Reply
      1. 四火 says:
        06/24/2018 at 1:37 PM

        FYI,已经解决了这个问题

        Reply
    2. aweffr says:
      02/18/2019 at 8:52 AM

      我们搭了一套 sentry 来监控业务告警, 非常好用

      Reply
  3. Sprinfall says:
    04/02/2018 at 9:28 AM

    动态语言在大型项目中都是挑战,Python 最成功的案例可能就是 Instagram 了。
    像 Type Hints (PEP 484) 这种特性,对于习惯了 C++、Java 的人来说,确实犹如福音,而且,了解 Haskell 的人一定会喜欢的。我坚定的认为,Type Hints 才是 Python 在大型项目中的生存之道。

    Reply
  4. 开发者头条 says:
    03/27/2018 at 8:51 AM

    您好,我是开发者头条的运营。您的《接触 Python 后的一点感受记录》已被我们平台用户推荐到首页。感谢您的辛苦创作,为了让更多读者认识您,我们邀请您来开发者头条分享。与创作不同,您仅需复制粘贴文章链接即可完成分享。您可以在各大应用市场搜索 “开发者头条” 找到我们的应用,欢迎了解。期待您的分享。

    Reply
  5. owenliang says:
    03/26/2018 at 10:17 AM

    oracle 用 python 做什么方面的项目,可以讲讲大概情况吗。

    Reply
    1. 四火 says:
      03/27/2018 at 6:07 AM

      我们有若干个不同种类的 Python 系统,都用于帮助 cloud instance 入栈。

      Reply
  6. laixintao says:
    03/26/2018 at 8:58 AM

    Python 单元测试很重要,要是没有单元测试,很久之前的代码回来看看的话什么都不敢动……

    Reply
    1. 小小陈 says:
      07/08/2019 at 12:17 PM

      pybook03

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Python Spark 互联网 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 程序员 管理 系统设计 缓存 编码 编程范型 英语 西雅图 设计 评审 问题 面试 项目

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Big Data and Machine Learning (5)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • + 1.943624 BTC.NEXT - https://graph.org/Ticket--58146-05-02?hs=9a9c6f8dfe3cdbe0074006e3e640b19b& on 所有文章
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
  • Dylan on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme