Курс по Python

[arseniiv]

Dmitriy40 в сообщении #1319881 писал(а):

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

Да, спасибо за уточнение, я хотел сказать это, но вышло, получается, недостаточно ясно.

[mihaild]

_Ivana в сообщении #1319966 писал(а):

А раньше возвращали списки? Тогда что такое списки в Питоне? Структуры данных с произвольным доступом за логарифмическое время, как в ПХП? За константное время, как настоящие массивы? С последовательным доступом за линейное время, как настоящие списки? Если последнее, то ленивые или полностью развернутые в памяти? И что же сейчас возвращает, к примеру, filter?

Доступ по индексу за константное время, объекты внутри произвольные, в памяти последовательно лежат указатели на PyObject.

_Ivana в сообщении #1319966 писал(а):

И что же сейчас возвращает, к примеру, filter?

В 3м питоне filter - это вообще класс. При инициализации iterable и функцию, при взятии следующего элемента берет элементы iterable, на каждом зовет функцию, пока не найдет что-то, на чем она вернет true.
Раньше filter при вызове сразу проходила по списку (нелениво), создавала список и возвращала его.

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

Про разницу между списком списков и двумерным массивом - это концепция из Паскаля (и, возможно, еще из каких-то языков). Иногда еще называют двумерным массивом структуру, в которой скажем элемент a[1][0] лежит в памяти сразу за a[0][N].
В питоновских списках списков никаких гарантий на расположение элементов из разных списков в памяти (точнее, указателей на них) нет.

[_Ivana]

Спасибо. То есть, упрощая и обобщая, во втором Питоне все эти мапы-фильтры принимали массивы и возвращали массивы по строгой семантике, создавая кучу промежуточных массивов-результатов при цепочке композиции, а в третьем они принимают итерабл (или преобразуют к нему массив оберткой) и обертывают его в новый итерабл (переписывая метод некст()) - здравствуй ленивый последовательный доступ без сохранения предыдущих значений? И мы можем как снова в массив его развернуть, проитерировавшись по нему, так и средьюсить во что-нибудь другое, так и оставить ленивым объектом, беря очередной элемент по мере надобности? Интересная модель, если я правильно понял. Но, в отличие от потоков, такие генераторы вроде не смерджишь с отфильтрованными результатами самих себя. Интересно, как в этой абстракции реализовать бесконечный генератор чисел Хэмминга, к примеру.

[mihaild]

iterable - это объект, у которого есть либо метод __iter__, либо __getitem__.
Из любого iterable можно сделать итератор, вызвав на нем функцию iter(x) - она просто позовет x.__iter__, если такой метод есть, а если нет - то создаст обертку, которая будет звать x.__getitem__ на всё возрастающих элементах.
Дальше у итератора есть метод __next__, который должен либо вернуть очередное значение, либо кинуть StopIteration.
При этом, в зависимости от объекта, разные итераторы по нему могут быть как зависимы, так и нет - например, итераторы по list независимы, а по sys.stdin или filter - зависимы.

Используется синтаксис Python

>>> a = [1, 2, 3, 4]
>>> x = iter(a)
>>> y = iter(a)
>>> next(x)
1
>>> next(y)
1
>>> u = filter(None, a)
>>> x1 = iter(u)
>>> y1 = iter(u)
>>> next(x1)
1
>>> next(y1)
2

Обратите внимание, что после взятия значения из x1 следующее значение из y1 получилось другим.
(а если посмотреть на id - то окажется, что u, x1, y1 это вообще один и тот же объект)

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

[arseniiv]

(Взгляд со стороны)

_Ivana в сообщении #1320052 писал(а):

Интересная модель, если я правильно понял.

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

[_Ivana]

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

defn cnt (n) lambda () (set! n (+ 1 n)) n
 => OK
def a (cnt 0)
 => OK
(a)
 => 1
(a)
 => 2

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

(def primes (s-cons 2 (s-filter is-prime? (int-from 3))))
(defn is-prime? (n) all (lambda (i) /= 0 (mod n i)) (take-while (lambda (i) <= (* i i) n) primes))
 => OK
s-take 30 primes
 => (2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97 101 103 107 109 113)

здесь для получения очередного значения нам нужно определенное количество уже полученных значений.

