作者：chenjiandongx
一个执迷于写 bug 的程序员

pyecharts V1.0.0 版本正式发布啦！

What's New in pyecharts V1

pyecharts 经过了半年的沉寂后，终于发布了新版本啦！新版本号将从 v1.0.0 开始，这是一个全新的，向下不兼容的 pyecharts 版本。不过如果开发者以前接触过 pyecharts 的话，新版本对于你们来说也是会很容易上手的。新版本修复 N 个 0.5.x 版本留下来的 bug。

1. 全面拥抱 Python3 和 TypeHint

pyecharts v1 停止对 Python2.7，3.4~3.5 版本的支持和维护，仅支持 Python3.6+。如果还不知道什么是 TypeHint 的同学，劝你尽早入坑，官方入坑指南 typing — Support for type hints。

在编程界，早已流传着 动态一时爽，重构火葬场 这样的真知灼见，动态语言类型检查已经成为了一种趋势，Javascript 已经有了 Typescript，Python 也在力推 TypeHint，虽然 Python 的 TypeHint 实际上对于程序的运行并没有任何影响......，但它配合 IDE 和 mypy，或者 pyright 这样的工具可以在开发阶段趁早发现问题。

2. 弃用插件机制

pyecharts v1 废除原有的插件机制，包括 地图包插件 和 主题插件，插件的本质是提供 pyecharts 运行所需要的静态资源文件(基本都是 .js 文件)，所以现在开放了两种模式提供静态资源文件。

1. online 模式，使用 pyecharts 官方提供的 assets host，或者部署自己的 remote host。

2. local 模式，使用自己本地开启的文件服务提供 assets host(离线模式)。

弃用插件的理由

1. 原先的 pyecharts 插件机制分散，管理/升级并没有想象中的方便，而且分开为 jupyter/local render 两种情况，这就导致了两个要分开管理，虽然我们的 pip 包可以同时 update 这两种情况引用的 assets，但是由于存在缓存等因素，并不能保证每次都到正确的更新。

2. pyecharts 不用再依赖这些包，依赖包和 pyecharts 包版本的管理也是一个容易出问题的地方。

3. 减少维护工作，线上热更新。

3. 更加轻量级

新本的 pyecharts 只依赖了两个第三库，jinja2 和 prettytable。这意味着 pyecharts 总体的体积将变小，安装更加轻松，也可以很方便的进行离线安装，配合上面讲的 local 模式。

4. 支持原生 JavaScript

0.5.X 的版本，对原生 JavaScript 的支持还很局限，v1 版本彻底打通了任督二脉，支持传入任意的 JavaScript 的代码，任意的配置项回调函数。

5. 支持 JupyterLab

对 JupyterLab 的支持一直是很多开发者关心的功能，毕竟 JupyterLab 号称是下一代的 Notebook。pyecharts v1 开始支持在 JupyterLab 中渲染图表啦！

Jupyter Notebook

Jupyter Lab

6. 代码风格重构

所有配置项均 OOP，在新版本的 pyecharts 中，一切皆 Options。配置项种类更多，可操作性更强，可以画出更丰富的图表，pyecharts 官方画廊 pyecharts/pyecharts-gallery。

0.5.X 版本写法

from pyecharts import Bar
attr = ["衬衫", "羊毛衫", "雪纺衫", "裤子", "高跟鞋", "袜子"]
v1 = [5, 20, 36, 10, 75, 90]
v2 = [10, 25, 8, 60, 20, 80]
bar = Bar("柱状图数据堆叠示例")
bar.add("商家A", attr, v1, is_stack=True)
bar.add("商家B", attr, v2, is_stack=True)
bar.render()

v1 版本写法，支持链式调用，导包方式也发生了变化，所以不要再问为什么旧版的代码运行不了啦！因为两个版本根本就完全不兼容，当成一个新库来学的话会好很多。

import pyecharts.options as optsfrom pyecharts.charts import Bar
attr = ["衬衫", "羊毛衫", "雪纺衫", "裤子", "高跟鞋", "袜子"]
v1 = [5, 20, 36, 10, 75, 90]
v2 = [10, 25, 8, 60, 20, 80]
bar = (
Bar()
.add_xaxis(attr)
.add_yaxis("商家A", v1, stack="stack1")
.add_yaxis("商家B", v2, stack="stack1")
.set_series_opts(label_opts=opts.LabelOpts(is_show=False))
.set_global_opts(title_opts=opts.TitleOpts(title="柱状图数据堆叠示例"))
)
bar.render("bar_stack.html")# 当然不习惯链式写法的开发者仍旧可以使用
bar.add_xaxis(attr)
bar.add_yaxis("商家A", v1, stack="stack1")
bar.add_yaxis("商家B", v2, stack="stack1")
bar.render()

