А в каком виде оно в функцию передается?

и что за функция? орм какой-нибудь?

Нет. POST в роут, дальше вручную. ОРМ не юзаю.

так функцию покажи

или ты в скуль так и передаешь (1,) ?

Да нет там функций каких-то. Выгребание данных с формы и их обработка. Вытащил кортеж - и в sql запрос в стиле select ... where in {0}.format(users)

И, ессно, что select... where in (1,) не работает.

ну а что тебе мешает это джойном сделать?

Инъекции же

а, да

Нельзя SQL делать форматом

Инъекции - то отдельный разговор.

чо за база? есть же драйвера которые подготовленные запросы делают

Для этого обычно функции в либе есть

Нельзя SQL делать форматом

для where ... in ... приходится

нету

ну psycopg2 нормально примет тупл же? нет?

нет

всё плохо

Ну тогда join

обычно люди конструируют запрос вида ... where x in (?, ?, ?, ...) - длиной в len(args) и подставляют args у этого подхода разумеется проблемы с кэшированием запроса, раз и с обработкой вырожденных случаев для len = 0 и 1

вроде отдельные DBAPI модули понимают ('... where x=?', [(args, ...)]) стиль, но это надо уточнять по каждому отдельно

Кстати, столкнулся с мелкой такой пайтоновской особенностью кортежей (1,) . Приходят данные в виде кортежа с Id пользаками. Я потом делаю выборку в стиле select ... where in . Всё бы прекрасно, но скуль загибается, если пользователь один. Блин, без костылей никак не получилось элегантно обработать этот вариант. Пришлось городить огород с if len(users)==1

и это не особенность пайтоновских кортежей

а особенность твоего применения их

Есть вот проект примерно 50k LOC, нужно определить, что тормозит систему. До этого профайлеры для питона не юзал, не было необходимости.

python -m cProfile script.py

и это не особенность пайтоновских кортежей

Не знаю. Кортеж+where in был элегантным решением, но единичный случай всё разбил в пух и прах. Пришлось костыли городить, которые меня откровенно раздражают. Но лучшего варианта не придумал

python -m cProfile script.py

А как это будет работать с приложением за uswgi?

А как это будет работать с приложением за uswgi?

не удивлюсь если там готовый ключ есть вообще вызов профайлера тогда в скрипт вписать надо или тестить под другим сервером

Не знаю. Кортеж+where in был элегантным решением, но единичный случай всё разбил в пух и прах. Пришлось костыли городить, которые меня откровенно раздражают. Но лучшего варианта не придумал

какие костыли? ",".join(("1",))

какие костыли? ",".join(("1",))

Так всё равно не подойдет

where ... in () . Без скобок не работает.

и?

встаавь в скобки?

В запрос, который уже рассчитан на кортеж?

def where_in(args, placeholder='?'): return '({})'.format(', '.join(*[placeholder]*len(args))) ...execute('select * from table where key in {}'.format(where_in(args)), [args])

для :name параметров придётся допиливать нумерацию через enumerate

какие костыли? ",".join(("1",))

Кстати, а как тут join получает на выводе 1?

def where_in(args, placeholder='?'): return '({})'.format(', '.join(*[placeholder]*len(args))) ...execute('select * from table where key in {}'.format(where_in(args)), [args])

Спасибо. Завтра посмотрю

потому что один элемент же

джойн вставляет строки между элементами, но если список из одного или нуля - вставлять некуда

Да, действительно. Не знал

