Why are modules generated from C++ prefixed with "Py"?

[rdesparbes]

I was wondering what is the motivation for prefixing the Python modules generated from C++ with Py ? (PyDb, PyAx...)
The first thing that is done when loading those modules from Python is giving them an alias without this prefix.

Why not directly generating the Python module directly with their final name?

It would:

• Simplify the stubs generation, as the pyrx.doc_utils.rx_meta.PyRxModule would not be needed anymore
• Remove some tests as a consequence
• Simplify all the occurrences of import PyModule as Module to import Module

[CEXT-Dan]

Mostly ignorance, but then to differentiate between the “Ac” prefix. I think the first class I wrote was wrapper around AcRxObject, PyRxObject seemed cool at the time.

When programming in Arx, I think of AcDb, AcGe etc, as a namespaces, so PyDb and PyGe was born.

Having spent time programming in .NET and having to use obnoxiously long spaces i.e
Autodesk.AutoCAD.ApplicationServices.Application.DocumentManager.MdiActiveDocument.Editor.WriteMessage

Even typing PyDb everywhere seemed to be a bit long, so I started adding aliases, those aliases eventually made there way into import pyrx

Having said that, I considered PyDb to be the actual name, the aliases is a convenience. It’s my understanding that everything outside import pryx is an alias

[CEXT-Dan]

More background;

I had never written a line of Python in my life before starting this project. My goal was only to make a better scripting interface for AutoCAD. Originally, I had started extending AutoLISP, but then I found a breaking bug in AutoCAD’s OARX <-> AutoLISP interface that made this impossible.

I had been watching a previous attempt from MickD at the swamp to embed Python into ARX, codenamed PyArx.
https://www.theswamp.org/index.php?topic=24262.0

Python fit the bill perfectly, I could interface with it directly, unlike lisp, it had deterministic garbage collection, unlike .NET.

The next issue was scale. I had posted a link to PyAcad (another Py prefix) https://pyacad.sourceforge.net/ for Mick to check out, he had been considering SWIG.

I had played with the results of SWIG from ODA https://www.opendesign.com/files/white-papers/ODA%20SWIG%20Wrappers.pdf
verses ODA Classic wrappers and AutoCAD’s wrappers for .NET

it was clear that in order for the project to be “Juicy and Delicious”, it had to be hand rolled with love. I hand rolled a prototype with PyAcad, but it quickly became clear that I could not finish the task in my lifetime

The choices at that point we PyBind11 (Again with the Py) and boost::python, after a bit more prototyping, boost was my choice as it was x4 faster.

By the time anyone with actual Python experience took interest, I was already 150,000 lines of code in. The first stub generator was a monumental catastrophe, Grzegorz has been cleaning up ever since.

[CEXT-Dan]

I don’t have a problem dropping the Py. It’s a bit of a chore, mostly just a lot of find and replace. The C++ classes internally will still need to be prefixed with Py

[CEXT-Dan]

Oh, I thought they were changes in from python’s perspective, I could not load any modules but I could import Ed , Db in the command line

[CEXT-Dan]

I missed changing the macros, I’ll make a new build

[CEXT-Dan]

committed a new build

[CEXT-Dan]

pyrx.Db

you mean like pyrx.Ge.Point3d(0,0,0) each time I need a point?
IMHO, that's too verbose

[rdesparbes]

No, when I wrote pyrx.Db, it was only a way to indicate where the real python module should be located in the Python tree. Right now, its real location is simply PyDb, and it is remapped to pyrx.Db using an alias in pyrx/__init__.py.

For the end user, it would not change anything, they would still write:

from pyrx import Ge

Ge.Point3d(0, 0, 0)

or

from pyrx.Ge import Point3d

Point3d(0, 0, 0)

[CEXT-Dan]

I think this branch (Task285) is now too far out of date, I messed you up by adding in ton of signatures; we will get into merge hell. I also forgot to do the return types. I propose to delete it and get it done in main when we’re ready to knock it out

[rdesparbes]

Yes, I agree to remove this branch. I tried to make it work, but couldn't.
On this branch, I was expecting to be able to import Ap directly, be it did not work.

And after some thought, I am not even sure if it is worth the change anymore.

[CEXT-Dan]

Ok, I think we can try again at some time later, I tried to give you an updated build, but I have already changed to C++ projects quite a bit