a "type" is an abstract set of method signatures

def min(a: iterable(T)) -> T:
    .....

def read(f: file | str) -> str:
    "read data from a file"

def min(a: T, b: T) -> T:
    if a < b:
        return a
    else:
        return b

What about min(1, 2.5)? That ought to be valid and return a float. I guess this means that there should be some kind of typing hierarchy that explains how the various numeric types are embedded in each other. The VM already knows about these coercion rules, but the trick is to build them into the type system. I think I would like to do this using a mechanism separate from inheritance, since I really don't think that it is a good idea to require that int is a subclass of float and float a subclass of complex. But the mechanism should also be open to user-defined types; there shouldn't be mechanisms in Python that the user cannot extend (not many, anyway).

К>Поясни выделенное, плиз

interface I1:
    def fumble(name: str, count: int) -> bool:
        """docstring"""
        assert count > 0
        assert name in ReferenceTable

(Maybe) add optional declarations for static typing

def min[ T < Ordered[T] ]( a: T, b: T ) : T =
  if( a < b ) a else b

E>>def min[ T < Ordered[T] ]( a: T, b: T ) : T =
E>>  if( a < b ) a else b
E>>

class BcdNumber
    def initialize( v )
        @value = v
    end

    def to_int
        @value
    end

    def to_f
        @value.to_f
    end

    def to_s
        "bcd:#{@value}"
    end

    def <(other)
        if other.respond_to?( :to_f )
            @value.to_f < other.to_f
        elsif other.respond_to?( :to_int )
            @value < other.to_int
        else
            fail "unable to compare #{self} with #{other}"
        end
    end
end

class SimpleFraction
    def initialize( dividend, divisor )
        @dividend, @divisor = dividend, divisor
    end

    def to_f
        @dividend.to_f / @divisor
    end

    def to_s
        "(#{@dividend}/#{@divisor})"
    end

    def <(other)
        if other.respond_to?( :to_f )
            self.to_f < other.to_f
        else
            fail "unable to compare #{self} with #{other}"
        end
    end
end

def min(a, b)
    if a < b then a else b end
end

b = BcdNumber.new( 5 )
s = SimpleFraction.new( 1, 3 ) # 1/3

puts min( b, 6 )    
puts min( b, 4 )    
puts min( b, 4.99 ) 
puts min( b, 5.01 ) 
puts min( b, s )    
puts min( s, b )    
puts min( s, 0.2 )  
puts min( s, 0.34 )

bcd:5
4
4.99
bcd:5
(1/3)
(1/3)
0.2
(1/3)

def doSomething[t]( v: t ) { ... }

val b : BcdNumber = ...
val s : SimpleFraction = ...

// 1)
doSomething( min( b, s ) );

// 2)
if( b < s )
  doSomething( b )
else
  doSomething( s )

interface I:
    def foo(x: int) -> str:
        "The foo method."
        assert x > 0

Here the metaclass would replace C.foo with a wrapper that (1) checks that exactly one argument is passed, (2) checks that it is an int, (3) executes the body of the method declared in the interface (which in this example checks that x is > 0), (4) calls the method implementation; (5) checks that the return value is a string; and (6) returns the return value.

FR>Мне тоже самое кажется насчет тебя

Ну и кроме того обозначены и некторые проблемы которые например в том же окамле (а он типизирован по второй схеме) не разрешены.

FR>interface I:
FR>    def foo(x: int) -> str:
FR>        "The foo method."
FR>        assert x > 0
FR>

Methods in interfaces should not declare "self" as an explicit argument.

Design By Contract, Eiffel's approach to integrating pre- and post-conditions into the type system, was recommended frequently (also in the past) and I would love to do something with this. Thinking aloud, perhaps the body of a method declaration in an interface could be interpreted as code implementing the precondition? I had previously thought that interfaces could use this syntax:

interface I1:
    def fumble(name: str, count: int) -> bool:
        """docstring"""

Now it seems easy enough to extend this by allowing additional code in the body following the docstring, for example:

interface I1:
    def fumble(name: str, count: int) -> bool:
        """docstring"""
        assert count > 0
        assert name in ReferenceTable

(But what to do for the postcondition? Perhaps we could use a nested function with a designated name, e.g. check_return().)

C>Я прошу прощения за оффтоп... Не первый раз встречаюсь с фразой "утиная типизация". Это что за зверь такой?

interface IMyInterface
{
  void Foo();
  void Bar(int i);
}

class MyClass1 // наследования от интерфейса IMyInterface нет
{
  void Foo() {}
  void Bar(int i) {}
}

class MyClass2 // наследования от интерфейса IMyInterface нет
{
  void Foo() {}
  void Bar(int i, int j) {}
}

static class Test
{
  static void Method(IMyInterface mi)
  {
  }
}

void Main()
{
  Test.Method(new MyClass1()); // OK
  Test.Method(new MyClass2()); // Fail, сигнатуры методов не удовлетворяют интерфейс IMyInterface
}

#ifndef _MODULE_NAME
#define _MODULE_NAME

...

#endif

def min(a: T, b: T) -> T:
if a < b:
return a
else:
return b

As a (rather unpythonic) strawman, I'm using T and T0, T1, T2, etc. as type variables. You can think of these as the free variables in an equation of types; we're saying that the types of a, b and the (unnamed) return value must all be the same. So min(1, 2) is valid and returns an int; min("a", "b") is valid and returns a string.

What about min(1, 2.5)? That ought to be valid and return a float. I guess this means that there should be some kind of typing hierarchy that explains how the various numeric types are embedded in each other. The VM already knows about these coercion rules, but the trick is to build them into the type system. I think I would like to do this using a mechanism separate from inheritance, since I really don't think that it is a good idea to require that int is a subclass of float and float a subclass of complex. But the mechanism should also be open to user-defined types; there shouldn't be mechanisms in Python that the user cannot extend (not many, anyway).