I want to decompile PYC file in Python 3.9. I tried decompyle3, uncompyle6, but output was like this:
Error: decompyle3 requires Python 3.7-3.8
What I should use?
If you really have to support 3.9, you're going to have to do it yourself.
Clone the repo locally, Change the line which requires 3.7-8, have a go, and fix it where it starts breaking (and do submit a PR when you're done). The changes between 3.8 and 3.9 are not enormous, so it likely won't be too much work. If the code you're trying to decompile is <3.9 anyway, you won't actually have to implement 3.9isms, so it may run straight off---code written in 3.8 will likely run in 3.9, as AFAIK the APIs haven't changed noticeable. I haven't looked at how compiling works, though, so I could be wrong.
Related
So I've found a few resources on the internet, but I'm running into trouble with the version numbers. Apparently there were some "major" changes to some aspects of Python between versions 3.7 and 3.10? Since the file I'm attempting to decompile back into readable code is some years old (just happened to run across it and wanted to improve on it now that I've progressed my Python knowledge somewhat).
I'm not entirely sure there's a way around this or not, but perhaps I'm doing something wrong. I attempted to use decompyle6 ... which is where I'm running into the version issue. I suppose the most obvious answer would be to go back through the archives, install the older Python version, and decompile from IT?
I'd like to upgrade to python 3.5, but I use legacy python 2.7 packages. Is it easy to run legacy packages in python 3.5? I have been under the impression that this isn't easy, but I did a few searches to see if I'm wrong and didn't come up with much.
I would expect there to be a multiprocessing package that allows standardized hand-offs between 3.5 code and 2.7 packages, allowing them to run independently under their own environments, but being somewhat seamless to the developer.
I'm not talking about converting my own code to 3.5, I'm talking about libraries that I use that won't be updated for or by me.
If you used the newer syntax supported by 2.7, e.g. around exceptions, and/or, better yet, worked with new features imported from __future__, you'll have much easier time converting your code to Python 3 (up to no changes at all). I'd suggest to follow this path first, for it can be trod gradually, without an abrupt jump to Python 3.
I suppose Python processes with different versions can interoperate, because object pickling format is compatible, and you can explicitly use a specific pickling protocol version on both sides to ensure that. I don't think multiprocessing packages on either side would be too useful, though. Consider using e.g. ZeroMQ as a more general solution.
Unfortunately there is no "nice" or automatic way of handling the processing of 2.7 code under 3.5 (that works perfectly).
You mentioned that you are concerned about libraries, not your own code - firstly, you'd hope that if they are under active development, they will be updated. If not, as you stated, then there is a possibility that they were written to be future proof. I've found some good ones are (e.g. google-api-python-client, e.g. https://github.com/google/google-api-python-client/blob/master/setup.py).
Failing that, the only way to upgrade is to fix all the syntax changes yourself. Most common ones I deal with are around 'print' and exception handling.
I have python 2.7 installed. I want to use python 2.4 to run python code. Is it possible?
Either directly use the Python 2.4 interpreter to run it, or modify the programs she-bang line to point to the interpreter you wish to use.
Note that there's many things in common use in recent python (any/all, the 1 if 2 else 3 syntax, as well as major stdlib and language changes) that may cause your program to experience difficulties.
It's also worth noting that a lot of the common 3rd party modules require at least 2.5 and some of those are even dropping that and only guaranteeing 2.6+ compatibility.
You can install Python 2.4 as well. Any of the minor versions, 2.4, 2.5, 2.6, etc. can live side by side.
Code you write for 2.4 will also run on Python 2.7, albeit that you may hit some deprecation warnings. If you are using the 2.7 interpreter to write 2.4 code, you'll need to be careful that you don't use syntax and modules that have been added in newer Python versions.
To see what has been added, look at the What's new documentation; there is a document for each minor version:
What's new in Python 2.5
What's new in Python 2.6
What's new in Python 2.7
You specifically want to look for syntax changes and for new modules to avoid.
There are a few things that can bite you. Some syntactic changes have happened since 2.4, so you may get syntax errors. The standard library is bigger in 2.7, so you may have some things missing. The docs generally lists the version of python when things were added, and can be great help in making sure things will run on different python versions. Generally, syntax and libraries are forward compatible, so if you have to support 2.4, I would write using 2.4 and things should work with 2.7. The same is not true in reverse.
I'm working on my first Python-based program. I would like it to be as maintenance free in the future as possible and I was wondering if this could be a problem as Python is updated. I'm using 2.7.2 currently, but when 3 becomes standard what could happen to my program? Will it likely stop working on a system installed with Python 3 and will it be impractical to have the user install an older version of Python? I assume 2.7.2 won't be maintained indefinitely, and I wouldn't think newer versions of Python would run my program successfully. Sorry if this seems like a newb question; I'm used to working with compiled languages.
Not to stray too far off topic, but would it be better to use Lua in this case?
Will it stop working - that depends on how the program is being run. If the system has both versions installed and you ask to run against Python 2, then it'll continue to work. If you don't explicitly ask to run against a certain version, and it's not there, then it'll probably fail.
Lua offers you no solutions here - if you rely on a system-installed Lua and that Lua becomes incompatible in the future, you're stuck. Think of your scripting language as a dynamic library - if the user has the right version, they're ok, and if not, they don't, just like with C/C++ apps.
If you're deploying to Unix-like platforms, I expect they will support Python 2 for at least another 5 years, maybe 10.
If you're deploying to a Windows platform, you usually package up the relevant version of Python as part of your app.
So the problem is unlikely to be as significant as you fear.
It will take a very, very long time until Python2 will die.
Python2 code will most likely require modifications to run with Python3 (there's the 2to3 tool to help with migrating though), but with all the libs out there which are for python2 it will take years until py2 dies - so you don't really have to care about it right now. Besides that, I believe as long as enough people are using Python2, a version will be kept up to date with fixes.
CVS deleted one of my files when I updated my project before commit. All that I've got now is a .pyc file compiled by Python 2.7. How can I decompile it?
This is old but may still work: http://www.crazy-compilers.com/decompyle/
A newer tool can be found here: http://www.depython.net/
Your can also try this one (but it doesn't work on iterators): http://sourceforge.net/projects/unpyc/
You may try Easy Python Decompiler. It's based on Decompyle++ and Uncompyle2.
Note: I am the author of the above tool.