Чтоб перейти к следующему циклу сразу

Чисто псевдокод, идея такая прост

Эм

Непонятно было как лениво это все организовать

херь какая-то

А зачем лениво?:

Непонятно было как лениво это все организовать

зачем тут ленивость?

Хороший вопрос, я думал это может помочь решить проблему таким образом

А где проблема?

Вероятно, для моей проблемы будет достаточно найти самый длинный массив, range(len(arr)), 4 элемента добавлять в test_obj, потом obj['tests'].append(test_obj), если какой то элемент пустой - не добавлять его в test_obj

Может таки скажете, в чем заключается проблема?

У нас есть 3 словаря с результатами тестов, 1 словарь - логи, 2 словарь - другие логи, 3 словарь - проверка тестов В каждом словаре есть ключи, в первом - name, во втором - status test, в третьем - excepted results и actual results Мы должны сделать 4 словарь, по ключу tests у нас есть массив с тестами

В массиве каждый элемент это 4 параметра, которые я написал в сообщение выше

Словарь с логами например как организован? id_test: {status: str}?

в смысле словаря?

может быть у тебя списки словарей?

{ "logs": [ { "time": "946684810", "test": "Test output A", "output": "fail" } ] }

{ "suites": [ { "name": "suite1", "tests": 1, "cases": [ { "name": "Test output B", "errors": 0, "time": "Saturday, 01-Jan-00 00:00:20 UTC" } ] } ] }

{ "captures": [ { "expected": "B" "actual": "B", "time": "2000-01-01T00:00:20+00:00" }, { "expected": "A" "actual": "B", "time": "2000-01-01T00:00:10+00:00" } ] }

вот три словаря

нужно объеденить их в четвертый fourth_dict = {'tests': [ ]}

zip(a[“logs”], b[“suits”], c[“captures”])

дальше собирай итоговый словарь и пиши в список или делай yield

почему хотел по одному собирать этот словарь, вдруг значение невалидное, тогда пишем пустую строку в параметр

ну так и собирай, zip ленивый

for i in range(length_test_class_1): test_obj = {} test_obj['name_test'] = test_class_2.suites[i]['name'] test_obj['status_test'] = test_class_1.logs[i]['output'] test_obj['excepted'] = test_class_3.captures[i]['expected'] test_obj['actual'] = test_class_3.captures[i]['actual'] data.test_5['tests'].append({data.prefix + str(i): test_obj}) вот у меня пока такое получилось) но это ужос

а как мне с зипом считать i? у меня же там массив объектов

test_obj['name_test'] = test_class_2.suites[0]['name'] test_obj['name_test'] = test_class_2.suites[1]['name'] итд

for log, suite, capture in zip(a[“logs”], b[“suites”], c[“captures”]): test_obj = {} test_obj[‘name_test’] = suite[‘name’] …

нинада рейндж по длине

надо enumerate

не надо enumerate, у него N списков.

TypeError: list indices must be integers or slices, not str

how to fix?

TypeError: list indices must be integers or slices, not str

код покажи

Ну ёпта, в гуголь переводчик

class Attributes1: def __init__(self, json_dict: dict): for k, v in json_dict.items(): if isinstance(v, dict): value = Attributes1(v) else: k = f'{k}_' if iskeyword(k) else k value = v self.__dict__[k] = value def __repr__(self): return self.logs

допустим как логи показываем

for i, suite, log, capture in enumerate(zip(test_class_2.suites, test_class_1.logs, test_class_3.captures): data.test_5['tests'].append({data.prefix+str(i): {'name_test': suite['name'], 'status_test': log['output'], 'excepted': capture['expected'], 'actual': capture['actual']}})

через точку

создаем объект

a.logs => показывает по ключу logs

так ладно, я спать. у нас тут уже классы пошли на кой-то хрен. но трейсбеки мы читать не умеем.

ок, спасибо за помощ

нужно объеденить их в четвертый fourth_dict = {'tests': [ ]}

Просто циклом от i до n пройтись по 3 спискам и сделать tests.append({logs, expected, actual, name})?

for i in range(length_test_class_1): test_obj = {} test_obj['name_test'] = test_class_2.suites[i]['name'] test_obj['status_test'] = test_class_1.logs[i]['output'] test_obj['excepted'] = test_class_3.captures[i]['expected'] test_obj['actual'] = test_class_3.captures[i]['actual'] data.test_5['tests'].append({data.prefix + str(i): test_obj}) вот у меня пока такое получилось) но это ужос

this

Просто циклом от i до n пройтись по 3 спискам и сделать tests.append({logs, expected, actual, name})?

ну вот я походу к этому и пришел обратно

for i, suite, log, capture in enumerate(zip(test_class_2.suites, test_class_1.logs, test_class_3.captures): data.test_5['tests'].append({data.prefix+str(i): {'name_test': suite['name'], 'status_test': log['output'], 'excepted': capture['expected'], 'actual': capture['actual']}})

не работает ValueError: not enough values to unpack (expected 4, got 2)

for i, (suite, log, capture) in ....

@toooobeedo ^

воу

а это круто) спасибо

Привет чат всем

Привет чат всем

правила. ты их читал?

Есть питон, есть вим, не работают вместе, шо делать, какие подводные?

