>>> "%d | %d" % (12.54,-12.54)
'12 | -12'
>>> "%s | %s" % (12.54,-12.54)
'12.54 | -12.54'
name = "NAME"
input_path = "INPUT_PATH"
print('"{name}" - ERROR! File "{name}" not found in "{input_path}"'.format(name=name, input_path=input_path))
print(f'"{name}" - ERROR! File "{name}" not found in "{input_path}"')
sprite = pygame.sprite.Group()
temp = []
sprite.add(temp.append(arr))
$('.submit').on("click", function() {
var form = $(this).closest('form');
...
....
in certain cases, Selenium tries to wait "automatically" for you when it thinks the page is loading. It even provides a method called `implicitly_wait" that lets you control how long it will wait if you ask it for an element that doesn’t seem to be on the page yet.
....
The problem is that implicit waits are always a little flakey, and with the release of Selenium 3, implicit waits became even more unreliable. At the same time, the general opinion from the Selenium team was that implicit waits were just a bad idea, and to be avoided.
Вот только с твоим решением надо ХОРОШО подумать, чтобы обойтись без всякой грязи в коде, потому что тебе 99% придется пилить костыли, так как тут как минимум две проблемы - связать choices которые существуют только на бумаге с уже созданными в бд объектами requirements, сравнивать их, вторая проблема - это расширяемость, каждый раз в код лазить чтобы изменить необходимые requirements которые определенны кортежом choices? Полюбому же они не будут статическими, а вариант с choices, который в документации советуют определять на модели, и который точно так же в документации советуют использовать только для статических данных - не даст тебе так просто добавить или изменить требование когда твой проект уже будет крутиться на сервере.
А вот сделал бы заранее необходимые requirements и просто присваивал бы их через m2m к необходимым проектам - вообще бы проблем не было. И новый requirement добавить, неугодный удалить, и форму отрендерить с disabled, и все было бы просто - это если я правильно понял твою идею из ее куцего описания.