A snap is a fancy zip file containing an application together with its dependencies, and a description of how it should safely be run on your system, especially the different ways it should talk to other software. Most importantly snaps are designed to be secure, sandboxed, containerised applications isolated from the underlying system and from other applications. Snaps allow the safe installation of apps from any vendor on mission critical devices and desktops.

>> zip file containing an application together with its dependencies >> secure ?

а, они secure в связке с Mir, ок.

?

A snap is a fancy zip file containing an application together with its dependencies, and a description of how it should safely be run on your system, especially the different ways it should talk to other software. Most importantly snaps are designed to be secure, sandboxed, containerised applications isolated from the underlying system and from other applications. Snaps allow the safe installation of apps from any vendor on mission critical devices and desktops.

вообще это описание всей экосистемы макоси

там тоже говноаппы

норм аппы

Привет! Мы ищем мидл разработчиков в Питере в несколько проектов на фултайм к нам в офис. Нам нужен ваш опыт с Python 2.7 и PostgreSQL. Есть возможность разрабатывать проекты с нуля (практически без легаси) Пишите в личку ?https://spb.hh.ru/vacancy/19128820

почему не третьепитон

Ага

Без легаси

Питон2

вот это и смущает.. вроде с 0, без легаси, но 2.7 питон? WTF

Наши ожидания от кандидатов: отличное знание Python 2.7. > использование табов.

Лол

да, 2.7 не нужен

Юмористическая вакансия

Табы не нужны тем более

Pycharm их сам в пробелы переводит

а обратно умеет?

Он все умеет

Но не любит

а обратно умеет?

а не надо, нарушение будет

Нарушение УК?

нарушение pep8

нестрогое, но тем не менее

А если мне не нравится pep8

А если мне не нравится pep8

тогда тебя нельзя пускать писать продакшен на питоне

Не весь продакшен пишется по пеп8

ну Армину тоже не нравится пеп8

Не весь продакшен пишется по пеп8

и это очень плохо

Почему?

ну Армину тоже не нравится пеп8

Армину вообще мало что нравится :)

особенно аргументы типа def foo(bar, baz)

лол пробелы неправильно

Почему?

потому что стайлгайды придумали для людей

потому что стайлгайды придумали для людей

Кроме пеп8 есть тысячи других стайлгайдов

Кроме пеп8 есть тысячи других стайлгайдов

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

Если что-то официально признано, это не значит, что я обязан использовать это в моем проекте

Даже стандартная библиотека не всегда его соблюдает

Если что-то официально признано, это не значит, что я обязан использовать это в моем проекте

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

иначе не обижайся, если будут чморить

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

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

Даже стандартная библиотека не всегда его соблюдает

пруф?

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

вовсе да. То, что команда предпочитает неправильный стиль - это проблемы команды

пруф?

Классы должны начинаться с большой буквы, defaultdict не начинается

Классы должны начинаться с большой буквы, defaultdict не начинается

а ты от него часто наследуешься?

вовсе да. То, что команда предпочитает неправильный стиль - это проблемы команды

То есть я в своем коммерческом проекте должен писать в стиле, который не нравится ни мне, ни команде, просто потому что "так надо"?

а ты от него часто наследуешься?

Я его иногда использую

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

я не говорю, что это верно

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

то есть в своём проекте тоже можно пользоваться вот такой вот аргументацией стайла не по пеп8?

но вообще за несоблюдение пеп8 на кодревью надо бить по рукам всегда. точка.

мол, это ж питон, какая разница, всё вокруг объект

то есть в своём проекте тоже можно пользоваться вот такой вот аргументацией стайла не по пеп8?

на стандартную библиотеку ты повлиять не можешь все равно, поэтому если подгорает - можно себе придумать такое объяснение, не хуже любого другого :)

но вообще за несоблюдение пеп8 на кодревью надо бить по рукам всегда. точка.

Если в проекте официально используется пеп8, да. Если не используется, нет.

