Summary
I am asking the users of my decorator module if they would accept a new version breaking backward compatibility in a minor way.
Advertisement
I am thinking about releasing a new version of the decorator module,
completely rewritten from scratch. The new implementation takes half
the lines of the original one and it is much more general, so I like
it more. However, there is an issue of compatibility with the past
and I am asking here for feedback from my users.
I have already broken backward compatibility in the
past, with version 2.0 of the module, and I could break it again
in version 3.0. However, the breakage in version 2.0 was very
minor and at the time the module had very few users so that nobody
ever complained.
Nowadays there are a lot of people using it and there are frameworks
relying on it (such as Pylons) so I am reluctant
to break compatibility, even in minor ways.
I want to ask people how do they use the module.
If you just use the decorator function, that will continue
to work as before and I do not think I will ever break that
functionality - actually I am thinking of enhancing it.
However, over the time I have added other
utilities to the module - I am referring to getinfo and new_wrapper -
and I would like to get rid of them. Actually I would like to deprecate
them in decorator 3.0 and to remove them in decorator 3.1 or later on,
after a grace period of one year or so.
Also, I would like to remove a new feature introduced in version 2.3,
i.e. the direct support to decorator factories. I added it in haste
and now I have changed my mind. Is there anybody using that
functionality? I want to offer an alternative which does not
involve magically adding a __call__ method to a class.
In general I want to remove a few things because I feel they add to
the learning curve without offering a compelling benefit, or because I
think the new implementation offer better ways to do the same job.
If nobody uses those features I will remove them; on the other hand,
if this is too much of a breakage, I will just start a new project
with a different name. The old decorator module will continue
to live forever, but the developement on it will stop and the new
things will go in the new module.
Personally, I would like to keep the name, and to add some support
for Python 3.0: decorator 3.0 sounds good for Python 3.0, and
the change I have in mind is the same kind of change which happened
for Python 3.0, i.e. a simplification more than an addition of new
features.
Pylons only uses the decorator function, and I doubt any Pylons projects use anything but the decorator function as well. +1 on deprecating the other things as you see fit
i’d suggest giving the old package a new name that includes its version number, so people can simply ‘easy_install decorator2’, then change their import statements to ‘import decorator2 as decorator’ or similar, or choose to upgrade their code where needed. compatibility is a fine thing, but it shouldn’t be allowed to hamper progress. python’s standard library already has too many quaint modules that betray their age.
Previous Topic
