[x3d-public] x3d.py package: Some feedback and suggestion for improvement; tuples and lists; updated x3d.py
Brutzman, Donald (Don) (CIV)
brutzman at nps.edu
Tue Mar 1 19:31:55 PST 2022
Thanks for super feedback, sounds promising.
1. Fixed capitalization in autognerated __init__.py file.
2. Got the dot! “from .x3d import *”
Inspectable at
* https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/python/__init__.py
Full details on relative imports at
* https://docs.python.org/3/reference/import.html#package-relative-imports
3. Added NumpyExample.py to build tests, works fine
* https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/python/examples/NumpyExample.py
4. Rechecked setup.py according to
* https://docs.python.org/3/distutils/setupscript.html
5. Bad news, still no joy. Following “pip install x3d” and hiding PYTHONPATH, the PyPi version installed via pip still fails, now saying:
IT160907-UWALPP+brutzman at IT160907-UWALPP /cygdrive/c/x3d-code/www.web3d.org/x3d/content/examples/X3dForWebAuthors/Chapter02GeometryPrimitives
$ python BoxExample.py
Traceback (most recent call last):
File "C:\x3d-code\www.web3d.org\x3d\content\examples\X3dForWebAuthors\Chapter02GeometryPrimitives\BoxExample.py", line 23, in <module>
import x3d
ModuleNotFoundError: No module named 'x3d'
6. Here is what it looks like with same local x3d.py directory found in PYTHONPATH
IT160907-UWALPP+brutzman at IT160907-UWALPP /cygdrive/c/x3d-code/www.web3d.org/x3d/content/examples/X3dForWebAuthors/Chapter02GeometryPrimitives
$ python BoxExample.py
x3d.py package 4.0.60 loaded, have fun with X3D Graphics!
Python-to-XML well-formed XML document test of XML output complete
Python-to-XML X3D 3.3 schema validation test of XML output complete
Python-to-VRML export of VRML output successful
Python-to-JSON export of JSON output successful (under development)
python x3d.py load and self-test complete for BoxExample.py
7. And so, am still stuck. Arggh. Further review welcome. I have checked in everything, now including the build artifacts.
* https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/python
* https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/python/x3d.egg-info
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: Tuesday, March 1, 2022 9:46 AM
To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; X3D-Public <x3d-public at web3d.org>
Cc: John Carlson <yottzumm at gmail.com>; Peitso, Loren (CIV) <lepeitso at nps.edu>; Hans Moritz Guenther <hgunther at mit.edu>
Subject: Re: [x3d-public] x3d.py package: Some feedback and suggestion for improvement; tuples and lists; updated x3d.py
I have taken an additional look at this.
1. In the file x3d/__init__.py , for the pypi installation, a Python list is declared with name of __all__ , this is a magic name in the Python import system and is intended to be a list of strings, matching the names of Python elements in a module. At the version 4.0.51 this list is no longer consistent with the contents of the x3d.py file, in particular the string 'accessTypeChoices' is in the __all__ list, but there is no Python content of that name in x3d.py (there is a different capitalization version, ACCESSTYPECHOICES . Python is case-sensitve throughout.
This breaks some of the import statements, so as a temporary fixed I renamed the __all__ variable so it is inert and harmless. The other fix would be to update __all__
* Have updated autogeneration rule for __all_ to include matching capitalization for these enumerations.
*
2. With the __all__ variable removed as discussed above, I added this statement as the last line of the x3d/__init__.py file:
############## added ######
from .x3d import *
############## end added ###
With that change, I was able to run the NumpyExample.py script using either of the import statements at the top of the script:
from x3d import *
OR
from x3d.x3d import *
My confirmation is on a system with only the Pypi installation of the x3d package, and no site-specific modification of the Python package search functions.
This fix, or something very close to it, was suggested by Moritz Guenther in one of his emails to the Consortium or mailing list.
For Python-heads : In the statement "from .x3d import *' the period before x3d is crucial, it activates the concept of Python relative import : see https://docs.python.org/3/reference/import.html <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.python.org%2F3%2Freference%2Fimport.html&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610573878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=omk23QAef2xroumVFYzUYNdCSRgUa0fLOVDjUsjB7Pk%3D&reserved=0>
Vince Marchetti
On Mar 1, 2022, at 10:02 AM, Brutzman, Donald (Don) (CIV) <brutzman at nps.edu <mailto:brutzman at nps.edu> > wrote:
Our goal is to make this widely repeatable without problems, used by anyone. So we must get the simplest of cases sorted out first.
The pypi distribution of x3d.py does not behave the same as someone’s local copy of x3d.py package, presumably because of the __init__.py provided with it or possibly some other configuration file. Sleuthing and testing continue.
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br <mailto:brutzman at nps.edu> brutzman at nps.edu
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, Navy robotics https:// <http://faculty.nps.edu/brutzman> faculty.nps.edu/brutzman
From: John Carlson < <mailto:yottzumm at gmail.com> yottzumm at gmail.com>
Sent: Monday, February 28, 2022 8:47 PM
To: Brutzman, Donald (Don) (CIV) < <mailto:brutzman at nps.edu> brutzman at nps.edu>
Cc: Hans Moritz Guenther < <mailto:hgunther at mit.edu> hgunther at mit.edu>; Peitso, Loren (CIV) < <mailto:lepeitso at nps.edu> lepeitso at nps.edu>; X3D Public Mailing List ( <mailto:x3d-public at web3d.org> x3d-public at web3d.org) < <mailto:x3d-public at web3d.org> x3d-public at web3d.org>
Subject: Re: [x3d-public] x3d.py package: Some feedback and suggestion for improvement; tuples and lists; updated x3d.py
Ok, Don. I mostly just copy x3d.py to my source folder and set PYTHONPATH. Maybe you could try in a conda or python virtual environment?
On Mon, Feb 28, 2022 at 10:44 PM Brutzman, Donald (Don) (CIV) < <mailto:brutzman at nps.edu> brutzman at nps.edu> wrote:
Have tried a few solutions to getting things working without having the double x3d.x3d import statement. Unfortunately still not working.
Latest stable build remains
* <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpypi.org%2Fproject%2Fx3d%2F4.0.51&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610573878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=7e3tTYAtr63mTy6BtSNYauvvr%2BFJtgZ2fF6XnK7G6Pc%3D&reserved=0> https://pypi.org/project/x3d/4.0.51
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br <mailto:brutzman at nps.edu> brutzman at nps.edu
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, Navy robotics https:// <http://faculty.nps.edu/brutzman> faculty.nps.edu/brutzman
From: Brutzman, Donald (Don) (CIV) < <mailto:brutzman at nps.edu> brutzman at nps.edu>
Sent: Wednesday, February 23, 2022 7:30 AM
To: X3D Public Mailing List ( <mailto:x3d-public at web3d.org> x3d-public at web3d.org) < <mailto:x3d-public at web3d.org> x3d-public at web3d.org>
Cc: rlentz < <mailto:rlentz at gmail.com> rlentz at gmail.com>; Vince Marchetti < <mailto:vmarchetti at kshell.com> vmarchetti at kshell.com>; Mike McCann < <mailto:mccann at mbari.org> mccann at mbari.org>; Peitso, Loren (CIV) < <mailto:lepeitso at nps.edu> lepeitso at nps.edu>; Hans Moritz Guenther < <mailto:hgunther at mit.edu> hgunther at mit.edu>; Brutzman, Donald (Don) (CIV) < <mailto:brutzman at nps.edu> brutzman at nps.edu>
Subject: RE: x3d.py package: Some feedback and suggestion for improvement; tuples and lists; updated x3d.py
Have released another build of x3d.py (aka X3DJSAIL), now version 4.0.51.
* <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpypi.org%2Fproject%2Fx3d&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610573878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=wx49U15gxIkHs0EZ7f8O%2F1GRofDyhebuxAj4ARgE2Xg%3D&reserved=0> https://pypi.org/project/x3d
* <https://www.web3d.org/x3d/stylesheets/python/python.html> https://www.web3d.org/x3d/stylesheets/python/python.html
Updated features include:
* Override (and report) when a contained MetadataSet (or other Metadata*) node has incorrect containerField, providing extra care since default values changed in X3D4. Similar checks are provided in X3dTidy stylesheet.
* When a conversion error to XML (.x3d output file) occurs, only print out 7 lines of result file containing the error (instead of the whole file).
* Proper handling of typed values contained by <field> or <fieldValue> initializations for Script nodes and prototypes.
create python:
C:\x3d-code\ <http://www.web3d.org/> www.web3d.org\x3d\content\examples\X3dForWebAuthors/Chapter14Prototypes//TextStringPrototype.x3d processing with X3dToPython stylesheet...
C:\x3d-code\ <http://www.web3d.org/> www.web3d.org\x3d\content\examples\X3dForWebAuthors/Chapter14Prototypes//TextStringPrototype.py self-validation tests...
validate python:
x3d.py package loaded, have fun with X3D Graphics!
Python-to-XML well-formed XML document test of XML output complete
Python-to-XML X3D 3.3 schema validation test of XML output complete
Python-to-VRML export of VRML output successful
Python-to-JSON export of JSON output successful (under development)
python x3d.py load and self-test complete for TextStringPrototype.py
* <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dgraphics.com%2Fexamples%2FX3dForWebAuthors%2FChapter14Prototypes%2FTextStringPrototypeIndex.html&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610573878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=lFr2RUn33JQZl%2FyXdRyTtXYYsiLTdQLU9aXpurtVDp0%3D&reserved=0> https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/TextStringPrototypeIndex.html
* <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dgraphics.com%2Fexamples%2FX3dForWebAuthors%2FChapter14Prototypes%2FTextStringPrototype.py&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610573878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=UoaQmUDo4iJhBj5BgNfp%2F6xYYjZ93vX8bUsXhRFTmak%3D&reserved=0> https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/TextStringPrototype.py
* <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dgraphics.com%2Fexamples%2FX3dForWebAuthors%2FChapter14Prototypes%2FTextStringPrototype.x3d&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610573878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=jG18pUgyiMcwf3xLawh24TJoHU1RV7mYWxlLfaQzPSI%3D&reserved=0> https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/TextStringPrototype.x3d
The regression tests are running very cleanly, when processing the X3D Examples archives a handful of errors in field initializations were detected and now few exceptions are reported. Perhaps the only recurring exceptions are when some of our extremely large scans are encountered, too big for my laptop to published.
* <https://www.web3d.org/x3d/content/examples/build.python.all.log.txt> https://www.web3d.org/x3d/content/examples/build.python.all.log.txt
Also upgraded the Saxon xslt engine to version 11.2 of open-source home edition (HE), to good effect.
* <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.saxonica.com%2Fhtml%2Fdocumentation11%2Fabout&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610573878%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=DV7rsjxGdCSSgPlTBnv%2F%2FcyMS%2BnrwmgoINz3dqQYuTc%3D&reserved=0> https://www.saxonica.com/html/documentation11/about
Have fun with X3D Python! 8)
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br <mailto:brutzman at nps.edu> brutzman at nps.edu
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, Navy robotics https:// <http://faculty.nps.edu/brutzman> faculty.nps.edu/brutzman
From: Brutzman, Donald (Don) (CIV) < <mailto:brutzman at nps.edu> brutzman at nps.edu>
Sent: Monday, February 21, 2022 9:41 AM
To: Hans Moritz Guenther < <mailto:hgunther at mit.edu> hgunther at mit.edu>; X3D Public Mailing List ( <mailto:x3d-public at web3d.org> x3d-public at web3d.org) < <mailto:x3d-public at web3d.org> x3d-public at web3d.org>
Cc: rlentz < <mailto:rlentz at gmail.com> rlentz at gmail.com>; Vince Marchetti < <mailto:vmarchetti at kshell.com> vmarchetti at kshell.com>; Mike McCann < <mailto:mccann at mbari.org> mccann at mbari.org>; Peitso, Loren (CIV) < <mailto:lepeitso at nps.edu> lepeitso at nps.edu>; Brutzman, Donald (Don) (CIV) < <mailto:brutzman at nps.edu> brutzman at nps.edu>
Subject: RE: x3d.py package: Some feedback and suggestion for improvement; tuples and lists; updated x3d.py
Hello all python programmers. Another x3d.py release is available. Have performed a complete refactoring of field type setters as well as corresponding isValid* and assertValid* methods. The field types now perform value validation whenever setting, and duck typing is preserved wherever possible up and down within the X3D field types. Now published to PyPi with corresponding unit tests complete.
* x3d 4.0.50
* pip install x3d==4.0.50
* <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpypi.org%2Fproject%2Fx3d%2F4.0.50&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610730103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=yEACKYmvcqPb3PZ3gjzcAdezLTMPh%2BoY6dRreSwpry8%3D&reserved=0> https://pypi.org/project/x3d/4.0.50
* X3D Examples Archive regression tests, several post-test improvements are being added:
* <https://www.web3d.org/x3d/content/examples/build.python.all.log.txt> https://www.web3d.org/x3d/content/examples/build.python.all.log.txt
Once again a large number of smoke tests have been added, confirming it is indeed a good way to check new functionality.
* <https://www.web3d.org/x3d/stylesheets/python/examples/PythonX3dSmokeTests.py> https://www.web3d.org/x3d/stylesheets/python/examples/PythonX3dSmokeTests.py
* <https://www.web3d.org/x3d/stylesheets/python/build.examples.log.txt> https://www.web3d.org/x3d/stylesheets/python/build.examples.log.txt
I’ve looked at numpy a little, but there are many types. We’re ready to consider utility methods. Up until now, I have hesitated to offer plain-array support for data types since that might easily break tuple checks.
Example(s) showing common use cases for X3D with numpy would be helpful, TIA.
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br <mailto:brutzman at nps.edu> brutzman at nps.edu
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, Navy robotics https:// <http://faculty.nps.edu/brutzman> faculty.nps.edu/brutzman
From: Brutzman, Donald (Don) (CIV) < <mailto:brutzman at nps.edu> brutzman at nps.edu>
Sent: Sunday, February 13, 2022 11:08 PM
To: Hans Moritz Guenther < <mailto:hgunther at mit.edu> hgunther at mit.edu>; Peitso, Loren (CIV) < <mailto:lepeitso at nps.edu> lepeitso at nps.edu>
Cc: rlentz < <mailto:rlentz at gmail.com> rlentz at gmail.com>; Vince Marchetti < <mailto:vmarchetti at kshell.com> vmarchetti at kshell.com>; Mike McCann < <mailto:mccann at mbari.org> mccann at mbari.org>; X3D Public Mailing List ( <mailto:x3d-public at web3d.org> x3d-public at web3d.org) < <mailto:x3d-public at web3d.org> x3d-public at web3d.org>; Brutzman, Donald (Don) (CIV) < <mailto:brutzman at nps.edu> brutzman at nps.edu>
Subject: RE: x3d.py package: Some feedback and suggestion for improvement; tuples and lists; updated x3d.py
I have updated x3d.py to include several points of progress.
a. REGEX_PYTHON (perturbated from REGEX_XML) for all types. Validation of each X3D-typed python value now includes regex checking.
b. The standard python library ‘re’ for regexes is now imported by x3d.py
c. In X3D XML Schemas and X3DUOM, made regex occurrence (\s) consistent throughout as \s
d. Strings are now allowed as validatable values for some simple types. More work needed for list and array combinations.
e. Documentation and tests:
* Python X3D Package x3d.py
* “The x3d.py Python X3D Package supports programmers with Python interfaces and objects for standards-based X3D programming, all as open source.”
* <https://www.web3d.org/x3d/stylesheets/python/python.html> https://www.web3d.org/x3d/stylesheets/python/python.html
f. A large number of smoke tests have been added, this is indeed a good way to check new functionality.
* <https://www.web3d.org/x3d/stylesheets/python/examples/PythonX3dSmokeTests.py> https://www.web3d.org/x3d/stylesheets/python/examples/PythonX3dSmokeTests.py
* <https://www.web3d.org/x3d/stylesheets/python/build.examples.log.txt> https://www.web3d.org/x3d/stylesheets/python/build.examples.log.txt
g. Have added section on Data Types to X3D Python page.
* <https://www.web3d.org/x3d/stylesheets/python/python.html#DataTypes> https://www.web3d.org/x3d/stylesheets/python/python.html#DataTypes
<https://www.web3d.org/x3d/stylesheets/python/python.html#DataTypes> 🔖 Data Types
An important aspect of Python ease of programming is <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDuck_typing&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610730103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=vNED01kmiH0jq0k80r8NUjBvhfMxJHfXNH5eJeehp8Y%3D&reserved=0> duck typing: If it looks like a duck and walks like a duck and quacks like a duck, then it must be a duck.
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.python.org%2F3%2Fglossary.html%23term-duck-typing&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610730103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=DgZm0pmpsxc0mRUJl40dW7c4fDw24BnEx0NLQEpb8K8%3D&reserved=0> Python duck typing describes how well-designed code improves its flexibility by allowing polymorphic substitution (i.e. <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FParametric_polymorphism&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610730103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=vhtpnrl6REzxXdO%2BXa743Ob0VeNASOCzjAA0ipqZ8NM%3D&reserved=0> parametric polymorphism).
X3D has strictly defined <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/fieldTypes.html> field types for every field of every node in the standard. This means that all values can be statically checked when defining a model, leading to high-quality model files. Further it is an error to provide an incorrectly typed value at run time, i.e. an SFString cannot be directly used as a numeric value. This approach precludes a wide range of errors that can occur in other languages. Details on each possible X3D type can be found at <https://www.web3d.org/x3d/content/X3dTooltips.html#type> X3D Tooltips: types.
Strict typing checks are included when building X3D classes and assigning values to fields, for all X3D types. This strictness for input data prevents <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FGarbage_in%2C_garbage_out&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610730103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=FpbUU06pR%2Fon85yPbMSp5R%2BFaAaoyeudoEeiJSqQ0TI%3D&reserved=0> Garbage in, garbage out pathologies when creating X3D models.
<https://www.web3d.org/specifications/X3dRegularExpressions.html> X3D regular expression (regex) checking is applied to result values. Each type class includes string constants for REGEX_PYTHON and REGEX_PYTHON patterns.
Python authors can confirm data validity and take further advantage of available type-checking methods, such as the following:
* Checks value expression and reports results as boolean:
isValidSFBool(value), isValidSFVec3f(value), isValidMFRotation(value), etc.
* Checks value expression and assets valid results, or else Fails and throws traceback:
assertValidSFBool(value), assertValidSFVec3f(value), assertValidMFRotation(value), etc.
The x3d.py python package strives to support duck typing of unambiguous values while preserving strict X3D validation of all inputs. Example tests for each case can be found in <https://www.web3d.org/x3d/stylesheets/python/examples/PythonX3dSmokeTests.py> examples/PythonX3dSmokeTests.py with corresponding outputs shown in <https://www.web3d.org/x3d/stylesheets/python/build.examples.log.txt> build.examples.log.txt
h. Update available for installation/refresh
* x3d 4.0.49
* pip install x3d==4.0.49
* <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpypi.org%2Fproject%2Fx3d%2F4.0.49&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610730103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=OgyoL%2FMwwlJ1qKSZOkKq9Q9tL6ViCoL0LO48UYz7ljk%3D&reserved=0> https://pypi.org/project/x3d/4.0.49
g. It would be helpful to have a simple example program contributed that uses both x3d.py and numpy packages, this will doubtless inform current development future testing.
Unit tests appear to be passing, I hope these changes are indeed improvements. Updated test reports welcome.
Have fun with X3D Python! 8)
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br <mailto:brutzman at nps.edu> brutzman at nps.edu
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, Navy robotics https:// <http://faculty.nps.edu/brutzman> faculty.nps.edu/brutzman
From: Brutzman, Donald (Don) (CIV)
Sent: Saturday, February 12, 2022 5:50 PM
To: Hans Moritz Guenther < <mailto:hgunther at mit.edu> hgunther at mit.edu>; Peitso, Loren (CIV) < <mailto:lepeitso at nps.edu> lepeitso at nps.edu>
Cc: rlentz < <mailto:rlentz at gmail.com> rlentz at gmail.com>; Vince Marchetti < <mailto:vmarchetti at kshell.com> vmarchetti at kshell.com>; Mike McCann < <mailto:mccann at mbari.org> mccann at mbari.org>; X3D Public Mailing List ( <mailto:x3d-public at web3d.org> x3d-public at web3d.org) < <mailto:x3d-public at web3d.org> x3d-public at web3d.org>; <mailto:brutzman at nps.edu> brutzman at nps.edu
Subject: RE: x3d.py package: Some feedback and suggestion for improvement; tuples and lists
[Cc: x3d-public list, all design discussions are open and archived]
Splitting out one issue at a time (see subject line please)
Moritz wrote:
This works:
x3d.Coordinate(point=[[0, 0, 0], (0, 1, 0), (1, 1, 0)])
This fails:
x3d.Coordinate(point=([0, 0, 0], (0, 1, 0), (1, 1, 0)))
X3DTypeError: ([0, 0, 0], (0, 1, 0), (1, 1, 0)), type=<class 'tuple'> is not a valid Python list for MFVec3f
Why not allow a tuple instead of a list here? The inner coordinates can be either tuples or lists.
I don't understand what that typechecking is good for here.
Background: X3D types include strongly typed tuples (Single Field Vector, SFVec* types) and ordered lists of those same types (Multiple Field Vector, MFVec* types)
* X3D4 Architecture, clause 5 Field type reference
* <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/fieldTypes.html> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/fieldTypes.html
further explained at
* X3D Tooltips, Type definitions
* <https://www.web3d.org/x3d/content/X3dTooltips.html#type> https://www.web3d.org/x3d/content/X3dTooltips.html#type
Not yet described in the documentation, but evident in the code, is the design decision to use python tuples for SFVec types, and python lists for MFVec types.
This remains the most logical alignment with Python data structures.
Glad to see your test case provoked an understandable error! Indeed
The intent of strictness is to avoid run-time problems that can easily arise from lackadaisical treatment of arrays. Something like your example might look obvious in an example composed of numeric data, but might be much less clear if variables are used.
Am further concerned that if mixed combinations of values are allowed, then isolation of errors within long lists might not be possible/practical if error messages remain as terse as above (or, conversely, if error messages are immensely complex).
If is conceivable we might find some cases where we can safely add support. For example, creating a new SFVec3f([1,2,3]) might be allowable.
Am thinking we should be careful on this one. Defining some simple acceptable variations that we might add to the Smoke Tests would be a good next step.
* <https://www.web3d.org/x3d/stylesheets/python/examples/PythonX3dSmokeTests.py> https://www.web3d.org/x3d/stylesheets/python/examples/PythonX3dSmokeTests.py
* <https://www.web3d.org/x3d/stylesheets/python/build.examples.log.txt> https://www.web3d.org/x3d/stylesheets/python/build.examples.log.txt
The place to put any relaxations will be in the type classes themselves, e.g. SFVec3f and MFVec3f etc.
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br <mailto:brutzman at nps.edu> brutzman at nps.edu
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, Navy robotics https:// <http://faculty.nps.edu/brutzman> faculty.nps.edu/brutzman
From: Hans Moritz Guenther < <mailto:hgunther at mit.edu> hgunther at mit.edu>
Sent: Friday, February 11, 2022 7:45 PM
To: Peitso, Loren (CIV) < <mailto:lepeitso at nps.edu> lepeitso at nps.edu>
Cc: Brutzman, Donald (Don) (CIV) < <mailto:brutzman at nps.edu> brutzman at nps.edu>; rlentz < <mailto:rlentz at gmail.com> rlentz at gmail.com>; Vince Marchetti < <mailto:vmarchetti at kshell.com> vmarchetti at kshell.com>; Mike McCann < <mailto:mccann at mbari.org> mccann at mbari.org>
Subject: Re: x3d.py package: Some feedback and suggestion for improvement
On 2/11/22 8:47 PM, Peitso, Loren (CIV) wrote:
Hans,
I have had a chat with Don and we are in full agreement that your described use case is important and would be quite useful for widening the usefulness of the x3d package. Consideration for expanding usability is to not break anything (obviously), remain Pythonic, and not add additional code constructs/constraints that require consideration of architectural changes every time something needs adding or updating. I'll propose a couple solutions by issue-raised and we can discuss debate from there.
" I need to use "x3d.x3d". That's of course possible but a little cumbersome."
Agreed on cumbersome! Have you tried import x3d.x3d as x3d_ ?
Sure (I even use import x3d.x3d as x3d). But it's not how most python packages work, stating with the standard library:
from os import chdir, not from os.os import chdir
from math import atanh, not from math.math import atanh
The same is true for common Python packages that are not part of the standard library:
import numpy as np; arr = np.ones(5), not import numpy.numpy as np
import pandas as pd, not import pandas.pandas as pd
It is of course your prerogative as package author to chose any naming scheme that seems sensible to you, but it is certainly unusual to import a package this way. It *does* make sense if you plan for more functionality in the future, e.g. if you think there could be other submodules such as
x3d.json
x3d.numpy_interface
x3d.utils
x3d.display
etc.
If that's the case, maybe a short comment in the code that explains the reasoning would be useful.
- the __init__.py file. The file is present, but not correct. It lists all the classes in __all__ but does not actually import them. Thus, that can't actually be used.
Per <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.python.org%2F3%2Ftutorial%2Fmodules.html&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610730103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=nrwdjikfEifZx55a4PlZ87QneWVAO2nzfIqnzB%2B9J9c%3D&reserved=0> https://docs.python.org/3/tutorial/modules.html, section 6.4:
"In the simplest case, __init__.py can just be an empty file, but it can also execute initialization code for the package or set the __all__variable, described later."
Per <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.python.org%2F3%2Ftutorial%2Fmodules.html&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610730103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=nrwdjikfEifZx55a4PlZ87QneWVAO2nzfIqnzB%2B9J9c%3D&reserved=0> https://docs.python.org/3/tutorial/modules.html, section 6.4.1:
"Although certain modules are designed to export only names that follow certain patterns when you use import *, it is still considered bad practice in production code."
The "not actually import(ing) them part" is working as Python intends when we provide the empty __init__.py file (per 6.4.1)
If __all__ is not defined, the statement from sound.effects import *does not import all submodules from the package sound.effects into the current namespace; it only ensures that the package sound.effects has been imported (possibly running any initialization code in __init__.py) and then imports whatever names are defined in the package.
The __all__ attribute gets initialized during the importing, but only as far as described. Thus requiring the package name prepend for fully-qualified names to properly resolve.
We have chosen the empty __init__.py file convention for simplicity, as there is no forced loading of any leading underscore names into the _all__ attribute and/or namespace by using this convention (respecting 6.4.1). This aspect is a future-proofing against having to consider if future code changes need to consider __all__ or not. With the empty __init__.py there are no potential forcing issues with respect to future code updates.
Well, you don't import anything, then there is no reason to define __all__ in the __init__ file. In that case the file should just be empty. As the paragraphs that you pasted above explain, the purpose of __all__ is to limit what gets imported when I do "from x3d import *" for example, if the following is my __init__.py:
from math import sqrt
from
__all__ = ['answer', 'MyClass']
answer = 5
class MyClass():
def calc(self, x):
return sqrt(x)
then "from xxx import *" gives me "answer" and "MyClass". Without the __all__ I would get "answer" "MyClass" and
"sqrt" i.e. everything that's available inside __init__.py. Often, that's not what we want because sqrt is nothing specific from our package. So __all__ restricts that. In the version of x3d.py that I have the __init__ files lists a whole bunch of things in the __all__, but does not import them. So why is there an __all__ at all?
However, the most common case is to selectively import things into __init__, often including things like a version string (as __version__) and the most important classes or functions that user may want in the flat namespace.
Examples from pretty standard Python packages:
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Furllib3%2Furllib3%2Fblob%2Fmain%2Fsrc%2Furllib3%2F__init__.py%23L27&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610730103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=GEG9iX3BhiLjgqnamGZ0JB7RkZPsd6DonSBmBxj7lbw%3D&reserved=0> https://github.com/urllib3/urllib3/blob/main/src/urllib3/__init__.py#L27
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpypa%2Fsetuptools%2Fblob%2Fmain%2Fsetuptools%2F__init__.py%23L24&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610730103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=3Ia6E%2B%2BxZNhQzNdFLX%2FpjHIfznga%2F%2FwST087%2BZcjX68%3D&reserved=0> https://github.com/pypa/setuptools/blob/main/setuptools/__init__.py#L24
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnumpy%2Fnumpy%2Fblob%2Fmain%2Fnumpy%2F__init__.py&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610730103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=kwTQjz7mrDG1%2BtWMOXlbtMgTGXs4H9hKOVFSLC64FCs%3D&reserved=0> https://github.com/numpy/numpy/blob/main/numpy/__init__.py
Additionally, and as indicated by the bulk of the next two paragraphs, probably more importantly: I have been burned very badly in the past, entering Imports Hell, based on using an ill-timed from xyz import * and had to explore the arcane and totally insane practice of putting import statements at the bottom of a file to partially attempt to compensate for import loading circular dependencies. Putting from x3d import * into the __init__.py file opens the door to that netherworld which awaits someone unluckily coding something that creates a circular dependency. I can't guarantee that there is zero chance of that in coding up a solution for Numpy types, or other kinds of types that may be necessary in the future. We would hate to inadvertently force a package user into that special hell.
I'm curious to learn how that works, since I've never seen a case where any other module imported anything from __init__.py Circular imports can happen and have happened to me, but never related to __init__, so I'm a little surprised. about that.
- Python usually makes heavy use of duck-typing (you can use any object as long as it behaves as you expect) instead of explicit "isinstance" checks. A lot of numerical computations in Python are done using the numpy ( <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnumpy.org%2F&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610730103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=LgxVOCqqKyzUInTq%2FisxjCwQZR2Eyp89k8GuLqGxfoE%3D&reserved=0> https://numpy.org) library, which implements array-based math and is optimized in C. Numpy has datatypes that are essentially similar to Python int but fail an isinstance checks, and I can pass those in some, but not all places in x3d.py. Here is an example that fails:
We agree that this use-case needs addressing to provide a Numpy compliant x3d.py experience. Please provide some feedback on following proposal, design goals/constraints first.
1) Yes, in the implementation code there is a point where duck-typing must become enforced typing, because the x3d module is for implementing a specified standard which has specified types.
But the specific standard is not the Python type. As I understand it the standard says "integer" not "64 bit integer in big-endian". If I'm correct, any int will do (32 bin on a 32 bit machine, 64 bit on a 64 bit machine etc.). If that's case, then there is in fact no reason at all to case e.g. a numpy int64 to a Python int - on a 64-bit machine they are identical anyway. When I output the x3d to an xml file or a json file, they will all be converted to a string anyway. Then, it's even less important what type of int they where initially, because you won't even see the difference between an int64 and an int128.
So the type checking problem is unavoidable, it just comes down to at what layer of the code does a particular type run into an unavoidable requirement to finally do the type-check for a verified per-standard-construction. The requirement has been addressed in code for the transition from basic types to the specified X3D types. We know that so far this code works, so it would be nice to not rewrite all, or even any, of that working code.
2) Users who are using native Python types as inputs should not feel any performance change when adding the necessary Numpy type use functionality to module x3d. Adding mandatory casts, or even conditionals for deciding casts, could add significant overhead if millions+ of values are processed so targeting only where the price must be paid no-matter-what is advisable.
Performance is always and important consideration. However, it seems to me that this is premature optimization. We are not the first people thinking about this and it's not a bottleneck. On my machine, "if isinstance(a, int)" is about 1 ns faster than "int(a) = a" if a is an int already (that's the case of possible performance loss, if a is not an int already, then the current implementation fails anyway).
%timeit if isinstance(a, int): pass
50.3 ns ± 0.266 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)
%timeit if int(a) == a: pass
51.4 ns ± 0.172 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)
That 1 ns is only 2% of the total runtime of the if statement and < 0.04 % of the total runtime of executing something useful where that statement matters. Here, I making the smallest IndexedFaceSet I can. If that takes 1 ns longer, that's OK. If I can afford to run a 26.3 microsecond operation a few million times, I can afford to run a 26.301 microsecond operation - the difference is within the noise of the measurement.
%timeit out = x3d.IndexedFaceSet(coord=x3d.Coordinate(point=[(0, 0, 0), (0, 1, 0), (1, 1, 0)]), coordIndex=[0, 1, 2])
26.3 µs ± 185 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)
3) There must be some other communities out there, or in the future, that will have similar type issues specific to their use-case implementation, our Numpy solution should show the way forward for those, and in implementing those future updates require as little touching of verified-correct code as possible.
Numpy by far the most important one. While counting the importance of libraries is a tricky business, in e.g. PEP 465 <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.python.org%2Fdev%2Fpeps%2Fpep-0465%2F%23but-isn-t-matrix-multiplication-a-pretty-niche-requirement&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610730103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=TYnWPaCmAD7qfI1yMWay2UaJjdGRPwXxxnyD8Vy7zCw%3D&reserved=0> https://www.python.org/dev/peps/pep-0465/#but-isn-t-matrix-multiplication-a-pretty-niche-requirement the authors found that numpy was the forth most used library - ranking far before most packages of even the standard library (only sys, os, and re and imported more often). That does not mean that there is not and won't ever be other ways to do numerics in Python ever, but it does mean the numpy is a pretty save bet.
Proposal: Adding a submodule in the x3d module which serves as the interface layer between Numpy users and x3d.py. Numpy users should only need to import their 'shim' from the x3d module (As a non-binding name example: import x3d.numpy2x3d as x3d_ I don't think I like the specific name either, but we all get the idea) and it will provide Numpy-compliant type input, do any necessary type casting on parameters, and then call working x3d.py code. It should have an equivalent call for every public API function/method in x3d.py, but only include the minimal necessary type-casting code to make the call. Once developed, well tested and verified, the long term maintenance tail of this shim file should be mostly restricted to times when Numpy makes changes to its type system (VERY rare), and if the x3d.py API gets any public additions (bugs are bugs, and that's not the tail I'm addressing here as we have the duty to kill as many as possible early.)
I think that will work - but it's not the most convenient for the user. I think the most convenient would be to iterate over any input, and don't check that the input is a list
This works:
x3d.Coordinate(point=[[0, 0, 0], (0, 1, 0), (1, 1, 0)])
This fails:
x3d.Coordinate(point=([0, 0, 0], (0, 1, 0), (1, 1, 0)))
X3DTypeError: ([0, 0, 0], (0, 1, 0), (1, 1, 0)), type=<class 'tuple'> is not a valid Python list for MFVec3f
Why not allow a tuple instead of a list here? The inner coordinates can be either tuples or lists.
I don't understand what that typechecking is good for here.
Moritz
An added benefit of this flavor of solution is that your participation is not within the autogenerated x3d.py layer, so no concerns of breaking a working x3d.py file. Writing this to be autogenerated as well is probably best practice, that way it significantly reduces eyeball-missed public API functions. Don is the expert in the auto-generation aspect. I helped him with x3d.py by describing the repeatable stylistic issues, conventions and some advantageous techniques to provide low-cost syntactic guarantees within chunks of code, he made the magic auto-happen, we debugged pairs style with him driving. Setting up the Numpy-isms is likely a very similar flavor of project, but more favorably scoped as start-type and destination-type are both going to be defined the majority of the time, your expertise will be quite valuable in this process.
I have not started coding, but I would be surprised if more than 100 line of code are needed for this.
Looking forward to seeing your thoughts. Have a great weekend!
v/r Loren
From: Hans Moritz Guenther <mailto:hgunther at mit.edu> <hgunther at mit.edu>
Date: Monday, February 7, 2022 at 7:06 AM
To: Don Brutzman <mailto:brutzman at nps.edu> <brutzman at nps.edu>, "Peitso, Loren (CIV)" <mailto:lepeitso at nps.edu> <lepeitso at nps.edu>
Subject: x3d.py package: Some feedback and suggestion for improvement
NPS WARNING: *external sender* verify before acting.
Hi,
I'm starting to use the x3d.py library to generate x3d output.
For a little bit of background, I'm an astronomer and one of the things I do is ray-tracing of the designs for new instruments. It is then very useful to have some form of output that allows me to put images of how the instrument looks and what path the photons take into presentations or on the web. As it turns out, X3D is a great format for that, see e.g. <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fspace.mit.edu%2Fhome%2Fguenther%2FARCUS%2F3Dview.html&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610730103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=R9pQbefHVGoQ25HNMrE6j8ha7nfKEOztUmZRe7jpt7M%3D&reserved=0> https://space.mit.edu/home/guenther/ARCUS/3Dview.html
In that past, I've generated the X3D output through a python package called mayavi ( <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.enthought.com%2Fmayavi%2Fmayavi%2F&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610730103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=eigxM5pQOtf2DEKROwYLBS7x3p0zrLINjUazRDvVax0%3D&reserved=0> https://docs.enthought.com/mayavi/mayavi/) but that is a rather heavy dependency for this very limited purpose. So, I'm trying to convert to use your x3d.py library instead.
I'm very much a Python programmer using what people call the "scientific stack" in Python (the libraries numpy, scipy, pandas, etc.) with very little experience in 3D visualization or web-programming. First, let me thank you for your effort to make x3d.py at all. In general it works great!
I'd like to mention a few glitches I've run into so far, and since I did not see in your package description what's the preferred way to give feedback I decided to just email you. Please let me know if you prefer me to raise those in a different forum (mailing list, sourceforge ticket ...).
I might be able to help with some of this, but since you say your package is autogenerated, there is little use for me to change the code I have; presumably all changes need to be done to the code that you use to autogenerate things.
OK, here are a few things I noticed:
- the __init__.py file. The file is present, but not correct. It lists all the classes in __all__ but does not actually import them. Thus, that can't actually be used.
In [1]: import x3d
In [2]: x3d.IndexedTriangleSet
---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)
<ipython-input-2-93a98d5f0414> in <module>
----> 1 x3d.IndexedTriangleSet
Instead, I need to use "x3d.x3d". That's of course possible but a little cumbersome.
In [4]: import x3d.x3d
x3d.py package loaded, have fun with X3D Graphics!
In [5]: x3d.x3d.IndexedTriangleSet
Out[5]: x3d.x3d.IndexedTriangleSet
I think all that's missing is the following line in the __init__.py
from x3d import *
which will import everything that's defined in x3d.py into the __init__.py namespace and than the user an get it from "import x3d" which gives you the names defined in x3d/__init__.py
- IndexTriangleSet: Coordinates are given as a list of tuples [(x1, y1, z1), (x2, y2, y3), ...]. I think that makes sense. It orders stuff in a natural way and is easy to understand. However, the index needs to be given as a flat list [ind11, ind12, ind13, ind21, ind22, ind23, ...]. Since there are three indices per triangle, I think the same list of tuples as for the coordinates would make more sense [( ind11, ind12, ind13), (ind21, ind22, ind23) ...]
- Python usually makes heavy use of duck-typing (you can use any object as long as it behaves as you expect) instead of explicit "isinstance" checks. A lot of numerical computations in Python are done using the numpy ( <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnumpy.org%2F&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610730103%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=LgxVOCqqKyzUInTq%2FisxjCwQZR2Eyp89k8GuLqGxfoE%3D&reserved=0> https://numpy.org) library, which implements array-based math and is optimized in C. Numpy has datatypes that are essentially similar to Python int but fail an isinstance checks, and I can pass those in some, but not all places in x3d.py. Here is an example that fails:
~/mambaforge/envs/kitchensink/lib/python3.10/site-packages/x3d/x3d.py in __init__(self, ccw, colorPerVertex, index, normalPerVertex, solid, color, coord, fogCoord, normal, texCoord, attrib, DEF, USE, IS, metadata, class_, id_, style_)
48191 self.ccw = ccw
48192 self.colorPerVertex = colorPerVertex
> 48193 self.index = index
48194 self.normalPerVertex = normalPerVertex
48195 self.solid = solid
~/mambaforge/envs/kitchensink/lib/python3.10/site-packages/x3d/x3d.py in index(self, index)
48230 if index is None:
48231 index = MFInt32.DEFAULT_VALUE()
> 48232 assertValidMFInt32(index)
48233 assertNonNegative('index', index)
48234 self.__index = index
~/mambaforge/envs/kitchensink/lib/python3.10/site-packages/x3d/x3d.py in assertValidMFInt32(value)
2622 if not isinstance(each, int):
2623 # print(flush=True)
-> 2624 raise X3DTypeError('MFInt32 list has contained value=' + str(each) + ' with type=' + str(type(each)) + ' which is not a valid int')
2625 if not isValidMFInt32(value):
2626 # print(flush=True)
X3DTypeError: MFInt32 list has contained value=1 with type=<class 'numpy.int64'> which is not a valid int
There is an easy workaround:
x3d.IndexedTriangleSet(index = [int(x) for x in myindex]
but it would be nice if IndexedTriangleSet accepted my numbers directly.
There are several ways of doing that, but the easiest is probably to change line 2622 to:
if not int(x) == x:
That will work for any object that can be converted to an int, including numpy, python decimal, fraction, ..
- Numpy: One might consider taking numpy arrays directly, i.e. instead of
x3d.Coordinate(point=[(x1, y1, z1), (x2, y2, y3), ...])
one could do
x3d.Coordinate(point=arr)
where arr is a (3, n) numpy array. Now, if done naively that would require numpy as a dependency to x3d.py and it's probably good to avoid that. However, there are ways to accept numpy arrays without requiring numpy. That's a little more involved, but can be done (for example using decorators or a separate module (x3d.numpy_interface) or separate package (x3d-numpy)). Not sure if it's worth the effort at this point - that depends on what your future plans for this package are and how fast this is developing.
- Changelog. From the pypi entry and the docs on <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.web3d.org%2Fx3d%2Fstylesheets%2Fpython%2Fpython.html&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610886323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=MizyC1goMdfbZ5TYbIADty6HUJ%2BVurSPuyMUfdWmnOs%3D&reserved=0> https://www.web3d.org/x3d/stylesheets/python/python.html it was not quite clear to me how stable the package is or where I would see changes listed, for example, if you do the change that I suggested above (accepting index values as tuples instead of a flat list) that would break the interface. Would you do that? Where would I find a list of changes from one version to another?
- Jupyter notebook: I'm working on a wrapper to automatically display any x3d representation in the jupyter notebook. It's only a few lines of code, and I'm happy to share (it could be integrated into the Python package x3d easily), but I want to use it a little longer for myself to make sure I have the kinks worked out so I don't pass code with major bugs to you.
Please let me know if there is anything I can do to help with this awesome package, that really makes generating X3D from Python so much simpler already.
Yours,
Moritz
--
Hans Moritz Günther
Massachusetts Institute of Technology
Kavli Institute for Astrophysics and Space Research
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F77%2BMassachusetts%2BAvenue%3Fentry%3Dgmail%26source%3Dg&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610886323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=p15QJHvTTe7AV4iLY8powKU0ygsiUenqD%2B7ySu3WFhk%3D&reserved=0> 77 Massachusetts Avenue
NE83-569
Cambridge, MA 02139
<mailto:hgunther at mit.edu> hgunther at mit.edu
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fspace.mit.edu%2Fhome%2Fguenther%2F&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610886323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=%2FDLUzYkzMAB0GCYLX3Gdzum3IXSwB8r7qp%2FaolK8plM%3D&reserved=0> https://space.mit.edu/home/guenther/
--
Hans Moritz Günther
Massachusetts Institute of Technology
Kavli Institute for Astrophysics and Space Research
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F77%2BMassachusetts%2BAvenue%3Fentry%3Dgmail%26source%3Dg&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610886323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=p15QJHvTTe7AV4iLY8powKU0ygsiUenqD%2B7ySu3WFhk%3D&reserved=0> 77 Massachusetts Avenue
NE83-569
Cambridge, MA 02139
<mailto:hgunther at mit.edu> hgunther at mit.edu
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fspace.mit.edu%2Fhome%2Fguenther%2F&data=04%7C01%7Cbrutzman%40nps.edu%7Ca9d858d0c9e94448f9eb08d9fbab6dd1%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637817536610886323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=%2FDLUzYkzMAB0GCYLX3Gdzum3IXSwB8r7qp%2FaolK8plM%3D&reserved=0> https://space.mit.edu/home/guenther/
_______________________________________________
x3d-public mailing list
<mailto:x3d-public at web3d.org> x3d-public at web3d.org
<http://web3d.org/mailman/listinfo/x3d-public_web3d.org> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
_______________________________________________
x3d-public mailing list
<mailto:x3d-public at web3d.org> x3d-public at web3d.org
<http://web3d.org/mailman/listinfo/x3d-public_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/20220302/af8bdd34/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5353 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220302/af8bdd34/attachment-0001.p7s>
More information about the x3d-public
mailing list