win32com ChartObject pythonwin vs idle
I'm curious as to why the difference between IDLE and pythonWin when using win32com. opening an excel file, i've attempted to grab the chart information out of the file. commands like co = ChartObjects(1) works in pythonWin but doesn't work in IDLE. however, on both co = chartobjects(1) works just fine. The same goes other things like SeriesCollection()/ seriescollection(1),seriescollection(2)..., Close()/close Is there any way to fix it such that IDLE works with ChartObject() too? I'd really like to be able to use ChartObject().Count() (there doesn't seem to be an equivalent chartobject.count) Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: win32com ChartObject pythonwin vs idle
On Jul 31, 4:28 am, Tim Golden <[EMAIL PROTECTED]> wrote:
> sterling wrote:
> > I'm curious as to why the difference between IDLE and pythonWin when
> > using win32com.
> > opening an excel file, i've attempted to grab the chart information
> > out of the file.
>
> > commands like co = ChartObjects(1) works in pythonWin but doesn't
> > work in IDLE.
>
> > however, on both co = chartobjects(1) works just fine.
>
> I can't speak for IDLE vs PythonWin but in general
> case-sensitivity of win32com stuff is related to
> early vs late Dispatch. If you've explicitly generated
> proxy modules for the Excel objects (via makepy,
> EnsureDispatch or whatever) then those are Python
> modules with case-sensitivity. If you're using dynamic
> dispatch then Python is simply passing your attribute
> name along to COM, which isn't case-sensitive, so either
> case will work.
>
> Not sure why IDLE vs PythonWin should make a difference
> here, but maybe the above explanation sheds some light...
>
> TJG
Thanks Tim. I'm wondering if it's an OS issues with Vista (I'm
strangly ashamed to admit that both my laptop and main computer are
running it).
I decided to try the same code on my main computer (do most of my work
on my laptop) and the exact same thing has happened: I can run it in
pythonwin and not idle.
I found that I can't even run Open (I must have been running open()
previously):
i.e.
>>> import win32com.client
>>> ex = win32com.client.Dispatch("Excel.Application")
>>> wb = ex.Workbooks.Open("C:\Temp\SalesChart.xls")
Traceback (most recent call last):
File "", line 1, in
wb = ex.Workbooks.Open("C:\Temp\SalesChart.xlsx")
File "C:\Python25\Lib\site-packages\win32com\client\dynamic.py",
line 467, in __getattr__
if self._olerepr_.mapFuncs.has_key(attr): return
self._make_method_(attr)
File "C:\Python25\Lib\site-packages\win32com\client\dynamic.py",
line 295, in _make_method_
methodCodeList =
self._olerepr_.MakeFuncMethod(self._olerepr_.mapFuncs[name],
methodName,0)
File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
297, in MakeFuncMethod
return self.MakeDispatchFuncMethod(entry, name, bMakeClass)
File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
318, in MakeDispatchFuncMethod
s = linePrefix + 'def ' + name + '(self' + BuildCallList(fdesc,
names, defNamedOptArg, defNamedNotOptArg, defUnnamedArg, defOutArg) +
'):'
File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
604, in BuildCallList
argName = MakePublicAttributeName(argName)
File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
542, in MakePublicAttributeName
return filter( lambda char: char in valid_identifier_chars,
className)
File "C:\Python25\Lib\site-packages\win32com\client\build.py", line
542, in
return filter( lambda char: char in valid_identifier_chars,
className)
UnicodeDecodeError: 'ascii' codec can't decode byte 0x83 in position
52: ordinal not in range(128)
but the exact same code works in PythonWin. Perhaps I will just find a
way to code everything I want in the older lowercase.
--
http://mail.python.org/mailman/listinfo/python-list
Re: win32com ChartObject pythonwin vs idle
On Jul 31, 11:22 pm, "Roger Upole" <[EMAIL PROTECTED]> wrote: > "sterling" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > > > > > > I'm curious as to why the difference between IDLE and pythonWin when > > using win32com. > > opening an excel file, i've attempted to grab the chart information > > out of the file. > > > commands like co = ChartObjects(1) works in pythonWin but doesn't > > work in IDLE. > > > however, on both co = chartobjects(1) works just fine. > > > The same goes other things like SeriesCollection()/ > > seriescollection(1),seriescollection(2)..., Close()/close > > > Is there any way to fix it such that IDLE works with ChartObject() > > too? I'd really like to be able to use ChartObject().Count() (there > > doesn't seem to be an equivalent chartobject.count) > > > Thanks. > > This was probably due to a conflict with the way IDLE sets the locale. > Bug report > here:http://sourceforge.net/tracker/index.php?func=detail&aid=2006053&grou... > > This is fixed in build 212, just released today. > > Roger- Hide quoted text - > > - Show quoted text - Thanks for the tip Roger. Installed 212 and it worked right away! -- http://mail.python.org/mailman/listinfo/python-list
Re: constructin trees in python
> Thanks a lot peter, that worked as i needed. Where can i find some
> good documentation which explains such behavior.
The reason for this behavior is the way python stores attributes.
Both a class and an instance of a class have a __dict__ attribute
which is a dictionary which stores attributes in name value pairs.
Consider the following class.
class A(object):
a = 1
def __init__(self, b):
self.b = b
Inspecting A.__dict__, one will see that it looks like {'a': 1} with
no reference to b.
Instantiating with a = A(2), one will see that a.__dict__ is {'b': 2}
with no reference to a.
If one accesses a.b, then Python will first look in a.__dict__ and
find 'b'. It will then return that value for a.b
If one instead accesses a.a then Python will first look in a.__dict__
and not find an entry for 'a'. It will then look in type(a).__dict__
== A.__dict__, find 'a' and return it for a.a
One can in fact use this behavior to shadow class attributes. If the
__init__ function is changed to
def __init__(self, a, b):
self.a = a
self.b = b
then all instances of A will have their own instance attribute named a
with whatever value is passed to __init__. They will still have a
class level attribute named a with value 1 but Python will never see
it because it will find an entry for a in some_instance.__dict__. If
one executes
del some_instance.a
Then on that one instance, visibility for the class level a will be
restored. In fact, one can always get the class level instance as
type(some_instance).__dict__['a'] but that's a little awkward.
The reason that this matters with mutable attributes and not with
(often) with immutable attributes is that a statement of the form
some_instance.some_mutable_attribute.append(foo)
will reference the same class level attribute regardless of the
instance it's called with. There's no assignment going on here. An
existing binding is being looked up, and the resulting value (a list
in this case) is having an attribute called on it. No new bindings are
being created. A statement of the form
some_instance.some_mutable_attribute = some_new_list
Will not affect the class level attribute at all but will simply
shadow it in the same manner as describe above. Once a name is bound
to an immutable value, the only way to change the value that it points
to is to rebind it. This means that any 'change' to a class level
immutable value (accessed through attribute lookup on an instance)
will simply shadow it on the instance upon which it is accessed.
HTH
--
http://mail.python.org/mailman/listinfo/python-list
