[Python-ideas] Delay evaluation of annotations

[Neil Girdhar]

On Tue, Sep 27, 2016 at 5:01 AM Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 27 September 2016 at 17:29, Neil Girdhar <mistersheik at gmail.com> wrote:
> > On Friday, September 23, 2016 at 2:23:58 AM UTC-4, Nick Coghlan wrote:
> >> The difference between that and the "methods referring to the class
> >> they're defined in" case is that it's likely to be pretty normal to
> >> want to do the latter, so it may prove worthwhile to provide a cleaner
> >> standard spelling for it. The counter-argument is the general
> >> circularity one above: do you *really* need instances of the
> >> particular class being defined? Or is there a more permissive
> >> interface based type signature you could specify instead? Or perhaps
> >> no type signature at all, and let ducktyping sort it out implicitly at
> >> runtime?
> >
> > I agree that circularity should in general be avoided, but it's not
> always
> > possible or elegant to do that.  Sometimes you really need two classes to
> > refer to each other. In that case, why not expose your placeholder idea
> to
> > the user via a library? You have one function that generates placeholder
> > singletons (generate_placeholder()), and another function to walks a
> class
> > object and replaces a placeholder with a given value
> > (replace_placeholder(placeholder, cls, value)).
>
> Because the general case is already covered by using a quoted string
> instead of a name reference. "I don't like using strings to denote
> delayed evaluation" isn't a compelling argument, which is why
> alternative ideas have to offer some other significant benefit, or
> else be incredibly simple both to implement and to explain.
>

My motivation for something other than quoted strings is that there are
other instances of circular dependencies.  Currently, when I am forced into
a circular dependency, I import the later class in the member functions of
the first:

# module x
class X:
    def f(self):
        from y import Y
        # do something with Y

# module y
class Y:
    pass

That's not ideal and I don't see how to extend this solution to use of "y"
in class level definitions.

Best,

Neil


> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160927/4c16e79e/attachment.html>