Some Operations and Expectations throw a module 'openqml' has no attribute error

[pennylaneai]

Some Operations and Expectations throw a module 'openqml' has no attribute error

[co9olguy]

I believe this is caused by plugins having a larger set of implemented gates than openqml core. Safe to ignore for now.

At some point we intend to allow plugins to put their own gates in openqml, but I doubt this will make it into the initial release.

[josh146]

It could also be typos, I'll double check. Things like Squeeze instead of Squeezing.

[cgogolin]

I just had a look a the code and it looks like it should be rather easy to modify the OperationFactory and ExpectationFactory to also load operations/expectations from the plugin scope, such as openqml.plugins.[plugin].ops. Both the ProjectQ and the SF plugin already have custom operations, so that would actually add value. Shall I give that a shot next week or do you want to wait until after 0.1?

[co9olguy]

@josh146 this is your area of expertise; what do you think?

[josh146]

I think this makes sense - it avoids the user having to import from both openqml and the plugin. There are only two pain points I can think of:

1. As this is not standard Python packaging behaviour, we'll have to make it very clear how this works in the plugin documentation.

2. If the user is working in an interactive environment, such as Jupyter, IPython or PyCharm, autocomplete likely won't work on the dynamically generated attributes.

[cgogolin]

1. Good point. 2. I suppose we could make it possible for the user to also import something from the plugin in case they want auto complete?

[josh146]

Yep. The user should automatically be able to import it from the plugin if they wanted to, right? In fact, I can't see any obvious issues with them importing one of the current projectq plugin operations, it should just work.

I quite like this approach - I feel like, either way, the user will definitely be able to find the operations

[cgogolin]

I looked into this. Some research reveals that __getattr__() does not work on modules below python 3.7. :-( The there are some proposed hacks (see the link), but I am not sure how hacky we want to go here....

[cgogolin]

Another option is to use setattr(openqml, 'foo', 'bar'). I didn't expect it, but this can even already be used from __init__() of openqml! I think we can use that to add operations to the openqml context during the initialization of a device, or, maybe even better during in the qfunc decorator. The special operations would then only be accessible via openqml.XXX(...) during a qufunc with a device that actually supports them. I will look into that later today...

[josh146]

@cgogolin let me know if you can get that working! My other concern would be what happens if two plugins are loaded with two operations with the same name? Having them accessible only within a particular QNode/device that actually supports them would solve that issue.

Another thing: I've been thinking about test_installed_plugins, and I'm not sure it belongs in OpenQML base. The tests provided with OpenQML should be testing the code provided with OpenQML, such as the operations, gradients, devices, QNodes, and default plugins.

External plugins should be responsible for their own tests, including: making sure that the plugin device works as expected, and that all supported/unsupported operations work. The plugins themselves should not need to test gradients, as that should be covered by the base OpenQML test suite.

Having test_installed_plugins in OpenQML base is problematic, as it can cause the OpenQML test suite to fail depending on external Python packages the user has installed. Alternatively, we should provide a test suite template that plugin developers can use for their own testing purposes, perhaps based on test_default_plugin or the SF/ProjectQ tests.

[cgogolin]

Yes, that was my concern as well and this approach would solve this nicely.

I agree that test_installed_plugins should be moved out of the core openqml test suite before release, Please leave it there a little longer, because for the moment it is tremendously useful for me...

[cgogolin]

This is fixed in #65. If you like that PR, we can close this issue.