3 ms·

I've been wondering about this: for personal projects, Python is compelling. But when you start working with multiple developers, the lack of compile time typ

by prewett 17y ago

I've been wondering about this: for personal projects, Python is compelling. But when you start working with multiple developers, the lack of compile time type checking seems like it would lead to a lot of subtle runtime errors. How do multi-person Python projects deal with this?

steveklabnik 17y ago
I'm a Rubyist, not a Pythonista, but the same principles apply. I love really really strongly/statically typed languages (Haskell) and really really weakly/dynamically typed languages (Ruby). Generally, it's not a problem. I have a hard time articlating why, exactly... I guess my code just tends to be short, sweet, and to the point. It's very rare that when I code in C, for example, that I try to do something that the type system wouldn't allow anyway. That's a terrible answer, my apologies. Maybe this would be better: could you provide an example of a situation where you feel that dynamic code would cause a problem? Mabye a bit of back and forth will help me figure out what I'm trying to say.
- prewett 17y ago
  Is it only you writing the code? If it's just me, generally the names of my variables imply the type ("price" is probably a float, for example). But say you're joining a project with 100 Python classes. How do you write the code so that someone else will know that the arg named "network" is a ip address string and not a network socket or a class, presumably named "Network"?
  - steveklabnik 17y ago
    Funny, my "price" would probably be an integer ;). Maybe it comes down to documentation. If I were to use some sort of function where I wasn't sure what the argument was, I'd look in the docs to see first.
dasil003 17y ago
This tends not to be a significant problem--if you pass the wrong type you find out the first time you run the code, which is probably not any later than you would have compiled it. A much more common problem are null references, but Java doesn't do anything about those either. Java is great for the enterprise because it's stable, mature, and doesn't leave any room for cleverness to fly over people's heads. However the compile-time checks don't do much to prevent difficult-to-debug errors. A more powerful type system like Haskell is much more interesting in this regard.
- matunos 17y ago
  I admit upfront that I'm a static type snob, but I have to disagree here. I've not had much experience with Pythong, but I've had plenty of experience with Perl at the enterprise software level (not just talking shell scripts here) and in my experience, a few of your statements don't hold up. You definitely compile Java code well before you run it, at least in your full enterprise environment. And if you're using an IDE, you'll probably see any type errors well before you even compile it. Sure, you might put your code through a workout with unit tests (and you should!), but any programmer knows that unit tests do not guarantee that you are using the right types in production, and they definitely do not ensure that clients of your code will be using the right types from your code. I can't count the number of times I've had to use Data::Dumper just to figure out what type of object I'm dealing with. And don't even get me started with trying to figure out the right types of arguments to pass! You are correct that the hardest bugs will be left for run-time, but why add to the hassle?

by prewett 17y ago

steveklabnik 17y ago

I'm a Rubyist, not a Pythonista, but the same principles apply. I love really really strongly/statically typed languages (Haskell) and really really weakly/dynamically typed languages (Ruby). Generally, it's not a problem. I have a hard time articlating why, exactly... I guess my code just tends to be short, sweet, and to the point. It's very rare that when I code in C, for example, that I try to do something that the type system wouldn't allow anyway. That's a terrible answer, my apologies. Maybe this would be better: could you provide an example of a situation where you feel that dynamic code would cause a problem? Mabye a bit of back and forth will help me figure out what I'm trying to say.

prewett 17y ago
Is it only you writing the code? If it's just me, generally the names of my variables imply the type ("price" is probably a float, for example). But say you're joining a project with 100 Python classes. How do you write the code so that someone else will know that the arg named "network" is a ip address string and not a network socket or a class, presumably named "Network"?
- steveklabnik 17y ago
  Funny, my "price" would probably be an integer ;). Maybe it comes down to documentation. If I were to use some sort of function where I wasn't sure what the argument was, I'd look in the docs to see first.

dasil003 17y ago

This tends not to be a significant problem--if you pass the wrong type you find out the first time you run the code, which is probably not any later than you would have compiled it. A much more common problem are null references, but Java doesn't do anything about those either. Java is great for the enterprise because it's stable, mature, and doesn't leave any room for cleverness to fly over people's heads. However the compile-time checks don't do much to prevent difficult-to-debug errors. A more powerful type system like Haskell is much more interesting in this regard.

matunos 17y ago
I admit upfront that I'm a static type snob, but I have to disagree here. I've not had much experience with Pythong, but I've had plenty of experience with Perl at the enterprise software level (not just talking shell scripts here) and in my experience, a few of your statements don't hold up. You definitely compile Java code well before you run it, at least in your full enterprise environment. And if you're using an IDE, you'll probably see any type errors well before you even compile it. Sure, you might put your code through a workout with unit tests (and you should!), but any programmer knows that unit tests do not guarantee that you are using the right types in production, and they definitely do not ensure that clients of your code will be using the right types from your code. I can't count the number of times I've had to use Data::Dumper just to figure out what type of object I'm dealing with. And don't even get me started with trying to figure out the right types of arguments to pass! You are correct that the hardest bugs will be left for run-time, but why add to the hassle?