Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
0
function coolSplit(str, pattern) {
var result = [];
while(1){
var m = str.match(pattern);
if(!m) {
if(str) result.push(str);
return result;
}
if(m.index) result.push(str.substr(0, m.index));
result.push(str.substr(m.index, m[0].length));
str = str.substr(m.index + m[0].length);
}
}
Из шифроскрипта. https://github.com/1024--/govnokod.ru-userscripts/commit/898e6195b9799853b08a01834ce55f8d780757f3#diff-40cd32e1559d395399816968845cb034R151
coolSplit(str, /expr/) ≡ str.split(/(expr)/) // Говнокод обучающий
Запостил: 
1024--,
(Updated )
http://govnokod.ru/18688#comment297468
Если уж на то пошло - как сматчить ^(regexp)+\+(regexp)$? Т.е. идет несколько regexp, между ними плюсы. Без re.split.
> как сматчить ^(regexp)+\+(regexp)$? Т.е. идет несколько regexp, между ними плюсы. Без re.split.
А, то есть regexp может быть фигнёй вида /<[^>]*>/ и соответствовать строке "<+>", из-за чего простой split невозможен...
В жс можно было бы
1. в цикле матчить один регексп и откусывать начало строки (как в данном ГК)
2. в цикле матчить, следя за lastIndex
3. использовать функци-анальный форич-подход с replace *:
В PHP, кажется, была функция "всё заматченное для шаблона" (по-моему, preg_match_all). Там надо было бы проверить на соответствие этому самому ^(?:(regexp)\+)+(regexp)$, а затем вызвать эту функцию с симметричным регекспом /(regexp)\+?/ - шаблон и необязательный разделитель. *
______________
* если шаблон не начинается с плюса
Нахуй.
Регексп - str1|str2|str3. Может и + содержать.
>Нахуй.
Я же упомянул про preg_match_all. В питоне мог быть и аналог.
Вышеописанный подход на питоне:
Если у шаблона нет вореций, брать или не брать плюс в начале/конце (например, r'1\+|1' или r'\++1'), такую технику можно использовать.
Тогда наверно и ограничений нет, кроме того, что в pattern не должно быть захватывающих скобок.
(Кстати, в коде из предыдущего комментария в pattern тоже не должно их быть)
Разбей мне в один заход 1+2+3 на \d+ разделенные "+", не сплитя по +, или выдай ошибку если формат не тот.
Да, формат строгий, при нарушении надо материться.
В чем прикол начинать модули для питона с py?
Да так же как в жабе все на J...
Да, цифры я для примера привел, в реальности там было
>Регексп - str1|str2|str3. Может и + содержать.
Т.е. можно искать фрагменты внутри хтмл и.т.п.
А вообще - все эти парсеры намного сильнее регулярок. Рекурсивную херню типа XML или выражений со скобочками они запросто сожрут и не подавятся.
Если он входит в возможное слово - то не разделитель. См. здесь http://govnokod.ru/18737#comment298410
>А вообще - все эти парсеры намного сильнее регулярок.
Да я понял уже. Но у меня ситуация вполне конкретная.
А вообще интересно было бы увидеть парсер конфигов на нем. Где-то я что-то похожее видел, в pyload, кажется.
Что-то типа такого нужно? http://ideone.com/RKaR6K
Ну с константами даже проще...
http://ideone.com/5E5v2p
Ну и можно делать парсеры для фрагментов, комбинировать их в бОльшие, реюзать, делать рекурсию и т.п. С регулярками такое не катит.
Юзаем регулярки для задач, для которых они не предназначены с 60х годов и гордимся этим!
Но ведь функции для всего, что мы делаем, есть!
Проверить на (A\+)+A мы можем. Одновременно проверить и заматчить A в A\+A мы можем. Почему бы одновременно не проверить и заматчить все A в (A\+)+A, не притягивая более серьёзные инструменты?
Ну или юзать унылый цикл с откусыванием по кусочку или по результатам split()/findall().
> скобки в re не умеют
Он же вроде PCRE совместимый?
Уже было в http://govnokod.ru/18737#comment298410
Говно. sum(map(len, found)) + len(found) -1 же. Или len("".join(found)) + len(found) -1. Но все равно дополнительная проверка.
Короче я решил так.
Дальше проверяем чтобы список состоял из пустых строк и +, или если строже - '' в начале и конце, остальное + (что-то в твоем коде не то)
Сам такой!
> Дальше проверяем чтобы список состоял из пустых строк и +
Если просить заматчить ещё и разделитель вместе со строкой, в предложенном мной случае /1\+|1/ и '1++1+1+' оно не съест лишний раз "1+" (что и произошло в коде выше), когда этот плюс будет разделителем.
Тогда в моём случае будет
И список всегда будет состоять только из пустых строк.
Но зачем? Он же разделитель.
>Сам такой!
Ну сам смотри.
>'' в начале и конце, остальное +
У меня такого не было тк + был внутри, так что я об этом как-то не задумывался.
> У меня такого не было
Вот ради таких случаев, когда разделитель на краю строки.
Ну и ради равномерности: ['', '', '', ''] против ['', '+', '+', '']
И ради равномерности регулярки для всей строки: ^(A\+)+$ вместо ^A(\+A)*$. С этого-то всё и началось.
Ну я представлял это как вызвать findall и в цикле проверить, что все найденные куски лежат друг за другом (разделитель бы захватывался в конце кусков). Но хуёвый вариант, да.
Откусывание по одному фрагменту проще всего смотрится из всего этого говна.
> Он же вроде PCRE совместимый?
Хер знает, если честно. Я особо не заморачивался. Сам потестил - скобка с плюсом после неё захватывает только последний кусок (матчит само собой всё - group(0) == "1+2+3+4", но захватывает только последний: group(1) == "3+"). Посмотрел на stackoverflow - народ жалуется, что захватывается только последний и предлагает юзать regex вместо re. В спеке как всегда о таких тонкостях умалчивается (питон стайл, хули). Вот и всё что мне известно по этой проблеме.
All engines return the last value captured. For instance, if you match the string A_B_C_D_ with ([A-Z]_)+, when you inspect the match, Group 1 will be D_.
Ну т.е. как в питоне. За исключением движков, которые умеют массивы в группах возвращать (например, тот самый regex, о котором я писал выше).