转换个类型，还要先比对字符串，真的是能跑就行，但凡有点要求也应该单独定义类似i32_from_be_bytes u32_from_be_bytes的函数
Python 的首要要求是易读性和易用性而不是性能，适合快工出糙活而不适用于琢磨特定函数的性能差距……本质还是脚本语言，字符串不是它该纠结的东西，牺牲这个字符串带来的阅读负担比字符串本身更重要。
附一个很主观的编程语言及其运行时的分类：
| 糙活 | 平衡点 | 细活 | |
|---|---|---|---|
| 快工 | Python/Lua | Python (+Pypy & Mypy) | |
| 平衡点 | POSIX Shell 脚本 | JS/TS | Go/Java |
| 慢工 | PowerShell 脚本 | C/C++/Rust |
6 个赞
有个更加规范的struct模块专门做这个事情，效率会高很多。
Python 是可读性大于一切，性能不是 Python 追求的东西。
很少有 Python 高手只玩 Python 一个语言。一般都会兼修 Java, go 或者 c 语言。我觉得 c 语言和 Python 的搭配最好，刚好是两个极端。需要性能的时候用 c 语言写好，再用 Python 调用。
所以你这种事情，如果不是热点，你直接用 Python 搞定，如果是热点，就用 c 重写一下吧。Python 毕竟是高级 VM 语言，无论再怎么优化，和纯 c 比都有 1000 倍这个数量级的差距。
现在 Rust 和 Py 搭配是热门了
一点都不热。Rust 的核心卖点是解决内存安全性问题。可是你再想想，Python 有内存安全性问题？
那就是解决 C 语言的内存安全性问题了？但 Python 和 C/C++ 的搭配里面，一般 C /C++ 都是关键模块，少量代码负责高性能计算，能有多少安全性问题，值得使用 Rust 这么重型的语言？Rust 的语言模型也和 Python 不够兼容，写出来的程序，让ctypes调用是个问题，内存布局和接口定义不够明确。
另外呢，rust 只是解决一些资源管理安全性的问题。但是有很多 BUG 还是没法解决啊。比如我语句的顺序写错，变量名写错，把数据库给写错了，或者提前结束了事务。等等。很多编程 BUG 和资源管理不相关。我个人觉得 Rust 这门语言的切换代价太大，得到的收益并不高。尤其是对于 Python 开发者，比那些纯粹的 C/C++ 开发者还低得多。或许只能纯粹的 C 开发者，转向 Rust 才是收益大于付出。
话说，最近几年，我看到 C++ 的市场需求在回升。C++ 的替代器 C# 以及 Rust 在中国的热度，反而是下降的。当然，外国市场和中国可能不一样我就不太清楚了。
最近几年 C++ 内存安全性的问题严重性突升，以我的研究，其实是因为最近很多人使用 C++ 编写回调式代码引起的。在上世纪八九十年代的过程式编程中，整个项目一般非常简单，不会管理太多的资源，所以调用方式是非常平坦的层次性调用，一个函数调用另外一个函数，自顶而下的执行。资源大多数情况下生存在栈空间里面。但是九十年代以后，因为多核程序以及 GUI 程序的出现，搞出了大量的回调式编程，事件循环式编程，C++ 的对象都生存在堆里面，对象的生命周期经常跳出创建它的那个函数的生命周期。此时，C++ 的内存安全性问题就突显出来了。
我相信这个问题很快就可以得到解决，只要协程编程被推广开，那么 C++ 的编程又会重新回到以前那种大多数对象生存在栈空间里面的情况。这个不是我的癔测，因为我已经实践 C++ 的协程编程近六年了。目前确实观察到，在以栈程架构以主的 C++ 程序里面，大多数函数接收的参数是const Object &这样的，而不是shared_ptr<Object>这样的。这意味着什么，相信 C++ 老手们都清楚吧。
1 个赞
再讨论一个问题。Python 这个生态仍然是可以改进提速的。毕竟，运行效率就像性一样，如果能够免费获得，那肯定非常好，对吧。
首先，Python 的应用场景，目前一般都不太需要性能。比如 Web 开发，AI 训练等等。Python 之所以这么慢，也是有收益的。这个世界就是各种折衷，Python 选择了可读性，以及非常动态的运行时。举个例子:
import xmlrpc.client
proxy = xmlrpc.client.ServerProxy("http://localhost:8000/")
print(proxy.add(2, 5))
在以上代码中，proxy这个对象，莫名多出了一个add()方法。背后的实现机制是使用getattr()返回一个特别的BoundMethod，当执行这个BoundMethod.__call__()的时候向远程发送调用请求，并且等待返回结果。
大家可以想想这在其它语言里面怎么干？看看 vue 在 js 实现动态绑定有多少难，再看看 Python 不超过十行代码。
但，代价就是 Python 的运行速度。
Python 的运行速度确实是可以改进的。我自己就有一个方案，写了个原型，就没有时间再做下去了，只要牺牲一点点 Python 的动态性，比如去掉运行时生成类metaclass，以及eval()这样的函数确实可以做到。
1 个赞
我记得好像说python可以很方便地调c，性能的东西，当然是C为王咯。
这种语法糖在那些以秒计的库上确实易读易写，但在本身以微秒计的函数，以增加数倍的成本使用语法糖，我就无法理解了。
有人说追求性能就用 C，而我又对几百次循环 int.from_bytes() 的耗时不满意。那我要把这几行代码用 C 实现？还是说整个代码都切换到 C？问题就变得玄妙起来。
还是说不要写什么 python 代码，当成一个 C Shell 来用就行了？
__
而且相比我以为我会找到的 int.uint_from_be_bytes(t)
我在 int.from_bytes(t, byteorder=‘little’) 里看不到易读写易用，只看到了呆板，那种"我就是要把语法糖用到每个角落"的自以为是
用rust bind对开发者和库的使用者来说友好的多
对于那种简单，只是解决性能问题的函数，直接用C确实更好
但是对于库来说用C/C++一个是依赖管理问题，另一个是跨平台编译问题，用Rust这两个基本不是问题
是切换到 c 写的模块，比如你这个问题，直接用 numpy 啊。基本上，只要涉及到批量的数值操作，都可以使用 numpy 或者 pandas 来解决:
import numpy as np
np.frombuffer(b'\xa3\x8eq\xb5', dtype=np.uint32)
那个字符串可以非常长，np.frombuffer()返回值是一个数组。
python官方好像也没宣传过性能吧
主打就是一个万能胶作用，看生态，灵活，简单快速开发，什么依赖什么第三方库，拿来就是用，性能全靠第三方
python3甚至比python2性能还低，证明官方就没打算把性能作为主打指标
Rust 的广告疗效里面这个交叉编译就是说得最多的。但依我看，交叉编译就是伪需求。市面上那么多平台，有谁能够提供全的呢？有很多平台，作者根本没有提供二进制包，或者提供的二进制包不符合要求（缺少签名之类的），最终还是得搞源码编译。Rust 的源码编译特别的麻烦，要下载一整套 Rust 开发套件下来。我就被这件事情坑过，我同事写程序依赖了orjson这个 Rust 写的库，结果pip install orjson的时候，没有 openbsd 的预编译模块，最后还是安装不上。再比如我现在用龙芯电脑。。
另外，交叉编译的依赖条件太多了。如果只是简单地只依赖标准库，当然很容易做到交叉编译，连 C/C++ 现在都能用个zig c命令简单地搞出交叉编译。但是依赖项一多就不行了。比如 Rust 的这个交叉编译，据我所知仍然要求你弄到几个平台的 Python DLL 放到你本地，又或者依赖更多的 C++ 库试试，依赖 Qt? 还不是一样麻烦。很扯蛋的事情。
所以我一直说 Rust 这门语言，对于普通的应用开发者，付出太多而收益不大。只适合那些纯的 C 开发者，一般是嵌入式和系统开发者。比如你打算开发一个操作系统，不错，Rust 是唯一正确的选择！
聊性能，算了，前端还是别说话了（不过如果只是想日常方便点，我觉得入门学 JS 挺好，起码打开浏览器就能运行
Rust的最大优势是性能和安全，又不是交叉编译…
我猜你大概是没拿rust做过项目，rust强大的抽象能力和安全性在写普通应用也是很舒服的。我用rust写的程序几千行代码十几个依赖项写完一遍不用debug能直接跑起来，基本功能正常没有bug或只有极少的bug，放在其他语言里绝对没有这个体验。
写rust编译器会持续地拷打你，直到你达到它的最低要求 
读写本地文件还是免不了得上个服务器脚本语言。现在读取好像可以通过文件对象访问了，写的话只能download，也还算勉强可以。但php是真的好。
在性能上，JS 是脚本语言前列，至少可以鄙视一下 Python
啊，原来 JS 这么强吗（查询以后觉得难以置信……反正我也是菜鸡，倒正常
不是 js 多强，是 py 太差，ahk 都是它的数倍性能。