大家好，今天小编关注到一个比较有意思的话题，就是关于python 学习 打包的问题，于是小编就整理了2个相关介绍Python 学习 打包的解答，让我们一起看看吧。
- pyinstaller打包了一个python程序，生成的.exe文件打开后Failed to execute script main？
- 既然Python是用C实现的，那为什么Python不能直接生成exe？
pyinstaller打包了一个python程序，生成的.exe文件打开后Failed to execute script main？
我遇到一相同的问题，是python2.7+web.py,目前在win10x64下编译后出现你这个问题，但不是编译的所有项目还这样。在winxpx32下编译（运行直接说不是有效win32），然后放在win10x64下运行没有问题，我觉得应该就是各种库有不兼容的地方，现在也没有找到解决方法，只能先在xp打包好再用
既然Python是用C实现的，那为什么Python不能直接生成exe？
python不是用C实现的，而是利用了CPython解释器使python的运行效率可以接近C程序。至于为什么不直接生成exe，因为没有必要啊，exe是C程序编译之后执行的，意味着每一次执行python，后端的C解释器都需要将目前的python代码翻译成C代码，再执行编译、检查链接等等一系列操作，之后把所有的库静态或者动态打包好形成一个exe来供用户执行，这个效率未免太低了吧？而且在调用库的时候要如何选择链接方式？使用静态链接的话编译出来的文件会很大，动态链接又不能保证每一个用户都可以执行，不能保证库文件已经正确安装，导致跨平台性不好。
Python运行原理是运行在C编写的Python虚拟机上，通过opcode来决定python需要执行的指令，并且可以通过创建线程的方式来提高python的运行效率。只要解释器生成了对应的机器码，虚拟机线程可以立刻进入执行状态，效率比编译高多了，无论是暂停、修改还是重新运行速度都非常快。
我觉得你需要搞清楚一个概念，runtime. exe 只是一个壳子，exe 可以把整个just-in-time编译器和代码全部打包。看上去就是一个exe，但和你想象的exe不是一回事。程序分为三种，一种比如c,c++, rust，不需要JIT (just-in-time)编译器，不需要 runtime。第二种是不需要JIT 但需要runtime 比如 go, 它的gc 是runtime来实现的。第三种是需要JIT和runtime 比如java, .net, javascript, python 等等。JIT 的任务是产生中间代码，j***a 叫byte code, .net 叫 IL. 仅仅打包为 exe 不代表可以确定是三种中的任何一种。比如你把 .net 的exe 反编译，得到的代码甚至不是IL而是稍稍变了一点样子的源代码。我们知道机器是不需要函数名的，反编译看到函数名说明什么？说明本来打包为exe就没怎么动你的代码，仅仅是做了语法分析和linking，但是没有真正意义上向c++那样编译而产生机器执行指令。这一点来讲，j***a, .net, python， j***ascript 其实区别只是是不是強类型，没有哪个真正发布了“编译”，应该是 比compile 原始但比transcoding更复杂一点的那种事。
可以直接生成exe，但python的依赖很多，直接生成exe其实就是把依赖和环境打包成一个壳，体积较大（即使一个小功能也可能几百兆），而且执行效率也不高，所以通常都是在开发环境下解释执行。
【十年独立游戏开发者，关注者粉丝，可向我提问，尽量回答】
到此，以上就是小编对于python 学习 打包的问题就介绍到这了，希望介绍关于python 学习 打包的2点解答对大家有用。
