[Py OV] Move ie_api.py and exceptions.py files to openvino module

[almilosz]

Details:

• move runtime/ie_api.py and rename it to _ov_api.py as ie_api is a legacy name.

• add runtime/ie_apy/__init__.py as proxy

• update openvino/__init__ to import from _ov_api.py.

• move runtime/exceptions.py and add proxy in runtime

• update test_ovdict to use OVDict defined in openvino.runtime.utils.data_helpers

• update tensor_from_file import in openvino/__init__.py. This function is located in openvino.runtime.utils.data_helpers

Part of openvino.runtime deprecation

Tickets:

• CVS-129459

[popovaan]

Do we need to change __init__ files in dev tools?
https://github.com/openvinotoolkit/openvino/blob/master/tools/mo/openvino/__init__.py#L26-L30

[almilosz]

Do we need to change __init__ files in dev tools? https://github.com/openvinotoolkit/openvino/blob/master/tools/mo/openvino/__init__.py#L26-L30

Currently there are no changes to tools/mo/openvino/__init__.py beacuse it's deprecated and will be removed. But imports like from openvino.runtime import Model should work during the deprecation period for openvino.runtime. openvino.runtime will be dropped in 2026.0 release.

[rkazants]

what is the correct (official and offered to user) way to import Model, Core, and others here?
May be it should be just from openvino import Model and from openvino import Core?

[akuporos]

yes, it is
_ov_api contains python wrappers above pybind11 bindings.

[rkazants]

To me, _ov_api looks like internal api that nobody should use it.

[akuporos]

There is a check that __init__ files of openvino, ovc and benchmark app (prev also mo and openvino-dev) should be the same. It's still openvino/__init__.py. All three __init__ files during wheel building are installed in the same place openvino/__init__. If they aren't identical, they will overload each other.

[rkazants]

Will we still have openvino.runtime? May be it is better to have openvino.utils?

[akuporos]

it will be done in a separate PR

[rkazants]

User will never import in such a way. AFAIK, we propose from openvino import compile_model

[akuporos]

answered above

[rkazants]

It is not clear. Let us use from openvino import compile_model. Now it should work.

[p-wysocki]

_ov_api.py is just a place for Python wrappers for C++ bindings (sometimes they're necessary, not in all cases). Since all __init__.py files are merged into one in wheel, they have to be aligned - that's why that change is also in tools/ovc/openvino/__init__.py.

Because it's in __init__.py, this import is indeed "internal" as you mentioned - the user will still be able to run from openvino import compile_model, because that __init__.py pulls compile_model from _ie_api.py and publishes it in the main openvino module.

The act of publishing the function to the main module itself is internal, it's not public API and should not concern the user, who keeps the same functionality of from openvino import compile_model.

[rkazants]

Please clarify what is a concept of having _ov_api? Can't we just import directly from openvino?

[almilosz]

To sum up
There is a way to import Core, Model and etc. directly from openvino. In the deprecation notice for openvino.runtime we would like to put the information to migrate to it.

From the user perspective it's a change a like this:

Before openvino.runtime deprecation	After openvino.runtime deprecation
from openvino.runtime import Core	from openvino import Core
from openvino.runtime import Model	from openvino import Model
from openvino.runtime import compile_model	from openvino import compile_model
from openvino.runtime import tensor_from_file	from openvino import tensor_from_file

Please clarify what is a concept of having _ov_api?

It's a bad practice to have the implementation of classes and functions in openvino.__init__.py. It should be clean and focused on the public API. So the implementation will be located in _ov_api.py, while public API will be accessible directly from openvino.

[mlukasze]

@rkazants @akuporos @p-wysocki
CI is Green, answers delivered, please take a look again.

[rkazants]

To sum up There is a way to import Core, Model and etc. directly from openvino. In the deprecation notice for openvino.runtime we would like to put the information to migrate to it.

From the user perspective it's a change a like this:

Before openvino.runtime deprecation After openvino.runtime deprecation
from openvino.runtime import Core from openvino import Core
from openvino.runtime import Model from openvino import Model
from openvino.runtime import compile_model from openvino import compile_model
from openvino.runtime import tensor_from_file from openvino import tensor_from_file

Please clarify what is a concept of having _ov_api?

It's a bad practice to have the implementation of classes and functions in openvino.__init__.py. It should be clean and focused on the public API. So the implementation will be located in _ov_api.py, while public API will be accessible directly from openvino.

I am lost. So do you mean I need to use _ov_api.py for importing Core class? And do you propose to users to import openvino._ov_api? It looks awkward because names with prefix _ used for internal API.

Best regards,
Roman

[rkazants]

Need clarification of further Python API design and not clear why _ov_api is needed and targeted for.

[p-wysocki]

_ov_api.py is just a place for Python wrappers for C++ bindings (sometimes they're necessary, not in all cases). Since all __init__.py files are merged into one in wheel, they have to be aligned - that's why that change is also in tools/ovc/openvino/__init__.py.

Because it's in __init__.py, this import is indeed "internal" as you mentioned - the user will still be able to run from openvino import compile_model, because that __init__.py pulls compile_model from _ie_api.py and publishes it in the main openvino module.

The act of publishing the function to the main module itself is internal, it's not public API and should not concern the user, who keeps the same functionality of from openvino import compile_model.