pywin32-bugs Mailing List for Python for Windows Extensions
OLD project page for the Python extensions for Windows
Brought to you by:
mhammond
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
(19) |
Jun
(15) |
Jul
(43) |
Aug
(39) |
Sep
(25) |
Oct
(43) |
Nov
(19) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(21) |
Feb
(18) |
Mar
(14) |
Apr
(80) |
May
(56) |
Jun
(24) |
Jul
(30) |
Aug
(17) |
Sep
(36) |
Oct
(106) |
Nov
(38) |
Dec
(30) |
2005 |
Jan
(14) |
Feb
(14) |
Mar
(48) |
Apr
(28) |
May
(49) |
Jun
(23) |
Jul
(9) |
Aug
(13) |
Sep
(28) |
Oct
(21) |
Nov
(8) |
Dec
(26) |
2006 |
Jan
(56) |
Feb
(33) |
Mar
(33) |
Apr
(18) |
May
(16) |
Jun
(9) |
Jul
(24) |
Aug
(16) |
Sep
(14) |
Oct
(37) |
Nov
(38) |
Dec
(22) |
2007 |
Jan
(7) |
Feb
(16) |
Mar
(11) |
Apr
(15) |
May
(15) |
Jun
(8) |
Jul
(24) |
Aug
(26) |
Sep
(18) |
Oct
(11) |
Nov
(20) |
Dec
(1) |
2008 |
Jan
(19) |
Feb
(55) |
Mar
(7) |
Apr
(35) |
May
(66) |
Jun
(38) |
Jul
(26) |
Aug
(5) |
Sep
(25) |
Oct
(25) |
Nov
(18) |
Dec
(18) |
2009 |
Jan
(25) |
Feb
(38) |
Mar
(29) |
Apr
(25) |
May
(5) |
Jun
(11) |
Jul
(16) |
Aug
(16) |
Sep
(16) |
Oct
(1) |
Nov
(15) |
Dec
(33) |
2010 |
Jan
(13) |
Feb
(11) |
Mar
(1) |
Apr
(24) |
May
(26) |
Jun
(19) |
Jul
(22) |
Aug
(51) |
Sep
(38) |
Oct
(39) |
Nov
(25) |
Dec
(27) |
2011 |
Jan
(40) |
Feb
(31) |
Mar
(21) |
Apr
(42) |
May
(11) |
Jun
(16) |
Jul
(20) |
Aug
(14) |
Sep
(6) |
Oct
(8) |
Nov
(34) |
Dec
(7) |
2012 |
Jan
(60) |
Feb
(24) |
Mar
(6) |
Apr
(28) |
May
(41) |
Jun
(15) |
Jul
(14) |
Aug
(25) |
Sep
(30) |
Oct
(18) |
Nov
(30) |
Dec
(9) |
2013 |
Jan
(3) |
Feb
(8) |
Mar
(17) |
Apr
(23) |
May
(34) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
From: Mark H. <mha...@sk...> - 2017-10-03 00:00:07
|
This isn't the correct list - try the python-win32 mailing list. You need to be subscribed to the list before you can post to it - see http://mail.python.org/mailman/listinfo/python-win32 for subscription options. However, I don't believe it will be possible to build pywin32 as a buitin module - for one thing, there's really no single module named "pywin32" - there are lots of modules, and many of the features simply will not work. You might be able to get it working for some modules, but I suspect it will take some significant hacks that will not be accepted back into the tree. You should consider mailing the python-win32 list with the underlying problems causing you to believe this is the solution and see if they have alternative solutions. Cheers, Mark On 3/10/2017 7:39 AM, A wrote: > Hello, > > I need some assistance please regarding building PyWin32. I hope that > this is the correct mailing list to ask this, but if not, please direct > me to the right place. I'm wondering if it's possible to build PyWin32 > into Python as a built-in module? I would like to do this with Python > 2.7.13 64-bit for Windows. I have Microsoft Visual Studio 2008 and VS > 2010 Service Pack 1 installed, and I have built Python from the source > code with "pcbuild.sln". I found that most of the modules distributed > with Python can be made to be built-in by changing the module's project > type to be "Static library (.lib)" rather than a DLL project, adding > "Py_BUILD_CORE;Py_NO_ENABLE_SHARED;" to the module project's > preprocessor directives, changing the project references so that the > "pythoncore" project refers to the module's project rather than the > module's project referring to "pythoncore", and adding corresponding > lines for the module in "PC\config.c" (in the "pythoncore" project). > (There are a few more steps/hacks needed for some of the modules, but > that is the basic process.) I can do this because the modules > distributed with Python ("bz2", "_ctypes", etc.) are Visual Studio > projects. However, PyWin32 is much different because it is built with > Python Distutils and a "setup.py" script, not a Visual Studio > project/solution. Usually, PyWin32 would be built with the command > "python setup.py {build|install}". I have tried playing with > command-line options to no avail thus far. I have also tried including > all of the .c, .cpp, .cxx, .h, etc. files from the PyWin32 source > directories into the "pythoncore" Visual Studio project, but this didn't > end up working. I figure that I would need to do one of two things: > either (a) the PyWin32 modules need to be built as static library (.lib) > files rather than .pyd files somehow, and "pythoncore" needs to link to > those .lib files (like I did with the modules distributed with Python), > or (b) I need to include PyWin32's source files into the "pythoncore" > project somehow (and the way that I tried it was incorrect for some reason). > > Can someone please provide guidance as to how I can properly build > PyWin32 into Python as a built-in module? Is there a quick way of doing > this, or would it take an entire overhaul of all of PyWin32's source > code to accomplish this? > > Thank you! > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > pywin32-bugs mailing list > pyw...@li... > https://lists.sourceforge.net/lists/listinfo/pywin32-bugs > |
From: A <abc...@gm...> - 2017-10-02 20:39:34
|
Hello, I need some assistance please regarding building PyWin32. I hope that this is the correct mailing list to ask this, but if not, please direct me to the right place. I'm wondering if it's possible to build PyWin32 into Python as a built-in module? I would like to do this with Python 2.7.13 64-bit for Windows. I have Microsoft Visual Studio 2008 and VS 2010 Service Pack 1 installed, and I have built Python from the source code with "pcbuild.sln". I found that most of the modules distributed with Python can be made to be built-in by changing the module's project type to be "Static library (.lib)" rather than a DLL project, adding "Py_BUILD_CORE;Py_NO_ENABLE_SHARED;" to the module project's preprocessor directives, changing the project references so that the "pythoncore" project refers to the module's project rather than the module's project referring to "pythoncore", and adding corresponding lines for the module in "PC\config.c" (in the "pythoncore" project). (There are a few more steps/hacks needed for some of the modules, but that is the basic process.) I can do this because the modules distributed with Python ("bz2", "_ctypes", etc.) are Visual Studio projects. However, PyWin32 is much different because it is built with Python Distutils and a "setup.py" script, not a Visual Studio project/solution. Usually, PyWin32 would be built with the command "python setup.py {build|install}". I have tried playing with command-line options to no avail thus far. I have also tried including all of the .c, .cpp, .cxx, .h, etc. files from the PyWin32 source directories into the "pythoncore" Visual Studio project, but this didn't end up working. I figure that I would need to do one of two things: either (a) the PyWin32 modules need to be built as static library (.lib) files rather than .pyd files somehow, and "pythoncore" needs to link to those .lib files (like I did with the modules distributed with Python), or (b) I need to include PyWin32's source files into the "pythoncore" project somehow (and the way that I tried it was incorrect for some reason). Can someone please provide guidance as to how I can properly build PyWin32 into Python as a built-in module? Is there a quick way of doing this, or would it take an entire overhaul of all of PyWin32's source code to accomplish this? Thank you! |
From: wzint <zi...@op...> - 2015-11-10 21:26:15
|
PyWin32 build 213 and up exhibit lots of orphaned object.Object proxy objects. How to reproduce: Get a vanilla Python and PyWin32 build >=213 installation (32 or 64 bit). I have used PythonWin 219 and Python 2.7 for this listings. Start PythonWin, open the interactive window. Enter import gc,pprint from pywin.mfc import object enumerate the existing object.Objects gc.collect() pprint.pprint([obj for obj in gc.get_objects() if isinstance(obj,object.Object)]) #one gets a list like this: [<pywin.framework.intpyapp.InteractivePythonApp instance at 0x00C1AC60>, <pywin.framework.intpydde.DDEServer instance at 0x00CA9198>, <pywin.framework.intpydde.DDESystemTopic instance at 0x00CA9620>, <pywin.framework.intpyapp.MainFrame instance at 0x00CA99E0>, <pywin.framework.editor.color.coloreditor.SyntEditTemplate instance at 0x00DCC440>, <pywin.docking.DockingBar.DockingBar instance at 0x00CAEA30>, <pywin.debugger.debugger.DebuggerStackWindow instance at 0x00DD7418>, <pywin.docking.DockingBar.DockingBar instance at 0x00CAE210>, <pywin.debugger.debugger.DebuggerBreakpointsWindow instance at 0x00CAE828>, <pywin.docking.DockingBar.DockingBar instance at 0x00DD7530>, <pywin.debugger.debugger.DebuggerWatchWindow instance at 0x00DD7828>, <pywin.docking.DockingBar.DockingBar instance at 0x00DDC210>, <pywin.framework.interact.CDockedInteractivePython instance at 0x00DDC2B0>, <pywin.framework.winout.WindowOutputDocument instance at 0x00DDC3A0>, <pywin.framework.interact.DockedInteractiveView instance at 0x00DDC828>, <pywin.debugger.debugger.HierListDebugger instance at 0x00DD7440>, <pywin.framework.sgrepmdi.GrepTemplate instance at 0x00E2E710>, <pywin.framework.mdi_pychecker.TheTemplate instance at 0x00E355F8>] #Enter Ctrl-N (File/New) and select python script and immediately close the script window again. Only the interactive window remains. List the existing object.Objects again: gc.collect() pprint.pprint([obj for obj in gc.get_objects() if isinstance(obj,object.Object)]) [<pywin.framework.intpyapp.InteractivePythonApp instance at 0x00C1AC60>, <pywin.framework.intpydde.DDEServer instance at 0x00CA9198>, <pywin.framework.intpydde.DDESystemTopic instance at 0x00CA9620>, <pywin.framework.intpyapp.MainFrame instance at 0x00CA99E0>, <pywin.framework.editor.color.coloreditor.SyntEditTemplate instance at 0x00DCC440>, <pywin.docking.DockingBar.DockingBar instance at 0x00CAEA30>, <pywin.debugger.debugger.DebuggerStackWindow instance at 0x00DD7418>, <pywin.docking.DockingBar.DockingBar instance at 0x00CAE210>, <pywin.debugger.debugger.DebuggerBreakpointsWindow instance at 0x00CAE828>, <pywin.docking.DockingBar.DockingBar instance at 0x00DD7530>, <pywin.debugger.debugger.DebuggerWatchWindow instance at 0x00DD7828>, <pywin.docking.DockingBar.DockingBar instance at 0x00DDC210>, <pywin.framework.interact.CDockedInteractivePython instance at 0x00DDC2B0>, <pywin.framework.winout.WindowOutputDocument instance at 0x00DDC3A0>, <pywin.framework.interact.DockedInteractiveView instance at 0x00DDC828>, <pywin.debugger.debugger.HierListDebugger instance at 0x00DD7440>, <pywin.framework.sgrepmdi.GrepTemplate instance at 0x00E2E710>, <pywin.framework.mdi_pychecker.TheTemplate instance at 0x00E355F8>, <pywin.framework.editor.color.coloreditor.SyntEditDocument instance at 0x00E73B48>, <pywin.framework.editor.color.coloreditor.SplitterFrame instance at 0x00E73CB0>, <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x00E73F58>, <pywin.framework.editor.ModuleBrowser.BrowserView instance at 0x00E77198>, <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x00E772D8>, <pywin.framework.editor.document.FileWatchingThread instance at 0x00E73B70>] #Note we have a SyntEditDocument, a SplitterFrame, two SyntEditViews and a FileWatchingThread #Enter Ctrl-N (File/New), select python script four times and immediately close these windows again. List again: gc.collect() pprint.pprint([obj for obj in gc.get_objects() if isinstance(obj,object.Object)]) [<pywin.framework.intpyapp.InteractivePythonApp instance at 0x00C1AC60>, <pywin.framework.intpydde.DDEServer instance at 0x00CA9198>, <pywin.framework.intpydde.DDESystemTopic instance at 0x00CA9620>, <pywin.framework.intpyapp.MainFrame instance at 0x00CA99E0>, <pywin.framework.editor.color.coloreditor.SyntEditTemplate instance at 0x00DCC440>, <pywin.docking.DockingBar.DockingBar instance at 0x00CAEA30>, <pywin.debugger.debugger.DebuggerStackWindow instance at 0x00DD7418>, <pywin.docking.DockingBar.DockingBar instance at 0x00CAE210>, <pywin.debugger.debugger.DebuggerBreakpointsWindow instance at 0x00CAE828>, <pywin.docking.DockingBar.DockingBar instance at 0x00DD7530>, <pywin.debugger.debugger.DebuggerWatchWindow instance at 0x00DD7828>, <pywin.docking.DockingBar.DockingBar instance at 0x00DDC210>, <pywin.framework.interact.CDockedInteractivePython instance at 0x00DDC2B0>, <pywin.framework.winout.WindowOutputDocument instance at 0x00DDC3A0>, <pywin.framework.interact.DockedInteractiveView instance at 0x00DDC828>, <pywin.debugger.debugger.HierListDebugger instance at 0x00DD7440>, <pywin.framework.sgrepmdi.GrepTemplate instance at 0x00E2E710>, <pywin.framework.mdi_pychecker.TheTemplate instance at 0x00E355F8>, <pywin.framework.editor.color.coloreditor.SyntEditDocument instance at 0x00E73B48>, <pywin.framework.editor.color.coloreditor.SplitterFrame instance at 0x00E73CB0>, <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x00E73F58>, <pywin.framework.editor.ModuleBrowser.BrowserView instance at 0x00E77198>, <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x00E772D8>, <pywin.framework.editor.document.FileWatchingThread instance at 0x00E73B70>, <pywin.framework.editor.color.coloreditor.SplitterFrame instance at 0x00E8A490>, <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x00E8A238>, <pywin.framework.editor.ModuleBrowser.BrowserView instance at 0x00E8A3F0>, <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x00E8A620>, <pywin.framework.editor.color.coloreditor.SplitterFrame instance at 0x00E9D9B8>, <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x00E9DA30>, <pywin.framework.editor.ModuleBrowser.BrowserView instance at 0x00E9DBE8>, <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x00E9DC10>, <pywin.framework.editor.color.coloreditor.SplitterFrame instance at 0x00EAE5A8>, <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x00EAE620>, <pywin.framework.editor.ModuleBrowser.BrowserView instance at 0x00EAE7D8>, <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x00EAE800>, <pywin.framework.editor.color.coloreditor.SyntEditDocument instance at 0x00EBD0D0>, <pywin.framework.editor.color.coloreditor.SplitterFrame instance at 0x00EBD1C0>, <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x00EBD238>, <pywin.framework.editor.ModuleBrowser.BrowserView instance at 0x00EBD3F0>, <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x00EBD418>, <pywin.framework.editor.color.coloreditor.SyntEditDocument instance at 0x00E8A968>, <pywin.framework.editor.color.coloreditor.SyntEditDocument instance at 0x00E9D8A0>, <pywin.framework.editor.color.coloreditor.SyntEditDocument instance at 0x00EAE490>, <pywin.framework.editor.document.FileWatchingThread instance at 0x00EBD0A8>, <pywin.framework.editor.document.FileWatchingThread instance at 0x00E8A738>, <pywin.framework.editor.document.FileWatchingThread instance at 0x00E9D8C8>, <pywin.framework.editor.document.FileWatchingThread instance at 0x00EAE4B8>] # four more sets of orphans # I am particularly concerned about docview.Documents. Define a helper fn=lambda ty: [obj for obj in gc.get_objects() if isinstance(obj,ty)] from pywin.mfc import docview fn(docview.Document) [<pywin.framework.winout.WindowOutputDocument instance at 0x00DDC3A0>, <pywin.framework.editor.color.coloreditor.SyntEditDocument instance at 0x00E73B48>, <pywin.framework.editor.color.coloreditor.SyntEditDocument instance at 0x00EBD0D0>, <pywin.framework.editor.color.coloreditor.SyntEditDocument instance at 0x00E8A968>, <pywin.framework.editor.color.coloreditor.SyntEditDocument instance at 0x00E9D8A0>, <pywin.framework.editor.color.coloreditor.SyntEditDocument instance at 0x00EAE490>] # these have a substantial reference counts import sys sys.getrefcount(fn(docview.Document)[1]) 10 # ...etc, until the end... sys.getrefcount(fn(docview.Document)[-1]) 10 # if one examines the orphans, the _obj_ member is None. So, these objects detatched correctly and # should perish at some time. # I have been using pythonwin up to build 212 in the past, these versions are not affected by this behaviour. Best regards Wolfgang Zint |
From: SourceForge.net <no...@so...> - 2013-05-19 23:11:14
|
Bugs item #3613577, was opened at 2013-05-18 22:23 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613577&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: pythonwin Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nick Jacobson (nicksjacobson) Assigned to: Nobody/Anonymous (nobody) Summary: Windows tray icon not removed after crash Initial Comment: In Windows 7, open an instance of pythonwin. A small green snake appears in the windows tray in the taskbar. Run this one-line program in pythonwin: "while True: pass". It will begin processing and never return. Force close the application. bug: In the windows tray, the green snake still appears until you mouse over it, at which time it disappears. This happens reliably every time after a program crash. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-05-19 16:11 Message: You'll find this is true for every program using such an icon. The problem is obviously that the program responsible for managing it has crashed, so has lost the opportunity to remove it! ---------------------------------------------------------------------- Comment By: Nick Jacobson (nicksjacobson) Date: 2013-05-18 22:25 Message: Expected behavior: Snake icon should disappear from the tray after a pythonwin crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613577&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-19 05:25:54
|
Bugs item #3613577, was opened at 2013-05-18 22:23 Message generated for change (Comment added) made by nicksjacobson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613577&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: pythonwin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nick Jacobson (nicksjacobson) Assigned to: Nobody/Anonymous (nobody) Summary: Windows tray icon not removed after crash Initial Comment: In Windows 7, open an instance of pythonwin. A small green snake appears in the windows tray in the taskbar. Run this one-line program in pythonwin: "while True: pass". It will begin processing and never return. Force close the application. bug: In the windows tray, the green snake still appears until you mouse over it, at which time it disappears. This happens reliably every time after a program crash. ---------------------------------------------------------------------- >Comment By: Nick Jacobson (nicksjacobson) Date: 2013-05-18 22:25 Message: Expected behavior: Snake icon should disappear from the tray after a pythonwin crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613577&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-19 05:23:00
|
Bugs item #3613577, was opened at 2013-05-18 22:23 Message generated for change (Tracker Item Submitted) made by nicksjacobson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613577&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: pythonwin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nick Jacobson (nicksjacobson) Assigned to: Nobody/Anonymous (nobody) Summary: Windows tray icon not removed after crash Initial Comment: In Windows 7, open an instance of pythonwin. A small green snake appears in the windows tray in the taskbar. Run this one-line program in pythonwin: "while True: pass". It will begin processing and never return. Force close the application. bug: In the windows tray, the green snake still appears until you mouse over it, at which time it disappears. This happens reliably every time after a program crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613577&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-16 23:20:06
|
Feature Requests item #3613470, was opened at 2013-05-16 16:20 Message generated for change (Tracker Item Submitted) made by nicksjacobson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3613470&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: pythonwin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nick Jacobson (nicksjacobson) Assigned to: Nobody/Anonymous (nobody) Summary: Drag and drop variables into Watch pane Initial Comment: While debugging with the Watch pane open, highlight a variable and try to drag it over into the watch pane. The "crossed out" symbol appears. See screenshot. Instead, it would be great if the variable could be dragged and dropped into the watch pane. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3613470&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-16 22:52:17
|
Bugs item #3613465, was opened at 2013-05-16 15:52 Message generated for change (Tracker Item Submitted) made by nicksjacobson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613465&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: pythonwin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nick Jacobson (nicksjacobson) Assigned to: Nobody/Anonymous (nobody) Summary: Control-V not mapped to Watch pane Initial Comment: In the Watch window if you double click on a variable, you can type a new name for it. bug: But if you hit Control-V to paste text in, it gets pasted into the code window instead. expected behavior: Control-V (and Control-C, Control-X, etc.) should map to the highlighted watch variable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613465&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-14 13:57:41
|
Bugs item #3613297, was opened at 2013-05-14 06:57 Message generated for change (Tracker Item Submitted) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613297&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: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Gencache throws excpeption running as restricted user Initial Comment: If the installation location is in a restricted area. and if a directory gen_py exists in the win32com directory, working as restricted user throws an exception, either while - generating the default __init__.py if not existing during "from win32com import client" - rebuilding the gencache cache (dicts.dat) during "from win32com.client import gencache" - generating an on demand wrapper (gencache.EnsureDispatch) This fix checks the accessibility of the directory and remaps the gencache path to the temp directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613297&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-14 12:49:44
|
Bugs item #3613288, was opened at 2013-05-14 05:10 Message generated for change (Comment added) made by uvapalmer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613288&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: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joshua Palmer (uvapalmer) Assigned to: Nobody/Anonymous (nobody) Summary: Installation of windows service fails when py files in zip Initial Comment: Python supports running py (or pyc) files directly out of zip files. There are two problems with this in pywin32: First, in GetServiceClassString the fname correctly represents the full path to the python file, but the win32api.FindFiles method does not find it because it is inside of a zip file. I got around this by checking to see if the file exists and if not seeing if there was a file with a .zip extension that exists in the path. If so, assume that it is correct. Second, when installing python files from within a zip file, the argv parameters from python are as follows: [0] – The full path to the python file, [1] – The full path to the zip file, [2:] – Any other parameters. To get around this, I check to see if [1] references a zip file that exists. If so, I delete [1]. Another option would be to also determine if [1] was a substring of [0]. There are a couple steps to run python files out of a zip file. - Create a zip file containing python files - Create a pth file containing a full path to the zip file. Put the file into %PYTHON_HOME%/Lib/site-packages. - If you are attempting to call the myPyFile.py file in the zip file residing at c:\myZipFile.zip, the command line would look something like: “%PYTHON_HOME%/python.exe –m myPyFile c:/myZipFile.zip install” ---------------------------------------------------------------------- >Comment By: Joshua Palmer (uvapalmer) Date: 2013-05-14 05:49 Message: This problem only occurs during service installation. Once the service is installed, it runs successfully. ---------------------------------------------------------------------- Comment By: Joshua Palmer (uvapalmer) Date: 2013-05-14 05:16 Message: I have added files showing the changes I made in order to make this work for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613288&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-14 12:48:20
|
Bugs item #3613288, was opened at 2013-05-14 05:10 Message generated for change (Settings changed) made by uvapalmer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613288&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: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joshua Palmer (uvapalmer) Assigned to: Nobody/Anonymous (nobody) >Summary: Installation of windows service fails when py files in zip Initial Comment: Python supports running py (or pyc) files directly out of zip files. There are two problems with this in pywin32: First, in GetServiceClassString the fname correctly represents the full path to the python file, but the win32api.FindFiles method does not find it because it is inside of a zip file. I got around this by checking to see if the file exists and if not seeing if there was a file with a .zip extension that exists in the path. If so, assume that it is correct. Second, when installing python files from within a zip file, the argv parameters from python are as follows: [0] – The full path to the python file, [1] – The full path to the zip file, [2:] – Any other parameters. To get around this, I check to see if [1] references a zip file that exists. If so, I delete [1]. Another option would be to also determine if [1] was a substring of [0]. There are a couple steps to run python files out of a zip file. - Create a zip file containing python files - Create a pth file containing a full path to the zip file. Put the file into %PYTHON_HOME%/Lib/site-packages. - If you are attempting to call the myPyFile.py file in the zip file residing at c:\myZipFile.zip, the command line would look something like: “%PYTHON_HOME%/python.exe –m myPyFile c:/myZipFile.zip install” ---------------------------------------------------------------------- Comment By: Joshua Palmer (uvapalmer) Date: 2013-05-14 05:16 Message: I have added files showing the changes I made in order to make this work for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613288&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-14 12:16:16
|
Bugs item #3613288, was opened at 2013-05-14 05:10 Message generated for change (Comment added) made by uvapalmer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613288&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: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joshua Palmer (uvapalmer) Assigned to: Nobody/Anonymous (nobody) Summary: Installation of python windows service fails when py files a Initial Comment: Python supports running py (or pyc) files directly out of zip files. There are two problems with this in pywin32: First, in GetServiceClassString the fname correctly represents the full path to the python file, but the win32api.FindFiles method does not find it because it is inside of a zip file. I got around this by checking to see if the file exists and if not seeing if there was a file with a .zip extension that exists in the path. If so, assume that it is correct. Second, when installing python files from within a zip file, the argv parameters from python are as follows: [0] – The full path to the python file, [1] – The full path to the zip file, [2:] – Any other parameters. To get around this, I check to see if [1] references a zip file that exists. If so, I delete [1]. Another option would be to also determine if [1] was a substring of [0]. There are a couple steps to run python files out of a zip file. - Create a zip file containing python files - Create a pth file containing a full path to the zip file. Put the file into %PYTHON_HOME%/Lib/site-packages. - If you are attempting to call the myPyFile.py file in the zip file residing at c:\myZipFile.zip, the command line would look something like: “%PYTHON_HOME%/python.exe –m myPyFile c:/myZipFile.zip install” ---------------------------------------------------------------------- >Comment By: Joshua Palmer (uvapalmer) Date: 2013-05-14 05:16 Message: I have added files showing the changes I made in order to make this work for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613288&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-14 12:10:01
|
Bugs item #3613288, was opened at 2013-05-14 05:10 Message generated for change (Tracker Item Submitted) made by uvapalmer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613288&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: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Joshua Palmer (uvapalmer) Assigned to: Nobody/Anonymous (nobody) Summary: Installation of python windows service fails when py files a Initial Comment: Python supports running py (or pyc) files directly out of zip files. There are two problems with this in pywin32: First, in GetServiceClassString the fname correctly represents the full path to the python file, but the win32api.FindFiles method does not find it because it is inside of a zip file. I got around this by checking to see if the file exists and if not seeing if there was a file with a .zip extension that exists in the path. If so, assume that it is correct. Second, when installing python files from within a zip file, the argv parameters from python are as follows: [0] – The full path to the python file, [1] – The full path to the zip file, [2:] – Any other parameters. To get around this, I check to see if [1] references a zip file that exists. If so, I delete [1]. Another option would be to also determine if [1] was a substring of [0]. There are a couple steps to run python files out of a zip file. - Create a zip file containing python files - Create a pth file containing a full path to the zip file. Put the file into %PYTHON_HOME%/Lib/site-packages. - If you are attempting to call the myPyFile.py file in the zip file residing at c:\myZipFile.zip, the command line would look something like: “%PYTHON_HOME%/python.exe –m myPyFile c:/myZipFile.zip install” ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3613288&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-11 00:17:26
|
Feature Requests item #3613075, was opened at 2013-05-10 15:47 Message generated for change (Comment added) made by khalak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3613075&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: win32 Group: Next Release (example) Status: Open Resolution: None Priority: 6 Private: No Submitted By: KHALAK Vasyl (khalak) Assigned to: Nobody/Anonymous (nobody) Summary: GCC-compiled pywin32 Initial Comment: Could we have a GCC-compiled pywin32? It would be awesome for Cygwin users. ---------------------------------------------------------------------- >Comment By: KHALAK Vasyl (khalak) Date: 2013-05-10 17:17 Message: ok, distutils supports 'cygwinccompiler', and just for the record: GCC is heavily used in Cygwin (no 'msvc9compiler' whatsoever), and offers an additional Unix-like compatibility layer, what in turn opens a wide gate for Unix-like programs to run them on Windows with no or little code modification. That is, Cygwin+GCC => Windows+Unix (and you still can compile Windows-only programs with MSVC, and maybe, just may-be, run them on Unix also) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-05-10 17:08 Message: I guess you'd first work out what support distutils has for building with GCC on Windows, then you'd look at setup.py to see how you would adapt that. Personally I've never used GCC on Windows and have no idea why anyone would want to, so have no interest in this whatsoever. ---------------------------------------------------------------------- Comment By: KHALAK Vasyl (khalak) Date: 2013-05-10 17:04 Message: any ideas what to look at? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-05-10 16:58 Message: Patches welcome! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3613075&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-11 00:08:38
|
Feature Requests item #3613075, was opened at 2013-05-10 15:47 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3613075&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: win32 Group: Next Release (example) Status: Open Resolution: None Priority: 6 Private: No Submitted By: KHALAK Vasyl (khalak) Assigned to: Nobody/Anonymous (nobody) Summary: GCC-compiled pywin32 Initial Comment: Could we have a GCC-compiled pywin32? It would be awesome for Cygwin users. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-05-10 17:08 Message: I guess you'd first work out what support distutils has for building with GCC on Windows, then you'd look at setup.py to see how you would adapt that. Personally I've never used GCC on Windows and have no idea why anyone would want to, so have no interest in this whatsoever. ---------------------------------------------------------------------- Comment By: KHALAK Vasyl (khalak) Date: 2013-05-10 17:04 Message: any ideas what to look at? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-05-10 16:58 Message: Patches welcome! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3613075&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-11 00:04:30
|
Feature Requests item #3613075, was opened at 2013-05-10 15:47 Message generated for change (Comment added) made by khalak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3613075&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: win32 Group: Next Release (example) Status: Open Resolution: None >Priority: 6 Private: No Submitted By: KHALAK Vasyl (khalak) Assigned to: Nobody/Anonymous (nobody) Summary: GCC-compiled pywin32 Initial Comment: Could we have a GCC-compiled pywin32? It would be awesome for Cygwin users. ---------------------------------------------------------------------- >Comment By: KHALAK Vasyl (khalak) Date: 2013-05-10 17:04 Message: any ideas what to look at? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-05-10 16:58 Message: Patches welcome! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3613075&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-10 23:58:40
|
Feature Requests item #3613075, was opened at 2013-05-10 15:47 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3613075&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: win32 Group: Next Release (example) Status: Open Resolution: None Priority: 5 Private: No Submitted By: KHALAK Vasyl (khalak) Assigned to: Nobody/Anonymous (nobody) Summary: GCC-compiled pywin32 Initial Comment: Could we have a GCC-compiled pywin32? It would be awesome for Cygwin users. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-05-10 16:58 Message: Patches welcome! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3613075&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-10 22:50:41
|
Feature Requests item #743527, was opened at 2003-05-26 01:11 Message generated for change (Comment added) made by khalak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=743527&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: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Dubner (dubnerm) Assigned to: Nobody/Anonymous (nobody) Summary: support for cygwin Initial Comment: Not sure that it will be easy, but there are w32api package... ---------------------------------------------------------------------- Comment By: KHALAK Vasyl (khalak) Date: 2013-05-10 15:50 Message: vote up ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-09-29 16:51 Message: Logged In: YES user_id=39274 Not sure. At last w32api cygwin package is compatible by signatures with MS library (as it uses same dlls!). Also I've just created oversimplified wrapper (with only functions used by anygui.backends.mswgui) with PyRex. Something like: --- win32api.pyx: cdef extern from "windows.h": ctypedef unsigned int UINT int w32_Beep "Beep" (UINT dwFreq, UINT dwDuration) def Beep(UINT freq, UINT dur): return w32_Beep(freq, dur) --- setup.py ... Extension("win32api", ["win32api.pyx"]), ... --- and what startled me it works under both VC and cygwin. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2003-09-17 16:15 Message: Logged In: YES user_id=552329 Could you not, then, port those extensions? Or use both the cygwin python and the windows one, running as separate processes and working together? Seems a lot simpler than porting all the win32all stuff over to cygwin... ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-09-17 16:12 Message: Logged In: YES user_id=39274 There are couple of extentions that exists only as cygwin versions ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2003-09-02 18:57 Message: Logged In: YES user_id=552329 I realise that, but my point was that you're on windows, so you can use a windows version of Python if you want to do windows things. If you want to do *nix'y sort of things, then use the cygwin version. You can still run the windows python in cygwin. ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-09-02 18:52 Message: Logged In: YES user_id=39274 Standard extentions can't work with cygwin version of python and visa-versa cygwin extentions can't work with windows version of python. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2003-05-26 01:15 Message: Logged In: YES user_id=552329 Why would you need support for cygwin? If you're running cygwin, then you have Windows, so you can use the standard extensions, can't you? (seems to work for me). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=743527&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-10 22:47:32
|
Feature Requests item #3613075, was opened at 2013-05-10 15:47 Message generated for change (Tracker Item Submitted) made by khalak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3613075&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: win32 Group: Next Release (example) Status: Open Resolution: None Priority: 5 Private: No Submitted By: KHALAK Vasyl (khalak) Assigned to: Nobody/Anonymous (nobody) Summary: GCC-compiled pywin32 Initial Comment: Could we have a GCC-compiled pywin32? It would be awesome for Cygwin users. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3613075&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-08 22:53:33
|
Bugs item #3612934, was opened at 2013-05-08 15:50 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612934&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: installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: mbmaser (mbmaser) Assigned to: Nobody/Anonymous (nobody) Summary: installation won't run Initial Comment: Trying to install win32 2.7.4 on Windows 7 64-bit (all patches up-to-date) and keep receiving a message that the system can't execute a necessary .dll required for installation. I'm not a programmer; I made sure all the security permissions were complete, and tried turning off anti-virus, etc. Nothing works. I'd installed Python at a previous time, and uninstalled that to install this update. This seems to be the only place with a hope of getting support. In browsing prior posts I did find one with the the subject, "[pywin32-bugs] [ pywin32-Bugs-3607350 ] pywin32 218 amd64 vista py3.3.0 installation Issue," that seems to be related. Any help or suggestions would be much appreciated. Thanks. (Python 2.7.4 is a prerequisite for an application I'd like to install). ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-05-08 15:53 Message: Exactly what error message did you get? Also, you mentioned you installed Python, but you must have the correct Python installed for the installation of pywin32 to succeed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612934&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-08 22:50:51
|
Bugs item #3612934, was opened at 2013-05-08 15:50 Message generated for change (Tracker Item Submitted) made by mbmaser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612934&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: installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: mbmaser (mbmaser) Assigned to: Nobody/Anonymous (nobody) Summary: installation won't run Initial Comment: Trying to install win32 2.7.4 on Windows 7 64-bit (all patches up-to-date) and keep receiving a message that the system can't execute a necessary .dll required for installation. I'm not a programmer; I made sure all the security permissions were complete, and tried turning off anti-virus, etc. Nothing works. I'd installed Python at a previous time, and uninstalled that to install this update. This seems to be the only place with a hope of getting support. In browsing prior posts I did find one with the the subject, "[pywin32-bugs] [ pywin32-Bugs-3607350 ] pywin32 218 amd64 vista py3.3.0 installation Issue," that seems to be related. Any help or suggestions would be much appreciated. Thanks. (Python 2.7.4 is a prerequisite for an application I'd like to install). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3612934&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-06 13:57:03
|
Patches item #3609017, was opened at 2013-03-25 07:39 Message generated for change (Comment added) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3609017&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: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Provide enums dynamically Initial Comment: In COM enums are transported as integers and hence hard to use for a programmer, which always has to map these numbers to comprehensive names. Since the enums are only available in typelibraries a wrapper had to be generated (makepy, gencache) to use them. There was no way that a enum could be used dynamically the same way a a COM object. The patch provides a way to use enums dynamically without generating a wrapper. So it is easy to use from a programmers viewpoint. The enum implementation used metaclasses so that the representation of the enum is always in a readable form and the enums are provided via members of enum classes. Used typelibraries are scanned inclusive their dependencies. >>> from win32com.client import Enums >>> from win32com.client import Dispatch >>> Word = Dispatch("Word.Application") >>> constants = Enums(Word) >>> constants.CertificateDetail.certdetIssuer <certdetIssuer 2> >>> print constants.CertificateDetail.certdetIssuer certdetIssuer >>> constants.CertificateDetail.certdetIssuer + 2 4 This enums class is used for over a year in our Python distribution and tested against Python 2.7.3 and Python 3.2.3 ---------------------------------------------------------------------- >Comment By: Stefan Schukat (sschukat) Date: 2013-05-06 06:57 Message: Fair enough, two places which serve similar functionality decrease the maintainability of an API. I'll have a look at the constants implementation, to see if these use cases could be coupled without breaking backward compatibility. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-05-06 05:30 Message: I agree that fixes for those issues with win32com.constants would be ideal. What I'm pushing back on is the introduction of a new object and implementation that serves the same basic role. IOW, I'd much rather see improvements to win32com.constants... ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-05-06 02:52 Message: The problem with the win32com.constants is that the generated module is bound to a specific version of the typelibrary. This module could not be easily accessed from an object created with client.Dispatch or gencache.EnsureDispatch. If you use gencache.EnsureModule to access the constants there is no easy way to get the information needed if you only have the ProgId which is enough for the creation of the objects. In addition to that the constants in win32com.client wrappers only give access to the enums in one typelibrary. If the enums are defined in a dependent typelibrary you would have to generate this typelibrary too (e.g. mso.. constants for office). This implementation automatically scans all dependent typelibraries and merges the constants. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-05-06 01:35 Message: Re the integers - it was a throw-away comment regarding: >>> constants.CertificateDetail.certdetIssuer + 2 4 where adding integers to an enum doesn't really make sense unless the enum is being treated as integer - which they are now. I'm not yet convinced the amount of code here is worthwhile when, best I can tell, you are suggesting the primary benefit is for a GUI environment where these values appear in a drop-down - I'd then argue that this burden belongs in that GUI. I can't really see how a developer *not* using such a GUI would benefit from these new objects, and it adds cognitive overhead for the average user (eg, "when do I use an enum vs win32com.client.constants?", "what are the benefits of one over the other?", etc) python-dev is also discussing adding enums as a builtin type (via PEP 435), so I'm inclined to reject this at least until that discussion settles down and we can see if pywin32 should use the new type rather than rolling our own (even if that type is only available in 3.? and later - .constants works fine for everyone else. ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-05-06 01:21 Message: Actually the code was developed with Python 2.5 and then tested with 2.7.4 and 3.2, so backward compatibility should be no issue. The extra code in the str function is due to the use cases that in a GUI or with an print the user should be able to see the enum names and not the values (e.g. in a combobox). With the str utility function the developer must not make it own mapping for the display. The repr function is overwritten because a simple integer value (which would be valid for the eval function) would not represent the originally used enum item. Hence I used the angle bracket notation to show the enum named and integer value. In addition a REPL situation it is easier to determine the value of an enum >>> from win32com.client import Dispatch, Enums >>> App = Dispatch("Word.Application") >>> constants = Enums(App) >>> Doc = App.Documents.Add() >>> print constants.WdShowFilter(Doc.FormattingShowFilter) wdShowFilterFormattingRecommended >>> print constants.WdLineEndingType(Doc.TextLineEnding) wdCRLF >>> constants.WdLineEndingType(Doc.TextLineEnding) <wdCRLF 0> The arbitrary integer comment I don't understand, the valid enum values are encoded in the _names attribute. All other values lead to an unknown element, which is not added to the internal list. During the writing I found a bug in the str methods of the enum and bitmask classes. Fix is added to the patch queue and added the diff as file. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-05-05 18:25 Message: You might need to sell this one some more. I see that having constants from dynamic objects is a win, but all the other behaviour seems of questionable utility, especially given the size of the additional code (eg, why is that repr or print a win given it would be quite obvious to the developer without them, why can arbitrary integers be added to enums, etc) I'd be very happy with a patch that extended the existing simple-to-understand "constants" to work with dynamic objects though. Also note that pywin32 works with Python 2.5 and later, so code that works only in 2.7+ wouldn't be acceptable (although I haven't checked to see what the min version this code actually does work with) ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-05-03 06:20 Message: Added the patch with pep8 checked source and unit tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3609017&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-06 12:30:44
|
Patches item #3609017, was opened at 2013-03-25 07:39 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3609017&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: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Provide enums dynamically Initial Comment: In COM enums are transported as integers and hence hard to use for a programmer, which always has to map these numbers to comprehensive names. Since the enums are only available in typelibraries a wrapper had to be generated (makepy, gencache) to use them. There was no way that a enum could be used dynamically the same way a a COM object. The patch provides a way to use enums dynamically without generating a wrapper. So it is easy to use from a programmers viewpoint. The enum implementation used metaclasses so that the representation of the enum is always in a readable form and the enums are provided via members of enum classes. Used typelibraries are scanned inclusive their dependencies. >>> from win32com.client import Enums >>> from win32com.client import Dispatch >>> Word = Dispatch("Word.Application") >>> constants = Enums(Word) >>> constants.CertificateDetail.certdetIssuer <certdetIssuer 2> >>> print constants.CertificateDetail.certdetIssuer certdetIssuer >>> constants.CertificateDetail.certdetIssuer + 2 4 This enums class is used for over a year in our Python distribution and tested against Python 2.7.3 and Python 3.2.3 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-05-06 05:30 Message: I agree that fixes for those issues with win32com.constants would be ideal. What I'm pushing back on is the introduction of a new object and implementation that serves the same basic role. IOW, I'd much rather see improvements to win32com.constants... ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-05-06 02:52 Message: The problem with the win32com.constants is that the generated module is bound to a specific version of the typelibrary. This module could not be easily accessed from an object created with client.Dispatch or gencache.EnsureDispatch. If you use gencache.EnsureModule to access the constants there is no easy way to get the information needed if you only have the ProgId which is enough for the creation of the objects. In addition to that the constants in win32com.client wrappers only give access to the enums in one typelibrary. If the enums are defined in a dependent typelibrary you would have to generate this typelibrary too (e.g. mso.. constants for office). This implementation automatically scans all dependent typelibraries and merges the constants. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-05-06 01:35 Message: Re the integers - it was a throw-away comment regarding: >>> constants.CertificateDetail.certdetIssuer + 2 4 where adding integers to an enum doesn't really make sense unless the enum is being treated as integer - which they are now. I'm not yet convinced the amount of code here is worthwhile when, best I can tell, you are suggesting the primary benefit is for a GUI environment where these values appear in a drop-down - I'd then argue that this burden belongs in that GUI. I can't really see how a developer *not* using such a GUI would benefit from these new objects, and it adds cognitive overhead for the average user (eg, "when do I use an enum vs win32com.client.constants?", "what are the benefits of one over the other?", etc) python-dev is also discussing adding enums as a builtin type (via PEP 435), so I'm inclined to reject this at least until that discussion settles down and we can see if pywin32 should use the new type rather than rolling our own (even if that type is only available in 3.? and later - .constants works fine for everyone else. ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-05-06 01:21 Message: Actually the code was developed with Python 2.5 and then tested with 2.7.4 and 3.2, so backward compatibility should be no issue. The extra code in the str function is due to the use cases that in a GUI or with an print the user should be able to see the enum names and not the values (e.g. in a combobox). With the str utility function the developer must not make it own mapping for the display. The repr function is overwritten because a simple integer value (which would be valid for the eval function) would not represent the originally used enum item. Hence I used the angle bracket notation to show the enum named and integer value. In addition a REPL situation it is easier to determine the value of an enum >>> from win32com.client import Dispatch, Enums >>> App = Dispatch("Word.Application") >>> constants = Enums(App) >>> Doc = App.Documents.Add() >>> print constants.WdShowFilter(Doc.FormattingShowFilter) wdShowFilterFormattingRecommended >>> print constants.WdLineEndingType(Doc.TextLineEnding) wdCRLF >>> constants.WdLineEndingType(Doc.TextLineEnding) <wdCRLF 0> The arbitrary integer comment I don't understand, the valid enum values are encoded in the _names attribute. All other values lead to an unknown element, which is not added to the internal list. During the writing I found a bug in the str methods of the enum and bitmask classes. Fix is added to the patch queue and added the diff as file. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-05-05 18:25 Message: You might need to sell this one some more. I see that having constants from dynamic objects is a win, but all the other behaviour seems of questionable utility, especially given the size of the additional code (eg, why is that repr or print a win given it would be quite obvious to the developer without them, why can arbitrary integers be added to enums, etc) I'd be very happy with a patch that extended the existing simple-to-understand "constants" to work with dynamic objects though. Also note that pywin32 works with Python 2.5 and later, so code that works only in 2.7+ wouldn't be acceptable (although I haven't checked to see what the min version this code actually does work with) ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-05-03 06:20 Message: Added the patch with pep8 checked source and unit tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3609017&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-06 09:52:06
|
Patches item #3609017, was opened at 2013-03-25 07:39 Message generated for change (Comment added) made by sschukat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3609017&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: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Provide enums dynamically Initial Comment: In COM enums are transported as integers and hence hard to use for a programmer, which always has to map these numbers to comprehensive names. Since the enums are only available in typelibraries a wrapper had to be generated (makepy, gencache) to use them. There was no way that a enum could be used dynamically the same way a a COM object. The patch provides a way to use enums dynamically without generating a wrapper. So it is easy to use from a programmers viewpoint. The enum implementation used metaclasses so that the representation of the enum is always in a readable form and the enums are provided via members of enum classes. Used typelibraries are scanned inclusive their dependencies. >>> from win32com.client import Enums >>> from win32com.client import Dispatch >>> Word = Dispatch("Word.Application") >>> constants = Enums(Word) >>> constants.CertificateDetail.certdetIssuer <certdetIssuer 2> >>> print constants.CertificateDetail.certdetIssuer certdetIssuer >>> constants.CertificateDetail.certdetIssuer + 2 4 This enums class is used for over a year in our Python distribution and tested against Python 2.7.3 and Python 3.2.3 ---------------------------------------------------------------------- >Comment By: Stefan Schukat (sschukat) Date: 2013-05-06 02:52 Message: The problem with the win32com.constants is that the generated module is bound to a specific version of the typelibrary. This module could not be easily accessed from an object created with client.Dispatch or gencache.EnsureDispatch. If you use gencache.EnsureModule to access the constants there is no easy way to get the information needed if you only have the ProgId which is enough for the creation of the objects. In addition to that the constants in win32com.client wrappers only give access to the enums in one typelibrary. If the enums are defined in a dependent typelibrary you would have to generate this typelibrary too (e.g. mso.. constants for office). This implementation automatically scans all dependent typelibraries and merges the constants. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-05-06 01:35 Message: Re the integers - it was a throw-away comment regarding: >>> constants.CertificateDetail.certdetIssuer + 2 4 where adding integers to an enum doesn't really make sense unless the enum is being treated as integer - which they are now. I'm not yet convinced the amount of code here is worthwhile when, best I can tell, you are suggesting the primary benefit is for a GUI environment where these values appear in a drop-down - I'd then argue that this burden belongs in that GUI. I can't really see how a developer *not* using such a GUI would benefit from these new objects, and it adds cognitive overhead for the average user (eg, "when do I use an enum vs win32com.client.constants?", "what are the benefits of one over the other?", etc) python-dev is also discussing adding enums as a builtin type (via PEP 435), so I'm inclined to reject this at least until that discussion settles down and we can see if pywin32 should use the new type rather than rolling our own (even if that type is only available in 3.? and later - .constants works fine for everyone else. ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-05-06 01:21 Message: Actually the code was developed with Python 2.5 and then tested with 2.7.4 and 3.2, so backward compatibility should be no issue. The extra code in the str function is due to the use cases that in a GUI or with an print the user should be able to see the enum names and not the values (e.g. in a combobox). With the str utility function the developer must not make it own mapping for the display. The repr function is overwritten because a simple integer value (which would be valid for the eval function) would not represent the originally used enum item. Hence I used the angle bracket notation to show the enum named and integer value. In addition a REPL situation it is easier to determine the value of an enum >>> from win32com.client import Dispatch, Enums >>> App = Dispatch("Word.Application") >>> constants = Enums(App) >>> Doc = App.Documents.Add() >>> print constants.WdShowFilter(Doc.FormattingShowFilter) wdShowFilterFormattingRecommended >>> print constants.WdLineEndingType(Doc.TextLineEnding) wdCRLF >>> constants.WdLineEndingType(Doc.TextLineEnding) <wdCRLF 0> The arbitrary integer comment I don't understand, the valid enum values are encoded in the _names attribute. All other values lead to an unknown element, which is not added to the internal list. During the writing I found a bug in the str methods of the enum and bitmask classes. Fix is added to the patch queue and added the diff as file. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-05-05 18:25 Message: You might need to sell this one some more. I see that having constants from dynamic objects is a win, but all the other behaviour seems of questionable utility, especially given the size of the additional code (eg, why is that repr or print a win given it would be quite obvious to the developer without them, why can arbitrary integers be added to enums, etc) I'd be very happy with a patch that extended the existing simple-to-understand "constants" to work with dynamic objects though. Also note that pywin32 works with Python 2.5 and later, so code that works only in 2.7+ wouldn't be acceptable (although I haven't checked to see what the min version this code actually does work with) ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-05-03 06:20 Message: Added the patch with pep8 checked source and unit tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3609017&group_id=78018 |
From: SourceForge.net <no...@so...> - 2013-05-06 08:35:50
|
Patches item #3609017, was opened at 2013-03-25 07:39 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3609017&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: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Provide enums dynamically Initial Comment: In COM enums are transported as integers and hence hard to use for a programmer, which always has to map these numbers to comprehensive names. Since the enums are only available in typelibraries a wrapper had to be generated (makepy, gencache) to use them. There was no way that a enum could be used dynamically the same way a a COM object. The patch provides a way to use enums dynamically without generating a wrapper. So it is easy to use from a programmers viewpoint. The enum implementation used metaclasses so that the representation of the enum is always in a readable form and the enums are provided via members of enum classes. Used typelibraries are scanned inclusive their dependencies. >>> from win32com.client import Enums >>> from win32com.client import Dispatch >>> Word = Dispatch("Word.Application") >>> constants = Enums(Word) >>> constants.CertificateDetail.certdetIssuer <certdetIssuer 2> >>> print constants.CertificateDetail.certdetIssuer certdetIssuer >>> constants.CertificateDetail.certdetIssuer + 2 4 This enums class is used for over a year in our Python distribution and tested against Python 2.7.3 and Python 3.2.3 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-05-06 01:35 Message: Re the integers - it was a throw-away comment regarding: >>> constants.CertificateDetail.certdetIssuer + 2 4 where adding integers to an enum doesn't really make sense unless the enum is being treated as integer - which they are now. I'm not yet convinced the amount of code here is worthwhile when, best I can tell, you are suggesting the primary benefit is for a GUI environment where these values appear in a drop-down - I'd then argue that this burden belongs in that GUI. I can't really see how a developer *not* using such a GUI would benefit from these new objects, and it adds cognitive overhead for the average user (eg, "when do I use an enum vs win32com.client.constants?", "what are the benefits of one over the other?", etc) python-dev is also discussing adding enums as a builtin type (via PEP 435), so I'm inclined to reject this at least until that discussion settles down and we can see if pywin32 should use the new type rather than rolling our own (even if that type is only available in 3.? and later - .constants works fine for everyone else. ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-05-06 01:21 Message: Actually the code was developed with Python 2.5 and then tested with 2.7.4 and 3.2, so backward compatibility should be no issue. The extra code in the str function is due to the use cases that in a GUI or with an print the user should be able to see the enum names and not the values (e.g. in a combobox). With the str utility function the developer must not make it own mapping for the display. The repr function is overwritten because a simple integer value (which would be valid for the eval function) would not represent the originally used enum item. Hence I used the angle bracket notation to show the enum named and integer value. In addition a REPL situation it is easier to determine the value of an enum >>> from win32com.client import Dispatch, Enums >>> App = Dispatch("Word.Application") >>> constants = Enums(App) >>> Doc = App.Documents.Add() >>> print constants.WdShowFilter(Doc.FormattingShowFilter) wdShowFilterFormattingRecommended >>> print constants.WdLineEndingType(Doc.TextLineEnding) wdCRLF >>> constants.WdLineEndingType(Doc.TextLineEnding) <wdCRLF 0> The arbitrary integer comment I don't understand, the valid enum values are encoded in the _names attribute. All other values lead to an unknown element, which is not added to the internal list. During the writing I found a bug in the str methods of the enum and bitmask classes. Fix is added to the patch queue and added the diff as file. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-05-05 18:25 Message: You might need to sell this one some more. I see that having constants from dynamic objects is a win, but all the other behaviour seems of questionable utility, especially given the size of the additional code (eg, why is that repr or print a win given it would be quite obvious to the developer without them, why can arbitrary integers be added to enums, etc) I'd be very happy with a patch that extended the existing simple-to-understand "constants" to work with dynamic objects though. Also note that pywin32 works with Python 2.5 and later, so code that works only in 2.7+ wouldn't be acceptable (although I haven't checked to see what the min version this code actually does work with) ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2013-05-03 06:20 Message: Added the patch with pep8 checked source and unit tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3609017&group_id=78018 |