Casey Hawthorne wrote: > I have heard, that one should always use objects when programming and > avoid the builtin types!
Who told you that? Some university teacher with no industrial experience? ;^) It's not good advice in Python programming, for two reasons. - It can influence performance significantly, since Python is so dynamic. You could change the behaviour of a class, or change the class of an instance in runtime. This means that the Python runtime system needs to look up a lot of things repeatedly for class instances. For ints and floats etc, it doesn't need to do that. - In general, Python doesn't rely on types so much for enforcing things. The good way to ensure correct Python code is with automated tests, and it's considered good practice to design your APIs so that they require as little as possible from the parameters passed in. Stricter typing means tighter coulpling, and thus a bigger maintenance burden. For e.g. C++, I think it could often be a good idea to use more specialzed classes, particularly if you want the compiler to help you with type checking. I've rarely seen it used in practice though. The problem with using the compiler to verify that the code is correct is that while it can check types (and do it better if they are more specific) it still can't verify that the code actually does what you want it to do, just that it does *something* which is legal C++. So, in the end you still need automated tests to verify the program in a systematic way, and these tests will find those type errors even if you don't write a lot of specialized classes. I mean, if you have a full set of tests, and all tests run OK, your program is correct, whatever types you used in various places. It might not be ideal, but it's correct. Your classes will mainly be a rigid way of documenting your API. -- http://mail.python.org/mailman/listinfo/python-list
