I know this is an old thread, however it has active= 11 days ago, so I thought I would answer this for you as it still looks unresolved....or somewhat unresolved? After much heart ache and pain and wasted hours been and gone, I will attempt to share with you what I know and have found working in these mixed environments.
Answering the NumPy issues you guys are having is most likely because the Python installer is on the Windows PATH and is the default Python install, but its own .PTH file has no reference to NumPy. Either update the .pth file so that it has the NumPy reference (if this is different to the ArcGIS installed Python but needs to call ArcPy you may have some issues? In that case refer to the .PTH file located in the ArcGIS installed Python and try replicating that across into the other python, I suspect that this will cause conflicts though so maybe test by removing the ArcGIS Python .pth file when you do an go from there) Or update the script to point to the correct instance, information about this will be covered further in detail below.
Python outside of ArcGIS has evolved now with a python launcher for windows. ArcGIS Python on the otherhand handles its communication with Python directly with arcpy via the Python .pth file in the nominated Python installation. What happens is there is a conflict between the python Windows path executable and the python .pth (yes there are TWO paths here....one in python and one in Windows). When you are calling the python exe it will always default to the one first set on the Windows path and then it will iterate through other locations until it can execute python. Within python its self if the first known Python location does not have a reference in its own path to the ArcPy instance then it will fail!
http://www.python.org/dev/peps/pep-0397/
The python exe cannot see ArcPy in its path. Similarly ArcGIS Python located in the C:\Python26\ArcGIS\ArcGIS10.0 (and of course now x64 with ArcGIS service pack C:\Python27\ArcGIS10.1x64) is becomes not the prefered .exe to run when calling python, so it too may fail to execute any "external" referencing scripts that call ArcPy to run from the Windows command prompt if the Windows PATH variable is set to different version of Python. ArcGIS Python (if it was installed as the first instance of python?) may (or may not?) know the reference of Python26 and execute that particular version of Python IF the user executes the script from within the ArcGIS scripting Windows inside of ArcMAP. I hope you guys are all following me here?
http://docs.python.org/3/using/windows.html#launcher
So there is a tendency these days to move away from "hard coding" the PATH for python and letting the Python launcher handle each instance of Python and nomination of the version of python being handled within the script. This is what I will be doing now as I migrate to Python 3.2 and not wanting to mess up my current ArcGIS python install. So....we kind of need to "unreference" the Python path that we have all been told to set in Windows Environment PATHs, and pass all Python related executions to the Python Launcher. How I go about this now is all theoretical, so bare with me here while I put my thoughts to text and hopefully help you guys to all understand the issues raised here:
1) Unreferencing all pythons from the Windows paths ensures that when python is called from the Windows console or by directly clicking on a executable .py file that handling is ignored by what Windows would want your to do and allowing the Python Launcher (bundled with 3x and above by default I am told?) to handle the execution of Python to the correct version instance.
2) Unreferencing the python locations from all Windows environment variables means that a single reference for Python goes to the Python launcher and is redirected accordingly by you the user 1 of 2 ways. Deducing the latest python installation by default by it's major.minor version if nothing is put in the .py script it's self, which references 1 of 2 INI files. 1 being a writeable version located in the users home directory <%SYSTEMDRIVE%> \ %USERPROFILE% \ %APPDATA% or APPDATA.....on XP will be something like Documents and settings....anyway I should not diverse, It will check the preferences INI (which you are nominated to set on first installation of the Python Launcher) OR another INI file located next to the python launcher executable (which may or may not be in a writable place for the user....hence default first to their home drive)
Selecting the Python version instance at execution from the script will have the Launcher check the version firstly from the script (as you the user has specified what version your script requires) and then following the defaults....set out in the ini and so on and so on.
What I think might be the only conflict migrating to this kind of set up is if you are attempting to execute a script that uses a later version of python than what is shipped (that you specified in the header of the script) and trying to call ArcPy, a) ArcObjects won't know what that Python is even if the Python .PTH is filled correctly b) You cannot reference two versions of Python from one script. Note: (this is speculative saying this) You may be able to get away with creating a non Python script to execute two separate scripts of different versions of Python, however you may need to put some wait commands in to allow one instance to complete before carrying out the next function?
Aside from all of this, what ever you do DO NOT do a repair install on ArcGIS Python install. It does not and WILL not work. It will almost always end in a catastrophic abortionising of all pythons on the computer! AcrGIS Python does run an auto detection for existing instances of Python, HOWEVER it has customisations that it installs that messes everything up.
I would suggest always installing ArcGIS Python first, All ArcGIS service packs etc, then....I would suggest doing your other installs. Active Python will install over the top of ArcGIS one WILL ruin your ArcGIS instance, so to save heaps of hours wasted uninstalling and installing again I would suggest not installing Active Python over your ArcGIS instance.
There is a slim chance that installing a later python version and updating its .pth file may over ride the ArcGIS one and allow you to call ArcPy from say a 3.2.x Python install if all of the base requirements are met? I would proceed doing that with caution? It may require some version tags in your scripts if you wish to change/update your python (there are huge benefits of migrating to a newer version too! So would be great if everything worked)
Also I would suggest installing the Python Launcher as early as possible i.e. next. And then iterating through the rest or remaining Python installations after that. I would remove the ArcGIS Python Environment variable from Windows PATH if it creates one. From memory though ArcGIS does not do this (this is because they have been running an installer like the Launcher for sometime now and try to make ArcGIS "standalone" and not interfere with anyone elses Python instances but ensuring it knows where its own instance is located)....so if it does, remove it and let the Python launcher handle it.
From here on, I would suggest adopting the Python Launcher versioning in your scripting which is coincidently enough exactly the same references that Unix/Linux and some other O/S' use to identify Python.
*NOTE: This may or may not be required when working in the Python Window in ArcGIS, however this WILL be required when working from the console (windows command prompt) moving forward.
1) Install ESRI Python first if you can
2) Try not to install Python anywhere on the system that has spaces in your path....just purely for naming conventions and execution
3) Adopt the new header in all your scripts regardless from here on. ESRI recommend this anyway
4) Remove any existing references to Python Environment variables from the Windows System env.
5) Let Python Launcher handle python requests
6) Set your defaults in the Launcher INI file.
Hopefully happy days :) Good luck....oh and wish me luck too. I am about to go and perform what I have outlined.
Lastly...those of you using Eclipse, make sure there are no conflicts between that eclipse and any others i.e. Android SDK comes packaged with it's own eclipse but as far as I know doesn't have it's own Win Env reference.....but the bin folders do! And they contain batch scripts that may or may not override your Eclipse install if its different to the Android SDK.
