[Python-ideas] Object grabbing

Joshua Morton joshua.morton13 at gmail.com
Sun May 1 21:32:50 EDT 2016


To be fair the second problem you mention already exists with nested
functions:

def example(x):
    print(x)
    def inner(x):
        print(x)

suffers from exactly the same issues as the proposed example. Admittedly,
the case you give is much, much less explicit since the attributes are
given in the function call example but not with the attribute access one.

My thoughts on this syntax would be to add a special object to the standard
library, that uses the existing `with` syntax. Take this as an example:

    import math
    with Namespace(math):
        print(pi**2)

    import math
    with Namespace(m=math):  # alternatively `Namespace(math) as m:`
        print(m.pi**2)

    import foo, bar
    with Namespace(f=foo, b=bar):
        print(f.spam)
        print(b.spam)

    import math, pprint
    with Namespace(math, pprint):
        pprint(pi**2)

With all of these modifying locals within the context manager. I assume
that currently this could be done with some AST rewriting, but a clean
standard implementation would be perhaps nice.

There are some obvious problems: name conflicts could through an error, but
that then leads to really ugly nested code or kludgy workarounds. I'm not
sure of good solutions to those, but I'm a +1 if that matters, assuming
those can be solved.

--Josh

On Sun, May 1, 2016 at 9:07 PM Steven D'Aprano <steve at pearwood.info> wrote:

> Hello Robert, and welcome,
>
> On Sun, May 01, 2016 at 10:27:04PM +0200, Robert van Geel wrote:
> [...]
> > The idea is to be able to write this code:
> >
> > myobject.a
> > myobject.b
> > myobject.c()
> > myobject.d = 1
> >
> > like this:
> >
> > using myobject:
> >     .a
> >     .b
> >     .c()
> >     .d = 1
>
> I think this is closely related to the Pascal "with" statement, which has
> a FAQ:
>
>
> https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments
>
> You require a leading dot to access attribute names, which avoids the
> ambiguity between attributes and variables, but it also fails the "new
> syntax shouldn't look like grit on Tim's monitor" test.
>
> using myobject:
>     .method(.eggs + (.spam or ham) - tomato - .cheese)
>
>
> All of these proposals raise the question, what do you do with nested
> blocks?
>
> using myobject:
>     print(.attr)
>     using yourobject:
>         print(.attr)
>
>
> Obviously in the outer block, ".attr" refers to myobject. My guess is
> that inside the inner block, it refers to yourobject. What happens if
> you want to refer to both? Would we have to write this?
>
> using myobject:
>     print(.attr)  # myobject
>     using yourobject:
>         print(.attr)  # yourobject
>         print(myobject.attr)  # be explicit
>
>
> Now imagine that you are a beginner, trying to understand this code
> block. What would you think it does? Might you not be surprised that
> the two references to ".attr" refer to different variables?
>
> And of course there is always the objection that the barrier to adding a
> new keyword is quite high. Somewhere out there, somebody is using
> "using" as a variable name (perhaps a decorator?) and making this a
> keyword will break her code. Is it worth it?
>
>
> Despite these objections, I'm cautiously interested in this. I don't
> think the objections are insurmountable, and if there is a significant
> gain in readability and performance, it may be worth while.
>
> A cautious and tentative +1.
>
> It may be worth you doing a survey of other languages and seeing if they
> have anything similar.
>
>
> --
> Steve
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160502/4b109197/attachment.html>


More information about the Python-ideas mailing list