Pure python tools

[gswifort]

Hi, as I understand it, PyRx primarily maps C++ functions to python.
How do you feel about adding tools written in pure Python to make working with C++ functions easier?
I mean, for example, this boilerplate code:

from pyrx_imp import Db

db = Db.curDb()

for id in db.objectIds(Db.Text.desc()):
    text = Db.Text(id)
    print(text.textString())

For example, you can create a function:

def get_objects(
    container: Db.Database | Db.BlockTableRecord | Db.Group | Ed.SelectionSet,
    object_type: Db.Entity,
):
    for id in container.objectIds(object_type.desc()):
        yield object_type(id)

which can be used as below:

for text in get_objects(db, Db.Text):
    print(text.textString())

Additionally, this will make it easier to debug the code, C++ exceptions are often incomprehensible at first glance, and extending the get_objects function with type checking etc. will make debugging much easier for beginners

[CEXT-Dan]

I think it’s great! It’s only natural to want to extend wrappers with syntax that’s more fitting to Python.

My original thoughts were to use similar syntax as ObjectARX, easy to port projects, use the documentation.
I.e. for additional help on Ed.Core.coordFromPixelToWorld, just copy&paste *coordFromPixelToWorld in Autodesk help…
https://help.autodesk.com/view/OARX/2024/ENU/?query=*coordFromPixelToWorld

Regarding exceptions, they currently include the things I need for support. Error code, Line number, function, and file. From here, I know exactly where to debug from in C++.

But yeah, I would fully expect Python users to want to add cool layers of abstraction on top. It’s better not done by me, as I’ve already been accused of having a C++ bias lol.

I haven’t thought much about library contributions, I guess I would have to make some guidelines. I.e. Unit tests and documentation

[CEXT-Dan]

On the surface that seems fine, but when I think about it, it could quickly become a support nightmare

[gswifort]

Maybe in order not to close ourselves off (the need to change imports), we should adopt this structure for now:

repo/
├── pyrx/
│   └── ... # python modules
└── pyrx-core/
    ├── Bin/
    │   └── ...
    ├── Stubs/
    │   └── ...
    └── activex/
        └── ...

For now, it would be two packages, but distributed together, later we could think about separating them.

[CEXT-Dan]

I don’t understand

[gswifort]

In your repository, in addition to the current directories and files, there would be two directories:

• pyrx
• pyrx_core
  The pyrx_core package would contain everything that I currently put here
  i.e. the Bin directory with ARX modules, the Stubs directory with stub files for ARX and the activex directory with .py and .pyi files for ActiveX.

The pyrx package would contain all the python tools.
An example module in pyrx would look like this:

from pyrx_core import Db

def do_anything_with_db(db: Db.Database):
    ...

Currently, both directories would be in the same repository and distributed in PyPI under the name pyrx, but when the user installs pip install pyrx, two packages will be installed in the site-packages directory - pyrx and pyrx_core. Just like when installing pywin32 - win32, win32com, win32comext etc. are installed in site-packages.
Later, when pyrx_core is already well developed and the only changes will be changes resulting from new versions of Autocad etc. and bugs - it will be possible to separate these two packages into two repositories, but pyrx would have pyrx_core as a dependency.

What's the point of all this?
I imagine the Python package pyrx will be in development for much longer than pyrx_core.
If someone creates a project based on pyrx 1.1.0, they may not be ready for the changes introduced in newer versions, and at the same time they may want to update their project to work with the new version of Autocad.
If both of these packages were distributed under one version, someone who wanted to run their project on a new version of Autocad would have to take into account all the changes occurring in the Python packages.

In my opinion, as long as everything is in one repository, it doesn't matter for maintenance whether it's two packages or one.

[CEXT-Dan]

No, I don’t want separate packages. It should be tested, packaged, and supported as a single version.

[CEXT-Dan]

ARX and ActiveX

I you look at the API in the aggregate, it contains both native and ActiveX,
SheetSets, ETransmit, Properties, Standards Manager, DesignCenter etc.
Wrapping ActiveX in C++ is not fun at all, while generators for the most part are pretty good, so I will leverage those when I can.
There may be a future where the ARX side calls a Python wrapper and vice versa
Point is, PyRx-Core API is combination of both ARX and ActiveX.

Just a thought, but pyrx-core/ could just include everything that’s core related.
Or have pyrx-core/Bin and pyrx-core/stubs