Rename the zope package

Author

Problem

Zope 2 has a package named "Zope". Zope 3 has a package named "zope". Starting with Zope 2.8, parts of Zope 3 will be included in Zope 2. As things stand, this will require having both "Zope" and "zope" packages. Python can handle this fine, however, it will require putting the packages in separate directories (for Windows and Mac OS).

Having two packages with the same name, differing only by case has a number of disadvantages:

It is confusing
- People looking through the source will find the existence of two Zope directories confusing. If they are looking for one and find the other, they will think they just had the capitalization wrong.
- When an import involving the name "zope" or the name "Zope" fails, people will need to wonder whether it failed due to a capitalization error.
- When people try to talk verbally about a zope package, there will be ambiguity about whether they mean "zope" or "Zope". They will often have to try to disambiguate by saying things like "big zope" or "little zope". Having participated in conversations like that, I can say it's not fun.
- It will need to be explained (excused)
It's brittle
- It will lead to weird errors when there are capitalization typos
- It will confuse tools like pkgutils, which provides some automation for allowing container packages to be spread across the Python path. There aren't many tools like this, but the fact that we broke one is not a good sign. (It's especially troubling because this tool was created specifically to help us distribute the zope package over multiple directories.)
It requires adding an additional directory to the Python path. This is not a big deal, but it is a significant annoyance.
It's poor style, and thus, embarrassing. Again, it will be something we have to make excuses for.

Background

See the email thread from the zope3-dev list: http://mail.zope.org/pipermail/zope3-dev/2004-April/010443.html

Alternatives

Suck it up, and keep the status quo
Note that it has been argued that this is OK because it only affects the transition from Zope 2 to Zope 3. I'll counter by noting that:
- The transition is very important. We need to make it as smooth and successful as possible.
- The transition is likely to last at least a year or two.
Rename the Zope (Zope 2) package
Zope 2 is used widely. There are hundreds of 3rd-party add on packages that would be affected by this change, mainly because the Zope package is often imported by unit tests.

Some have argued that Zope 2.8, which includes large base-architecture changes, will require product changes anyway. If true, I think that this is unacceptable. We will endeavor to be backward compatible with most packages. It is an open question how backward compatible Zope 2.8 will be, but I think we need to make every reasonable effort to be backward compatible.

Renaming the Zope 2 Zope package is very unattractive for backwards-compatibility reasons.
Rename the Zope 3 zope package
At this time (but after the move to svn), it's not too hard to make a change like this for Zope 3. Backward compatibility is not a big issue. This will change when X3.0 is released, which is why I'm bothering to deal with this issue now.

The effort to simply rename this package is modest.

Names like "zope3" and "z3" have been rejected by most folks, who don't like the idea of embedding a version number in the (this very important) package name.

I think that the name "z" has some advantages:
- It fits with the expansion of "Zope": "Z Object Publishing Environment".
- It echos the "circle z" Zope logo.
- It's short :)
- I find it makes imports look less cluttered.
  For example, I find:
```
          import z.interface
          from z.app import zapi
          from z.app.event import publish
          from z.app.event.objectevent import ObjectModifiedEvent
```
  to be less cluttered looking than:
```
          import zope.interface
          from zope.app import zapi
          from zope.app.event import publish
          from zope.app.event.objectevent import ObjectModifiedEvent
```
- The packages in "z" can be used for more than just Zope
- Emphasizes the more "minimalist" nature of Zope 3 relative to Zope 2
Of course, many people, understandably think that the name "z" is a bit terse. :)

If we really don't like "z", then we shouldn't do this. Zope 3 is, hopefully, going to be with us for a long time. If we don't like the name "z", we shouldn't use it solely to overcome the name conflict.

I suppose one could argue that it is a bit presumptuous to claim the package named "z". :)
Rename the Zope package to Zope2 and provide a legacy Zope package
- Rename the "Zope" package to "Zope2"
- Put the Zope 3 "zope" package into the same location as "Zope2" in a combined installation.
- Provide a legacy directory containing a "Zope" package. There will be an option to add this to the Python path. This option will be enabled by default in Zope 2.8 and disabled by default in Zope 2.9.
  Importing Zope will cause a deprecation warning.
  
  The legacy Zope package will have a README.txt file that explains what it is and refers people to the zope and Zope2 packages.

Proposal

I propose to rename the Zope 3 "zope" package described as alternative 3 above. I think that this is the best of the three alternatives described above. While I wouldn't be proposing this change if there wasn't a name conflict, I do like the way that "z" looks as a package name, for the reasons mentioned above.

Update: I've gotten a fair amount of negative reaction to this proposal. I've added an alternative 4 that I think is pretty workable. It is similar to the status quo, but provides a transition away from the status quo.
I think we should pick either option 3 or option 4.