https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds

Если в проекте официально используется пеп8, да. Если не используется, нет.

если в проекте официально не используется пеп8, проект надо переписать в идеале

в пеп-8 как бы прописано, что его можно нарушать

если в проекте официально не используется пеп8, проект надо переписать в идеале

Что за максимализм?

например, отсутствие pep8 - это бич Ansible

в пеп-8 как бы прописано, что его можно нарушать

не мешай фанатикам :)

если в проекте официально не используется пеп8, проект надо переписать в идеале

Если от этого не выгодно никому, переписывать его не надо

ERROR: S client not available

Даже если это опенсорс

Если от этого не выгодно никому, переписывать его не надо

это выгодно сообществу, которое хочет с кодом поработать

норм, обосрался с табов

в пеп-8 как бы прописано, что его можно нарушать

да, многие это делают. Хотя я и против даже специального выключения отдельных проверок, но это делать можно. В целом игнорировать пеп8 - нельзя

Мне кажется, интересы непосредственно разработчиков должны стоять выше интересов некоторого абстрактного сообщества

Мне не нравится camelCase в js. Но я бы не удивился, если бы в проекте js+python styleguide'ом приняли бы camelCase для переменных, например.

Мне кажется, интересы непосредственно разработчиков должны стоять выше интересов некоторого абстрактного сообщества

это называется “мне плевать на всех, паркуюсь, как хочу”

не надо так

Мне не нравится camelCase в js. Но я бы не удивился, если бы в проекте js+python styleguide'ом приняли бы camelCase для переменных, например.

не надо смешивать серверную и фронтендную части

не надо смешивать серверную и фронтендную части

А если работаешь не в команде?

тот, кто ноет про пеп8, просто не работал с flake8

Я всегда в своих проектах функции в camel case называю, еще ни разу не видел, как кому-то из сообщества​ от этого плохо стало

не надо смешивать серверную и фронтендную части

https://www.npmjs.com/package/node-python

Я всегда в своих проектах функции в camel case называю, еще ни разу не видел, как кому-то из сообщества​ от этого плохо стало

если ты делаешь это в питоне - я бы на кодревью отправил переписывать

не надо смешивать серверную и фронтендную части

Что значит не надо? Не надо писать одному человеку и серверную, и фронтенд часть? Ты из страны розовых единорогов?

https://www.npmjs.com/package/node-python

брось каку

если ты делаешь это в питоне - я бы на кодревью отправил переписывать

К сожалению, ты не мой тимлид

Что значит не надо? Не надо писать одному человеку и серверную, и фронтенд часть? Ты из страны розовых единорогов?

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

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

Иногда стек вызовов функций удобнее писать в лисп-стайл даже на питоне.

К сожалению, ты не мой тимлид

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

консистенси > пеп8

Иногда стек вызовов функций удобнее писать в лисп-стайл даже на питоне.

пока это не нарушает pep8 - welcome

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

Они, как бы пересекаются. API отдаёт переменные. По гайдлайнам в underscore_case. А в JS что с ними делать? Переписывать в camelCase? Использовать чуждый underscore_case? Это херня какая-то. Я бы уж предпочёл какой-то единый стиль. Пускай он будет и нестандартным для языка.

что-то мне это напоминает дискуссии в стиле "пешу как хачу - мы ни на икзамини"

что-то мне это напоминает дискуссии в стиле "пешу как хачу - мы ни на икзамини"

именно

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

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

Они, как бы пересекаются. API отдаёт переменные. По гайдлайнам в underscore_case. А в JS что с ними делать? Переписывать в camelCase? Использовать чуждый underscore_case? Это херня какая-то. Я бы уж предпочёл какой-то единый стиль. Пускай он будет и нестандартным для языка.

каким боком меня должно волновать именование переменных в двух разных языках?

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

парсить его смогут спокойно оба

как там переменные будут названы - дело десятое