ActivePython on Windows: References Question

[Mark Hammond]

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 
wscript/cscript.

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
> model.  

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")
WshShell.Popup(...)

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>

Mark.