Там в таблице пустые скобочки { } только в строке словаря, так как они создают пустой словарь.
Для множества указан пример {elm1, elm2} — при перечислении значений через запятую в { } создается множество.
Ну и вариант создания словаря из пар ключ: значение {key: value, } указан.
Более того, подобное замечание есть ниже под таблицей (UPD с благодарностью morff ), там как раз приведен пример практически идентичный Вашему.
Спасибо за предложение!
Да, там есть весьма интересные вещи и эта тема хорошо соответствует тематике данной серии.
Я пока сам не разбирался глубоко с этим модулем, но постараюсь после публикации уже запланированных материалов вернуться к этому вопросу.
Спасибо за предложение.
Тема добавления точно будет затронута в следующей статье серии, а также тема конкатенации (объединения) коллекций — уже имеются готовые наброски.
Касательно удаления элементов, там не так много нюансов, изначально эта тема не планировалась, но я подумаю и постараюсь включить и эти моменты в следующую статью.
С вопросами данного цикла статей мне приходилось непосредственно сталкиваться, большинство ошибок, от которых я предостерегаю, я в свое время совершал сам. Многие нюансы, казалось бы очевидных вопросов, при написании статьи открылись в новой стороны, так что польза такой систематизации информации в одном месте безусловно есть, даже если все это можно найти по-отдельности в учебниках и систематизировать самостоятельно.
Затрагиваемый же Вами вопрос более глубокий и узкоспециализированный, он рассчитан на более подготовленную аудиторию и более серьезный класс задач. На данный момент у меня вряд ли хватит алгоритмической подготовки для качественного детального разбора столь специфической темы, тем более, что я сам не сталкивался пока с задачами высокопроизводительных вычислений, не набил на этом своих «шишек», поэтому вряд ли смогу дать полноценные рекомендации в обсуждаемом вопросе.
При этом, мне интересна и эта тема, так как есть интерес к применению в дальнейшем Python в Data Science, но на данный момент эта задача не является для меня первостепенным приоритетом, поэтому и говорю, что в ближайшем будущем на углубление в этом направлении времени у меня точно не хватит.
Приняв во внимание количество проголосовавших за Ваш комментарий и осознав важность проблемы, переделал также схему и таблицу и расшифровки к ним, чтобы везде стояли корректные русские варианты названий. Остальной текст статьи был исправлен еще днем.
Большое спасибо за замечание, Вы действительно правы — Ваш пример не хешируем, я сейчас подумаю как это лучше сформулировать и внесу уточнения в статью, с указанием Вашей помощи.
В свое оправдание, скажу, что даже официальный глоссарии Python вводит в заблуждение, причем в обеих версиях:
https://docs.python.org/3/glossary.html#term-hashable
https://docs.python.org/2/glossary.html#term-hashable
"All of Python’s immutable built-in objects are hashable<...> Immutable objects include numbers, strings and tuples. "
Спасибо за замечание!
Не учел этот момент, так как в основном читаю англоязычные источники и не был уверен в устоявшейся терминологии на русском языке. Тем более, смутило, что однокоренные слова, как «мутация», «мутагенез» и т.п. присутствуют в русском языке.
Сделал правки по тексту статьи, кроме схем, таблиц и комментариев к ним.
Сразу видятся следующие проблемы:
1) Стоянка в порту отнюдь не бесплатная, так что экономия на земле может быть отрицательной
2) 8 МВт это серьезно, под это нужно строить в порту отдельный канал, плюс не решен вопрос с резервным питанием
3) Нужны мощные интернет-каналы, их тоже нужно тянуть отдельно
4) Побережье — это высокая влажность, с которой дополнительно надо бороться
А зачем при таких объемах нужен посредник? Почему такая крупная корпорация не договаривается с производителем ПО напрямую? Все-таки это не десяток лицензий для мелкой конторы, а крупный корпоративный заказ…
Для умственного труда не всегда можно определить сроки и объем задачи и почасовая ставка тут является выходом.
Как точно сразу определить сколько займет разработка алгоритма и получится ли вообще решить конкретную не стандартную задачу и соответственно какова ее стоимость?
Плюс, требования клиента к продукту могут меняться в процессе разработки, особенно когда делается что-то не стандартное и четкого видения у клиента еще нет — в данном случае почасовая оплата страхует разработчика от трений с заказчиком по поводу переделывания одного и того же многократно.
А можно ли делать не сразу оба глаза?
Я бы не рискнул сразу полным зрением, а так — сделал один глаз, прошло полгода-год, убедился что все нормально — сделал второй. В случае каких-то фатальных осложнений или врачебной ошибки, по крайней мере один глаз гарантировано будет рабочим.
Какие могут быть проблемы при таком подходе?
Про эмоциональное вовлечение НПС противников, посмотрите игру «Poker Night 2» (есть в Steam) — прекрасно реализовано именно то о чем Вы говорите. Эмоции у разных игроков разные и зависят от того, везёт им или нет.
Лучшая в плане юмора игра, по моему мнению, квест «The Book of Unwritten Tales» — это очень качественная (и по графике и по сюжету) пародия на все штампы фэнтези.
Другой достойный представитель юмористических квестов — «Deponia»
Для множества указан пример {elm1, elm2} — при перечислении значений через запятую в { } создается множество.
Ну и вариант создания словаря из пар ключ: значение {key: value, } указан.
Более того, подобное замечание есть ниже под таблицей (UPD с благодарностью morff ), там как раз приведен пример практически идентичный Вашему.
Да, там есть весьма интересные вещи и эта тема хорошо соответствует тематике данной серии.
Я пока сам не разбирался глубоко с этим модулем, но постараюсь после публикации уже запланированных материалов вернуться к этому вопросу.
Тема добавления точно будет затронута в следующей статье серии, а также тема конкатенации (объединения) коллекций — уже имеются готовые наброски.
Касательно удаления элементов, там не так много нюансов, изначально эта тема не планировалась, но я подумаю и постараюсь включить и эти моменты в следующую статью.
Затрагиваемый же Вами вопрос более глубокий и узкоспециализированный, он рассчитан на более подготовленную аудиторию и более серьезный класс задач. На данный момент у меня вряд ли хватит алгоритмической подготовки для качественного детального разбора столь специфической темы, тем более, что я сам не сталкивался пока с задачами высокопроизводительных вычислений, не набил на этом своих «шишек», поэтому вряд ли смогу дать полноценные рекомендации в обсуждаемом вопросе.
При этом, мне интересна и эта тема, так как есть интерес к применению в дальнейшем Python в Data Science, но на данный момент эта задача не является для меня первостепенным приоритетом, поэтому и говорю, что в ближайшем будущем на углубление в этом направлении времени у меня точно не хватит.
В свое оправдание, скажу, что даже официальный глоссарии Python вводит в заблуждение, причем в обеих версиях:
https://docs.python.org/3/glossary.html#term-hashable
https://docs.python.org/2/glossary.html#term-hashable
"All of Python’s immutable built-in objects are hashable<...> Immutable objects include numbers, strings and tuples. "
Не учел этот момент, так как в основном читаю англоязычные источники и не был уверен в устоявшейся терминологии на русском языке. Тем более, смутило, что однокоренные слова, как «мутация», «мутагенез» и т.п. присутствуют в русском языке.
Сделал правки по тексту статьи, кроме схем, таблиц и комментариев к ним.
1) Стоянка в порту отнюдь не бесплатная, так что экономия на земле может быть отрицательной
2) 8 МВт это серьезно, под это нужно строить в порту отдельный канал, плюс не решен вопрос с резервным питанием
3) Нужны мощные интернет-каналы, их тоже нужно тянуть отдельно
4) Побережье — это высокая влажность, с которой дополнительно надо бороться
Как точно сразу определить сколько займет разработка алгоритма и получится ли вообще решить конкретную не стандартную задачу и соответственно какова ее стоимость?
Плюс, требования клиента к продукту могут меняться в процессе разработки, особенно когда делается что-то не стандартное и четкого видения у клиента еще нет — в данном случае почасовая оплата страхует разработчика от трений с заказчиком по поводу переделывания одного и того же многократно.
Я бы не рискнул сразу полным зрением, а так — сделал один глаз, прошло полгода-год, убедился что все нормально — сделал второй. В случае каких-то фатальных осложнений или врачебной ошибки, по крайней мере один глаз гарантировано будет рабочим.
Какие могут быть проблемы при таком подходе?
Сколько килограмм пластилина ушло? :-)
Другой достойный представитель юмористических квестов — «Deponia»