Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
What does "namespace" mean?
A well-known easter egg in Python displays some ideas about writing good Python code, credited to Tim Peters (one of the core developers). This question is about the last:
Namespaces are one honking great idea -- let's do more of those!
It seems that the concept of a "namespace" appears in programming generally, not just in Python. Presumably this concept is important, given its inclusion here. However, it's hard to pin down a clear definition simply from considering its use in context. For example, I have seen a class SimpleNamespace in the Python standard library; but it seems like the term is also used to describe things that are not actually objects in a program at runtime at all.
What exactly is a "namespace"? Does it refer to one specific concept that has particular properties regardless of the programming language? Or else how exactly should I understand it?
2 answers
A namespace is a category to which a name can belong. Think of family names for people: I may be friends with several Jims, and if only one of them is present I can just call him Jim. But if multiple are present, I can disambiguate which I mean by saying Jim Jones or Jim Smith. ‘Jones’ and ‘Smith’ are namespaces which can both contain the name ‘Jim’, and thanks to them the name ‘Jim’ can be used by two different people without ambiguity.
In programming languages, sometimes types, variables, functions, labels (thing you can goto), struct fields, etc. all belong to distinct namespaces—if I write foo(a, b);, a compiler or interpreter might know to look for foo in the function namespace and ignore any variables or types that are also named foo. Python doesn't do this; variables and functions (and types, when using type annotations) are all looked up in the same namespace.
Programming languages also often have a concept of a ‘module’ or a ‘package’, which is another way to create namespaces. Python does have these, of course; I can define a function foo in module wibble, and you can define a function foo in module babble, and a user can disambiguate them by importing the modules and writing wibble.foo or babble.foo.
This is not an exhaustive classification; other types of namespaces are possible, but these are two of the most common.
A namespace may or may not have a run-time representation. Python modules do, but the term/type/etc. namespaces in languages like C and Haskell don't, nor do the module-like namespaces in Java and C#. As an abstract concept, the only important quality of a namespace is the ability to use the same name to mean different things in different contexts without ambiguity.
0 comment threads
A namespace is a category of names within which they must all be unique. This also means that names do not need to be unique between namespaces.
For example, states of the USA is a different namespace from countries of the world. "Georgia" has a completely different meaning in these two namespaces. That also requires that whenever the name "Georgia" is used, the namespace must be specified. In natural languages it is often inferred from context. Consider the two sentences "I visited Florida, Georgia, and South Carolina." and "I visited Turkey, Georgia, and Armenia.". In the first case, I could have visited the US states for Florida and South Carolina and the country of Georgia, but we expect the writer of the sentence to more explicitly tell us of the namespace change if that were the case.
In formal languages, like used for programming computers, we can't allow such ambiguity. We therefore have strict rules for interpreting names of things like variables and subroutines. For example, in many languages variable names are in a separate namespace per subroutine. The variable count in subroutine abc is different from the variable count in subroutine def. This is quite useful because the writers of the two subroutines don't have to check every other subroutine to make sure count isn't already used somewhere.
This concept is also commonly referred to as the "scope" of a name. The scopes of the two count variables is only within their respective subroutines.
In computer programming, namespaces are usually tree structured. If both subroutines are in the same module, and a variable count was defined at module-scope above all the subroutines, then just count in each subroutine would reference the single variable in the module namespace.
Different languages vary whether it is allowed to then create a count additionally in a subroutine, and what an unqualified reference to count in that subroutine would mean. In most cases, unqualified references are interpreted as being in the most local namespace. count in the subroutine would therefore refer to the local variable, not the module-level variable. It depends on the language how the module-level count is specified, and whether that's even possible at all.
0 comment threads
0 comment threads