On 5/29/2015 3:28 PM, Paul Moore wrote:
On 29 May 2015 at 23:15, Glenn Linderman firstname.lastname@example.org wrote:
I don't presently see any C:\Python34\DLLs or C:\Python34 on my path, but I didn't ask the installer to put it there either. So I'm guessing your option 1 assumes asking the Python installer to put it there? Not "automatically" but "on request", I think?
In my c:\Python34\DLLs, I don't see a python34.dll, only python3.dll... so I'm somewhat unclear on your simplified explanation.
I'm definitely batting zero today :-(
OK, let's try to be clear. I typically do "all users" installs. The "for me only" install is slightly different, and the new install for 3.5 may be different again. But what I see is:
- C:\Python34\DLLs containins python3.dll, which is *never* on PATH
(and doesn't need to be for normal use). Anything that wants to use python3.dll needs that directory manually adding to PATH. 2. python34.dll is in C:\Windows\System32. This is always available to all processes, as it's in the Windows system directory.
If you say "add Python to my PATH" you get C:\Python34 added to PATH. For a user install, I believe python34.dll may be in there rather than in C:\Windows\system32, so technically, for an app that uses python34.dll to work, you need *either* an admin install, *or* to have done "add Python to PATH".
In C:, I have directories Python27, Python32, Python33, Python34. I can't be 100% sure how I answered the install questions, even Python34 was a couple months ago.
In C:\Windows\System32, I have python27.dll, python32.dll, python33.dll, pythoncom32.dll, pythoncom33.dll, pythoncomloader32.dll, and pythoncomloader33.dll. But not python34.dll! I finally found that in c:\Windows\SysWOW64, which I guess means that I "accidentally" installed a 32-bit Python 3.4. Or maybe I had a reason at the time. But does that add another dimension to the picture for the stub?
I hope that made sense. Sorry for my garbled previous version.
This matches reality better... but whether it makes sense or not is another question.
On 5/29/2015 3:33 PM, Steve Dower wrote:
Paul Moore wrote:
One mildly annoying thing is that python3.dll is only installed in
<python install dir>\DLLs, which
typically isn't on PATH. So actually using the limited API from your
own application fails by default.
Fixing that's mostly a user admin issue, though (and you can just
link to the full API and avoid the whole problem).
I didn't even notice that 3.4 (and earlier?) were doing that, so I
changed/fixed it by accident :)
Indeed, and earlier. It apparently started in 3.2 with the definition of the Stable ABI.
Python 3.5 installs python3.dll alongside python35.dll, so it'll go
into the user's Python directory by default or into the system directory for an all-users installation. The embeddable distro includes python3.dll alongside the other DLLs as well.
This makes more sense... but will it cause problems with something? It seems to me like it was a bug to put it in the <python install dir> rather than %windir%\System32 back in Python 3.2 days when it was invented. What good is it to have a stable ABI that is hidden away where it cannot (easily) be used, and the more dynamic API is easier to get to?
Sadly, PEP 384 is silent on the location of python3.dll.