OT: This Swift thing

[Marko Rauhamaa]

I don't understand that comment, please explain.

I guess what is referred to is static typing. It serves two purposes:

1. It makes the managers of software development teams believe the
junior developers in their teams won't be able to do too much damage
as the compiler at least enforces some rigor in the code. Hence,
"safety."

2. It makes it much easier to automatically optimize the code.

Unfortunately, it also has serious downsides:

3. The code becomes very tedious to type in. You may need hundreds of
lines of boilerplate code before it actually does anything. It also
easily makes you lose your focus.

4. The flow of the code becomes hard to understand because of the
boilerplate. Ironically, the very straitjacket that seeks to force
good quality on you prevents you from seeing the forest for the
trees.

Example:


Map<StreetAddress, ZipCode> makeStreetAddressMap(
List<StreetInfo> infoList) {
Map<StreetAddress, ZipCode> map =
new HashMap<StreetAddress, ZipCode>();
for (StreetInfo info : infoList)
map.put(info.getStreetAddress(), info.getZipCode());
return map;
}

vs

def make_street_address_map(info_list):
map = {}
for info in info_list:
map[info.get_street_address()] = info.get_zip_code()
return map

or:

def make_street_address_map(info_list):
return dict((info.get_street_address(), info.get_zip_code())
for info in info_list)


Marko

 

[Mark Lawrence]

I don't understand that comment, please explain.

I guess what is referred to is static typing. It serves two purposes:

1. It makes the managers of software development teams believe the
junior developers in their teams won't be able to do too much damage
as the compiler at least enforces some rigor in the code. Hence,
"safety."

2. It makes it much easier to automatically optimize the code.

Unfortunately, it also has serious downsides:

3. The code becomes very tedious to type in. You may need hundreds of
lines of boilerplate code before it actually does anything. It also
easily makes you lose your focus.

4. The flow of the code becomes hard to understand because of the
boilerplate. Ironically, the very straitjacket that seeks to force
good quality on you prevents you from seeing the forest for the
trees.

Example:


Map<StreetAddress, ZipCode> makeStreetAddressMap(
List<StreetInfo> infoList) {
Map<StreetAddress, ZipCode> map =
new HashMap<StreetAddress, ZipCode>();
for (StreetInfo info : infoList)
map.put(info.getStreetAddress(), info.getZipCode());
return map;
}

vs

def make_street_address_map(info_list):
map = {}
for info in info_list:
map[info.get_street_address()] = info.get_zip_code()
return map

or:

def make_street_address_map(info_list):
return dict((info.get_street_address(), info.get_zip_code())
for info in info_list)


Marko

Interesting. We've gone from "Python has strong type safety" to "come
on" to "I guess what is referred to is static typing". I'll simply say
that I understand Python to be strongly, dynamically typed.

 

[Terry Reedy]

Cython is not Python, it is another language, with an incompatible
syntax.

Cython compiles Python with optional extensions that allow additional
speed ups over compiling Python as is. In other word, the Cython
language is a Python superset.

 

[Sturla Molden]

But this is true of any IO-bound program, whatever the language.

Exactly, this is true even with Swift. The Swift and the Python program
would spend most of the time doing the same thing (idle processing). Thus a
GUI program written in Python would not exhaust the battery faster than a
program written in Swift. In both cases, the majority of the wall time is
spent inside the kernel waiting for some UI event (keyboard, mouse,
whatever). And in both cases the battery is spent lighting up a screen that
is mostly static. And in both bases the graphics displayed on the screen is
generated inside some UI framework written in Objective-C.

Sturla

 

[Sturla Molden]

Come on.

You cannot spoof the type of an object in Python. In C++ you can downcast
any address to void* and make an object be treated as anything. You cannot
make Python treat an int as a float and return garbage. Types in Python are
strictly enforced.

Sturla

 

[Sturla Molden]

Many of these students suggest Python as the
development language (they learned it and liked it), and the suggestion
is (almost) always rejected, in favor of Java or C# or C/C++.

And it was almost always the wrong decision...

Sturla

 

[Sturla Molden]

"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].

Exactly.

I have no hopes that those who claim Python lacks type safety will
understand this, however.

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.

And then there is nothing that prevents the function from raising a
TypeError.


Sturla

 

