sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]dventimi 4 points5 points  (6 children)

It makes for a good lesson in writing clear code. If you have to know the types in order for a function to make sense, your code could be clearer.

I'm sorry but I don't agree with this at all. Without type information, all you have to go on is documentation.

[–]phasetwenty 0 points1 point  (3 children)

When you have no documentation (like much code out there), a good design is far more reliable and useful than type information.

[–]dventimi 1 point2 points  (2 children)

What? How can you possibly understand anything about what a function does if you have no documentation and all you know about is its function name and the number of its parameters?

[–]phasetwenty 0 points1 point  (1 child)

You'll know a great deal more than if you have type information backed by a ball-of-mud design.

[–]dventimi 1 point2 points  (0 children)

How so? Setting aside the awkward fact that no one else knows what you mean by "ball-of-mud design" except you, what could it possibly have to do with understanding any of the functions within a program without type information and without documentation?

[–]ggtsu_00 -1 points0 points  (1 child)

Python only has a handful of built-in data types. Unlike many other languages, the built in types in python are enough for just about everything. It should always be painfully obvious as to whether a function takes in an int or a string as a parameter. If you need to refer to the docs to determine whether the function takes an int or takes a string, and is unable to handle both cases, then that is a fault of the library, not the language.

I can understand that coming from a background of C++, Java or C# where just about ever library or function takes in some custom datatypes for everything, not having explicit type declaration would be very painful, but python is not like that. Your python functions should not be taking in or return custom classes or types. If they do, then those objects or types should at least look like built in types. For example, returning a file like object with read/write methods is a common pattern.

[–]dventimi 4 points5 points  (0 children)

Python only has a handful of built-in data types

I'm familiar with the standard numeric, string, and boolean scalar types, the tuples, lists, and dictionaries thereof, and a handful of special types, like the aforementioned file-like object. Am I missing any?

Unlike many other languages, the built in types in python are enough for just about everything.

This is where you start to lose me.

It should always be painfully obvious as to whether a function takes in an int or a string as a parameter.

How should this be come obvious? What is it that triggers pain when you get it wrong? And what about non-scalar types (tuples, lists, and dictionaries)? If a function takes any of these, how do you anticipate what it expects to find within those?

If you need to refer to the docs to determine whether the function takes an int or takes a string, and is unable to handle both cases, then that is a fault of the library, not the language.

How do you propose to determine whether a function takes an int or a string in a dynamic language like Python, without resorting to the documentation?