Опциональная типизация для Python

Только если опциональная.

На первый взгляд выглядит еще бесполезнее, чем типы в Typed Racket.

Предлагает хинты указывать в коментах?

x = []  # type: Sequence[int] 

AnyStr = Var('AnyStr', str, bytes) 
def longest(a: AnyStr, b: AnyStr) -> AnyStr
y = longest('a', b'abc')  # Fails static type check 

Наконец-то.

Я джва десятилетия ждал!

Неплохо, а раз это «Guido van Rossum, Dec 19, 2014» пишет, то есть шанс что будет поддерживаться всеми исполняющими средами.

Ради этого стоит всем ползти в сторону python-3.x, вот это уже серьезный стимул миграции.

Толку от такой типизации

Толку от такой типизации

Есть опыт использования?

Мне внутренняя ванга говорит, что не взлетит, так что нефиг радоваться. Не, а реально, какие проблемы ты планируешь ей решить?

Мне внутренняя ванга говорит, что не взлетит

Я вообще не о взлете спрашивал, а об опыте.

какие проблемы ты планируешь ей решить?

Я рассчитываю использовать «ее» для статической проверки программ.

Я не очень большой спец по статической типизации и петону, но по-моему в языках со слабой типизацией, где

3*1.0 = 3.0 (int*float = float), причем int и float друг с другом никак не связаны

или [1]*2 = [1,1] list * int = list

устраивать какую-то статическую проверку типов - это что-то не то. Как вообще определить, окей или не окей умножать mytype на mytype в статике?

Я не очень большой спец по статической типизации и петону, но по-моему в языках со слабой типизацией

Большое спасибо, достаточно.

Предлагает хинты указывать в коментах?

«To help with type inference in complex cases».

Я надеялся, что ты всё расскажешь, умник

У Python сильная типизация.

Начни с объяснения того, почему при умножении int на float получается именно float. Компилятор экстрасенс? Почему он неявно приводит тип int к float? Какие ещё есть «особые случаи»? В том же строго типизированном Common Lisp * умножает number и проблем с неявным приведением типов нет.

Я надеялся, что ты всё расскажешь

А я надеялся, что ты.

При сильной типизации нет неявного приведения типов, разве нет? Или как тогда работает умножение int на float?

Облом. Мне ещё и про питон надо рассказать, потому как я на нём почти не писал

Почему он неявно приводит тип int к float?

Он ничего не приводит, объект float умеет умножаться на int.

Тебя послушать, так java это слабо типизированный язык, потому что умеет умножать int на float.

А как это реализовать средствами самого питона, скажем, с собственными классами myint и myfloat?

Реализуешь метод __mul__(...)

нужно возвращать NotImplemented, а не делать assert 0

Т.е. В каждом классе я должен реализовать __mul__ для всех вариантов, т.е

myint*myfloat myfloat*myint myint*myint myfloat*myfloat

И это даже с диспетчеризацией только по первому аргументу. Нафига эта «сильная» типизация такой ценой? Ни typeclass'ов, ни ООП нормального. Лучше бы неявно приводили

Т.е. В каждом классе я должен реализовать __mul__ для всех вариантов

Нет, только у float который обрабатывает два типа в __mul__(...).

И это даже с диспетчеризацией только по первому аргументу. Нафига эта «сильная» типизация такой ценой? Ни typeclass'ов, ни ООП нормального. Лучше бы неявно приводили

Какую-то хрень несёшь не понимая смысла слов которыми её составляешь.

Нет, только у float который обрабатывает два типа в __mul__(...).

Ну-ну. Попизди мне тут

#!/usr/local/bin/python

class myfloat(object):
    def __init__(self, num):
        self.num = num

    def __mul__(self, b):
        if isinstance(b, myfloat):
            return self.num*b.num
        elif isinstance(b, myint):
            return self.num*b.num
        return NotImplemented

class myint(object):
    def __init__(self, num):
        self.num = num

i = myint(12)
f = myfloat(1.0)

print(f*i)
print(i*f)

Да, есть одна неточность. Нужно определить два метода, __mul__() и __rmul__() с одинаковым телом.

Ну и вернемся к выводу типов. Допустим, у нас есть самописные классы для int, float и double. При умножении int на float, получаем float, float на double получаем double. Как мне сделать автоматическое выведение типов для их произведения? Как выведение типов будет работать со встроенными классами?

