[x3d-public] Results for today with x3d.py, _X3DField
John Carlson
yottzumm at gmail.com
Mon Dec 6 13:03:01 PST 2021
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>
More information about the x3d-public
mailing list