Yes, but it's a hack, isn't it? I used to do this with the sorted lists and binary sort trees for my students. For instance, I would put in a "try: new_element > first_element; except: TypeError" to make sure the type of the new element was comparable with those in the data structure.
Then I realised that I could let Python raise the error, and all I had to do was surround the actual insert call with a try/except guard. I don't know, it felt more pythonic. Then I wondered again whether the exception shouldn't be caught inside the data structure's method. But what should it do? It's going to throw a TypeError anyway, because in Python 3 you can't compare a string to an int, for instance, so you can't insert a string in a bst or sorted list that's full of ints so far. I like your solution, I might do it from now on. Put first an unguarded expression that might go boom, so it goes boom early. Brilliant. It's still a hack. Java is boring and bureaucratic about types, but this kind of problems is caught much earlier, by the compiler. So, tradeoffs. Could be that statically typed languages with type inference and duck-type generics is what it's at. On Wed, Sep 4, 2013 at 10:31 AM, Lars Yencken <[email protected]> wrote: > (completely on the programming side) > > I haven't mastered it, but there seems to be an art to testing your type > assumptions early in Python. > > For example, if you are expecting to be passed in a list that you're going > to append to, or some compatible duck type, you might add a statement to the > top of your function: > > def f(l): > append = l.append > ... > append(v) > > at the top of your code. If you get some other incompatible type, it fails > early rather than in the bowels of your program. These kinds of things > really help you to be productive and safe in a duck-typing world. > > > On 4 September 2013 10:04, Javier Candeira <[email protected]> wrote: >> >> On Wed, Sep 4, 2013 at 9:37 AM, dan <[email protected]> wrote: >> > Slightly off topic but don't worry you're not the only one who finds it >> > daunting: >> > >> > http://www.abc.net.au/news/2013-08-29/preference-deals-could-benefit-micro-parties-at/4920822 >> > >> > It's obviously broken and needs to be fixed but awesome that there's a >> > tool >> > to help work around it in the interim. >> >> Trying to keep the offtopic on-topic, there is an interesting >> parallell between the cognitve loads associated with preferential >> voting and the type of direct democracy practiced in California (where >> they have many ballots at each election for with particular laws or >> "initiative") and the micromanaging of types, access modifiers etc. in >> enterprisey languages such as Java. >> >> There are tradeoffs everywhere. More control means more mental load. >> Lower mental load means less control. Coming from a country where >> Parliament is picked by closed lists, I appreciate the added control >> of preference ranking for Parliament here. But it certainly adds a >> mental toll. >> >> Coming from a language like Python 2, some people appreciate type >> annotations in Python 3, so they don't have to perform guards in their >> code at runtime. >> >> At Monash we're already running our first semester of Data Structures >> and Algorithms using Python instead of Java. I'm now translating >> sample code for students's pracs, and I find myself having to decide >> at every point whether to let some type errors (like comparisons of >> uncomparables types) pass to be caught by the Python runtime, or to >> catch them and do something myself. All of those are errors that would >> be caught by the Java compiler. >> >> It's interesting to see the student forums, because most of the errors >> the students get stuck at are type errors (looking at a Node object >> instead of extracting the item, assigning a variable from a function >> that returns None), and all of those would have been previously caught >> by their IDE. Now they have do debug on the run, and use their brain >> instead of leveraging better tools. >> >> Tradeoffs. >> >> J >> >> _______________________________________________ >> melbourne-pug mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/melbourne-pug > > > > _______________________________________________ > melbourne-pug mailing list > [email protected] > https://mail.python.org/mailman/listinfo/melbourne-pug > _______________________________________________ melbourne-pug mailing list [email protected] https://mail.python.org/mailman/listinfo/melbourne-pug
