Numpy: Подсказка / аннотация типа (PEP 484) для ndarray, dtype и ufunc

Я не думаю, что кто-то думал об этом. Возможно, вы хотели бы? :-)

Я также собираюсь предложить, чтобы, если вы хотите следить за этим, закрыть проблему gh и перенести обсуждение в список рассылки, так как это лучше подходит для открытых обсуждений дизайна.

Получив этот ответ на SO, я решил закрыть проблему.

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

Список рассылки обычно является лучшим местом, если вы пытаетесь начать работать над чем-то или надеетесь привлечь для помощи других заинтересованных людей.

Спасибо, @njsmith. Я решил начать здесь из-за более упорядоченного отслеживания проблем, в отличие от неструктурированного списка рассылки (среди других функций я искал тег «запрос функции» ...)

Поскольку парень, который ответил мне на SO, вернулся ко мне с жизнеспособным решением, я решил оставить этот вопрос.
Возможно, документация Numpy должна быть обновлена, чтобы включить его ответ (пожалуйста, не забудьте дать ему кредит, если вы это сделаете).

Еще раз спасибо!

Привет ребята! Я просто любезно поинтересовался, есть ли какой-либо прогресс по этому вопросу. Благодарю.

Это обсуждается в списке рассылки здесь .

Я снова открываю этот вопрос для тех, кто заинтересован в его дальнейшем обсуждении.

