Ruda911: добавьте тег Telegram API, и укажите что это pyTelegramBotAPI, тогда может найдутся люди которые вам помогут.
П.С. Я полчаса потратил на то чтобы выяснить откуда у кода ноги растут.
Нужен контекст. Похоже вы используете какой-то фреймворк или чужой код. По этому отрезку нельзя ответить на вопрос. Ссылку на гитхаб или что-то где можно посмотреть все целиком или хотя бы все задействованные части.
а как вы определили что шаг должен быть в первом случае 5 а во втором 50? А если бы границы были 2040 - 235 какой был бы интервал?
все просто, как только вы поймете как вы делаете вычисление интервала, останется только записать формулу :)
я бы просто взял шаг = макс/мин и округлить. а вот как именно округлять тут зависит от размерности, чем больше числа тем, грубее нужно округлять.
lavr_fedotov:
Из самого простого:
Вы можете использовать "in list" конструкцию питона;
if m.text in ['/сalculate', '/start', '\xF0\x9F\x93\x96', '/ads']:
и второе: вы можете сгруппировать условия с критерием длинны, по числовому значению
or (m.text in 'Qubit' and len(m.text)==5)
or (m.text in 'Quark' and len(m.text)==5)
#эквивалентно:
if len(m.text) == 5 and m.text in ["Qubit", "Quark"]:
Ну а в приницпе перейти на вариант предложеный Влад Григорьев.
KuzmenkoArtem: вряд ли кто-то когда либо ставил себе задачу обьяснить юнит тестирование для не программистов. Поэтому, скорее всего такого видео не существует. Для программистов - сколько угодно.
Толстый Лорри: пример с "открыть два раза подряд" покажется для "не программиста" надумманым. А что замочную скважину может заесть при низких температурах, с этим все сталкивались.
Можно писать end-to-end тесты на Selenium. Они будут реагировать на изменение классов в стилях. Поскольку доступ к элементам происходит через DOM и CSS селекторы. И на изменения в функционале.
Ярослав Корнилов: Задача теста не столько прояснить что там происходит, а иметь гарантию, что то, что сейчас поисходит будет происходить и завтра и послезавтра. (как это обычно бывает, а тут мы щас так сделаем, ну тут потом придумаем, щас вот это заимплементим, ну компилируется, да, ну вроде все как надо работает.. и потом большие глаза когда при добавлении нового кода начинают сыпаться исключения и пр., С тестами вы заставите себя все продумать прежде чем начинать писать, вы спрашиваете себя а каким условиям должен удовлетворять эта часть программы, начинаете думать "что будет если", а когда пишешь вперед, один критерий это ну компилируется же, я ввел текст в поле, отлично, сложение работает, я на прогоне сложил три и два, нормально. Ручной прогон программы это максимум смоук тест, и он никак не может заменить юнит тестов. Используя программный тест вы так же гарантируете что тест всегда будет выполняться с одинаковыми условиями, а не так как на ручном прогоне, то сложил пять и два а то шесть и восемь).
Не знаю может вам аналогия такая подойдет. Представьте себе стройку, мы можем вдоль всех плоскостей натянуть красную проволоку, и если части конструкции отвалятся, проволока неминуемо порвется и зазвенит сигнализация. Это тестирование после кода. Так же можно создать каркас из сигнализационной проволоки и строить так чтобы не зазвенело. Это будет TDD. Заметьте что в первом случае мы просто обнесли проволокой что есть не имея представление а то ли что нужно было построено. При втором подходе вам придется строить по намеченому заранее контуру.
Ярослав Корнилов: насчет архитектуры я имею ввиду, когда вы пишете тесты вы используете те классы и методы которые присутсвуют в системе. Либо их нет в системе и их нужно написать. Т.е вы пишете тест так как вам было бы удобно, например:
Validator v = Controllers.getController("org.me.StreamValidator")
assertNotEquals(v, null)
естественно никаких этих классов еще не существует, но написав такой тест вы определили как вы будете пользоваться системой, т.е. ее архитектуру. Вы задокументировали в коде дизайн системы. Это и есть TDD.
У меня на проекте ввели новую архитектуру коммуникации компонент, я пишу тесты, чтобы понять как она устроена. Документирую посредством тестов свои предположения о том как она работает (за отсутствием вменяемой документации). Задокументировав основные предположения, я могу браться за разработку самой программы используя эту новую архитектуру, зная что если кто-то начнет менять архитектуру по ходу дела, а такое у нас случается не редко, мои тесты мне на это укажут. Тесты это в том числе и своеобразное средство от неведения.
Можно смотреть только цены и когда вы найдете что нужно добрать информацию по товару (соседнй или родительский элемент) не уверен будет ли это ощутимо быстрее. В вашем случае решает частота опроса. Обработка то в принципе мгновенная.
Артём Петренков: спасибо за замечание. Почитал, выяснил, что они купили его потому что trello нацелен на "не-разработчиков" - логичный ход, так так расширяет рынок сбыта.
Артём Петренков: Откуда мне знать зачем Atlassian создало Trello если в Jira тоже есть кан-бан карточки :)
С Trello не работал ни разу. Но и в дефолтной инсталляции Jira никаких кан-бан карточек не замечал.
javedimka: Это верно что искать нужно, но, иногда бывает, что не знаешь что именно искать. Тогда гугл не поможет. Поэтому считаю что если хочется тыкнуть носом, то нужно указать поисковый запрос, чтобы человеку польза была.
Ingernirated: throw прерывает дальнейшее выполнение кода и вы непосредственно переходите в блок обработки исключения.
В блоке аварийного выхода у вас есть возможность "посадить самолет" более менее чтобы никто не пострадал, отправить сигнал в в службу спасения и пр. В противном случае, самолет просто разбобьется и все будут ходить гадать как такое случилось. Что же там произошло?
Ах да, исключение пробрасывается наверх если его не обработать, в отличии от простого вывода, где другие компоненты не узнают о том что произошла авария. Это также позволяет вам централизовать архитектуру обработки ошибок.
