At 07:06 AM 3/9/2011 -0500, Jim Fulton wrote:

They certainly aren't "projects" in any sense that most people would understand.

I don't follow you. Sourceforge hosts projects. Freshmeat indexes projects. Mozdev.org hosts projects. The Apache Foundation hosts projects. "Project", IOW, is *exactly* the word people use for these things, in the larger world of software, and that's precisely why I chose it for my original terminology proposal. Many PyPI listings also only describe a project, in the sense that there is no release information at all, or the code is only available via a revision control system, etc.

The term "project" has has never stuck, despite being discussed repeatedly.

It's only been discussed here, on this list. It hasn't been put in official documentation, or really blessed by anybody. When it has been discussed, it's been considered a reasonable name, and when people have needed to make the distinction, they've tended to use it. The primary reason it hasn't caught on in a larger sense is that people don't know about it, and have no motivation to learn it unless they end up in a situation where the distinction makes a difference... And let's face it, it really only makes a difference if you are creating some kind of packaging or distribution tool, or if you have a corner case of using one.

I think given the historical use of the term "package" it was reasonable to find another term. OK, we tried. It didn't work.

I don't think that's an accurate assessment on two points. First, "we" didn't try -- *I* did. (It's possible that someone else has promoted it, but I don't recall any instances of that.) So, there actually being a "we" behind it -- where "we" includes an approved PEP, documentation, etc., would be helpful. Second, I don't think it's accurate to say "it didn't work". It's not like people who need the distinction have objected to the word or proposed any alternatives.

We can pretent that if we work hard enough, we can make people adopt our confusing terminology. Good luck with that.

No matter which way we go (assuming there aren't any other alternatives), we will be trying to get some group of people to change their terminology. I'm just pointing out that the group that would need to change to use "project" is both smaller *and* inherently more motivated to change their usage, than the group that would need to replace "package" with "module". Thus, if getting people to use "project" is an uphill battle, getting people to stop using "package" is going to be a much higher vertical cliff. ;-) For one thing, if the distutils documentation simply starts out like: "If you want to distribute your work to the larger Python community, you need to create a project for it. In practical terms, this means having a directory with a setup.py and the code, data, or documentation you wish to distribute. Your project will also need a unique name, if you want to make it accessible to others via the Python Project Index (PyPI)." (replace setup.py w/setup.cfg for distutils2, of course) This usage of project also maps onto common IDE usage of the term project -- a directory of stuff that you're going to edit and build. And, it immediately introduces the term to a superset of the audience that will need to know it. Having PyPI describe its contents as "projects" is pretty much the other half of the indoctrination needed. In contrast, to make the package->module change, you'd have to not only change the official language reference and tutorial, but also every third-party book or tutorial about Python. Sure, some of those third party references would also exist for "package" as "project", but that's simply an *imprecise* usage, rather than an *incorrect* one.