[melbourne-pug] Data type assumptions in Python

Javier Candeira javier at candeira.com
Thu Sep 5 13:14:30 CEST 2013


 On Thu, Sep 5, 2013 at 6:27 PM, Tennessee Leeuwenburg
<tleeuwenburg at gmail.com> wrote:
> Sorry, but doesn't this just boil down to the original poster (I think
> Javier) writing a sorted-order list which only implemented some of the
> desired behaviour? There's nothing wrong with using a try:except: block in

What do you mean "only some". It preserves order over initialisation,
insertion and deletion. What else do you need?

> your insert method which logs an error, refuses to accept the item, but
> allows processing to continue, if that's what you want. It just sounds like

That should be a user option:
- The sorted list does well to raise a TypeError when you try to add
'a' to a list that contains, say, integers.
- The calling code calls sortedlist.insert() inside a try/except, and
the calling programmer gets to decide whether to forgive and continue
or abort the operation.

> an example where error-handling policy isn't defined.

But I disagree. It's clear the TypeError should be thrown.

> In leiu of actual rules about how to handle the exceptions, throwing a
> TypeError seems like very acceptable naive behaviour. Even in other
> languages, it's possible to end up with exceptions based on type issues in
> data structures, Python is not unique in that.

My point, my only point, was about diferent tradeoffs in making things
simple or giving you power.

In Java type safety is a mental load that is carried by Intellisense
in the IDE. Not that I like Java, in fact we are moving a whole unit
from Java to Python, but students used to not have these bugs, because
they didn't even consider them bugs. They were syntax errors in the
editor. So no need to put an exception guard in Java, because the type
system did it for you.

In Python genericity is a given. In Java you have to navigate
implements and extends and bounded type parameters. The mental load is
taken somewhere else.

These are tradeoffs. Type inference claims to save you from most of
the tradeoffs, allowing you to not live at either end (the dinamicity
of Python, or the bureaucratc regimented genericity of Java). But I'll
let you know when I learn a bit of Scala where I think the tradeoffs
are, what you lose when you gain strong typing with type inference.

 > Perhaps I've missed the point, but I feel like it's just the same old "in
> the face of ambiguity, resist the temptation to guess" principle.
>
> Javier, perhaps you could post your code to pastebin and we can have a more
> specific conversation?

No need. I didn't actually have questions. Just reflections, thoughts out loud.

> Also, Javier, thanks for the interesting code-related thread to discuss! :)

No worries, I'm having fun too, and learning a lot from the community.

J


More information about the melbourne-pug mailing list