Отпуска по уходу за ребенком могут быть использованы полностью или по частям также отцом ребенка, бабушкой, дедом, другим родственником или опекуном, фактически осуществляющим уход за ребенком.
Насколько я понимаю, «отпуск по уходу за ребёнком» не совсем правильно называть декретным (потому что последний — «отпуск по беременности и родам» — мужчинам недоступен), но людям, как всегда, лениво писать такие длинные названия.
Нет, не будет. Быстрее то, к чему привык, а для привыкшего к использованию мыши совместно с клавиатурой будет быстрее именно использование мыши.
Будет. Я говорю о скорости способа, а не скорости вас настоящего, который может им воспользоваться. При длительном использовании нового способа возникнет новая привычка. Скорость исполнения имеет смысл сравнивать только с учётом её возникновения и по прошествии некоторого времени. А чтобы не делать такое сравнение чисто экспериментальным — надо исходить из расстояний, на которые перемещаются кисти и пальцы и времени на бессознательный поиск новой позиции.
Я сам думал о том, чтобы начать повсеместно использовать vim, видя как некоторые преподы у нас быстро и (на вид) удобно им редактируют файлы, но привычка перевесила это желание :) Тем более, что непосредственно набор кода/текста — занимает относительно небольшую часть времени.
У sublime есть Vim-mode, vintage mode или что‐то в этом роде. У самого Vim есть большое количество проблем, связанных с исторически допущенными архитектурными просчётами либо же являющихся данью обратной совместимости (а то и тем, и другим сразу). Насколько я знаю в sublime можно запихать фактически что угодно, что поддерживает Vim, причём написать всё на Python, в Vim добавление части возможностей того же sublime (к примеру, поддержка <C-S-Key> или <C-Key> для не‐ASCII и некоторых ASCII символов) требует неплохого знания C, а то и вдобавок желания провести refactoring.
Относительно rebase. Бегло просмотрев документацию, я не совсем понял как происходит собственно rebase. Вот например есть дерево A-{B-C,D-E} и мы хотим сделать A-B-D-E-C. Как достичь этого?
У вас другой пример, я ответа на него не знаю. Точнее знаю, но это те же две команды¹, что и с mercurial (вариантов несколько, но все требуют как минимум две команды). В моём (A-{B-C,D-E} → A-B-C-E-D) — это та же команда (git rebase master, предполагая, что E — текущая ветка, а C — master), к которой просто добавили --interactive. Останавливаться именно на таком варианте (не прося изменить ветку, на которую происходит перенос той же командой) обычно имеет смысл, так как у меня чаще всего A-B-C — публичная master и менять её категорически не рекомендуется, а D-E, которую хочется превратить в E-D — feature branch. Соответственно, превращать A-B-C в A-B-D-E-C не нужно или даже невозможно (не примет upstream).
¹ Две команды:
hg rebase --source D --dest B && hg rebase --source C --dest E (можно использовать намного меньше символов, но так понятнее)
hg rebase --base E --dest C && hg histedit -r B
В данном контексте --source D и --base E (а также --rev D..E) эквивалентны. Git использует только --base (за исключением формы git rebase --onto master topicA topicB, эквивалентной hg rebase --rev 'topicA..topicB - topicA' --dest master).
Я ваше мнение понял, а вы никак не хотите признать что такое использование текстовых редакторов (перемещение клавишами) удобнее не для всех. Мне, например, намного удобнее и привычнее (соответственно, быстрее) указать позицию в редакторе мышью, чем идти к ней стрелками или смотреть точное число строк на сколько надо перейти. Поэтому, хотя при наборе команды в командной строке рука обычно не на мыши, потом для редактирования появившегося файла её в любом случай надо перенести на мышь. Странно, что дело вкуса и (даже больше) привычки вы пытаетесь рассматривать как «тезис», для которого возможно доказательство :)
Тезис — не удобство. Тезис — скорость. Я очевидно не смогу доказать, что всем удобнее было бы не использовать мышь в таких случаях. Даже я сам бы с этим не согласился, вспомнив о том, что использовал до изучения Vim. Но можно показать, что неиспользование мыши будет быстрее.
Кроме того, сравнивать скорости до возникновения привычки бесполезно. Но после её возникновения скорость ограничивается в первую очередь физически. Мышь+клавиатура может быть быстрее стрелочек, если изменений очень много. Она не может быть быстрее Vim при знании способов перемещения в любом случае и не может быть быстрее стрелочек при достаточно малом числе изменений (если их где‐то десяток и меньше). Впрочем, я всё равно не считаю стрелочки удобнее мыши и не считаю мышь удобнее навигации в Vim. Мышь также будет быстрее, если рука уже лежит на ней.
Вырезал (в смысле Ctrl+X, а не удалил) строчку, стал смотреть по графу куда надо вставить, отвлёкся на перемещение другого коммита, про первый забыл (так у меня раз было).
Понятно. У меня просто другой порядок действий: сначала смотрю, куда перемещать, потом уже выполняю перемещение. Соответственно к моменту удаления решение уже принято. Как‐то не подумал, что может быть иначе: зачем удалять строчку, если неизвестно надо ли удалять её вообще (может, проще переместить другую)? Да и в части случаев (именно в это время мною обычно используется fixup) я знаю, что с чем буду объединять ещё до фиксации изменения (ещё плюс git: наличие autosquash).
Остальная часть вашего комментария — это факты, которые и так понятно что верны, и смысла их обсуждать нет:
Можно было их дополнить (тем же autosquash). Или обсудить необходимость возможности histedit также делать rebase (я считаю это удобным, так как не придётся решать конфликты по два раза (из‐за rebase и из‐за изменения порядка; конфликты разные) в худшем случае, но аргументы против я тоже могу представить).
Если бы оно выполнялось часто, то я бы говорил про редакторы с расширениями и, соответственно, одну или две клавиши на действие. А так это просто мелкое неудобство, которого могло бы не быть.
Относительно мыши: если вы использовали git rebase -i из командной строки то рука вероятно не находилась на мыши. В этом случае, даже стрелочки + <Home>/<End> будут быстрее, чем заново искать основную позицию для правой руки (programming dvorak) после использования мыши: в отличие от позиций клавиш дополнительных блоков клавиатуры месторасположение мыши не фиксировано относительно основного блока. С us правда e[dit], f[old] и d[rop] на левой руке, только m[ess] (и p[ick]) нет, с git вообще все действия на ней (кроме p[ick], но последнее уже написано в обоих случаях), но перемещение руки на мышь всё равно остаётся более дорогим действием, чем перемещение на дополнительный блок, а <S-Home>/<S-End> — более быстрым, чем выделять мышью (если только не поддерживается тройное нажатие).
Постановка в начале не сложнее, потому что можно использовать клавишу <Home>.
И ещё, я категорически не понимаю, как использование редактора описанным вами способом сочетается с возможностью случайного удаления строки. Разве что разбирательства с перемещением курсора для последующей вставки отвлекают от самой задачи перемещения строки в нужное место настолько и занимают такое время, что за это время можно успеть получить сигнал (электронное письмо, кто‐то подошёл и т.д.), отвлечься на него и забыть про производимую операцию вообще. Я никогда не удалял случайно строчки именно по этой причине: dd или любое другое сочетание со схожим действием нажать ненамеренно проблематично, а за время перемещения строки в другое место я просто не успеваю отвлечься, чтобы потерять её.
Кстати, во многих программах выделение всей строки можно произвести тройным кликом.
А вообще, зачем всё это обсуждение таких небольших различий в скорости выполнения действия, которое обычно делается достаточно редко (например, реже чем hg ci/git commit)? Ну вот выяснили вы, что в некоторых случаях удобнее удалить строку, а в некоторых — поставить «d» в начале, и что?
Ничего. Ваш изначальный комментарий, ваш ответ и мой ответ на ваш ответ (считать те два мои комментария одним, я просто не успел отредактировать) были гораздо шире и касались более важных вещей. Но на следующем ответе вы уже коснулись только быстроты предпринимаемых действий и я просто продолжил доказательство тезиса, сомнение в котором было вами высказано. В данном случае — что удаление строки быстрее в любом редакторе.
Вообще по‐хорошему можно сократить все действия до одной клавиши: что в Vim, что во многих других редакторах, поддерживающих расширения. Но это экономит не настолько много времени, чтобы усиливать зависимость от наличия этих самых расширений.
Относительно лёгкости:
В nano (ещё один относительно стандартный консольный редактор, но без поддержки режимов) с этим делом примерно так же (одно <C-k> для удаления против многоклавиш (вероятно, легче всего <C-d><C-d><C-d><C-d>d) для замены).
В mcedit удаление одной строки на <C-y>, замена потребует больше клавиш (вероятно, наиболее простыми является либо <INS>drop, либо то же, что и у nano).
В gedit (GUI!) есть сочетание <C-d> для удаления всей строки. Для замены на drop вероятно легче всего использовать <C-S-Right>d.
В sublime (GUI!) судя по этой статье есть <C-k><C-k> для удаления до конца строки (т.е. курсор должен быть в начале) и <C-DEL>d для замены первого слова на d (замечу, что клавиша DEL несколько дальше k и потому первое набирается значительно быстрее).
В kate (GUI!) можно «удалить» строчку <C-d> (на самом деле осуществляет комментирование, если судить по этой PDF’ке). Считается, что kate знает, что такое «комментарий» в файле от git rebase. Если нет то, см. следующий абзац.
В любом редакторе можно «удалить» строчку путём написания одного символа #: git воспринимает такие строчки как удалённые.
Во всех примерах предполагается нахождение курсора в начале строки. Во многих примерах расположение курсора абсолютно не важно для удаления строки (верно если не указано обратное). Во всех примерах расположение курсора важно для замены слова.
Так что либо я не понимаю как в GUI редакторах быстро заменить одно слово на другое, либо ни о каком «по сути одинаково» речи быть не может. Замечу, что перемещение кисти куда‐либо с основной позиции слепой печати — операция заведомо более дорогая, чем нажатие дополнительных одной‐двух‐трёх (зависит от вашей скорости печати) клавиш, особенно если они расположены под разными руками.
А удаление vs drop — это dd (в любой части строки) vs Rdrop^[ или cwd^[ (но только в начале строки, то есть прибавляется ещё и команда на переход в начало строки) (вместо ^[ подставить ESC). Согласитесь, первое гораздо быстрее остального.
Эта необходимость указывать символ «d» для удаления отлично помогает от случаев, когда переставлял несколько коммитов и какую-то строчку случайно удалил или забыл вставить. У меня несколько раз точно такое бывало. Да и удаление строки не сказал бы что быстрее :)
Я в этом отношении более аккуратен, потому и имею другое мнение.
fixup это же просто fold, как написано в документации, только сообщение одного из коммитов игнорится?
Да.
Кейсов для использования exec я что-то не смог представить, приведите пару примеров. Mercurial хорошо поддаётся различному расширению функциональности, поэтому если это реально полезная фича, думаю её добавят.
Use-case для exec я тоже не знаю, но зачем‐то же он есть в git. То, что я могу представить проще и безопаснее делать без exec.
Это я что-то вообще не понял. Изменение порядка коммитов это же по сути и есть перемещение части из них?
Я имею ввиду, что A-{B-C,D-E} можно превратить одной git rebase -i в A-B-C-E-D, тогда как с mercurial вам придётся сначала делать A-B-C-D-E (или A-{B-C,E-D}), а потом уже только A-B-C-E-D: histedit не делает rebase.
У git всё же лучше интерфейс в этом плане: в mercurial нет fixup и exec, раньше не было reword; и histedit требует указания drop для удаляемых изменений, тогда как git обходится обычным удалением строки, что быстрее. Ещё histedit вызывает редактор для каждой строчки fold (squash из git), тогда как git обходится одним вызовом редактора на каждую серию squash/fixup (кажется, за исключением когда по пути встретились конфликты (если в дополнение к squash изменения были перемещены), но за это не поручусь). Ну и нельзя одной командой и переместить изменения, и изменить их порядок следования.
Одну вещь всё же хорошо придумали: названия всех действий занимают ровно четыре (или один) символа, так что можно использовать режим замены в редакторе.
Evolve пока «нету»: сами авторы говорят, что оно недопилена, и bitbucket пока не поддерживает.
Кроме того, непонятно зачем, но evolve также не разрешает изменять коммиты, отмеченные как «публичные». Учитывая, что история реально никуда не девается и есть способ автоматического исправления проблем, это странно.
Если бы я работал программистом, то я бы вряд ли поставил на работе такую систему. А дома — почему бы и нет? Останавливает только то, что единственная машина, на которой имеет смысл ставить distcc в качестве сервера, является единственной же, на которой мне когда‐либо требуются самостоятельно собранные exe’шники для windows (wine).
Про него, кстати, написано, что оно «feature of last resort» (т.е. последнее, что стоит использовать, только если других вариантов нет). Туда же, правда, записаны и любимые в git подрепозитории (subrepositories) (в git называются submodules), и largefiles.
Насколько я понимаю, единственное, чем MQ лучше технически — это возможностью переписывать историю на удалённом сервере. Evolve не зря назвали заменой MQ¹. К примеру, автор Vim никогда не принимает изменения из другого репозитория, всегда только патчи. MQ позволяет их удалить после принятия. Правда, я всё равно предпочитаю обычные ветки, несмотря на производимый в результате бардак.
А что не так с ней? Пользуюсь Motorola Droid 4 с кнопкой сверху, случайные нажатия довольно редки (хотя случайные нажатия на кнопки громкости, расположенные сбоку, всё же происходят реже).
Основная причина таких нажатий: поясное крепление. Точнее, процедура извлечения телефона сдвигом вдоль длинной стороны телефона, разумеется, производящаяся путём нажатия на один из торцов телефона. Кнопка находится на этом торце из‐за того, что в противном случае после извлечения телефон придётся переворачивать. Случайные нажатия в таком случае не мешают, так как после доставания телефона я в любом случае хочу его разблокировать.
Python вообще удивителен в этом плане: возможностей для создания хаков гораздо больше, чем в любом другом известном мне языке, а отношение к ним более терпимое. Конечно, такие трюки — последнее, что вам следует использовать, но в примере выше между «ставьте пропатченую версию IPython», «мы не поддерживаем версии ≤0.11» и «у нас есть хак для IPython <0.11» я уверенно буду выбирать последнее (пока разработчики Gentoo не объявят что‐то из >¹0.11 стабильной версией). Соответственно и не буду давать забывать о таких возможностях другим: иногда они очень полезны.
¹ Знаки ≤, < (без =) и > (тоже без =) не случайны: сама 0.11 является переходной версией и потому не поддерживается.
Можно. В Python со всем, что написано на Python, можно делать что угодно, зачастую даже не изменяя байт‐код. Я как‐то обходил попытку IPython (до версии 0.11, после они такой фигнёй не страдали) запретить использовать юникод в rewrite prompt (это стрелочка вида ---->, показываемая если вы включили автовызов функций и набрали в строке, к примеру str: без скобок) с помощью своего класса со своими методами __str__ и __add__.
С помощью аналогичных хаков легко меняется и результат практически всех функций: утиная типизация и возможность переопределения операторов делают своё дело.
Кстати, что именно значит «поменять результат возвращаемой функции» и «одна функция, возвращающая разные значения»? Я так понял, что имеется ввиду возможность заставить функцию выдать результат, неожиданный для её автора, противоречащий тому, что функция должна делать. Ничего невозможного тут нет.
Декоратор, хоть и выглядит частью определения функции, ею не является и отменить его можно. В Python вообще можно сделать практически всё, что никогда не придёт в голову разработчику на более строгом языке. Это не нужно учитывать, если вы пишете библиотеку декораторов, но это нужно помнить, столкнувшись с недостатками чужого кода. А также делая заявления о невозможности чего‐либо. Если в C вы легко натолкнётесь на очередной системе на пользователя с hardened ядром и запретом изменять исполняемый код в памяти без специального разрешения, таким образом обосновав невозможность залезть в чужую функцию, то в Python такого нет и написать хак можно всегда, пока не задействованы C расширения.
Это опять же следует из определения. Раз декоратор является частью объявления функции, вы его не можете отменить. Точно так же как вы не можете например сделать так, чтобы одна функция возвращала разные значения. Но вы опять же можете обернут любым количеством разных функция.
Не совсем. Я здесь где‐то видел пример вытягивания оригинальной функции из пачки вложенных декораторов с помощью какого‐то хака. И хак, насколько я помню, предполагал, что все декораторы реализованы на замыканиях. А ведь есть ещё встроенные функции (написанные на C) и классы в качестве декораторов. Так что так лучше не делать.
Но есть причины, по которым оригинальную функцию доставать может быть нужно. Например, мне в powerline, понадобились для документации и автоматической проверки настроек значения по‐умолчанию оригинальной функции и названия аргументов. Пришлось сочинять свой аналог functools.wraps, который применяет сам functools.wraps, после чего сохраняет оригинальную функцию как значение атрибута powerline_origin и своё расширение для Sphinx, которое умеет с этим делом работать. Впрочем, ни первое, ни последнее практически не представляет проблемы: вместо велосипедостроения в последнем случае я просто использую своего наследника одного из классов autodoc и вызываю его же функцию setup. Желания найти статью и взять оттуда хак у меня не возникло.
Обычно в таких ситуациях надо давать по лбу тем, кто, нажав вниз, входит в лифт, собирающийся наверх. Во всяком случае, у нас так: лифт не будет останавливаться, чтобы подобрать пассажиров, которые хотят поехать не в ту сторону, но будет, чтобы высадить пассажиров. Во время высадки народ снаружи и заходит. Лифт потом всё равно ещё раз остановится, поскольку вызов никто не отменял.
У вас здесь ошибка: vim-powerline — это тот, у которого URL репозитория заканчивается на vim-powerline, и который написан на чистом VimL (и который сейчас deprecated). Powerline (без vim-) — написан на Python, репозиторий там, где вы указали, основная цель — одна программа для tmux, bash, zsh, vim и т.д.: всюду, где хочется его видеть. Поэтому никакой приставки vim- в названии нет и не может быть.
Насколько я понимаю, «отпуск по уходу за ребёнком» не совсем правильно называть декретным (потому что последний — «отпуск по беременности и родам» — мужчинам недоступен), но людям, как всегда, лениво писать такие длинные названия.
У sublime есть Vim-mode, vintage mode или что‐то в этом роде. У самого Vim есть большое количество проблем, связанных с исторически допущенными архитектурными просчётами либо же являющихся данью обратной совместимости (а то и тем, и другим сразу). Насколько я знаю в sublime можно запихать фактически что угодно, что поддерживает Vim, причём написать всё на Python, в Vim добавление части возможностей того же sublime (к примеру, поддержка
<C-S-Key>или<C-Key>для не‐ASCII и некоторых ASCII символов) требует неплохого знания C, а то и вдобавок желания провести refactoring.У вас другой пример, я ответа на него не знаю. Точнее знаю, но это те же две команды¹, что и с mercurial (вариантов несколько, но все требуют как минимум две команды). В моём (A-{B-C,D-E} → A-B-C-E-D) — это та же команда (
git rebase master, предполагая, что E — текущая ветка, а C — master), к которой просто добавили --interactive. Останавливаться именно на таком варианте (не прося изменить ветку, на которую происходит перенос той же командой) обычно имеет смысл, так как у меня чаще всего A-B-C — публичная master и менять её категорически не рекомендуется, а D-E, которую хочется превратить в E-D — feature branch. Соответственно, превращать A-B-C в A-B-D-E-C не нужно или даже невозможно (не примет upstream).¹ Две команды:
В данном контекстеhg rebase --source D --dest B && hg rebase --source C --dest E(можно использовать намного меньше символов, но так понятнее)hg rebase --base E --dest C && hg histedit -r B--source Dи--base E(а также--rev D..E) эквивалентны. Git использует только--base(за исключением формыgit rebase --onto master topicA topicB, эквивалентнойhg rebase --rev 'topicA..topicB - topicA' --dest master).Кроме того, сравнивать скорости до возникновения привычки бесполезно. Но после её возникновения скорость ограничивается в первую очередь физически. Мышь+клавиатура может быть быстрее стрелочек, если изменений очень много. Она не может быть быстрее Vim при знании способов перемещения в любом случае и не может быть быстрее стрелочек при достаточно малом числе изменений (если их где‐то десяток и меньше). Впрочем, я всё равно не считаю стрелочки удобнее мыши и не считаю мышь удобнее навигации в Vim. Мышь также будет быстрее, если рука уже лежит на ней.
Понятно. У меня просто другой порядок действий: сначала смотрю, куда перемещать, потом уже выполняю перемещение. Соответственно к моменту удаления решение уже принято. Как‐то не подумал, что может быть иначе: зачем удалять строчку, если неизвестно надо ли удалять её вообще (может, проще переместить другую)? Да и в части случаев (именно в это время мною обычно используется fixup) я знаю, что с чем буду объединять ещё до фиксации изменения (ещё плюс git: наличие autosquash).
Можно было их дополнить (тем же autosquash). Или обсудить необходимость возможности histedit также делать rebase (я считаю это удобным, так как не придётся решать конфликты по два раза (из‐за rebase и из‐за изменения порядка; конфликты разные) в худшем случае, но аргументы против я тоже могу представить).
Относительно мыши: если вы использовали
git rebase -iиз командной строки то рука вероятно не находилась на мыши. В этом случае, даже стрелочки +<Home>/<End>будут быстрее, чем заново искать основную позицию для правой руки (programming dvorak) после использования мыши: в отличие от позиций клавиш дополнительных блоков клавиатуры месторасположение мыши не фиксировано относительно основного блока. С us правда e[dit], f[old] и d[rop] на левой руке, только m[ess] (и p[ick]) нет, с git вообще все действия на ней (кроме p[ick], но последнее уже написано в обоих случаях), но перемещение руки на мышь всё равно остаётся более дорогим действием, чем перемещение на дополнительный блок, а<S-Home>/<S-End>— более быстрым, чем выделять мышью (если только не поддерживается тройное нажатие).Постановка в начале не сложнее, потому что можно использовать клавишу
<Home>.И ещё, я категорически не понимаю, как использование редактора описанным вами способом сочетается с возможностью случайного удаления строки. Разве что разбирательства с перемещением курсора для последующей вставки отвлекают от самой задачи перемещения строки в нужное место настолько и занимают такое время, что за это время можно успеть получить сигнал (электронное письмо, кто‐то подошёл и т.д.), отвлечься на него и забыть про производимую операцию вообще. Я никогда не удалял случайно строчки именно по этой причине: dd или любое другое сочетание со схожим действием нажать ненамеренно проблематично, а за время перемещения строки в другое место я просто не успеваю отвлечься, чтобы потерять её.
Кстати, во многих программах выделение всей строки можно произвести тройным кликом.
Ничего. Ваш изначальный комментарий, ваш ответ и мой ответ на ваш ответ (считать те два мои комментария одним, я просто не успел отредактировать) были гораздо шире и касались более важных вещей. Но на следующем ответе вы уже коснулись только быстроты предпринимаемых действий и я просто продолжил доказательство тезиса, сомнение в котором было вами высказано. В данном случае — что удаление строки быстрее в любом редакторе.
Вообще по‐хорошему можно сократить все действия до одной клавиши: что в Vim, что во многих других редакторах, поддерживающих расширения. Но это экономит не настолько много времени, чтобы усиливать зависимость от наличия этих самых расширений.
Относительно лёгкости:
В nano (ещё один относительно стандартный консольный редактор, но без поддержки режимов) с этим делом примерно так же (одно
<C-k>для удаления против многоклавиш (вероятно, легче всего<C-d><C-d><C-d><C-d>d) для замены).В mcedit удаление одной строки на
<C-y>, замена потребует больше клавиш (вероятно, наиболее простыми является либо<INS>drop, либо то же, что и у nano).В gedit (GUI!) есть сочетание
<C-d>для удаления всей строки. Для замены на drop вероятно легче всего использовать<C-S-Right>d.В sublime (GUI!) судя по этой статье есть
<C-k><C-k>для удаления до конца строки (т.е. курсор должен быть в начале) и<C-DEL>dдля замены первого слова на d (замечу, что клавиша DEL несколько дальше k и потому первое набирается значительно быстрее).В kate (GUI!) можно «удалить» строчку
<C-d>(на самом деле осуществляет комментирование, если судить по этой PDF’ке). Считается, что kate знает, что такое «комментарий» в файле от git rebase. Если нет то, см. следующий абзац.В любом редакторе можно «удалить» строчку путём написания одного символа
#: git воспринимает такие строчки как удалённые.Во всех примерах предполагается нахождение курсора в начале строки. Во многих примерах расположение курсора абсолютно не важно для удаления строки (верно если не указано обратное). Во всех примерах расположение курсора важно для замены слова.
Так что либо я не понимаю как в GUI редакторах быстро заменить одно слово на другое, либо ни о каком «по сути одинаково» речи быть не может. Замечу, что перемещение кисти куда‐либо с основной позиции слепой печати — операция заведомо более дорогая, чем нажатие дополнительных одной‐двух‐трёх (зависит от вашей скорости печати) клавиш, особенно если они расположены под разными руками.
dd(в любой части строки) vsRdrop^[илиcwd^[(но только в начале строки, то есть прибавляется ещё и команда на переход в начало строки) (вместо^[подставить ESC). Согласитесь, первое гораздо быстрее остального.Да.
Use-case для exec я тоже не знаю, но зачем‐то же он есть в git. То, что я могу представить проще и безопаснее делать без exec.
Я имею ввиду, что
A-{B-C,D-E}можно превратить однойgit rebase -iвA-B-C-E-D, тогда как с mercurial вам придётся сначала делатьA-B-C-D-E(илиA-{B-C,E-D}), а потом уже толькоA-B-C-E-D: histedit не делает rebase.Одну вещь всё же хорошо придумали: названия всех действий занимают ровно четыре (или один) символа, так что можно использовать режим замены в редакторе.
Кроме того, непонятно зачем, но evolve также не разрешает изменять коммиты, отмеченные как «публичные». Учитывая, что история реально никуда не девается и есть способ автоматического исправления проблем, это странно.
¹ Evolve: A robust alternative to MQ
Основная причина таких нажатий: поясное крепление. Точнее, процедура извлечения телефона сдвигом вдоль длинной стороны телефона, разумеется, производящаяся путём нажатия на один из торцов телефона. Кнопка находится на этом торце из‐за того, что в противном случае после извлечения телефон придётся переворачивать. Случайные нажатия в таком случае не мешают, так как после доставания телефона я в любом случае хочу его разблокировать.
Кстати, Google отлично ищет его по картинке, выдавая «Скорее всего, на картинке аниме акселератор».
¹ Знаки ≤, < (без =) и > (тоже без =) не случайны: сама 0.11 является переходной версией и потому не поддерживается.
---->, показываемая если вы включили автовызов функций и набрали в строке, к примеруstr: без скобок) с помощью своего класса со своими методами__str__и__add__.С помощью аналогичных хаков легко меняется и результат практически всех функций: утиная типизация и возможность переопределения операторов делают своё дело.
Кстати, что именно значит «поменять результат возвращаемой функции» и «одна функция, возвращающая разные значения»? Я так понял, что имеется ввиду возможность заставить функцию выдать результат, неожиданный для её автора, противоречащий тому, что функция должна делать. Ничего невозможного тут нет.
Декоратор, хоть и выглядит частью определения функции, ею не является и отменить его можно. В Python вообще можно сделать практически всё, что никогда не придёт в голову разработчику на более строгом языке. Это не нужно учитывать, если вы пишете библиотеку декораторов, но это нужно помнить, столкнувшись с недостатками чужого кода. А также делая заявления о невозможности чего‐либо. Если в C вы легко натолкнётесь на очередной системе на пользователя с hardened ядром и запретом изменять исполняемый код в памяти без специального разрешения, таким образом обосновав невозможность залезть в чужую функцию, то в Python такого нет и написать хак можно всегда, пока не задействованы C расширения.
Но есть причины, по которым оригинальную функцию доставать может быть нужно. Например, мне в powerline, понадобились для документации и автоматической проверки настроек значения по‐умолчанию оригинальной функции и названия аргументов. Пришлось сочинять свой аналог
functools.wraps, который применяет самfunctools.wraps, после чего сохраняет оригинальную функцию как значение атрибутаpowerline_originи своё расширение для Sphinx, которое умеет с этим делом работать. Впрочем, ни первое, ни последнее практически не представляет проблемы: вместо велосипедостроения в последнем случае я просто использую своего наследника одного из классов autodoc и вызываю его же функцию setup. Желания найти статью и взять оттуда хак у меня не возникло.