Strong typing implementation for Python

[Bartc]

On 09/10/2015 17:26, John Michael Lafayette wrote:
> I would like Python to have a strong typing feature that can co-exist
> with the current dynamic typing system. Currently Python is like this:
>
>      var animal = Factory.make("dog")  # okay.
>      var dog = Factory.make("dog")       # okay.
>      var cat = Factory.make("dog")        # are you sure?

AFAIK (I'm not an expert) that isn't Python. And you wouldn't expect 
Python to know about the names of animals and their relationships to 
each other so that it can give that sort of warning.

> I would like Python to also be able to also do this:
>
>      Animal a = Factory.make("dog")    # okay. Dog is Animal.
>      Dog d = Factory.make("dog")         # okay. Dog is Dog.
>      Cat c = Factory.make("cat")           # Runtime error. Dog is not Cat.

It seems you're looking for a radically different language (statically 
typed amongst other things).

But I think you can define Animal, Dog and Cat such that you can write this:

     a = Factory.make(Animal,"dog")
     d = Factory.make(Dog,"dog")
     c = Factory.make(Cat,"cat")

and program it so that it behaves the way you want. That doesn't need 
any language changes.

> With a strong typing option that performs runtime type checking, the
> reader can be certain that the program is running the type they expect.
> Also, the IDE can be more helpful. Example:
>
>      var dog = Factory.make("dog")  # okay
>      dog. (Ctr+Space)                       # Auto-complete lists only
> Animal methods.

Even as a non-expert, I know that is not possible unless it is 
completely transformed (or you are running it interactively).

Neither the IDE nor the Python bytecode compile can know what Factory or 
make are going to be until runtime, and even then, not until it's about 
to execute that line (and perhaps not even by that point sometimes, if 
the evaluation of the line can change the meaning of Factory).

> This feature can be completely optional and could be integrated without
> anyone noticing. If it is integrated, only the people who want this type
> safety would have to use it. If there is a performance penalty, it would
> mainly affect the people who use this feature. Given that a lot of
> people transition from C/C++/Java to Python, I think that this feature
> would be intuitive to many users and a good addition for people who like
> type safety.

Remember that Python allows this:

   if randombit():   # 1 or 0
      import A
   else:
      import B

A defines Factory as that complex class or whatever you had in mind. 
While B defines Factory as:

   Factory = 42

-- 
bartc