[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
More information about the Python-Dev mailing list
Fri Aug 6 00:07:25 CEST 2004
- Previous message: [Python-Dev] Re: @decorators, the PEP and the "options" out there?
- Next message: [Python-Dev] About pep 318--Intro
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Re: @decorators, the PEP and the "options" out there?
- Next message: [Python-Dev] About pep 318--Intro
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list