Нашёл такую фразу "любой пользовательский тип является хэшируемым по определению, потому что его хэш-значение равно id() и никакие два объекта этого типа не равны". Почему? Если я определю класс с атрибутом значение которого установлю равным изменяемому объекту, например, пустому листу и потом будут добавлять элементы в этот лист, разве это не делает наличие среди атрибутов объекта изменяемого объекта сам объект не хэшируемым? Ведь сам объект при этом тоже изменится, а следовательно должен измениться и хэш?

Нашёл такую фразу "любой пользовательский тип является хэшируемым по определению, потому что его хэш-значение равно id() и никакие два объекта этого типа не равны". Почему? Если я определю класс с атрибутом значение которого установлю равным изменяемому объекту, например, пустому листу и потом будут добавлять элементы в этот лист, разве это не делает наличие среди атрибутов объекта изменяемого объекта сам объект не хэшируемым? Ведь сам объект при этом тоже изменится, а следовательно должен измениться и хэш?

как я понимаю, в данном случае случае хеш - "адресс" объекта. и как бы ты не менял сам объект, адресс останется прежним

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

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

да. меняется не адресс, а содержимое

что-то я нарушил c python на ubuntu 18 и теперь имею проблему ModuleNotFoundError: No module named имя_пакета как это пофиксить??? (вчера устанавливал google cloud) python -V Python 3.6.7 и либа тоже для 3 питона может питон и простой, но то что я имею проблемы с настройками среды периодически уже не делает его простым

помню когда-то пофиксил эту бяку переустановкой питона, но может есть проще костыли кто знает?

И при этом хэшируемость по определению предполает что хэш объекта должен оставаться не изменяемым на протяжении жизни объекта

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

например ты можешь засунуть лис в tuple, а потом изменить лист. как следствие "изменится" tuple

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

>>> t1 = ([],) >>> l = [] >>> t2 = (l,) >>> t1 == t2 True >>> l.append("2") >>> t1 == t2 False

И при этом хэшируемость по определению предполает что хэш объекта должен оставаться не изменяемым на протяжении жизни объекта

хеш не изменился. адресс объекта всегда уникален и неизменен

плохой пример с tuple

Хз, не знаю что здесь имеется в виду, это переведенная фраза из глоссария документации

Хз, не знаю что здесь имеется в виду, это переведенная фраза из глоссария документации

попробую так. у тебя есть пользовательский объект с разными полями. как легче всего найти уникальное значение для этого объекта? взять его адресс. Адресс у объекта будет уникален и объект будет равен только сам себе

Здравствуйте. Проблема в следующем: Нужно сделать скриншот элемента в headless браузере (chrome) Есть следующий простенький код, который работает: https://pastebin.com/pJd5fMcq Но если раскомментировать строчку с headless, он перестает работать.

попробую так. у тебя есть пользовательский объект с разными полями. как легче всего найти уникальное значение для этого объекта? взять его адресс. Адресс у объекта будет уникален и объект будет равен только сам себе

"a = [1, 2] print(id(a)) a.append(10) print(id(a)) выдаёт одинаковые адреса, но объект не хэшируемый, т.е. один и тот же адрес не предполагает хэшируемость, Для листа будет тот же адрес, после его изменения, но он не хэшируемый

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

id объекта не зависит от его атрибутов

"a = [1, 2] print(id(a)) a.append(10) print(id(a)) выдаёт одинаковые адреса, но объект не хэшируемый, т.е. один и тот же адрес не предполагает хэшируемость, Для листа будет тот же адрес, после его изменения, но он не хэшируемый

ты же не оздал из a новый объект. ты в объект a положил новое значение

адресс а остался прежним

При создании объекта ему назначается какой-то айди, который впоследствии не изменяется

Даже если сам объект мутируется

хеш не говорит, что объект неизменяем. хеш говорит, что объект должен быть уникален

