top gotchas for someone moving from a static lang (java/c#) to dynamic language like python

Question

What are the top gotchas for someone moving from a static lang (java/c#) to dynamic language like python?

It seems cool how things can be done, but renaming a method, or adding/removing parameters seems so risky!

Is the only solution to write tests for each method?

Answer 1

"Is the only solution to write tests for each method?"

Are you saying you didn't write tests for each method in Java?

If you wrote tests for each method in Java, then -- well -- nothing changes, does it?

renaming a method, seems so risky!

Correct. Don't do it.

adding/removing parameters seems so risky!

What? Are you talking about optional parameters? If so, then having multiple overloaded names in Java seems risky and confusing. Having optional parameters seems simpler.

---

If you search on SO for the most common Python questions, you'll find that some things are chronic questions.

• How to update the PYTHONPATH.

• Why some random floating-point calculation isn't the same as a mathematical abstraction might indicate.

• Using Python 3 and typing code from a Python 2 tutorial.

• Why Python doesn't have super-complex protected, private and public declarations.

• Why Python doesn't have an enum type.

The #1 chronic problem seems to be using mutable objects as default values for a function. Simply avoid this.

Answer 2

I would say that the number one gotcha is trying to write statically typed code in a dynamic language.

Dont hesitate to use an identifier to point to a string and then a list in self-contained sections of code

keys = 'foo bar foobar' # Imagine this coming in as an argument
keys = keys.split() # Now the semantically chose name for the argument can be 
                    # reused As the semantically chosen name for a local variable

don't hesitate to treat functions like regular values: they are. Take the following parser. Suppose that we want to treat all header tags alike and ul tags like ol tags.

class Parser(HTMLParser):
    def __init__(self, html):
        self.feed(html)

    def handle_starttag(self, tag, attrs):
        parse_method = 'parse_' + tag    
        if hasattr(self, parse_method):  
            getattr(self, parse_method)(attrs)


    def parse_list(self, attrs):
        # generic code

    def parse_header(self, attrs):
       # more generic code

    parse_h1 = parse_h2 = parse_h3 = parse_h4 = parse_h5 = parse_h6 = parse_header
    parse_ol = parse_ul = parse_list

This could be done by using less generic code in the handle_starttag method in a language like java by keeping track of which tags map to the same method but then if you decide that you want to handle div tags, you have to add that into the dispatching logic. Here you just add the method parse_div and you are good to go.

Don't typecheck! Duck-type!

def funtion(arg):
    if hasattr(arg, 'attr1') and hasattr(arg, 'attr2'):
         foo(arg):
    else:
         raise TypeError("arg must have 'attr1' and 'attr2'")

as opposed to isinstance(arg, Foo). This lets you pass in any object with attr1 and attr2. This allows you to for instance pass in a tracing class wrapped around an object for debugging purposes. You would have to modify the class to do that in Java AFAIK.

As pointed out by THC4k, another (more pythonic) way to do this is the EAPF idiom. I don't like this because I like to catch errors as early as possible. It is more efficient if you expect for the code to rarely fail though. Don't tell anybody I don't like it though our they'll stop thinking that I know how to write python. Here's an example courtesy of THC4k.

try: 
    foo(arg): 
except (AttributeError, TypeError): 
    raise InvalidArgumentError(foo, arg)

It's a tossup as to if we should be catching the AttributeError and TypeError or just let them propagate to somewhere that knows how to handle them but this is just an example so we'll let it fly.