To most non-programmers, JohnSmith, john_smith and JOHN_SMITH all denote the same person. As programmers, we unlearn this identity to make them different. When looking up a name, XL ignores case and separating underscore '_' characters (two consecutive underscores are not allowed).// There is only one 'file' and one 'open_file' below function OpenFile(string Name, Mode) return file FILE F := open_file("foo.dat", "r")
On the other hand, name overloading allows you to reuse the same name for different entities when the name will not be used in the same context.type rectangle function Rectangle(integer X, Y, Width, Height) return rectangle rectangle Rectangle := Rectangle(10, 10, 20, 20)
In addition, XL, like any Mozart-based language, requires a renderer, which can be used to present code to programmers with their preferred style.
Why? Style preferences cause religious reaction from many otherwise reasonable programmers. Style insensitivity allows reuse of libraries while maintaining a consistent style in your own code.
Cons: Entities that would be distinguished by case in the real world can no longer be distinguished this way. For instance, V for volume and v for speed in physics. This is common and reasonable practice.
An interesting idea, indeed. Python's lack of a naming style annoys me a great deal -- I'd be happy to use any naming style, if there were any reason to pick one over the other. Even the standard library has nothing approaching a standard naming style (there's even capitalized method names).
But there is no reason to pick one over the other. The only standard we have is CamelCase class names, and (except for the very occasional exception) method names start with lower case letters. After that all bets are off.
Anyway, style insensitivity seems like a cool way to deal with it. Maybe it would be annoying if there wasn't contextual names (like the in the rectangle example). But maybe not so bad either.
To me it seems consistent enough, if I look to PHP, but for inside project more consistency would be better.
I would like underscored_module_names for readability. No UpperCaseModuleNames becouse of different filesystems.
ClassNames are still CamelCase and functionsAndMethods start with lower case letter.
And probably it all makes more sense if we consider that in Python there are lots of C wraps, together with names and influences.
Do you see any major problem there?
Hmmm... yes, interacting with case sensitive code would be a problem. Many interfaces fix C naming weirdness (except for thin wrappers like expat -- but expat itself can be wrapped with a normal Python SAX interface). Anyway, it's easier to fix that naming in Python, but it would be hard if the system was case- and underscore-insignificant, because we couldn't even express the different naming schemes (and most insensitivity uses folding, not real insensitivity, and that's hard to calculate in an external interface).# Ian Bicking
There's somewhat of a style, or at least a style that's been growing in recent years. A lot of Python's standard library is old, and has been written by many individuals.
The style that I'm seeing, and is advocated in Guido's style guide, is to keep package and module names lower case, which I like. Zope 2 has the terrible example 'DateTime.DateTime.DateTime', and I think that in the __init__.py of the DateTime package, there is (or was) a 'from DateTime import DateTime'
Zope 3, Twisted, and Docutils all use the lowered path/module style, and I find that makes them a lot easier to navigate and to use as a developer, because it's much easier to follow an import statement to a source file.
As for underscored module names - I think it's better to structure packages and modules so that module names are short but still meaningful. 'zope.security' is better than 'zope_security'.
As for enforcing anything - I still like that Python doesn't enforce anything, or put any magic on inferring meaning from spelling/capitalization. Ruby, if I remember correctly, turns anything that's ALL_CAPS into a constant. I like to use that as a guide, but not a rule (some constants tent not to be so constant ;).
The guides used now for modules and packages to be accepted into Python are: