python ScriptControl error in Excel while running fine in python

[Sebastien de Menten]

I am trying to use ScriptControl under Excel (Windows XP) with the
code:

Global sc As New MSScriptControl.ScriptControl

Public Function os_getcwd()
sc.Language = "python"
sc.ExecuteStatement ("import os")
os_getcwd = sc.Eval("os.getcwd()")
End Function

When setting the language to python I have the error "A script engine
for the specified language..."

On the other side, under python, the translated code:

import win32com.client

sc=win32com.client.Dispatch("ScriptControl")
sc.Language = "python"
sc.ExecuteStatement ("import os")
print sc.Eval("os.getcwd()")

works without any problem !

So, is it possible that a different set of permissions for languages
available in ScriptControl is used when executed from Excel or from
python ?
Is it possible to ask the available languages to ScriptControl ?

Well, in fact I am totally puzzled by this behaviour so any help is
welcome :-)

Sebastien

PS: could you reply to my email address as I do not read regularly
c.l.p. ? thanks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: args attribute of Exception objects

[Sebastien de Menten]

Jeremy Bowers <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> On Fri, 08 Apr 2005 09:32:37 +, SÃÂbastien de Menten wrote:
> 
> > Hi,
> > 
> > When I need to make sense of a python exception, I often need to parse the 
> > string exception in order to retrieve the data.
> 
> What exactly are you doing with this info? (Every time I started to do
> this, I found a better way. Perhaps one of them will apply for you.)
> 
> (As a general comment, I'd point out that you don't have to check the
> entire error message; checking for a descriptive substring, while still
> not "safe", is at least safe*r*.)

I have symbolic expressions in a dictionnary like:

dct = dict( a = "b**2 + c", b = "cos(2.3) + sin(v)", v = "4", c =
"some_very_expensive_function(v)")

I want to build a function that finds the links between all those
expressions (think about computing dependencies between cells in a
spreadsheet).

All I do is:
def link(name):
   dependencies = {}
   while True:
  try:
 eval(dct[name], globals(), dependencies)
  except NameError,e:
 dependencies[e.args[0][6:-16]] = 1
  else:
 return dependencies

globals() can be replaced by a custom dictionnary for security
purposes.
variation on the theme can:
  - check SyntaxError and give interlligent feedback to user (BTW,
SyntaxError args are much smarter)
  - find or/and eval recursively the whole tree and keep in cache
values,...

Seb
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: args attribute of Exception objects

[Sebastien de Menten]

Thank you guys for those good advices (and the very interesting
example of AST hacking).

However, this was an example of use for Exception.args. It does not
alleviate my concerns about the fact that the args attribute is poorly
designed for standard Exceptions.
It is as if the Exception design was only made for end users (display
of a string in an interpreter) without thinking about original ways to
use them :-)

Seb
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: args attribute of Exception objects

[Sebastien de Menten]

> Did I misunderstand the problem again?

Hmmm, yes ! But I think I am not expressing clearly my concern :-)

So my problem is that "default exception" are badly designed in their
use of their args attribute.

I know it is possible to subclass Exception as every object and add
the attributes I want with the name I want, etc...

BUT, some (if not most) default exceptions in __builtins__ use the
args attribute and put a string in it without delivering interesting
information about the exception.

So 1) I think it is nice to keep args as name for the attribute as it
avoids looking at the documentation for looking at each specific
exception/attribute name.
   2) but args should be more cleverly designed (again, I am speaking
about exceptions in __builtins__ not user defined exceptions) and not
be a simple string.

Now, forcing user to avoid using default exceptions (i.e. force them
to use user defined exceptions) for anything but interactive use or
debugging is short minded (nobody says that, but the current situation
implies that).

Anyway, I log this as request on SF.

Best regards,

Sed
-- 
http://mail.python.org/mailman/listinfo/python-list