-----Original Message----- From: Tom Bryan [SMTP:tbryan@server.python.net] Sent: June 17, 1999 12:19 PM To: Crew List Subject: Re: [Crew] Wizards' Resolution to Zope/PIL/mxDateTime conflict?

Perhaps this discussion should be moved to the PSA list or to the comp.lang.python newsgroup. The Starship isn't going to be the only computer with this problem. We juat are going to be one of the few machines that currently has *many* third-party extensions to Python. As Python grows in popularity, this problem is only going to get worse. In the worst case scenario, people won't be able to use a Python solution because the required third-party extensions conflict and they don't want to kludge it all together themselves.

It seems to me perhaps the simplest solution is, dare I say it, Bureaucracy! Okay, now that I got you all riled up, let me explain. Right now, anyone can go write a Python package and post it up all over the place, helter-skelter. It may even appear on www.python.org. However, if I'm writing Package A and you have written package B unbeknownst to me, I might be stepping on your toes. That is to say, if my package does the same thing, so what? more choice to the hacker. The problem is when I CALL my module/package the same thing as you. It is this naming convention that needs to be cleaned up, as I see it. Rather than come up with some complex scheme of installation or some major changes to the python language, wouldn't it just be simpler to standardize our naming now, before Python does reach the 10,000,000 user mark? That is, rather then trying to come up with an installation-level solution, why not just have someone review all packages for conflicts on a first-come-first-serve basis? Set up a committee of Python certification which will basically go through each new package and install it on a max-install station. If there are no conflicts, the package is certified and the author gets official recognition. If there is conflict, a polite e-mail can be sent to the author suggesting he or she modify / change the name(s) chosen for his or her package to avoid future conflict potential. As for currently existing conflicts, there is of course the problem with install-base. The best thing I can suggest is a renaming of 1 or more existing packages to conform to the Python standard extension model. That is to say, there would then be two copies of the package available -- 1 with backwards-compatible naming and 1 which is the Python-certified name. Based on the desire of the package author / maintainer, the old names could be phased out as time goes by in new releases. Typically, the more ingrained a package is in an application, the less likely it is that a conflicting package will be installed on that system. Thus *hopefully* this should not effect any previous install of Python. It would probably be best when conflicts *do* occur to ask *both* pre-existing Package authors to try to come up with new names, so as to be more even-handed, though I'd suggest larger packages get priority. The best thing is, when Microsoft starts to see Python as a threat to its Visual xxx monopoly and starts to "embrace" Python with their new Visual P++ integrated development environment, and starts adding weird packages left, right and center, the Python certification committee can just "uncertify" the extensions and (hopefully) prevent the destruction of the language the same way they did Java. I think Mark Hammond would be heading Microsoft off at the pass, as it were WRT this issue though. What's more, we here at Starship seem to be the perfect candidate to be the "Python Package" machine, at least on the Unix / Linux side -- I should hope a similar all-install machine could be set up for Microsoft-based system verification, as well as Mac and any other OS which has a unique package list.

Does someone want to make an intelligent, concise post to one of the other forums? comp.lang.python has enough posters who want to "improve" the language. Perhaps we could direct their energy into a useful change.

I am sending a copy of this over there... Be Seeing You, Jeffrey.