Re: [Zope-dev] Proposal: set __parent__ and __name__ in Zope 2.12 OFS
On Sun, Apr 26, 2009 at 18:46, Martin Aspeli <optilude@gmail.com> wrote:
2009/4/27 Andreas Jung <lists@zopyx.com>:
You might approach Hanno since he has committer rights.
I do too... Does that mean you're +1 ?
I have no problem with the changes. You have my blessing if Hanno is ok with the changes from the Plone prospective. Andreas
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
Hanno Schlichting wrote:
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.
Indeed, and as someone who has real live production code that does exactly this kind of thing, I'm a big -1 for these changes. 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. For me, a true buildout-compatible release wins over all else. I really think we should aim for nothing more in terms of features before 2.12 is out... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
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
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
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
On Wed, Apr 29, 2009 at 16:09, Andreas Jung <lists@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
On 29.04.2009 16:51 Uhr, Lennart Regebro wrote:
On Wed, Apr 29, 2009 at 16:09, Andreas Jung <lists@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: info@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 PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote:
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.
That is fine. I think deferring the change proposed in this thread until after 2.12 is still the prudent thing to do. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ+IDf+gerLs4ltQ4RAr4WAJ4kurV2K2umCO3SM5UoGoBRyzKcwwCfWLsk gBY8/NfHQLN/GNGENXQDq4c= =b9qY -----END PGP SIGNATURE-----
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. For me, I'd happilly just see Zope 2.12 supported and let earlier versions only be supported/released when funded by any user or community that needs them or wants to do the work... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
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: info@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 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-----
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
participants (7)
-
Andreas Jung -
Chris Withers -
Hanno Schlichting -
Jens Vagelpohl -
Lennart Regebro -
Martin Aspeli -
Tres Seaver