Народ Нужна помощь. Есть ли в python3 возможность налету создавать списки
Например есть файл с примерно такой структуре(пример xml)

это надо представить в виде списка, categories= ,…,subcat_namen],…,cat_namen]
это нужно для того что бы потом прoбежаться по строкам.
например
вот как это можно сделать? это общее представление примерно как я вижу, если подскажете буду рад

Конечная цель в чём состоит?

Пробежать по всем элементам xml-дерева можно через соответствующий iter.
python.org. xml. iter

цель в следующем. есть строка из которой надо вытащить категории, подкатегории заданные изначально.
например
категория: двигатель
в неё входит подкатегория: поршни
в них входит: “(поршень)”
“(кольцо маслосъемное)
клапаны:
”клапан“
”что либо"
потом из строки разбирать в след вид. категория, под категория, бренд, наименование, марка, модели.
выдергивать придется с помощью регулярных выражений.
вот пример строки
Рычаги подвески™555;555;SA6181L;555-SA-6181L_рычаг передний верхний левый!\ Honda Accord 90-94;SA6181L_555;SA-6181L
а дерево категорий, не придумал ничего лучше, как засунуть в XML формат

Stazot
не придумал ничего лучше, как засунуть в XML формат

Трудно придумать что-то хуже чем засунуть в XML формат. Сделайте словари словарей, отлично будет и в питоне разбираться и сохраняться в pickle или json

doza_and
объясните фобию

FishHook
объясните фобию

Опыт. Если сохраняются именно данные то

• Код сохранения восстановления получается сильно больше, особенно если кто-то намутит с namespace.
  
• Нет родной поддержки примитивных типов int, float надо огород городить.
  
• Опыт редактирования данных в файле, причем не только мой но и коллег - редактировать сложнее чем тот-же yaml
  
• чуток больше чем json, иногда народ за каждую точечку бъется.
  
• Не поддерживается потоковая сериализация. Неудобно работать когда медленные соединения или большие объемы данных.
  

Но у xml конечно есть и достоинства.

• оптимизированные по быстродействию сериализаторы.
  
• xpath
  
• xslt
  

p.s.
постоянно приходится сталкиваться с проектами где в парсинг xml узкое место по быстродействию или xml загнали несколько десятков мегабайт текста и потом рекомендуют править ручками.
Но вообще xml vs some тема холиварная.

doza_and
или xml загнали несколько десятков мегабайт текста

Я вообще видал 600 мегов в одну строку. Даже прогами не обработаешь типа sed'а, потому что у него строковой буфер ограничен 4-мя (не менее) килобайтами.

Stazot
цель в следующем. есть строка из которой надо вытащить категории, подкатегории заданные изначально.

Неясно задание. Сделай примерный xml-файл (минимально ограниченный по данным), сделай файл результата, который нужно получить из исходного xml-файла. И потом объясни принцип получения. И только потом можно писать код - когда всё ясно.

Не поддерживается потоковая сериализация. Неудобно работать когда медленные соединения или большие объемы данных.

этого не понял, теговая структура именно способствует потоковой обработке данных ввиду однозначности события закрытия ноды

Код сохранения восстановления получается сильно больше, особенно если кто-то намутит с namespace.

и что? терабайты никто не передает ни в каком текстовом формате, не в 90-е живем, накладные расходы на закрывающие теги несущественны

Нет родной поддержки примитивных типов int, float надо огород городить.

никакой огород городить не надо если вы заранее знаете структуру данных, которая ожидается в XML. Я затрудняюсь придумать сценарий, когда структура может быть не известна. Сериализатор с одной стороны взаимодействия, десериализатор с другой, какие проблемы то? Любой современный ЯП позволяет делать это нативно и прозрачно

Опыт редактирования данных в файле,

Это конфиги что ли? Если у вас очень большие конфиги, то у вас что-то не то с архитектурой. В чем проблема работать с XML-конфигами? Любой текстовый редактор представит конфиг как дерево нод.

чуток больше чем json, иногда народ за каждую точечку бъется.

Я много всякого народа видел. 95% процентов населения дебилы

FishHook
этого не понял, теговая структура именно способствует потоковой обработке

Теговая структура да, но она есть не только в xml. Я знаю два способа парсинга xml. 1 загрузить все в память (dom/etree) очевидно пока не загрузишь все пользоваться xml нельзя, если данных много они сожрут память.
2 sax. По сути это и есть потоковая обработка. Но также как и xml она слишком общая, и поэтому очень неудобная. Если в определенный момент времени у вас произошел дисконнект, потребовалось перезапустить сервер и т.п. вы не можете начать читать данные с последней контрольной точки, вы обязаны начать читать xml дерево с самого начала (корректный xml документ должен иметь корневой элемент).

FishHook
и что? терабайты никто не передает

Я имел ввиду код программы который человек пишет для того чтобы использовать данные. Дело не в экономии на тегах а в экономии времени разработчика. Для xml необходим нетривиальный код разбора данных (то что я видел у коллег которые пользуются xml это сотни иногда тысячи строк кода). А для json/yaml/pickle/hdf5 и т. п. в большинстве случаев достаточно просто считать данные двумя тремя строчками. Т.е. не то что прозрачный а вообще никакой специальный код сериазизации/десериализации не нужен.

По поводу конфигов вы своих коллег опросите. Когда спрашbвал, вам конфиг в xml или в yaml сделать не было случая чтобы человек xml выбрал. Нахрена надо ручками каждую козявку в теги заворачивать? Народ данные зачастую из программы в конфиг копипастит. с нормальными форматами нет проблем, а с xml будь добр заворачивай… Еще забава. Народ в конфиги формулы забивает. Наши коллеги закончили тем что парсер расширили чтобы без проблем знаки больше и меньше можно было забивать. Т.е вроде и xml но невалидный, ничем кроме их парсера не читается.

С последним согласен. Но это ен упрщает к сожалению борьбу с такими лицами.

doza_and
Вы так говорите, как будто кто-то где то парсит результаты текстовой сериализации вручную. Не, бывает конечно такое, что клиент просит загрузить данные из какого-то своего своеобразного формата причем не через soap. Ну и что? Это копеечная работа и заюзать для парсинга lxml или json нет большой разницы. 99% трафика гуляющего между серверами парсится на уровне протоколов, поэтому совершенно все равно в каком формате эти данные передаются. А когда данные патрсятся на уровне прикладного кода то в дело вступают ORM-образные привязки и опять проблем нет. Повторю свою мысль - совершенно плевать, в каком формате передавать данные. Есть технологии подразумевающие формат данных. Если мы говорим про SPA и RESTfull API то тут скорее всего будет JSON, если про SOAP то XML. Но не те и не другие данные вам нет нужды форматировать руками - все делают библиотеки, поэтому плевать на формат.