On 12/29/05, Ka-Ping Yee <python-dev at zesty.ca> wrote: > In a fair number of cases, Python doesn't follow its own recommended > naming conventions. Changing these things would break backward > compatibility, so they are out of the question for Python 2.*, but > it would be nice to keep these in mind for Python 3K. > > Constants in all caps: > NONE, TRUE, FALSE, ELLIPSIS > > Classes in initial-caps: > Object, Int, Float, Str, Unicode, Set, List, Tuple, Dict, > and lots of classes in the standard library, e.g. > anydbm.error, csv.excel, imaplib.error, mutex.mutex... > > I know these probably look a little funny now to most of us, Oh yeah. =) > as > we're used to looking at today's Python (they even look a little > funny to me) but i'm pretty convinced that consistency will be > better in the long run. > Well, the problem is obviously requiring existing Python coders to have to re-educate themselves and the amount of code breakage. Luckily stuff like this should be changeable by some script that can try to convert 2.x code to 3.0 code. I am fine with changing the built-in types, but changing the built-in singletons just looks *really* odd to me. So odd that I just don't want to see them changed. I mean when I think of constants, I think of a variable that references an object and that reference never changes. The built-ins you are referencing, though, are singletons: named objects that are not variables. So keeping their naming scheme as-is does not feel like a breaking of the rules to me since they are not treated the same (especially at the C level). -Brett
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4