On Fri, Jun 6, 2014 at 7:23 AM, Mark Lawrence <breamore...@yahoo.co.uk> wrote: > On 05/06/2014 21:07, Alain Ketterlin wrote: >> >> Sturla Molden <sturla.mol...@gmail.com> writes: >> >>> On 05/06/14 10:14, Alain Ketterlin wrote: >>> >>>> Type safety. >>> >>> Perhaps. Python has strong type safety. >> >> Come on. > > I don't understand that comment, please explain.
"Type safety" means many different things to different people. What Python has is untyped variables, and hierarchically typed objects. It's impossible to accidentally treat an integer as a float, and have junk data [1]. It's impossible to accidentally call a base class's method when you ought to have called the overriding method in the subclass, which is a risk in C++ [2]. If you mistakenly pass a list to a function that was expecting an integer, that function will *know* that it got a list, because objects in Python are rigidly typed. But some languages stipulate the types that a variable can take, and that's something Python doesn't do. If you want to say that this function argument must be an integer, you have to explicitly check it inside the function. (And the Pythonic thing to do is to *not* check it, but that's a separate point.) This is something that function annotations can be used for, but I'm not seeing a huge thrust to make use of them everywhere. Why not? I suspect because the need for it just isn't as great as some people think. ChrisA [1] Note that in some circumstances, you can (deliberately) fiddle with an object's type. But you can't just reinterpret the bits in memory, the way you can in C, by casting a pointer and dereferencing it. Hence, it's impossible to *accidentally* muck this up. [2] Again, you can muck things up, by explicitly pulling up a function from the base class, rather than using method lookup on the object. But again, you can't do it accidentally. -- https://mail.python.org/mailman/listinfo/python-list
