A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2010-August/102669.html below:

[Python-Dev] PEP 376 proposed changes for basic plugins support

[Python-Dev] PEP 376 proposed changes for basic plugins support [Python-Dev] PEP 376 proposed changes for basic plugins supportexarkun at twistedmatrix.com exarkun at twistedmatrix.com
Mon Aug 2 15:53:54 CEST 2010
On 01:27 pm, mal at egenix.com wrote:
>exarkun at twistedmatrix.com wrote:
>>On 12:21 pm, mal at egenix.com wrote:
>>>
>>>See Zope for an example of how well this simply mechanism works out 
>>>in
>>>practice: it simply scans the "Products" namespace for sub-packages 
>>>and
>>>then loads each sub-package it finds to have it register itself with
>>>Zope.
>>
>>This is also roughly how Twisted's plugin system works.  One drawback,
>>though, is that it means potentially executing a large amount of 
>>Python
>>in order to load plugins.  This can build up to a significant
>>performance issue as more and more plugins are installed.
>
>I'd say that it's up to the application to deal with this problem.
>
>An application which requires lots and lots of plugins could
>define a registration protocol that does not require loading
>all plugins at scanning time.

It's not fixable at the application level, at least in Twisted's plugin 
system.  It sounds like Zope's system has the same problem, but all I 
know of that system is what you wrote above.  The cost increases with 
the number of plugins installed on the system, not the number of plugins 
the application wants to load.

Jean-Paul
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4