c[:]()

[Warren Stringer]

> 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:

	do(orchestra(score)).pickle()
	do(orchestra(conductor)).sequence()

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