CPython: pyrevit.forms WPF/XAML support (PythonNet3)

[OriAshkenazi]

TL;DR (decision needed)

CPython scripts (#! python3) currently cannot use pyrevit.forms (the module hard-fails at import time and depends on the IronPython-only wpf/XAML stack).

Please reply:

1. A or B for the path forward:
   • A) UI broker/proxy (Effort 1): make the existing pyrevit.forms implementation callable from CPython
   • B) Native pythonnet WPF/XAML support (Effort 2): implement/drive upstream support so CPython can run WPF natively
2. If you agree with (A), can I open a small Stage 0 PR immediately (import works + actionable exceptions), then follow with the broker?
3. Definition check: for this issue, does "CPython forms support" require:
   • (a) parity for the existing pyrevit.forms API (built-in dialogs/windows), OR
   • (b) also parity for CPython-authored WPFWindow + custom XAML event handlers?

Context

• CPython scripts currently cannot import pyrevit.forms because pyrevitlib/pyrevit/forms/__init__.py raises PyRevitCPythonNotSupported("pyrevit.forms").
• This is called out as a key missing piece for CPython in pyRevit 5 WIP (see @sanzoghenzo in Modernizing Python Runtimes #2124): Modernizing Python Runtimes #2124 (comment)
• In PR PyRevitRunner: honor cpython hashbang #3029 discussion, @sanzoghenzo pointed to the long-running CPython+WPF effort and mentioned possible internal pythonnet patches (McNeel/Dynamo), suggesting we coordinate/nudge upstream rather than reinvent the wheel:
  • PyRevitRunner: honor cpython hashbang #3029 (comment)
  • https://discourse.pyrevitlabs.io/t/pyrevit-cpython-wpf-support-saga/8394

Goal

• A CPython script can do from pyrevit import forms and call the same pyrevit.forms API that works today under IronPython.
• If the chosen path is the UI broker (Effort 1), CPython should be able to invoke the existing IronPython/WPF implementation and get structured results back (and interact with returned window objects via proxies).

Proposed plan (2 main efforts)

Effort 1 (recommended near-term): UI broker/proxy so CPython calls the existing IronPython/WPF implementation

This follows the "known good" practice: keep the existing WPF implementation as the source of truth, and have CPython proxy calls into it.

Effort 1 is best done in stages. Stage 0 matches the first "prep" idea discussed in the PR #3029 thread (my comment):

• PyRevitRunner: honor cpython hashbang #3029 (comment)

Stage 0 (small PR): make import pyrevit.forms work under CPython

• Remove the import-time hard guard in pyrevitlib/pyrevit/forms/__init__.py (do not raise on not IRONPY).
• Isolate IronPython-only imports (wpf, Autodesk UI modules, etc.) so CPython can import without immediately failing.
• Keep UI functionality IronPython-only for now (raise an actionable exception on call under CPython) until the broker is in place.
• Add a minimal CPython DevTools smoke command that:
  • imports pyrevit.forms, and
  • verifies at least one representative UI entrypoint fails with a clear "not yet supported under CPython; see this issue" message (instead of ImportError/AttributeError).

Stage 1+ (broker): make the full API callable from CPython by proxying to the IronPython/WPF implementation

1. Turn pyrevitlib/pyrevit/forms/__init__.py into an engine-agnostic facade

   • Move the current IronPython/WPF implementation into an IronPython-only module (e.g. pyrevitlib/pyrevit/forms/_ipy_forms.py) without changing IronPython behavior.
   • In __init__.py, dispatch:
     • IronPython (IRONPY=True) -> re-export from _ipy_forms.
     • CPython (IRONPY=False) -> re-export from a proxy module _cpy_forms_proxy.

2. Add a broker entrypoint on the .NET side (so both engines can reach it)

   Proposed boundary:

   string Invoke(string requestJson); // returns responseJson

   Notes/constraints:

   • JSON alone can not carry live Revit/.NET objects (Elements, UIApplication, WPF objects, delegates).
   • Plan: use an object-handle registry in the broker/handler for any non-JSON-serializable value. Requests/responses pass { kind: "handle", id: "..." } for those values.
   • Keep a strict allowlist of callable functions/methods and validate payloads to avoid turning this into "remote eval".
   • Execute UI actions on the Revit UI thread (Dispatcher/ExternalEvent) and return structured errors.

3. Implement the IronPython handler (execute real pyrevit.forms calls)

   • Import and execute the existing IronPython/WPF implementation.
   • Support:
     • function calls by name + args/kwargs
     • object lifecycle for WPF windows (create -> return handle id; later calls via handle id)
   • Definition check tie-in: if maintainers want CPython-authored WPFWindow + event handlers parity, this also needs a callback story (UI events firing in IronPython invoking CPython callbacks through a safe, explicit bridge). Otherwise, initial scope can be: "CPython can call the built-in forms API, including windows created by that API".

4. Implement the CPython proxy module

   • pyrevitlib/pyrevit/forms/_cpy_forms_proxy.py provides the same API surface, but each call serializes a request (name/args/kwargs) to the broker and deserializes the response.
   • For returned WPF objects, return lightweight Python proxy objects that forward method/property calls back to the broker using the handle id.

5. Add a small DevTools end-to-end smoke command

   • Add a CPython command under extensions/pyRevitDevTools.extension that exercises representative calls end-to-end (alert/select list + at least one WPFWindow-based dialog that is part of pyrevit.forms).

Effort 2 (larger + upstream dependent): native CPython WPF/XAML support

Summary of what we know so far (Discourse saga + repo references):

• In WIP pyRevit, pythonnet was updated to v3, which improves CPython integration but still has no WPF support out-of-the-box. In the saga thread, @sanzoghenzo documented an attempted path to make pyrevit.forms work under CPython by tackling the wpf.LoadComponent gap.
• Removing the IRONPY guard in pyrevitlib/pyrevit/forms/__init__.py quickly hits:
  • Autodesk-only imports (Autodesk.Windows.ComponentManager) used by forms.show_balloon.
  • The core blocker: wpf is None under CPython because pyrevitlib/pyrevit/framework.py only loads the IronPython wpf module when IRONPY is true. WPFWindow.load_xaml relies on wpf.LoadComponent.
• The thread highlights that LoadComponent is effectively the key missing primitive: under IronPython it comes from IronPython.Wpf and uses the DLR DynamicXamlReader + DynamicOperations to:
  • populate x:Name fields on the Python window instance
  • hook up XAML event handlers
  • reference implementation lives in this repo under dev/modules/pyRevitLabs.ironpython3/Src/DLR/Src/Microsoft.Dynamic/Xaml/DynamicXamlReader.cs (depends on DLR dynamic ops that pythonnet does not provide)
• An attempted Python port of DynamicXamlReader using System.Xaml (XamlXmlReader, XamlObjectWriter, custom XamlMemberInvoker) got further but failed early when loading pyrevitlib/pyrevit/forms/GetValueWindow.xaml with:
  • Set property "System.Windows.Window.ShowInTaskbar" threw an exception
    This suggests additional WPF/XAML loading semantics need to be replicated correctly (property setting, root instance handling, name scopes, event binding, etc.).
• @sanzoghenzo shared a WIP branch with the refactor/experiments: https://github.com/sanzoghenzo/pyRevit/tree/forms-refactor
• The repo also includes pythonnet WPF demos (not pyRevit-integrated) such as dev/modules/pyRevitLabs.Python.Net/demo/DynamicGrid.py that load XAML via System.Windows.Markup.XamlReader.Load on an STA thread.
• I did not find any repo-local pointers to the mentioned "McNeel/Dynamo pythonnet WPF patches" beyond @sanzoghenzo's note in the PR PyRevitRunner: honor cpython hashbang #3029 thread; no first-party code/docs/issues in this repo reference those patches explicitly.
• Quote for context (from @sanzoghenzo in the PR PyRevitRunner: honor cpython hashbang #3029 thread): "Ehsan (@eirannejad) told us about pythonnet patches made internally by mcneel, same thing by dynamo guys, I don't know if any of it reach upstream..."

Given the above, Effort 2 likely depends on upstream/downstream pythonnet work. Before investing heavily, it would help to identify:

• Is there an upstream pythonnet issue/branch for WPF/XAML parity?
• Are McNeel/Dynamo patches published, and can they be upstreamed/adopted?

Next step after decision

• If maintainers prefer (A), I can start with Stage 0 immediately, then follow with the facade + broker skeleton and a small CPython DevTools end-to-end smoke test.
• If maintainers prefer (B), I can help track down the relevant upstream pythonnet work/pointers first (issues/branches/patches), before starting a large in-repo WPF implementation.

[sanzoghenzo]

Ehsan told us about the McNeel patches (still unreleased to the public) during a virtual meeting, but not much info to work on;

I cannot pinpoint where the dynamo team declared that there were some patches/internal libraries that solve some of the upstream python.net issues, and it can be that they already sent them upstream, I didn't check it.
But I can point you to this blog post, especially the "WPF" section, and the more updated post, section "The UI with WPF".

Judging from these articles, it seems that we can make things work right away by changing the current classes:

1. OK to move the current forms to _ipy_forms and conditionally import it in forms
2. duplicate _ipy_forms to _cpy_forms and edit the classes as explained by the articles.
3. drop the import guard

I also would like to see the reorganization of the forms module in a subpackage as I did in my branch, but it's just my OCD talking 😅

[jmcouffin]

• agreed on the forms module org, it feels like such a huge chunk of code... It would need to be backward compatible while doing the refactoring
• not sure this help, but the is the dspythonnet3 package (as in dynamo package) available https://github.com/DynamoDS/PythonNet3Engine

[OriAshkenazi]

@sanzoghenzo @jmcouffin thanks for the pointers and the concrete suggestion(s).

I read both Dynamo posts (especially the WPF sections):

• https://dynamobim.org/pythonnet3-a-new-dynamo-python-to-fix-everything/ (section "WPF")
• https://dynamobim.org/dynamo-pythonnet3-upgrade-a-practical-guide-to-migrating-your-dynamo-graphs/ (section "The UI with WPF")

Also, the public DSPythonNet3 engine repo is helpful context:

• https://github.com/DynamoDS/PythonNet3Engine
  • It packages the engine Dynamo ships, and (at least today) consumes Autodesk.pythonnet 3.1.1-preview* + Python.Included 3.11.6.
  • I did not find any WPF/XAML helper layer in that repo itself (no XamlReader / PresentationFramework / LogicalTreeHelper / wpf usage when searching), but it still gives us a concrete reference for the PythonNet3 stack/versioning used in production by Dynamo.

My updated take: Effort 2 is a lot more actionable than I originally framed it. Dynamo is documenting a workable PythonNet3-native WPF pattern that does not depend on unreleased "McNeel patches", and may not require any special engine changes beyond what we already have with pythonnet v3.

Key constraints from the articles (important for pyRevit):

• There is no wpf helper module equivalent to IronPython's IronPython.Wpf.
• XAML event handlers (e.g. Click="...") can not be bound directly in XAML. The recommended pattern is:
  • set x:Name="..." on elements, then
  • wire events in code via LogicalTreeHelper.FindLogicalNode(...) (or FindName(...)).
• XAML is loaded via System.Windows.Markup.XamlReader.Load(...) from an XmlReader / StringReader.
• In the example they "merge" the XAML-created Window instance with a Python class by assigning window.__class__ = MyWindow, then do the wiring in __init__.
• Threading note: they only need Application.Current.Dispatcher.Invoke(...) in Dynamo Sandbox; inside Revit they claim you're already on the right UI thread (this matches pyRevit's typical command execution model).

So I think the plan should change like this:

• Step 1: reorganize pyrevit.forms (strictly backward compatible)

  • Move the current IronPython implementation to _ipy_forms (no behavior changes for IronPython users).
  • Make pyrevit.forms an engine-agnostic facade that re-exports _ipy_forms on IronPython.
  • Drop the import guard so import pyrevit.forms works under CPython.
  • Under CPython, keep UI calls raising actionable "not supported yet" errors until the PoC wiring lands (avoid ImportError/AttributeError).
  • Avoid a long-lived full _cpy_forms clone if possible: keep most of pyrevit.forms shared, and isolate only the engine-specific XAML/WPF loading + event wiring behind a small backend module.

• Step 2: Effort 2 PoC (inside Revit): validate the Dynamo PythonNet3 WPF approach against pyRevit's existing XAML

  • Implement the CPython XAML/WPF backend using the Dynamo approach (XamlReader.Load(...) + __class__ assignment).
  • Decide how to handle existing XAML event attributes (e.g. Click="select", TextChanged="..." in GetValueWindow.xaml):
    • Option A: strip event attributes before load, then re-attach handlers after load using x:Name + getattr(self, handler_name).
    • Option B: refactor the first window to follow the Dynamo pattern (no event binding in XAML; only code wiring).
  • Make one representative window work end-to-end under CPython (suggested first target: GetValueWindow.xaml).
  • Write up what changes are needed to scale (XAML preprocessing vs window refactors, limitations, etc.).

• Step 3: if the PoC scales, expand coverage across the built-in pyrevit.forms surface (more dialogs/windows) while keeping IronPython behavior unchanged.

Separate note (not part of the plan): earlier we discussed a UI broker/proxy approach (CPython calling the IronPython/WPF implementation). I'm intentionally parking that for now and focusing on the native PythonNet3 WPF path described in the Dynamo posts.

If you're OK with this direction, can I:

1. open the Step 1 PR (module refactor + drop guard + keep IronPython behavior unchanged), and
2. immediately follow with the GetValueWindow.xaml PoC and report back what changes are required (XAML preprocessing vs window refactors) before touching more of the surface area?

Project tracking (optional): if you're using pyRevit's Future to plan pyRevit5 work, can a maintainer add #3033 there?

[jmcouffin]

• Sounds good
• As for the project tracking, that's ok. It is not as if we had that many contributors or major refactoring going on

[OriAshkenazi]

Update: PR1 (facade refactor + CPython import/error-contract) is up for review.

• PR: PR1: forms facade + IronPython backend extraction + CPython stubs #3039
• Scope (PR1 only):
  • Extract existing IronPython implementation into pyrevitlib/pyrevit/forms/_ipy_forms.py (intended behavior-identical).
  • Add lightweight pyrevit.forms facade that routes by pyrevit.compat.IRONPY (facade stays free of WPF/clr imports).
  • Add CPython stub backend pyrevitlib/pyrevit/forms/_cpy_forms.py so import pyrevit.forms succeeds under CPython.
  • Enforce CPython contract: unsupported symbols raise PyRevitCPythonNotSupported("pyrevit.forms.<symbol>") (not ImportError / AttributeError).
  • Update DevTools CPython regression test to validate the PR1 contract (no dialogs invoked).
  • Fix output.print_md under CPython (Revit-hosted sys.stdout is ScriptIO with Flush() rather than flush()).
  • Document the facade/backend split + CPython contract in docs/architecture.md.

Validation (Revit 2025):

• CPython: pyRevitDevTools → Debug → Engine Tests → Test CPython Regressions (passes).
• IronPython: pyRevitDevTools → Debug → Unit Tests → Forms Module Tests (no regressions observed).

Contributing while PR1 is open:

• Please avoid adding new commits to the PR1 branch unless requested during review.
• Follow-up work (PR2+) should go on separate branches. If it depends on this refactor, branch off the PR1 branch and keep it stacked/draft until PR1 merges, then rebase onto develop.

Once PR1 is approved/merged, next step is PR2: CPython WPF/XAML PoC inside Revit (first target still GetValueWindow.xaml) without changing IronPython behavior.

[jmcouffin]

PR1 is good to go.
Proceed with PR2 ;p

[tay0thman]

I was able to get WPF to work with cpython in Rhino using Eto.forms. it is a wpf wrapper where everything is done on your mainscript. no xaml.

[jmcouffin]

PR2: CPython WPF/XAML PoC inside Revit (first target still GetValueWindow.xaml) without changing IronPython behavior.

@OriAshkenazi 👋