I've read the proposal, and this thread.

Questions:

1. It seems that I could get close to what you're aiming for by just
using underscores in names, and grouping them together in the class
definition. Is there any advantage to declaring methods in a namespace
beyond indentation and the dot notation?

2. If __dict__ contains "B.C" and "B", then presumably the interpreter
would need to try combinations against the outer __dict__ as well as B.
Is the namespace proxy you've mentioned intended to prevent further
lookup in the "B" attribute?

3. Can namespaces be nested? If so, will their attributed they always
resolve to flat set of attributes in the encapsulating class?

4. What would you expect getattr("A.B", "C") to yield?

Paul

On Mon, 2021-05-03 at 19:49 +0100, Stestagg wrote:
> The first example in the doc lays out the difference:
> 
> Assignments within the namespace block have this special behaviour
> whereby the assigned-to name is changed to be:
> ‘<namespace name>.<assignment name>’
> And the assignment is made in the ‘parent scope’ of the namespace.
> 
> I.e. (again, as described in the doc):
> 
> class A:
>     Namespace B:
>         C = 1
> 
> Results in:
> 
> A.__dict__ == {‘B.C’: 1, ‘B’: <namespace proxy>}
> 
> Note the ‘B.C’ entry
> 
> Now for me, the only place where is starts to be interesting is with
> methods within namespaces, where the ‘self’ binding is made against
> to top-level class, and not against the namespace.  This does make
> for some nicer nested API definitions (a-la pandas DataFrame.str.xxx
> methods) where an intermediate name os used just to group and
> organise methods.
> 
> 
> 
> On Mon, 3 May 2021 at 19:40, David Mertz <me...@gnosis.cx> wrote:
> > On Mon, May 3, 2021 at 6:37 PM Stestagg <stest...@gmail.com> wrote:
> > > On Mon, 3 May 2021 at 19:24, David Mertz <me...@gnosis.cx> wrote:
> > > > So yes... as I thought, SimpleNamespace does EVERYTHING
> > > > described by the proposal, just without needing more keywords:
> > > > 
> > > 
> > > 
> > > Except that the code and description of the proposal explicitly
> > > outline behaviours that SimpleNamespace does not provide (and
> > > aren’t trivially possible to add)
> > > 
> > 
> > 
> > I've looked and been unable to find an example of that. Can you
> > show one?
> > 
> > 
> > 
> > _______________________________________________
> > 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/YTARLBP3TIARJ4FUEPPDZAUIS33P2C3Q/
> > Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________
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/UAZBIPDC3DRSA5A2GST72KDO2Y2R6RBX/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to