Думаю, что про react-router стоило добавить о недавном мажорном релизе, значительно поменявшем данную библиотеку.
По поводу управления состоянием, для меня откровением стал Recoil: в своих проектах выбрал для себя его окончательно - минималистичный, очень соответствует духу React и отлично без проблем вписывается в React-проекты без значительных доработок под него.
почему вместо того, чтоб оставлять комментарий // TODO, я не могу сразу сделать то, что там написано?
Потому что это заставляет переключать контекст относительно вашей текущей задачи. А если при реализации этого TODO, вам понадобится написать ещё два TODO?
Занимательная математика:
В проекте, с которым я работаю около 15 000 000 строк кода.
Пусть я буду читать по строке в секунду без остановки (без сна, обеда, отпуска, выходных и перерывов) — на это мне понадобится примерно полгода. Если всё же предположить, что я буду читать по строке в секунду только в рабочее время, то у меня уйдёт более двух лет. Всё это время я не буду работать и буду только читать код, который, кстати, за два года кардинально изменится. Если заложить время не только на чтение, но и на его обдумывание, то, боюсь представить время на такое обдумывание.
Такие дела.
1) Не понимаю, как ваше первое предложение соотносится со вторым? И что, что списки гетерогенны? А кортежи не гетерогенны? Как это вообще связано с тем, что я сказал?
2) Как связано то, что кортежи неизменяемы с тем, что итерация или проверка на вхождение по ним якобы шустрее аналогичной для списка?
3) Нет, строка в Python совсем не тоже самое, что кортеж.
4) А теперь самое главное. Возьмём кусок вышеприведенного кода с заменой списка на кортеж и без замены, вот так:
>>> test1 = lambda response: response in ('y', 'д')
>>> test2 = lambda response: response in ['y', 'д']
>>>
затем дизасемблируем обе функции, сначала ту, что с кортежем:
Есть ли (или будет ли) возможность прикручивать свои свои языки программирования и/или VCS?
И мне кажется, что вот этот момент у Вас не очень хорош:
Следует иметь в виду, что вне зависимости от количества пользователей в той или иной лицензии, одна из учетных записей по умолчанию будет административной, еще одна — гостевой. Гостевую при желании можно отключить. Таким образом, 10 пользователей = 8 пользователей + администратор + гость; 25 пользователей = 23 пользователя + администратор + гость; и так далее.
Есть ощущение, что честнее было бы не отрезать у клиентов два пользователя от озвученных, а добавлять этих пользователей к числу купленных, иначе это выглядит как неприятная сноска мелким шрифтом.
На самом деле Ваш код просто ужасен. Автор, извините, но у Вас C++ головного мозга, на python так не пишут. Pythonic-код — это понятный, легко-читаемый код с нормальными именами переменных, Вы же, видимо, стремились к максимально короткому и насыщенному лишними абстракциями коду.
Я не очень в теме, поэтому могу задать тупые вопросы, не судите строго.
Совсем немного почитал и посмотрел о ПО и сервисах вольфрам и заинтересовался.
Собственно, вопросы:
Могу ли я дополнять, расширять базы знаний вольфрама и создавать свои?
Если да, то эта функциональность доступна и локально и в облаке?
Можете привести небольшой пример к выведанным вопросам или дать ссылку на подобный пример?
Базы знаний доступны только онлайн?
Есть ли какие-то сравнения производительности вольфрама по сравнению с другими языками?
Спасибо огромное, сайт просто великолепный, интерактивные примеры сделаны очень круто. Был бы рад увидеть среди них примеры на python.
Ни в коем случае не переделывайте дизайн — он идеален.
Думаю, что про
react-router
стоило добавить о недавном мажорном релизе, значительно поменявшем данную библиотеку.По поводу управления состоянием, для меня откровением стал
Recoil
: в своих проектах выбрал для себя его окончательно - минималистичный, очень соответствует духуReact
и отлично без проблем вписывается вReact
-проекты без значительных доработок под него.Потому что это заставляет переключать контекст относительно вашей текущей задачи. А если при реализации этого TODO, вам понадобится написать ещё два TODO?
В проекте, с которым я работаю около 15 000 000 строк кода.
Пусть я буду читать по строке в секунду без остановки (без сна, обеда, отпуска, выходных и перерывов) — на это мне понадобится примерно полгода. Если всё же предположить, что я буду читать по строке в секунду только в рабочее время, то у меня уйдёт более двух лет. Всё это время я не буду работать и буду только читать код, который, кстати, за два года кардинально изменится. Если заложить время не только на чтение, но и на его обдумывание, то, боюсь представить время на такое обдумывание.
Такие дела.
2) Как связано то, что кортежи неизменяемы с тем, что итерация или проверка на вхождение по ним якобы шустрее аналогичной для списка?
3) Нет, строка в Python совсем не тоже самое, что кортеж.
4) А теперь самое главное. Возьмём кусок вышеприведенного кода с заменой списка на кортеж и без замены, вот так:
затем дизасемблируем обе функции, сначала ту, что с кортежем:
всё логично и предсказуемо, а теперь ту, что со списком:
неожиданно? как видите, листинг вообще ничем не отличается.
Знакомьтесь, Peephole Optimizer, встроенный в CPython.
И мне кажется, что вот этот момент у Вас не очень хорош:
Есть ощущение, что честнее было бы не отрезать у клиентов два пользователя от озвученных, а добавлять этих пользователей к числу купленных, иначе это выглядит как неприятная сноска мелким шрифтом.
Откройте для себя enumerate.
На самом деле Ваш код просто ужасен. Автор, извините, но у Вас C++ головного мозга, на python так не пишут. Pythonic-код — это понятный, легко-читаемый код с нормальными именами переменных, Вы же, видимо, стремились к максимально короткому и насыщенному лишними абстракциями коду.
Совсем немного почитал и посмотрел о ПО и сервисах вольфрам и заинтересовался.
Собственно, вопросы:
Ни в коем случае не переделывайте дизайн — он идеален.
Думаю, что так будет красивей: