>> Regardless, all use cases you've listed are already satisfied by use of >> the static and class method decorators. Methods decorated with these do >> not require an instance initialization to use.
> And are significantly less easy to use, as the functions MUST refer to each > other by their dotted names. My response to this may come off as a bit glib, but it isn't intended that way. If the problem with using classes to satisfy the namespace need is that it's unwieldy to use dot qualified paths then isn't that quite similar to saying namespaces are unwieldy? Leveraging classes as a nested module creates a de-facto internal namespace of "cls" for self reference and I'm unsure of why that is unwanted but "module.namespace.blah" is wanted. I suppose my issue is not so much that namespace objects are a bad idea as that the proposal does little to express why the existing tools are deficient enough to require a new concept. > For the proponents of namespace, what is deficient in the above example > that necessitates a language change? >> It's not a language change. Perhaps. My argument is that anything that introduces a new class-like construct and set of lexical scoping rules is a language change. For example, if this change went into 2.7.13 would Jython suddenly be broken because it hasn't implemented the new scoping rules? >> IIRC, classes came about as a "module in a module". > I'm pretty sure they did not. Object oriented programming (and hence > classes) came about from simulating real world objects, hence the > name: I realize my statement was ambiguous. I didn't mean to suggest that classes, as an idea and OOP tool, were derived from the concept of a namespace. I meant to say that the Python implementation of classes is quite similar to the implementation of modules in the cPython code. The commit messages from the earlier days (ref: ab5db02) don't carry much detail so I'm mostly basing my belief of the implementation similarities and anecdotes from the community. Right or wrong, I don't believe it has much weight in the namespace discussion and I shouldn't have brought it up. On Sun, Jul 3, 2016, 00:17 Ethan Furman <et...@stoneleaf.us> wrote: > On 07/02/2016 08:44 PM, Steven D'Aprano wrote: > > > Try getting this behaviour from within a class: > > > > > > class Food(metaclass=Namespace): > > > > # (1) no special decorators required > > def spam(n): > > return ' '.join(['spam']*n) > > > > # (2) can call functions from inside the namespace > > breakfast = spam(5) > > > > # (3) no "cls" or "self" argument > > def lunch(): > > # (4) can access variables using their undotted name > > return breakfast + ' and eggs' > > > > def supper(): > > # (5) likewise functions (a special case of #4) > > return lunch() + ' and a fried slice of spam' > > > > def mutate(n): > > # global inside the namespace refers to the namespace, > > # not the surrounding module > > global breakfast > > breakfast = spam(5) > > > Can you do all of that with an ordinary class? > > You can get #2 already, but not the rest (without your spiffy code ;) : > > Python 3.5.1+ (3.5:f840608f79da, Apr 14 2016, 12:29:06) > [GCC 4.8.2] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> class Huh: > ... def blah(text): > ... print('blah blah %s blah blah blah' % text) > ... blah('whatever') > ... > blah blah whatever blah blah blah > > -- > ~Ethan~ > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list