之前为了做服务器日志过滤，纠结了好久perl和python哪个好，手上现成的老脚本全是perl写的，新需求又有人劝我直接上python，那段时间来回折腾，脑子里面两种写法搅在一起，经常写着写着就串了语法。

拿到日志文件的那天，先试着沿用之前的路子，拿perl来写正则提取字段，那些匹配行、截取内容的写法随手就能敲出来，符号短，不用额外导入一堆模块，简简单单几行代码就能抓出来我想要的ip和状态码，跑起来的时候处理大文本文件，速度看着也挺顺。当时还觉得，怪不得老运维都偏爱perl，处理这种流式文本，写起来好像没什么多余负担，不用考虑太多额外的东西，正则直接嵌在语句里面，不用单独拆出去定义。

麻烦是后面才冒出来的。

改第二版的时候，要在原有逻辑上加异常判断，还要把解析出来的数据整理好，输出成表格格式给别的同事拿去看。顺着perl往下写，代码慢慢就变乱了，变量到处飘，注释少一点，隔半天回头再读，自己都要花时间猜当初这一段是想做什么。想给字段加校验，写出来的代码层层嵌套，看着乱糟糟的，改一处，生怕别的地方跟着崩掉，翻网上的例子，写法也是五花八门，每个人的编码习惯差的很远，很难找到统一的思路。

抱着试一试的想法，把同样的解析逻辑用python重写了一小段。

导入re模块之后，正则写起来规矩很多，代码一行一行看得明白，定义好函数，每个函数只做一件小事，哪个地方是读取文件，哪个地方做匹配，哪个地方组装输出，边界分得清清楚楚。同事过来接手的时候，扫几眼就能看懂流程，问的问题也少了很多。可也不是全都顺心，处理超大的日志文件，一次性读入的时候，内存占用明显比perl那边高，同样一份几个G的日志，perl脚本跑完很快就释放资源，python这边要是没写生成器，跑一会就告警内存超标，还要单独调整读取的方式，一行一行迭代读取，才能稳住。

有一回赶紧急需求，临时要加一个简单的过滤规则，随手用perl加两行正则，十几分钟就上线跑起来了，当时还感慨，这种临时一次性的小脚本，perl确实顺手，不用搭建什么环境，服务器上基本默认就装好了，拉过来直接执行。但是后面这个需求慢慢迭代，不停新增过滤条件、对接数据库、生成可视化统计，perl的代码越堆越难维护，每次加功能都要小心翼翼，生怕把之前的匹配逻辑改坏。

身边做运维的老大哥，一直坚持用perl处理文本，说它在文本处理这块底子厚，简洁利落，适合快速写一次性工具；做开发的朋友就偏向python，说生态全，不管后续要对接什么工具、做统计画图，都能找到现成的包，长期维护省心很多。听他们聊的时候，也没法直接说谁更好，只是自己踩过这些坑之后才明白，这俩东西适合的场景本来就不一样。

试过把perl脚本封装，给它加上规范的注释和结构，写起来就失去了它原本简短轻便的优势，变得又长又啰嗦；硬把python写得很精简，堆砌一行式的写法，又丢掉了它可读性强的长处，读起来一样费劲。

后来也没有一刀切换掉哪一个，临时应急、简单文本抓取的活，偶尔还是会敲几行perl；只要是后续会反复修改、多人维护，或者还要对接别的程序的任务，就老老实实选用python。这个选择只是贴合我手上这些活，换做别人，手上的项目不一样，感受大概率完全不同，仅代表我个人情况，不同场景、不同人的体验会存在差异。

那天忙完很晚，关掉终端的时候，屏幕上一边是perl简洁的脚本，一边是python分层的代码，没有哪个是完美无缺的，只是各自适配不一样的麻烦。