Хотя тут стоит упомянуть потенциальный выстрел в ногу: текстовые файлы открываются на чтение и запись в системной кодировке, которая вовсе не обязательно utf-8. Поэтому в open я всегда прописываю аргумент encoding='utf-8', чтоб на винде проблем не было (а для чтения вообще utf-8-sig, чтобы символ BOM нормально обрабатывался)
Нужность загрузки на PyPI действительно спорная (помимо двух упомянутых сайтов у меня есть ещё несколько, которые я не гружу на PyPI, потому что зачем), но тем не менее не вижу смысла не оформлять сайт как пакет изначально, так как пакет удобнее в пользовании (деплой через pip install по-моему намного лучше, чем какой-то убогий git pull) и в будущем передумать будет сильно труднее, чем изначально сделать всё правильно
Это лишь ваше личное мнение. Ничего не мешает сайту быть пакетом. У меня есть два сайта на фласке, опубликованные на PyPI, можете поискать и попробовать запустить у себя если интересно
Чтобы другие люди могли легко поднимать их у себя, ваш Капитан Очевидность. Да и деплой упрощается даже без PyPI — копируем whl-файл на сервер, pip install, migrate и в принципе всё
Неправильно понимаете, в питоне 3 и строки по умолчанию юникодные, и кодировка файла по умолчанию utf-8 — всё сразу. Писать # -*- coding: utf-8 -*- бессмысленно
Откройте своего Бизли на странице 772, и увидите там:
В Python 3 предполагается, что исходные тексты программ набираются в кодировке UTF-8.
2018 год на дворе, почему сайты на питоне до сих пор не оформляют как полноценные самодостаточные пакеты? Пакет с именем app не загрузишь на PyPI. В данном случае, конечно, достаточно переименовать app во что-нибудь адекватное, но меня расстраивает, что это не делают изначально (джанги это тоже касается, кстати)
К слову, Word прекрасно умеет копипастить форматирование как HTML-код. Если воткнуть js-обработчик Ctrl+V на сайте и немного почистить вставляемые данные от мусорных тегов, то получается конфетка и без WYSIWYG. То же самое касается и гуглдоков и прочих мест, которые умеют помещать text/html в буфер обмена
Ещё раз, в «чистоте эксперимента» нет никакого практического смысла, потому что никто не пользуется голым железом. Ещё раз, цель сабжа — измерение задержки, которую видит обычный пользователь в обычном окружении. Когда вы поставите «чистый эксперимент», это будет уже не обычное окружение.
Мне глубоко плевать, если мой ноутбук на Core i5 вдруг уделает Apple 2e покажет задержку в десять миллисекунд на каком-нибудь FreeDOS. Какое мне дело до FreeDOS, если я в повседневной жизни использую какой-нибудь gnome-terminal с композитным оконным менеджером, с которыми задержка, к примеру, сотня миллисекунд?
Сравнить «навороченность железа и время отклика» в принципе можно, но, ещё раз, у автора такой цели не было. И я тоже не вижу в этом смысла.
(мы ведь сравниваем навороченность железа и время отклика?)
Нет, мы сравниваем задержку, которую видит обычный пользователь на обычном (или почти обычном) компьютере в обычном для рассматриваемого компьютера окружении. Сравнивать голое железо нет никакого практического смысла, потому что голым железом никто (или почти никто) не пользуется. Вы же сами пишете этот комментарий через виртуальную машину в песочнице в фреймворке в нескольких абстракциях от железа, не так ли? :)
Насчёт одного символа — я как-то слабо представляю, как сравнивать не один символ, если обычные клавиатуры позволяют вводить текст только посимвольно
А какой смысл во всём этом, если простой пользователь всё равно не будет проводить все эти манипуляции и у него в итоге все эти задержки всё равно будут? Как я уже отмечал выше, измерения в сферических условиях в вакууме не столь интересны. Таких условий всё равно ни у кого нет. Так-то можно на современный комп воткнуть какой-нибудь FreeDOS и получить офигенную скорость отклика, но зачем?
Впрочем, об этом даже в самой статье написано:
… измерения произведены с настройками, максимально близкими к настройкам ОС по умолчанию, поскольку примерно 0% пользователей меняют настройки дисплея для уменьшения буферизации, отключения компоновщика и т.д.
По-моему как раз наиболее корректно сравнивать с тем, чем человек пользуется в повседневной работе. Лично я не сижу в /dev/tty и поэтому сравнение с ним для меня ничего не будет значить :) (Хотя, конечно, увидеть измерения /dev/tty в табличке всё равно будет любопытно)
А зачем усложнять-то синтаксис? Сейчас синтаксис вида <тег> может иметь аж ТРИ разных значения: самозакрывающийся тег (<br/>), открытие тега (<div>) или открытие тега с закрытием предыдущего тега (<p>1<p>2 эквивалентно <p>1</p><p>2</p>). Нахрена это всё, когда можно просто считать <тег> открытием тега и не мудрить мозги ни себе, ни разработчикам парсеров?
Кстати, с вот этим вот <p><p> связана ещё одна подстава: многие пишут что-то вроде <p>1<blockquote>2</blockquote>3</p>, но это парсится как <p>1</p><blockquote>2</blockquote><p>3</p>, отчего могут отвалиться некоторые CSS-селекторы — это одна из вещей, которая бесит меня больше всего в HTML. Здесь приходится неизбежно запасаться справочниками и зубрить все теги наизусть. На этом даже разработчики адмики Django попадались (в одной из версий заменили-таки все <p> на <div>).
Алсо, если бы браузеры вместо попыток исправить ошибки кривых исходников отказывались отображать сайт, как это было с XHTML — интернет сильно похорошел бы.
Справедливости ради, имэйл мог выродиться в том числе именно из-за геморройной настройки, потому что протокол изначально ущербен. Какой-нибудь не менее федеративный ejabberd поднимается в пару кликов правок конфига, и сам протокол XMPP в принципе не имеет многих из проблем, которые имеет почта — и таки многие имеют свои собственные джаббер-сервера, чего не скажешь про почту. Грамотно продуманная федерация, имхо, имеет право на существование без вырождения
Нужность загрузки на PyPI действительно спорная (помимо двух упомянутых сайтов у меня есть ещё несколько, которые я не гружу на PyPI, потому что зачем), но тем не менее не вижу смысла не оформлять сайт как пакет изначально, так как пакет удобнее в пользовании (деплой через pip install по-моему намного лучше, чем какой-то убогий git pull) и в будущем передумать будет сильно труднее, чем изначально сделать всё правильно
Чтобы другие люди могли легко поднимать их у себя, ваш Капитан Очевидность. Да и деплой упрощается даже без PyPI — копируем whl-файл на сервер, pip install, migrate и в принципе всё
Я не понял, откуда такой вывод? Создал сейчас Python-файл в Блокноте без всяких явных указаний кодировок —
Неправильно понимаете, в питоне 3 и строки по умолчанию юникодные, и кодировка файла по умолчанию utf-8 — всё сразу. Писать
# -*- coding: utf-8 -*-бессмысленноОткройте своего Бизли на странице 772, и увидите там:
2018 год на дворе, почему сайты на питоне до сих пор не оформляют как полноценные самодостаточные пакеты? Пакет с именем
appне загрузишь на PyPI. В данном случае, конечно, достаточно переименоватьappво что-нибудь адекватное, но меня расстраивает, что это не делают изначально (джанги это тоже касается, кстати)Да в общем-то не осталась, вот такая страница абсолютно валидна:
Мне глубоко плевать, если мой ноутбук на Core i5 вдруг уделает Apple 2e покажет задержку в десять миллисекунд на каком-нибудь FreeDOS. Какое мне дело до FreeDOS, если я в повседневной жизни использую какой-нибудь gnome-terminal с композитным оконным менеджером, с которыми задержка, к примеру, сотня миллисекунд?
Сравнить «навороченность железа и время отклика» в принципе можно, но, ещё раз, у автора такой цели не было. И я тоже не вижу в этом смысла.
Нет, мы сравниваем задержку, которую видит обычный пользователь на обычном (или почти обычном) компьютере в обычном для рассматриваемого компьютера окружении. Сравнивать голое железо нет никакого практического смысла, потому что голым железом никто (или почти никто) не пользуется. Вы же сами пишете этот комментарий через виртуальную машину в песочнице в фреймворке в нескольких абстракциях от железа, не так ли? :)
Насчёт одного символа — я как-то слабо представляю, как сравнивать не один символ, если обычные клавиатуры позволяют вводить текст только посимвольно
А какой смысл во всём этом, если простой пользователь всё равно не будет проводить все эти манипуляции и у него в итоге все эти задержки всё равно будут? Как я уже отмечал выше, измерения в сферических условиях в вакууме не столь интересны. Таких условий всё равно ни у кого нет. Так-то можно на современный комп воткнуть какой-нибудь FreeDOS и получить офигенную скорость отклика, но зачем?
Впрочем, об этом даже в самой статье написано:
А зачем усложнять-то синтаксис? Сейчас синтаксис вида
<тег>может иметь аж ТРИ разных значения: самозакрывающийся тег (<br/>), открытие тега (<div>) или открытие тега с закрытием предыдущего тега (<p>1<p>2эквивалентно<p>1</p><p>2</p>). Нахрена это всё, когда можно просто считать<тег>открытием тега и не мудрить мозги ни себе, ни разработчикам парсеров?Кстати, с вот этим вот
<p><p>связана ещё одна подстава: многие пишут что-то вроде<p>1<blockquote>2</blockquote>3</p>, но это парсится как<p>1</p><blockquote>2</blockquote><p>3</p>, отчего могут отвалиться некоторые CSS-селекторы — это одна из вещей, которая бесит меня больше всего в HTML. Здесь приходится неизбежно запасаться справочниками и зубрить все теги наизусть. На этом даже разработчики адмики Django попадались (в одной из версий заменили-таки все<p>на<div>).Алсо, если бы браузеры вместо попыток исправить ошибки кривых исходников отказывались отображать сайт, как это было с XHTML — интернет сильно похорошел бы.
кликовправок конфига, и сам протокол XMPP в принципе не имеет многих из проблем, которые имеет почта — и таки многие имеют свои собственные джаббер-сервера, чего не скажешь про почту. Грамотно продуманная федерация, имхо, имеет право на существование без вырождения