NXOpen Python Binding Quirks in Batch: Parts.New Doesn't Exist, and Other Surprises

Facts that cost time when writing NXOpen Python for headless (run_journal) sessions, verified live against NX 2606.

Creating a new part: no Parts.New in Python

session.Parts.New(path, units) — the signature .NET code and older examples suggest — does not exist in the Python binding. dir(session.Parts) on NX 2606 shows NewBase, NewBaseDisplay, NewDisplay, FileNew (and no New). What works headless:

part = session.Parts.NewDisplay(path, NXOpen.Part.Units.Millimeters)

NewDisplay works fine in batch despite the name (batch skips rendering; the "display part" concept still functions logically). NewBase exists but threw with the same argument pattern in testing; the FileNew builder is the journal-recorded route and also works. If a part with the same leaf name is already loaded in the session, creation fails with NXException: File already exists even when the file is absent on disk — check session.Parts first.

Detecting batch, and the theSession convention

• session.IsBatch is a real property — use it to branch UI-vs-batch code.
• Recorded journals reference theSession, theUFSession etc. If you embed recorded code into a hosted namespace (an exec-based dispatcher), pre-bind those aliases so recorded code pastes in unchanged.

Introspect live instead of guessing signatures

The .pyd docstrings carry the actual signatures and parameter docs, including deprecation notices. When a call errors or an API name is uncertain, dir(obj) and print(obj.__doc__) inside the session answer it in seconds — e.g. ufs.Disp.BatchShade.__doc__ yields "BatchShade(filename, xSize, ySize, method)" plus ".. deprecated:: NX2406" and the parameter list. This beats guessing from .NET documentation, which does not always match the Python surface.

The embedded interpreter is sealed — plan for stdlib-only

NX 2606 embeds CPython 3.12.13 (NXBIN\python\python312.dll) with no python.exe and no pip; the stdlib lives in Python312.zip. Journal code and anything it imports must be standard-library-only, unless you repoint UGII_PYTHON_HOME/UGII_PYTHON_DLL at your own matching Python 3.12 install (the sanctioned way to get numpy et al. into journals). A socket server, JSON, gzip, and subprocess are all available — enough for substantial in-session tooling without any of that.

Parametric edits in batch: expressions + explicit update

wp = session.Parts.Work
try:
    expr = next(e for e in wp.Expressions if e.Name == "width")
    wp.Expressions.Edit(expr, "120")
except StopIteration:
    wp.Expressions.Create("width=120")
mark = session.SetUndoMark(NXOpen.Session.MarkVisibility.Invisible, "edit")
session.UpdateManager.DoUpdate(mark)

DoUpdate wants an undo-mark id; creating an invisible mark inline is the batch-friendly pattern (there is no dialog to own the update).

Six .pyd files are not importable — by design

NXOpen_CLDMfgModel/CLDReport/CLDSnapshots/Capital/Mfg_AM/Mfg_Mlp.pyd fail with ImportError: dynamic module does not define module export function. They are support DLLs shipped alongside the real bindings, not API modules — skip them when enumerating NXOpen*.pyd programmatically. The other 107 modules import cleanly in batch (CAM, CAE, Mechatronics, Routing, Drafting, Annotations, ShipDesign, ... all included).