Поиск подстрок в строке

Просто цикл в цикле, который по штучке берёт и ищет элементы из set-а в строке забахать, наверное, не самый красивый вариант.

Из-за таких тэгов как «visual studio» вряд ли получится по другому.

tags = {'c#', 'visual studio', 'java'}
text = 'разработка на c# в visual studio'

print(tags & set(text.split(' ')))
print({*filter(lambda x: x in text, tags)})

{'c#'}
{'visual studio', 'c#'}

Важно ещё чтобы в c# c не находило.

filter(lambda x: f' {x} ' in text, tags) или регулярка.

теряет visual studio

f' {x} ' in f' {text} ' ))

Будет пропускать c опять. Не столь тривиально, как кажется на первый взгляд.

Вот спасибо. Выручил.

Хотя странно как-то. На маленьких данных нормально работает, но на больших строках фигня получается. Возвращает просто set() vvn_black. И самое обидное, непонятно, откуда такое происходит и что виновно.

Пример бы текста и тэгов, на которых не работает.

Точка или запятая после «тега».

ааа, если там предложение и тэг в конце, тогда да - не найдётся. Текст можно предварительно «приготовить», заменить на пробелы всю пунктуацию.

Точно. Уже сам нашел.

Если у тебя текста очень много, то лучше разбить его на слова, привести всё к одному регистру, а потом пройтись по словам слева направо, проверяя, нет ли совпадения от текущего слова в словаре тегов. Если среди тегов много таких, что начинаются с одинаковых слов, можно использовать что-то вроде Ахо-Корасик, только символы будут не отдельные буквы, а целые слова.

заменить на пробелы всю пунктуацию.

работает до следующего

Салтыков-Щедрин, Михаил Евграфович

КемелКейсом записывать в таких случаях.

Ну мне 100% точность не требуется, т.к. я датасет скриптом собираю, который по определению не 100% точный, т.к. данные писали люди, в том числе и с ошибками. Запятые и точки слишком часто встречаются, чтобы их игнорировать.

Зачем ты адовый быддокод выдаёшь, когда сам знаешь, что следует юзать регулярки?

Ты думаешь, их так много, что регуляркой будет не эффективно, или что?

не эффективно

Пока устраивает O(N×M), сгодится, хоть и не эффективно. Но если станет не хватать, есть куда двигаться.

Создай FSM для каждого элемента в set и линейно иди по строке. Быстро, но по памяти будет не очень.

По хорошему, если тегов будет действительно много и будет длинные строки, по которым ты ищешь теги, то стоит использовать что-нибудь вроде алгоритма Рабина-Карпа, который позволяет за один проход по строке искать в ней несколько подстрок одновременно. Может даже есть для питона что-то готовое.

Всем спасибо. Данные уже собраны. Там всего-то пол гига текста перелопатить надо было и в скорости особой важности не было, т.к. всё упирается в скорость сайта, откуда берутся данные.