Why does ActivePython exist? [closed] - python

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.

Related

Why doesn't Python come pre-built with required libraries like pandas, numpy etc [closed]

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 5 years ago.
Improve this question
What is the reason packages are distributed separately?
Why do we have separate 'add-on' packages like pandas, numpy?
Since these modules seem so important, why are these not part of Python itself?
Are the "single distributions" of Python to come pre-loaded?
If it's part of design to keep the 'core' separate from additional functionality, still in that case it should at least come 'pre-imported' as soon as you start Python.
Where can I find such distributions if they exist?
Many of these tools, including core Python, are separately developed and distributed by different team, so it is up to aggregators to curate them and put them into a single distribution. Here are some notable examples:
The Anaconda distribution from Continuum Analytics
The Canopy distribution from Enthought
ActivePython from ActiveState
PythonXY for scientific programming
WinPython for Windows
PyIMSL Studio from Rogue Wave Software
This is a bit like asking "Why doesn't every motor come with a car around it?"
While a car without a motor is pretty useless, the inverse doesn't hold: Most motors aren't even used for cars. Of course one could try selling a complete car to people who want to have a generator, but they wouldn't buy it.
Also the people designing cars might not be the best to build a motor and vice versa.
Similarly with python. Most python distributions are not used with numpy, scipy or pandas. Distributing python with those packages would create a massive overhead.
However, there is of course a strong demand for prebuilt distributions which combine those modules with a respective python and make sure everything interacts smoothly. Some examples are Anaconda, Canopy, python(x,y), winpython, etc. So an end user who simply wants a car that runs, best chooses one of those, instead of installing everything from scratch. Other users who do want to always have the newest version of everything might choose to tinker them together themselves.
You can make the interactive interpreted launch with "pre-imported" modules, as well as with pre-run code, using The Interactive start-up file.
Alternatively, you can use The Customization modules to pre-run code on every invocation of python.
Regarding whether pandas and numpy should be part of the standard library - it's a matter of opinion.
PyPi currently has over 100,000 libraries available. I'm sure someone thinks each of these is important.
Why do you need or want to pre-load libraries, considering how easy a pip install is especially in a virtual environment?

Python 3.X or Python 2.X [closed]

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.

