A RetroSearch Logo

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

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2004-March/043023.html below:

[Python-Dev] PEP 318 - generality of list; restrictions on elements

[Python-Dev] PEP 318 - generality of list; restrictions on elements [Python-Dev] PEP 318 - generality of list; restrictions on elementsJust van Rossum just at letterror.com
Wed Mar 10 10:52:01 EST 2004
Aahz wrote:

> On Mon, Mar 08, 2004, Fred L. Drake, Jr. wrote:
> > On Monday 08 March 2004 04:00 pm, Aahz wrote:
> >>
> >> Principle of least surprise, essentially.  There are already going
> >> to be enough obscure uses for this; let's try to keep the
> >> completely whacky out of it.  You'll have to come up with an
> >> awfully convincing use case to change my mind.
> > 
> > I'd be very surprised if the interpreter cared that a decorator
> > returned a callable; what should it care?
> 
> The interpreter doesn't care; *people* care.  That's precisely why it
> should be a documented requirement.

Presumably people also care about contortions like this:

  >>> def blackhole(*args):
  ...   return None
  ... 
  >>> class Foo(object):
  ...   __metaclass__ = blackhole
  ... 
  >>> print Foo
  None
  >>> 

Yet that doesn't mean Python has to disallow it (and indeed it doesn't).

Btw. +1 from me for

  def func(args) [decorators]:

and -1 for

  def func [decorators] (args):

I already frown when people put a space between the function name and
arglist, I wouldn't want to separate them even more.

Just

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