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.
On 10/26/05 3:00 PM, "Tim Peters" <[EMAIL PROTECTED]> wrote:
> [Mark Hammond]
>> FYI, there is a new pywin32 build out now that should solve this problem
>> without requiring any imports to be reordered.
>> 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
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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -