Let me first say that I'm sure that this subject has come up before,
and so forgive me for beating a dead horse. Secondly, let me say that
Python's strength is its dynamic nature, and I don't believe that it
should ever require a precondition scaffolding. With that said, I do
believe that something like type hinting would be beneficial to the
Python community, both for tool enablement and for disambiguous
programming.
Here is what I mean. The following function, though conventionally
indicating that it will perform a multiplication, will yield standard
Python behaviors if a string value is passed to it:
def multiplyByTwo(value):
return value * 2
Passing 14 to it will return 28, whereas passing "14" to it will return
"1414". Granted, we know and accept that this is Python's behavior
when you multiply two values, but because we don't (and shouldn't have
to) know the inner workings of a function, we don't know that the types
of the values that we pass into it may adversly affect that results
that it yields.
Now, on the other hand, if we were to introduce a purely optional type
hint to the function prototype, such as follows:
def multiplyByTwo(value:int):
return value * 2
The python interpreter could do the work of casting the incoming
parameter to an int (if it is not already) before it is multipled,
resulting in the desired result or a typecasting error otherwise.
Furthermore, it could do it more efficiently than a developer having to
put conditional code at the beginning of traditionally typecasting
functions.
All of this wouldn't require changes to the calling code, and would be
a purely optional feature of the function declaration, one that as far
as I can tell would be backward compatible both with Python's standard
operating behavior, and it's overall grammar. This hinting would also
apply to derived class names. Functions like the one first
demonstrated would continue to operate as normal.
The additional benefit of this type hinting mechanism is that tools
like Komodo would be able to perform a "close-to-java" like amount of
code analysis and completion, even though Python would continue to be
just as dynamic as it had always been, refining Python's productivity
benefits even moreso.
This could also be extended into the realm of return types, but that
might imply imposing typing in calling code, which is why I do not
propose it as part of a type hinting system, as I believe calling code
should remain unaffected by the introduction of such a system.
The next question is how do you represent lists, maps and tuples in
this system? would it be something like this? myList:[] And if so,
do we further allow for typing hinting within the contents of the list
such as myList:[int]? There would be no harm in allowing a parameter
that is a list, map, or tuple to remain in a parameter list without
type hinting, even while other parameters retain hints.
It wouldn't be hard to prototype something like this using Jython.
Thoughts?
--
http://mail.python.org/mailman/listinfo/python-list
