Author Topic: Python Automation Interface - EA.Interop Development - alpha project  (Read 747 times)

Andrew Mitchell

  • EA Novice
  • *
  • Posts: 11
  • Karma: +1/-0
    • View Profile
We are in the middle of the process of developing a Python module that exposes a portion of the EA Automation Interface.

We are publishing early alpha code (this can be found at: https://github.com/boro-alpha/ea_interop_service.git) to invite comments, so we can learn from the community. We will incorporate any good advice into later versions of the code.

This is an early version, so we would advise caution when using it.

We have developed this on the basis of the suggestion in https://sparxsystems.com/forums/smf/index.php?topic=3953.0.

We are hoping this will help people attempting to connect to the EA Automation Interface using Python - that they will now have access to more resources than we did.

We grew up using the C# dll: Interop.EA.dll and found the IntelliSense feature invaluable for quick code development.  When we started coding in Python, we found the the raw technique of connecting as a win32com client every time slowed things down. We built on the suggestion above by exposing the Automation Interface so that PyCharmís code completion has something to work with (so similar to C#'s IntelliSense).  This has sped up our coding time - we hope others will find it as useful.

Any feedback would be welcome.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 11315
  • Karma: +422/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Python Automation Interface - EA.Interop Development - alpha project
« Reply #1 on: November 12, 2020, 11:44:12 pm »
Any reason why you are changing all the operations name (e.g. get_connector_by_id() that calls GetConnectorByID())

That might make moving to this library harder then it could be.

Geert

Andrew Mitchell

  • EA Novice
  • *
  • Posts: 11
  • Karma: +1/-0
    • View Profile
Re: Python Automation Interface - EA.Interop Development - alpha project
« Reply #2 on: November 13, 2020, 02:02:17 am »
Hi Geert,
Thanks for the very quick reply.  This is exactly the feedback we were after.
The reason we went this direction is that it follows the Python style guide (https://www.python.org/dev/peps/pep-0008/#function-and-variable-names).  Although the code is small enough that it is not too late late to change.
When coming up with coding styles for our team to use we have found many contradictoy guidance and it is a balance to develop an in-house style.  e.g. Python's PEP8, Robert Martin's Clean Code, C# Coding Conventions.  You have now given us new guidance to think about.
p.s. we could have a facade that has the original calls, but this will contravene PEP8, but at least this isolates the issue.
Andy

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 11315
  • Karma: +422/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Python Automation Interface - EA.Interop Development - alpha project
« Reply #3 on: November 13, 2020, 02:48:44 am »
I guess it depends on what you are aiming for.

If your goal is to provide a mirror of the EA API, but for python users, I would be inclined to follow the existing API names (so CamelCase)

You could argue that this exception applies
Quote
mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility.

If on the other hand you are aiming for an enhanced API that is a different story. I did that in C# and based it on the UML meta model:https://github.com/GeertBellekens/Enterprise-Architect-Add-in-Framework
I try to hide the simple EA API object as much as possible and instead provide a much richer, functional API for my add-ins.

Geert

Andrew Mitchell

  • EA Novice
  • *
  • Posts: 11
  • Karma: +1/-0
    • View Profile
Re: Python Automation Interface - EA.Interop Development - alpha project
« Reply #4 on: November 13, 2020, 08:26:51 pm »
Hi Geert,
This looks really good.  We are in the process of writing a wrapper to this project that hides the simple API and as you say creating an enhanced API for our specific needs.  It would be good hide the simple API in its own project with the original names (to help porting).  I will pass this back to the team.
Many thanks again,
Andy