[Steven D'Aprano]

Come on.

No, Sturla is correct. Python has strongly-typed values and dynamically-
typed variables, which means that you get type errors at run-time, not
compile-time. But you still get type errors:

py> '1' + 2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: Can't convert 'int' object to str implicitly


[...]

Cython is not Python, it is another language, with an incompatible
syntax.

Cython is best considered a superset of Python, with a pure-Python
compatibility mode. It can run standard Python code.

 

[Chris Angelico]

You cannot spoof the type of an object in Python.

Not without fiddling around. Python 3.4 on win32:
def spam(self):
print(self,"spams")
def spam(self):
print(self,"eats spam")
<__main__.Bar object at 0x0169AB10> eats spam

The thing has the same id (as shown in its repr), but has changed
class. However, you can't turn it into an int:
Traceback (most recent call last):
File "<pyshell#36>", line 1, in <module>
x.__class__ = int
TypeError: __class__ assignment: only for heap types

So there are limits. (Obviously with ctypes you can do anything, but
at that point, you're not working with Python any more, you're
fiddling with CPython's RAM. That's quite different.)

ChrisA

 

[Mark Lawrence]

And it was almost always the wrong decision...

Sturla

s/almost//

 

[Sturla Molden]

I have seen dozens of projects where Python was dismissed because of the
lack of static typing, and the lack of static analysis tools.

If you are worried your code will bring down the next Ariane launch, I
can understand this argument. If you are only worried a junior developer
will make stupid mistankes that the test suite will trap, then no...

In Python you cannot spoof an object's type, which means the type safety
is strong. You cannot make Python silently return bytes of garbage by
using objects of incompatible types. You cannot add a char to a float,
and you cannot make a bit be treated bitwise as a float. You cannot make
Python silently treat four bytes as an int. The worst thing that can
happen is a TypeError raised at run-time. Yes, an unhandled TypeError
exception could in theory bring down Ariane. But you are probably not
developing for it.

When is static analysis actually needed and for what purpose? The
problem seems to be that managers, team leaders, CEOs, or (insert your
favorite tite), are not qualified to answer this question. So to be on
the safe side they go for as much static analysis as possible. But still
they avoid Ada, because, you know, the journals they read are full of
Java buzzwords.


Sturla

 

[Sturla Molden]

s/almost//

Sometimes it is the right decision, like when your code is firmware for
some avionics or medial life-support apparatus.


Sturla

 

[Roy Smith]

If you are worried your code will bring down the next Ariane launch, I
can understand this argument. If you are only worried a junior developer
will make stupid mistankes that the test suite will trap, then no...

In Python you cannot spoof an object's type, which means the type safety
is strong. You cannot make Python silently return bytes of garbage by
using objects of incompatible types.

Well, you *can* play evil games with the struct module

 

[Sturla Molden]

Well, you *can* play evil games with the struct module

But then you are asking for it, it does not happen by accident.

Sturla

 

[Steven D'Aprano]

I'll simply say that I
understand Python to be strongly, dynamically typed.

Correct.

Anyone who hasn't done so needs to read this:

http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/


I wouldn't quite go so far as to say that weakly typed is a meaningless
concept, but I would agree that there are degrees of weakness.

 

[Steven D'Aprano]

You cannot spoof the type of an object in Python.

Not without fiddling around. Python 3.4 on win32: [...]<__main__.Bar object at 0x0169AB10> eats spam

The thing has the same id (as shown in its repr), but has changed class.

That's not spoofing types. That is a language feature: within limits,
instances can change their type. It has been around for a long, long
time, back to Python 1.5 or older, and it has real-world use-cases:

http://code.activestate.com/recipes/68429-ring-buffer/

 

[Chris Angelico]

You cannot spoof the type of an object in Python.

Not without fiddling around. Python 3.4 on win32: [...]

x = Foo()
x.spam()

x.__class__ = Bar
x.spam()

<__main__.Bar object at 0x0169AB10> eats spam

The thing has the same id (as shown in its repr), but has changed class.

That's not spoofing types. That is a language feature: within limits,
instances can change their type. It has been around for a long, long
time, back to Python 1.5 or older, and it has real-world use-cases:

http://code.activestate.com/recipes/68429-ring-buffer/

True, it's not *spoofing*, in the same way that this C code is:

float x = 3.14159;
int y = *(int *)&x;

And I'm aware that it's a language feature (why else would it be
specifically limited with a clear exception when you try to assign
something you can't?). So's the C-level fiddling, albeit for different
reasons and in different ways. Anyway, I was broadly agreeing -
Python's type system is "objects have types", rather than "stuff is in
memory and data types are just how you look at it". It just happens to
be possible to fiddle if you want to

ChrisA

 

[Steven D'Aprano]

When is static analysis actually needed and for what purpose? The
problem seems to be that managers, team leaders, CEOs, or (insert your
favorite tite), are not qualified to answer this question. So to be on
the safe side they go for as much static analysis as possible.

Replace "as much as possible" with "the bare minimum provided by the
compiler", and you will be usually right

Managers rarely choose languages like Haskell or Ada(?) where programs
can be provably shown to be correct. They choose languages with just
enough compile-time type checking to get in the way of rapid development,
but not enough to lead to actual correct code.

Some want languages like C that offer type-checking, but not languages
like Pascal and its derivatives which enforce that type-checking --
Pascal is a "bondage and discipline" language, while C lets you escape
from the discipline of types with the freedom of casts and other
dangerous weak-typing features.

 

[Travis Griggs]

Swift's memory management is similar to python's (ref. counting). Which
makes me think that a subset of python with the same type safety would
be an instant success.

Except that while you don't need to regularly worry about cycles in python, you do in swift. Which means you get to think constantly about direct and indirect cycles, figure out where to put weak stuff, when to use a local to keep a weak property alive until it finds it's strong home, etc.

 

[Alain Ketterlin]

Except that while you don't need to regularly worry about cycles in
python, you do in swift.

Right. You can't just ignore cycle in Swift.

Which means you get to think constantly about direct and indirect
cycles, figure out where to put weak stuff, when to use a local to
keep a weak property alive until it finds it's strong home, etc.

Well, I don't consider this a bad trade-off. Deciding which refs are
weak and which are strong, or even designing an explicit deallocation
strategy, are design decisions.

-- Alain.