Warren Stringer warren at muse.com
Fri Jun 1 11:20:17 CEST 2007

> Warren Stringer wrote:
> > `c[:]()` is unambiguous because:
> >
> >     def c(): print 'yo'
> >
> >     c()     # works, but
> >     c[:]()  # causes:
> >
> >     Traceback (most recent call last)...
> >         c[:]()  # causes:
> >     TypeError: unsubscriptable object
> >
> > There are many `c()` to be found in the wild and no `c[:]()`, thus
> > unambiguous. To be honest, I wasn't sure, until testing this, just now.
>  >>> c = 'not quite'
>  >>> c[:]
> 'not quite'
>  >>> c[:]()
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
> TypeError: 'str' object is not callable

Interesting example. By extension
>>> def c(): print 'yo'
>>> c
<function c at 0x00B867F0>
>>> c(bad)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: name 'bad' is not defined

Both your example and mine show well formed and ill formed statements at the
command line.

> You also seem to be under the impression that `x[:]()` is somehow
> special syntax that is treated differently than `y = x[:]; y()`.  It is
> not.

No; I was under the impression that `x[:]()` didn't work and the reason why
it didn't work wasn't obvious. 

I like your use case. Am I correct in assuming that `y = x[:]; y()` is NOT
to be found in working code? If that is the case, then nothing gets broken.
It would be instructive to have a use case where enabling c[:]() would break
existing code. 

> Besides, _ambiguity_ was never the problem.  _Functionality_ is the
> problem.

Ambiguity is one of many parameters. It was a problem with another poster. I
wish I had McConnel's Code Complete book handy. Let's see ... a search
yields: debugging, testing, performance, portability, design, interfaces,
style, and notation. 

My use case is this:


And so now, that I can, I am happy. Life is good. Time to sleep.

More information about the Python-list mailing list