A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2004-August/046970.html below:

[Python-Dev] Re: @decorators, the PEP and the "options" out there?

[Python-Dev] Re: @decorators, the PEP and the "options" out there?Jp Calderone exarkun at divmod.com
Fri Aug 6 00:07:25 CEST 2004
Martin v. L=F6wis wrote:
> Nicolas Fleury wrote:
> =

>> Other crazy ideas (in case it inspires anyone):
>>
>> accepts(int,int,def)
>> returns(float,def)
>> def bar(low,high):
> =

> =

> That doesn't work. If accepts and returns are callables
> (as they should be), then this already means something
> in current Python. So this would not be backwards
> compatible.

   Adding _any_ names to Python has this potential problem.  I don't =

think that's going to stop anyone from adding new modules to the =

standard library or new builtins (2.4 introduces 3 new builtins).

   To say this isn't backwards compatible is true, but not in a sense =

that strikes me as important.  "accepts" and "returns" don't even need =

to be builtins, they could be placed in a module with a handful of other =

useful common decorators.

   Jp
More information about the Python-Dev mailing list

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