[Twisted-Python] New components questions
1. Currently, if c is a Componentized, IFoo(c, persist=False) will bypass c.getComponent() and do standard lookup. Is it worth supporting this at all? It'd make code cleaner if not, and integration with zope.interface easier. 2. How do we package zope.interface package? We could: a. include copy of code, as e.g. twisted.interface, and have it replace itself with zope.interface if that exists. This opens us to possible _xmlplus style horribleness. b. install zope.interface in our setup.py if it doesn't exist. c. tell people to install it themselves. 3. Do we want our own adapter registry or not? Zope's global registry is in zope.component, which is a whole new package we need to install and backport to 2.2. And it has lots of other stuff which while interesting and possibly useful means more cognitive overhead. My current code has its own registry and does not require zope.component. The downside is that if we have our own registry, code that uses both Twisted and zope.component will cause adaptation to an interface will be slower because it will need to check two registries. -- Itamar Shtull-Trauring http://itamarst.org Looking for a job -- http://itamarst.org/resume.html
Itamar Shtull-Trauring wrote:
AFAIC, persist= argument to adaptation doesn't make sense and shouldn't be worried about much. Deprecated backwards compatibility would be *nice*, of course, but don't worry about it if it's a big problem and nobody pipes up about the fact they're using it.
Definitely B or C... probably B, unless distutils grows automatic dependency downloading/management. :-P
Is the current situation duplicating code? If a "registry" is basically just a big dict or something, then no big deal... but I think sharing code is a good idea, if there is a significant amount of code involved. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://radix.twistedmatrix.com/
On Fri, 2004-05-07 at 18:31, Christopher Armstrong wrote:
I have full backwards compat already, though I'd encourage people to use zope's code directly instead of the compat layer. Question is if this specific backwards compat feature can be dropped (this will allow Componentized to work with straight-off zope.interface correctly, right now it only works via backwards-compat code). That is, I am asking if persist=False can be dropped for Componentized.
No, the zope.interface has the class definition for a registry, zope.component just adds a little utility wrapper around it and provides a global *instance* of the registry that apps can use. -- Itamar Shtull-Trauring http://itamarst.org Looking for a job -- http://itamarst.org/resume.html
Itamar Shtull-Trauring wrote:
I think so.
Hmm. How about using their registry if it's available? -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://radix.twistedmatrix.com/
On Fri, 2004-05-07 at 19:04, Christopher Armstrong wrote:
Itamar Shtull-Trauring wrote:
Yeah. agreed. Just make sure that the _adapter_ can still say that it doesn't want to be persistent; code that really, really seriously wants to remove a persistent adapter after it's created one can do just that; componentized.unsetComponent. Is it possible that we can move to a new-style Componentized somewhere else? There are a lot of slightly-incompatible changes I'd like to make, most especially to slotlessly subclass dict, so that the unweildy names like 'setComponent' and 'unsetComponent' become 'x[IY] = y' and 'del x[IY]', and to save space on what should be as lightweight an object as possible...
Hmm. How about using their registry if it's available?
I do like this idea. How do we determine if it's available though? It seems like there could be a lot of edge cases. Thank you, Itamar, for doing all this work.
On Fri, 2004-05-07 at 22:44, Glyph Lefkowitz wrote:
That's internal code in Adapter and Componentized, no? I won't be touching that.
Sure, think up a new name. To be honest, I think the way Componentized interacts with Adapter is ugly. I haven't looked at it closely enough to be sure exactly why - I just glanced at it, but really I'd think a special method that returns some info to the Componentized would be cleaner than checking attributes. Or something. -- Itamar Shtull-Trauring http://itamarst.org Looking for a job -- http://itamarst.org/resume.html
Christopher Armstrong wrote:
FWIW Fred Drake (PythonLabs/ZC) is working on zpkg: a packaging and dependency management tool, integrated with distutils. I believe the intent is to propose this as a Python tool eventually (presumably with a less "z..."-like name?). I know the immediate intent is to allow various different distributions of the Zope 3 code (including perhaps just the interface package for you all) to be distributed. That description doesn't give it much justice, but this should begin to: http://zope.org/Members/fdrake/zpkgtools/ I believe Fred is still actively seeking feedback, and requests feedback and questions on zope3-dev@zope.org. Gary
Gary Poster wrote:
FWIW Fred Drake (PythonLabs/ZC) is working on zpkg: a packaging and
Yeah, I'm already aware, thanks. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://radix.twistedmatrix.com/
On May 7, 2004, at 6:14 PM, Itamar Shtull-Trauring wrote:
No. The only places I've seen persist=False used, it's been a pure optimization. E.g. "I know I never want persistence, don't bother checking for me". I don't think anyone would cry if it went away. At least, I *hope* noone has been insane enough to depend on it.
I'd say "b", especially since "c" doesn't appear to be possible at all right now? For packaged versions, we should of course not include zope.interface at all, but simply depend on its package.
Wait, isn't the recommended path for new code that uses twisted supposed to be "use zope directly, not our compatibility wrappers"? How can we say that if we don't use/support the standard zope registry? What is the actual downside to using their registry? You don't have to tell people about all the crazy stuff you can do with it, just the one "registry adapter" call that they actually need. James
On Fri, 2004-05-07 at 19:10, James Y Knight wrote:
I'd say "use zope.interface directly except for register() for registering adapters, Componentized and Adapter which are in t.p.components". And if I do what Chris suggested that will be alias for zope's registry if it's installed.
Need to backport another package to 2.2, distribute it and keep it backported, mainly. -- Itamar Shtull-Trauring http://itamarst.org Looking for a job -- http://itamarst.org/resume.html
On May 7, 2004, at 7:15 PM, Itamar Shtull-Trauring wrote:
That sounds good to me. And if such a time comes as we actually want/need the extra zope registry features, we can either backport it then, or else 2.2 will be obsolete and we'll have to backport it to 2.3. ;) But in any case, old code will be automatically compatible. James
On Fri, 2004-05-07 at 20:22, James Y Knight wrote:
Why do we not want to provide this kind of aliasing for the whole interfaces package in order to avoid packaging issues? I still think that importing twisted.zope.interface is less problematic than importing zope directly. (It may be desireable for us to rev components less frequently than zope, for example.) What exactly about the _xmlplus mess made it a nightmare and why? I have vague memories of horribleness but I gave up too early to be seriously scarred.
On Fri, 2004-05-07 at 22:17, Glyph Lefkowitz wrote:
1. User installs Twisted which has z.i v0.9 2. User runs software happily 3. User installs z.i v0.91, twisted now uses thaat 4. Software suddenly breaks due to change in z.i - but it's very confusing why because as far as user is concerned they didn't change *twisted*. Except it's in practice unlikely. -- Itamar Shtull-Trauring http://itamarst.org Looking for a job -- http://itamarst.org/resume.html
Itamar Shtull-Trauring wrote:
AFAIC, persist= argument to adaptation doesn't make sense and shouldn't be worried about much. Deprecated backwards compatibility would be *nice*, of course, but don't worry about it if it's a big problem and nobody pipes up about the fact they're using it.
Definitely B or C... probably B, unless distutils grows automatic dependency downloading/management. :-P
Is the current situation duplicating code? If a "registry" is basically just a big dict or something, then no big deal... but I think sharing code is a good idea, if there is a significant amount of code involved. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://radix.twistedmatrix.com/
On Fri, 2004-05-07 at 18:31, Christopher Armstrong wrote:
I have full backwards compat already, though I'd encourage people to use zope's code directly instead of the compat layer. Question is if this specific backwards compat feature can be dropped (this will allow Componentized to work with straight-off zope.interface correctly, right now it only works via backwards-compat code). That is, I am asking if persist=False can be dropped for Componentized.
No, the zope.interface has the class definition for a registry, zope.component just adds a little utility wrapper around it and provides a global *instance* of the registry that apps can use. -- Itamar Shtull-Trauring http://itamarst.org Looking for a job -- http://itamarst.org/resume.html
Itamar Shtull-Trauring wrote:
I think so.
Hmm. How about using their registry if it's available? -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://radix.twistedmatrix.com/
On Fri, 2004-05-07 at 19:04, Christopher Armstrong wrote:
Itamar Shtull-Trauring wrote:
Yeah. agreed. Just make sure that the _adapter_ can still say that it doesn't want to be persistent; code that really, really seriously wants to remove a persistent adapter after it's created one can do just that; componentized.unsetComponent. Is it possible that we can move to a new-style Componentized somewhere else? There are a lot of slightly-incompatible changes I'd like to make, most especially to slotlessly subclass dict, so that the unweildy names like 'setComponent' and 'unsetComponent' become 'x[IY] = y' and 'del x[IY]', and to save space on what should be as lightweight an object as possible...
Hmm. How about using their registry if it's available?
I do like this idea. How do we determine if it's available though? It seems like there could be a lot of edge cases. Thank you, Itamar, for doing all this work.
On Fri, 2004-05-07 at 22:44, Glyph Lefkowitz wrote:
That's internal code in Adapter and Componentized, no? I won't be touching that.
Sure, think up a new name. To be honest, I think the way Componentized interacts with Adapter is ugly. I haven't looked at it closely enough to be sure exactly why - I just glanced at it, but really I'd think a special method that returns some info to the Componentized would be cleaner than checking attributes. Or something. -- Itamar Shtull-Trauring http://itamarst.org Looking for a job -- http://itamarst.org/resume.html
Christopher Armstrong wrote:
FWIW Fred Drake (PythonLabs/ZC) is working on zpkg: a packaging and dependency management tool, integrated with distutils. I believe the intent is to propose this as a Python tool eventually (presumably with a less "z..."-like name?). I know the immediate intent is to allow various different distributions of the Zope 3 code (including perhaps just the interface package for you all) to be distributed. That description doesn't give it much justice, but this should begin to: http://zope.org/Members/fdrake/zpkgtools/ I believe Fred is still actively seeking feedback, and requests feedback and questions on zope3-dev@zope.org. Gary
Gary Poster wrote:
FWIW Fred Drake (PythonLabs/ZC) is working on zpkg: a packaging and
Yeah, I'm already aware, thanks. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://radix.twistedmatrix.com/
On May 7, 2004, at 6:14 PM, Itamar Shtull-Trauring wrote:
No. The only places I've seen persist=False used, it's been a pure optimization. E.g. "I know I never want persistence, don't bother checking for me". I don't think anyone would cry if it went away. At least, I *hope* noone has been insane enough to depend on it.
I'd say "b", especially since "c" doesn't appear to be possible at all right now? For packaged versions, we should of course not include zope.interface at all, but simply depend on its package.
Wait, isn't the recommended path for new code that uses twisted supposed to be "use zope directly, not our compatibility wrappers"? How can we say that if we don't use/support the standard zope registry? What is the actual downside to using their registry? You don't have to tell people about all the crazy stuff you can do with it, just the one "registry adapter" call that they actually need. James
On Fri, 2004-05-07 at 19:10, James Y Knight wrote:
I'd say "use zope.interface directly except for register() for registering adapters, Componentized and Adapter which are in t.p.components". And if I do what Chris suggested that will be alias for zope's registry if it's installed.
Need to backport another package to 2.2, distribute it and keep it backported, mainly. -- Itamar Shtull-Trauring http://itamarst.org Looking for a job -- http://itamarst.org/resume.html
On May 7, 2004, at 7:15 PM, Itamar Shtull-Trauring wrote:
That sounds good to me. And if such a time comes as we actually want/need the extra zope registry features, we can either backport it then, or else 2.2 will be obsolete and we'll have to backport it to 2.3. ;) But in any case, old code will be automatically compatible. James
On Fri, 2004-05-07 at 20:22, James Y Knight wrote:
Why do we not want to provide this kind of aliasing for the whole interfaces package in order to avoid packaging issues? I still think that importing twisted.zope.interface is less problematic than importing zope directly. (It may be desireable for us to rev components less frequently than zope, for example.) What exactly about the _xmlplus mess made it a nightmare and why? I have vague memories of horribleness but I gave up too early to be seriously scarred.
On Fri, 2004-05-07 at 22:17, Glyph Lefkowitz wrote:
1. User installs Twisted which has z.i v0.9 2. User runs software happily 3. User installs z.i v0.91, twisted now uses thaat 4. Software suddenly breaks due to change in z.i - but it's very confusing why because as far as user is concerned they didn't change *twisted*. Except it's in practice unlikely. -- Itamar Shtull-Trauring http://itamarst.org Looking for a job -- http://itamarst.org/resume.html
participants (5)
-
Christopher Armstrong -
Gary Poster -
Glyph Lefkowitz -
Itamar Shtull-Trauring -
James Y Knight