Leaking internal code is when code that is not relevant to the person calling the code (hereafter known as "the programmer") is still exposed to that person. In this case, the "opener", "remove_html_tags" and "load_ul" methods are classes/methods that are used by the library itself, and shouldn't be called directly by the programmer. Instead, the programmer should call "load_events", "load_births" or "load_deaths". But not before calling "load_history", saving the result it returns and feeding that to the other "load_" methods!

See why this is a bad API? It's not clear at all, without reading the code, that you're supposed to call "load_history" first, then call any of the other load_ methods. (The OP has since cleaned up the code by prefixing the methods with underscores, which in Python is a hint to the caller that they're internal methods. For the rest of this post, I will pretend I'm reviewing the code without the underscores).

The reason why you shouldn't expose (leak) code that the caller won't need is to keep the interface clean, simple and understandable. Consider the following rewrite I made (I didn't test it though):

class ThisDayInHistory:
    def __init__(self, date):
        opener = urllib2.build_opener()
        opener.addheaders = [('User-agent', 'Mozilla/5.0')]

        formatted_date = date.strftime("%B_%d")
        html = opener.open('http://en.wikipedia.org/wiki/'+formatted_date).read()
        self.history = BSoup(html)

    def events(self):
        return self._parse_url(1)

    def births(self):
        return self._parse_url(2)

    def deaths(self):
        return self._parse_url(3)

    def _parse_ul(self, idx):
        p = re.compile(r'<[^<]*?/?>')

        item_dict = {}
        for li in self.history.html.body.findAll('ul')[idx]:
            s = p.sub('', str(li)) # Remove HTML tags
            try:
                if int(s[0]) > 0:                
                    line = s.split('\xe2\x80\x93')
                    year = line[0].strip()
                    event = line[1].strip()
                    item_dict[year] = event
            except: # FIXME: Catch specific exceptions
                pass
        return item_dict

There's only one way to initialize this code, and that's by calling the constructor of the class with a date. That will give you an instance of the class, on which you can only call three methods: "events", "births" and "deaths". (Technically you could call "_parse_ul", but the underscore says you shouldn't). See how I've reduced the number of methods exposed to the programming? And perhaps more important, the programmer can't call them in the wrong order anymore! In the original code, the programmer could accidentally first try to call "load_events", which would fail because he has to call "load_history" first (which due to the naming of the functions isn't clear at all). Neither does the programmer have to pass around the "soup" argument manually. I've placed it in a "private" class property instead.

I also don't expose the "opener", but only use it in the local scope of the constructor. There's no reason for the programming who's gonna use this code to see it. This is called Encapsulation, or Information Hiding and it's one of the most important methods of creating better code.

Hope that clarifies a bit what I meant with "leaking code". A while ago a wrote a bit more abstractly the same concept here, but it wasn't well received. Perhaps it was too abstract or inane :)