From: "Samuele Pedroni" <pedroni@inf.ethz.ch>
> the question was whether
> adding a method to a gf
> is always the moral equivalent of
>
> lib.py:
>
> class A:
> def meth(self,...): ...
>
> class B(A): ...
>
> class C(B):
> def meth(self,...): ...
>
> abusive_user.py:
>
> from lib import A
>
> def foo(...): ...
>
> A.meth=foo
And the answer is, "clearly not always".
> > Well, I still don't get it. I clearly don't know what "fiddling"
means,
> > since any added signature can change the behavior of the multimethod. I
> > think I would be inclined to forbid your first case, where you're
adding a
> > multimethod implementation whose signature exactly matches another one
> > > that's already in the multimethod.
>
> The point is whether the behavior is changed in an undetected way
> with respect to sets of arguments for which some matching signature/
> method is already defined. So my conditions
>
> add(M,(h,T3)) with T3==T2 (*) or T1<T3<T2.
> (assuming that T3==T2 triggers substitution) .
>
> [T3==T2 case corresponds to the above
>
> A.meth = foo
I hope you are covering this case just for generality's sake. It's easy
enough to forbid.
> T1<T3<T2 correspond to the single dispatch case:
>
> from lib import B
>
> B.meth=... ]
I don't understand why you're using such a complicated condition; you can
change the behavior "in an undetected way WRT sets of arguments for which
some matching signature/method is already defined" simply by adding a
signature T4 s.t. T4 < X for some X in the signatures of the multimethod.
> If T3 is < or uncomparable with all the signatures
> already in M:
> - you are doing the moral equivalent of overriding
> in the single dispatch case
Sort of. You might not be the same person that supplies the types in T3.
> - or you are defining the gf for some unrelated
> class hierarchies
Yep.
> - or some case that was unambiguous
> will become ambiguous and the outcome
> will depend on the rules you choose to
> deal with ambiguity (which is a general
> problem with multidispatching).
Yep.
> > > [Btw up to (*), missing a module or calling
> > > a generic function before all modules are loaded,
> > > load order does not count.]
> > The above sentence is completely incomprehensible to me.
>
> Dispatching outcomes are invariant wrt
> the order by which you add gf-methods to a gf.
It depends on your dispatching rules, of course. However, I'd like to pick
order-independent rules.
> > > See my posted code for the idea of redispatching
> > > on forced types, which seems to me reasonably Pythonic
> > > and allows OTOH to choose a very strict approach
> > > in face of ambiguity because there's anyway a user
> > > controllable escape.
> >
> > Could you please explain your scheme in plain English?
> > What is a "forced type"?
>
> the idea is to allow optionally to specify together
> with an argument a supertype of the argument and to have
> the dispatching mechanism use the supertype instead
> of the type of the argument for dispatching:
>
> gf(a,b,_redispatch=(None,SuperTypeOf_b))
>
> the dispatch mechanism will consider the
> tuple (type(a),SuperTypeOf_b) instead
> of (type(a),type(b)) for dispatching.
More "sugarily:"
gf(a, dispatch_as(b, SuperTypeOf_b))
Interesting. Not sure how I feel about this.
> This is the moral equivalent of
> single dispatching:
>
> SuperTypeOf_b.meth(b)
>
> or super(SuperTypeOf_b).meth(b)
Hmm. OK, I see the analogy. I hardly ever have to do that even in the
single case, but I get what you're up to.
> > > My opinion: left-to-right and refuse ambiguity
> > > are depending on the generic function both
> > > reasonable approaches.
>
> > I assume that "left-to-right" is some kind of precedence ordering for
> > ambiguous multimethod implementations. Can you give an example where
that
> > would be appropriate?
>
> is the default used by CLOS, that simply means that
> signature (type tuples) are compared using the lexico-order,
>
> given
> class A: pass
> class B(A): pass
>
> then (B,A)<(A,B)
>
> you get the same effect as multidispatching
> simulated through chained single dispatching.
That seems a bit arbitrary, but I guess there are other precedents in
Python for an arbitrary ordering (e.g. ordering on type names for
heterogeneous object comparison).
> > > The proposed notation or whatever should be at most
> > > just syntax sugar:
> > >
> > > (a,b,c).f(d) === f(a,b,c,d) in general.
> >
> > All notations (except really ugly ones) are syntax sugar. What point
are
> > you trying to make?
>
> what I was trying to convoy is that it would
> be bad to have multimethod invocation be a special
> operation different from the usual function invocation
> (which currently is at work also for method invocation).
Agreed.
> > It now looks like you were trying to say in 3. that multimethods
should be
> > invokable and definable in the same way as single-methods.
>
> no, I was saying that at most
>
> (a,).gf(b) should just be equivalent to gf(a,b) (*)
>
> but plain a.meth() should still mean what it means today.
>
> But honestly I find (*) unnecessary and ugly.
> I'm not even sure one can really disambiguate
> such syntax:
>
> (a,b).__contains__(2)
> (a,).__contains__(2)
>
> are valid Python.
>
> >Well, I'm not
> > sure that this elegant idea from Dylan is essential or even
neccessarily
> > good for Python. It's cute, but what does it really buy us?
>
> nothing. My point is that once we have multimethods,
> one has the choice, one can
> define classes without normal methods and just use multimethods instead,
There's the (minor?) issue of access to "private" members whose names begin
with two underscores.
> I was not advocating that C().meth() should be equivalent
> to meth(C()) in every respect and that the method definitions
> inside the class definitions should triggers gf-method
> definitions. It would be a disruptive change for Python.
>
> So we agree.
Good!
> Multidispatching functions should be an extension of the notion
> of function in Python not of class methods. OTOH
> class methods are defined by defining functions
> inside class namespaces, so it should be possible
> to get class methods also from gfs defined
> in a class namespace.
Yes, I strongly agree.
-Dave
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4