On Jan 11, 2007, at 12:55 AM, Steve Chaplin wrote:
>> I have never run into a problem with relative imports, though I don't
>> object to removing them. Why are they bad style and what is the
>> danger?
>
> Its because you can unwittingly end up with module name clashes. There
> can be two diffe
On Jul 19, 2007, at 12:28 PM, Fernando Perez wrote:
> Is Peter Wang on this list? If not, perhaps you should CC him and tip
> him to come over. I know Robert monitors this, but we shouldn't make
> him the single point of responsibility for keeping tabs on the bridges
> with Cha
On Jul 19, 2007, at 3:05 PM, Bill Baxter wrote:
> Chaco may be formidable and complex, but so is the list of features
> and requirements you just posted. What about just focusing on a Pylab
> wrapper for Chaco? And working with Peter to make Chaco everything
> you envison. Or does Chaco have th
On Jul 19, 2007, at 12:18 PM, John Hunter wrote:
> = Data copying =
>
> Push the data to the backend only once, or only when required. Update
> the transforms in the backend, but do not push transformed data on
> every draw. This is potentially a major win, because we currently
> move the data a
On Jul 19, 2007, at 5:31 PM, Christopher Barker wrote:
>> Also, everything should be numpy enabled,
>> and the sequence-of-python-tuples approach that many of the
>> collections take should be dropped.
>
> who hoo!
>
> However, numpy doesn't handle "ragged" arrays well. I wonder if
> there's
> a
On Jul 19, 2007, at 10:42 PM, Ken McIvor wrote:
>> = Z-ordering, containers, etc =
>>
>> Peter has been doing a lot of nice work on z-order and layers for
>> chaco, stuff that looks really useful for picking, interaction,
>> etc...
>> We should look at this approach, and think carefully about ho
On Jul 24, 2007, at 7:31 PM, Chris Barker wrote:
>> output when usetex is enabled.
>
> Ah! and some good math implementation -- What does Chaco do for
> that? I
> know I took part in a discussion about it on a Chaco list a few years
> back -- at the time I argued that you're never going to do
On Sep 12, 2007, at 3:27 PM, Paul Kienzle wrote:
>> Extensibilty:
>>
>> We would like to make it fairly easy for users to add additional
>> non-linear transformations. The current framework requires
>> adding a
>> new function at the C++ layer, and hacking into axes.py to support
>> add
