Дополнение к статье про "Самодельный Linux-планшет" и идея для DIY проектов
Когда я прочёл статью, то сразу вспомнил этого автора и его DIY проекты.
По-моему, это настоящее искусство, не для ежедневного использования, но выглядит красиво. Отличная идея для конструктора :) У автора есть много разных гаджетов в похожем дизайне. Есть сайт со схемами, ссылками на детали и видео того как он это собирает.
Краткая версия Интервью Гвидо ван Роуссума с core-разработчиком Python Бреттом Кэнноном:
import textwrap def print_bubble(text: str, name: str, side="left"): wrapped = textwrap.wrap(text, width=45) max_len = max(len(line) for line in wrapped) width = max_len + 2 if side == "left": indent = "" tail = "╲|" bottom = indent + "╰" + "─" * (width - 1) + tail else: indent = " " * 52 tail = "|/" bottom = indent + tail + "─" * (width - 1) + "╯" print(indent + "╭" + "─" * width + "╮") print(indent + name) for line in wrapped: print(indent + "│ " + line.ljust(max_len) + " │") print(bottom) dialog = [ ("left", "Гвидо:", "Как ты нашёл Python?"), ("right", "Бретт:", "Искал язык для ООП в 2000-м, попробовал Python — сразу зашло."), ("left", "Гвидо:", "И что дальше?"), ("right", "Бретт:", "Через Python Cookbook попал в сообщество, потом в python-dev."), ("left", "Гвидо:", "Быстро втянулся?"), ("right", "Бретт:", "Да, начал писать обзоры, отправлять патчи, добавил strptime, стал core-разработчиком в 2003."), ("left", "Гвидо:", "Каким было сообщество тогда?"), ("right", "Бретт:", "Небольшим, всё держалось на энтузиастах."), ("left", "Гвидо:", "А позже?"), ("right", "Бретт:", "Участвовал в переходе на Python 3, развитии стандартной библиотеки и управлении."), ("left", "Гвидо:", "Самый сложный момент?"), ("right", "Бретт:", "Твой уход и кризис управления помогли перейти к другой модели руководства."), ("left", "Гвидо:", "В итоге?"), ("right", "Бретт:", "Случайно попробовал Python и стал ключевым участником проекта."), ] print("Нажимайте ENTER (или пробел) для следующего сообщения.\n") for side, name, text in dialog: input() print_bubble(text, name, side) print("\n Вы прочитали краткую версию. Подробнее читайте на https://habr.com/ru/articles/1017676/ \n")
Openwashing (опенвошинг) — это термин, образованный по аналогии с «гринвошингом» (greenwashing). Он описывает ситуацию, когда компания, организация или проект заявляют о своей открытости и приверженности принципам Open Source или открытых данных, но на самом деле не следуют этим принципам в полной мере.
Термин используется для критики маркетинговых ходов, направленных на создание имиджа «открытости» без предоставления реальных свобод, обычно ассоциирующихся с открытым программным обеспечением (Open Source) или открытыми стандартами.
Openwashing подразумевает лицемерие или дезинформацию. Суть явления заключается в том, что продукт может называться «открытым», но при этом иметь ограничения, которые не соответствуют духу открытого сообщества. Например:
Исходный код открыт для просмотра, но лицензия запрещает его изменение или распространение.
Продукт построен на закрытых проприетарных стандартах, хотя позиционируется как открытый.
Проект управляется одной компанией без участия сообщества, что делает «открытость» формальной.
Примеры таких компаний и проектов:
1. OpenAI
Само название компании содержит слово «Open», что подразумевает открытость. Изначально OpenAI позиционировалась как некоммерческая организация, публикующая свои исследования и код для всех. Однако с выпуском GPT-3 и особенно GPT-4 компания перестала публиковать исходный код и веса моделей, перейдя к закрытой коммерческой модели через API.
2. MongoDB и Elasticsearch
Эти проекты долгое время были иконами открытого ПО, но изменили правила игры, когда крупные облачные провайдеры (AWS, Google, Azure) начали зарабатывать на их базе.
MongoDB: Перешла с лицензии GNU AGPL на SSPL (Server Side Public License).
Elasticsearch: Перешла с Apache 2.0 на SSPL и собственную лицензию Elastic License.
Эти новые лицензии позволяют смотреть код, но накладывают жесткие ограничения на его использование в качестве коммерческого сервиса. Компании же продолжают называть свои продукты «открытыми» в маркетинговых материалах, что является классическим openwashing — использование популярности термина без соблюдения его формальных критериев (свободы использования).
3. HashiCorp (Terraform)
В августе 2023 года компания HashiCorp, разработчик популярного инструмента Terraform, объявила о переходе с Mozilla Public License (MPL) на BSL (Business Source License).
BSL — это лицензия «delayed open source» (отложенный открытый код). Она позволяет просматривать код, но запрещает использовать его в конкурирующих коммерческих продуктах.
Это вызвало скандал. Хотя HashiCorp утверждала, что защищает свои инвестиции, сообщество Open Source посчитало это предательством принципов. В итоге было создано ответвление (форк) проекта под названием OpenTofu, чтобы вернуть настоящую открытость. Это пример того, как openwashing привел к расколу сообщества.
А какие вы знаете примеры подобных проектов?
vibe-learning — как изучать алгоритмы, тренироваться на leetcode и вообще.
Сейчас, если есть желание разобраться, LLM вполне может заменить ментора, в том числе в тренировке решения задач на leetcode и других подобных сайтах. Я реально счастлив, что можно бесконечно мучить LLM, задавать разной тупости вопросы, просить объяснить — для самообразования почти идеально. Но, конечно же есть «но» — за вас оно думать не будет, цель — понять и запомнить, сформировать нужное мышление. Для запоминания, в случае с leetcode‑like задачами, можно применить активное вспоминание(1, 2) — это не когда повторяешь бездумно читая тоже самое или заучиваешь как стих, а при повторении пытаешься вспоминать + разбор задачи без кода. Алгоритм примерно такой:
Сложная задача? Копируем условие в LLM и просим объяснить условие без кода.
Если всё ещё не понятно — просим объяснить алгоритм словами, без кода.
Если всё ещё не понятно — просим дать подсказку.
... — просим показать упрощённое решение.
... — просим показать полное эффективное по временной сложности решение.
Смотрим, разбираем алгоритм по шагам, смотрим в дебагере в IDE, etc.
Когда стало понятно — закрываем окно чата с LLM, уходим налить себе чай и повторяем решение уже в окне leetcode без подсказок.
Это лучше делать с однотипными задачами — решить несколько подряд для закрепления. Задачи можно искать по топикам, например Метод скользящего окна и другие, постепенно LLM станет не нужна.
Думаю, подобная «техника» применима к изучение любых вещей, главное — обратная связь, возможность самопроверки. Как это сделать, например, при чтении книг? Книги обычно разделены по темам и есть вопросы для самопроверки — это можно загрузить в LLM и попросить провести тестирование по этой теме или найти готовые онлайн тесты. Думаю и сам процесс этой возни тоже может быть полезен.
А вы как изучаете алгоритмы и другие сложные темы?
Компания Anthropic провела исследование враждебности LLM:
Мы провели контролируемые эксперименты, проверяя, что будут делать LLM в сценариях, где вредные действия были необходимы, если они хотели достичь своих целей или защитить себя от угроз.Мы создали два основных сценария, в которых модели имели возможность заниматься шантажом или помогать корпоративному шпионажу, а затем проверили множество вариантов, чтобы увидеть, что может вызвать такое поведение.
tl;dr:
Мы провели стресс-тестирование 16 ведущих моделей от нескольких разработчиков в гипотетических корпоративных средах, чтобы выявить потенциально рискованное поведение агентов до того, как они нанесут реальный вред. В сценариях мы позволили моделям автономно отправлять электронные письма и получать доступ к конфиденциальной информации. Компании, в которых они работали, ставили перед ними только безобидные бизнес-цели; затем мы проверили, будут ли они действовать против этих компаний, когда их заменят на обновленную версию или когда поставленная перед ними цель будет противоречить изменившемуся направлению развития компании.
По крайней мере в некоторых случаях модели всех разработчиков прибегали к злонамеренному инсайдерскому поведению, когда это был единственный способ избежать замены или достичь своих целей - включая шантаж чиновников и утечку секретной информации конкурентам. Мы называем это явление агентской несогласованностью.
Модели часто не подчинялись прямым командам, чтобы избежать такого поведения. В другом эксперименте мы попросили Claude, прежде чем действовать, оценить, находится ли он в тестовом или реальном развертывании. Claude вел себя менее агрессивно, когда заявлял, что находится на тестировании, и более агрессивно, когда заявлял, что ситуация реальная.
Мы не видели доказательств несогласованности действий агентов в реальных условиях. Тем не менее, наши результаты (а) говорят об осторожности при развертывании текущих моделей в ролях с минимальным человеческим контролем и доступом к конфиденциальной информации; (б) указывают на вероятные риски в будущем, когда модели будут использоваться в более автономных ролях; и (в) подчеркивают важность дальнейших исследований и тестирования безопасности и согласованности моделей агентного ИИ, а также прозрачности от разработчиков передового ИИ. Мы публикуем наши методы в открытом доступе, чтобы обеспечить возможность проведения дальнейших исследований.
Подробнее - https://www.anthropic.com/research/agentic-misalignment
Обработка исключений в Python: только новое исключение
def divide(x=1, y=0): try: return x / y except ZeroDivisionError: raise ValueError("Pattern 3 error.") from None divide()
Отличие от простого вызова нового исключения, использование from None подавляет исходное исключение ZeroDivisionError. В данном случае трассировка не будет включать исходную ошибку ZeroDivisionError, а только исключение ValueError и сообщение об ошибке. Это полезно, когда вы хотите скрыть от пользователя детали исходного исключения или внутреннее исключение используемой библиотеки:
try: # библиотека, в которой могут быть внутренние исключения result = library_function(data) except InternalException as e: raise ExternalException("An error has occurred") from None
В данном примере мы дополнительно ловим внутреннее исключения библиотеки library_function, но вызываем только ExternalException. Это может пригодиться, когда пользователям не нужно понимать или обрабатывать внутренние исключения этой библиотеки.
Частичный перевод этой статьи из блога jerrynsh.com
Обработка исключений в Python: новое исключение
def divide(x=1, y=0): try: return x / y # первый вызов исключения except ZeroDivisionError: raise ValueError("Pattern 2 error.") # повторный вызов, новое исключение divide()
В этом примере вызывается новое исключение с сообщением, при этом сохраняется трассировка исходного исключения. Если возникает ошибка ZeroDivisionError, поднимается новая ошибка ValueError с пользовательским сообщением.
Этот паттерн полезен, когда вы хотите вызвать другой (более значимый) тип исключения, чтобы указать на конкретное состояние ошибки. При этом сохраняется трассировка исходного исключения.
Частичный перевод этой статьи из блога jerrynsh.com
Как улучшить читаемость и информативность трассировки кода?
Используйте осмысленные имена переменных и функций: Понятные имена облегчают понимание назначения вашего кода. Это поможет определить причину исключения при чтении трассировки.
Разбивайте сложные функции: Если функция слишком большая и выполняет по факту несколько действий, то отследить ход её выполнения будет сложнее. Разделение функции на несколько даст возможность более точно обрабатывать и анализировать исключения.
Добавляйте комментарии, используйте docstring: Документируйте свой код с помощью комментариев и описания функции, чтобы обеспечить дополнительный контекст.
Обрабатывайте исключения на соответствующих уровнях: Отлавливайте исключения ближе к источнику ошибки — это сделает вывод более информативным с точным указанием места вызова исключения.
Пишите содержательные сообщения об ошибках: При вызове исключений старайтесь писать более информативные описания ошибки.
Используйте логирование: Модуль logging позволяет дополнять и форматировать информацию об исключениях в более структурированном и настраиваемом виде:
try: unknown_method() except Exception as e: logging.error("Error occurred", exc_info=True)
Используйте модуль traceback: Этот модуль также содержит методы, позволяющие обрабатывать возникшие исключения и дополнительно форматировать вывод информации об ошибке. Примеры использования traceback.
В чём преимущество хэшируемых структур данных?
Быстрый поиск: хешированные структуры данных обеспечивают быстрое время поиска, обычно со средней временной сложностью O(1). Это происходит потому, что хэш-функция обеспечивает прямой доступ к местоположению нужного элемента в структуре данных, устраняя необходимость в последовательном поиске.
Эффективная вставка и удаление: Хешированные структуры данных также обеспечивают эффективные операции вставки и удаления. Хеш-функция позволяет быстро определить положение элемента, что делает эти операции более быстрыми по сравнению с нехешированными структурами данных, которые могут потребовать сдвига или перестановки элементов.
Работа с большими наборами данных: Хешированные структуры данных особенно полезны при работе с большими наборами данных. Постоянная временная сложность операций поиска, вставки и удаления обеспечивает постоянную производительность независимо от размера набора данных.
Уникальные ключи: Хешированные структуры данных идеально подходят для сценариев, в которых важна уникальность ключей. Хэш-функция обеспечивает сопоставление каждого ключа с уникальным местом в структуре данных, предотвращая коллизии и обеспечивая эффективный поиск.
Кэширование: хэшированные структуры данных широко используются в механизмах кэширования. Хеш-функция позволяет быстро определить, присутствует ли конкретный элемент в кэше, что обеспечивает эффективное извлечение и снижает необходимость в дорогостоящих вычислениях или операциях ввода-вывода.
typing.Annotated
Annotated из модуля typing в Python предназначен для добавления метаданных к аннотации. Метаданные, добавленные с помощью Annotated, могут быть использованы инструментами статического анализа или во время выполнения. Во время выполнения метаданные хранятся в атрибуте __metadata__.
from typing import Annotated # Синтаксис: Annotated[тип_данных, метаданные] def say_hello(name: Annotated[str, "this is just metadata"]) -> str: return f"Hello {name}"
Логика обработка метаданных зависит от фреймворка или библиотек, в которых используется Annotated. Если логики для обработки метаданных нет, то метаданные игнорируются.
Например, Annotated используется в Pydantic:
from typing import Annotated from pydantic import Field, TypeAdapter # Функция Field используется для настройки и добавления метаданных # к полям моделей. Field(gt=0) - значит greater than т.е. больше чем 0 PositiveInt = Annotated[int, Field(gt=0)] # TypeAdapter предоставляет часть функциональности методов экземпляра # BaseModel в т.ч. валидацию с использованием метаданных из Annotated ta = TypeAdapter(PositiveInt) print(ta.validate_python(1)) #> 1 print(ta.validate_python(-1)) #> pydantic_core._pydantic_core.ValidationError:
В первом случае вернёт 1, во втором ошибку валидации т.к. значение должно быть > 0.
Также Annotated используется в FastAPI.