в смысле не работают и в смысле вместе?

Интеграция питона в вим через джедай

Интеграция питона в вим через джедай

я вообше хз, но в любом случае лучше подробнее описать проблему. Что именно не работает, что пробовал, что смотрел

я вообше хз, но в любом случае лучше подробнее описать проблему. Что именно не работает, что пробовал, что смотрел

Есть питон 3.7.3 64х, есть вим 8.1.чтотодальше 64х, хотел внедрить нормальную проверку и дополнение кода, почитал что хорош jedi-vim, выполнил его установку и вим начал обильно ругаться на невозможность инициализации питона, +python штуки в виме есть, Команда echo has(python) даёт 0,

@Kdanylov прошу прощения за, возможно, тупой вопрос, но в тесте asyncio количество загруженных ядер для асинка и тредов было равным? Я перед сном в чат заглянул, меня что-то клинит на том, что асинк в один поток работает.

@Kdanylov прошу прощения за, возможно, тупой вопрос, но в тесте asyncio количество загруженных ядер для асинка и тредов было равным? Я перед сном в чат заглянул, меня что-то клинит на том, что асинк в один поток работает.

да, все тесты запускались с привязкой к одному ядру. Генератор нагрузки пинился на другие ядра процессора. В питоне потоки тоже в один поток работают фактически. Пока один исполняет питон-байтокод - остальные стоят. Но потенциально могут исполнять узкие прослойки С-кода. Но тут нет, тест пинится на одно ядро процессора. Если не пинить на одно ядро - потоки начинают сильно проседать изза паразитных переключений. Это, в частности, проблема многих "тестов" потоки vs async в инете - народ тупо не знает что нужно пинить на одно ядро многопоточные программы на питоне

О как. А простого синхронного теста не было?

Без потоков и асинка

@nepherpitou собвственно это совершенно ожидаемый результат. asyncio выполняет просто безумное количество питон кода на каждый await сначала ты уходишь вних по славно задизайненному со всеми требуемыми паттернами стеку вызовов в недра asyncio что бы она сконтруировала тебе Future потом это future ты везешь обратно по всему своему стеку вызовов до самого loop. loop регистрирует на него калбек и проделывает вагон метаработы и всякой фигни. Однажды future исполнится, ему поставят done, вызовется callback и корутину подвинут в очередь готовых. Потом обратно через весь стек вниз прокинут результат. Выходит 400+ питоновских инструкций на каждый await. Каждая примерно по ~50 тактов CPU. или 20к+ тактов. А переключение потоков в ядре со всем скедуленгом и туда-сюда < 500 тактов. Так и живем

О как. А простого синхронного теста не было?

нет, да и нет смысла, будет совсем смешно. Но можно запустить потоковый тест на одном воркере

Тест будет полностью лимитироваться латентностью tcp стеков и сетки

Тест будет полностью лимитироваться латентностью tcp стеков и сетки

А с медлительным сервером не оценивал результаты? Когда время исполнения питонячей богодельни будет сильно меньше времени ответа сервера.

Блин, надо будет завтра поковыряться.

как удалить все папки в которых нету файла ПАРОЛИ ?

Хм... Для такого теста надо логику менять, в текущем виде асинк будет ждать каждого нового ответа, а потоки будут делать это в N раз чаще.

@nepherpitou если сервер будет тупить, или если на клиенткой стороне будет еще какая-то активность между приемом и посылкой сообщения, то просто возрастет латентность. Сообщения же не паплайнятся. Но в таком случае ты будешь мерять не совсем то. но вообще по мере роста количества соединений потокам становится все хуже и хуже, так что если сервер будет тупить и открытые соединения будут копится - потоки начнут проигрывать постепенно изза повышенного потребления ресурсов при простое. Собвественно на том ноуте где я это тестит больше 20к потоков не удавалось запустить. На текущем работает с 30k, но дальше уже не.

да, все тесты запускались с привязкой к одному ядру. Генератор нагрузки пинился на другие ядра процессора. В питоне потоки тоже в один поток работают фактически. Пока один исполняет питон-байтокод - остальные стоят. Но потенциально могут исполнять узкие прослойки С-кода. Но тут нет, тест пинится на одно ядро процессора. Если не пинить на одно ядро - потоки начинают сильно проседать изза паразитных переключений. Это, в частности, проблема многих "тестов" потоки vs async в инете - народ тупо не знает что нужно пинить на одно ядро многопоточные программы на питоне

Вот это сейчас неожиданно реально. Каждый поток на свое ядро пинил или все на одно?

Хм... Для такого теста надо логику менять, в текущем виде асинк будет ждать каждого нового ответа, а потоки будут делать это в N раз чаще.

нет, у тебя же асинков тоже много как и потоков. все параллельно

Вот это сейчас неожиданно реально. Каждый поток на свое ядро пинил или все на одно?

все на одно. иначе они бОльшую часть времени тупо за GIL воюют

нет, у тебя же асинков тоже много как и потоков. все параллельно

В десятый раз пошел с телефона а код тупить...

Они и так воюют за гил

В общем непонятно

Код теста бы

Они и так воюют за гил

код теста в той же репе. main.py

так они не воюют