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.
Related
I've read in few places that generally, Python doesn't provide backward compatibility, which means that any newer version of Python may break code that worked fine for earlier versions. If so, what is my way as a developer to know what versions of Python can execute my code successfully? Is there any set of rules/guarantees regarding this? Or should I just tell my users: Just run this with Python 3.8 (for example) - no more no less...?
99% of the time, if it works on Python 3.x, it'll work on 3.y where y >= x. Enabling warnings when running your code on the older version should pop DeprecationWarnings when you use a feature that's deprecated (and therefore likely to change/be removed in later Python versions). Aside from that, you can read the What's New docs for each version between the known good version and the later versions, in particular the Deprecated and Removed sections of each.
Beyond that, the only solution is good unit and component tests (you are using those, right? 😉) that you rerun on newer releases to verify stuff still works & behavior doesn't change.
According to PEP387, section "Making Incompatible Changes", before incompatible changes are made, a deprecation warning should appear in at least two minor Python versions of the same major version, or one minor version in an older major version. After that, it's a free game, in principle. This made me cringe with regards to safety. Who knows if people run airplanes on Python and if they don't always read the python-dev list. So if you have something that passes 100% coverage unit tests without deprecation warnings, your code should be safe for the next two minor releases.
You can avoid this issue and many others by containerizing your deployments.
tox is great for running unit tests against multiple Python versions. That’s useful for at least 2 major cases:
You want to ensure compatibility for a certain set of Python versions, say 3.7+, and to be told if you make any breaking changes.
You don’t really know what versions your code supports, but want to establish a baseline of supported versions for future work.
I don’t use it for internal projects where I can control over the environment where my code will be running. It’s lovely for people publishing apps or libraries to PyPI, though.
I have some rather large code I've written and tested to work with the 2.7.3 version of python available in my elementary OS 0.2 system (based on Ubuntu 12.04)
My code is hosted on Github and I'd like to know if it works on newer versions of python up to 3.x.
Is there some way to do this automatically or with as little hassle as possible?
It's unlikely that your code will work automatically unless it's some very simple script because many of the standard Python operators and methods changed. For example, the print statement becomes the print() method, and that will become a syntax error when you try to run the code.
If you're willing to take the time to set it up and install other version of python, you can use PyEnv to install multiple versions of Python to test your code with. It's very similar to Ruby's RVM if you've used that. While it's not an automated method of testing if your code will work, and it does require some setup, it is a way that you could test your code on multiple versions of Python. Once it is setup, you can continue to use it for your other Python projects as well.
In addition to PyEnv, you can take inspectorG4dget's advice from the comments and use Python's automated version 2 to version 3 code translation. Since it is unlikely that your code will work immediately in version 3 due to changing syntax of keywords and standard methods, you can use that tool to translate your code without too much effort.
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.
As a small-time Python package writer (cobs, simplerandom), I'm wondering what Python versions I should support.
I've heard anecdotally that Python 2.5 is still in use on enterprise type servers. So I thought 2.5 was the oldest that needed to be practically supported, here in 2011.
However, I saw this blog in which the author says he's still using 2.4. From memory, I saw an e-mail on the PyCrypto mailing list saying they aimed to keep support going back to 2.2 if possible.
Of course, then there's Python 3.x which is slowly gaining momentum. It would be good to know who is using that.
Then, there is also Jython and Ironpython, and I have very little idea about them.
Is there any concrete and up-to-date Python installation/usage data available to enlighten us? Is there any "best practices" or other advice for what versions/flavours of Python a package writer should aim to support?
I think that this is a problem that's simply inherent when developing any software. Anyone could be running any version and would need support for that version (I wonder how many people are still running Windoze ME out there? ;)). Personally, when developing libraries, I'll support only support the current version+. If for no other reason, because I'm only one person and I don't have a team.
Having said that, I'd stick my packages up on github and take patches from anyone who wants support for previous versions (and is willing to put in the work).
Edit:
I've found that a good rule in software development (especially packages) is develop only for what is needed, not what you think might be needed. In other words, get it working for whatever version of Python you're running (or is dearest to you) and then take support requests if you want to implement them yourself as people need them.
I have servers that run Python 2.3. :-)
But no, you don't need to support it. Most servers like that are just running, and do not get any new modules installed.
When creating a new module today, 2.6, 2.7, 3.1 and 3.2 is the versions to support. For existing modules you can ask your users. :-)
You should support the latest of the 2.x series (2.7 as of now) and 3.x (3.2 as of now). Unless you have a specific need for supporting older versions, I don't think you need to go there.
As for alternate implementations like IronPython and Jython, you should do that only if needed. It can be time consuming (although perhaps educational) to support you app for all these implementations.
As a side node, to test your app on multiple versions/implementations of Python, I recommend tox.
This question already has answers here:
Closed 12 years ago.
Possible Duplicates:
Is it advisable to go with Python 3.1 for a beginner?
What version of Python should I use if I’m a new to Python?
Haven't really made anything in Python... Which Python should I take ahold of? 2.X or 3.X?
2.X still offers a far wider variety of third-party libraries / frameworks, instructional websites and books, and experts to help you out -- I expect this will continue for a few years until 3.X gradually overtakes it. Right now, therefore, I would still recommend 2.X despite 3.x's even-greater "clean-ness" and simplicity (because some cruft which 2.x has to keen around for backwards compatibility was finally wiped out in 3.x). Very few new features of 3.x are not backported in 2.x, by the way -- e..g, if you want print to be a function, like in 3.x, in your 2.6 or 2.7 module, just put, at the start of the module, the statement
from __future__ import print_function
"Importing from the future" is a typical Python way to make new features available when explicitly requested, without breaking backwards compatibility.
You are in luck! Due to a lot of confusion about this people have put together a wiki page in the last few days: Should I use Python 2 or 3?
I'd say it depends where you are going to run the code. If you have complete control over the environment, use 3.x. If your environment is controlled externally (cheap webhosting for example) then you will probably need to use 2.x. The only other reason to stick with 2.x is if a critical library you can't live without hasn't been ported to 3.x yet. Don't saddle new code with 2.x-isms if you can avoid it.
2.x
Quite some modules have not yet been ported to python 3 and you will find much more books, online resources for learning python 2.x
You also can't rely on python 3 being preinstalled, while for most linux distributions you can rely on some version of python 2 being available. The only one I know of that already has python 3 packages is the latest Fedora 13. If that matters to you depends on your needs.
See also this related (though not identical) thread on Python 3.0.
While I think the case for 3.x is more compelling than it was a year ago, it still doesn't have the breadth of third-party library coverage of 2.x. I would suggest developing for 2.6 and making use of the migration utilities when the time finally comes (e.g. some dependency is forcing you) to move to 3.x.
If you are just learning Python (and you don't have a specific project you need to complete), I'd suggest that you start with the newest version (3.x). Even if you start with 2.x, though, the basics will be the same, so you will be able to learn any differences in 3.x very quickly.
Go with 2.x
I ran into a lot of compatibility issues with libraries and Python 3.x, although I can't recall which ones specifically. The specific issue I was seeing had to do with unicode strings, which I understand is the default in Python 3. The library threw an exception when using unicode strings, and returned an error for normal ASCII strings. This was about 6 months ago, and I'm assuming the support hasn't drastically improved since then.
If you're absolutely sure you won't use any external libraries, 3.x might not bite you. As a compromise, you could use 2.x and try to avoid the changes in 3.x to make it compatible.