Announcement
Bob Kuszewski · Oct 28

Start learning about Embedded Python!

Welcome to day 3 of Virtual Summit 2021!  We have incredible content available to you this year and I'd just like to bring your attention to the 4(!) sessions that we have on Embedded Python.

 

50
3 3 13 242
Log in or sign up to continue

I just finished watching the first two videos and wow, wow, wow!!

I'll be honest, I hadn't followed the prior python interoperability work in IRIS because it always seemed to me to be more of a way to allow Python developers to get access to data and logic inside of InterSystems IRIS, and since I am already comfortable working natively inside of IRIS with ObjectScript, that didn't have any appeal to me (why would I want to learn Python in order to call into IRIS when I can already do what I need inside of IRIS?)  However, I was happy for those who already knew Python but didn't want to learn ObjectScript to have tools to reach fetch data out of IRIS, etc.

However, Embedded Python is not at all what I expected (true confession!)  With Embedded Python it looks like there is no reason for me to write Python code or work within Python in order to bring value into my IRIS-based applications running all of their business logic in ObjectScript.  I can leverage 10s of thousands of python modules (ref: https://www.quora.com/Is-there-a-comprehensive-list-of-Python-libraries) without writing a single line of Python code!  This immediately makes available all sorts of calculation, integration and translation packages which I would have had to write and maintain myself in ObjectScript or access via a more complicated self-built bridge into a Python runtime environment).  This is REALLY powerful and ATTRACTIVE to me as an ObjectScript developer, setting with an extraordinarily low bar to start using it (I only need to figure out management of .py files as part of my CICD).  I had no idea that Embedded Python would be so immediately relevant to me as an ObjectScript developer!

I think the best analogy I can come up with is the complementary power of ObjectScript and SQL which I rely on every day.  No one would want to use ObjectScript without the various ways of executing SQL from within the environment.  You could do it (iterate through objects / globals to fetch the data elements that you want) but why would you want to when you have the power and elegance of SQL to simplify data access for you?  I see Embedded Python as having the potential to be just as powerful as SQL within my ObjectScript application, but exposing *reusable logic* to me, rather than exposing *data*.  Leveraged properly, Embedded Python has the promise of drastically cutting down what I need to implement myself in ObjectScript ... if I can find a Python library that already does what I want, then I can wrap that in a couple lines of ObjectScript and start using it immediately.  That is so incredibly powerful.

Thank you @Bob Kuszewski  and team for bringing this new feature into InterSystems IRIS - I look forward to seeing how we can use it to make ObjectScript-based application development even faster than before!

Agreed - this feels like the biggest gamechanger among Virtual Summit announcements since we've called it Virtual (or Global) Summit.

I do agree Tim!!

I followed the first 3 sessions and just can strongly recommend following it.
To my opinion, it is MUST to follow them for anyone developing in IRIS in the future.

@Robert Cemper - I agree on the strong recommendation!  

I am curious, why do you see Embedded Python as central for all IRIS developers?

In past, I have seen so many "re-invented wheels" on COS that were mostly kind of remakes of
existing packages or solutions. Though this is impressive from a coding point of view,
it is just a waste of energy from point of view of a project AND its maintenance.

I had similar experiences with SQL that was refused by "experienced" programmers
insisting on horrible $ORDER() / $QUERY() constructs almost un-supportable, to gain
a few microseconds of performance on a weekly report. 

The deeper reason: nobody explained it and trained them.
That's the behaviour to avoid. 

So you are saying that in order to Embedded Python to be able to be appropriately leveraged in places where it should be leveraged alongside ObjectScript, it is important for all developers to understand its potential, even if they don't have use-cases where they personally require its use?

that's correct.
I see the need to understand the potential and the possibilitiies to apply if appropriate.
Actually, we do this with SQL and it is totally normal  [hopefully]
It should be as normal also for Embedded Py

I agree Robert - I think ObjectScript, SQL and Embedded Python of the potential of a very powerful trifecta for customer logic (close to the data), data access, and re-usable library access!

The king is dead, long live the king! is a traditional phrase that is proclaimed at the advent of a new monarch in France.

May I say: IRIS is dead, long live IRIS!

This is what I feel with the arrival of Embedded Python.

The old monarch spoke ObjectScript, he allowed us to accomplish great things but now let's stop looking back, let's move forward. Let's induct the new monarch who speaks Python. Let's stop worshipping his father and let's make room for the new generation.

That's why I think, we must stop coding in ObjectScript, we must strive to use Python, everywhere in IRIS and this without the wrapper ([language = python]).

Why be so radical?

  1. Coding in Python is to show by example and in a language that the uninitiated know and thus prove the extent of the possibilities of IRIS
  2. Coding in Python is to start answering and finding solutions to the new problems that we will encounter:
    a. How to integrate .py files in our CICD pipes
    b. How to integrate PyPI with ZPM
    c. How to elegantly expose future APIs coded on the Flash Framework with IRIS and CSP gateways
  3. Coding in Python encourages InterSystems to produce new packages in Python rather than ObjectScript.

Choosing your programming language in IRIS is a political act.

  • Coding in ObjectScript is to be conservative.
  • Coding in Python is to be liberal.

Choose your side.

@Guillaume Rongier - an interesting (and indeed radical) take on this ;)  I agree that broader use of Python will allow gaps and new best practices to be identified more quickly, to the benefit of all.  Your suggestion of not needing to use [language = python] is thought-provoking ... have you logged an enhancement to allow a descriptor at the class level which will allow python to be assumed across the entire class without requiring the python language to be specified in each method?  

I am generally quite conservative in nature, but your 'liberal' ideas are indeed thought provoking ;) 

@Ben Spead

With Embedded Python, code can (and should?) not be stored in the databases and still be executed on the server side with the irispython interpreter.

Here is a GitHub link that demonstrates the use of embedded python with a backend on the Flask micro framework + Iris as a database.

It is true that Embedded python will change a lot of our paradigms, best practices, reflexes.

That's why we, as ObjectScript and IRIS experts, must try to use it as much as possible.

We will have to go out of our comfort zone and it is essential, it is up to us to go towards the python community because the opposite will not happen.

Regarding the [language = python] tag, I'm not saying it's useless. It can be useful in some cases.
I just think that it should not become the norm.

PS: My previous answer is indeed provocative and this is to draw attention to Embedded Python which is not a feature but a major evolution (Révolution ?).