[pywin32-bugs] [ pywin32-Patches-2630059 ] patch for genpy.py to improve support for constants class

[SourceForge.net <no...@so...>]

Patches item #2630059, was opened at 2009-02-23 23:53
Message generated for change (Settings changed) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2630059&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Michael Neuroth (mindia)
Assigned to: Mark Hammond (mhammond)
Summary: patch for genpy.py to improve support for constants class

Initial Comment:
With the build 213 I had problems with a COM class when using genpy.py. The COM class has no constants defined but the method Generator.do_generate() in the genpy.py file had problems to generate a valid python class. The following construct was generated:

...
MajorVersion = 1
MinorVersion = 1
LibraryFlags = 8
LCID = 0x0

class constants:

from win32com.client import DispatchBaseClass
class IMyInterface(DispatchBaseClass):
	"""IMyInterface Interface"""
...

Unfortunately this code is not a valid python code.

I appied the following patch to genpy.py which helped me to fix this problem. Maybe a similar patch could be included into the original source code?

======= Modifications in genpy.py ==========

  def do_generate(self):
    ...
    # Generate the constants and their support.
    if enumItems:
        iTotalCount = 0                                             # PATCH
        print >> stream, "class constants:"
        items = enumItems.values()
        items.sort()
        for oleitem in items:
            iTotalCount += oleitem.WriteEnumerationItems(stream)    # PATCH
            self.progress.Tick()
        if iTotalCount==0:                                          # PATCH
            print >> stream, "\tpass"                               # PATCH
        print >> stream

    ...

class EnumerationItem(build.OleItem, WriteableItem):
  ...

  def WriteEnumerationItems(self, stream):
    enumName = self.doc[0]
    iItemCount = 0                                      # PATCH
    # Write in name alpha order
    names = list(self.mapVars.keys())
    names.sort()
    for name in names:
      entry = self.mapVars[name]
      vdesc = entry.desc
      if vdesc[4] == pythoncom.VAR_CONST:
        val = vdesc[1]
        if sys.version_info <= (2,4) and (isinstance(val, int) or isinstance(val, long)):
          # in python 2.3, 0x80000000L == 2147483648
          if val==2147483648: # == 0x80000000L - special case for 2.3...
            use = "0x80000000L" # 'L' for future warning
          elif val > 2147483648 or val < 0: # avoid a FutureWarning
            use = long(val)
          else:
            use = hex(val)
        else:
          use = repr(val)
        print >> stream, "\t%-30s=%-10s # from enum %s" % \
                      (build.MakePublicAttributeName(name, True), use, enumName)
        iItemCount += 1                                 # PATCH
    return iItemCount                                   # PATCH



----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2010-08-30 10:52

Message:
Thanks!
Checking in genpy.py;
new revision: 1.68; previous revision: 1.67

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2009-02-25 09:27

Message:
Right - typedefs also appear there, which explains things.  I certainly do
want pywin32 to be robust against *real* problems - I just needed to
understand this one well enough to convince myself it was real :)  I'll
apply your patch, thanks.

----------------------------------------------------------------------

Comment By: Michael Neuroth (mindia)
Date: 2009-02-24 23:29

Message:
Sorry, I missed a line of code:

    typedef [public    ,
      custom(F914481D-9C62-4B43-9340-E9B2E6252E5F, 1)    
]
    unsigned long ULONG_PTR;


----------------------------------------------------------------------

Comment By: Michael Neuroth (mindia)
Date: 2009-02-24 23:27

Message:
The COM object is until now only used internally. 
I found out that the following definition in the IDL file caused the
problems:

[id(7), helpstring("method getNumberInfos")] HRESULT getNumberInfos([out,
retval] SIZE_T* number);

This statement produced in the type library (I used OLEView to display
this information) this data:

typedef [public    ,
   custom(F914481D-9C62-4B43-9340-E9B2E6252E5F, 1)    
]

When I replaced the SIZE_T type in the method the problematic data in the
type library disappeared and genpy.py has no problems at all to generate a
valid python file.
I am not sure if the type SIZE_T is a valid COM type. The type SIZE_T is
defined in the header file BaseTds.h as follows:

typedef ULONG_PTR SIZE_T, *PSIZE_T;

And the COM object could be created with MS Visual Studio 2008 without
errors.
Isn't it a good idea to make the genpy.py code robust against 'unclean'
(but valid) input?



----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2009-02-24 09:47

Message:
What COM object is this?  I'm interested to know how we are getting
enumeration items, but ending up with no constants.  In other words, the
correct fix may be elsewhere - to have enumItems only have real items with
constants and the existing check for enumItems to continue doing its job.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2630059&group_id=78018