py.user.next
Ну, для этого подойдёт СУБД SQLite, например. И что дальше? Как тебе эта информация поможет создать редактор?
Это всё равно что ты бы спросил “скажите, как мне нарисовать кошку? прошу задать мне направление в сторону каких карандашей и красок смотреть, какой архитектуры”. Тебе говорят “ну, вот карандаш, рисуй кошку вот им как раз”. А что это даст?

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

Мне уже приходилось работать с массивами и с файлами на си-подобном языке. Но в данном случае, единственный текстовый файл, в который будет сваливаться вся информационная составляющая программы мне кажется далеко не идеальным решением. Поэтому и озаботился поиском какой-то альтернативы. Потому что с БД как раз особо работать не приходилось, а если и приходилось, то это совсем не то что мне нужно.

Повторюсь, что ищу решение сохранения информации по типу, как в программе marsnotebook - https://mars-soft.net/downloads/
То есть считаю, что данную хотелку - БД в одном можно осуществить в принципе. И вот пытаюсь понять, с чем именно нужно начать работать.

py.user.next
Значит, не справишься. Потому что программы сложно писать. При этом если ничего не знаешь, то оно само не будет получаться. Программирование - это не волшебная палочка.

Alex_289 не слушайте его, пишите, пускай кроме вас оно никому не нужно, в процессе узнаете много чего новго и интересного, что может вам пригодиться в будущем.
PS посмотрите на cherrytree, https://www.giuspen.com/cherrytree/ наверно не совсем то что вам нужно но может подойдет.. она опенсорс, тоесть можно, как минимум, подсмотреть как там у них все организовано.

py.user.next
Это всё равно что ты бы спросил “скажите, как мне нарисовать кошку?

сову же

Alex_289
смотрю пока в сторону PyQt5 из-за наглядности. У wxPython есть какие-либо особые преимущества?

практически никаких, кроме того что Qt это комбайн, там и медиа, и потоки, и сигналы и черт лысый, а Wх чисто ГУИ.
ну и подход: Qt - на всех платформах единый интерфейс. Wх - на каждой платформе нативнsй нтерфейс.

Alex_289
вот уже более десяти лет пользуюсь программой marsnotebook

я тоже в свое время в его сторону смотрел, но тогда он был на б-гомерзком нет-фреймоврке, котороый в винде не шел “изкаробки”

Ого, у вас есть прототип и идеи что нужно. Это гораздо лучше. Правда простым и инутитивно понятным я бы прототип не назвал судя по картинкам ))).

ОЧЕНЬ важно!!! Код желательно писать так, чтобы общение с хранилищем данных осуществлялось через простой программный интерфейс. Тогда вам не надо будет все переписывать при смене базы данных.

pickle вовсе не простой текстовый файл. Прочитайте документацию.

Про GUI. при написании на питоне игроков не много Qt, wx, GTk. Qt конечно дает гораздо больше возможностей.
Из преимуществ wx - у него гораздо более прозрачная лицензия (для нас определяющее). У него значительно меньше рантайм. Ну и нативность контролов зачастую важна.

Наглядность Qt? Это вы про дизайнер? Он есть практически для всех фреймвоков. Ну от себя я бы рекомендовал не увлекаться. Думаю вы очень Быстро упретесь в то что дизайнер не позволяет выразить как именно надо разместить элементы. Последует болезненный переход на программное размещение.

Мне для сложного GUI поддерживать программное размещение элементов гораздо проще чем поддерживать код и метафайлы дизайнера вместе.

Требование чтобы у базы был один файл выглядит идиотским. Одни там файл или 10 вообще ничего ни для кого не значит.

Рекомендую посмотреть на SQL алхимию. Она изолирует вас от конкретного движка Реляционной СУБД.

Есть еще такой зверь как zodb. Для нее даже ОРМ не нужен.

Но я рекомендую не париться и взять pickle

Alex_289
Но все-же более менее уже представляю, как писать интерфейс, связывать между собой окна и тд и тп.

Думаю, ты в розовых очках сидишь. “я представляю” и “я знаю как” - это разные вещи. Утонешь просто в графике только, до базы данных не дойдёшь даже. Потому что надо много раз переписывать одно и то же, чтобы научиться, а ты этого как раз избегаешь. Избегаешь - значит, не делаешь; не делаешь - значит, не умеешь делать.

Alex_289
Но в данном случае, единственный текстовый файл, в который будет сваливаться вся информационная составляющая программы мне кажется далеко не идеальным решением. Поэтому и озаботился поиском какой-то альтернативы. Потому что с БД как раз особо работать не приходилось, а если и приходилось, то это совсем не то что мне нужно.

Для твоей программки единственный текстовый файл подойдёт. Единственное, что ты не понимаешь, - это то, что в любой момент можно взять и переделать единственный файл на множественные файлы без какого-либо переделывания всей программы. Но для этого нужно иметь навыки разбиения программы на модули. Они есть у тебя? Очень сомнительно.

Так что без всех этих навыков ты дальше пустых окон, которые чотавот не работают нифига, не продвинешься. Соответственно, нет даже смысла тебе рассказывать, как написать эту программу, потому что ты каждый раз будешь спрашивать “а что дальше делать?”. Это как с базой данных и СУБД - два понятия, которые ты не различаешь даже. Нужно всё это тебе разъяснять и рассказывать. А какой в этом смысл? Всё уже и так написано в книгах, которых ты не читал, так как это всё долго и скучно.

PEHDOM
Alex_289 не слушайте его, пишите, пускай кроме вас оно никому не нужно, в процессе узнаете много чего новго и интересного, что может вам пригодиться в будущем.

Не слушаю )

