PythonNet VS dataenforce

I looked into using .NET as a "backend" and the pythonnet library to bridge the gap, but unfortunately that library does not support async. To properly support it would require some kind of integration with the asyncio event loop APIs or implement the AbstractEventLoop interface and some how make it thread-safe - not even sure that's possible with the API design of asyncio itself.

If you're running the python within C# using Python.NET, then you're somewhat within-process and there are ways of sending the data across. (Return objects, channel/queues, whatever fits your use case.)

I was going to make a joke about Python .NET core .. but .. apparently it's a real thing.

I am not set on .NET, but just curious, so thanks for the suggestions. Interesting that it's billed as cross-plaform, but doesn't do it that well. I just searched 'python wrapper for .net' and found PythonNET. Also, it seems yes IronPython is active.

I created a Django based python project that interfaces to TIA Openness to create some Remote IO. To do this I use the pythonnet library. so that I can load the Openness DLL.

Any .NET language with https://github.com/pythonnet/pythonnet

The dependence on library authors is always a challenge in any language. You might have one author using `[a]` where another uses `PositiveNumeric a, Fin n => NonEmptyList n a` for the same thing. You can always just annotate whatever the library author used (e.g. they return a list of strings, so you use List[str]).

There are some interesting further add ons that seem very python, allowing you to go further. For example, with a pandas dataframe you can just say your type is a dataframe which isn't so useful, but it's possible to hack your own types onto it in the vein of https://github.com/CedricFR/dataenforce, or use things like https://smarie.github.io/python-vtypes/ to get smarter typing on things the authors didn't type. I expect that trend will continue.

What fascinates me about python's types is actually the very fact that they are bolted on. You have a language that lets you do crazy things and a type system trying to catch up and make it convenient to verify those crazy things. It's a nice complement to the usual developments of verifying all of the things and slowly extending the set of things you can do.

https://github.com/CedricFR/dataenforce enforces column names and types, no versioning though. My first instinct is that important data should be stored in databases which enforce schemas, and that should be separate from the python code that reads it.