On May 22, 10:49 am, Michele Simionato
wrote:
> I have finally decided to port the decorator module to Python 3.
> Changing the module was zero effort (2to3 worked) but changing the
> documentation was quite an effort, since I had to wait for docutils/
> pygements to support Pyt
I have finally decided to port the decorator module to Python 3.
Changing the module was zero effort (2to3 worked) but changing the
documentation was quite an effort, since I had to wait for docutils/
pygements to support Python 3 and to change all my custom build
process. Also, I am relying on
On Apr 7, 7:57 am, Daniel Fetchinson
wrote:
> > have always seen the decorator module
> > as a temporary hack waiting for a proper solution
> > at the language level. I wanted the possibility to modify the
> > signature of a function. Everybody more or less agreed
> >
_wrapper() and functools.wraps()
> are NOT equivalent to the decorator module.
Exactly, that's why I think the decorator module would be a useful
addition to functools.
> My original
> plan when I wrote the decorator module was to make aware
> people that the corrent support for decor
nfortunately functools.update_wrapper() and functools.wraps()
are NOT equivalent to the decorator module. My original
plan when I wrote the decorator module was to make aware
people that the corrent support for decorators in the language
is insufficient. I have always seen the decorator module
as a temporary hack w
On Mon, Apr 6, 2009 at 5:41 PM, Daniel Fetchinson
wrote:
> The decorator module [1] written by Michele Simionato is a very useful
> tool for maintaining function signatures while applying a decorator.
> Many different projects implement their own versions of the same
> functionality,
The decorator module [1] written by Michele Simionato is a very useful
tool for maintaining function signatures while applying a decorator.
Many different projects implement their own versions of the same
functionality, for example turbogears has its own utility for this, I
guess others do
On Dec 1, 9:18 pm, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> Release a final 2.x version with whatever internal changes but with
> external api unchanged or at least backward compatible. Mark items to
> be deleted as deprecated. Keep that available indefinately.
>
> Then release a 3.0 version wi
Michele Simionato wrote:
What do you people think?
I am not a user yet, but my opinion anyway...
Release a final 2.x version with whatever internal changes but with
external api unchanged or at least backward compatible. Mark items to
be deleted as deprecated. Keep that available indefin
On Mon, Dec 1, 2008 at 9:16 AM, Michele Simionato
<[EMAIL PROTECTED]> wrote:
> I am thinking about releasing a new version of the decorator module,
> [...]
Just FYI, the module being discussed here is
http://www.phyast.pitt.edu/~micheles/python/documentation.html
I dont use it mysel
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
Yep, I was wondering about irrelevant things, there is no problem in
this case,
actually.
Michele Simionato
--
http://mail.python.org/mailman/listinfo/python-list
Michele Simionato wrote:
> Duncan Booth:
>> Fortunately you have a list of
>> argument names readily available so it shouldn't be too
>> hard to generate unique names to use in their place.
>
> It does not look too simple either. Whereas I can easily
> build valid Python identifiers which are ext
I have uploaded version 0.5 that should fix all the
subtle bugs you pointed out, but there could be others
(I would not be surprised in that case ;).
I will add a test suite for various corner cases tomorrow.
BTW, I cannot decide if exotic function signatures are
a feature or an accident ...
Duncan Booth:
> Fortunately you have a list of
> argument names readily available so it shouldn't be too
> hard to generate unique names to use in their place.
It does not look too simple either. Whereas I can easily
build valid Python identifiers which are extremely unlikely
to clash with any ide
Notice that the decorator module is at version 0.4 and I still consider
it as experimental. The reason why I posted the link here is to get
feedback and it seems I got it ;)
I will upgrade to version 0.5 shortly, fixing the easily fixable bugs
and
documenting what cannot be easily fixed.
Thanks
Michele Simionato wrote:
> with the following advantages:
>
> 1. one-level of nesting is saved ("flat is better than nested")
> 2. name, docstring and dictionary of the original function are
> preserved;
> 3. the signature of the original function is preserved (this one is
> nontrivial).
>
; return new_f
> return check_accepts
>
> After I saw all the examples, I concluded that every decorator must
> define an inner function which takes only one argument, the
> function to decorate. Is this right?
>
Yes, but you may want to look at my decorator modul
I have written a decorator module to make easier to write good
decorators
(i.e. decorators preserving the signature of the functions they
decorate).
The documentations contains a (hopefully) nice collections of use cases
(which are also test cases, sice I take doctest very seriously ;).
You can
19 matches
Mail list logo
