RE: [Crew] Wizards' Resolution to Zope/PIL/mxDateTime conflict?

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.
I am sending a copy of this over there... Be Seeing You, Jeffrey.

Jeffrey C. Jacobs writes:
Too much bureaucracy; won't fly. Either Java's org.python.core arrangement will have to be used, or some other automatic disambiguation method will have to be used; intervention of an outside committee isn't acceptable, because then I can't name anything without contacting them. -- A.M. Kuchling http://starship.python.net/crew/amk/ Nothing I've ever written has reached 1.0. -- Greg Ward at IPC7, on using small version numbers

[Charset iso-8859-1 unsupported, filtering to ASCII...]
[Other discussion snipped]
Be Seeing You,
Jeffrey.
Jeffrey, there is already a service for this, Guido set it up some time ago: go to http://www.python.org/search/ and select the link "The Python module registry at NIST". This service needs more press and perhaps more "peer pressure" from module authors. -Arcege

Jeffrey C. Jacobs writes:
Too much bureaucracy; won't fly. Either Java's org.python.core arrangement will have to be used, or some other automatic disambiguation method will have to be used; intervention of an outside committee isn't acceptable, because then I can't name anything without contacting them. -- A.M. Kuchling http://starship.python.net/crew/amk/ Nothing I've ever written has reached 1.0. -- Greg Ward at IPC7, on using small version numbers

[Charset iso-8859-1 unsupported, filtering to ASCII...]
[Other discussion snipped]
Be Seeing You,
Jeffrey.
Jeffrey, there is already a service for this, Guido set it up some time ago: go to http://www.python.org/search/ and select the link "The Python module registry at NIST". This service needs more press and perhaps more "peer pressure" from module authors. -Arcege
participants (3)
-
Andrew M. Kuchling
-
Jeffrey C. Jacobs
-
Michael P. Reilly