Re: [Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
Hanno Schlichting wrote: Going back to the 3.4 stable set and being stuck at Python 2.4 would be quite disappointing for me. Me too, especially as I now have a Zope 2.12 project that's using lots of interesting Python 2.5'isms ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
Chris Withers wrote: plohn. ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
On 01.05.2009 17:33 Uhr, Chris Withers wrote: Andreas Jung wrote: We would have to maintain four different major release of Zope: 2.10, 2.11, 2.12 and 2.13. Why? I suspect most of this work is caused by plohn. If you're speaking as a member of that community, then fine, but that's not really a Zope issue. I am speaking for myself wearing lots of different hats. Plone is part of the Zope eco-system and we have to take their needs and requirements into account. Andreas -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: i...@zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK E-Publishing, Python, Zope Plone development, Consulting begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 1, 2009, at 17:47 , Andreas Jung wrote: On 01.05.2009 17:33 Uhr, Chris Withers wrote: Andreas Jung wrote: We would have to maintain four different major release of Zope: 2.10, 2.11, 2.12 and 2.13. Why? I suspect most of this work is caused by plohn. If you're speaking as a member of that community, then fine, but that's not really a Zope issue. I am speaking for myself wearing lots of different hats. Plone is part of the Zope eco-system and we have to take their needs and requirements into account. I would make that one of the most important parts of the Zope eco system. Without Plone, I suspect the Zope community as a whole would be a lot smaller, and certainly less colorful. Chris, don't let personal grudges get in the way of planning decisions like this ;-) jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkn7J5kACgkQRAx5nvEhZLJ5kACgkAPSHtYByr+VBtKT4/o7hVxc +8cAnA1guu8cpVL/7x3jLmAU4PKZWRrJ =nait -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
Jens Vagelpohl wrote: Chris, don't let personal grudges get in the way of planning decisions like this ;-) Hey! Don't you go all good cop on me :-P Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
Hanno Schlichting wrote: Chris Withers wrote: I'm also about -sys.maxint on these changes for Zope 2.12 as I'd like to see 2.12 out the door as soon as possible. Then we have a conflict of interest. My main goal for Zope 2.12 is to be based on the Zope Toolkit 1.0 release and loose quite some more stuff. My understanding is that the big drive for Zope 2.12 was to get it egg-based. That is now done, so lets get it out the door. I think Zope 2.13 would be an excellent target for moving to ZTK 1.0. There's no reason Zope 2.13 shouldn't follow as quickly after 2.12 as it is able, but I also see no reason to hold up 2.12 waiting for something which has no defined end point. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
On 29.04.2009 15:28 Uhr, Chris Withers wrote: Hanno Schlichting wrote: Chris Withers wrote: I'm also about -sys.maxint on these changes for Zope 2.12 as I'd like to see 2.12 out the door as soon as possible. Then we have a conflict of interest. My main goal for Zope 2.12 is to be based on the Zope Toolkit 1.0 release and loose quite some more stuff. My understanding is that the big drive for Zope 2.12 was to get it egg-based. That is now done, so lets get it out the door. I think Zope 2.13 would be an excellent target for moving to ZTK 1.0. There's no reason Zope 2.13 shouldn't follow as quickly after 2.12 as it is able, but I also see no reason to hold up 2.12 waiting for something which has no defined end point. I strongly object inflationary Zope 2 releases. Andreas begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
On Wed, Apr 29, 2009 at 16:09, Andreas Jung li...@zopyx.com wrote: On 29.04.2009 15:28 Uhr, Chris Withers wrote: Hanno Schlichting wrote: Chris Withers wrote: I'm also about -sys.maxint on these changes for Zope 2.12 as I'd like to see 2.12 out the door as soon as possible. Then we have a conflict of interest. My main goal for Zope 2.12 is to be based on the Zope Toolkit 1.0 release and loose quite some more stuff. My understanding is that the big drive for Zope 2.12 was to get it egg-based. That is now done, so lets get it out the door. I think Zope 2.13 would be an excellent target for moving to ZTK 1.0. There's no reason Zope 2.13 shouldn't follow as quickly after 2.12 as it is able, but I also see no reason to hold up 2.12 waiting for something which has no defined end point. I strongly object inflationary Zope 2 releases. Well, this isn't inflationary, is it? 2.12 is eggified. That deserves a new version number. If we then after that start changing how acquisition work, that also needs a new version number. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
On 29.04.2009 16:51 Uhr, Lennart Regebro wrote: On Wed, Apr 29, 2009 at 16:09, Andreas Jung li...@zopyx.com wrote: On 29.04.2009 15:28 Uhr, Chris Withers wrote: Hanno Schlichting wrote: Chris Withers wrote: I'm also about -sys.maxint on these changes for Zope 2.12 as I'd like to see 2.12 out the door as soon as possible. Then we have a conflict of interest. My main goal for Zope 2.12 is to be based on the Zope Toolkit 1.0 release and loose quite some more stuff. My understanding is that the big drive for Zope 2.12 was to get it egg-based. That is now done, so lets get it out the door. I think Zope 2.13 would be an excellent target for moving to ZTK 1.0. There's no reason Zope 2.13 shouldn't follow as quickly after 2.12 as it is able, but I also see no reason to hold up 2.12 waiting for something which has no defined end point. I strongly object inflationary Zope 2 releases. Well, this isn't inflationary, is it? 2.12 is eggified. That deserves a new version number. If we then after that start changing how acquisition work, that also needs a new version number. We would have to maintain four different major release of Zope: 2.10, 2.11, 2.12 and 2.13. Support for 2.10 can't be dropped since it is the requirement for Plone 3.X. A new major Zope 2.13 can be addressed when there are enough valuable features and changes that satisfy a new release. Andreas -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: i...@zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK E-Publishing, Python, Zope Plone development, Consulting begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
Lennart Regebro wrote: Or, we could release 2.12 soon, and then start working on 2.13, a version that explicitly is for people who want to move towards the Zope Toolkit, and may not be completely backward compatible. This would be my vote. Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
Chris Withers wrote: Lennart Regebro wrote: Or, we could release 2.12 soon, and then start working on 2.13, a version that explicitly is for people who want to move towards the Zope Toolkit, and may not be completely backward compatible. This would be my vote. Right now the story for features in Zope 2.12 is at http://docs.zope.org/zope2/releases/2.12/WHATSNEW.html and has the following items: - Support for newer Python versions - Fully eggified - Zope Toolkit - ZODB 3.9 - Module cleanup - Documentation updates - Acquisition redux - Object managers and IContainer If I understand some people correctly, they want Fully eggified over all others. The risky and mostly undefined item on the list is the Zope Toolkit. While ZODB 3.9 isn't finished yet, it is close enough to not cause any major trouble. So which of the three options do people want, when it comes to the included Zope packages: 1. Stable - meaning use the same as Zope 2.11 does (== Zope 3.4) 2. Zope Toolkit 1.0 (whatever that is) 3. A newer mix of Zope packages, which particular mix isn't shared with anyone else There are some bad implications for all of these items: 1. The stable option also looses us support for newer Python versions. It is only very recently that packages got full deprecation warning less support for Python 2.5 and 2.6. With Zope 3.4 we are stuck with Python 2.4. 2. The Zope Toolkit 1.0 isn't defined yet and will delay any kind of beta release by some more undefined time. 3. The kind of wild mix of Zope packages we have right now is hard to maintain, as nobody else is testing the particular combination in any way and ongoing refactorings cause subtle breakage all the time. My personal vote still goes for option 2. What that means is trying to establish a more minimal set of packages and declaring a particular version soup of that mix as stable. In order to get this done, we need someone other than me trying to do the actual work of defining such set of packages and the steering group to make a decision about the scope of a 1.0 release. I'm all in favor of declaring whatever we basically got now as a good 1.0 release and then continue to work on a Zope Toolkit 2.0 where an exclusion of the ZMI bits and maybe the zope.app.publication and friends refactorings are major work items. Speaking from the Plone perspective, a Zope 2.12 release that is released as soon as possible has no particular value. No official Plone version would use such a release and with the kind of changes we have, it's unlikely that any Plone 3.x version will work with it. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
My 2 cents: Zope 2.12 will go into beta state as soon as ZODB 3.9.0 goes beta. The underlying Zope 3 packages are stable and good enough right - I don't care much right now about having an official Zope Toolkit Release 1.0. If this will happen soon: fine - otherwise we will stay with the current Zope 3.4 packages. With Zope 2.12.0b1 we will look at the state of the ZTK and make a final decision (3.4 vs. ZTK 1.0). This decision will then be final for the 2.12 release. People will be free to use the ZTK later on their own risk by overriding the versions or by providing a dedicated index Andreas On 28.04.2009 9:58 Uhr, Hanno Schlichting wrote: Chris Withers wrote: Lennart Regebro wrote: Or, we could release 2.12 soon, and then start working on 2.13, a version that explicitly is for people who want to move towards the Zope Toolkit, and may not be completely backward compatible. This would be my vote. Right now the story for features in Zope 2.12 is at http://docs.zope.org/zope2/releases/2.12/WHATSNEW.html and has the following items: - Support for newer Python versions - Fully eggified - Zope Toolkit - ZODB 3.9 - Module cleanup - Documentation updates - Acquisition redux - Object managers and IContainer If I understand some people correctly, they want Fully eggified over all others. The risky and mostly undefined item on the list is the Zope Toolkit. While ZODB 3.9 isn't finished yet, it is close enough to not cause any major trouble. So which of the three options do people want, when it comes to the included Zope packages: 1. Stable - meaning use the same as Zope 2.11 does (== Zope 3.4) 2. Zope Toolkit 1.0 (whatever that is) 3. A newer mix of Zope packages, which particular mix isn't shared with anyone else There are some bad implications for all of these items: 1. The stable option also looses us support for newer Python versions. It is only very recently that packages got full deprecation warning less support for Python 2.5 and 2.6. With Zope 3.4 we are stuck with Python 2.4. 2. The Zope Toolkit 1.0 isn't defined yet and will delay any kind of beta release by some more undefined time. 3. The kind of wild mix of Zope packages we have right now is hard to maintain, as nobody else is testing the particular combination in any way and ongoing refactorings cause subtle breakage all the time. My personal vote still goes for option 2. What that means is trying to establish a more minimal set of packages and declaring a particular version soup of that mix as stable. In order to get this done, we need someone other than me trying to do the actual work of defining such set of packages and the steering group to make a decision about the scope of a 1.0 release. I'm all in favor of declaring whatever we basically got now as a good 1.0 release and then continue to work on a Zope Toolkit 2.0 where an exclusion of the ZMI bits and maybe the zope.app.publication and friends refactorings are major work items. Speaking from the Plone perspective, a Zope 2.12 release that is released as soon as possible has no particular value. No official Plone version would use such a release and with the kind of changes we have, it's unlikely that any Plone 3.x version will work with it. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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 ) -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: i...@zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK E-Publishing, Python, Zope Plone development, Consulting begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
2009/4/27 Chris McDonough chr...@plope.com: On 4/27/09 3:27 PM, Laurence Rowe wrote: Martin Aspeli wrote: Laurence Rowe wrote: Martin Aspeli wrote: Hi, First - a quick question: can we treat __name__ and id/getId()/_setId() as the same, always? OFS.SimpleItem has some support for letting id and name be the same, but the link is lost once both __name__ and id are set. Why isn't __name__ just a property that reflects self.id ? I would prefer this to be the other way around -- getId() / _setId() should operate on __name__. It will be easier to drop OFS support in the future if pickles store the real __name__ and __parent__ attributes. We will presumably require a migration now anyway to add __parent__ pointers. It kind of already does that if 'id' isn't set. But when 'id' is set, they diverge. Also note that according to ILocation, __name__ is a TextLine, which implies unicode. unicode ids are a no-no in Zope 2. I doubt it would be all that difficult to change the publisher to handle unicode path segments. This would be the only sane thing to do if Zope was being created today. It's a lot saner to store Unicode object identifiers than string ones, and if you've got that it's a no-brainer to use Unicode path segments too. But if you did one and not the other, it would be a worthless change. My point here is that if we modify the publisher then maybe we can start storing unicode __name__ attributes. Unicode container keys work just fine now so long as they contain only ascii characters. The current solution I've put into dexterity is to let __name__ be a property that gets and sets id, but assumes its value is unicode. It'll fail if the unicode string can't be encoded to ASCII, though. That's certainly keeping with the spirit of the default bad identifier regex in OFS, but it does feel a little weird to need to never use high-order characters in ids (even if you did need to make them utf-8 encoded). I had to work around this for one very large application that wanted to use Zope as a filesystem storage and it was no fun at all (in fact, it would have been sanest to not use Zope for that). This is what I'm worried about. If new code uses __name__ instead, then it opens up the possibility to share ZODB content between Plone and lightweight systems like repoze.bfg, as well as making it easier for Plone to migrate to a cleaner content model. Plone has been around for eight years now, I sincerely hope we are not still stuck on OFS.SimpleItem for another eight years! I wouldn't worry much about trying to preserve compatibility between Zope 2 and Zope 3/bfg at this level; it's highly unlikely that *any* Plone content object will work out of the box on any system other than Zope2 (or at least without a large chunk of Zope2 sitting around) due to abuses of things like self.REQUEST in Archetypes. But I could be wrong. You don't have to write Archetypes to use Plone though. Tools like plone.app.content allow you to write sane, lightweight content types with zope.schema today. You need to bring in a lot of baggage in your base classes for things to be compatible with the CMF layer, but on the storage layer at least things are starting to look fairly sane. The acquisition changes in Zope 2.12 give us the possibility of writing clean new code without having to rewrite everything at once. Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
On Tue, Apr 28, 2009 at 09:58, Hanno Schlichting hanno...@hannosch.eu wrote: 1. The stable option also looses us support for newer Python versions. It is only very recently that packages got full deprecation warning less support for Python 2.5 and 2.6. With Zope 3.4 we are stuck with Python 2.4. I haven't run one single Zope project for at least 3-4 years that doesn't start up with screens of deprecation messages. It might be ugly, but it isn't really a significant problem. So I'll +2 my cents to Andreas 2 cents. :-) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
On 28.04.2009 15:02 Uhr, Lennart Regebro wrote: On Tue, Apr 28, 2009 at 09:58, Hanno Schlichting hanno...@hannosch.eu wrote: 1. The stable option also looses us support for newer Python versions. It is only very recently that packages got full deprecation warning less support for Python 2.5 and 2.6. With Zope 3.4 we are stuck with Python 2.4. I haven't run one single Zope project for at least 3-4 years that doesn't start up with screens of deprecation messages. It might be ugly, but it isn't really a significant problem. So I'll +2 my cents to Andreas 2 cents. :-) And since Jim will release ZODB 3.9.0 beta soon (see zodb-dev list) we will see a 2.12.0b1 pretty soon (first half of May or so) - likely with the Zope 3.4 packages. Andreas begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: Chris Withers wrote: Lennart Regebro wrote: Or, we could release 2.12 soon, and then start working on 2.13, a version that explicitly is for people who want to move towards the Zope Toolkit, and may not be completely backward compatible. This would be my vote. Right now the story for features in Zope 2.12 is at http://docs.zope.org/zope2/releases/2.12/WHATSNEW.html and has the following items: - Support for newer Python versions - Fully eggified - Zope Toolkit - ZODB 3.9 - Module cleanup - Documentation updates - Acquisition redux - Object managers and IContainer If I understand some people correctly, they want Fully eggified over all others. The risky and mostly undefined item on the list is the Zope Toolkit. While ZODB 3.9 isn't finished yet, it is close enough to not cause any major trouble. So which of the three options do people want, when it comes to the included Zope packages: 1. Stable - meaning use the same as Zope 2.11 does (== Zope 3.4) 2. Zope Toolkit 1.0 (whatever that is) 3. A newer mix of Zope packages, which particular mix isn't shared with anyone else There are some bad implications for all of these items: 1. The stable option also looses us support for newer Python versions. It is only very recently that packages got full deprecation warning less support for Python 2.5 and 2.6. With Zope 3.4 we are stuck with Python 2.4. 2. The Zope Toolkit 1.0 isn't defined yet and will delay any kind of beta release by some more undefined time. 3. The kind of wild mix of Zope packages we have right now is hard to maintain, as nobody else is testing the particular combination in any way and ongoing refactorings cause subtle breakage all the time. My personal vote still goes for option 2. What that means is trying to establish a more minimal set of packages and declaring a particular version soup of that mix as stable. In order to get this done, we need someone other than me trying to do the actual work of defining such set of packages and the steering group to make a decision about the scope of a 1.0 release. I'm all in favor of declaring whatever we basically got now as a good 1.0 release and then continue to work on a Zope Toolkit 2.0 where an exclusion of the ZMI bits and maybe the zope.app.publication and friends refactorings are major work items. Speaking from the Plone perspective, a Zope 2.12 release that is released as soon as possible has no particular value. No official Plone version would use such a release and with the kind of changes we have, it's unlikely that any Plone 3.x version will work with it. At the moment, the Zope 2 package set it defined here: http://svn.zope.org/Zope/trunk/versions.cfg?view=markup I don't see any reason to hold up a 2.12 release while the ZTK stabilizes: in fact, I think the existince of a stable 2.12 release with a known package set may be a prerequisite for getting there. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ9xI2+gerLs4ltQ4RAjEAAKCmpxhaxX6NDuhrAAmnLdLh1/RLVQCgxlc8 4JQYuT+aGmNfqCWkudPDovw= =drGg -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
Andreas Jung wrote: I have no problem with the changes. You have my blessing if Hanno is ok with the changes from the Plone prospective. I'm OK with the changes from the Plone perspective. I do however have a concern from the Zope perspective ;) What I'm worried about is what kind of migration we need for this to happen and what kind of impact this can have on derived types which might override the methods in question. If someone overwrites _setOb and _delOb in custom classes without calling the methods on the base classes or hasn't fully bought into the events story, I'm a bit worried we get hard to track down inconsistencies in the parent pointers. Since these pointers will take precedence over any even manually crafted Acquisition chains, certain operations might no longer be possible. An object with parent pointers will have its real physical path as its context. In the way Acquisition used to be used, it was quite possible to change the context of things by crafting different AQ chains. I'm quite certain that none of the code in Plone or on the CMF level has such problems. But I have no idea what kind of code is out there in the wild based on Zope2. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
Chris Withers wrote: I'm also about -sys.maxint on these changes for Zope 2.12 as I'd like to see 2.12 out the door as soon as possible. Then we have a conflict of interest. My main goal for Zope 2.12 is to be based on the Zope Toolkit 1.0 release and loose quite some more stuff. That in itself is going to take quite some more months to get to I'd assume. In the current situation Zope2 is based on some undefined mix of packages which none of the others projects share. To share actual maintenance cost between the different communities we need to get some stable basis with a somewhat defined scope back. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
Martin Aspeli wrote: Hi, First - a quick question: can we treat __name__ and id/getId()/_setId() as the same, always? OFS.SimpleItem has some support for letting id and name be the same, but the link is lost once both __name__ and id are set. Why isn't __name__ just a property that reflects self.id ? I would prefer this to be the other way around -- getId() / _setId() should operate on __name__. It will be easier to drop OFS support in the future if pickles store the real __name__ and __parent__ attributes. We will presumably require a migration now anyway to add __parent__ pointers. In Zope 2.12, acquisition wrappers are optional. Instead of using a wrapper, acquisition can work by following __parent__ pointers. That work well for views, where these are now set properly, but no content currently maintains __parent__ pointers. We can fix this by introducing some code in OFS (and BTreeFolder2) that mimics what zope.container does. We can't use the setitem() and uncontained() helpers directly, since these deal with containment proxies and have slightly different semantics, but I think we can do this: 1) Add the following to _setOb: def _setOb(self, id, object): if ILocation.providedBy(object): if not IContained.providedBy(object): alsoProvides(object, IContained) oldname = getattr(object, '__name__', None) oldparent = getattr(object, '__parent__', None) if id is not oldname: object.__name__ = id if self is not oldparent: object.__parent__ = self setattr(self, id, object) 2) Add the following to _delOb: def _delOb(self, id): Remove the named object from the folder. try: obj = self._getOb(id, _marker) if obj is not _marker: if IContained.providedBy(obj): obj.__parent__ = None obj.__name__ = None except AttributeError: # No need to fail if we can't set these pass delattr(self, id) Note that there's a slight discrepancy here with the way zope.container works. In Zope 3, the __parent__ pointer is not unset until after the ObjectRemovedEvent is fired. In Zope 2, we only fire that event after the object has been fully removed (in _delObject()), but we have the ObjectWillBeRemovedEvent that is fired before. I don't think this really matters, though. 3) It'd be nice to also make ObjectManager and BTreeFolder2Base support the IContainer interface, so that OFS containers can be used with the more natural dict-like API of Zope 3 rather than the somewhat obscure getattr()/_getOb()/_setObject()-vs-_setOb() and so on API we have now. To add this, we'd just need to add a few methods to ObjectManager that calls the existing APIs, e.g. __getitem__, __delitem__, __setitem__ and so on. We have code for all three of these in plone.folder which could be pushed down to OFS an BTreeFolder2 quite easily. +1 Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
Laurence Rowe wrote: Martin Aspeli wrote: Hi, First - a quick question: can we treat __name__ and id/getId()/_setId() as the same, always? OFS.SimpleItem has some support for letting id and name be the same, but the link is lost once both __name__ and id are set. Why isn't __name__ just a property that reflects self.id ? I would prefer this to be the other way around -- getId() / _setId() should operate on __name__. It will be easier to drop OFS support in the future if pickles store the real __name__ and __parent__ attributes. We will presumably require a migration now anyway to add __parent__ pointers. It kind of already does that if 'id' isn't set. But when 'id' is set, they diverge. Also note that according to ILocation, __name__ is a TextLine, which implies unicode. unicode ids are a no-no in Zope 2. The current solution I've put into dexterity is to let __name__ be a property that gets and sets id, but assumes its value is unicode. It'll fail if the unicode string can't be encoded to ASCII, though. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
Martin Aspeli wrote: Laurence Rowe wrote: Martin Aspeli wrote: Hi, First - a quick question: can we treat __name__ and id/getId()/_setId() as the same, always? OFS.SimpleItem has some support for letting id and name be the same, but the link is lost once both __name__ and id are set. Why isn't __name__ just a property that reflects self.id ? I would prefer this to be the other way around -- getId() / _setId() should operate on __name__. It will be easier to drop OFS support in the future if pickles store the real __name__ and __parent__ attributes. We will presumably require a migration now anyway to add __parent__ pointers. It kind of already does that if 'id' isn't set. But when 'id' is set, they diverge. Also note that according to ILocation, __name__ is a TextLine, which implies unicode. unicode ids are a no-no in Zope 2. I doubt it would be all that difficult to change the publisher to handle unicode path segments. The current solution I've put into dexterity is to let __name__ be a property that gets and sets id, but assumes its value is unicode. It'll fail if the unicode string can't be encoded to ASCII, though. This is what I'm worried about. If new code uses __name__ instead, then it opens up the possibility to share ZODB content between Plone and lightweight systems like repoze.bfg, as well as making it easier for Plone to migrate to a cleaner content model. Plone has been around for eight years now, I sincerely hope we are not still stuck on OFS.SimpleItem for another eight years! Laurence ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
On 4/27/09 3:27 PM, Laurence Rowe wrote: Martin Aspeli wrote: Laurence Rowe wrote: Martin Aspeli wrote: Hi, First - a quick question: can we treat __name__ and id/getId()/_setId() as the same, always? OFS.SimpleItem has some support for letting id and name be the same, but the link is lost once both __name__ and id are set. Why isn't __name__ just a property that reflects self.id ? I would prefer this to be the other way around -- getId() / _setId() should operate on __name__. It will be easier to drop OFS support in the future if pickles store the real __name__ and __parent__ attributes. We will presumably require a migration now anyway to add __parent__ pointers. It kind of already does that if 'id' isn't set. But when 'id' is set, they diverge. Also note that according to ILocation, __name__ is a TextLine, which implies unicode. unicode ids are a no-no in Zope 2. I doubt it would be all that difficult to change the publisher to handle unicode path segments. This would be the only sane thing to do if Zope was being created today. It's a lot saner to store Unicode object identifiers than string ones, and if you've got that it's a no-brainer to use Unicode path segments too. But if you did one and not the other, it would be a worthless change. The current solution I've put into dexterity is to let __name__ be a property that gets and sets id, but assumes its value is unicode. It'll fail if the unicode string can't be encoded to ASCII, though. That's certainly keeping with the spirit of the default bad identifier regex in OFS, but it does feel a little weird to need to never use high-order characters in ids (even if you did need to make them utf-8 encoded). I had to work around this for one very large application that wanted to use Zope as a filesystem storage and it was no fun at all (in fact, it would have been sanest to not use Zope for that). This is what I'm worried about. If new code uses __name__ instead, then it opens up the possibility to share ZODB content between Plone and lightweight systems like repoze.bfg, as well as making it easier for Plone to migrate to a cleaner content model. Plone has been around for eight years now, I sincerely hope we are not still stuck on OFS.SimpleItem for another eight years! I wouldn't worry much about trying to preserve compatibility between Zope 2 and Zope 3/bfg at this level; it's highly unlikely that *any* Plone content object will work out of the box on any system other than Zope2 (or at least without a large chunk of Zope2 sitting around) due to abuses of things like self.REQUEST in Archetypes. But I could be wrong. - C ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
Now when we have eggs, can we fork the relevant modules (Publisher + OFS?) into two versions. Zope 2 backwards compatible versions, and versions that rely on that __parent__ is sane? Plone, and any others that want to gradually migrate to the toolkit, could then use that version. People who require backwards compatibility but need to more to Python 2.5/2.6 could use the old? Or, we could release 2.12 soon, and then start working on 2.13, a version that explicitly is for people who want to move towards the Zope Toolkit, and may not be completely backward compatible. (Let the flaming begin.) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
zopyxfil...@gmail.com wrote: On 27.04.2009 22:56 Uhr, Shane Hathaway wrote: Lennart Regebro wrote: Or, we could release 2.12 soon, and then start working on 2.13, a +1. We need an eggified, Buildout-friendly Zope 2 that's fully compatible with Zope 2.11. Zope 2.11??? In other words, let's not discuss any more sweeping changes for Zope 2.12. I want an eggified Zope 2 release soon so that RelStorage is easier to support. :-) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
Hi, First - a quick question: can we treat __name__ and id/getId()/_setId() as the same, always? OFS.SimpleItem has some support for letting id and name be the same, but the link is lost once both __name__ and id are set. Why isn't __name__ just a property that reflects self.id ? Then, the proposal: In Zope 2.12, acquisition wrappers are optional. Instead of using a wrapper, acquisition can work by following __parent__ pointers. That work well for views, where these are now set properly, but no content currently maintains __parent__ pointers. We can fix this by introducing some code in OFS (and BTreeFolder2) that mimics what zope.container does. We can't use the setitem() and uncontained() helpers directly, since these deal with containment proxies and have slightly different semantics, but I think we can do this: 1) Add the following to _setOb: def _setOb(self, id, object): if ILocation.providedBy(object): if not IContained.providedBy(object): alsoProvides(object, IContained) oldname = getattr(object, '__name__', None) oldparent = getattr(object, '__parent__', None) if id is not oldname: object.__name__ = id if self is not oldparent: object.__parent__ = self setattr(self, id, object) 2) Add the following to _delOb: def _delOb(self, id): Remove the named object from the folder. try: obj = self._getOb(id, _marker) if obj is not _marker: if IContained.providedBy(obj): obj.__parent__ = None obj.__name__ = None except AttributeError: # No need to fail if we can't set these pass delattr(self, id) Note that there's a slight discrepancy here with the way zope.container works. In Zope 3, the __parent__ pointer is not unset until after the ObjectRemovedEvent is fired. In Zope 2, we only fire that event after the object has been fully removed (in _delObject()), but we have the ObjectWillBeRemovedEvent that is fired before. I don't think this really matters, though. 3) It'd be nice to also make ObjectManager and BTreeFolder2Base support the IContainer interface, so that OFS containers can be used with the more natural dict-like API of Zope 3 rather than the somewhat obscure getattr()/_getOb()/_setObject()-vs-_setOb() and so on API we have now. To add this, we'd just need to add a few methods to ObjectManager that calls the existing APIs, e.g. __getitem__, __delitem__, __setitem__ and so on. We have code for all three of these in plone.folder which could be pushed down to OFS an BTreeFolder2 quite easily. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
On 26 Apr 2009, at 16:53, Martin Aspeli wrote: We can fix this by introducing some code in OFS (and BTreeFolder2) that mimics what zope.container does. Is there any risk involved in this? It looks ok in theory, just that we're at a4 of Zope 2.12, we should be getting wary of features. We have code for all three of these in plone.folder which could be pushed down to OFS an BTreeFolder2 quite easily. plone.folder is GPL and owned by the Plone Foundation, BTreeFolder2 is ZPL and owned by the Zope Foundation and contributors. This sounds like quite easily from a copy-the-code point of view, but doesn't take account of legal issues. You'd need at least a PF board vote. I doubt the Plone foundation is a Zope contributor, and I'm not sure if their agreements would even be compatible, it may grant Zope Corp some rights that weren't granted to the PF. Matt ___ Zope-Dev maillist - Zope-Dev@zope.org 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] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 26.04.2009 um 18:16 schrieb Matthew Wilkes: On 26 Apr 2009, at 16:53, Martin Aspeli wrote: We can fix this by introducing some code in OFS (and BTreeFolder2) that mimics what zope.container does. Is there any risk involved in this? It looks ok in theory, just that we're at a4 of Zope 2.12, we should be getting wary of features. We have code for all three of these in plone.folder which could be pushed down to OFS an BTreeFolder2 quite easily. plone.folder is GPL and owned by the Plone Foundation, BTreeFolder2 is ZPL and owned by the Zope Foundation and contributors. This sounds like quite easily from a copy-the-code point of view, but doesn't take account of legal issues. You'd need at least a PF board vote. I doubt the Plone foundation is a Zope contributor, and I'm not sure if their agreements would even be compatible, it may grant Zope Corp some rights that weren't granted to the PF The License-Locked-In effect? Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkn0jVUACgkQCJIWIbr9KYw6LwCgm2tdWpe2mHdZyobsb7mdSrgs JCYAoOUmoTtqTCVWqA/qHwwvsDxhnS/U =LNu3 -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
