Pack/unpack float bug in Python

Looks really strange:

from struct import *
data = pack("<f", 1096037602)
print unpack("<f", data)
> 1096037632

SHA256 в Python

SHA256 в Python бывает и стандартный (из hashlib), и сторонний (из PyCrypto). Интересно, что при неосторожном использовании они дают разные результаты.

Во-первых, SHA256.new() из PyCrypto сразу после создания имеет digest. Это SHA от пустой строки - широко известное 0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.

Во-вторых, каждый update накладывается в нём на предыдущий, поэтому если digest используется на следующей итерации, то SHA256.new() надо пересоздавать. То есть аналог

h = hashlib.sha256(data + h).digest()

Это

hsh_exec = SHA256.new()
hsh_exec.update(data + hsh)
h = hsh_exec.digest()

Д. Босуэлл, Т. Фаучер - Читаемый код или программирование как искусство

Небольшая книжка, в которой много полезных мелочей.

Например, более точные варианты названий для типичных функций:

send - deliver; dispatch; announce; distribute; route
find - search; extract; locate;recover
start - launch; create; begin; open
make - create; setup; build; generate; compose; new

Именованные интераторы для циклов (ui лучше, чем просто i).

Дополнительные постфиксы - size_mb, html_utf луче, чем size и html.

first/last - это включающие, а begin/end - исключающие границы.

Пометы в комментах:

TODO - задумано, но не сделано.
FIXME - известно, что есть проблема
HACK - неэлегантное решение проблемы
XXX - серьёзная проблема

Уже второе недоумение насчёт цикла do-while (которые непонятно, зачем нужен).

Разоблачён миф о том, что из функции должен быть только один выход. Он тянется из чистого C, где нередко забывали вычистить память перед выходом. Но c тех пор появились исключения, деструкторы и очистка мусора. А в C простительно писать goto cleanup;

Вообще, если удаётся уменьшить количество отступов, - это хорошо.

Запутывают код: многопоточность, обработчики сигналов/прерываний, исключения, указатели на функции и анонимные функции, виртуальные методы.

В JavaScript и Python переменная, объявленная внутри цикла, будет видна и снаружи. Вообще, область видимости переменных надо сужать. А самые лучшие переменные - константы, поэтому лучше всего менять их один раз.

Переменные объявлять где используются, а не в начале блока. Объявлять всё в начале блока - дурная традиция из Pascal и раннего C (хотя в C99 уже разрешили объявлять где угодно).

Также есть приятные куски кода:

Макрос для C++, чтобы убрать warning для неопределённого конструктора копирования или оператора присваивания.

#define DISALLOW_COPY_AND_ASSIGN(ClassName) \
  ClassName(const ClassName&); \
  void operator=(const ClassName&);

И потом писать:

class ClassName {
  private:
     DISALLOW_COPY_AND_ASSIGN(ClassName);
     ...
  public:
     ...
};

Python - filesize in bytes with proper prefix

 
def get_bytes_size_units(num):
  """ Get file size with proper units of measurement.
  """
  range_titles = ["b", "kB", "Mb", "Gb", "Tb", "PB", "EB", "ZP", "YB"]
  range_titles_len = len(range_titles)
  i = 1
  prev_value = 0
  new_value = num
  is_iteration = True
  while is_iteration:
    prev_value = new_value
    new_value = num >> ((i << 1) * 5)
    i += 1
    is_iteration = new_value < 0 and i < range_titles_len
  i -= 2
  return "%.2f%s" % (float(num) / float(1 << ((i << 1) * 5)), range_titles[i])

WordCount в Sublime

Sublime чудесен. Можно сказать, что проблема отсутствия под linux-ом Notepad++ успешно решена.

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

Соответствующий плагин нашёлся сразу, но он не умел посчитывать количество символов. Решил допилить, а заодно разобраться, что у этих плагинчиков внутри.

В результате – целый вечер открытий и удивительных экспериментов. Удивился встроенной консоли, попутно оптимизировал код и исправил баг с полем read_time в настройках.

Обновлённый код успешно merged и залит в основную ветку.

А удивил меня сам алгоритм подсчёта. Их там целых два, причём первый закомментирован:

#=====1
# wrdRx = Pref.wrdRx
# """counts by counting all the start-of-word characters"""
# # regex to find word characters
# matchingWrd = False
# words = 0
# for ch in content:
# # # test if this char is a word char
# isWrd = wrdRx(ch)
# if isWrd and not matchingWrd:
# words = words + 1
# matchingWrd = True
# if not isWrd:
# matchingWrd = False


#=====2
wrdRx = Pref.wrdRx
words = len([x for x in content.replace('\n', ' ').split(' ') if False == x.isdigit() and wrdRx(x)])

На первый вгляд, алгоритм 1 должен работать лучше и экономней. Фактически, перед нами нечто наподобие state machine, и его сложность не больше o(n). В то время как второй алгоритм создаёт кучу новых элементов только для того, чтобы их пересчитать.

На самом деле алгоритм 2 отрабатывает намного быстрее, чем 1. Например, чтобы подсчитать количество слов в “Петербургских трущобах” Крестовского, 2-ому нужно порядка 1 сек., а первому – 2.

Вот вам и оптимизация.

Phylosophy: ElseIf vs Switch, Python vs XSLT

There're ELSEIF operator in Python, and there aren't any SWITCH.

There're SWITCH operator in XSLT (aka <xsl:choose>), and there aren't any ELSEIF. There aren't any ELSE in it even.