Re: [Zope-dev] [Checkins] SVN: zope.component/branches/tseaver-wo_zope_deferred/ Branch removing zope.deferred.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Korostelev wrote:
2009/3/4 Tres Seaver <tseaver@palladion.com>:
Log message for revision 97465: Branch removing zope.deferred.
Changed: D zope.component/branches/tseaver-wo_zope_deferred/src/zope/component/bbb/
-# BBB: Backward-compatibility; 12/05/2004 -from bbb.interfaces import *
Note, that the context-dependent/presentation/view stuff that was in BBB interfaces are still used in some places, like zope.publisher, so this needs more careful (re)moving. I think that one of the nice places for those interfaces is zope.browser, however they are not necessary browser-related, so maybe they should be moved elsewhere or just placed in zope.component.interfaces for now, as they're really tiny.
Yup. That was probably a case of premature deprecation (back in 2004). Note that I'm not actually proposing that we merge this branch any time soon: it is a bit of a straw man for the ongoing process conversation. 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 iD8DBQFJra+4+gerLs4ltQ4RAtw3AJ9sS97lAUFp09XHeYUy9HGgt+DHzQCcDKEY s40FAqfVUgblyg4OosNm7WM= =EyRo -----END PGP SIGNATURE-----
2009/3/4 Tres Seaver <tseaver@palladion.com>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dan Korostelev wrote:
2009/3/4 Tres Seaver <tseaver@palladion.com>:
Log message for revision 97465: Branch removing zope.deferred.
Changed: D zope.component/branches/tseaver-wo_zope_deferred/src/zope/component/bbb/
-# BBB: Backward-compatibility; 12/05/2004 -from bbb.interfaces import *
Note, that the context-dependent/presentation/view stuff that was in BBB interfaces are still used in some places, like zope.publisher, so this needs more careful (re)moving. I think that one of the nice places for those interfaces is zope.browser, however they are not necessary browser-related, so maybe they should be moved elsewhere or just placed in zope.component.interfaces for now, as they're really tiny.
Yup. That was probably a case of premature deprecation (back in 2004).
Note that I'm not actually proposing that we merge this branch any time soon: it is a bit of a straw man for the ongoing process conversation.
Why not? It looks that it's just a dependency cleanup, so it can be merged (and released!) really soon (if noone objects, of course). I personally don't like long-living branches and forks. -- WBR, Dan Korostelev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Korostelev wrote:
2009/3/4 Tres Seaver <tseaver@palladion.com>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dan Korostelev wrote:
2009/3/4 Tres Seaver <tseaver@palladion.com>:
Log message for revision 97465: Branch removing zope.deferred.
Changed: D zope.component/branches/tseaver-wo_zope_deferred/src/zope/component/bbb/ -# BBB: Backward-compatibility; 12/05/2004 -from bbb.interfaces import * Note, that the context-dependent/presentation/view stuff that was in BBB interfaces are still used in some places, like zope.publisher, so this needs more careful (re)moving. I think that one of the nice places for those interfaces is zope.browser, however they are not necessary browser-related, so maybe they should be moved elsewhere or just placed in zope.component.interfaces for now, as they're really tiny. Yup. That was probably a case of premature deprecation (back in 2004).
Note that I'm not actually proposing that we merge this branch any time soon: it is a bit of a straw man for the ongoing process conversation.
Why not? It looks that it's just a dependency cleanup, so it can be merged (and released!) really soon (if noone objects, of course). I personally don't like long-living branches and forks.
Well, part of the dependency cleanup involves making a possibly- controversial coding style change ("from imports"), and I may have broken something in the 'compattests'. I would also like to make 'setup.py test' actually work in the absence of buildout. 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 iD8DBQFJrbMN+gerLs4ltQ4RAp7FAJ9WewCeb9MjTCs+uLjBzKVGjxTgIACghhhI Zm+bEA0HXgd7ULswVhJ8zzo= =1lIL -----END PGP SIGNATURE-----
2009/3/4 Tres Seaver <tseaver@palladion.com>:
Note that I'm not actually proposing that we merge this branch any time soon: it is a bit of a straw man for the ongoing process conversation.
Why not? It looks that it's just a dependency cleanup, so it can be merged (and released!) really soon (if noone objects, of course). I personally don't like long-living branches and forks.
Well, part of the dependency cleanup involves making a possibly- controversial coding style change ("from imports"),
Will it cause any problems in packages that use existing zope.component with its current coding style? If not, then why can it be a problem?
and I may have broken something in the 'compattests'.
Well, that certainly needs to be tested, but I don't think it's a blocker for merging. We're on the development version anyway. :-) (however, of course if would be nicer to do compattests before merging, but this should'nt take much time?)
I would also like to make 'setup.py test' actually work in the absence of buildout.
Isn't this as easy as adding the contents of "test" extra to the "test_requires" parameter? -- WBR, Dan Korostelev
Dan Korostelev wrote:
2009/3/4 Tres Seaver <tseaver@palladion.com>:
Note that I'm not actually proposing that we merge this branch any time soon: it is a bit of a straw man for the ongoing process conversation. Why not? It looks that it's just a dependency cleanup, so it can be merged (and released!) really soon (if noone objects, of course). I personally don't like long-living branches and forks. Well, part of the dependency cleanup involves making a possibly- controversial coding style change ("from imports"),
Will it cause any problems in packages that use existing zope.component with its current coding style? If not, then why can it be a problem?
Because Jim doesn't like "from" imports. :) I do like from imports just fine, especially if they allow us dumping zope.deferredimport (which I didn't realize needed zope.proxy, ugh), so +1 from me. Regards, Martijn
2009/3/4 Martijn Faassen <faassen@startifact.com>:
Dan Korostelev wrote:
2009/3/4 Tres Seaver <tseaver@palladion.com>:
Note that I'm not actually proposing that we merge this branch any time soon: it is a bit of a straw man for the ongoing process conversation. Why not? It looks that it's just a dependency cleanup, so it can be merged (and released!) really soon (if noone objects, of course). I personally don't like long-living branches and forks. Well, part of the dependency cleanup involves making a possibly- controversial coding style change ("from imports"),
Will it cause any problems in packages that use existing zope.component with its current coding style? If not, then why can it be a problem?
Because Jim doesn't like "from" imports. :)
I think, it's can be important when we talking about some "coding style standard", but when from imports are used as a tool to achieve specific need, I don't think that Jim will object. :) +1 on dropping zope.deferredimport+zope.proxy dependency ASAP. -- WBR, Dan Korostelev
Dan Korostelev wrote:
2009/3/4 Martijn Faassen <faassen@startifact.com>:
Dan Korostelev wrote:
2009/3/4 Tres Seaver <tseaver@palladion.com>:
Note that I'm not actually proposing that we merge this branch any time soon: it is a bit of a straw man for the ongoing process conversation. Why not? It looks that it's just a dependency cleanup, so it can be merged (and released!) really soon (if noone objects, of course). I personally don't like long-living branches and forks. Well, part of the dependency cleanup involves making a possibly- controversial coding style change ("from imports"), Will it cause any problems in packages that use existing zope.component with its current coding style? If not, then why can it be a problem? Because Jim doesn't like "from" imports. :)
I think, it's can be important when we talking about some "coding style standard", but when from imports are used as a tool to achieve specific need, I don't think that Jim will object. :)
+1 on dropping zope.deferredimport+zope.proxy dependency ASAP.
Agreed, +1 from the Zope Framework Steering Group. I've recorded this decision here: http://svn.zope.org/zopeframework/trunk/decisions.txt Regards, Martijn
participants (3)
-
Dan Korostelev -
Martijn Faassen -
Tres Seaver