[Zope-dev] Re: [Zope3-dev] Re: Zope and zope
Note that the reason I suggested renaming Zope to zope2 (or whatever) as opposed to zope to zope3 is because Zope 3 uses absolute imports almost everywhere; it would be far less work to change Zope to Zope2 because Zope 2 either uses relative imports or assumes it can find what it needs on sys.path. I think the breakage, although literally incalculable (as is every change to Zope 2, given that it has no canonical API), would be manageable given enough lead time. In fact, if we did change the module name, we could just leave a bruce package in place that, when imported, raised a ObsoleteError with a descriptive message. I *hate* the idea of having two packages named zope where case is the only thing different. It's would be insanely difficult (not to mention embarrassing) to document, should the two codebases merge in some unholy fashion at some point as is on the 2.9 roadmap. - C - Original Message - From: Tres Seaver [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, April 13, 2004 11:08 PM Subject: Re: [Zope3-dev] Re: Zope and zope Stephan Richter wrote: On Tuesday 13 April 2004 22:17, Tres Seaver wrote: snip Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? -1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence. You wanna rename 'zope' to 'z3' for the purpose of merging the two? I really hope that will not be the case. Or is this for Zope 2 only? Note that I am -0 to the idea. I would hate to have imports like z3.app.foo or even z3.i18n. I am definitely -1 on this option, if it also applies to standalone Zope 3. I am just arguing that it would be saner to rename 'zope' to 'z3' (or 'zope3', or whatever) than to rename 'Zope' to 'zope2' (or whatever). Tres. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com ___ Zope3-dev mailing list [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope3-dev ___ 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: [Zope3-dev] Re: Zope and zope
Stephan Richter wrote: On Tuesday 13 April 2004 22:17, Tres Seaver wrote: snip Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? -1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence. You wanna rename 'zope' to 'z3' Tres doesn't. I want to solve the problem of having both zope and Zope. for the purpose of merging the two? Yes I really hope that will not be the case. Why? Or is this for Zope 2 only? No, it would have to apply to both. Packages that would otherwise work with Zope 3 in Zope 2 should not have to be changed to be used with Zope 3. I would hate to have imports like z3.app.foo or even z3.i18n. Why? What about z.app.foo or z.i18n? 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: [Zope3-dev] Re: Zope and zope
Chris McDonough wrote: Note that the reason I suggested renaming Zope to zope2 (or whatever) as opposed to zope to zope3 is because Zope 3 uses absolute imports almost everywhere; it would be far less work to change Zope to Zope2 because Zope 2 either uses relative imports or assumes it can find what it needs on sys.path. Zope 3 is still (for a short time) in a far more plastic state. There aren't many third-party products and their authors expect change at this time. For example, we very recently rearranged the zope.app package. I think the breakage, although literally incalculable (as is every change to Zope 2, given that it has no canonical API), would be manageable given enough lead time. In fact, if we did change the module name, we could just leave a bruce package in place that, when imported, raised a ObsoleteError with a descriptive message. But I think that this is a big problem. Backward compatibility for Z2 *is* important. It's too bad that lots of test files have to import Zope. Sigh. I *hate* the idea of having two packages named zope where case is the only thing different. Me too, the more I think about it. It's would be insanely difficult (not to mention embarrassing) to document, should the two codebases merge in some unholy fashion at some point as is on the 2.9 roadmap. Actually, the Zope 2.8 roadmap. :) Zope 2.8 will have Zope 3 interfaces. 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: [Zope3-dev] Re: Zope and zope
Stephan Richter wrote: On Wednesday 14 April 2004 11:08, Jim Fulton wrote: ... What about z.app.foo or z.i18n? The shortness of this example is very attractive, but it is still a compromise in my opinion. Again, I think educating is easier than anything else. People understand that this is due to a merge of codebases and is for a transition period only. And, the TTW scripter will not care. But this is a really important transition. It's a transition that will last at least a year or two, maybe longer, and will be an extremely sensitive period. I want things to go really well during this transition. 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: [Zope3-dev] Re: Zope and zope
On Wed, 2004-04-14 at 11:18, Stephan Richter wrote: Because in general I don't like version numbers in the path. I also think that zope is the only name that is 100% right on. Everything else is a compromise I would try to avoid. We will be sorry about it later, when many more people run Zope 3 only applications. I tend to agree, but if compromise is the only solution, then I'd tend to favor keeping Zope3 'clean'. We're planning on Zope3 being around much longer than Zope2, right? :) onions-are-tasty-but-not-in-the-varnish-ly y'rs, -Barry ___ 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: [Zope3-dev] Re: Zope and zope
On Wednesday 14 April 2004 11:36, Jim Fulton wrote: Again, I think educating is easier than anything else. People understand that this is due to a merge of codebases and is for a transition period only. And, the TTW scripter will not care. But this is a really important transition. It's a transition that will last at least a year or two, maybe longer, and will be an extremely sensitive period. I want things to go really well during this transition. Me too! And I think some good transition documents can help explaining this. I will commit to writing them with the help of someone who knows Zope 2 well. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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: [Zope3-dev] Re: Zope and zope
On Wednesday 14 April 2004 11:44, Barry Warsaw wrote: On Wed, 2004-04-14 at 11:18, Stephan Richter wrote: Because in general I don't like version numbers in the path. I also think that zope is the only name that is 100% right on. Everything else is a compromise I would try to avoid. We will be sorry about it later, when many more people run Zope 3 only applications. I tend to agree, but if compromise is the only solution, then I'd tend to favor keeping Zope3 'clean'. We're planning on Zope3 being around much longer than Zope2, right? :) Yes, this is really what I meant. I want to keep Zope 3 clean too. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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: [Zope3-dev] Re: Zope and zope
On 04/14/04 12:27, yuppie wrote: Jim Fulton wrote: But I think that this is a big problem. Backward compatibility for Z2 *is* important. It's too bad that lots of test files have to import Zope. Sigh. Why is that a *big* problem? - It's not nice to break tests, but that doesn't necessarily mean the products are broken. - AFAICT many products need some polishing and a new release for Zope 2.8 anyway. I'm with Yuppie. With fundamental changes occurring in ExtensionClass and ZODB, lots of products are going to need a small revision anyway. For example, we've already started changing from ZODB import Persistent to from Persistence import Persistent everywhere. The majority of products that need to import Zope will just change from: from Zope import app to: try: from zope2 import app except ImportError: # Pre-Zope 2.8 from Zope import app I think it's cool that Python makes that so easy to do. Shane ___ 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: [Zope3-dev] Re: Zope and zope
On Tuesday 13 April 2004 22:17, Tres Seaver wrote: snip Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? -1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence. You wanna rename 'zope' to 'z3' for the purpose of merging the two? I really hope that will not be the case. Or is this for Zope 2 only? I would hate to have imports like z3.app.foo or even z3.i18n. I am definitely -1 on this option, if it also applies to standalone Zope 3. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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: [Zope3-dev] Re: Zope and zope
Stephan Richter wrote: On Tuesday 13 April 2004 22:17, Tres Seaver wrote: snip Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? -1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence. You wanna rename 'zope' to 'z3' for the purpose of merging the two? I really hope that will not be the case. Or is this for Zope 2 only? Note that I am -0 to the idea. I would hate to have imports like z3.app.foo or even z3.i18n. I am definitely -1 on this option, if it also applies to standalone Zope 3. I am just arguing that it would be saner to rename 'zope' to 'z3' (or 'zope3', or whatever) than to rename 'Zope' to 'zope2' (or whatever). 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 )
[Zope-dev] Re: [Zope3-dev] Re: Zope and zope
Jim Fulton noted: Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? A bit ugly, but I can live with it. On Tuesday 13 April 2004 22:17, Tres Seaver wrote: -1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence. On Tuesday 13 April 2004 10:44 pm, Stephan Richter wrote: You wanna rename 'zope' to 'z3' for the purpose of merging the two? I really hope that will not be the case. Or is this for Zope 2 only? I would hate to have imports like z3.app.foo or even z3.i18n. I am definitely -1 on this option, if it also applies to standalone Zope 3. Tres has a good objection, *if* we actually expect 3rd-party Zope 2 code to work in Zope 3. (I don't know if we have this requirement or not; I've no personal interest in doing so.) If we don't expect 3rd-party Zope 2 code to work in Zope 3, then the second entry on sys.path seems good enough; having a collection of code identified by two different names is unworkable. (Think absolute imports here.) Any requirement that states 3rd-party Zope 2 code work in Zope 3 will have to be worked out; that's the key here. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ 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: [Zope3-dev] Re: Zope and zope
Fred Drake wrote: Jim Fulton noted: Of course, having two packages with names differing only in case is a bit ugly. Do we want to consider renaming one or both of these packages to avoid the conflict? A bit ugly, but I can live with it. On Tuesday 13 April 2004 22:17, Tres Seaver wrote: -1 to renaming 'Zope'; the amount of third-party code which we would break is incalculable. -0 to renaming 'zope' to 'z3', or something; at least third party code for Zope3 was built in the test-driven culture, and has at least some chance of migrating cleanly with confidence. On Tuesday 13 April 2004 10:44 pm, Stephan Richter wrote: You wanna rename 'zope' to 'z3' for the purpose of merging the two? I really hope that will not be the case. Or is this for Zope 2 only? I would hate to have imports like z3.app.foo or even z3.i18n. I am definitely -1 on this option, if it also applies to standalone Zope 3. Tres has a good objection, *if* we actually expect 3rd-party Zope 2 code to work in Zope 3. (I don't know if we have this requirement or not; I've no personal interest in doing so.) If we don't expect 3rd-party Zope 2 code to work in Zope 3, then the second entry on sys.path seems good enough; having a collection of code identified by two different names is unworkable. (Think absolute imports here.) Any requirement that states 3rd-party Zope 2 code work in Zope 3 will have to be worked out; that's the key here. -Fred I have not done anything with z3 yet, tough we intend to start working with it soon. We have a number of products that are mostly plain python within a thin zope-shell. Since we probably would like to use them in z3 and must maintain them in z2 I would like to see a way to mix the two. Robert ___ 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 )
