Re: [Zope-dev] Re: Converting from old-style BTreess
Chris McDonough wrote: On Sun, 2003-12-14 at 23:02, Chris McDonough wrote: Here's an idea: create a simple script that manufactured a module which set up the Zope configuration, filled in for BTree in sys.modules, and got a hold of Zope.app(), causing ZGlobals to be replaced by a new-style BTree due to the above magic. People upgrading to 2.8 with databases created by Zope versions older than 2.3 would still need to run convertBTrees inside a different Zope version, but people upgrading databases created in versions equalling or later than 2.3 wouldn't because we stopped using the old BTree module for anything except ZGlobals after 2.3 AFAICT. Actually, given my findings later in this email, this isn't even necessary. Right. Whew. I checked in the necessary fix for PersistentMapping. There was a change in the data structure and I had to add some logic to convert some old state. I also had to check in a %$#@ travesty because Data.fs.in still has references to BoboPOS. With these changes, I can create a database with 2.6 and open it with the head. Thanks Chris for helping us figure out that this was easier than we thought. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Converting from old-style BTreess
Chris McDonough wrote: ... Out of curiosity, could you explain why it matters in this context whether it's an extensionclass or not? Is it because there might be a set of people using PersistentMapping objects for whom its important that they be able to use extenionclass semantics against them? I'd just never thought of using __of__ or inheritedAttribute or any of the other EC-specific stuff on a PersistentMapping. shrug Who knows. I'd rather be safe. It's not that hard. In any case, we would have needed the fix to handle old pickles correctly. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Converting from old-style BTreess
On Mon, 2003-12-15 at 02:47, Jim Fulton wrote: Chris McDonough wrote: ... Out of curiosity, could you explain why it matters in this context whether it's an extensionclass or not? Is it because there might be a set of people using PersistentMapping objects for whom its important that they be able to use extenionclass semantics against them? I'd just never thought of using __of__ or inheritedAttribute or any of the other EC-specific stuff on a PersistentMapping. shrug Who knows. I'd rather be safe. It's not that hard. In any case, we would have needed the fix to handle old pickles correctly. Gotcha. Can you answer a question about the features we're allowed now? If we don't use extensionclass, is it possible to persist instances of new-style classes in ZODB now (ie. is persistent.Persistent really a new-style type/class)? - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Converting from old-style BTreess
On Mon, 2003-12-15 at 02:39, Jim Fulton wrote: I checked in the necessary fix for PersistentMapping. There was a change in the data structure and I had to add some logic to convert some old state. Oh, geez, I remember this setstate/getstate business now. FWIW, I think Jeremy added it at my insistence after he changed PersistentMapping to inherit from UserDict in order to maintain backwards compatibility for versions that didn't. The next panic will start when UserDict becomes a new-style class. ;-) - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Head (2.8) breaks refresh
On Mon, 2003-12-15 at 07:34, Dieter Maurer wrote: I don't think it makes a lot of sense to put an __del__ method on a Persistent object. I just read in cPersistence.c:ghostify: /* We remove the reference to the just ghosted object that the ring * holds. Note that the dictionary of oids-objects has an uncounted * reference, so if the ring's reference was the only one, this frees * the ghost object. Note further that the object's dealloc knows to * inform the dictionary that it is going away. */ This means: *all* persistent objects have a special dealloc function. Hope, this dealloc function plays well with the cyclic garbage collector. All Python objects have a dealloc function -- whatever is in the tp_dealloc slot. The tp_dealloc function at the C level is completely different from an __del__ method at the Python level. Jeremy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Converting from old-style BTreess
On Mon, Dec 15, 2003 at 05:21:55AM -0500, Jim Fulton wrote: Chris McDonough wrote: Woot! ;-) Descriptors, yum... But you can use descriptors in extension classes now too. I wondered what the heck you guys were on about... google turned up this: http://users.rcn.com/python/download/Descriptor.htm very very cool stuff. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's ZORRO SLUDGE! (random hero from isometric.spaceninja.com) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: On with the show....
Sidnei da Silva wrote:
If you look at FSPageTemplate, its obvious that it doesn't subclass
ZopePageTemplate, but the solution is not so obvious. Using:
pt_getContext = ZopePageTemplate.pt_getContext.im_func
Wow, FSPageTemplate is lousy with this sort of thing, isn't it? I'd
have spelled it ZopePageTemplate.__dict__['pt_getContext'], but your
code works out to the same thing. I don't endorse this sort of
cross-tree method copying, but if we're going to do it on this scale, at
least we can make it tidier. Before the Globals.InitializeClass:
zpd = ZopePageTemplate.__dict__
for m in ('func_code', '_default_bindings', 'manage_FTPget',
'get_size', 'PrincipiaSearchSource', 'document_src',
'pt_getContext', 'ZScriptHTML_tryParams'):
setattr(FSPageTemplate, m, zpd[m])
A similar error also happened with FSImage.__str__ (which is assigned
Image.__str__, but FSImage just subclasses FSObject).
Any thought on those?
Yep -- it seems very silly to copy a one-line method like that.
Cheers,
Evan @ 4-am
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] On with the show....
On Mon, Dec 15, 2003 at 07:56:04AM -0500, Chris McDonough wrote: | On Mon, 2003-12-15 at 08:04, Sidnei da Silva wrote: | pt_getContext = ZopePageTemplate.pt_getContext.im_func | | Seemed to work, though I'm almost sure that is not the Right Thing (tm). | | This exact fix was already checked in to the CMF HEAD by Yuppie a couple | of days ago (and a series of other ones, as well as one for | Image.__str__) based on an audit by Dieter. Maybe you're using the 1.4 | branch? Yep. Sorry for not having checked CMF Head. BTW, Yuppie, can we get a 1.5 soon? -- Sidnei da Silva [EMAIL PROTECTED] http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher Memory fault - where am I? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: On with the show....
Sidnei da Silva wrote: Yep. Sorry for not having checked CMF Head. BTW, Yuppie, can we get a 1.5 soon? Maybe [EMAIL PROTECTED] is a better place for questions like that? Today Tres Seaver wrote: BTW, I plan to post a draft roadmap for CMF 1.5 soon (today, I hope), and to ask for feedback. Yuppie ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: On with the show....
On Mon, 15 Dec 2003 10:02:58 -0600
Evan Simpson [EMAIL PROTECTED] wrote:
Sidnei da Silva wrote:
If you look at FSPageTemplate, its obvious that it doesn't subclass
ZopePageTemplate, but the solution is not so obvious. Using:
pt_getContext = ZopePageTemplate.pt_getContext.im_func
Wow, FSPageTemplate is lousy with this sort of thing, isn't it? I'd
have spelled it ZopePageTemplate.__dict__['pt_getContext'], but your
code works out to the same thing. I don't endorse this sort of
cross-tree method copying, but if we're going to do it on this scale, at
least we can make it tidier. Before the Globals.InitializeClass:
zpd = ZopePageTemplate.__dict__
for m in ('func_code', '_default_bindings', 'manage_FTPget',
'get_size', 'PrincipiaSearchSource', 'document_src',
'pt_getContext', 'ZScriptHTML_tryParams'):
setattr(FSPageTemplate, m, zpd[m])
A similar error also happened with FSImage.__str__ (which is assigned
Image.__str__, but FSImage just subclasses FSObject).
Any thought on those?
Yep -- it seems very silly to copy a one-line method like that.
Smells like a broken class hierarchy to me. I really think we need to consider
refactoring the code so this sort of sillyness isn't necessary.
-Casey
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: On with the show....
On Mon, 2003-12-15 at 11:51, Casey Duncan wrote:
On Mon, 15 Dec 2003 10:02:58 -0600
Evan Simpson [EMAIL PROTECTED] wrote:
Sidnei da Silva wrote:
If you look at FSPageTemplate, its obvious that it doesn't subclass
ZopePageTemplate, but the solution is not so obvious. Using:
pt_getContext = ZopePageTemplate.pt_getContext.im_func
Wow, FSPageTemplate is lousy with this sort of thing, isn't it? I'd
have spelled it ZopePageTemplate.__dict__['pt_getContext'], but your
code works out to the same thing. I don't endorse this sort of
cross-tree method copying, but if we're going to do it on this scale, at
least we can make it tidier. Before the Globals.InitializeClass:
zpd = ZopePageTemplate.__dict__
for m in ('func_code', '_default_bindings', 'manage_FTPget',
'get_size', 'PrincipiaSearchSource', 'document_src',
'pt_getContext', 'ZScriptHTML_tryParams'):
setattr(FSPageTemplate, m, zpd[m])
A similar error also happened with FSImage.__str__ (which is assigned
Image.__str__, but FSImage just subclasses FSObject).
Any thought on those?
Yep -- it seems very silly to copy a one-line method like that.
Smells like a broken class hierarchy to me. I really think we need to
consider refactoring the code so this sort of sillyness isn't necessary.
While we are at it, we need to refactor the core bits of ZPT
(expressions, PageTemplateFile, etc.) out of 'Products.PageTemplates'
and into a better top-level pacakge. People are beginning to use PTF
for ZMI, which shouldn't break in the absence of a product.
Tres.
--
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation Zope Dealers http://www.zope.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python 2.3.2 and dir
Alan Milligan wrote at 2003-12-15 13:45 +1100: I'm trying to upgrade my Zpydoc product to Python 2.3.2 from 2.1.3 and have come across a confusing situation in regard to the inspect.getmembers function. This function uses the builtin dir() function to get a list of an objects attributes. For Zope products, I am getting a situation where returned attributes are not found in the object - explicitly __call__, __delattr__, etc etc. You know, I have a similar product (DocFinder). I directly look into the class' __dict__ to learn about a class' members. -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] It's me again :(
So... this time I got a really weird one. I'm storing a subclass of File (Archetypes newBaseUnit, File is the only base class) into a PersistentMapping, and I'm getting: 'Can't pickle objects in acquisition wrappers' However, as far as I can see, the object is *not* acquisition wrapper. If I put a try: except in ZODB.serialize and try obj.aq_base, I get an attribute error, and aq_base(obj) is obj returns True. It *smells* like Implicit.__getstate__ is being called, though I can't really tell :( Any ideas? -- Sidnei da Silva [EMAIL PROTECTED] http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher Sic transit discus mundi -- From the System Administrator's Guide, by Lars Wirzenius ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
