On Tue, May 25, 2021 at 11:37:06AM -0400, David Mertz wrote: > We've already had all of this since long before typing.py existed. > > ALLCAPS means "this value should only be set once and not changed."
`math.pi` says hello. The existence of math.pi and the fact that probably nobody ever has introduced a bug into their code by carelessly assigning another value to it suggests strongly that the benefit of language enforced constants is not high. But then on the other hand, who would ever want to change the value of pi? > _underscore means "this is not part of public API, and it may change in > next version. Namedtuple and the sys module also say hello. Namedtuple reserves single underscore names to itself, since any regular name could be a field name. So namedtuples have five public APIs starting with underscores. https://docs.python.org/3/library/collections.html#collections.namedtuple The sys module has numerous documented and apparently public functions starting with underscores, apparently to indicate that they are, or may be, implementation-dependent, or "internal and specialized purposes only", or for no given reason at all. https://docs.python.org/3/library/sys.html The naming conventions in the sys module are very inconsistent. Other functions that are clearly implementation-dependent have regular names, and some underscore names are in common use. E.g. _getframe. > __double_under means "this is SERIOUSLY not something you should muck with, > it's likely to break stuff if you do." That's a convention I've never heard of before. What's the difference between "private" and "SERIOUSLY private, I REALLY mean it"? The convention I know for double-underscores is that *in classes only* a name with a leading double-underscore is name-mangled in order to avoid naming conflicts with subclasses. Its not really more private than single-underscore names because it is transformed into a single- underscore name: __spam --> _classname__spam > Python should never become a B&D language like Java. If a user violates the > contracts provided by code they utilize, that's on them, not on the > language. Python is not really a design by contract language. Types are strongly checked, at runtime, and you can't turn that off. We have no syntactic support for contracts. A few third-party libraries have attempted to provide pre- and post-condition checking, but without syntactic support they are awkward to use. Its hard to blame people for violating a contract that they don't know applies, isn't an actual contract, and isn't enforced. The problem with naming conventions is that not everyone knows the conventions. Not every Python programmer spends hours every day on Python forums, reading Stackoverflow, etc. What you call "a B&D language like Java", other people might call "safety rails and warning lights". -- Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FNOIQFNJODYOPLH472VIBBP7TLPKR6ZD/ Code of Conduct: http://python.org/psf/codeofconduct/
