On 01/11/2007, Don Dwiggins <[EMAIL PROTECTED]> wrote: > > SPE Stani's Python Editor wrote: > > Hi Rob, > > I also run a while ago into that 'problem' of numpy. (I've emailed you > > about it.) Would it not be better to load "numpy" only on demand even > > if you have it installed? It increases unnecessarily boot time and > > memory usage as someone might not use the image viewer every session. > > Some IDE users are quite critical about it and they are right. > > > This would be a good idea in general: give the user a list of plugins, > and a way to control their loading: on startup, on first use, or never > (this could be useful to keep the plugin in the list for occasional use, > but avoid having it loaded inadvertently).
This is an area where it might be a good idea to borrow some design ideas from JEdit. Since version 4.2 or 4.3, I can't remember which, they've supported dynamic plugin loading. I think at the time, the primary reason was to cut back on startup time -- less of an issue with Python apps than Java ones, I've noticed. However, it does everything you ask in an elegant (not counting the XML) way. JEdit is well designed and well-documented, code-wise. I suggest running doxygen on it to gain some insight into its design. > Come to think of it, the > list should probably be a tree to show dependencies among plugins. This is true when it comes to recursively loading or unloading plugins. However, I personally think dependencies should not be tracked or managed. The reason for this is that it is entirely possible that someone will write a plugin that provides the same functionality as another plugin, but in a completely different way. A plugin that depends on this functionality should not have to depend on one or both of those other plugins. This simply extends the pythonic philosophy of duck typing to a higher level of abstractions. As a really bad example, you might have a plugin that parses the structure of a java file and another plugin that parses the structure of a python file. A third plugin might use this parse structure to provide autocomplete or class navigation or similar functionality without caring about which of the other two plugins (or maybe a totally different generic plugin that parses all languages that hasn't been written yet) is loaded. Dusty
