Beautiful Code

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

Собс-но если собрать кучу коротких эссе от разных людей, то результат выйдет вполне предсказуемым - некоторые вещи кажутся мне просто неинтересными, некоторые требуют нехилой математической подготовки откуда ей взяться после 3 классов и двух коридоров церковно-приходской школы, некоторые же по сравнению с прочими выглядят тривиально или вообще полным бредом. Примерно вот так они выглядят тащемта:

Почему-то особенно радуют бредовостью тривиальностью статьи про python

Вот например глава 18 про реализацию словарей в питоне жжет - мы тут померяли кое-то и решили, что вот так оно лучше. Ни формул (как у Бентли), ни теоретического обоснования - нету ничего, см. комменты в коде, ага. Дичайше радует следующая цитата:

This means dictionaries are never resized on deletion. If you build a large dictionary and then delete many keys from it, the dictionary’s hash table may be larger than if you’d constructed the smaller dictionary directly. This usage pattern is quite infrequent, though. Keys are almost never deleted from the many small dictionaries used for objects and for passing function arguments. Many Python programs will build a dictionary, work with it for a while, and then discard the whole dictionary.Therefore,very few Python programs will encounter high memory usage because of the no-resize-on-deletion policy

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

Или вот глава 19 про реализацию итераторов в numpy тоже не блещет умом и практичностью:

The arrays in this structure (coords, dims_m1, strides, backstrides, and factors) are fixed-size arrays with dimensions controlled by the NPY_MAXDIMS constant. This choice was made to simplify memory management. However, it does limit the number of dimensions that can be used. It could easily be handled differently by dynamically allocating the needed memory when the iterator is created; such a change would not alter the fundamental behavior.

Я не поленился, проверил в сорцах - NPY_MAXDIMS у них равно 32. Внезапно 33х размерные массивы перестанут работать. Но даже и с таким запасом память банально транжирится зря - я с трудом могу себе представить применение массивов с более чем 4мя размерностями. Соотв-но ничто (кроме лени канешна же) не мешало реализовать три разных типа итераторов:

• последовательный - когда массив просто итерируется подряд в foreach
• для мелко-размерных массивов, скажем до 4х размерностей - использовать текущую реализацию с урезанным NPY_MAXDIMS
• для всех прочих не хардкодить размерность, а выделять все нужные данные в хвосте структуры и иметь поле для числа размерностей

Причем даже не нужно больших усилий сопрягать все это хозяйство - можно было завести пару указателей на ф-ции (как было описано буквально двумя главами ранее про файловые системы в FreeBSD) - get_next и is_end например. Тем не менее у автора хватило наглости утверждать что его код не просто красив, но и вообще образец совершенства и гибкости

И не смейте даже подумать, что я пристрастен - например самая угарная глава 11 - про систему, написанную на perl. Автор несколько лет писал систему почтовых сообщений с распределенным управлением ключами (типа все секурно и параноидально) и приводит вот такой кусок кода:

sub _getuser {  # Get a user object from the database.
  my $self = shift; my $username = shift;
  $self->db->table('users'); $self->db->template($usertmpl);
  my ($user) = $self->db->select("WHERE USERNAME = '$username'");

Остается только пожелать гражданину удачи с именами пользователей типа ';delete from users where username <> '

С интересом продолжаю чтение