Re: [Zope-dev] Experiencing TypeError: The object is not a PySECURITY_ATTRIBUTES object
[Mark Hammond]
FYI, there is a new pywin32 build out now that should solve this problem without requiring any imports to be reordered.
Yay!
It would be great if whoever turns the crank for the next Zope/Windows builds (which may even turn out to be me! :) uses build 205.
Andreas Jung made a "surprise" release of Zope 2.8.4 today, but only the tarball, not a Windows installer. If you want to make the latter, more than fine by me, else I'll try to make one tomorrow (with your build 205, of course -- will require some retroactive patching of the 2.8.4 tag no matter who does it).
Sadly, I believe it is not trivial to install a new pywin32 build into a Zope binary. You could patch it up though by opening the pywin32 release executable in WinZip (or similar), then replacing 'pywintypes.py' and extracting a new "_win32sysloader.pyd" module.
Ya, like Windows users are gonna do _that_ <wink>.
Finally, I believe another way to solve this problem would be to remove pywintypes23.dll from the system32 directory (the the underlying problem is that 2 copies of this DLL are being loaded into memory). However, doing this may prevent other things (such as your existing Python installation) from working correctly, so do this with caution. Zope does not install anything into system32, so presumably something else on your system is also using Python.
All "recent" PySECURITY_ATTRIBUTES complaints I know about have come from people using both Zope and Plone. I don't know anything about Plone installation, but it's natural to suspect that Plone is the source of the other pywin32 installation, and possibly of compounding sys.path convolutions too. So, a natural question based on this ignorance: is it enough for just Zope to install build 205, if Plone also installs its own (older) pywin32 and mangles sys.path so that its pywin32 is also visible? I suspect (but don't know) that's what's happening. It would be a lot better if a Plone user tested the proposed solution before we release another Windows Zope that may still turn out not to solve Plone's problems here.
Hi Guys, Thanks for your responses. I'll investigate the version of Plone that I had downloaded (2.1.1) to see whether or not there are any calls to the pywintypes32 library within the Plone products that could be causing this problem. I had suspected it may be a Plone issue because I didn't see the problem when I just installed Zope, and started it up. Only after adding the Plone products did I start to see the problem. However, I wasn't sure what might be causing it because I'm not really a Python guy. To be honest, I've never used it before. So I'll check into this and get back to you. I'd be happy to test the proposed solution BTW, if you send me a tarball, and report the results to the list. Thanks! Cheers, Chris On 10/26/05 3:00 PM, "Tim Peters" <tim.peters@gmail.com> wrote:
[Mark Hammond]
FYI, there is a new pywin32 build out now that should solve this problem without requiring any imports to be reordered.
Yay!
It would be great if whoever turns the crank for the next Zope/Windows builds (which may even turn out to be me! :) uses build 205.
Andreas Jung made a "surprise" release of Zope 2.8.4 today, but only the tarball, not a Windows installer. If you want to make the latter, more than fine by me, else I'll try to make one tomorrow (with your build 205, of course -- will require some retroactive patching of the 2.8.4 tag no matter who does it).
Sadly, I believe it is not trivial to install a new pywin32 build into a Zope binary. You could patch it up though by opening the pywin32 release executable in WinZip (or similar), then replacing 'pywintypes.py' and extracting a new "_win32sysloader.pyd" module.
Ya, like Windows users are gonna do _that_ <wink>.
Finally, I believe another way to solve this problem would be to remove pywintypes23.dll from the system32 directory (the the underlying problem is that 2 copies of this DLL are being loaded into memory). However, doing this may prevent other things (such as your existing Python installation) from working correctly, so do this with caution. Zope does not install anything into system32, so presumably something else on your system is also using Python.
All "recent" PySECURITY_ATTRIBUTES complaints I know about have come from people using both Zope and Plone. I don't know anything about Plone installation, but it's natural to suspect that Plone is the source of the other pywin32 installation, and possibly of compounding sys.path convolutions too.
So, a natural question based on this ignorance: is it enough for just Zope to install build 205, if Plone also installs its own (older) pywin32 and mangles sys.path so that its pywin32 is also visible? I suspect (but don't know) that's what's happening. It would be a lot better if a Plone user tested the proposed solution before we release another Windows Zope that may still turn out not to solve Plone's problems here.
______________________________________________ Chris A. Mattmann Chris.Mattmann@jpl.nasa.gov Staff Member Modeling and Data Management Systems Section (387) Data Management Systems and Technologies Group _________________________________________________ Jet Propulsion Laboratory Pasadena, CA Office: 171-266B Mailstop: 171-246 _______________________________________________________ Disclaimer: The opinions presented within are my own and do not reflect those of either NASA, JPL, or the California Institute of Technology.
All "recent" PySECURITY_ATTRIBUTES complaints I know about have come from people using both Zope and Plone. I don't know anything about Plone installation, but it's natural to suspect that Plone is the source of the other pywin32 installation, and possibly of compounding sys.path convolutions too.
So, a natural question based on this ignorance: is it enough for just Zope to install build 205, if Plone also installs its own (older) pywin32 and mangles sys.path so that its pywin32 is also visible? I suspect (but don't know) that's what's happening.
When first reading this, I assumed we were talking about a Plone binary build - which the following all applies to: I believe the problem is that the Plone installer (like the Enfold Server) copies pywintypes23.dll etc to system32 as part of the install. This is evil and is being addressed. The issue isn't sys.path mangling as such, as pywintypes23.dll is never imported directly by Python (ie, no one ever imports a module of that name). The problem is that when pywintypes23.dll is in system32 *and* in the same directory as the executable, the following things can happen: 'import pywintypes' - pywintypes.py explicitly looked for and loaded pywintypes23.dll 'import win32api' - Windows looks for and loads pywintypes23.dll due to win32api.pyd using symbols from the DLL. The problem was that Windows was a little smarter than me :) If 'import pywintypes' has been done first, Windows would notice the module was already loaded, so 'import win32api' would happily use that. But when 'import win32api' happens first, Windows has already loaded pywintypes23.dll. If the 'import pywintypes' followed, we did *not* reuse the already loaded module - we (possibly) chose and loaded a new one. The fix in pywin32 was to use a special .pyd file that was capable of determining if pywintypes23.dll was already loaded, and if so, reuse that (ironically, win32api itself could do that if only it didn't depend on pywintypes23.dll itself! This new .pyd obviously does not depend on that DLL) Moving forward: I have fixed the "Plone Community" installer released by Enfold to copy nothing into system32, and confirmed that it does work even when the DLL exists in system32, and this should be released soon. I hope to give our commercial offering "Enfold Server" the same treatment very soon. The older plone installers will probably not be fixed. BUT - reading Chris's mail, it seems he installed a Zope binary package, and manually added the Plone products to it. In this case, I doubt Plone is mangling much, nor would it be copying pywintypes23.dll around. Thus, unless there was a pre-existing pywintypes23.dll in system32, I don't see how this problem could happen. I've asked Chris to let me know if there was that pre-existing DLL.
It would be a lot better if a Plone user tested the proposed solution before we release another Windows Zope that may still turn out not to solve Plone's problems here.
I've mailed Chris the 2 relevant updated files to see if his problem goes away. I guess that is a good start :) Cheers, Mark
Hi Mark,
BUT - reading Chris's mail, it seems he installed a Zope binary package, and manually added the Plone products to it. In this case, I doubt Plone is mangling much, nor would it be copying pywintypes23.dll around. Thus, unless there was a pre-existing pywintypes23.dll in system32, I don't see how this problem could happen. I've asked Chris to let me know if there was that pre-existing DLL.
I guess I should qualify the "full process" that I went through to arrive at the error I posted to the list. Before trying anything else, I first tried to install the Plone 2.1.1 Windows installer, which worked fine, mind you. Then, I ran into an error where my colleague and I were trying to do some code along the lines of: final = super(ATImage, self).SearchableText() + ' ' + ' '.join(names) which I guess the python version that Zope 2.7.8 uses doesn't support. Turns out that the windows installer on the plone.org site for plone version 2.1.1 includes Zope 2.7.8, which as I said, doesn't seem to support the above statement. So, in lieu of changing that code, my friend suggested upgrading to Zope 2.8.2, which supports the above code (I'm guessing b/c the Python version libraries included with that Zope can do the super() call). So, I uninstalled the Plone windows installer and set about on my path of running into the PySECURITY_ATTRIBUTES error with: Plone 2.1.1, just the products Zope 2.8.2, the tar.gz from the zope.org site And Python 2.3.5, from the python.org site So, it's entirely possible that even when I uninstalled the Plone 2.1.1 windows installer, that it didn't "uninstall" that pywintypes23.dll file that you mention the windows installer installs by default. So, that may be why I was seeing the error. I will report back soon on if I find that dll file in my system32 directory. I'll also report the results of your patch files applied to my environment, and whether they worked or not. Thanks a lot, again! Cheers, Chris
It would be a lot better if a Plone user tested the proposed solution before we release another Windows Zope that may still turn out not to solve Plone's problems here.
I've mailed Chris the 2 relevant updated files to see if his problem goes away. I guess that is a good start :)
Cheers,
Mark
The bad news is that I don't think I'll ever put in enough time to fully understand what went wrong here. The good news is that the newly-released Zope 2.8.4 Windows installer, at http://www.zope.org/Products/Zope/2.8.4 includes pywin32 build 205. If that doesn't fix PySECURITY_ATTRIBUTES problems for Plone users, you know which Mark Hammond to contact ;-) Thanks to all for the help!
participants (3)
-
Chris Mattmann -
Mark Hammond -
Tim Peters