Added decorator3.txt

1 files changed, 50 insertions, 0 deletions

diff --git a/artima/python/decorator3.txt b/artima/python/decorator3.txt
new file mode 100644
index 0000000..deac441
--- /dev/null
+++ b/artima/python/decorator3.txt
@@ -0,0 +1,50 @@
+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 relectant
+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.
+
+What do you people think?