What's going on with python 3k? [closed]

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 13 years ago.
Since I'm not strictly python developer please don't flame me just for the question.
I'm wondering about Python 3k, that from my point of view, might be some kind of misconception.
Or quite in-relevant step forward (I'm taking into account the 2.6 and 3k releases, which was almost one after another).
Before the flame will start, I'll explain my position at this topic and I'd assume couple facts from my work environment.
I work in a cutting edge market data solutions company,
we use mainly functional languages to high throughput data analysis.
But we also use python as a second technology for smaller tasks, scripts, process management & monitoring.
Some of my colleagues write more serious production applications based on python technologies,
but:
ALL of our customers use python 2.6,
because of above we have quite strong 2.6 toolset and internal/external support,
We still plan to develop 2.6 apps.
Every small tool development is also based on 2.6 platform.
Additional what I observe:
at this point any new linux distribution (in our infrastructure) has python 2.6 on the board,
most third party modules are developed for 2.6 version,
great part of resources in the network is also dedicated for 2.6
(I know that You can port most of this to 3.1.x, but it's too big overhead here.)
I know that Py 3k is still growing but,
there is already python 3.1.1, but no one "cares" (in my environment).
I've a strong feeling that Python 3k overheads are stopping it for moving this great technology into new dimension.
The OP appears to be surprised that a minor-release upgrade (which added some nifty features, basically broke zero existing code, and allowed trivial rebuilds of all existing third party libraries) happened overnight at their organization, while a major-release upgrade (requiring much more effort especially from the point of view of third-party library authors) didn't and won't. I think I mostly feel surprised at their surprise;-).
Even minor-release upgrades don't happen instantly in most large projects and organizations; for example, App Engine is still using Python 2.5 (apparently, upgrading its specialized "sandboxed" Python runtime and all it relies on is not a zero-effort proposition, so they prefer to keep putting their energy towards adding engine features instead) -- so I believe are implementations such as Jython and PyPy (I think IronPython's in the process of migrating to 2.6, but the current production version is still 2.5).
Totally new projects starting today should seriously consider starting with Python 3; for example, Allison Randal's pynie (Python for Parrot) project made exactly that choice (and, I think, it was the correct choice in their situation). Migrating existing projects is a harder proposition, and mostly depends on what third-party components the existing project depends on (if a new project intrinsically depends on some functionality that's only available in 3rd party libraries for 2.6, not 3.1, then the new project will probably also have to stick with the 2.6 version for the time being, of course).
Third party libraries that are under active development will probably come out with Python 3 version gradually (for example, gmpy did so relatively recently). Once enough such third party libraries are available, the chance that a missing library inhibits migrating an existing project (or, even more, starting a new project) using Python 3 starts going down pretty rapidly. This makes Python 3 ports feasible. At some point, some attractive functionality will become available in Python 3 only (for example, if and when pynie releases, that might be the case for a Parrot implementation affording smooth interoperability with Perl &c), and that will provide a strong motivation for some projects to go 3-only (pragmatically stronger than pure issues of language quality).
Even then, some sufficiently large projects and organizations will stick with Python 2 for a long time, and you can confidently expect that at some time a 2.7 will exist (possibly one or two more after that, but that's harder to predict). Hey, I sharply remember that throughout the '90s in most large projects and organizations "Fortran" still meant Fortran 77 (in fact in some places -- not many, 30+ years after than Fortran version's first release -- that's still true today!)... for all the advantages of Fortran 90 and later versions, migration costs (esp. in terms of various compilers, libraries, tools) were just perceived as being too high a price to pay for the advantages of the new language version. That's just inevitable when a language acquires a large installed base and a rich ecosystem of third party tools and libraries, as Python 2 now has. No reason for surprise!-)
Py3k is a good and necessary step in the evolution of the Python language. I like it much better than 2.x, and code in it almost exclusively. I'm fortunately not dependent on third-party libraries, few of which are there for Py3k yet. But they will be.
There is nothing wrong with using 2.6 - 2.7 will come and be even more of a bridge to 3.x, and you can start generating Py3k-like code already that will be trivial to port to 3.x once your favorite third-party library is there. I think I read somewhere that Py2k will be around for several more years.
What exactly is the question here? You observe that there's a newer version of the platform you currently use. You have good reason for staying with the version you have. This pattern is common across very many development organisations, you simply cannot chase every new version of the stuff yiou use. Nor can you stay where you are for ever, eventually you will need to migrate.
There are forces that may drive you to migrate, for example
The new version has some very major new feature you would really benefit from (eg. annotations in Java 5)
Support for a current platform (or dependent library) is being withdrawn
Meanwhile, you could attempt to future-proof your code so that migrating is easier. Are you familiar with the level of change required to move up?
Since Python 3K is not backwards compatible, you can expect that it will take more time to be accepted in corporate environments. Python has a huge code base and many important third libraries. One must wait for all dependencies to be converted to Python 3K before adopting it. This could be a real slow process.
From what I understand, the creators of Python expected this to happen, but they thought it will be worse not to make the changes and just let the language "die".
Python 3.x is not yet aimed at production use, but it will get there in time.
As a language and a runtime, Python 3.x is fine. The limitation is that a lot of important third party libraries and tools are still in the process of being ported and tested.
It is expected that the transition to Python 3.x will take up to five years.
So, if you are not library developer, you really don't need to care about Python 3.x for the time being.
Also, it is not expected of current Python users to do the switch to Python 3.x anytime soon.
There are a lot of libraries which depend on other libraries in the Python ecosystem. Nose is used to test numpy, and scipy requires numpy, and lots of scientific libraries require scipy. Also, none of the library developers can start porting until their dependencies are ported. It's going to take a long time for whole chain to port across.
A lot of the pragmatists are hoping that python 2.7 and 2.8 will gradually depreciate the bits that won't work in python 3 (introduce a print function called print_function, then depreciate the print statement, then rename print_function to print ...), so eventually python 2 will merge with python 3.
Here is a video there Guido van Rossum, at the Py4Science meeting, talks about Python 3.
http://fperez.org/py4science/2009_guido_ucb/index.html

What's the state-of-the-art in Python programming in Windows? [closed]

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 looking to set up my development environment at home for writing Windows applications in Python.
For my first piece, I'm writing a simple, forms-based application that stores data input as XML (and can read that information back.) I do want to set up the tools I'd use professionally, though, having already done a round of didactic programming.
What tools are professional python developers using these days? In order to have a working python environment, what version of the compiler should I be using? What editor is common for professionals? What libraries are considered a must-have for every serious python developer?
Specifically, which Windowing and XML libraries are de rigeur for working in Windows?
I like Eclipse + PyDev (with extensions).
It is available on Windows, and it works very well well. However, there are many other IDEs, with strengths and weakness.
As for the interpreter (Python is interpreted, not compiled!), you have three main choices: CPython, IronPython and Jython.
When people say "Python" they usually refer to "CPython" that is the reference implementation, but the other two (based, respectively, on .Net and Java) are full pythons as well :-)
In your case, I would maybe go on IronPython, because it will allow you to leverage your knowledge of .Net to build the GUI and treating the XML, while leaving the implementation of business logic to Python.
Finally, should you decide to use CPython, finally, there are several choices for working with xml:
minidom; included in the standard library
lxml, faster and with a better API; it means an additional installation on top of Python.
Lots of questions, most hard to answer correctly. First of all, most of python development happens on unix-like platforms. You will hit many walls during development on Windows box.
Python is not a compiled lanugage, current preferred version for production is 2.5. For environement setup you should take a look at virtualenv. Editor is a personal choice, many Python developers use Vim, you can customize it pretty well to suite your needs.
About libraries, Python is very strong around this area and it's really hard to say what is a must to know. If you want to handle XML, I would preffer lxml.
If you go for CPython, make sure you get the win32 extensions by Mark Hammond, either as a separate download which you install on top of the vanilla Python installation, or as part of ActiveState's ActivePython. It includes an integrated editor and debugger.
Jython has recently reached 2.5 compliancy, but we quickly ran into recursion limit issues.
The standard distribution includes IDLE, a graphical editor and debugger.
I like shells, so I'm using IPython for interactive work, and pydb as debugger (unfortunately, I had problems getting pydb to work under Windows).
"What tools are professional python developers using these days?"
Lots
"In order to have a working python environment, what version of the compiler should I be using?"
["compiler" is meaningless. I'll assume you mean "Python"]
We use 2.5.4. We'll be upgrading to 2.6 as soon as we've done the testing.
"What editor is common for professionals?"
We use Komodo Edit.
"What libraries are considered a must-have for every serious python developer?"
We use Django, XLRD, PIL, and a few others. We don't plan this kind of thing in advance. As our requirements arrive, we start looking for libraries. We don't "pre-load" a bunch of "must-have" libraries. The very idea is silly. We load what we need to solve the problems we have.
There are no set standards in these matters, and for good reasons:
there is a fair amount of good choice
different people are productive with different tools
different tools and libraries are suited for solving different problems
That said, I think it's a valid question exactly because there is a fair amount of good choice. When there is too much choice people often do not chose at all and move on. You still need to do your own research to decide what is best for you but you may find here some good starting points.
Here is what I use professionally on windows:
python 2.5.4
latest wxPython
XRC Resource Editor from the wxPython docs & demos for the grunt of the tedious GUI design
lxml or gnosis utils for xml
WingIDE Professional
Taking the headline question literally, the answer has to be IronPython. The 2.0 releases are equivalent to CPython 2.5, and the 2.6 release (currently at beta2) is intended to match CPython 2.6 (full 2.6 release some time in the next couple of months). With either you can use the state of the art in Windows GUI frameworks, i.e. WPF; and you get the whole .net XML support libraries (excepting Linq to XML, which relies on clever bits of C# that IronPython cannot yet emulate).
I've used NetBeans Python plug-in happily as an IDE for IronPython using WPF.
The answer would depend on what you want to do with Python. If you want to do web programming, Python is blessed with many web frameworks. The most popular ones are: Django, Pylons, and Turbogears. There's also Google App Engine, where you can deploy your Python webapp (based on GAE framework) to Google's infrastructure. If you want to do Desktop programming then there is PyQT and TkInter, or you can even try using Java Swing with Jython. And if you want to do Mobile app programming then there is Python for S60 which is backed by Nokia.
Python is interpreted language, so there is no compiler (although the interpreter also compiles your python module into bytecode). I would recommend using Python 2.6 as it has some syntax and libraries that is different compared to 2.5. You can also start learning Python 3.0 too.
There is several IDE that is good for Python. You don't have to get yourself attached into one editor/IDE because most of them are good ones. For the commercial ones there is WingIDE which is really focus on making IDE for Python and I would really recommend IntelliJ IDEA with Python plugin which is really nice if you often look at the libraries in your Python environment. For the free ones (as others have said) there is Komodo Edit or you can also try Netbeans with Python plugin.
As for the must-have libraries, this is depending on what you want to do. What kind of application you want to develop with Python. But I think every Python developer should consider PIL for imaging library. I also use simplejson quite often, because I prefer using JSON rather than XML. If you are using XML though, you can use lxml as it is really fast in parsing XML.

Why won't you switch to Python 3.x? [closed]

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.

Categories