операция slice в питоне копирует подстроку

http://svn.python.org

svn

Как ты думаешь, какого года эти сырцы? Хинт: много лет назад они перешли на hg и год назад на git.

По поводу строк, уверен, вопрос раскрыт в гугле. Что касается memoryview то он у меня работал заметно медленнее обычных строк (раза в два что-ли, померяй). Единственное, он память экономит.

Разве что проще освобождать память от отдельных подстрок?

В инете периодически пролетают всякие «продвинутые» структуры данных на питоне, в том числе на тему строк. Но я бы сначала убедился что это поможет. Питон в принципе небыстрый ЯП и не всегда низкоуровневые операции приносят общий прирост производительности.

Как ты думаешь, какого года эти сырцы?

тут то же самое: https://hg.python.org/cpython/file/v2.7.11/Objects/stringobject.c

Питон в принципе небыстрый ЯП и не всегда низкоуровневые операции приносят общий прирост производительности

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

По поводу строк, уверен, вопрос раскрыт в гугле.

Подкинь пару ссылочек плз? Гуглеж по «alternative python string library», "[re]implementation", «fast slice» ничего не дал.

Видимо, все довольны тем, что есть.

Мне бы память сэкономить хоть

Тогда memoryview.

На счёт альтернативных реализаций, я, возможно, немного погорячился. Но в плане хранения данных есть просто куча несколько разных фреймворков со своей реализацией массивов (тебе именно строки нужны или bytes?). Навскидку: pandas, numpy и вообще любой приличный научный фреймворк.

А ты почитай тут:

https://hg.python.org/cpython/file/3.5/Objects/unicodeobject.c

и тут:

https://hg.python.org/cpython/file/3.5/Objects/sliceobject.c

я там ни фига не понимаю, правда, но кажется, что всё уже оптимизировано. Можно тесты погонять.

Нифига себе. Всю жизнь был уверен, что там легковесные слайсы, а тут такое.

memoryview

Вроде бы прекрасен, но придется велосипедить всякие find() итп. Хотя так и так придется, так что все равно свою обертку писать

тебе именно строки нужны или bytes?

Таки наверное bytes. Скорее всего. Наверное.

Пока речь идет о bytes. С принципиальной точки зрения, что для bytes, что для unicode, проблема одна и та же.

придется велосипедить всякие find()

У него есть .tobytes(), но сколько это памяти займёт я хз :). Есть ещё модуль array, как он работает хз. Причём, в третьем питоне плюшек больше.

Но всё же я бы посмотрел numpy или pandas. Для numpy.array пишут что оно работает так как тебе нужно. И пишут что там свои грабли.

вообще-то как бэ строки в python это immutable, хочешь скорости - пиши на C

Ну так потому и должны быть легковесные слайсы, что immutable.

Кстати, да, в numpy дешёвые слайсы как раз есть. Но там не строки, а массивы же, find() там тоже нет.

Он хочет память сохранить, ему как раз и поможет немутабельность строк. Т.е. ему нужна ссылка на старый объект(если он изменился), а дальше уже нарезать лениво эти куски(класть указатель на нужную часть). Кажется тут проще будет сделать свою кастомную str.

Еще можно попробовать посмотреть как делают lazy split, но он делается через итераторы(если память не изменяет) и сделать ему find будет затратно.

для такого slice'а нужно все строковые методы переписывать, ведь он не будет null-terminated

откуда у тебя эти гигабайтные строки?.. какую задачу решаешь? 90% что делаешь что-то не то

вот что нашел, буду посмотреть:

https://sourceforge.net/projects/pyropes/

судя по дескрипшну, там быстрые слайсы, конкатенация и даже операция повторения, всё на С