Очень субъективно, и распаковка и тернарный оператор — отличные инструменты, повышающие читаемость кода, если их применять к месту. В примерах выше я бы предпочел распаковку.
Еще для наглядности.
Все операции типа +, += это вызов специальных методов. x += y это x.__iadd__(y). В таком методе мы можем поменять состояние объекта и вернуть себя же (self), или же создать и вернуть новый объект.
class Immutable:
def __iadd__(self, x):
return self._value + x # ну или Immutable(self._value + x)
class Mutable:
def __iadd__(self, x):
self._value += x
return self
Для людей знакомых например с с++, но не знакомых с питон, знание о передаче аргументов по ссылке или по значению — лишь немного путают в этой ситуации )
На самом деле в питоне все есть объекты. Вот сколько например у int методов:
Здесь другая ситуация. При попытке сделать assignment для переменной, котороя ссылается на immutable объект, питон создает новый объект. Встроенный int это объект, но не изменяемый.
x = 1 # int is immutable
print(id(x))
x += 1
print(id(x))
# 94029430744832
# 94029430744864
x = (1, 2) # tuple is immutable
print(id(x))
x += (3, 4)
print(id(x))
# 140065572803008
# 140065572117216
x = [] # list is mutable
print(id(x))
x += [1, 2]
print(id(x))
# 140381673357056
# 140381673357056
В контексте данной проблемы x += y и x = x + y одно и тоже (т.е. от деталей можно абстрагироваться). Если Питон видит assignment для переменной, то она автоматом помещается внутрь локального scope, если не указан nonlocal или global.
Понятие hoisting немного смежное, но к питону это не имеет отношения. При загрузке модуля (скрипта), пока мы не дойдем до объявления класса/функции (и не выполним этот код!) — обращаться к таким объектам нельзя. Переменные вообще невозможно объявить без инициализации.
Бывают специфические для языков штуки. Вот как оно в CS бывает.
По поводу 3-го случая объяснение в статье какое-то загадочное.
Однако попытка изменить неизменяемую переменную во второй функции y += x приводит к тому, что y начинает ссылаться на другой адрес в памяти: исходная y будет забыта, что приведёт к ошибке UnboundLocalError.
Здесь мы пытаемся использовать неинициализированную переменную. Потому как: y += x это y = y + x. Справа доступ к неинициализированной y.
trio.hazmat is Trio’s “hazardous materials” layer: it contains APIs useful for introspecting and extending Trio. If you’re writing ordinary, everyday code, then you can ignore this module completely. But sometimes you need something a bit lower level.
Автор воспринимает это как разные возможности в асинхронном подходе, которые лежат «под капотом». Он вообще рассматривает другую проблему. Пришел синтаксический сахар, который все равно не решает проблему контроля flow.
Я просто вырезал regex'ом полагая что строка в задании «URL-ом считается подстрока» однозначно просит нас вырезать любые подстроки URL, ну например для сбора статистики, или же известно что в логе URL будут отделены пробелами.
Так вот, могу ли я переделать код с учетом вышесказанного в комментах и отправить на ревью повторно?
До сих пор спорят о том что современный С++ ужасно сложен, и иногда надежнее разрабатывать на С, так как специалист который не знает полностью инструмент разработки — не может гарантировать поведение. В Google рекомендуют использовать коды возврата, вместо exceptions c++, так как это опять же позволяет лучше контролировать поток выполнения программы.
Но по-вашему ГМО — это метод, а не результат. А так не бывает. Чем сложнее инструменты, тем больше факторов влияют на результат, тем больше побочных эффектов.
Просто крутая статья. Прочитал и что-то щелкнуло «Вот оно». Последняя точка поставлена. То к чему дошел на своем опыте, теперь обрело форму нескольких лаконичных правил.
По своему опыту я всегда не мог согласиться с MVC, которые диктует тот или иной фреймворк. В первую очередь, не потому что фреймворк плох (смотри ниже второе), а потому что его пользователи, мои коллеги, отталкивались в своих спорах от этого фреймворка. Поясню. У меня всегда было стойкое ощущение, что споры об MVC не от того правильно или неправильно кто-то использует конкретный фреймворк. А от непонимания, что данный конкретный фреймворк разработан со своим видением MVC. Да, все банально, но часто происходит так: Что такое MVC? А вот он в этом фреймворке. И далее гадание на кофейной гуще и ориентация на мнение авторитетов или собственные эксперименты. Т.е. нужно разделять: «Ты работаешь не так как принято с этим фреймворком» и «Ты не понимаешь принципы MVC».
Второе, а так ли я готов согласиться с моделью конкретного фреймворка, нужно обсуждать только после того как понял и принял первое. И уже здесь приходит понимание, что нужны четкие формализованные правила, с помощью которых можно рассмотреть все основные реализации MVC на предмет «удобно или не удобно» работать. И в статье сразу же бросается в глаза:
Модель с точки зрения реализации — это интерфейс к бизнес логике. Просто в точку.
Разделение на контроллер лежит на следующей уровне иерархии после разделение на «Модель предметной области» и «Взаимодействие с пользователем».
Все операции типа +, += это вызов специальных методов. x += y это x.__iadd__(y). В таком методе мы можем поменять состояние объекта и вернуть себя же (self), или же создать и вернуть новый объект.
На самом деле в питоне все есть объекты. Вот сколько например у int методов:
И все передается по ссылке, ниже id выводит адрес объекта в памяти:
Здесь другая ситуация. При попытке сделать assignment для переменной, котороя ссылается на immutable объект, питон создает новый объект. Встроенный int это объект, но не изменяемый.
Понятие hoisting немного смежное, но к питону это не имеет отношения. При загрузке модуля (скрипта), пока мы не дойдем до объявления класса/функции (и не выполним этот код!) — обращаться к таким объектам нельзя. Переменные вообще невозможно объявить без инициализации.
Бывают специфические для языков штуки. Вот как оно в CS бывает.
3) github.com/satwikkansal/wtfpython#-the-out-of-scope-variable
Здесь мы пытаемся использовать неинициализированную переменную. Потому как: y += x это y = y + x. Справа доступ к неинициализированной y.
trio.readthedocs.io/en/stable/reference-hazmat.html
Так вот, могу ли я переделать код с учетом вышесказанного в комментах и отправить на ревью повторно?
- Тут есть некий подвох и нужно сообразить самому?
- Это нужно понимать буквально (только для пути "/" и/или 4 раза)?
- Или это пример для всех путей и в любых количествах? Т.е. любой путь считается отличным от другого если они одинаковы, но разные домены?
«упоминания» где? В общей статистике или а топе? Или и там и там?Но по-вашему ГМО — это метод, а не результат. А так не бывает. Чем сложнее инструменты, тем больше факторов влияют на результат, тем больше побочных эффектов.
По своему опыту я всегда не мог согласиться с MVC, которые диктует тот или иной фреймворк. В первую очередь, не потому что фреймворк плох (смотри ниже второе), а потому что его пользователи, мои коллеги, отталкивались в своих спорах от этого фреймворка. Поясню. У меня всегда было стойкое ощущение, что споры об MVC не от того правильно или неправильно кто-то использует конкретный фреймворк. А от непонимания, что данный конкретный фреймворк разработан со своим видением MVC. Да, все банально, но часто происходит так: Что такое MVC? А вот он в этом фреймворке. И далее гадание на кофейной гуще и ориентация на мнение авторитетов или собственные эксперименты. Т.е. нужно разделять: «Ты работаешь не так как принято с этим фреймворком» и «Ты не понимаешь принципы MVC».
Второе, а так ли я готов согласиться с моделью конкретного фреймворка, нужно обсуждать только после того как понял и принял первое. И уже здесь приходит понимание, что нужны четкие формализованные правила, с помощью которых можно рассмотреть все основные реализации MVC на предмет «удобно или не удобно» работать. И в статье сразу же бросается в глаза: