Develop Reference

Does using site packages installed for 32-bit Python introduce memory limitations if they are also used with 64-bit Python?

Aside from the obvious solution of "just install the respective package(s) with your 64-bit Python version", and aside from justifying valid use cases, I am after some technical insight into this scenario.
As an example, say I am running a Python script with a 64-bit Python version, which includes something along the lines of below:
sys.path.append("some 32 bit Python version site package path")
import some_32bit_library
# do stuff with some_32bit_library...
Such that some_32bit_library is being imported and used from the 32-bit version of Python.
Even though the overall script is run with a 64-bit Python, will importing and using this some_32bit_library introduce a memory limit because it is from a 32-bit version?
I am aware that a 32-bit application itself is limited to accessing ~4GB of memory. The question is, will using the 32-bit library via a Python script running with a 64-bit version also have the same ~4GB limitation?
Any answer/insight would be appreciated, thank you.

It simply will not work. When a package is labeled 32 or 64, that means it contains binary libraries. You cannot load a 32-bit library into a 64-bit process, nor vice versa.
If the package is Python only (no binary), then it is probably bit-for-bit identical, and will work fine.

Accessing a 32bit with python on a Debian 64bit with CDLL lib (or other)

I'm trying for ages to access a 32bit C compiled lib within an 64bit Ubuntu. I'm using python and CDLL lib in order to make it happen but with no success so far. I can easily open the same 32bit lib on a 32bit OS, and the 64bit version on a 64bit OS.
So, what I'm asking is if anyone knows a way to encapsulate/sandbox/wrap the lib so I can achieve my goal. That way I can use a single 64bit server to access the 32 and 64bit versions of those libs.
If someone knows another python lib that can make the trick please let me know.

I am not sure if you can do this in the same process - we are talking about arithmetic here: 32bit pointers are different from 64bit pointers, so trying to reference them in the same process ... well, I am not sure what happens when trying to access a memory area which is not accessible or which is not supposed to be accessed (I guess Segmentation fault? ).
The only solution I can think of is it to have a separate Python 32 bit instance that runs in its own process. Then, with some form of IPC you can call the python32 bit instance from your 64 bit instance.

(apart from crazy hacks)
You have to have a 32-bit process to load a 32-bit library and call its functions.
You can install 32-bit version of Python side-by-side with native, 64-bit version on Debian.
See e.g. this question: https://askubuntu.com/questions/29253/how-can-i-install-a-32bit-python-on-64-bit-ubuntu
Or small hack using pyenv: https://github.com/yyuu/pyenv/issues/66
Or install binary pypy release: http://pypy.org/download.html#default-with-a-jit-compiler

Which Python to use on Windows for Numpy and friends?

For research related Python programs, I require Python 2.6 (or 2.7), numpy, scipy and matplotlib. Occasionally, I'm going to use other modules such as mayavi2 or numexpr.
The programs in questions will be exchanged between (Ubuntu) Linux and Windows and can be modified to work across platforms. The setup on the Windows side should resemble the Linux one as closely as possible. Integration with COM, .NET, or the Windows OS is not required.
I'm aware of the following options:
Python for Windows from python.org
ActivePython
Python(x,y), a bundle of Python with modules and GUIs
Enthought Python distribution, a bundle of Python with modules
Which of those will provide me most efficiently with a setup that just works? And how would they differ?

EDIT 2017-11-4: At this point in time Anaconda seems by far to be the best option. It is multi-platform, doesn't require admin/root permission, and it allows you to install multiple python versions in parallel.
Original post
The easiest way to install all the python libraries necessary for scientific computing is to install either Python(x,y) or Enthought Python Distribution (EPD). Both offer a fairly similar set of packages (including numexpr and mayavi2), so it's probably just a matter of personal preference. I prefer Python(x,y) because it is fully open source, whereas EPD is a commercial product with a free edition. You can compare the included packages for EPD and Python(x,y).
Both these options are much better than using the standard python (or ActiveState) then manually installing all the required scientific packages. Both should work well with code transported from Linux. It's worth mentioning that EPD also has a Linux version, so if you need all packages and versions to be absolutely identical between Windows and Linux setups, this might be the way to go.
Edit:The win32-superpack is a good option if you just want a few basic scientific packages, but if you want more complex things like mayavi, you'd need to install them yourself.
Edit 2013-05-03:
There are now a couple of other options which are also worth considering: winpython and anaconda

The question is old, but the answer nowadays to this question will always be Anaconda, so I thought I provide you a link to it.
Not only for scientfic purposes - it has all the libraries and tools for this, installed - but its also the best python distribution in general:
https://www.anaconda.com/download/

I have used the win32-superpack from the official SciPy distribution. It includes Python, NumPy, SciPy, matplotlib, etc. and everything works out of the box.
Maybe I should also comment on the packages on your list:
The standard Python distribution from Python.org does not include SciPy, as far as I know.
The Enthought distribution is installed on some of the computer clusters that I am using. It is linked against the Intel MKL and could be faster for linear algebra than the SciPy one. But it is a commercial package. Python programs developed with the SciPy distribution should, however, run without problems under Enthought, too.
I don't know anything about the other two distributions.

Python on windows7 intel 64bit

I've been messing around with Python over the weekend and find myself pretty much back at where I started.
I've specifically been having issues with easy_install and nltk giving me errors about not finding packages, etc.
I've tried both Python 2.6 and Python 3.1.
I think part of the problem may be that I'm running windows 7 in 64bit mode on an Intel T5750 chipset.
I'm thinking of downloading Python for windows extension http://sourceforge.net/projects/pywin32/files/, but not sure which version to get.
Why do packages have a specific AMD64, but not intel?
However, this may not even solve my problems. Any recommendations on getting Python to work in this environment?
I've currently got Python 3.1 installed, and removed 2.6

The most popular 64-bit mode for "86-oid" processor is commonly known as AMD64 because AMD first came up with it (Intel at that time was pushing Itanium instead, and that didn't really catch fire -- it's still around but I don't even know if Win7 supports it); Intel later had to imitate that mode to get into the mass-64 bit market, but it's still commonly known as AMD64 after its originator. For Windows 7 in 64-bit mode, AMD64 seems likely to be what you want.
The 64-bit-Windows downloads from activestate come with a few important pieces that aren't part of the standard python.org 64-bit Windows builds, and might perhaps make your life easier.

Is there a list of Python packages that are not 64 bit compatible somewhere?

I am going to move to a 64 bit machine and a 64 bit OS (Windows) and am trying to figure out if any of the extensions/packages I am using are going to be lost when I make the move. I can't seem to find whether someone has built a list of known issues as flagged on the Python 2.5 release page. I have been using 2.5 but will at this time move to 2.6. I see that the potential conflicts will arise because of the module relying on a C extension module that would not be compatible in a 64 bit environment. But I don't know how to anticipate them. I want to move to a 64 bit system to because my IT guys told me that is the only way to make a meaningful move up the memory ladder.

We're running 2.5 on a 64-bit Red Hat Enterprise Linux server.
Everything appears to be working.
I would suggest you do what we did.
Get a VM.
Load up the app.
Test it.
It was easier than trying to do research.

Perhaps you should figure out what "make a meaningful move up the memory ladder" means. Do you currently need to address more than 4GB of RAM? If not then you don't need a 64-bit system.

It really depends on the specific modules you are using. I am running several 64-bit Linux systems and I have yet to come across problems with any of the C modules that I use.
Most C modules can be built from source, so you should read about the Python distribution utility distutils to see how you can build these modules if you cannot find 64-bit binaries.
Whether a specific module will work in a 64-bit environment depends on how the code was written. Many modules work correctly when compiled for 64-bits, however there is a chance that it won't. Many popular modules such those from SciPy work just fine.
In short you will either need to just try the module on a 64-bit system or you will have to find the developer/project page and determine if there is a 64-bit build or if there are known bugs.

It seems like you already know this, but it's worth pointing out for the sake of completeness. With that said, remember that you shouldn't have any problems with pure Python packages.
Secondly, you also don't necessarily have to install the 64-bit version of Python unless you're planning on running a program that will take up greater than 4 GB of memory. The 32-bit version of Python should work perfectly fine on 64-bit windows.