PEHDOM
посмотрите на cherrytree, https://www.giuspen.com/cherrytree/ наверно не совсем то что вам нужно но может подойдет.. она опенсорс, тоесть можно, как минимум, подсмотреть как там у них все организовано.

Большое спасибо! Даже не рассчитывал, что можно будет где-то что-то еще и подсмотреть. Программа реально напоминает марснотебук. Только на питоне и БД в одном файле, как я и хотел.

doza_and
ОЧЕНЬ важно!!! Код желательно писать так, чтобы общение с хранилищем данных осуществлялось через простой программный интерфейс. Тогда вам не надо будет все переписывать при смене базы данных.

Ну, слева дерево разделов, справа заметки с нужными полями. Никак проще даже не представляю в отличие от того же evernote. А БД вот никак не хочется в будущем менять, поэтому и заморачиваюсь правильным выбором сразу.

doza_and
pickle вовсе не простой текстовый файл. Прочитайте документацию.

То, что нашел на русском пока не помогло мне осознать, как этот модуль можно использовать для моих задач. Может пойму в будущем. Но пока смотрю всё же в сторону sqlite. Мне кажется это реально как раз то что мне нужно.

doza_and
Про GUI. при написании на питоне игроков не много Qt, wx, GTk. Qt конечно дает гораздо больше возможностей.
Из преимуществ wx - у него гораздо более прозрачная лицензия (для нас определяющее).

Что значит более прозрачная лицензия? и почему это для нас определяющий момент?

doza_and
Наглядность Qt? Это вы про дизайнер? Он есть практически для всех фреймвоков. Ну от себя я бы рекомендовал не увлекаться. Думаю вы очень Быстро упретесь в то что дизайнер не позволяет выразить как именно надо разместить элементы. Последует болезненный переход на программное размещение.

Думаю, я понимаю про что вы, но мне дизайнер нужен прежде всего для того, чтобы быстро набросать интерфейс и посмотреть как все это может выглядеть в целом. Кстати для wx пока не нашел дизайнера, хотя его нативность действительно служит для меня весомым аргументом.

doza_and
Требование чтобы у базы был один файл выглядит идиотским. Одни там файл или 10 вообще ничего ни для кого не значит.e

Для меня как пользователя значило! ) Я когда пробовал все эти программки, всегда боялся множества этих файлов из-за того, чтобы случайно чего-то там из них не удалить. А когда БД одна и ее можно забекапить простым копированием - вот это для меня идеально. Насколько я наконец понял sqlite как раз такая и есть.

doza_and
Рекомендую посмотреть на SQL алхимию. Она изолирует вас от конкретного движка Реляционной СУБД. Есть еще такой зверь как zodb. Для нее даже ОРМ не нужен.

Спасибо! SQLAlchemy заинтересовал, тоже планирую поизучать. А вот до ZODB пока не дорос походу… также как и с pickle пока непонятна сама логика использования при моих задачах. Что там у меня считать объектом, заметку что-ли…

p.s. Ну, в общем ответ на свой вопрос я получил. Почитал еще разные статьи, посмотрел некоторые ролики и насколько я понял SQLite должен мне подойти идеально. Еще раз большое спасибо всем, кто помог мне въехать в тему! )

Alex_289

а что если работать со словарем dict(), а хранить в json в одном файле?

Варианты json/yaml/picle предполагают загрузку всех данных в память, а базы данных могут кусочками подгружать. Но в этом приложении данных мало, поэтому вполне рабочий вариант.

Вторая особенность. Базы могут откатывать назад транзакции. Это может уменьшить количество кода.

Ну и наконец с азами будет трудоемкая возня с явным или неявным ORM. Именно поэтому я не советую использовать RDBM

doza_and
Но в этом приложении данных мало, поэтому вполне рабочий вариант.

Я думаю это простой вариант,чтобы тс смог попробовать просто сохранить данные в словаре,без всяких GUI пока, написать пару функций => создать заметку, сохранить заметку,редактировать.При выходе из консоли сохраниться в json, а при старте приложения загрузиться из json.

xam1816
При выходе из консоли сохраниться в json, а при старте приложения загрузиться из json.

Любой формат подойдёт, даже свой собственный. Проблемы начнутся, когда эта штука станет большой. Её всю надо будет загружать сначала в память, потом при каждом мелком изменении её всю надо будет сохранять на диск. И для большой штуки, которая не только загружается, но ещё на её основе строится какое-то представление, начнётся долгое просчитывание всех этих построений, которое будет занимать уже секунды.
В Emacs'е такая проблема с org-файлами как раз. На большом org-файле работа с пунктами в нём начинает тормозить, потому что он всё время пересчитывает пункты, чтобы правильно отображать всё.

Вот поэтому ему предлагаем реляционную СУБД, хранящуюся в одном файле. В такой СУБД можно редактировать данные по частям, не считывая всё в память. Но проблема в том, что она бинарная. То есть для правки понадобится программа, руками в неё не залезешь через обычный блокнот или через обычный скрипт.

Вот doza_and писал, например, про дизайнеры форм для GUI, что они неудобны и тому подобное. Я сделал просто: все проблемы с дизайнером устранил с помощью своего скрипта, который залазит в файлы дизайнера и просто меняет их. Дизайнер что-нибудь сделал ненужное, я скрипт свой запустил, всё убралось обратно, полезное осталось, вредное удалилось. А как я так залез в файлы дизайнера? Да очень просто, это же XML-файлы, а XML - это просто текст. Были бы они бинарными, я бы ещё десять раз подумал, стоит ли писать для них обработчик. Его, во-первых, не напишешь, а во-вторых, если и напишешь, то это того не стоит.