On Nov 15, 2:50 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> I wonder whether the best solution is to include all your type checks
> (isinstance or duck-typing) in the unit tests, so you can avoid paying
> the cost of those tests at runtime? If your code passes the unit tests,
> but fails with real data, then your unit tests aren't extensive enough.
>
> --
> Steven
The real penalties that you pay for static typing are not at compile
time, but at design time. Because of duck-typing, Python programmers
can skip a lot of the extra hoops/cruft that Java and C++ developers
must jump through, usually to *get around* the restrictions of static
typing. Imagine how much code is needed in those languages to
implement this simple generic Proxy class:
class Proxy(object):
def __init__(self,other):
self.obj = other
def __getattr__(self,attr):
print "Get attribute '%s'" % attr
return getattr(self.obj,attr)
x = "slfj"
xproxy = Proxy(x)
print xproxy.upper()
# prints:
# Get attribute 'upper'
# SLFJ
I used very similar code to write a CORBA interceptor for a client in
about 15 minutes, which would have taken *much* longer in C++ or Java.
-- Paul
--
http://mail.python.org/mailman/listinfo/python-list