Допустим, у нас есть самописные классы для int, float и double. При умножении int на float, получаем float, float на double получаем double. Как мне сделать автоматическое выведение типов для их произведения?

А это принципиально отличается от любых других классов?

Просто ответь на вопрос

def plus(a, b): return double(a+b)

И он будет знать заранее, что от plus вернется значение типа double?

И он будет знать заранее

Алгоритм вывода типа тривиально выведет тип функции plus. Кого ты называешь «он», «заранее» по сравнению с чем - ХЗ.

Ну и вернемся к выводу типов.

Не нужно ни к чему возвращаться, мог бы сам уже давно придумать ответы на все свои вопросы.

1. В полностью динамическом ЯП вроде питона тип определяется по факту возвращаемого объекта, никакого вывода нет. Тот же __mul__() может вернуть что угодно и заранее не ясно что.

2. Хрень из топика ситуацию никак не меняет, она использует необязательные хинты которые ни к чему не обязывают даже если они указаны. Так по крайней мере в текущей реализации и навряд ли такое поведение будут ломать.

man asm.js

Как вы с машиной друг другу противоречите, это супер.

Как вы с машиной друг другу противоречите, это супер.

И в чем противоречие? Только конкретно.

почему при умножении int на float получается именно float. Компилятор экстрасенс?

Осиль уж документацию https://docs.python.org/2/library/stdtypes.html#numeric-types-int-float-long-...

When a binary arithmetic operator has operands of different numeric types, the operand with the “narrower” type is widened to that of the other, where plain integer is narrower than long integer is narrower than floating point is narrower than complex. Comparisons between numbers of mixed type use the same rule. [2] The constructors int(), long(), float(), and complex() can be used to produce numbers of a specific type

man asm.js

Это из другой оперы. Там всё сделано для того, чтобы код был статически типизирован.

Доки читить не Ъ? https://docs.python.org/2/reference/expressions.html#binary-arithmetic-operat...

The * (multiplication) operator yields the product of its arguments. The arguments must either both be numbers, or one argument must be an integer (plain or long) and the other must be a sequence. In the former case, the numbers are converted to a common type and then multiplied together. In the latter case, sequence repetition is performed; a negative repetition factor yields an empty sequence.

Вот какое отношение всё, что ты понаписал имеет к статической типизации и выводу типов?

Алгоритм вывода типа тривиально выведет тип функции plus. Кого ты называешь «он», «заранее» по сравнению с чем - ХЗ.

1. В полностью динамическом ЯП вроде питона тип определяется по факту возвращаемого объекта, никакого вывода нет. Тот же __mul__() может вернуть что угодно и заранее не ясно что.

Я сегодня вместо анонiмуса

http://pastebin.com/d2jVpBQQ

Алгоритм вывода типа тривиально выведет тип функции plus. Кого ты называешь «он», «заранее» по сравнению с чем - ХЗ.

1. В полностью динамическом ЯП вроде питона тип определяется по факту возвращаемого объекта, никакого вывода нет. Тот же __mul__() может вернуть что угодно и заранее не ясно что.

Я же просил конкретно указать, где ты увидел противоречие. В приведенных высказываниях его нет. Алгоритм вывода в самом деле выведет тип plus; но в Python не используется никакой алгоритм вывода.

Топик о _разработке предложения_ по добавлению некоторой формы статической типизации в Python (эта форма будет включать в себя некоторый вывод типов); в чем я и mashina не сходимся, так это в полезности такого добавления.

Алгоритм вывода в самом деле выведет тип plus;

Нет, не виведет даже в таком простом случае. Потому что...

>>> class One(object):
...     def __init__(s, val): pass
...     
... 
>>> class Two(object):
...     def __init__(s, val): pass
...     
... 
>>> plus = lambda x,y: double(x+y)
>>> double = One
>>> type(plus(1,2))
<class '__main__.One'>
>>> double = Two
>>> type(plus(1,2))
<class '__main__.Two'>
>>> 

Не заметил, что в моем примере было переопределение double.

тоже самое, что и твои примеры с «неявным» и «друг с другом не связанным».

ВНЕЗАПНО, нормальные доки и их осиляторство, вместе с тестами, могут вполне заменить стат. типизацию.