Steve Holden Wrote
> The general rule in Python is that you provide the right objects and
> expect error tracebacks if you do something wrong. So I don't really see
> why you feel it's necessary to "[be] unambiguous about using a
> container" when you don't appear to feel the same about its containing
> only functions.
Give that everything is a first class object
"Look ma! I'm an object"() # causes
Traceback (most recent call last) ...
TypeError: 'str' object is not callable
def funky(): lookma()
funky() # causes
Traceback (most recent call last)...
NameError: global name 'lookma' is not defined
Means that any exception can be caught, thus equal.
`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.
> > You're right. At the same time, version 3 is coming up soon. There is a
> > short window of opportunity for profound changes.
> >
> Which closed at the end of April as far as PEPs affecting the initial
> implementation of version 3 was concerned. The python3000 and
> python-ideas lists are the correct forum for those issues, though you
> will of course get all sorts of opinions on c.l.py.
Oh well. Perhaps I can relax and actually write functioning code ;-)
What do you mean by 'c.l.py' ? The first thing that comes to mind is
'clippy' that helpful little agent in Word that helped pay for Simonyi's
trip into space.
Ching ching,
Warren
--
http://mail.python.org/mailman/listinfo/python-list
