I've just committed a patch to stop "from pylab import *"
> from overriding Python builtin functions like min() and
> max().
> Spurred on by the potential of matplotlib included in the
> Enthought Edition of Python, I've gone ahead and added the
> following lines to pylab.py in CVS:
> import __builtin__ min = __builtin__.min max =
> __builtin__.max sum = __builtin__.sum round =
> __builtin__.round abs = __builtin__.abs
I thought we last left this with the idea that these changes would be
made in matplotlib.numerix level, and that the old symbols would still
be provided under the names amin, amax, aabs, etc..., and the existing
matplotlib code and examples would be ported to the new naming scheme.
Eg,
http://sourceforge.net/mailarchive/forum.php?thread_id=6323208&forum_id=36187
My fear is that if we do this in pylab but not numerix, confusion will
only deepen.
FYI, we have until late Thursday I think to get anything we want in
before the final enthon roll-up.
JDH
my comments on modules being exposed appear to have fallen into a
vacuum. I still ask if "from matplotlib import *" should expose the
time module or the sys module?
Danny
--- John Hunter <jdhunter@...4...> wrote:
> I've just committed a patch to stop "from pylab import *"
> from overriding Python builtin functions like min() and
> max().
> Spurred on by the potential of matplotlib included in the
> Enthought Edition of Python, I've gone ahead and added
the
> following lines to pylab.py in CVS:
> import __builtin__ min = __builtin__.min max =
> __builtin__.max sum = __builtin__.sum round =
> __builtin__.round abs = __builtin__.abs
I thought we last left this with the idea that these changes would be
made in matplotlib.numerix level, and that the old symbols would
still
be provided under the names amin, amax, aabs, etc..., and the
existing
matplotlib code and examples would be ported to the new naming
scheme.
Eg,
http://sourceforge.net/mailarchive/forum.php?thread_id=6323208&forum_id=36187
···
My fear is that if we do this in pylab but not numerix, confusion
will
only deepen.
FYI, we have until late Thursday I think to get anything we want in
before the final enthon roll-up.
JDH
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive
Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF,
etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
Why not go one step higher and discuss the issue in Numeric and numarray? It
seems like a typical problem in the python community that conflicts are not
discussed and decided centrally but instead everyone just does things their
way. The possibility to change and fix everything by a wrapper module really
causes a huge mess in the various libraries...
···
Am Mittwoch, 19. Januar 2005 23:39 schrieb John Hunter:
I thought we last left this with the idea that these changes would be
made in matplotlib.numerix level
--
_________________________________________Norbert Nemec
Bernhardstr. 2 ... D-93053 Regensburg
Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
eMail: <Norbert@...399...>