As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am extremely new to python, having started to learn it less than a month ago, but experienced with some other programming languages (primarily C# and SQL). But now that Python 3.0 has been released and is not backwards compatible, what would be the advantages and disadvantages of deciding to focus on Python 3.0 or Python 2.6?
Go with 2.6 since that's what most libraries(pygame, wxpython, django, etc) target.
The differences in 3.0 aren't that huge, so transitioning to it later shouldn't be much of a problem.
Since they have incompatibilities, I suggest you start going for Python 3.0 which is more useful in the future anyway. It's a better language. You can see the precise differences in What's new page on its Web site.
I would say begin with 2.6 since the vast, vast majority of documentation regarding Python will be applicable to 2.6 as well most open source projects you may want to contribute to will be in 2.6 for awhile. Then, once you have a good foundation in 2.6, you can learn 3.0. That way you can kind of appreciate how the language has evolved and where the "aesthetic" of the code comes from.
Start with 2.6, and when you get a bit more proficient with the language (few thousands of lines of code written), transitioning to 3.0 will be easy and natural. While learning I suggest you ignore classic classes, and pay special attention to iterators, generators, and list comprehension.
It depends on what you are willing to do.
Python 3.0 is the newer release, and with time should become the standard.
However, it has almost no libraries or frameworks available, and even the tools are not so up to date (e.g. the Eclipse plug-in for Python is still in the migration phase).
On the other hand, there are no huge differences, and once you learn one, moving to the other is quite easy.
So, if you plan just to play around, you can go with 3.0.
If you plan to use it on a new project, I would stick on an older release.
Be careful though. Libraries such as the mysql driver are still in 2.5
If you're looking at it from a getting-a-job perspective, I'd definitely at least learn 2.x as well. The code I work on is still targeting python 2.4 and to the best of my knowledge there is no plans to move to even 2.6, let alone 3.0 in the near future. There will be a ton of 2.x python code floating around for years to come and the vast majority of python jobs will involve working with that code.
So I'd start by learning python 2.6 while the whole time keeping an eye on 3.0 so that you are at least aware of what bits of your 2.x code won't work in 3.0
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Been looking at porting a BitCoin Mining Pool server across to IronPython
Apart from the limitations of Ironpython supporting upto Python ~v2.7
Is a Ironpython/windows platform really not suited to this type of high volume/large transactional system
What are some of the other limitations I might encounter or should i juts bite the bullet and build up an ubuntu programming RIG
If the later what would be an easy IDE for someone coming from a c# Visual Studio world
Thanks in Adavnce
Without knowing how your existing code is built, or how you intend the new version to work, it's hard to answer specifically, but I can give some generalities.
IronPython limitations/issues, in decreasing order of importance:
* No third-party C extension modules. If you depend on any, you'll have to find a .NET equivalent or reimplement the same thing yourself. If not, not a problem.
* No 3.x. If you know 3.x, Unicode is a lot easier, yield from rocks, etc., and 3.x keeps improving (and even speeding up), while 2.x is stagnant. But how much this is worth is a matter of personal preference, not something anyone else can give you an objective answer on.
* No third-party pure Python modules that rely (in important ways) on refcounting semantics. There aren't too many of these out there, but if you need one, you need it.
* There are a handful of differences between IronPython and CPython, listed in the release notes. Probably none of these will affect you, but you should check.
* If there's any heavy application logic (as opposed to all of the work being networking/files/database), IronPython is much faster than CPython at a few things and much slower at a few others, so you probably need to profile and perf-test before you go too far down either path. (And consider at least PyPy, if not Jython, while you're at it…) But usually this isn't an issue for servers.
Next, is a Windows platform suited to a high-volume systems? Windows is definitely capable of handling thousands of connections per second (or requests, or bytes, or whatever's most relevant to your use case). It will probably never beat linux in pure connections/second/$, but you have to realistically trade off operational costs vs. dev costs. However, oversimplifying a bit, Windows sucks at reactors and rocks at proactors, while linux rocks at reactors and is decent at proactors (and there are other similar issues—e.g., substitute processes/threads for the above). So, even though Windows can do nearly as well as linux in general, it can't do as well on the same code, or often even the same designs. You need to architect your code to take advantage of Windows features and take into account Windows weaknesses. And if you're using a framework to do the heavy lifting for you, there are going to be fewer choices, and the best ones may not work like what you're used to, which is usually a much higher dev cost than changing platforms.
If you do go with CPython on linux, what IDE should you use? Stick with Visual Studio. You can, and probably should, write either all or most of your code in a cross-platform way that runs on both IronPython and linux CPython. Then you can code, test, and debug with Iron Python in Visual Studio, use native Windows CPython and/or Cygwin CPython for occasional sanity checks, and only touch linux for performance tests, final acceptance tests before releases, and debugging problems you can't repro on Windows. You'll still occasionally need a simple text editor on linux, but IDLE, or whichever of vi-vs.-emacs you prefer, or whichever GUI text editor your linux distro comes with as the default will be fine.
If your application logic is tightly coupled with your reactor design or something, this could be difficult. If it's doable, it's probably worth doing, but if it's not… well, you can still use Visual Studio as an editor and project organizer, even if the actual code is intended to be run on a linux box. You don't get the nifty debugger integration, etc. that way, but you still get a lot of mileage.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I've looked around for answers and much seems to be old or outdated. Has Python 3 been updated yet so that it's decently faster than Python 2.7 or am I still better off sticking with my workable code?
The issue isn't about speed -- they're either the same speed or Python 3.x is faster (depending on which benchmarks you look at). More specifically, Python 2 used to be faster, but apparently, they're on par with each other now (?). See the comments and this slide deck (towards the back).
The core devs are also actively working on optimizing Python 3 -- each new release of Python 3 has been faster than the last. You can keep abreast of the latest proposals and ideas on optimizing Python (as well as the many complications) by monitoring the python-dev mailing list.
Rather, the reason many people used to give for not updated is because when Python 3 came out, and for several years after, the majority of Python libraries were not updated to work on Python 3.x. However, thankfully, this situation is vastly improved today -- the majority of 3rd party libraries are now Python 3 compatible.
The Python FAQ contains more info. You can also check the Python Wall of Superpowers or Py3 Readiness to get an overview of which popular Python libraries are currently compatible with Python 3.
Update: (Summer 2017)
I feel somewhat obligated to note that support for Python 2 is formally ending in 2020.
Many 3rd party libraries are also planning on following suit -- a large subset of the scientific ecosystem (e.g. matplotlib, pandas, ipython) are planning on dropping support for Python 2 in 2020, Django is dropping support... I wouldn't be surprised if other libraries do the same.
So, if you're interested in making sure you can use the latest and greatest features in either Python or your favorite library, you should look into migrating to Python 3 sooner rather than later.
Here are some guides on converting Python 2 to 3 code:
https://docs.python.org/3/howto/pyporting.html
http://python3porting.com/
https://eev.ee/blog/2016/07/31/python-faq-how-do-i-port-to-python-3/
FYI, here's a performance benchmark comparing Python 2.7 with Python 3.3. Python 3.3 comes faster than Python 2.7.
Python 3.3 included an optimization for Unicode strings that reduced their memory consumption. That might translate into faster code if more of it fits into cache.
Really the only way to know is to benchmark your most critical code in both and see what the difference is.
The necessity of Libraries for your applications will determine whether Python3 or Pyhton2 is better.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
We think about whether we should convert a quite large python web application to Python 3 in the near future.
All experiences, possible challenges or guidelines are highly appreciated.
My suggestion is that you stick with Python 2.6+, but simply add the -3 flag to warn you about incompatibilities with Python 3.0. Then you can make sure your Python 2.6 can be easily upgraded to Python 3.0 via 2to3, without actually making that jump quite yet. I would suggest you hold back at the moment, because you may at some point want to use a library and find out that it is only available for 2.6 and not 3.0; if you make sure to cleanup things flagged by -3, then you will be easily able to make the jump, but you will also be able to take advantage of the code that is only available for 2.6+ and which is not yet ready for 3.0.
For each third-party library that you use, make sure it has Python 3 support. A lot of the major Python libraries are migrated to 3 now. Check the docs and mailing lists for the libraries.
When all the libraries you depend on are supported, I suggest you go for it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Recently I decided to expand my programming horizons and learn the python programming language. While I have used python a little bit for classes in college and for a project or two at work I am by no means an expert. My question is as follows: should I bother with the 2.x releases or should I jump straight to 3.0? I am leaning towards 3.0 since I will be programming applications more for personal/learning use, but I wanted to see if there were any good arguments against it before I began.
Absolutely not 3.0 - 3.1 is out and is stabler, better, faster in every respect; it makes absolutely no sense to start with 3.0 at this time, if you want to take up the 3 series it should on all accounts be 3.1.
As for 2.6 vs 3.1, 3.1 is a better language (especially because some cruft was removed that had accumulated over the years but has to stay in 2.* for backwards compatibility) but all the rest of the ecosystem (from extensions to tools, from books to collective knowledge) is still very much in favor of 2.6 -- if you don't care about being able to use (e.g.) certain GUIs or scientific extensions, deploy on App Engine, script Windows with COM, have a spiffy third party IDE, and so on, 3.1 is advisable, but if you care about such things, still 2.* for now.
Use 3.1
Why?
1) Because as long as everyone is still using 2.6, the libraries will have less reasons to migrate to 3.1. As long as those libraries are not ported to 3.1, you are stuck with the choice of either not using the strengths of 3.1, or only doing the jobs half way by using the hackish solution of using a back-ported feature set. Be a forward thinker and help push Python forward.
2) If you learn and use 3.1 now, you wont have to relearn it later when the mass port is complete. I know some people say you wont have to learn much, but why learn the old crap at all? Python itself is moving towards 3.1, the libraries will move toward 3.1, and it sucks to have to play catch-up and relearn a language you are already using.
3) 3.1 is all around a better language, more stable and more consistent than 2.6... this is normal. The lessons learned from 2.6 were all poured into 3.1 to make it better. It is a process called PROGRESS. This is why nobody still uses Windows 3.1. It is the way things move FORWARD. Why else do you think they went to the trouble of back porting a feature set in the first place?
4) If you are learning Python, and learn 2.6, then by the time you are really comfortable with the language, the ports will be out, and you will have to learn the libraries, and the language all over again. If you start with 3.1, then by the time you are comfortable with the language, the ports will be out, and then you can learn the libraries that you are interested in. It is a smoother process.
5) To be a better developer. If you have to learn and relearn the same things, your understanding will not be very deep. By learning this language, and its libraries only once, you will have more time to work with them rather than relearning syntax. This allows you to understand them better. If you are really missing some pieces by forgoing on the libraries? WRITE THEM. You will probably not need an entire library, and can usually write only those pieces that you need, and develop tools for yourself. This, again, helps you understand the language better, and more deeply.
Short answer: Start with Python 2.6.
Why: Programming is more fun and useful when you can leverage the work of others. This means using 3rd party libraries often. Many of the popular libraries for Python don't have 3.x support yet. PIL and NumPy/SciPy come to mind. My favorite interpreter, ipython, also doesn't work with 3.0 yet. Many unit testing frameworks and web frameworks are also not on 3.0 yet.
So if you start out in 3.x many doors will be closed to you, at least until 3.x porting takes on steam. There are admittedly a lot of nice features in Python 3.x, but some of them have been backported to 2.6 and some more will make it into 2.7. So stick with 2.6 for now, and re-evaluate 3.x in a year's time or so.
I think that you will be better served going straight into 3.0. Unless you have a legacy codebase to contend with, there are very few advantages to learning the 2.xx ways of doing things.
In the Python world (as in most others, really), releases do tend to take a while to migrate down to all of the subprojects, but if you ever find the need to transition back to 2.xx, I don't think you'll find relearning things to be particularly painful.
You should go with the latest release of any programming language you learn unless you have a specific reason not to. Since you don't have an existing project that won't work with Python 3.0, you should feel free to use the newest version.
Use python 3.1, Luke.
Python 3.1 should not be used until other libraries have caught up with support for it.
You should use 2.6 now. It has several 3.x features back-ported to it, so that migrating to 3.x won't be difficult later on, and you won't learn obsolete practices.
The good news is that it's not really that tough to learn both Python 2.x and 3.x. You can install the latest 2.x version as the version registered with the system to run Python scripts by default, but also install the latest 3.x version to explicitly kick off when you want to. That's what I have on my Windows Vista system.
Then, the key document for learning the differences between the 2.x and 3.x versions is:
http://docs.python.org/3.1/whatsnew/3.0.html
If you read Python learning materials out there which are based on 2.x and also refer to that "What’s New In Python 3.0" link above, you'll get an understanding of how things changed. Also see the other whats new docs, like for the differences between 3.0 and 3.1, but the link above is the main one to understand the 2.x vs. 3.x changes.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Except for CPython, which other Python implementations are currently usable for production systems?
The questions
What are the pros and cons of the various Python implementations?
I have been trying to wrap my head around the PyPy project. So, fast-foward 5-10 years in the future what will PyPy have to offer over CPython, Jython, and IronPython? and
Migrating from CPython to Jython
already shed some light on the pros/cons on the topic. I am wondering now, if those more exotic implementations are actually used in systems that have to run reliably. (possible examples? open-source?)
EDIT: I'm asking for code that needs the Python version >= 2.5
CPython
Used in many, many products and production systems
Jython
I am aware of production systems and products (a transactional integration engine) based on Jython. In the latter case the product has been on the market since the early 2000's. Jython is a bit stagnant (although it seems to have picked up a bit lately) but it is mature and stable.
IronPython
This is the new kid on the block, although it does have some track record in products. It (particularly version 1.x) can be viewed as stable and ready for production use, and development is officially funded by Microsoft, who appear to have an interest in dynamic languages on top of the CLR. It is the greenest of the major python implementations, but appears to be reasonably stable.
Stackless Python
This is used extensively in EVE Online, and they seem to view it as production ready. Bear in mind that Stackless Python has been around for something like 10 years.
At least one product, Resolver One, is said to be production-level and is totally based on IronPython.
Resolver One is a program that blends a familiar spreadsheet-like interface with the powerful Python programming language, giving you a tool with which to better analyse and present your data.
I know that Jython is pretty mature and has been around for a long time.
Also, I'd take a look at Stackless python
You can check http://www.portablepython.com/ which is the portable version of CPython. It is also bundled with very common and useful libraries and even an IDE, all portable.
There was Pyrex, which can be found at http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/. It is not Python, but very close. The Cython (not CPython) is based on Pyrex and can be found at http://www.cython.org/. They are both useful for creating C extensions for Python. Their languages are so Pythonic.