Всю жизнь пускал слюни на циферки, все игры проходил на 100% ещё во времена пиратства, когда эти циферки видел только я.
Но в этой игре поступил так же - только закрыл все квесты. Зачищать локации невероятно скучно. Вот и думаю, это я повзрослел, или игра такой получилась? Впрочем, в том же излюбленном автором ведьмаке зачистить Скеллиге меня тоже не хватило.
Житейский вопрос - как автор умудряется совмещать две работы и уделять время жене и ребёнку? И надеюсь, теперь жена уволилась и занимается тем, что ей нравится. После того, как тянула семью на себе несколько месяцев, мне кажется, заслужила.
Если это код ваш или вашей команды, и находится в рамках одного проекта/решения, то вам, вероятно, даже IDE подскажет.
Если это код закрытой библиотеки, то всё, что у вас есть - это документация. И тогда всё зависит от неё.
Ожидать одно, получить другое - в целом всё зависит от конкретной ситуации, от того, как хорошо описана функция. Не от наличия декоратора. Да и сами декораторы нужны лишь для пред- и пост-обработки. Не думаю, что кто-то будет писать их для того, чтобы сбить вас с толку.
Делегаты про передачу функции в качестве параметра. Да, можно сделать подобие вызова функции с декоратором с помощью делегатов, но это будет вызов вида Декоратор(Функция, [параметры функции]), вместо обычного Функция([параметры функции]).
Представим, что мы пишем библиотеку. Разработчик, её использующий, будет видеть только сигнатуры функций. Если мы в питоне навесим на неё декоратор, он будет использован при обычном вызове функции. А в примере с делегатом этот разработчик может не знать о декораторе и не вызвать его.
Да, можно сделать функцию 1 приватной, затем сделать публичную функцию 2, которая будет вызывать функцию 1 с декоратором, но тут возникает проблема: если у нас есть один декоратор, который мы навешиваем на несколько разных функций, то для каждой придётся писать такой дубликат.
В общем, декоратор - удобный синтаксический сахар. При желании на чём угодно можно написать что угодно, вопрос лишь в том, сколько времени это займёт. В питоне навесить декоратор - написать одно слово с @ перед функцией. В примере выше, хоть и немного, но написать нужно больше. А теперь помножим это на количество таких ситуаций, и ещё раз помножим на тот факт, что декоратор - это лишь один из примеров, а подобных сладостей в питоне много. Мне например, ещё очень нравится слайсинг. Вот из всего этого сахара и складываются меньшие затраты времени на разработку.
И, опять же, это лишь общая идея того, для чего вообще создавался питон, я не ручаюсь, что это так работает в реальности, ибо в .NET тоже хватает сахара, по сравнению с той же Java. Я её как-то попробовал, и обплевался от отсутствия даже такой банальной вещи, как Свойства классов. Но это лишь моё мнение, кому-то и без них норм, да и Легаси кому-то надо поддерживать
В том же, в чём преимущество использования питона в принципе. Он создавался как язык, на котором можно было бы разрабатывать быстро. Т.е. удобный синтаксис, много сахара, декораторы, слайсинг и т.п. А также интерпретируемость, позволяющая не ждать пересборки всего проекта при отладке, если ты изменил одну строку.
Почему в таком случае его сейчас не выбирают все подряд - программы, написанные на нём работают медленнее, чем на Java или .NET, отчасти засчёт той же интерпретируемости, поскольку компиляторы способны выдавать очень сильные оптимизации, т.к. знают обо всём твоём коде сразу.
То есть питон выгоден, если надо быстро и в сжатые сроки построить систему и отдать заказчику, но если в системе много вычислений, которые должны работать быстро, то другие языки предпочтительнее.
Btw, могу ошибаться, ибо сам являюсь .NET разработчиком, но в своё время был в восторге от питоновских декораторов, иногда их не хватает
Попробовал. Пришёл к выводу, что цель врача не зависит от экономической системы. Если он не получит больше от того, что вылечит больше/качественнее, то рано или поздно в приступе усталости он спросит себя, стоит ли вообще напрягаться?
Недавно была задача (помогал человеку с дипломом) - переписать через зад сделанную прогу с шарпа (которого, кстати, нет в статье) на питон. Прога состояла чисто из циклов и проверок if-else. При этом я умудрился убрать кучу ненужного кода и провёл все оптимизации, какие смог. Всё равно итоговое детище работало раз в 10 медленнее изначального...
Всю жизнь пускал слюни на циферки, все игры проходил на 100% ещё во времена пиратства, когда эти циферки видел только я.
Но в этой игре поступил так же - только закрыл все квесты. Зачищать локации невероятно скучно. Вот и думаю, это я повзрослел, или игра такой получилась? Впрочем, в том же излюбленном автором ведьмаке зачистить Скеллиге меня тоже не хватило.
Житейский вопрос - как автор умудряется совмещать две работы и уделять время жене и ребёнку? И надеюсь, теперь жена уволилась и занимается тем, что ей нравится. После того, как тянула семью на себе несколько месяцев, мне кажется, заслужила.
Вот здесь я вас не очень понял.
Если это код ваш или вашей команды, и находится в рамках одного проекта/решения, то вам, вероятно, даже IDE подскажет.
Если это код закрытой библиотеки, то всё, что у вас есть - это документация. И тогда всё зависит от неё.
Ожидать одно, получить другое - в целом всё зависит от конкретной ситуации, от того, как хорошо описана функция. Не от наличия декоратора. Да и сами декораторы нужны лишь для пред- и пост-обработки. Не думаю, что кто-то будет писать их для того, чтобы сбить вас с толку.
Тут лучше спросить питониста, но я предположу, что скрыто. Как и любая другая деталь реализации в целях инкапсуляции.
Так step - это самое сладкое!
Делегаты про передачу функции в качестве параметра. Да, можно сделать подобие вызова функции с декоратором с помощью делегатов, но это будет вызов вида Декоратор(Функция, [параметры функции]), вместо обычного Функция([параметры функции]).
Представим, что мы пишем библиотеку. Разработчик, её использующий, будет видеть только сигнатуры функций. Если мы в питоне навесим на неё декоратор, он будет использован при обычном вызове функции. А в примере с делегатом этот разработчик может не знать о декораторе и не вызвать его.
Да, можно сделать функцию 1 приватной, затем сделать публичную функцию 2, которая будет вызывать функцию 1 с декоратором, но тут возникает проблема: если у нас есть один декоратор, который мы навешиваем на несколько разных функций, то для каждой придётся писать такой дубликат.
В общем, декоратор - удобный синтаксический сахар. При желании на чём угодно можно написать что угодно, вопрос лишь в том, сколько времени это займёт. В питоне навесить декоратор - написать одно слово с @ перед функцией. В примере выше, хоть и немного, но написать нужно больше. А теперь помножим это на количество таких ситуаций, и ещё раз помножим на тот факт, что декоратор - это лишь один из примеров, а подобных сладостей в питоне много. Мне например, ещё очень нравится слайсинг. Вот из всего этого сахара и складываются меньшие затраты времени на разработку.
И, опять же, это лишь общая идея того, для чего вообще создавался питон, я не ручаюсь, что это так работает в реальности, ибо в .NET тоже хватает сахара, по сравнению с той же Java. Я её как-то попробовал, и обплевался от отсутствия даже такой банальной вещи, как Свойства классов. Но это лишь моё мнение, кому-то и без них норм, да и Легаси кому-то надо поддерживать
В том же, в чём преимущество использования питона в принципе. Он создавался как язык, на котором можно было бы разрабатывать быстро. Т.е. удобный синтаксис, много сахара, декораторы, слайсинг и т.п. А также интерпретируемость, позволяющая не ждать пересборки всего проекта при отладке, если ты изменил одну строку.
Почему в таком случае его сейчас не выбирают все подряд - программы, написанные на нём работают медленнее, чем на Java или .NET, отчасти засчёт той же интерпретируемости, поскольку компиляторы способны выдавать очень сильные оптимизации, т.к. знают обо всём твоём коде сразу.
То есть питон выгоден, если надо быстро и в сжатые сроки построить систему и отдать заказчику, но если в системе много вычислений, которые должны работать быстро, то другие языки предпочтительнее.
Btw, могу ошибаться, ибо сам являюсь .NET разработчиком, но в своё время был в восторге от питоновских декораторов, иногда их не хватает
Попробовал. Пришёл к выводу, что цель врача не зависит от экономической системы. Если он не получит больше от того, что вылечит больше/качественнее, то рано или поздно в приступе усталости он спросит себя, стоит ли вообще напрягаться?
Надо ли чистить код отладки, когда закончил её и убедился, что всё работает?
Про первый способ понятно, но про остальные хотелось бы получше понять, как это на производительность влияет
У него в аббревиатуре есть слово язык :)
Недавно была задача (помогал человеку с дипломом) - переписать через зад сделанную прогу с шарпа (которого, кстати, нет в статье) на питон. Прога состояла чисто из циклов и проверок if-else. При этом я умудрился убрать кучу ненужного кода и провёл все оптимизации, какие смог. Всё равно итоговое детище работало раз в 10 медленнее изначального...