И да, я еще REGEXP в скуль воткнул. В итоге получается запросец в виде `select ... where id in .. or name REGEXP ...``. Полистал на Стеке. Вроде юзать можно, но осторожно

Кстати, интересный вопросец: like быстрее регекспа или нет? Чисто академический интерес

это и есть регэксп

только попроще 8)

Но я так понимаю, за индексы можно забыть

почему?

like точно их не юзает

субд какая?

mysql

а, греп

http://dev.mysql.com/doc/refman/5.7/en/index-btree-hash.html

"The index also can be used for LIKE comparisons if the argument to LIKE is a constant string that does not start with a wildcard character. For example, the following SELECT statements use indexes:" часть

в пг можно вроде регэксповые индексы клепать

Стопе, это 5.7. Раньше такая тема была?

была

В пг, говорят, можно индекс по выражению делать

если у лайка есть константный префикс, то индекс может урезать диапазон поиска

можно

https://www.postgresql.org/docs/9.1/static/sql-createindex.html вон примеры внизу

Век живи век учись

SELECT * FROM tbl_name WHERE key_col LIKE other_col;

In the second statement, the LIKE value is not a constant.

Ч0т не вьехал

тебе ясным английским пишут

Это не константа, хорошо. Но почему она проигрывает `a%``

ERROR: S client not available

?

а если подумать?

Если подумать

Зарт, стоп

Дай подумаю

col1 like col2 - тебе надо обойти всю сраную таблицу и дергать из КАЖДОЙ строки и кол1 и кол2

когда же у тебя 'a%', ты заведомо знаешь что все ключи меньше 'b...'

значит можно б-трии хэшем откинуть сразу ~1/50

class Buffer: def __init__(self): self.in_lst = [] self.count = 0 def add(self, *a): self.a = list(a) for i in a: if len(self.in_lst) < 5: self.in_lst.append(i) self.count += i if len(self.in_lst) == 5: print(self.count) self.in_lst = [] self.count = 0 def get_current_part(self): print(self.in_lst)

Вам дается последовательность целых чисел и вам нужно ее обработать и вывести на экран сумму первой пятерки чисел из этой последовательности, затем сумму второй пятерки, и т. д. Но последовательность не дается вам сразу целиком. С течением времени к вам поступают её последовательные части. Например, сначала первые три элемента, потом следующие шесть, потом следующие два и т. д. Реализуйте класс Buffer, который будет накапливать в себе элементы последовательности и выводить сумму пятерок последовательных элементов по мере их накопления. Одним из требований к классу является то, что он не должен хранить в себе больше элементов, чем ему действительно необходимо, т. е. он не должен хранить элементы, которые уже вошли в пятерку, для которой была выведена сумма.

buf = Buffer() buf.add(1, 2, 3) buf.get_current_part() # вернуть [1, 2, 3] buf.add(4, 5, 6) # print(15) – вывод суммы первой пятерки элементов buf.get_current_part() # вернуть [6] buf.add(7, 8, 9, 10) # print(40) – вывод суммы второй пятерки элементов buf.get_current_part() # вернуть [] buf.add(1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) # print(5), print(5) – вывод сумм третьей и четвертой пятерки buf.get_current_part() # вернуть [1]

все выполняется как выше, но где-то ошибка?

точнее степик не принимает ответ, загуглил решения - сделано у некоторых через while, но сути не меняет, одно и тоже...

В чем ошибка-то?

кто бы знал Failed test #1. Wrong answer

Сам тест дается?

на степике не даются тесты

вот это и бесит, авторы придерживаются мнения, что ученики сами должны догадаться, лол

хреновая реализация буфера

а задачка вполне реальная, такие буфера часто попадаются то тут, то там

вроде все обрабатывается, можно и через срезы это сделать, а не через переменную count, но сути не меняет

count не нужен

ну, ок, переделал на срез, все тоже самое

кто бы знал Failed test #1. Wrong answer

полный вывод дай

полный вывод дай

это и есть полный

они там обычно приводят входные данные как минимум

когда-то да, когда-то нет

self.a у тебя бесполезное

хм... count у тебя на самом деле summ

вообще алгоритм хотя и глубоко неоптимальный, но выглядит правильно

ну да, сейчас переделал на sum(self.in_lst[:5]) и потом его обнуляю, все равно тоже самое

ну да, сейчас переделал на sum(self.in_lst[:5]) и потом его обнуляю, все равно тоже самое

А зачем ты числа вообще сохраняешь?