lst=[5, 3, 0, 2, 0, 3, 8, 2, 9, 7, 0, 0, 7, 1, 5, 3]
L = len(lst)
# если в начале списка не 0, то мы сможем задать корректные значения только на обратном ходе
# так что ставим заведомо большее значение счетчика
counter = len(lst) if lst[0] != 0 else 0
for i in range(0, L):
if lst[i] == 0:
counter = 0
else:
counter += 1
lst[i] = counter
# обратный ход
counter = lst[-1] - 1 #чтобы не запороть последние элементы
for i in range(L-1, -1, -1):
if lst[i] == 0:
counter = 0
else:
counter += 1
lst[i] = min(counter, lst[i])
print(lst)
# [2, 1, 0, 1, 0, 1, 2, 3, 2, 1, 0, 0, 1, 2, 3, 4]lst=[5, 3, 0, 2, 0, 3, 8, 2, 9, 7, 0, 0,7,1, 5, 3]
l=[i for i,v in enumerate(lst) if v == 0]
m_l=[]
for i,ls in enumerate(lst):
m=len(lst)
for j in l:
if m>abs(i-j):
m=abs(i-j)
m_l.append(m)
print (m_l)m_l=[len(lst)]*len(lst)m_l.append(m)m_l[i]=mВ итоге получается что у JS огромное преимущество перед Python в области разработки сайтов, так как на нем можно сразу писать и бэк, и фронт.Вообще вы не правы, есть много вакансий, на которые нужны только Node.js разрабы.
В итоге проект повиснет в ожидании исполнителя.А если разраб один, то вообще всё повиснет если он уйдёт. Фулстеков на джанго не намного меньше чем фулстеков на js.
Прикрутив Bootstrap мы немного приукрасим скелет, но он все равно не будет отвечать требованиям современных динамических сайтов, типа асинхронная подгрузка комментов, вывод онлайн лайков, дизлайков. Все это может реализовать только умелый js программист.Для проектов у которых есть 2 программиста обычно это не ключевые моменты (да и не все пишут соц. сети и клоны ютубов). Есть проекты, где статических сайтов будет достаточно, а если работодатель хочет дешево заплатить за сложную работу, то он должен понимать к чему это может привести.
А Python разработчики имеют дело в основном только с бэкенд - и понятия про фронтенд у них будут на уровне dummy html, css, bootstrap.
Дальше у меня возник вопрос и ступор - мы почему то возвращаем не результат выполнения функции wrapper, а возвращаем саму функцию-объект.
def f1(): return 1
a = f1() # присваиваем результат работы функции, т.е. в a будет 1
a = f1 # присваиваем саму функцию
# тогда a - это не результат работы функции f1, а сама функция f1
# и мы можем ее запустить
print(a() ) # выведет 1, т.к. мы через a запустили f1@uppercase
def greet(): ...
# то когда мы запускаем функцию
greet()
# по факту запускается
uppercase(greet)()original_result = func() # запускает переданную ему функцию на исполнение, в нашем случае greet
return f'Большие {original_result.upper()}' # и возвращает строку с результатами исполненияИ она сама каким-то образом вызывается и выполняется, хоть мы и явно не пишем это.
uppercase(greet)()
а т.к. uppercase(greet) возвращает wrapper
то uppercase(greet)() запускает wrapper()
Допустим если генератор сжигает кучу топлива и вырабатывает 100к киловатт. Но потребителям требуется лишь половина, 50к киловатт. Остальная половина просто куда-то исчезнет, улетит куда-то?Нет, 100 кВт - это максимальная мощность. Если потребляют 50 кВт, то генератор вырабатывает 50кВт и сжигает примерно вдвое меньше топлива (не будем вдаваться в подробности про КПД).
какой-нибудь автосервис будет вовсю использовать все сварочные аппараты и для стабильной работы потребуется 150к киловатт. Что тогда будет? Просто упадет напряжение допустим с 220В до 170ВТут верно. Так и будет. Вырабатываемая мощность будет 100 кВт, потребляемая тоже 100 кВт, ток в сети увеличится, а напряжение уменьшится.
for i in range(0, len(table[0]), 1):table[0], а в вашем вместо 0 выступает переменная i, равная 0. 
Можно ли любое GUI положение сперва реализовать в консольном варианте, а потом уже привязывать к нему GUI?Едва ли. Для простых еще можно, а для сложных, как Excel?
учить на Борланд С++
нужно изучить STL, я открывал по ним статейки и закрывал их с мыслями что за архаизм
Можно ли любое GUI положение сперва реализовать в консольном варианте, а потом уже привязывать к нему GUI?Если вы правильно пишите логику, то что для консоли, что для gui вам нужно будет только сделать интерфейс, если сам gui простой, то занимает это немного времени. Некоторые вообще пишут графику поверх консольных приложений.
Все по схеме - долго думал, прицелился, но запутался в своих мыслях и прострелил себе ногу. И вот в этот раз, наконец то я подумал - а что если любое приложение даже на этапе рисования на бумажках, начинать не с рисования ГУЙев и кнопочек, а именно с консольного ввода вывода информации? А потом привязывать к интерфейсам ввода-вывода ГУЙ и продумывать окошечки-кнопочки. А ведь об этом мне надо было задумываться еще будучи в универе - когда я написал всего два полезных для себя приложения, и оба были консольные.В общем писать сразу в GUI даже приложение на 1000 строк мне кажется сомнительным. Как по мне проще в консоли функционал весь написать/проверить (с тестовыми данными), а потом просто привязать к кнопке эту функцию.
Годится ли i3-2100 для клиента 1СДля описанных задач такой процессор даже избыточен. Получится производительный и шустрый системник.
собирать новый на базе G5420, Ryzen 3 2200G или i3-9100?А они для поставленной задачи ничем не лучше. Разницы никакой.
