grackle <[EMAIL PROTECTED]> writes: > I do use packages. I mentioned the Java naming conventions because > they were my first thought for solving the problem of name clashes, > and they work well in some non-Java languages. They don't apply well > to Python, since every top-level module has a unique identity that > can only be specified on one source path. If two libraries use the > same top-level module name, they can't be used together in the same > program without modifying their source code.
What do you mean by "top-level module", and "the same top-level name"? Do you mean "the same fully-qualified name"? If two modules are in separate places in the hierarchy, they will have different fully-qualified names. ===== $ find foo/ -name '*.py' foo/__init__.py foo/spam.py foo/bar/__init__.py foo/bar/spam.py foo/baz/__init__.py foo/baz/spam.py ===== ===== eggs.py ===== import foo.spam import foo.bar.spam import foo.baz.spam # ... ===== > mycompany_mymodulename was just the first solution I thought of that > seemed practical. The mycompany_ prefix protects me from name clashes > with useful modules I might acquire from elsewhere. Ah, I see; you're referring to a worldwide package namespace, enforced by the language. AFAIK there's no such thing in Python. > Of course, the best convention is probably the predominant one, and > that's my question: What is the standard way of naming Python > packages? Release your package as free software on the Cheeseshop <URL:http://cheeseshop.python.org/>. If the name you want is already taken, pick one that will help users distinguish yours from the existing one. -- \ "If you do not trust the source do not use this program." | `\ —Microsoft Vista security dialogue | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
