Correction:
4. What would you expect getattr(A.B, "C") to yield?
Paul
On Mon, 2021-05-03 at 12:10 -0700, Paul Bryan wrote:
> 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 <[email protected]> wrote:
> > > On Mon, May 3, 2021 at 6:37 PM Stestagg <[email protected]>
> > > wrote:
> > > > On Mon, 3 May 2021 at 19:24, David Mertz <[email protected]>
> > > > 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 -- [email protected]
> > > To unsubscribe send an email to [email protected]
> > > https://mail.python.org/mailman3/lists/python-ideas.python.org/
> > > Message archived at
> > >
> > https://mail.python.org/archives/list/[email protected]/message/YTARLBP3TIARJ4FUEPPDZAUIS33P2C3Q/
> > > Code of Conduct: http://python.org/psf/codeofconduct/
>
> _______________________________________________
> Python-ideas mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/UAZBIPDC3DRSA5A2GST72KDO2Y2R6RBX/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/Q2OTIBAPH7GUBAMKOY3DF3HZWQI4OZMO/
Code of Conduct: http://python.org/psf/codeofconduct/
