If my understanding is right, enthought does this with an "api" module.
It might be worth going in the same direction.
My 2 cents,
Ga�l
···
On Sat, Feb 10, 2007 at 08:04:38AM -0600, John Hunter wrote:
I am inclined to consider ripping out the __init__ stuff into a
"config" module or something like that.
--
Gael Varoquaux,
Groupe d'optique atomique,
Laboratoire Charles Fabry de l'Institut d'Optique
Campus Polytechnique, RD 128
91127 Palaiseau cedex FRANCE
!!!! NEW Phone number !!!!
Tel : 33 (0) 1 64 54 33 49 - Fax : 33 (0) 1 64 54 31 01
Labs: 33 (0) 1 64 54 33 63 - 33 (0) 1 64 54 33 62
> I am inclined to consider ripping out the __init__ stuff into a
> "config" module or something like that.
If my understanding is right, enthought does this with an "api" module.
It might be worth going in the same direction.
And for what it's worth this is also the direction nipy is taking,
having an api.py in each package.
Tim
···
On 2/11/07, Gael Varoquaux <gael.varoquaux@...427...> wrote:
On Sat, Feb 10, 2007 at 08:04:38AM -0600, John Hunter wrote:
My 2 cents,
Gaël
--
Gael Varoquaux,
Groupe d'optique atomique,
Laboratoire Charles Fabry de l'Institut d'Optique
Campus Polytechnique, RD 128
91127 Palaiseau cedex FRANCE
!!!! NEW Phone number !!!!
Tel : 33 (0) 1 64 54 33 49 - Fax : 33 (0) 1 64 54 31 01
Labs: 33 (0) 1 64 54 33 63 - 33 (0) 1 64 54 33 62
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
I don't have a problem with this if it makes sense to other people and
helps with consistency across packages, but I don't find the mnemonic
particularly clear. Eg
from matplotlib.config import rc, verbose
makes more sense to me than
from matplotlib.api import rc, verbose
since I consider these (and most other stuff in __init__) to be part
of the configuration, and a lot of stuff that doesn't live there
(Figure, Axes, Line2D) to be part of the API. What is the
enthought/nipy rationale for calling it api?
JDH
···
On 2/10/07, Tim Leslie <tim.leslie@...149...> wrote:
And for what it's worth this is also the direction nipy is taking,
having an api.py in each package.
> And for what it's worth this is also the direction nipy is taking,
> having an api.py in each package.
I don't have a problem with this if it makes sense to other people and
helps with consistency across packages, but I don't find the mnemonic
particularly clear. Eg
from matplotlib.config import rc, verbose
makes more sense to me than
from matplotlib.api import rc, verbose
since I consider these (and most other stuff in __init__) to be part
of the configuration, and a lot of stuff that doesn't live there
(Figure, Axes, Line2D) to be part of the API. What is the
enthought/nipy rationale for calling it api?
Sorry, I think I might have given the wrong impression. Our use of an
api.py is for having a single location to import classes equivalent to
Figure, Axes, etc from. Your suggestion of having a matplotlib.config
for things like rc and verbose makes a lot of sense I think.
Tim
···
On 2/11/07, John Hunter <jdh2358@...149...> wrote:
On 2/10/07, Tim Leslie <tim.leslie@...149...> wrote:
JDH
Same missunderstanding here.
Ga�l
···
On Sun, Feb 11, 2007 at 01:32:45AM +1100, Tim Leslie wrote:
Sorry, I think I might have given the wrong impression. Our use of an
api.py is for having a single location to import classes equivalent to
Figure, Axes, etc from. Your suggestion of having a matplotlib.config
for things like rc and verbose makes a lot of sense I think.