def get_data_value(data, data_size): '''The helper function to get value of the data field from parameters header.''' fmt = "{}s".format(data_size) data_value = struct.unpack(fmt, data[0:data_size]) if data_value == 0: data_value = struct.unpack(fmt, data[8:data_size]) data_value = struct.unpack("b", data_value[0]) return data_value[0]
py.user.nextСпасибо ) а то я перерыл пол интернета и так и не понял, в чем дело
Там, наверное, что-то другое было, потом это поменяли, а условие забыли поменять. struct.unpack() всегда возвращает кортеж.
RodegastЯ сейчас на сишнике прогу делаю. Возникла проблема “как открыть файл на терабайт?”, открыл, потом “как применить fseek() к терабайтному файлу?” - обычные проблемы сишника. Но вроде решилось всё постепенно. (Через специальные дефайны fopen() подменяется на fopen64(), но fseek() всё равно принимает long int для позиции, нельзя скакнуть далеко. Пришлось делать в обход.) Потом дальше “а как сделать мок для юнит-теста?”. Оказалось, что и тут не всё гладко. Решил делать без моков, иначе надо полностью менять фреймворк для юнит-тестов, а я так привык к стандартному, он такой удобный, я его даже ещё не изучил наполовину.
Вот это как раз одна из причин по которой я перехожу на Haskell.
RodegastТак я тебе говорю, что это не проблема. Это всё можно выявить с помощью юнит-тестов. Проблема - это когда ты что-то сделать не можешь.
Проблема не в типах, а в ошибках связанных с динамической типизацией.
func main() {
i := 0
fmt.Println(i == 0.5)
}Rodegast:) В разных языках разные ошибки. Я вот со студентами вожусь. Очень хорошо видно как человек пишет не то что имеет ввиду. И отлично они это делают на любых языках и на питоне и на C++ и на haskel и на ada. На последних меньше, поскольку мало кто их использует.
Вот это как раз одна из причин по которой я перехожу на Haskell.
py.user.nextНа сишке наверное. В плюсах проблем меньше поскольку там fstream в котором специальный тип для позиции в файле и для смещений. Но тоже была ложка дегтя MS ссылаясь на стандарт делали его unsigned long. а g++ и другие доступные к тому времени компиляторы делали тип таким что все было ок. Эта проблемка решилась патчем иклудников fstream у MS Visual studio.
Возникла проблема “как открыть файл на терабайт?”
py.user.nextC++ - язык со слабой типизацией
Если C++ брать, там нет такого, хоть там и строгая типизация.
py.user.next
Это же сравнение, оно что делает? запускается внутренние методы магические - это мощь.
py.user.nextНу и нахрена нужна была бы такая мощь, наличие которой обязывает к стопроцентному покрытию юнит-тестами? Мне кажется гораздо более логичной ситуация, когда ошибки выявляются компилятором, а не тестом. Если отставить в сторону снобизм, то для большей части задач юнит-тестирование вообще не нужно. Ну вот есть у меня на клиенте контроллер, который обрабатывает событие клика на иконке и показывает попап. Что я тут должен тестировать? А только ту гипотетическую ситуацию, когда чьи-то кривые руки изменят АПИ компонента-попапа. Если у меня клиентский код на тайпскрипте, то проблема решается сама собой - дженкинс не сможет собрать бандлы, коммит не попадет в мастер, криворукий гражданин во время не закроет задачу и больше никогда так не будет делать. С джаваскриптом проблему увидит либо пользователь, либо тест и то не факт, что автотест тут чем-то поможет. У питона те же самые косяки, которые никогда и ни за что не позволят столь вольно типизируемому языку стать стандартом разработки больших промышленных решений.
Это всё можно выявить с помощью юнит-тестов
Prelude> let i = 0.5 Prelude> let n = 1 Prelude> i == n False Prelude> i < n True Prelude> let err = '1' Prelude> i == err <interactive>:7:1: error: • No instance for (Fractional Char) arising from a use of ‘i’ • In the first argument of ‘(==)’, namely ‘i’ In the expression: i == err In an equation for ‘it’: it = i == err
