On Tuesday, January 23, 2018 at 8:23:43 PM UTC+5:30, Peter Otten wrote: > Rustom Mody wrote: > > [I find the OO/imperative style of making a half-done node and then > > [throwing > > piece-by-piece of contents in/at it highly aggravating] > > What I meant is that once you throw a bit of introspection at it much of the > tedium vanishes. Here's what might become of the DOM-creation as part of an > actual script:
«snipped named-tuple magic» > To generalize that to handle arbitrarily nested lists and namedtuples a bit > more effort is needed, but I can't see where lxml.objectify could make that > much easier. You really mean that?? Well sure in the programming world and even more so in the python world “Flat is better than nested” is a maxim But equally programmers need to satisfy requirements… And right now I am seeing things like this ----------------------------------------------- <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <locns:blobRetrieveResponse xmlns:locns="http://example.com/"> <REQUEST> <TYPE> AGGREGATION_ANALYSIS </TYPE> <DATASTREAM_COLLECTION> <DATASTREAM ID="ad907z9e-982c-4491-bc26-75bf96c0d59d"> <FIELDINFO FIELD="Date Stamp" FIELDTYPE="DATE" FIELDFORMAT="m/d/y" /> <FIELDINFO FIELD="Transaction Amount" FIELDTYPE="MONEY" LOCALE="en-US"/> </DATASTREAM> </DATASTREAM_COLLECTION> <COMPUTATION_COLLECTION> <COMPUTATION ALGORITHM="VARIANCE" DATASTREAM="ad907z9e-982c-4291-bc26-75bf96c0d59d" FIELD="Transaction Amount" RESULT="6ef0ce23-6637-4cb7-974c-3973d5a58942" /> <COMPUTATION ALGORITHM="MEDIAN" DATASTREAM="ad907z9e-982c-4291-bc26-75bf96c0d59d" FIELD="Date Stamp" RESULT="6ef0ce23-6637-4cb7-974c-3973d5a58942" /> <COMPUTATION ALGORITHM="AVERAGE" DATASTREAM="ad907z9e-982c-4291-bc26-75bf96c0d59d" FIELD="Transaction Amount" RESULT="6ef0ce23-6637-4cb7-974c-3973d5a58942" /> </COMPUTATION_COLLECTION> <DATA_COLLECTION> <DATA DATASTREAM="ad907c9e-982c-4491-bc26-45af96c0d59d" MODE="BLOB" TYPE="CSV"> «Big base64 blob» </DATA> </DATA_COLLECTION> </REQUEST> </locns:blobRetrieveResponse> </soap:Body> </soap:Envelope> ----------------------------------------------- Thats 7 levels of nesting (assuming I can count right!) Speaking of which another followup question: With # Read above xml >>> with open('soap_response.xml') as f: inp = etree.parse(f) # namespace dict >>> nsd = {'soap': "http://schemas.xmlsoap.org/soap/envelope/", 'locns': >>> "http://example.com/"} The following behavior is observed — actual responses elided in the interest of brevity >>> inp.xpath('//soap:Body', namespaces = nsd) finds/reaches the node >>> inp.xpath('//locns:blobRetrieveResponse', namespaces = nsd) finds >>> inp.xpath('//locns:dtCreationDate', namespaces = nsd) does not find >>> inp.xpath('//dtCreationDate', namespaces = nsd) finds >>> inp.xpath('//dtCreationDate') also finds Doesnt this contradict the fact that dtCreationDate is under the locns namespace?? Any explanations?? -- https://mail.python.org/mailman/listinfo/python-list