Нашёл такую фразу "любой пользовательский тип является хэшируемым по определению, потому что его хэш-значение равно id() и никакие два объекта этого типа не равны". Почему? Если я определю класс с атрибутом значение которого установлю равным изменяемому объекту, например, пустому листу и потом будут добавлять элементы в этот лист, разве это не делает наличие среди атрибутов объекта изменяемого объекта сам объект не хэшируемым? Ведь сам объект при этом тоже изменится, а следовательно должен измениться и хэш?

Здесь говорится о том, что по умолчанию в CPython __hash__ основывается на id, это реализация по умолчанию, которая не особенно полезна.

"a = [1, 2] print(id(a)) a.append(10) print(id(a)) выдаёт одинаковые адреса, но объект не хэшируемый, т.е. один и тот же адрес не предполагает хэшируемость, Для листа будет тот же адрес, после его изменения, но он не хэшируемый

попробую так. Есть человек. у человека есть Фамилия и Имя. Фамилия и Имя не гарантирует уникальность человека (у нас без проблем может бы 2 Васи Пупкиных)

при этом если Человек сменит Имя/Фамилию, это все-равно останется прежний человек

Ребята подскажите ловлю ValueError: list.remove(x): x not in list while len(spisok) > 0: print('Длина списка:', len(spisok)) with Pool(25) as p: p.map(download_html, spisok) def download_html(url): spisok.remove(url) print('Скачал и удалил', url) в чем проблема?

