> 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.
--
http://mail.python.org/mailman/listinfo/python-list