То есть я не против итераторов-генераторов, но с одной стороны их можно реализовать везде где есть лямбды, и для этого не надо ничего добавлять в язык, с другой - я не вижу их больших преимуществ, но вижу ограничения, и с третьей - просто непривычно мыслить мапы/фильтры как обертки над такими "значениями без истории". Но возможно это все от того, что я не умею их готовить.

[arseniiv]

Стоит различать итератор и iterable/enumerable. Второе — это класс коллекций, которые можно итерировать (то есть они позволяют получить соответствующий итератор). Это свойство даёт наделать уже достаточно большой API (реализации при этом, конечно, не обязаны делать всё всегда только используя итераторы и не используя других знаний о коллекции); почти вездесущие сейчас циклы for … in — это прямое следствие выделения iterable как отдельной сущности.

[_Ivana]

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

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

ЗЫ хотя, возможно, вы сторонник мнения, что стандартная библиотека является частью языка. Но мне кажется это надо четко разделять. В С++ нет векторов, в С нет строк, тем более нуль-терминированных, в моих примерах выше бесконечные потоки не являются частью ядра языка, а реализованы как библиотека. При этом фор-ин в Джаве зачем-то часть синтаксиса, а про Питон и его генераторы-итераторы до сих пор непонятно.

[iakovk]

_Ivana в сообщении #1320065 писал(а):

В С++ нет векторов

Есть.
См. стандарт (например тут)

стандарт C++ писал(а):

23.3.6 Class template vector

_Ivana в сообщении #1320065 писал(а):

стандартная библиотека является частью языка

А что, нет?
Смею предположить, что все, что описано в этом документе, является частью языка.

[_Ivana]

iakovk в сообщении #1320094 писал(а):

А что, нет?

Разумеется, нет. Но тут исключительно терминологический вопрос, который, как ни странно, имеет важные следствия при изучении и применении. Можно под термином язык понимать всю совокупность - синтаксис, семантику, стандартные библиотеки и комьюнити. В этом смысле даже вы лично являетесь частью С++. А можно лишь синтаксис/семантику ядра плюс подробности реализаций для различных целевых платформ. И в каком смысле в Питоне есть итераторы/генераторы мне пока непонятно.

[realeugene]

_Ivana в сообщении #1320065 писал(а):

хотя, возможно, вы сторонник мнения, что стандартная библиотека является частью языка. Но мне кажется это надо четко разделять.

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

Собственно, даже в С часть арифметических операций (например, обычное деление) нередко реализуется через библиотечные функции. Плюс стартап-код, плюс завершение процесса и функция atexit, плюс куча (используется хотя бы для той же atexit), плюс аллокации на стеке, плюс взаимодействие с OS, и много всего другого, что требует CRTL и не может быть реализовано программистом самостоятельно на голом портабельном ядре языка без закапывания в детали реализации конкретной системы и аппаратуру.

В более высокоуровневых языках даже для простейших типов требуется куча стандартных библиотечных функций. При их отрезании язык становится полностью нежизнеспособен.

[_Ivana]

Обычное деление является частью С потому что это встроенный в ядро языка оператор, а то что в разных платформах используются либо инструкции div, либо целые асм-процедуры (из-за отсутствия div на данной архитектуре) - это уже детали реализации. А остальные ваши примеры, от менеджеров памяти и до взаимодействия с ОС, не имеют к собственно языку никакого отношения, как и нуль-терминированные строки. И в программах для микроконтроллеров это отчетливо видно. Точно так же монады не являются частью Хаскелл, хотя для них там даже синтаксис свой есть в ядре.

[iakovk]

_Ivana в сообщении #1320099 писал(а):

В этом смысле даже вы лично являетесь частью С++

По-моему, это бред. Может быть, даже и оскорбление.

[_Ivana]

Наоборот комплимент, речь же не про ПХП А насчет бреда - я понимаю, что вам ваш ближе, но с вашего позволения я выберу свои заблуждения

[realeugene]

_Ivana в сообщении #1320103 писал(а):

И в программах для микроконтроллеров это отчетливо видно.

Программы для микроконтроллеров бывают разные. Некоторые вообще под Линуксом крутятся. Другие вынуждены использовать только некоторое подмножество языка, как раз в силу отсутствия нормальных библиотек и операционки. Но у всех есть стартап-код. И все используют некоторое подмножество CRTL.