At 08:56 PM 5/30/2006 +0200, Alexander Bernauer wrote: >Hi > >I found two bugs in example 4 of the PEP 318 [1]. People on #python >pointed me to this list. So here is my report. Additionally I appended >an afaics correct implementation for this task. > >[1] http://www.python.org/dev/peps/pep-0318/ > >Bug 1) >The decorator "accepts" gets the function which is returned by the >decorator "returns". This is the function "new_f" which is defined >differently from the function "func". Because the first has an >argument count of zero, the assertion on line 3 is wrong. The simplest fix for this would be to require that returns() be used *before* accepts(). >Bug 2) >The assertion on line 6 does not work correctly for tuples. If the >second argument of "isinstance" is a tuple, the function returns true, >if the first argument is an instance of either type of the tuple. This is intentional, to allow saying that the given argument may be (for example) an int or a float. What it doesn't support is nested-tuple arguments, but that's a reasonable omission given the examples' nature as examples. > def check(*args, **kwds): > checktype(args, self.types) > self.func(*args, **kwds) This needs a 'return', since it otherwise loses the function's return value. >To be honest, I didn't understand what the purpose of setting >"func_name" is, so I left it out. If its neccessary please feel free to >correct me. It's needed for Python documentation tools such as help(), pydoc, and so on display something more correct for the decorated function's documentation, although also copying the __doc__ attribute would really also be required for that. >In contrast to tuples lists and dictionaries are not inspected. The >reason is that I don't know how to express: "the function accepts a list >of 3 or more integers" or alike. Perhaps somebody has an idea for this. I think perhaps you've mistaken the PEP examples for an attempt to implement some kind of typechecking feature. They are merely examples to show an idea of what is possible with decorators, nothing more. They are not even intended for anybody to actually use! >I wonder, how it can be, that those imho obvious mistakes go into a PEP >and stay undetected there for almost 3 years. That's because nobody uses them; a PEP example is not intended or required to be a robust production implementation of the idea it sketches. They are proofs-of-concept, not source code for a utility. If they were intended to be used, they would be in a reference library or in the standard library, or otherwise offered in executable form.
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