[Zope-dev] Experiencing TypeError: The object is not a PySECURITY_ATTRIBUTES object

Chris Mattmann chris.mattmann at jpl.nasa.gov
Wed Oct 26 22:54:59 EDT 2005


Hi Mark,

 Success! That fixed the problem. Thanks for the excellent help. I'd say
this patch is a good for the next iteration of builds ;)

Take care,
 Chris


______________________________________________
Chris A. Mattmann
Chris.Mattmann at 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.


> -----Original Message-----
> From: Mark Hammond [mailto:mhammond at skippinet.com.au]
> Sent: Wednesday, October 26, 2005 4:00 PM
> To: Chris Mattmann
> Subject: RE: [Zope-dev] Experiencing TypeError: The object is not a
> PySECURITY_ATTRIBUTES object
> 
> Hi Chris,
>   You could try the solution with the attached files:
> 
> pywintypes.py replaces an existing file in what I believe is the
> "{zope}\bin\lib\site-packages\win32\lib directory.  Please take a copy of
> the original in case I totally screw you :)
> 
> _win32sysloader.pyd is a new file, and goes into the existing directory
> "{zope}\bin\lib\site-packages\win32", where you should find many other
> .pyd
> files.
> 
> Simply restart Zope after this, and the problems should vanish.
> 
> Mark.
> 
> > -----Original Message-----
> > From: Chris Mattmann [mailto:chris.mattmann at jpl.nasa.gov]
> > Sent: Thursday, 27 October 2005 8:18 AM
> > To: Tim Peters; Mark Hammond
> > Cc: zope-dev at zope.org
> > Subject: Re: [Zope-dev] Experiencing TypeError: The object is not a
> > PySECURITY_ATTRIBUTES object
> >
> >
> > 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 at 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 at 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.
> >
> >
> >
> >
> >



More information about the Zope-Dev mailing list