traits?

Development matplotlib-devel
1

I've been hacking away at adding support for "dropped spines" to MPL
(e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
have come to the conclusion that there is a fundamental issue in the
code base that the traits package has solved -- many values that depend
on other values with complicated stuff that happens when one of the
parent values changes. For example, the location of the text from the
xaxis depends on the padding value in addition to the xaxis location.
Now I'm trying to add another element to the mix -- namely an axis spine
that can change location -- and things are going to spiral into a
(further) collection of special-cased updates unless there's some
reworking of the infrastructure.

So, the question is, should I attempt to use traits for this? I guess
that I won't have the time to re-write the entire code base to use
traits, but I'd like make a stab a stab at dropped spine support with
the knowledge that, should I be successful, there's at least a chance we
would again ship traits with MPL. I imagine we could incrementally move
more and more to traits if I'm successful, particularly now that we have
the beginnings of a unit test infrastructure (thanks James!).

-Andrew

2

If you switch to traits, will things still build with py2exe? Are there speed costs? Startup time?

Cheers,

William

···

On Mon, May 18, 2009 at 8:07 PM, Andrew Straw <strawman@…36…> wrote:

I’ve been hacking away at adding support for “dropped spines” to MPL

(e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and

have come to the conclusion that there is a fundamental issue in the

code base that the traits package has solved – many values that depend

on other values with complicated stuff that happens when one of the

parent values changes. For example, the location of the text from the

xaxis depends on the padding value in addition to the xaxis location.

Now I’m trying to add another element to the mix – namely an axis spine

that can change location – and things are going to spiral into a

(further) collection of special-cased updates unless there’s some

reworking of the infrastructure.

So, the question is, should I attempt to use traits for this? I guess

that I won’t have the time to re-write the entire code base to use

traits, but I’d like make a stab a stab at dropped spine support with

the knowledge that, should I be successful, there’s at least a chance we

would again ship traits with MPL. I imagine we could incrementally move

more and more to traits if I’m successful, particularly now that we have

the beginnings of a unit test infrastructure (thanks James!).

-Andrew

Crystal Reports - New Free Runtime and 30 Day Trial

Check out the new simplified licensing option that enables

unlimited royalty-free distribution of the report engine

for externally facing server and web deployment.

http://p.sf.net/sfu/businessobjects

Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

3

Hi Andrew,

···

On Mon, May 18, 2009 at 8:07 PM, Andrew Straw <strawman@…36…> wrote:

I’ve been hacking away at adding support for “dropped spines” to MPL

(e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and

have come to the conclusion that there is a fundamental issue in the

code base that the traits package has solved – many values that depend

on other values with complicated stuff that happens when one of the

parent values changes. For example, the location of the text from the

xaxis depends on the padding value in addition to the xaxis location.

Now I’m trying to add another element to the mix – namely an axis spine

that can change location – and things are going to spiral into a

(further) collection of special-cased updates unless there’s some

reworking of the infrastructure.

So, the question is, should I attempt to use traits for this? I guess

that I won’t have the time to re-write the entire code base to use

traits, but I’d like make a stab a stab at dropped spine support with

the knowledge that, should I be successful, there’s at least a chance we

would again ship traits with MPL. I imagine we could incrementally move

more and more to traits if I’m successful, particularly now that we have

the beginnings of a unit test infrastructure (thanks James!).

A couple summers back I wrote the config subpackage for mpl, which is based on Fernando’s traited configobj package TConfig. It hasn’t been used or tested in a while, but the other devs had been pretty good about keeping it up to date with changes to the regular rcparams. If there is any push to use Traits in mpl, I would really like to see the config package ressurrected. To use it, there is a global variable in matplotlib’s init.py that needs to be set to True.

Darren

4

If you do, *please* either depend on Traits or, if you must include the code in matplotlib itself, stick it under matplotlib's namespace. I really don't want to go back to having to fix people's broken installations again.

···

On 2009-05-18 19:07, Andrew Straw wrote:

I've been hacking away at adding support for "dropped spines" to MPL
(e.g. Performance trade-offs in the flight initiation of Drosophila | Journal of Experimental Biology | The Company of Biologists ) and
have come to the conclusion that there is a fundamental issue in the
code base that the traits package has solved -- many values that depend
on other values with complicated stuff that happens when one of the
parent values changes. For example, the location of the text from the
xaxis depends on the padding value in addition to the xaxis location.
Now I'm trying to add another element to the mix -- namely an axis spine
that can change location -- and things are going to spiral into a
(further) collection of special-cased updates unless there's some
reworking of the infrastructure.

So, the question is, should I attempt to use traits for this? I guess
that I won't have the time to re-write the entire code base to use
traits, but I'd like make a stab a stab at dropped spine support with
the knowledge that, should I be successful, there's at least a chance we
would again ship traits with MPL. I imagine we could incrementally move
more and more to traits if I'm successful, particularly now that we have
the beginnings of a unit test infrastructure (thanks James!).

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

5

I’ve been hacking away at adding support for “dropped spines” to MPL

(e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and

have come to the conclusion that there is a fundamental issue in the

code base that the traits package has solved – many values that depend

on other values with complicated stuff that happens when one of the

parent values changes. For example, the location of the text from the

xaxis depends on the padding value in addition to the xaxis location.

Now I’m trying to add another element to the mix – namely an axis spine

that can change location – and things are going to spiral into a

(further) collection of special-cased updates unless there’s some

reworking of the infrastructure.

So, the question is, should I attempt to use traits for this? I guess

that I won’t have the time to re-write the entire code base to use

traits, but I’d like make a stab a stab at dropped spine support with

the knowledge that, should I be successful, there’s at least a chance we

would again ship traits with MPL. I imagine we could incrementally move

more and more to traits if I’m successful, particularly now that we have

the beginnings of a unit test infrastructure (thanks James!).

If you do, please either depend on Traits or, if you must include the code in

matplotlib itself, stick it under matplotlib’s namespace.

We stopped shipping traits with mpl a long time ago, when that issue was identified.

I really don’t want to

go back to having to fix people’s broken installations again.

Was that comment really necessary?

Darren

···

On Mon, May 18, 2009 at 8:41 PM, Robert Kern <robert.kern@…552…149…> wrote:

On 2009-05-18 19:07, Andrew Straw wrote:

6

     > I've been hacking away at adding support for "dropped spines" to MPL
     > (e.g. Performance trade-offs in the flight initiation of Drosophila | Journal of Experimental Biology | The Company of Biologists ) and
     > have come to the conclusion that there is a fundamental issue in the
     > code base that the traits package has solved -- many values that
    depend
     > on other values with complicated stuff that happens when one of the
     > parent values changes. For example, the location of the text from the
     > xaxis depends on the padding value in addition to the xaxis location.
     > Now I'm trying to add another element to the mix -- namely an
    axis spine
     > that can change location -- and things are going to spiral into a
     > (further) collection of special-cased updates unless there's some
     > reworking of the infrastructure.
     >
     > So, the question is, should I attempt to use traits for this? I guess
     > that I won't have the time to re-write the entire code base to use
     > traits, but I'd like make a stab a stab at dropped spine support with
     > the knowledge that, should I be successful, there's at least a
    chance we
     > would again ship traits with MPL. I imagine we could
    incrementally move
     > more and more to traits if I'm successful, particularly now that
    we have
     > the beginnings of a unit test infrastructure (thanks James!).

    If you do, *please* either depend on Traits or, if you must include
    the code in
    matplotlib itself, stick it under matplotlib's namespace.

We stopped shipping traits with mpl a long time ago, when that issue was
identified.

But part of that calculation was that Traits wasn't being used for anything non-experimental. Since that is being revisited, and since you still do distribute other packages like dateutils and pytz (which also cause similar installation headaches) the same way, I would like this to be kept in mind.

    I really don't want to
    go back to having to fix people's broken installations again.

Was that comment really necessary?

Was it really offensive? People would install matplotlib, then they would try to install other parts of ETS, the ETS stuff wouldn't work, thus they had a broken installation. I do not want to go back to having to fix their broken installations. This isn't a jab at the matplotlib team.

···

On 2009-05-18 20:05, Darren Dale wrote:

On Mon, May 18, 2009 at 8:41 PM, Robert Kern <robert.kern@...149... > <mailto:robert.kern@…149…>> wrote:
    On 2009-05-18 19:07, Andrew Straw wrote:

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

7 
 > I've been hacking away at adding support for "dropped spines" to MPL

 > (e.g. [http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7](http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7) ) and

 > have come to the conclusion that there is a fundamental issue in the

 > code base that the traits package has solved -- many values that

depend

 > on other values with complicated stuff that happens when one of the

 > parent values changes. For example, the location of the text from the

 > xaxis depends on the padding value in addition to the xaxis location.

 > Now I'm trying to add another element to the mix -- namely an

axis spine

 > that can change location -- and things are going to spiral into a

 > (further) collection of special-cased updates unless there's some

 > reworking of the infrastructure.

 >

 > So, the question is, should I attempt to use traits for this? I guess

 > that I won't have the time to re-write the entire code base to use

 > traits, but I'd like make a stab a stab at dropped spine support with

 > the knowledge that, should I be successful, there's at least a

chance we

 > would again ship traits with MPL. I imagine we could

incrementally move

 > more and more to traits if I'm successful, particularly now that

we have

 > the beginnings of a unit test infrastructure (thanks James!).

If you do, *please* either depend on Traits or, if you must include

the code in

matplotlib itself, stick it under matplotlib's namespace.

We stopped shipping traits with mpl a long time ago, when that issue was

identified.

But part of that calculation was that Traits wasn’t being used for anything

non-experimental. Since that is being revisited, and since you still do

distribute other packages like dateutils and pytz (which also cause similar

installation headaches) the same way, I would like this to be kept in mind.

I really don't want to

go back to having to fix people's broken installations again.

Was that comment really necessary?

Was it really offensive?

The whole situation was just really embarrassing for me. Who would want to go back to having to fix people’s broken installations? It just opened an old wound.

People would install matplotlib, then they would try to

install other parts of ETS, the ETS stuff wouldn’t work, thus they had a broken

installation. I do not want to go back to having to fix their broken

installations. This isn’t a jab at the matplotlib team.

I had tried to work things out so mpl would only install traits if traits wasn’t already installed, or if the installed version had also been provided by mpl. That turned out to be insufficient to avoid the problems you and Gael had to deal with, because if setup.py was ever run when Traits was not installed, distutils would copy traits into the build/ directory. Once it ended up in build/, “setup.py install” would install it regardless of what checks were in place in setup.py, thus overwriting existing Traits and breaking environments.

To make a long story short, it won’t happen again.

Darren

···

On Mon, May 18, 2009 at 9:37 PM, Robert Kern <robert.kern@…552…149…> wrote:

On 2009-05-18 20:05, Darren Dale wrote:

On Mon, May 18, 2009 at 8:41 PM, Robert Kern <robert.kern@…149… > > mailto:robert.kern@...149...> wrote:
On 2009-05-18 19:07, Andrew Straw wrote:

8

Excellent.

I do agree with both of you that shipping Traits with matplotlib is very
likely to get all of us in trouble.

If there are issue with having Traits as a dependency, they must be
adressed in the Traits codebase.

Gaël

···

On Mon, May 18, 2009 at 10:41:22PM -0400, Darren Dale wrote:

   I had tried to work things out so mpl would only install traits if traits
   wasn't already installed, or if the installed version had also been
   provided by mpl. That turned out to be insufficient to avoid the problems
   [...]

   To make a long story short, it won't happen again.