On Wednesday 07 November 2007 03:34:18 pm Eric Firing wrote:
> Darren Dale wrote:
> > I have been working on updating the trunk to provide enthought.traits
> > version 2.6b1. backend_driver.py is running without exceptions using the
> > traited config package with the internal traits package.
> >
> > Issues:
> >
> > 1) there are lots of absolute package imports scattered throughout
> > traits' code. I worked around this by adding a line to
> > matplotlib/__init__.py:
> >
> > sys.path.append(os.path.split(__file__)[0])
> >
> > This lets matplotlib access enthought.traits without modifying enthoughts
> > code (anymore than Gael had already done by stripping the pkg_resources
> > imports).
> >
> > 2) When I tried updating rc_traits.py to import
> > matplotlib.enthought.traits instead of enthought.traits (which isnt on
> > the PYTHONPATH), I discovered a problem:
> >
> > enthought.traits.trait_errors.TraitError: The 'parents_items' trait of a
> > ViewElements instance must be a TraitListEvent, but a value of
> > <matplotlib.enthought.traits.trait_handlers.TraitListEvent object at
> > 0x850454c> was specified.
> >
> > So traits would be a behind-the-scenes package, for internal mpl use
> > only.
>
> Regarding (1) and (2), and asking out of ignorance:
>
> 1) If an internal version of traits is to be used, how hard would it be
> to patch it in such a way that it *could* be used externally?
I think this would be too significant an undertaking to seriously consider.
The easier part is replacing all the "from enthought" imports in the library
to "from matplotlib.enthought", and they are scattered throughout the code.
The harder part seems to be the error messages due to traits expecting
enthought.traits objects, not matplotlib.enthought.traits objects.
Johns suggestion that we try to deal with traits the same way we do pytz and
datetime should solve this, with a caveat:
> 2) Does Gael's version already get around the slow initialization
> problem? (I presume so--it was pkg-resources that was causing the
> trouble, wasn't it?) I think this is important. Some mpl applications
> involve running simple scripts many times, so startup time matters. I
> would not want to see traits as an external dependency if that brought
> with it the startup lag--apart from all the other questions associated
> with making it an external dependency in any of its present forms.
I think it does get us around the initialization problem, although I need to
run backend_driver once I get the installation worked out to be sure.
However, if the user already has traits installed on their system, it will
not be stripped of pkg_imports, so the work-around would only apply to the
mpl-shipped version of traits.
> > 3) We can not include traits-3 without either adding setuptools as an
> > external dependency (which is already true for python-2.3 users) or
> > monkey-patching distutils. traits-3 includes some pyrex code, which
> > standard distutils does not recognize.
>
> Is it a viable alternative to add pyrex as an external dependency?
> Pyrex.Distutils makes it easy to use pyrex modules via otherwise
> standard setup.py scripts. And pyrex itself is pure python, very easy
> to install.
I usually look to you and John for answers to questions like these. I think I
tried this yesterday, and ran into a problem. You have to import build_ext
from Pyrex.Distutils, and then pass "cmdclass = {'build_ext': build_ext}" to
setup(). The build failed, maybe because build_ext was being applied to
non-pyrex extension code, or maybe because I didn't know what I was doing.
> Part of my motivation in bringing this up is that I have found pyrex
> extremely useful for quick speedups and for interfacing to larger chunks
> of C code. (And I have a strong personal bias towards C and pyrex for
> extension code in preference to C++ and any of the mechanisms used to
> provide bindings for C++ code. I find the former vastly more readable,
> understandable, and hence maintainable.)
Would I be able to understand it? :)
> Pyrex (actually its variant,
> cython) is already essential to basemap, and I am hoping for increasing
> basemap integration, as well as judicious use of extension code to make
> the transforms branch lightening-fast.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
