ActivePython on Windows: References Question
mhammond at skippinet.com.au
Wed Jan 15 05:18:42 CET 2003
Alex K. Angelopoulos wrote:
> Thanks for all the info. I have some notes below, inline.
> I've noticed issues with many Python scripts not working when run from
> wscript/cscript, and part of it does seem to be core engine implementation.
Standard python scripts are not really designed to be run from
All the axscript\demos\wsh demo files work for me, but WSH is
particularly useless for Python programmers - there is nothing WSH can
do that Python itself can not do. Hence I can see no reason at all to
use Python under WSH.
> I suspect the major problem is the lack of a lot of interest in this hosting
This is largely true. People using Python are generally unlikely to
choose IIS/ASP as their web hosting model. People choosing IIS/ASP as
their hosting model are more likely to stick with VB/JS.
This leaves the only users of this technology being poor Python
programmers having this stuff thrust down their throats, but they remain
grateful that Python is at least available. When these people come to
advocating their use of technology, they are more likely to advocate
Python itself than specifically Python hosted under ASP/WSH.
> If the Python core was much more widely distributed as an Active
> Scripting engine, it would make sense, but in my experience most Windows users
> who install Python actually use the entire language natively - you get access to
> a lot of fully-wrapped functionality that way.
Almost anyone who uses Python on Windows ends up with either
ActivePython or win32all, so I believe it quite widely distributed.
>>Mark Hammond seems to be the single source for all the win32 extensions
> he also is the author of one of the few other Active Scripting engines available
> in source form, a "Forthish" example available for download from MSKB.
That is a blast from the past :)
> The problem with Python COM examples is that even the ones which claim to be
> "WSH examples", is that they usually aren't. They are usually demos of
> accessing COM objects installed _with_ WSH, but hosted by Python itself.
This is pretty gray. The following Python code:
WshShell = WScript.CreateObject("WScript.Shell")
WshShell.Popup("This script shows ...", 2)
Is pure Python code, but will only work under WSH. While Python is not
*creating* these WSH objects directly, it is still creating them and
using them like any other COM object.
ie, this code is almost identical to:
WshShell = win32com.client.Dispatch("WScript.Shell")
The fact one is run under WSH and the other via Python directly is
really just a matter of a few levels of indirection.
I'm not trying to argue with anything you said, but am trying to
downplay the relevence <wink>
More information about the Python-list