Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
What's the ideal Python version for a beginner to start learning Python? I need to recommend some newbies a programming language to learn and I chose Python. I'm still not sure which version.
It depends what you're going to do with it.
Unicode handling has vastly improved in Python 3. So if you intend to use this for building web pages or some such, Python 3 might be the obvious choice.
On the other hand, many libraries and frameworks still only support Python 2. For example, the numerical processing library numpy, and the web framework Django both only work on Python 2. So if you intend to use any of those, stick with Python 2.
Either way, the differences aren't huge to begin with. I'd say Python 3 is a little easier to pick up (due to its string handling), but that is a good reason to learn Python 2 first. That way, if you run into a piece of Python 2 code (and you will), you'll know what is going on.
Adoption of Python3 has been held up by a few critical 3rd party packages. numpy is a good example of a package that has just barely started working on Python3. Quite a few other packages depend on numpy, so they will hopefully be supporting Python3 very shortly too.
Most of the time it's possible to write code that is compatible with 2.6/2.7/3.1 by using __future__ imports. So learning one does not mean you are not learning the other.
My vote is for 3.1
My reasoning is simple and selfish. The more new python programmers that only use 3.1 there are, the more likely it is that one of them is going to decide that they need some library from 2.6 and port it to 3.1 (learning 2.6 in the process I might add).
After this happens, I can start using 3.1: it looks really cool.
I would suggest Python 2.6; I know it's old, but it's not only the current standard, and there is way more documentation and libraries available for it.
I'll throw my experience into the works:
Right now you should be using 2.6. Switch to 2.7 when 2.7.1 comes out. Switch to 3.1/2 when all the libraries you want are fully supported and stable there.
Related
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 8 years ago.
Improve this question
I'm working on a large-ish project. I currently have some functional tests hacked together in shell scripts. They work, but I'd like to make them a little bit more complicated. I think it will be painful to do in bash, but easy in a full-blown scripting language. The target language of the project is not appropriate for implementing the tests.
I'm the only person who will be working on my branch for the foreseeable future, so it isn't a huge deal if my tests don't work for others. But I'd like to avoid committing code that's going to be useless to people working on this project in the future.
In terms of test harness "just working" for the largest number of current and future contributors to this project as possible, am I better off porting my shell scripts to Python or Perl?
I suspect Perl, since I know that the default version of Python installed (if any) varies widely across OSes, but I'm not sure if that's just because I'm less familiar with Perl.
Every modern Linux or Unixlike system comes with both installed; which you choose is a matter of taste. Just pick one.
I would say that whatever you choose, you should try to write easily-readable code in it, even if you're the only one who will be reading that code. Now, Pythonists will tell you that writing readable code is easier in Python, which may be true, but it's certainly doable in Perl as well.
This is more personal, but I always used python and will use it till something shows me it's better to use other. Its simple, very expansible, strong and fast and supported by a lot of users.
The version of python doesn't matter much since you can update it and most OSes have python 2.5 with expands the compatibility a lot. Perl is also included in Linux and Mac OS, though.
I think that Python will be good, but if you like perl and have always worked with it, just use perl and don't complicate your life.
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'm not quite sure what the real differences are so I'm not able to decide which version is better for a beginner.
I have a background about C, C++ and Java basically, i would like to start Python because i need it, this will look like a noob question but i really don't know which version i'm supposed to pick; for what i see the difference between 2.x and 3.x are mostly related to the syntax used in the two versions, but since i don't even have started anything yet i know nothing so i ask: which one I'm supposed to pick ?
You can start with any of the version you want. Syntax are almost similar, the major differences can be found here:
http://docs.python.org/release/3.0.1/whatsnew/3.0.html
For learning though I would suggest 3.x because 2.x are frozen. There will hardly be any features added apart from bug-fixings.
For industry level application : 2.x because many libraries are yet to be ported ( example: mechanize, BeautifulSoup etc). Also Google App Engine does not support 3.x yet.
My suggestion would be to write code in 2.x, but make sure it can easily be ported. It's not that tough once you get the hang of py2to3 tool.
Just read this from python wiki. Short version: Python 2.x is the status quo, Python 3.x is the present and future of the language.
Personally I would install both, but for now use 2.x (2.7 or with some specific libraries 2.6) for developement, mainly due to better library support. And if the time comes, juping won't be too difficult, as the syntax changes aren't that substantial as Ashwini Chaudhary points. If you are just learning and don't need vast library support, go for the 3.x.
Most people are still using 2.x, even Django (one of the most popular web frameworks for Python) doesn't fully support Python 3 yet.
I would start with version 2.x. You'll have a lot less headaches when working with other libraries.
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 3 years ago.
Improve this question
What's ActivePython actually about?
From what I've read it's just standard Python with OpenSSL and PyWin32 (on Windows). No big deal I guess; I could install them in matter of minutes, and most people don't need them anyway. All other mentioned libraries (zlib, bzip2, SQLite 3, Tkinter, ElementTree, ctypes, and multiprocessing) are part of the core Python distribution.
Next up, the tag-line "ActivePython is the industry-standard Python distribution", isn't core Python distribution "industry-standard" (whatever that means?)?
And the weirdest thing, is that ActiveState bundles it with crappy PythonWin, and not their own most-awesome Python editor/IDE, Komodo. What gives?
I actually never got to installing ActivePython, so maybe I don't know something, but it seems pretty irrelevant, and I see the name quite often on forums or here.
It's a packaging, or "distribution", of Python, with some extras -- not (anywhere) quite as "Sumo" as Enthought's huge distribution of "Python plus everything", but still in a similar vein (and it first appeared much earlier).
I don't think you're missing anything in particular, except perhaps the fact that David Ascher (Python enthusiast and my coauthor in the Python Cookbook) used to be CTO at ActiveState (and so no doubt internally pushed Python to go with other dynamic languages ActiveState focuses on), but he's gone now (he's CEO at the Mozilla-owned firm that deals with email and similar forms of communication -- Thunderbird and the like, in terms of programs).
No doubt some firms prefer to purchase a distribution with commercially available support contracts, like ActivePython, just because that's the way some purchasing departments in several enterprises (and/or their IT departments) are used to work. Unless you care about such issues, I don't think you're missing anything by giving ActiveState's Python distribution a pass;-).
(I feel similarly about costly Enterprise distributions of Linux, vs. Debian or Ubuntu or the like -- but then I'm not in purchasing, nor in an IT department, nor do I work for a very traditional enterprise anyway;-) )
ActiveState has a long tradition contributing Windows support to Python, Tcl, and Perl: by hiring key developers (like Mark Hammond, for some time), by fixing bugs specific to Windows, and having employees contribute fixes back, and by being sponsors of the Python Software Foundation.
While it is true that the distribution they produce is fairly similar to mine, it's as RichieHindle says: you can get paid support from ActiveState (but not from me).
The main feature is that you can buy a paid support contract for it.
Why does Red Hat Enterprise Linux exist when you can compile everything yourself? 8-)
For many businesses, the combination of proven Open Source software and a support contract from people who build, package and test that software, is an excellent proposition.
I've been using ActivePerl for years and when I made the switch to Python, I very naturally downloaded ActivePython.
I never had any problems with the Active* distributions - they're robust, come with a few useful libraries, like PyWin32, that the vanilla core Python doesn't have. They also come bundled with a .CHM Python documentation compilation that's very useful.
Here is an email to python-list I wrote on this a long while ago:
https://mail.python.org/pipermail/python-list/2007-July/456660.html
Mostly those details are still true. Also, all the other responses I've seen to this question are fair.
Note that as of release 2.6.3.7 ActivePython includes PyPM (similar to PPM for ActivePerl) to help with installing Python packages -- the hoped for benefit over "easy_install" and "pip" (and others) to be the installation of popular binary packages.
ActiveState will also be supporting Python 2.7 while the standard Python 2.7 will no longer be supported in 2020. If you have a large codebase that won't be migrated in time, you'll need to make security patches yourself or go with something like ActiveState Python.
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 ask this for deployable reasons. As in, if I write a solution in python, I feel bound to write to 2.x due to the lack of adoption of python 3. This is a major daily concern of mine, and I want to figure out what's going on.
For many of the python-based questions here, people are giving solutions that simply do not work in python 3.x.
So, I ask the question: What has prevented you from switching to python 3.x in your personal or work environment? The conversion script exists, and yet programmers (who are usually the earliest adopters of everything) seem to refuse to upgrade.
Why?
[Edit 03/10/2014: This answer is now out-of-date. Django has supported Python 3 for some time.]
[However, it must also be noted that the django third-party packages and extensions used in many Django projects are in various stages of Python 3 compatibility implementation. More details can be found in Django packages website which tracks the statuses of various projects.]
Django has not moved over to 3.0. That is all I need to know.
Related Questions
Will Python 3.0’s backwards-incompatibility affect adoption?
Is Python 3 a good starting point when you want to learn Python?
If I’m going to learn Python, should I learn 2.x or just jump into 3.0?
Who’s Using Python 3.0?
Python Version for a Newbie
Is it worth learning Python 2.6 with 3.0 coming?
Most of the answers in these questions echo the same sentiments. Aside from Django, too many frameworks/libraries - WxPython, PyGame, Django, etc - have still not adopted it. I'm sure as hell not making the move until they do.
Because major libraries that my codebase depends upon have not released a 3.x version. (wxPython, matplotlib, numpy, etc.)
So the responsibility goes upstream from my point of view.
If all my dependencies were 3.x compatible, I'd probably have switched by now.
Compiled 3rd party modules haven't updated.
Different syntax
Slower integers.
The #python IRC channel on freenode has in its title that its too early to switch.
3rd party tools and libraries. I'm having trouble making some things work under 2.6 (not a LOT of trouble, mind you, but some.)
As I see it, the ecosystem is one of Python's biggest strengths, and going to 3.0 at this point chucks a lot of that out the window. (In a year, I'm sure the story will be totally different.)
(Obviously, there's a chicken and egg problem here, but fortunately it's not my problem to solve, so I'll stay with 2.6 for a while.)
For many of the python-based questions here, people are giving solutions that simply do not work in python 3.x.
I think you answered your own question here. The lack of backwards compatibility makes 3.0 a much harder sell than a seamless upgrade because you have to adjust your thinking and discard some programming techniques to use the new version.
Call me back when they have an upgrade script for my brain.
Because the default installation of 2.5 on Mac OSX Leopard works just fine. I have no need to upgrade and I see no advantage to upgrading except an end to the woes of unicode.
If you are interested to move to Py3k one interesting way would be to write code in Py3k and use a 3to2 script which is being written now as a part of Google Summer of code project, on the lines of 2to3 script.
The operating system I use the most, Debian, does not have a Python 3 package, not even in the "unstable" (brand new) branch. Unless I compile it myself (which is quite 20th century), it means no Python3 to me.
I bet it is the same issue with many operating systems.
Unfortunately, for the same reason as most others have said - 3rd party libraries still not having been made 3.0 compatible.
For this reason, as well as that some GNU/Linux distributions (Ubuntu in my case) still comes with Python 2.6, I can't completely throw 2.x out the window yet.
However, the change to 3.0 is not a major one IMO. Except for "print" being a function and the new string formatting system, it's really more or less the same as before.
In fact, I find that most of my old scripts (those that do not depend on 3.0 incompatible 3rd party libraries) will work flawlessly in 3.0 after I update all the prints and string formatting. In some cases I've also had to change some module names (specifically stuff from the "email" module), but other than that nothing major.
Also, all the scripts I have updated for 3.x compatibility so far still seem to work flawlessly in 2.6 (but not older 2.x of course, as they lack the new 3.x syntax).
The main reason I am not switching is that so many books and coding challenge websites are still 2.x. I installed 3.x and realized very quickly that I had to uninstall and go to 2.x.
Because of the lack of backward compatibility, switching is hard, especially if there is C code involved. And although I understand the unicode/string thing may be very useful to some people, I certainly don't care about it myself.
Basically, Py3k did not solve many problem that I care about (distribution issues, versioning of modules, simplified import model).
Python 3+ does not support numpy.
Correction: it now does. As it now supports mathplotlib.
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
I've seen a number of postgresql modules for python like pygresql, pypgsql, psyco. Most of them are Python DB API 2.0 compliant, some are not being actively developed anymore.
Which module do you recommend? Why?
psycopg2 seems to be the most popular. I've never had any trouble with it. There's actually a pure Python interface for PostgreSQL too, called bpgsql. I wouldn't recommend it over psycopg2, but it's recently become capable enough to support Django and is useful if you can't compile C modules.
I suggest Psycopg over Psycopg2 since the first one seems a bit more sable. At least in my experience. I have an application running 24/7 and sometimes I was getting random memory crashes (double free or corruption errors) from Psycopg2. Nothing I could have debug fast or easily since it's not a Python error but a C error. I just switched over to Pyscopg and I did not get any crashes after that.
Also, as said in an other post, bpgsql seems a very good alternative. It's stable and easy to use since you don't need to compile it. The only bad side is that library is not threadsafe.
Pygresql seems nice, there's a more direct way to query the database with this library. But I don't know how stable this one is though.
I've used pg8000 without any problems in the past 3 years. It's uptodate and available on pypi and works on both python2 and python3. You can use "pip install pg8000" to quickly get it (don't forget to use --proxy=yourproxy:yourport if you're behind a firewall).
If you're worried about thread safety, it also provides a score for thread safety (see: http://pybrary.net/pg8000/dbapi.html and https://www.python.org/dev/peps/pep-0249/ for definitions of the different levels of thread safety) (although I have no yet used threads with psql).
In my experience, psycopg2 is the most used library for this. Like you said, it's DB API 2.0 compliant, wich gives a solid interface to work with.
For those who find the standard API to be a little too verbose and hard to work with, I made a small library that might help:
https://github.com/hugollm/rebel
Psycopg1 is known for better performance in heavilyy threaded environments (like web applications) than Psycopg2, although not maintained. Both are well written and rock solid, I'd choose one of these two depending on use case.
I uses only psycopg2 and had no problems with that.