Python - working with xml/lxml/objectify/schemas, datatypes, and assignments

[aapost]

On 1/11/23 13:21, Dieter Maurer wrote:
> aapost wrote at 2023-1-10 22:15 -0500:
>> On 1/4/23 12:13, aapost wrote:
>>> On 1/4/23 09:42, Dieter Maurer wrote:
>>> ...
>>>> You might have a look at `PyXB`, too.
>>>> It tries hard to enforce schema restrictions in Python code.
>>> ...
>> Unfortunately picking it apart for a while and diving deeper in to a
>> rabbit hole, PyXB looks to be a no-go.
>>
>> PyXB while interesting, and I respect it's complexity and depth, is
>> lacking in design consistency in how it operates if you are trying to
>> modify and work with the resulting structure intuitively.
>> ... problem with simple types ...
> 
> I use `PyXB` in `dm.saml2` and `dm.zope.saml2`, i.e. with
> the SAML2 schema definitions (which include those
> of XML signature and XML encryption).
> I had no problems with simple types. I just assign them to attributes
> of the Python objects representing the XML elements.
> `PyXB` does the right thing when it serializes those objects into XML.

It does do a lot of good things, and I am sad to see all the good work 
in it not get used, but for me it really boils down to what it can sum 
up itself in a couple comments from the author in it's first file (which 
I appreciate them and their honesty, because those are comments I could 
see myself writing in a similar situation)...

######
class cscRoot (object):
     """This little bundle of joy exists because in Python 2.6 it
     became an error to invoke C{object.__init__} with parameters (unless
     you also override C{__new__}, in which case it's only a warning.
     Whatever.).  Since I'm bloody not going to check in every class
     whether C{super(Myclass,self)} refers to C{object} (even if I could
     figure out how to do that, 'cuz the obvious solutions don't work),
     we'll just make this thing the root of all U{cooperative super
 
calling<http://www.geocities.com/foetsch/python/new_style_classes.htm#super>}
     hierarchies.
######

######
     def __init__ (self, *args, **kw):
         # Oh gross.  If this class descends from list (and probably 
dict), we
         # get here when object is *not* our direct superclass.  In that 
case,
         # we have to pass the arguments on up, or the strings don't get
         # created right.  Below is the only way I've figured out to 
detect the
         # situation.
         #
         # Note that we might also get here if you mix-in a class that used
         # object as a parent instead of cscRoot.  Don't do that. 
Printing the
         # mro() is a decent way of identifying the problem.
######

using that suggestion you can see that on simple types
 >>> pyxbxmlroot.SomeString._mro()
[<class 'pyxb.binding.datatypes.string'>, <class 
'pyxb.binding.basis.simpleTypeDefinition'>, <class 
'pyxb.binding.basis._TypeBinding_mixin'>, <class 
'pyxb.utils.utility.Locatable_mixin'>, <class 
'pyxb.utils.utility._DeconflictSymbols_mixin'>, <class 
'pyxb.binding.basis._DynamicCreate_mixin'>, <class 'pyxb.cscRoot'>, 
<class 'str'>, <class 'object'>]

it has a python type that it sends all the way up right next to object, 
when that doesn't actually occur until after simpleType in class string 
(basis.simpleTypeDefinition, str):

This makes the object dependent on it's parent, since it itself IS the 
value, I can't assign to or do anything to it by itself, or it and all 
the other stuff goes away. As designed it is very hard to change 
anything in it without breaking something.

After working with xmlschema, it pretty much confirmed my assumptions 
that it doesn't need to be that way. I was able to follow what was going 
on and tweak xmlschema fairly easily.

That and the fact that PyXB was abandoned 5-6 years ago make it a strong 
no-go to use in a project. It would need to be adopted with fresh 
development, stripped of the python2 stuff, and the object structure 
redesigned in a more uniform way with functionality properly 
containerized instead of all stuffed together...