I suggest tag the code with decorator @deprecated and @experimental.
The decorators could check config to see if need to raise a warning or not.

both decorator could have parameter. Kevin in the widget proposition there is a module deprecated with a decorator implementation. you could you adapt it to check with config.

Ian Bicking a écrit :

Kevin Dangoor wrote:

On 1/31/06, Michael Schneider <[EMAIL PROTECTED]> wrote:

What about some varent of what python uses:

from __future__ import  .....

http://docs.python.org/ref/future.html



I had considered using special imports or other trickery, but it also
occurred to me that the easiest thing might be to just wrap the
experimental features in a config variable. If you want them on, you
need to explicitly enable them in the config file.


You could also create your own warning type, and put in a warning call in those experimental features, and provide a configuration parameter that will turn off that warning. Then everything is always there -- no confusing ImportErrors -- but people clearly see messages when they use a feature that isn't stable.


--------------------------------------------------------------
David "Dwayne" Bernard            Freelance Developer
                                  mailto:[EMAIL PROTECTED]
      \|/                         http://dwayne.java-fan.com
--o0O @.@ O0o-------------------------------------------------

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to