OT: This Swift thing

Chris Angelico rosuav at gmail.com
Thu Jun 5 17:36:33 EDT 2014


On Fri, Jun 6, 2014 at 7:23 AM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> On 05/06/2014 21:07, Alain Ketterlin wrote:
>>
>> Sturla Molden <sturla.molden at 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.



More information about the Python-list mailing list