Jonathan Wiltshire <debian@jwiltshire.org.uk> writes: > In lib* libraries, we (usually) have SONAMEs which provide some kind > of contract between the .so and the consuming application. Is there an > equivalent practice in pure Python modules that is implemented widely > enough to be useful? The convention in Python is that any name in a namespace is public, unless it is named with a single leading underscore. So there are three kinds of name to be aware of regarding this: * ‘__foo_bar__’ is a reserved-for-use-by-Python name, but the attribute is public nevertheless * ‘_foo_bar’ (single leading underscore on any name) is a name for an internal-to-implementation attribute * ‘foo_bar’ (any other name) is a name for an available-for-public-use attribute In other words, all attributes are public by default, and there is a naming convention (called the “weak "internal use" indicator” in PEP 8 <URL:http://python.org/dev/peps/pep-0008/>) for indicating an attribute not part of the public API. That said, I think you are correct in your observation that there is less adherence in the Python community to the practice of preserving a stable API of such public attributes over the lifetime of the code. The Python standard library adheres to that practice reasonably well, but that often doesn't carry over to the third-party libraries. -- \ “Creativity can be a social contribution, but only in so far as | `\ society is free to use the results.” —Richard Stallman | _o__) | Ben Finney
Attachment:
pgpdsuVabnrUk.pgp
Description: PGP signature