[x3d-public] Results for today with x3d.py, _X3DField

[John Carlson]

Based on a tiny bit of code review, the below parameter changes may be necessary.  I don’t think we should clutter up the code with numerous unnecessary parameters.

However, the output JSON is not pretty yet.  I will take the string and run it through json.loads and json.dumps when I get a chance.  I’m fairly sure the JSON doesn’t pass jsonlint though, so parsing is premature.

Are you parsing XML yet, or do you see my code as a new generation of X3DJSONLD?

John

Sent from my iPad

> On Dec 6, 2021, at 2:27 AM, John Carlson <yottzumm at gmail.com> wrote:
> 
> 
> Apparently the package/module hasn't propagated yet, because it said I had 4.0.43 up-to-date.   But I got x3d.py from sourceforge:
> 
> The follow diff allowed me to export JSON as found in a previous attachment.   Perhaps we should add indent and syntaxs to all JSON def methods?  Also, the str I adding I think prints out NoneType...not desired in JSON, perhaps we need to throw an exception? if each.JSON() returns None or NoneType? I will review particulars you have changed.
> 
> $ diff /c/x3d-code/www.web3d.org/x3d/stylesheets/python/x3d.py x3d.py 
> 12286c12286 
> <                     result += each.JSON(indentLevel=indentLevel+1, syntax=syntax) 
> --- 
> >                     result += str(each.JSON()) 
> 42390c42390 
> <                     result += each.JSON(indentLevel=indentLevel+1, syntax=syntax) 
> --- 
> >                     result += each.JSON() 
> 77395c77395 
> <                 result += self.geometry.JSON(indentLevel=indentLevel+1, syntax=syntax) 
> --- 
> >                 result += self.geometry.JSON() 
> 89045c89045 
> <                     result += each.JSON(indentLevel=indentLevel+1, syntax=syntax) 
> --- 
> >                     result += each.JSON()
> 
> On 12/6/21 00:36, Brutzman, Donald (Don) (CIV) wrote:
>> I think it cleaned up OK.  Changes tested and checked in, now version 4.0.44 on PyPi.
>>  
>> https://pypi.org/project/x3d
>>  
>> all the best, Don
>> --
>> Don Brutzman  Naval Postgraduate School, Code USW/Br        brutzman at nps.edu
>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA    +1.831.656.2149
>> X3D graphics, virtual worlds, navy robotics https:// faculty.nps.edu/brutzman
>>  
>> From: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu> 
>> Sent: Sunday, December 5, 2021 10:09 PM
>> To: vmarchetti at kshell.com; John Carlson <yottzumm at gmail.com>
>> Cc: X3D-Public <x3d-public at web3d.org>; Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
>> Subject: RE: [x3d-public] Results for today with x3d.py, _X3DField
>>  
>> Thanks for reports and correct diagnosis.  I did take out the three “object” inheritances earlier today, pylint says it is no longer required in Python 3, no ill effects noted.
>>  
>> I have tried to follow X3D4 Architecture exactly, and am keen to avoid overwriting!  Hopefully tonight’s build looks a bit better.
>>  
>> The specification does not show X3DField inheriting from anything.
>>  
>> X3D4 Architecture, 5.2.3 X3DField
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/fieldTypes.html#X3DField
>>  
>> X3D4 Architecture, 54.4.2.3 Interface hierarchy
>> (looks like first line of Figure 4.2 needs more whitespace)
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/concepts.html#InterfaceHierarchy
>>  
>> Sure enough, searching for “class _ X3DField” in x3d.py reveals two abstract class definitions, ouch!  That’s more like multiple personalities that multiple inheritance…
>>  
>> Will work on fixing the autogeneration of offending version.
>>  
>> all the best, Don
>> --
>> Don Brutzman  Naval Postgraduate School, Code USW/Br        brutzman at nps.edu
>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA    +1.831.656.2149
>> X3D graphics, virtual worlds, navy robotics https:// faculty.nps.edu/brutzman
>>  
>> From: vmarchetti at kshell.com <vmarchetti at kshell.com> 
>> Sent: Sunday, December 5, 2021 3:59 AM
>> To: John Carlson <yottzumm at gmail.com>
>> Cc: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; X3D-Public <x3d-public at web3d.org>
>> Subject: Re: [x3d-public] Results for today with x3d.py, _X3DField
>>  
>> Python does support multiple inheritance, but these fragments are not an example of a multiple-inheritance situation -- rather, the later class definition -- where _X3DField is a subclass of _X3DNode, overwrites the earlier class definition.
>>  
>> In the x3d.py file, only three classes are defined as direct subclasses of object:
>>  
>> class _X3DField
>> class _X3DNode
>> class _X3DStatement
>>  
>> So I think the operative question is whether it is a design intent that _X3DField also should be a subclass of _X3DNode.  I judge the answer is no, since that would include support for DEF, USE, and metadata. In that light, the second class defintion for _X3DField would be regarded as a bug, to be corrected by modifying the X3duomToX3dPythonPackage.xslt stylesheet.
>>  
>> 
>> On Dec 4, 2021, at 11:40 PM, John Carlson <yottzumm at gmail.com> wrote:
>>  
>> Two declarations of _X3DField?
>> $ grep "class _X3DField" x3d.py          
>>  
>> class _X3DField(object):
>> class _X3DField(_X3DNode):
>> Is there a pylint?
>> Isn't multiple inheritance possible?
>> Thanks!
>> John
>>  
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20211206/1ba6911b/attachment-0001.html>