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? 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. > > 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. 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.) 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. Eric ------------------------------------------------------------------------- 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
