принимать в команду людей, которые не умеют следовать простейшим соглашениям.
Не понял, при чём тут люди какие-то, если речь шла о PEP? Люди нанимаются и обязаны следовать тому, что принято в команде/компании, а последння не обязана следовать PEP'у и может вполне "законно" создавать свои правила.
Изначально речь шла не за людей, а за авторов. Вы же понимаете разницу или нет? Автор может быть компанией, командой, и отдельно взятым Васей которым совершенно не обязательно "Нужно просто следовать соглашениям."
Не понял, для чего "супер-pip"'у проходить по проекту, когда об этом может позаботится автор пакета и создать requirements.txt?
Даже если это пупер супер pip, то причем здесь редактирование? Максимум что нужно — это чтение.
Еще раз — параметризация import ИСКЛЮЧИТЕЛЬНО для автора проекта. Никаким девопсам никакого до этого дела не должно быть. Для них автор кода готовит requirements.txt.
Many projects have their own coding style guidelines. In the event of any conflicts, such project-specific guides take precedence for that project.
Насколько я понял, здесь указано, что PEP не является законом для кода, и если в вашем проекте сущетвуют свои правила, то они в любых конфликтах приоритетней этого PEP.
Так что, совершенно не обязательно следовать указанию в 80 cols. Тем более, этот PEP морально устарел, ему уже 18 лет. В 2001 году возможно это было актуально, чтобы код умещался на мониторе 14-15 дюймов которые в те времена были популярны.
он может быть девопсом, например, и решать пакетированием чисто задачи доставки кода на стейдж/прод.
Так… и в чём сложности?
Он же может выполнить pip requirements.txt который напишет автор кода или какой-нибудь авто-tools сгенерирует его для пакета. Зачем девопсу лезть в код? Не нужно.
А import должен писать джун, у которого вообще нет полномочий, чтобы решать, какую версию пакета использует проект.
А это я не совсем понял. Речь о том, чтобы "физически" был запрет выбора иной версии пакета в проекте кроме той, что установил devops? Ну так и не будет у него такой возможности.
Правильного ответа не существует до тех пор, пока кто-то не получит осознание с помощью той или иной версии, он же и определит, кто прав лично для него. Для другого правда может быть другой.
Я привел пример своей версии и выразил своё мнение, что термин для меня лично не размыт, совершенно чёткий.
Мы можем спорить до второго пришествия, и каждый останется при своём мнении.
Совершенно верно. Правда у каждого своя )) На этом предлагаю закончить дискуссию и не тратить на это время )) Всего доброго!
Когда, чтобы поменять что-то в инфраструктуре, приходится лезть в код − это называется «прибили гвоздями»
А почему бы нет? Если автор пакета решил, что его пакет зависит от какой-то версии другого пакета, например версии 1.x, и не работает, скажем с версией 2.x, то как вы будете менять инфраструктуру не залазия в код?
Если для понимания значения некоторого термина нужно привлекать фантазию, аналогии, субъективные ассоциации и аргумент «мне кажется, что»
Интересное заявление. С "мне кажется" согласен, это было лишнее в моём предложении, надо было более увереннее писать.
Но всё, что вы перечислили нужно исключать, чтобы получить понимание о термине? А как собственно понимать остаётся? Зубрёжкой?
В теориях получается нет терминов, так как их нельзя понимать по-вашему, так как для этого нужно привлекать всё, что вы перечислили?
термин расплывчато определён
Он не может быть в принципе быть расплывчатым или не расплывчатым. Не существует таких у него свойств. Расплывчатость лежит в границах только отдельно конкретно взятой личности и за пределы его понимания не выходит. У кого-то расплывчато, а у кого то не расплывчато. Тогда как Вы определите, расплывчат он сам по себе термин или нет?
плохочитаемые штуки
было бы понятно, что он делает.
ОЧЕНЬ плохой стиль
Это эмоции. Аргументов не увидел. Кому-то, например мне, непонятно что код делает, когда в нем присутствуют переносы. Это всё субъективность. Вам то нравится, мне это. Но объективных аргументов получается нет никаких?
Причем тут мониторы вообще?
При том, чтобы они ограничивали видимую длину строки и способствовали "хорошему" стилю программирования, соответствовали PEP'у.
Какое это соглашение будет, хорошее или плохое? Чем оно будет принципиально оличаться от 80 cols?
Ну первые 2 пунта еще куда не шло, можно принять за аргументы, но вот третий пункт… не аргументирован. Что значит плохой стиль? В чем его "плохость" проявляется? Конкретные примеры есть?
А тех, кто нарушает общепринятые соглашения, ИМХО, нужно публично расстреливать
Повеселили )) С большинством соглашений вполне можно согласиться, но вот это соглашения меня просто выбешивает и вынуждает создать аналогичное соглашение, чтобы производители мониторов не производили мониторы диагнональю больше 15'', а кто это соглашение будет нарушать, того, ИМХО:
Почему у Вас возникли сложности ответить на простой вопрос? Я хочу знать аргументы, что заставляет вас придерживаться 80 cols и почему вы отказываетесь, например от 100-120 cols.
означает ли ваше высказывание, что можно не соблюдать соглашения, если у вас монитор на 27'?
Конечно ДА, ведь это соглашение. С ним можно соглашаться, а можно не соглашаться. Выбор всегда остается за разработчиком. Ничто мне этому не препятствует (Python в Exception не вылетает).
Меня интересует почему Вы соглашаетесь с этим? Какие аргументы у этого соглашения? У вас монитор 15''? Или что? Можете аргументированно пояснить?
Действительно, очень странный PEP. Вместо того, чтобы решить задачу, они усложняют проблему. Вот что мешает параметризировать команду import и оставить только пользовательский каталог библиотек? Например:
import foo.bar <= 0.5
каталог в пользовательском пространстве:
python_lib
├── 3.5
└── 3.7
├── foo.0.4
│ └── bar
└── foo.1.0
└── bar
Вы скажите — Ну это же будет помойка, +100500 версий одного модуля, да и как быть с
$ pip install --upgrade <PACKAGE>
?
А не нужно апгрейдить существующий пакет! Только инсталлировать каждый раз новый пакет с новой версией. Но тогда же встанет проблема с версиями пакетов которые не используются в проектах и занимают место? Верно, такая проблема будет. Для этого инструмент pip можно снабдить чистильщиком, который просканирует проекты, найдет команду import, сопоставит с текущим каталогом пакетов в пользовательском пространстве и удалит лишние.
Что в этой схеме не так? Почему, например, такое решение не принято до сих пор, которое решает проблему заодно и с зависимостями от тех или иных версий пакетов/библиотек?
Значение термина «инкапсуляция» расплывчато и отличается от источника к источнику
Почему расплывчато? Инкапсуляция от англ. encapsulation и от лат. in capsula, то есть что-то в капсуле (коробочке). Далее не трудно вообразить некую коробочку (класс), сверху которой есть только какие-то кнопки управления (публичные методы), а в целом весь механизм скрыт от пользователя (программиста который использует класс).
В данном случае, любой класс в котором есть хотя бы одна переменная и один метод который ею управляет наглядно демонстрирует этот принцип
class Phone:
number = "111-11-11"
def print_number(self):
print( "Phone number is: ", self.number )
Мне кажется, что здесь как раз таки нет принципа инкапсуляции, поле number открыто и доступно из вне. Можно вызвать метод, а можно обратится к полю = получим один и тот же результат, стало быть ничего не сокрыто (не инкапсулировано).
Та же джанга предлагает увеличивать допустимую длину строки до 100-120 cols
А чем это плохо? Как быть программисту у которого монитор >= 27''? Страдать с 80 cols на четверти экрана? Поясните пожалуйста, как Вы работаете с этим соглашением?
Мне вот всё равно не понятно назначение g и инициализации там формы SearchForm, если:
переменная g специфична для каждого запроса и каждого клиента
и еще инициализация g.search_form происходит в функции @bp.before_app_request
Правильно ли я понимаю, что объект формы заново инициализируется в g при каждом новом запросе? Почему бы тогда не записать инициализацию формы в функции просмотра (routes) как это было в предыдущих уроках?
Если бы g.search_form не была специфична для каждого запроса, то было бы понятно, что это оптимизация создания объектов в Python — однажды созданный объект для всего приложения, а не каждый раз для отдельного запроса. Или я не правильно понял вообще всё с этой g? ))
Вопрос снимаю )) Я просто загнался и надо было немного отдохнуть ))
Переменная bp остаётся в пространстве модуля, т.е. в routes.bp, а из этого модуля пространство __init__.py не доступно.
Это и так было мне понятно, но пока рефакторил код по статье, запутался что и куда импортируется и возник этот вопрос ))
Не понял, при чём тут люди какие-то, если речь шла о PEP? Люди нанимаются и обязаны следовать тому, что принято в команде/компании, а последння не обязана следовать PEP'у и может вполне "законно" создавать свои правила.
Изначально речь шла не за людей, а за авторов. Вы же понимаете разницу или нет? Автор может быть компанией, командой, и отдельно взятым Васей которым совершенно не обязательно "Нужно просто следовать соглашениям."
Вы же их, почему-то хотите расстреливать ))
Не понял, для чего "супер-pip"'у проходить по проекту, когда об этом может позаботится автор пакета и создать requirements.txt?
Даже если это пупер супер pip, то причем здесь редактирование? Максимум что нужно — это чтение.
Еще раз — параметризация import ИСКЛЮЧИТЕЛЬНО для автора проекта. Никаким девопсам никакого до этого дела не должно быть. Для них автор кода готовит requirements.txt.
Обнаружило в PEP8 следующее:
Насколько я понял, здесь указано, что PEP не является законом для кода, и если в вашем проекте сущетвуют свои правила, то они в любых конфликтах приоритетней этого PEP.
Так что, совершенно не обязательно следовать указанию в 80 cols. Тем более, этот PEP морально устарел, ему уже 18 лет. В 2001 году возможно это было актуально, чтобы код умещался на мониторе 14-15 дюймов которые в те времена были популярны.
Импорты кто пишет? Автор кода? Значит автор кода.
Так… и в чём сложности?
Он же может выполнить pip requirements.txt который напишет автор кода или какой-нибудь авто-tools сгенерирует его для пакета. Зачем девопсу лезть в код? Не нужно.
А это я не совсем понял. Речь о том, чтобы "физически" был запрет выбора иной версии пакета в проекте кроме той, что установил devops? Ну так и не будет у него такой возможности.
Правильного ответа не существует до тех пор, пока кто-то не получит осознание с помощью той или иной версии, он же и определит, кто прав лично для него. Для другого правда может быть другой.
Я привел пример своей версии и выразил своё мнение, что термин для меня лично не размыт, совершенно чёткий.
Совершенно верно. Правда у каждого своя )) На этом предлагаю закончить дискуссию и не тратить на это время )) Всего доброго!
Я не понял Вашего аргумента.
А почему бы нет? Если автор пакета решил, что его пакет зависит от какой-то версии другого пакета, например версии 1.x, и не работает, скажем с версией 2.x, то как вы будете менять инфраструктуру не залазия в код?
Интересное заявление. С "мне кажется" согласен, это было лишнее в моём предложении, надо было более увереннее писать.
Но всё, что вы перечислили нужно исключать, чтобы получить понимание о термине? А как собственно понимать остаётся? Зубрёжкой?
В теориях получается нет терминов, так как их нельзя понимать по-вашему, так как для этого нужно привлекать всё, что вы перечислили?
Он не может быть в принципе быть расплывчатым или не расплывчатым. Не существует таких у него свойств. Расплывчатость лежит в границах только отдельно конкретно взятой личности и за пределы его понимания не выходит. У кого-то расплывчато, а у кого то не расплывчато. Тогда как Вы определите, расплывчат он сам по себе термин или нет?
Это эмоции. Аргументов не увидел. Кому-то, например мне, непонятно что код делает, когда в нем присутствуют переносы. Это всё субъективность. Вам то нравится, мне это. Но объективных аргументов получается нет никаких?
При том, чтобы они ограничивали видимую длину строки и способствовали "хорошему" стилю программирования, соответствовали PEP'у.
Какое это соглашение будет, хорошее или плохое? Чем оно будет принципиально оличаться от 80 cols?
Ну первые 2 пунта еще куда не шло, можно принять за аргументы, но вот третий пункт… не аргументирован. Что значит плохой стиль? В чем его "плохость" проявляется? Конкретные примеры есть?
Повеселили )) С большинством соглашений вполне можно согласиться, но вот это соглашения меня просто выбешивает и вынуждает создать аналогичное соглашение, чтобы производители мониторов не производили мониторы диагнональю больше 15'', а кто это соглашение будет нарушать, того, ИМХО:
))))
Почему у Вас возникли сложности ответить на простой вопрос? Я хочу знать аргументы, что заставляет вас придерживаться 80 cols и почему вы отказываетесь, например от 100-120 cols.
Конечно ДА, ведь это соглашение. С ним можно соглашаться, а можно не соглашаться. Выбор всегда остается за разработчиком. Ничто мне этому не препятствует (Python в Exception не вылетает).
Меня интересует почему Вы соглашаетесь с этим? Какие аргументы у этого соглашения? У вас монитор 15''? Или что? Можете аргументированно пояснить?
Действительно, очень странный PEP. Вместо того, чтобы решить задачу, они усложняют проблему. Вот что мешает параметризировать команду import и оставить только пользовательский каталог библиотек? Например:
каталог в пользовательском пространстве:
Вы скажите — Ну это же будет помойка, +100500 версий одного модуля, да и как быть с
?
А не нужно апгрейдить существующий пакет! Только инсталлировать каждый раз новый пакет с новой версией. Но тогда же встанет проблема с версиями пакетов которые не используются в проектах и занимают место? Верно, такая проблема будет. Для этого инструмент pip можно снабдить чистильщиком, который просканирует проекты, найдет команду import, сопоставит с текущим каталогом пакетов в пользовательском пространстве и удалит лишние.
Что в этой схеме не так? Почему, например, такое решение не принято до сих пор, которое решает проблему заодно и с зависимостями от тех или иных версий пакетов/библиотек?
Почему расплывчато? Инкапсуляция от англ. encapsulation и от лат. in capsula, то есть что-то в капсуле (коробочке). Далее не трудно вообразить некую коробочку (класс), сверху которой есть только какие-то кнопки управления (публичные методы), а в целом весь механизм скрыт от пользователя (программиста который использует класс).
Мне кажется, что здесь как раз таки нет принципа инкапсуляции, поле number открыто и доступно из вне. Можно вызвать метод, а можно обратится к полю = получим один и тот же результат, стало быть ничего не сокрыто (не инкапсулировано).
А чем это плохо? Как быть программисту у которого монитор >= 27''? Страдать с 80 cols на четверти экрана? Поясните пожалуйста, как Вы работаете с этим соглашением?
Ошибки в тексте:
С наивных объектов по всей видимости надо исправить на нативные объекты )))))
Python 2.7 старше (старее), чем Python 3.4
по другому: Python 3.4 моложе (новее), чем Python 2.7
Мне вот всё равно не понятно назначение g и инициализации там формы SearchForm, если:
и еще инициализация g.search_form происходит в функции @bp.before_app_request
Правильно ли я понимаю, что объект формы заново инициализируется в g при каждом новом запросе? Почему бы тогда не записать инициализацию формы в функции просмотра (routes) как это было в предыдущих уроках?
Если бы g.search_form не была специфична для каждого запроса, то было бы понятно, что это оптимизация создания объектов в Python — однажды созданный объект для всего приложения, а не каждый раз для отдельного запроса. Или я не правильно понял вообще всё с этой g? ))
Привет! В листинге app/models.py: SearchableMixin class. пропущен метод reindex:
Для чего служит этот импорт в app/__init__.py?
Вопрос снимаю )) Я просто загнался и надо было немного отдохнуть ))
Переменная bp остаётся в пространстве модуля, т.е. в routes.bp, а из этого модуля пространство __init__.py не доступно.
Это и так было мне понятно, но пока рефакторил код по статье, запутался что и куда импортируется и возник этот вопрос ))