v1 版本不仅支持 Opts 配置项作为参数传入，同时也支持原生 dict 类型，也就意味着自己可以随意扩展 pyecharts(如果你对 Echarts 有一定了解的话)，而不用修改 pyecharts 源码。

bar.set_series_opts(label_opts=opts.LabelOpts(is_show=False))# 等价于
bar.set_series_opts(label_opts={"show": False})

具体参考 pyecharts/options 包。

7. 支持 selenium/phantomjs 渲染图片

非必须，如果无此需求的开发者可忽略，并不会影响正常的使用。

pyecharts v1 提供两种模式渲染图片，selenium 和 phantomjs，分别需要安装 snapshot-selenium 和 snapshot-phantomjs。

from pyecharts import options as optsfrom pyecharts.charts import Barfrom pyecharts.render import make_snapshotdef bar_chart() -> Bar:
c = (
Bar()
.add_xaxis(["衬衫", "毛衣", "领带", "裤子", "风衣", "高跟鞋", "袜子"])
.add_yaxis("商家A", [114, 55, 27, 101, 125, 27, 105])
.add_yaxis("商家B", [57, 134, 137, 129, 145, 60, 49])
.set_global_opts(title_opts=opts.TitleOpts(title="Bar-测试渲染图片"))
)return cdef render_chart_by_selenium():from snapshot_selenium import snapshot
make_snapshot(snapshot, bar_chart().render(), "bar0.png")def render_chart_by_phantomjs():from snapshot_phantomjs import snapshot
make_snapshot(snapshot, bar_chart().render(), "bar1.png")

8. 新增更多的图表类型

新增了图表类型和组件类型

旭日图

百度地图

很酷吧，你可以在 Notebook 环境中使用百度地图，指哪打哪，妈妈再也不用担心我地图不够用啦。

组件类型

9. 更加完善的文档和示例

经开发团队决定，0.5.x 版本将不再进行维护，问题依旧可以提，但基本不会解决。0.5.x 版本代码位于 05x 分支，文档位于 https://05x-docs.pyecharts.org。v1 版本文档位于 https://pyecharts.org。新版文档中提供了更加丰富的示例，帮助开发者更容易入手 pyecharts。

总结

此次的重构主要原因是我发现 pyecharts 以前的设计实在是太糟糕了，导致后来版本的更新一直都是在为这糟糕设计打补丁。在某一个夜深人静的夜晚，我下定了决心，他妈的，看不下去了，老子要重构，不要拦着我。在重构之前，正好那段时间在写 Golang，所以就写了一个 go-echarts，对 Golang 开发感兴趣的开发者也可以关注一下。后来觉得 go-echarts 的接口设计还不错，所以就搬到新版的 pyecharts 中来。新接口更加清晰，语义化。

在重构的过程中也产生了很多的思考，如何把接口设计得简单易用又有可扩展性，这个其实是有矛盾的地方在的，简单易用意味着要尽量封装实现细节，而可扩展性可定制性又意味着要尽量暴露底层接口，参数要灵活，但也不能直接就 *args, **kwargs，真心觉得，Python 这个传参方式被过度使用了，很多库为了追求方便，形参都是直接写的 foo(*args, **kwargs)，不仔细去阅读具体实现逻辑你根本不知道它需要传什么，然后传的值是什么类型.... 我个人的观点是，Keyword only+TypeHint 是最好的实践，别懒，多写几行代码，不然以后看起来连自己都懵。

开发和维护 pyecharts 花费了我巨大的心力，如果你觉得项目帮助到您，请认真考虑请作者喝一杯咖啡 ?

敲黑板

参与贡献

期待能有更多的开发者参与到 pyecharts 的开发中来，我们会保证尽快 Reivew PR 并且及时回复。但提交 PR 请确保

1. 通过所有单元测试，如若是新功能，请为其新增单元测试

2. 遵守开发规范，使用 black 以及 isort 格式化代码($ pip install -r requirements-dev.txt)

3. 如若需要，请更新相对应的文档

我们也非常欢迎开发者能为 pyecharts 提供更多的示例，共同来完善文档，文档项目位于 pyecharts/website

感谢陪伴 pyecharts 一路走来的每个人，我相信 pyecharts 为很多的 python 开发者提供了方便的绘图方式，我希望有提出问题的人，更希望有更多能够一起解决问题的人，如果您真心想参与到开发中来，请及时联系我，邮箱 chenjiandongx@qq.com。

点击阅读原文进入相关github

感谢阅读

推荐阅读：

1:【小编心得】互联网公司实习一年，我被迫知道了这些内幕...

2：我想加入阿里，我该怎么做

3：1 行Python代码能干哪些事，这 13个你知道吗？

4：2018年Python爱好者社区历史文章合集(作者篇)

5：2018年终精心整理|Python爱好者社区历史文章合集(类型篇)