Народ подскажите а у jinja2 рендеринг файла асинхронный? Я чет не могу понять из доков (( Уже и в код залез а там блокирующий open()

url нев в списке)

Народ подскажите а у jinja2 рендеринг файла асинхронный? Я чет не могу понять из доков (( Уже и в код залез а там блокирующий open()

с чего бы?

синхронный

url нев в списке)

а как его может не быть в списке если он был передан в функцию

Ребята подскажите ловлю ValueError: list.remove(x): x not in list while len(spisok) > 0: print('Длина списка:', len(spisok)) with Pool(25) as p: p.map(download_html, spisok) def download_html(url): spisok.remove(url) print('Скачал и удалил', url) в чем проблема?

ох ну и пиздец. тебя не смушает что ты модифицируешь список, по которому итерируешься? Да еще и в разных потоках?

синхронный

Вот блин ((( а тогда какой профит использования в асинхронных фреймворках?

хеш не говорит, что объект неизменяем. хеш говорит, что объект должен быть уникален

Почему лист тогда не хэшируемый, он ведь тоже может быть уникальный?

Вот блин ((( а тогда какой профит использования в асинхронных фреймворках?

а в чем собственно проблема? рендеринг шаблона в основном CPU bound за исключением его чтения из файла и записи в кеш.

Однако файловый IO не может быть асинхронным (на самом деле может).

Почему лист тогда не хэшируемый, он ведь тоже может быть уникальный?

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

Вот есть асинхронная жинжа для аиохттп https://github.com/aio-libs/aiohttp-jinja2

Поэтому если рендеринг шаблона у тебя становится узким местом - выноси ее в отдельный поток.

Не смотрел что именно там асинхронное

а в чем собственно проблема? рендеринг шаблона в основном CPU bound за исключением его чтения из файла и записи в кеш.

да понятно, но вот чтение то и хотелось не блокирующее. СпасибО!

Не смотрел что именно там асинхронное

Ну скорее всего как и aiofiles, просто враппер над отдельным потоком.

ох ну и пиздец. тебя не смушает что ты модифицируешь список, по которому итерируешься? Да еще и в разных потоках?

смущает

Вот есть асинхронная жинжа для аиохттп https://github.com/aio-libs/aiohttp-jinja2

видел - но не пробовал к санек прикручивать и возможно ли это ))) А тот что предлагает сам санек юзать он синхронный

Почему лист тогда не хэшируемый, он ведь тоже может быть уникальный?

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

Ну скорее всего как и aiofiles, просто враппер над отдельным потоком.

В общем, глянул, там один файл, асинхронщины нет, просто интерфейс к аиохттп

Ну оно и понятно

дык, а что ты ожидал. файлового асинхронного IO в общем случае не бывает.

(под линуксами, если не брать во внимание AIO)

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

смущает

если ты запускаешь Pool.map(), нафига вообще удалять из списка урлы?

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

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

если ты запускаешь Pool.map(), нафига вообще удалять из списка урлы?

щас подумаю

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

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

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

Скажите, вы понимаете, зачем хеши вообще нужны?)

щас подумаю

думай

Скажите, вы понимаете, зачем хеши вообще нужны?)

Чтобы было уникальное соответствие между ключом и значением

при чем тут адрес объекта в памяти к его хешу?

Чтобы было уникальное соответствие между ключом и значением

нет, хеши не могут быть уникальными по определению.

Чтобы было уникальное соответствие между ключом и значением

Нет)

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

Чтобы было уникальное соответствие между ключом и значением

Хеш нужен, чтобы можно было по _значению_ объекта "примерно" понять, есть он в хеш-таблице (dict, set) или нет. Примерно — см. коллизии. Проблема с изменяемыми (mutable) типами вроде списка в том, что после изменения этот список будет лежать не в той ячейке хеш-таблицы.

Для кастомных типов по умолчанию есть максимально тупая реализация хешей — хеш это условно адрес в памяти, сравнение всегда возвращает False.

Хеш нужен, чтобы можно было по _значению_ объекта "примерно" понять, есть он в хеш-таблице (dict, set) или нет. Примерно — см. коллизии. Проблема с изменяемыми (mutable) типами вроде списка в том, что после изменения этот список будет лежать не в той ячейке хеш-таблицы.

> сравнение всегда возвращает False. шта?

Хеш нужен, чтобы можно было по _значению_ объекта "примерно" понять, есть он в хеш-таблице (dict, set) или нет. Примерно — см. коллизии. Проблема с изменяемыми (mutable) типами вроде списка в том, что после изменения этот список будет лежать не в той ячейке хеш-таблицы.

Согласен, неправильно выразился, а ячейка хэш таблицы не id предполагает разве?

> сравнение всегда возвращает False. шта?

А, неправильно. Сравнение сравнивает адреса, т.е. сам с собой объект будет сравниваться на True.

Согласен, неправильно выразился, а ячейка хэш таблицы не id предполагает разве?

нет

нет

Я про вот такое: >>> class User: ... def __init__(self, name): ... self.name = name ... >>> User('abc') == User('abc') False

А, неправильно. Сравнение сравнивает адреса, т.е. сам с собой объект будет сравниваться на True.

нет, если у кастомного типа не реализован оператор сравнения, то сравниваются id() объектов.

нет, если у кастомного типа не реализован оператор сравнения, то сравниваются id() объектов.

Так я это и сказал? В стандартной реализации id это адрес

для CPython id() возвращает адрес объекта в памяти, но это особенность реализации.

Вы в двух чатах одновременно это обсуждаете?

Согласен, неправильно выразился, а ячейка хэш таблицы не id предполагает разве?

Хеш это просто int

Хеш это просто int

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

Приветствую. У gunicorn можно выбрать асинхронный тип воркеров -k gevent, но я наблюдаю следующую картину: при 1 воркере если отправить один запрос, который выполняется довольно долнго и следом отправить второй (лёгкий), то второй ждёт пока первый не отработает. Куда смотреть или я неправильно понимаю назначение gevent воркеров?

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

уникальность листа напрямую зависит от содержимого. уникальность объекта в базовой реализации зависит от адресса

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

ты всегда можешь переопределить метод хеша, если тебя не устраивает текущая реализация

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

Потому что решили по дефолту не запрещать для произвольных объектов хэш ибо хз что там. Например, если если список в одном из полей, не факт что он должен участвовать в хэше. А вот просто со списком все однозначно

В нейронках шарит кто?

Потому что решили по дефолту не запрещать для произвольных объектов хэш ибо хз что там. Например, если если список в одном из полей, не факт что он должен участвовать в хэше. А вот просто со списком все однозначно

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

Да не в коллизиях дело

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

В списке все элементы равноправны и по логике все должны участвовать в хэше. А в объекте бабушка надвое сказала

сорян за оффтоп, YouTube API знает кто? как узнать место ролика в тренде?