Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental brace.py,NONE,1.1

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

Hi André,

On 31.08.05, Andre Wobst wrote:
> I was always thinking about braces to be somehow related to connectors
> and/or decorators. But neigher connectors nor decorators fit very
> well. Instead, in the first, they are path "constructors". A
> brace-function seems absolutely natural. I have to repeat myself: +1

Exactly. Don't be to focused on decorators and this whole stuff. It's a
good framework and terminology for some things but definitely not for
everything.

> > We could then create a new package
> > (for instance "paths", but I'm sure there is a better name, "elements"
> > also came to my mind) which contains only modules generating paths. In
> > principle, already a simple circle or a line would belong there, but I'm
> > not sure whether we want something like:
> > 
> >         paths.circle.circle(1, 2, 3)
> >         paths.line.line(1, 2, 3, 4)
> > 
> > One could also think about grouping stuff together
> > 
> >         paths.basic.circle(1, 2, 3)
> >         paths.basic.line(1, 2, 3, 4)
> > 
> > Then we could also say that all stuff from the basic package is so
> > important that we inject it in the paths namespace:
> > 
> >         paths.circle(1, 2, 3)
> >         paths.line(1, 2, 3, 4)
> > 
> > Actually, I think this is not too bad, is it?
> 
> Interesting. But it looks a bit overdesigned. Should paths become a
> subdirectory? How is this subdirectory related to the path (normpath)
> module(s)? Do we except such a huge number of path creating functions
> having that much code? Get's something like a -0.5 from me ...

Ok, but if we move the connectors there (which makes a lot of sense) and
have braces there as well, we certainly don't want to put everything
into one file.

> I would suggest to split the path module into path, paths and
> normpath (the later is quite unimportant to the user, it should not
> even be imported by "from pyx import *").

Of course.

> > Btw, André, if we are about to split path anyway (in order to separate
> > normpath out), we could also think about doing things like this at the
> > same time.
> 
> BTW I've already started to rework the pathitem signature. It seems to
> work very well and leads to very clean and readable code (overall it
> becomes less code and faster code as well). However, I'm not yet
> finished (pdf is not working ... I want to allow for epsilon=None to
> be used in that case), but I guess I can easily finish it tonight.
> It's not really related to this discussion, but I could easily split
> of the normpath (a regular user should not even notice this) ... and
> create a paths module at the very same time. Do we already have a
> consensus (otherwise this splitting can wait ... as I said, its not
> really related).

Let's first do one thing and split later.

        Jörg