Re: [Pyx-devel] design/arg.tex

[Joerg L. <jo...@us...>]

On 25.02.02, Andre Wobst wrote:
> Hi,
>=20
> On 25.02.02, Joerg Lehmann wrote:
> > > On 24.02.02, Andre Wobst posted a comment of Joerg Lehmann:
> > > import types
> > >=20
> > > def show(text, *args):
> > >     if type(text) =3D=3D types.TupleType:
> > >         show(text[0], *(args + text[1:]))
>                             ^---- ordering
> > >         return
> > >     for arg in args:
> > >         print arg
> > >     print text
> > >     for arg in args:
> > >         print "</>"
> > >=20
>=20
> I think, the ordering is quite natural --- not a problem at all. In
> the case (as above) where the parameters do fullfill a stack like
> behavior, you just have to apply the most inside arguments last
> (closest to text in the example above). They are somehow strongest
> bound to the text. So there is some very intrinsic logic behind it.

Fair enough.

> I think, we do *not* mix arglist and argdicts here. And I'll add
> another example in order to clearify my problems (show may be defined
> as above):
>=20
> def showtitle(title =3D "some default", subtitle =3D "some default"):
>     show(title, A("red"))
>     show(subtitle)
>=20
> We can do now:
>=20
> showtitle("text")
> showtitle(title =3D "text")
> showtitle(title =3D "text1", subtitle =3D "text2")
> showtitle(title =3D ("text1", A("blue")), subtitle =3D "text2")

So you have to A("Blue") and A("red") for title, where the second one
overrides the first one, which should presumably be the default? But
the output corresponding to such a solution wouldn't be very nice,
would it?

> showtitle(title =3D "text1", subtitle =3D ("text2", A("green")))

> Both, title and subtitle could have some attribute of class A. You
> can't distinguish it without tighten this attribute to title itself.
> (Please don't come up with some way getting this out of the ordering
> of the arguments.) So title and subtitle themself are just argdict
> arguments, but they *themself* are arglists. They can get parameters
> exactly like the show routine itself. At the same time, showtitle can
> easily provide default attributes to a title (like the color red in
> the examle). To my eyes, this technique is very transparent for both
> developers and users.

Ok, this is certainly an advantage of such an approach (but see my
comment above), though it is not perfectly object oriented. Maybe, we nee=
d=20
compound objects, which glue together some text or path with style proper=
ties.=20
I already though about something like this for paths. But this is just an=
 idea.

> > > Arrows are a different topic, I would guess. They do have something=
 to
> > > do with paths. I'm not quite sure, if they are attributes of paths =
or
> > > what else we should do about it ...
> >=20
> > I thought a little about that, but now it seems clear to me, that
> > arrows are attributes of paths _during_ the drawing on the canvas.
> > For instance, we need to know something about the current linewidth i=
n
> > order to be able to draw reasonable arrows.
>=20
> That sounds good. This would mean, a draw attribute can actually do
> more than just add some postscript in front the draw. We should get
> some technique into the draw routine, which allows for that (e.g.
> the arrow attribute has to get the path to be drawn somehow). I think,
> we can do that somehow. But this will need some thoughts ...

Yes, but we need something like that.

>=20
> > Indeed. We should pull this out of tex.py. And in my opinion, we
> > should extend this routine to a point, where things like
> >=20
> >         canvas(unit.unit())
> > and
> >         canvas(unit=3Dunit.unit())
> > are equivalent.=20
>=20
> Let's first (at least try to) clean up our minds about that mixturing.
>=20
> > > ...
> > > titleaxis(genpart(opt =3D 10), title =3D "", min =3D 1) # doesn't w=
ork ...
> > > titleaxis(title =3D "", genpart(opt =3D 10), min =3D 1) # doesn't w=
ork ... either
> > > ...
> >=20
> > Why don't we just use
> >=20
> >         self.title =3D dict.get("title", "")
> >=20
> > and don't ever specify the parameters explicitly in the function
> > definition.
>=20
> You're right that this would be a solution. But do we really want to
> give up the standard way of having default arguments? We could never

Isn't this a standard way? I saw it many time before.

> write define axis.__init__(self, min =3D None, max =3D None) anymore.
> Instead, we would get a much less convenient way of writing
> parameters. And another crutial thing. What happens if somebody
> misspells title in his parameter list ... he would never get any
> warning about writing tilte ... the value of the parameter would just
> be ignored.

Concerning your last point: this could be avoided if we track the use=20
of all parameter names. If there is eventually some parameter left, we
could throw an exception...
But I still think, that such a solution could be automated very well,
and therefore it would be possible.


> I do claim, that we should not rewrite the hole argument handling by
> ourselfs. The solution you suggest does that.

Right, but see previous sentence.

        J=F6rg