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

[Andre W. <wo...@us...>]

Hi,

On 31.08.05, Joerg Lehmann wrote:
> On 31.08.05, Michael Schindler wrote:
> > Update of /cvsroot/pyx/pyx/test/experimental
> > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv28316
> > 
> > Added Files:
> > 	brace.py 
> > Log Message:
> > braces that look good even when drawn huge -- but where to put them?
> 
> Looks amazing! But obviously, we do not yet have a place where one could
> put such stuff. Maybe it would maybe be more clear if brace were a path
> instead of having a path() method.

That's an interesting idea. Get's a +1 from me.

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

> 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 ...

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 *").

> 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).

> Adding some backwards compatibility code which issues a
> warning would be rather simple.

Right, we definitely should do that.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/