Я думаю, что это, безусловно, было бы желательно для NumPy, но действительно есть несколько сложных аспектов API NumPy для ввода для сортировки, например, как NumPy в настоящее время принимает произвольные объекты в конструкторе np.array (хотя мы хотим очистите это, см. https://github.com/numpy/numpy/issues/5353).

Здесь выполняется хорошая работа: https://github.com/machinalis/mypy-data

Обсуждается, следует ли продвигать работу вверх по потоку или набирать: https://github.com/machinalis/mypy-data/issues/16

CC @mrocklin

Это действительно было бы отличным дополнением к NumPy. Какими будут следующие шаги, чтобы довести это до машинного перевода или NumPy? Даже неполная заглушка была бы полезна, и я рад помочь с небольшим указанием направления?

@henryJack Лучше всего начать с инструментов: выяснить, как мы можем интегрировать аннотации базовых типов в репозиторий NumPy (и, в идеале, протестировать их) таким образом, чтобы это работало с mypy и поддерживало их добавление постепенно.

Затем начните с минимального количества аннотаций, и мы сможем продолжить. В частности, я бы пока пропустил аннотации dtype, поскольку у нас нет хорошего способа их указать (т. Е. Делать только ndarray , а не ndarray[int] ).

Если это поможет, у меня есть альтернативная версия аннотаций, которую я написал для использования в Google и мог бы иметь открытый исходный код. Но у нас есть собственная уникальная система сборки, и мы выполняем проверку типов с помощью pytype , поэтому, вероятно, возникнут причуды при ее переносе в апстрим.

Я полагаю, единственный способ проверить аннотации - запустить mypy на примерах кода и проверить результат?

Было бы лучше интегрировать аннотации с кодом или в виде отдельных заглушек?

Я полагаю, мы также должны научиться у Dropbox и pandas, что мы должны начать с листьев кодовой базы, а не с основных структур данных?

@shoyer figure out how we can integrate basic type annotations
Не было бы просто поместить https://github.com/machinalis/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyi в базовый каталог модуля numpy, чтобы сделать именно это .. В какой-то экспериментальной версии как минимум

Было бы лучше интегрировать аннотации с кодом или в виде отдельных заглушек?

Было бы прекрасно интегрировать с кодом, но я пока не думаю, что это возможно для NumPy. Даже с версией аннотации типа со строкой комментария нам нужно будет импортировать из typing на Python 2, а добавление зависимостей в NumPy в значительной степени исключено.

Кроме того, большинство основных структур данных и функций (такие как ndarray и array ) определены в модулях расширения, нам в любом случае нужно будет использовать там заглушки.

Не было бы просто поместить https://github.com/machinalis/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyi в базовый каталог модуля numpy, чтобы сделать именно это .. В какой-то экспериментальной версии как минимум

Да, думаю, для внешнего кода этого хватит. Но как mypy обрабатывает библиотеки с неполными аннотациями типов?

Если возможно, мы могли бы аннотировать numpy.core.multiarray напрямую, а не только на верхнем уровне. ( multiarray - это модуль расширения, в котором определены основные типы NumPy, такие как ndarray .) Я думаю, это позволит самому NumPy использовать проверку типов для некоторых из своих модулей на чистом Python.

Мне любопытно, что это за тип np.empty(shape=(5, 5), dtype='float32') ?

Какой тип np.linalg.svd ?

Я думаю, что @kjyv попытался их определить.

np.empty : https://github.com/kjyv/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyi#L523
np.linalg.svd : https://github.com/kjyv/mypy-data/blob/master/numpy-mypy/numpy/linalg/__init__.pyi#L13

Похоже, что типы параметризованы, это с их dtype? Возможно ли также параметризовать их размер или форму? Насколько сложен модуль набора текста Python?

Да, они параметризованы своим dtype. Я не специалист по модулю набора текста, но думаю, что вы могли бы просто наследовать тип ndarray Generic[dtype, int] для параметризации ndim . Я считаю, что именно этим занимается Джулия. Я не уверен, можно ли легко параметризовать форму. Я также не уверен, какие преимущества это принесет или почему это не было сделано таким образом вообще.

Можно ли использовать numpy dtypes в параметре dtype или это может быть только ввод
типы модулей?

Также странно, что numpy.empty возвращает массив типа Any. Я подозреваю
сложно интер и взять тип из значения ключевого слова dtype =?

1 сентября 2017 г. в 18:42 «Жак Квам» [email protected] написал:

Да, они параметризованы своим dtype. Я не специалист по набору текста
модуль, но я думаю, вы могли бы просто наследовать тип ndarray Generic [dtype,
int] для параметризации на ndim. Я считаю, что именно этим занимается Джулия. я не
конечно, если бы вы могли легко параметризовать форму. Я не уверен в чем
выгоды, которые могли бы принести или почему это не было сделано именно поэтому в первую очередь.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/numpy/numpy/issues/7370#issuecomment-326698639 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AASszMlYO7iHdoPE_GU--njIYICSVVZ0ks5seIhFgaJpZM4Hm_CR
.

Вы можете использовать numpy dtypes, нам просто нужно их определить. Это было сделано здесь с помощью floating с np.std.

https://github.com/kjyv/mypy-data/blob/24ea87d952a98ef62680e812440aaa5bf49753ae/numpy-mypy/numpy/__init__.pyi#L198

Я не уверен, я не думаю, что это возможно. Я не думаю, что вы можете изменить тип вывода на основе значения аргумента. Я думаю, лучшее, что мы можем сделать, - это перегрузить функцию всеми специализациями типов, которые нам нужны.

https://docs.python.org/3/library/typing.html#typing.overload

Другой вариант - ввести несколько псевдонимов со строгой типизацией, поэтому np.empty[dtype] - это функция с сигнатурой (ShapeType) -> ndarray[dtype] .

Уже есть прецедент с необычной функцией np.cast[dtype](x)

@jwkvam Хорошо, так что, возможно, аннотации dtype выполнимы - я просто предлагал начать с простого и двигаться дальше .

Я думаю , что TypeVar , возможно , можно было бы использовать вместо перегрузками, может быть:

D = TypeVar('D', np.float64, np.complex128, np.int64, ...)  # every numpy generic type
def empty(dtype: Type[D]) -> ndarray[Type[D]]: ...

Если я правильно понимаю, это будет означать empty(np.float64) -> ndarray[np.float64] .

Также было бы здорово иметь возможность набирать информацию о форме и размерности, но я не думаю, что текущие средства проверки типов подходят для этой задачи. Generic[int] - это ошибка, например, аргументы Generic должны быть экземплярами TypeVar :
https://github.com/python/cpython/blob/868710158910fa38e285ce0e6d50026e1d0b2a8c/Lib/typing.py#L1131 -L1133

Нам также потребуется выразить подписи с указанием размеров. Например, np.expand_dims сопоставляет ndim -> ndim+1 .

Я полагаю, что один подход, который будет работать, - это определение классов для каждого неотрицательного целого числа, например, Zero , One , Two , Three , .. ..и затем определите перегрузки для каждого. Это очень быстро утомляло.

В TensorFlow tf.Dimension() и tf.TensorShape() позволяют статически выражать формы. Но это не то, что делается в системе типов. Скорее, каждая функция имеет связанный с ней помощник, который определяет статическую форму выходных данных на основе формы входных данных и любых нетензорных аргументов. Я думаю, что нам понадобится нечто подобное, если бы мы надеялись сделать это с помощью NumPy, но в системе типизации Pythons нет ничего, что предполагало бы такую ​​гибкость.

@shoyer Понятно , это разочаровывает. Мне удалось взломать следующие

_A = TypeVar('_A')
_B = TypeVar('_B', int, np.int64, np.int32)

class Abs(Generic[_A, _B]):
    pass

class Conc(Abs[_A, int]):
    pass

Но я не думаю, что это никуда приведет ...

Похоже, ваш пример работает! Казалось, что без ограничений типа он работал лучше. Я мог тестировать такие типы, как str . Мне пришлось удалить аргумент по умолчанию, я не мог понять, как заставить его работать.

D = TypeVar('D')
def empty(shape: ShapeType, dtype: Type[D], order: str='C') -> ndarray[D]: ...

и код

def hello() -> np.ndarray[int]:
    return np.empty(5, dtype=float)

я получил

error: Argument 2 to "empty" has incompatible type Type[float]; expected Type[int]

Я немного запутался, потому что если я поменяю типы:

def hello() -> np.ndarray[float]:
    return np.empty(5, dtype=int)

Я не получаю ошибки. Хотя я не думаю, что что-то помечено как ковариантное.

Хотя система типов не такая сложная, как хотелось бы. Как вы думаете, оно того стоит? Одно преимущество, которое я был бы признателен, - это лучшее завершение кода через джедаев.

Я немного запутался, потому что если я поменяю типы:

Я считаю, что проблема здесь в том, что экземпляры int неявно считаются допустимыми для аннотаций float . См. Примечания к числовой башне при вводе PEP:
https://www.python.org/dev/peps/pep-0484/#the -numeric-tower

Я думаю, этого можно избежать, если мы будем настаивать на скалярных типах NumPy вместо общих типов Python для аннотаций, например, np.ndarray[np.integer] а не np.ndarray[int] .

На самом деле это немного проще, чем я думал, потому что TypeVar имеет аргумент bound . Итак, пересматривая мой пример:

D = TypeVar('D', bound=np.generic)
def empty(dtype: Type[D]) -> ndarray[D]: ...

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

Я не совсем понимаю, к чему вы здесь?

Я просто попытался закодировать в заглушке значение dtype по умолчанию. Они сделали это в репозитории mypy-data.

def empty(shape: ShapeType, dtype: DtypeType=float, order: str='C') -> ndarray[Any]: ...

из https://github.com/kjyv/mypy-data/blob/master/numpy-mypy/numpy/__init__.pyi#L523

Следуя вашему примеру, мне не удалось заставить mypy работать с аргументом по умолчанию для dtype. Я пробовал dtype: Type[D]=float и dtype: Type[D]=Type[float] .

Я думаю, что dtype также должен стать универсальным типом, и тогда вам нужно установить значение по умолчанию для общего подкласса numpy, такого как np.float64 а не float , например,

# totally untested!
D = TypeVar('D', bound=np.generic)

class dtype(Generic[D]):
    <strong i="9">@property</strong>
    def type(self) -> Type[D]: ...

class ndarray(Generic[D]):
    <strong i="10">@property</strong>
    def dtype(self) -> dtype[D]: ...

DtypeLike = Union[dtype[D], D]  # both are coercible to a dtype
ShapeLike = Tuple[int, ...]

def empty(shape: ShapeLike, dtype: DtypeLike[D] = np.float64) -> ndarray[D]: ...

Это не правильно. D == type(dtype.type) == type , поэтому параметризация вашего типа бесполезна, поскольку единственный используемый параметр - D = type .

@ eric-wieser упс, я думаю, теперь это исправлено.

Обсуждалась связанная с этим система отслеживания проблем mypy (в основном python / mypy # 3540). Здесь мы считаем, что основная проблема заключается в том, что массивы numpy концептуально включают свои измерения в свой тип, а текущая система типов на самом деле этого не поддерживает. Если проекты mypy или typeshed могут каким-либо образом помочь в работе с набором текста для numpy, сообщите нам об этом!

Обсуждалась связанная с этим система отслеживания проблем mypy (в основном python / mypy # 3540). Здесь мы считаем, что основная проблема заключается в том, что массивы numpy концептуально включают свои измерения в свой тип, а текущая система типов на самом деле этого не поддерживает. Если проекты mypy или typeshed могут каким-либо образом помочь в работе с набором текста для numpy, сообщите нам об этом!

Я мог бы представить здесь кодирование большей или меньшей информации параметризованными типами. Например, массив типа np.empty((2, 3)) может быть любого из следующих типов:

1. Array[float64, (2, 3)]
2. Array[float64, (n, m)]
3. Array[float64, ndim=2]
4. Array[float64]
5. Array

@JelleZijlstra, что вы

Кажется довольно очевидным, что для поддержки форм и размерности потребуется значительная работа в системе типов. Я бы приветствовал это (и просто записал кучу идей в python / mypy # 3540), но пока давайте назовем это за рамками NumPy. Просто заставить работать ndarray[float64] кажется достаточно сложным, учитывая сложную иерархию типов numpy и проблемы универсальных типов.

Да, я думаю, что первым шагом было бы просто получить базовую поддержку набора текста для numpy (а также Pandas и sklearn) без учета форм и других дополнительных ограничений для этих типов.

Проблема с другими дополнительными ограничениями заключается в том, что недостаточно просто описать dtype (shape = 5,6), но должен существовать язык для описания ограничения для этой формы. Вы можете представить, что хотите определить функцию, которая принимает только квадратные формы в качестве входных данных, или функцию, в которой одно измерение должно быть в 2 раза больше другого.

Примерно так было сделано в проекте контрактов .

Я также думаю, что здесь было бы здорово поддержать PEP 472 , потому что тогда действительно можно было бы делать такие вещи, как Array[float64, ndim=2] .

В самом деле, PEP 472 был бы удобен для набора текста, хотя, вероятно, это было бы одним из самых простых способов исправить это! (Пожалуйста, свяжитесь со мной, если вы хотите возобновить обсуждение этого вопроса, поскольку я думаю, что есть также убедительные варианты использования именованных измерений при индексировании.)

Я не уверен, как я могу внести свой вклад, но я определенно думаю, что это будет отличная функция по нескольким причинам. Но мы идем в этом направлении, и тогда кажется, что [] просто становится другим способом вызова объекта. Итак, object(*args, **kwargs) делает что-то, object[*args, **kwargs] что-то еще, а затем мы можем даже обобщить и также иметь object{*args, **kwags} и object<*args, **kwargs> . ;-)

@mitar : Глядя на это с другой стороны, возможно, нам стоит просто аннотировать что-то вроде ndarray[float].constrain(ndim=2) . У нас уже есть много доступного синтаксиса, и, в отличие от декораторов, аннотации не имеют ограничений.

На самом деле я пробовал использовать следующий синтаксис: ndarray[float](ndim=2) , поэтому перегрузка этого в дженериках __call__ снова возвращает класс, а не экземпляр класса. Но с типами, не являющимися универсальными, это стало непросто.

Я думаю, что основная проблема связана с поддержкой ndarray[float] , поскольку ndarray[float] не является чем-то, что действительно существует в ndarray , нужно было бы изменить сам ndarray , который Я не уверен, что это хороший общий принцип (изменение исходного кода для поддержки лучшего набора текста).

Еще один подход может заключаться в использовании нового типа переменных типа ConstrainedTypeVar , где вы могли бы сделать что-то вроде ConstrainedTypeVar('A', bound=ndarray, dtype=float, ndim=2) или что-то в этом роде, а затем использовать A в качестве var в сигнатуре функции. Но это становится очень многословным.

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

Основные идеи включают:

1. Добавление примитива DimensionVar который позволяет использовать символические идентификаторы для измерений массива
2. Распознавание ... ( Ellipsis ) как широковещательного массива индикации.

Например, чтобы ввести np.matmul / @ :

from typing import DimensionVar, NDArray, overload

I = DimensionVar('I')
J = DimensionVar('J')
K = DimensionVar('K')

<strong i="17">@overload</strong>
def matmul(a: NDArray[..., I, J], b: NDArray[..., J, K]) -> NDArray[..., I, K]: ...

<strong i="18">@overload</strong>
def matmul(a: NDArray[J], b: NDArray[..., J, K]) -> NDArray[..., K]: ...

<strong i="19">@overload</strong>
def matmul(a: NDArray[..., I, J], b: NDArray[J]) -> NDArray[..., I]: ...

Этого было бы достаточно, чтобы можно было набирать обобщенные функции . См. Документ для получения более подробной информации и примеров.

Возможное решение для поддержки как типов, так и фигур, если мы уже решили сохранить отличными NDArray и ndarray :

NDArray[float].shape[I, J, K]
NDArray[float]
NDArray.shape[I, J, K]

Просто подумайте, есть ли смысл иметь такой ярлык?

NDArray.ndim[2]  # NDArray.shape[..., ...]
NDArray[float].ndim[2]  # NDArray[float].shape[..., ...]

- что может упростить ряд подписей, особенно в нисходящем коде.

@aldanor Я думаю, вы имеете в виду NDArray.shape[:, :] ( ... означает «ноль или более измерений», что не совсем верно в данном контексте). Но да, это выглядит разумным.

Быстрое обновление по вводу типов dtypes: я написал игрушечный модуль, используя подход, описанный выше, который использует подклассы np.generic с Generic для параметризованных типов ndarray / dtype .

В основном это работает с mypy, как я и ожидал, включая вывод типа с эквивалентом np.empty(..., dtype=np.float32) . Он не может отловить одну из моих преднамеренных ошибок типа, связанных с типом Union (я отправлю отчет об ошибке позже).

Я думаю, что этого, вероятно, было бы достаточно для dtypes. Без поддержки ввода буквальных значений мы не смогли бы сделать вывод типа с dtype, указанным как строки ( dtype='float32' ). Возможно, более проблематично то, что он также не обрабатывает вывод типов из таких типов Python, как dtype=float . Но эти типы могут быть неоднозначными (например, dtype=int сопоставляется с np.int64 в Linux и np.int32 в Windows), поэтому, вероятно, в любом случае лучше использовать явные универсальные типы. Ничего страшного, если вывод типа не работает во всех возможных случаях, если спецификации dtype=float выводятся как dtype Any а не вызывают ошибку.

Но эти типы могут быть неоднозначными (например, dtype = int сопоставляется с np.int64 в Linux и np.int32 в Windows).

Это не двусмысленно - во всех случаях это отображается на np.int_ , который является типом C long .

Я написал список рассылки, чтобы достичь консенсуса по поводу написания заглушек типов для NumPy в отдельном пакете:
https://mail.python.org/pipermail/numpy-discussion/2017-November/077429.html

Потрясающе, спасибо @shoyer !

Согласно консенсусу в списке рассылки, я хотел бы объявить https://github.com/numpy/numpy_stubs открытым для бизнеса!

Начнем с основных аннотаций (без поддержки dtype). Если кто-то хочет собрать базовый PR, чтобы добавить строительные леса PEP 561 для репо, это будет оценено!

ДА, ДА, В 1000 раз ДА!

Внимание всем, кто следит за этой проблемой: я обнаружил две проблемы в трекере python / typing:

• ndarray типизация в целом (https://github.com/python/typing/issues/513)
• синтаксис для ввода ndarray (https://github.com/python/typing/issues/516)

Какое ожидаемое время выпуска функции набора текста?
Есть ли причина пытаться поддерживать совместимость с 2.7?
В одном из ранних комментариев упоминалась сложность интеграции с python 2. С тех пор кажется, что numpy изменил свою позицию.

Я знаю, что это движущиеся цели, но есть ли смысл ориентироваться на что-то вроде Python 3.4-3.6?

Какое ожидаемое время выпуска функции набора текста?

На PyCon было несколько дискуссий об этом (целочисленные дженерики, известные как простые зависимые типы), я скоро напишу прото-PEP на основе этих обсуждений и исходного документа, написанного @shoyer . Моя цель - написать PEP, реализовать в mypy и вовремя принять его для Python 3.8 beta 1 (также весьма вероятно последующий бэкпорт новых типов в typing для Python 2)

@hmaarrfk что касается написания аннотаций типов для самого NumPy, мы начали делать это в отдельном репозитории: https://github.com/numpy/numpy-stubs. У вас должна быть возможность установить и использовать эти заглушки в текущем состоянии (с последней версией mypy), но они далеки от завершения. Помощь будет признательна!

Конечно, я рад помочь, где могу, и я видел репозиторий. Я просто знаю, что на это нужно время.
Я видел репо и заметил, что коммит упоминает совместимость 2.7, поэтому я спросил.

Срок выпуска бета-версии Python 3.8 - середина 2019 года . Numpy упомянул, что они остановят новые функции в конце 2018 года .

Печатание кажется обязательной функцией для numpy, а не обязательной. Таким образом, таргетинг на два языка кажется немного сложным, особенно если функция начнет появляться намного позже срока поддержки собственного numpy.

Мне будет интересно прочитать, что @ilevkivskyi говорит в PEP.

@hmaarrfk Вы подняли хороший вопрос о поддержке Python 2.7. Если честно, я еще не продумал до конца. Я действительно ожидаю, что мы в конечном итоге откажемся от него, но, вероятно, не раньше, чем mypy сам откажется от поддержки Python 2.7, учитывая, что основным вариантом использования для набора текста является написание кода, совместимого с Python 2/3.

На данный момент, похоже, не требуется много компромиссов для поддержки Python 2 в наших аннотациях типов, поэтому я рад оставить его, особенно с учетом того, что он исходил от участника, который, очевидно, был в нем заинтересован.

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

В transonic , проекте по обобщению ускорителей numpy, у нас есть синтаксис подсказок типа в качестве альтернативы аннотациям Pythran, которые используют комментарии . Сейчас он плохо работает с mypy, но мне интересно, полезен ли он. См. Пример: https://transonic.readthedocs.io/en/latest/examples/type_hints.html

Если это полезно для этой проблемы, я упомяну, что я сделал инструмент для преобразования строк документации в комментарии типа: https://pypi.org/project/doc484/

Я использую это с предварительной фиксацией в нескольких проектах, чтобы синхронизировать строки документации с комментариями типа.

Вам все равно нужно будет преобразовать типы в ваших строках документации, чтобы они соответствовали PEP484.

Привет всем,

Я хотел внести свой вклад, поэтому разветвил репо и начал добавлять подсказки по типу. Моя идея заключалась в том, чтобы работать снизу вверх, поэтому начните с «простых» функций и двигайтесь оттуда вверх. (Начиная с низко висящих фруктов)

Например, в _string_helpers.py я добавил подсказки типа для некоторых переменных и функций.

LOWER_TABLE: str = "".join(_all_chars[:65] + _ascii_lower + _all_chars[65 + 26:])
UPPER_TABLE: str = "".join(_all_chars[:97] + _ascii_upper + _all_chars[97 + 26:])

def english_lower(s: str) -> str:
    """ Apply English case rules to convert ASCII strings to all lower case.
   ...
    """
    lowered = s.translate(LOWER_TABLE)
    return lowered

Что Вы думаете об этом?

Я бы порекомендовал немного поработать и открыть PR, чтобы получить комментарии. numpy нацелен на более старых питонов (аннотации, введенные в 3.5, IIRC), и это может нарушить эти сборки, поэтому, возможно, посмотрите на написание файлов .pyi или проверьте документацию mypy, чтобы узнать, есть ли немного дополнительных рекомендаций по передовым методам.

До сих пор мы делали аннотации в отдельных заглушках numpy
репозиторий, но это был медленный процесс.

В четверг, 14 ноября 2019 г., в 9:57 Бен Самуэль [email protected] написал:

Я бы порекомендовал немного поработать и открыть PR, чтобы получить комментарии. тупой
нацелен на старых питонов (3.5 введенных аннотации, IIRC), и это
нарушат эти сборки, поэтому, возможно, посмотрите на запись файлов .pyi или проверьте
документацию mypy, чтобы узнать, есть ли дополнительные рекомендации по передовым методам.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/numpy/numpy/issues/7370?email_source=notifications&email_token=AAJJFVVH5CLAHPJKWJHDQ73QTVRMXA5CNFSM4B436CI2YY3PNVWWK3TUL52HS4DFMVREXG2HS4DFMVREXG5CNFSM4B436CI2YY3PNVWWK3TUL52HS4DFMVREXG
или отписаться
https://github.com/notifications/unsubscribe-auth/AAJJFVTWTKLP63AK2C2IUW3QTVRMXANCNFSM4B436CIQ
.

@ bsamuel-ui numpy в настоящее время требует Python 3.5+, а NEP-29 [1] утверждает, что можно поднять его до 3.6+
[1] https://numpy.org/neps/nep-0029-deprecation_policy.html

Аннотации (для аргументов функций и возвращаемых типов) фактически поддерживаются во всех версиях Python 3; 3.6 только ввела аннотации переменных. В ранней версии Python 3 (<3.5) вы должны использовать бэкпорт модуля typing .

Я добавил запрос на перенос с моим первым файлом .pyi. Это требует некоторой работы, но было бы неплохо, если бы вы, ребята, могли взглянуть на него, чтобы я мог получить первоначальный отзыв

Как упоминалось в gh-14905, у нас есть начало библиотеки-заглушки в https://github.com/numpy/numpy-stubs. Было бы здорово получить это с помощью надлежащих тестов, а затем мы могли бы решить, как лучше всего его упаковать или объединить в numpy / numpy.

Мой плохой @mattip. Я удалю запрос на перенос из numpy и добавлю новый в numpy-stubs

он все еще открыт, но я считаю, что numpy уже поддерживает это в основной версии

Привет,
Я пытаюсь определить псевдоним типа для вектора 3d, поэтому массив numpy формы (3,) dtype int32.

(Я знаю, что могу ввести подсказку с помощью np.ndarray, но как мне получить более конкретную информацию? Я прочитал здесь все и не понял, я также ищу учебник о том, как использовать типы numpy для ввода в Python, но не найти что-нибудь.)

Вроде можно написать:

from typing import Tuple
VectorType = Tuple[int, int, int]

Я пробовал делать:

VectorType = np.ndarray(shape=(3,), dtype=np.int32)

Это правильный способ?

Может ли кто-нибудь указать мне учебник или пример, пожалуйста?

Кроме того, я нашел это репо, которое называется «Типовые подсказки для Numpy»: https://github.com/ramonhagenaars/nptyping

Будет ли Numpy интегрировать это?
@ramonhagenaars

@mattip

Как упоминалось в gh-14905, у нас есть начало библиотеки-заглушки в https://github.com/numpy/numpy-stubs.

Похоже, это было объединено с основным репо. Это было выпущено, или это в дорожной карте? Пытаемся решить, стоит ли нам исследовать что-то стороннее, например https://github.com/ramonhagenaars/nptyping, или (в идеале) ждать / использовать официально поддерживаемые подсказки типа.

Благодарю.

Мы объединили большую часть numyp-заглушек в ветку разработки. Вы можете следить за прогрессом, ища метку статической печати . Надеюсь, это будет частью следующего выпуска. Вы можете опробовать то, что в настоящее время объединено, используя HEAD-версию numpy. Мы всегда ищем участников: конструктивный анализ, документация, комментарии по проблемам и запросы на вытягивание - вот несколько способов помочь.

(Я знаю, что могу ввести подсказку с помощью np.ndarray, но как мне получить более конкретную информацию? Я прочитал здесь все и не понял, я также ищу учебник о том, как использовать типы numpy для ввода в Python, но не найти что-нибудь.)

В этой области есть большой интерес, но более конкретная типизация (типы и размеры) для массивов NumPy пока не поддерживается.

@ GilShoshan94 FWIW Я подал https://github.com/ramonhagenaars/nptyping/issues/27

Также FWIW, вот что pybind11 использует для "аннотирования" сигнатур типов в строках __doc__ для перегрузок:
https://github.com/pybind/pybind11/blob/0af7fe6c1943e6a9043e4e01c4bc9059108a6c98/include/pybind11/eigen.h#L195 -L208
https://github.com/pybind/pybind11/blob/0af7fe6c1943e6a9043e4e01c4bc9059108a6c98/tests/test_eigen.py#L185
https://github.com/pybind/pybind11/blob/0af7fe6c1943e6a9043e4e01c4bc9059108a6c98/tests/test_numpy_array.py#L290