On Tue, Sep 27, 2016 at 5:01 AM Nick Coghlan <ncogh...@gmail.com> wrote:
> On 27 September 2016 at 17:29, Neil Girdhar <mistersh...@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 | ncogh...@gmail.com | Brisbane, Australia
>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
