search

potassco / clorm

🗃️ A Python ORM-like interface for the Clingo Answer Set Programming (ASP) reasoner
https://clorm.readthedocs.io
MIT License
52 stars 5 forks source link

Extend the forward reference handling to more complex boundary cases #132

Closed daveraja closed 6 months ago

daveraja commented 6 months ago

I've extended the postponed type annotations for some more complicated (boundary) cases. For example, when the Predicate definition with type annotation is defined in a non-global scope (eg. within a function) and is referring to another predicate definition of a different scope. While some of these cases are probably not something anyone would (or should) do, it is good to have it working in case.

@florianfischer91 let me know if you have any thoughts. I find this postponed annotations and the from __future__ import annotations stuff to be quite a mess. It seems that there is no clear way to deal with it that doesn't involve some sort of hack; such as accessing undocumented APIs (eg. typing._eval_type()) or complicated workarounds for specific versions of Python.

daveraja commented 6 months ago

Note, I've modified slightly the logic of mixing type annotations with explicitly defined fields. If a type annotation is used for one field then it must be used for all. But you can use a type annotation and still override the behaviour with an explicit field() declaration. This allows the user to write their own BaseField class to provide some specific Python to Clingo translation, but still maintain the type checking features for linting, etc.

florianfischer91 commented 6 months ago

Sry for the late response. Yeah dealing with types in python is always a bit ugly and even more if you have to support multiple python versions. Supporting non-global scope is a good idea. I can remember that there was something like this in Clingraph (don't know if this still the case) when you dynamically want to define classes. I have also tried this and it works 👍 I also like the change that a user either has to use annotations for all fields or not use annotations at all.

daveraja commented 6 months ago

Sry for the late response. Yeah dealing with types in python is always a bit ugly and even more if you have to support multiple python versions. Supporting non-global scope is a good idea. I can remember that there was something like this in Clingraph (don't know if this still the case) when you dynamically want to define classes. I have also tried this and it works 👍 I also like the change that a user either has to use annotations for all fields or not use annotations at all.

Cool. Thanks for responding and testing it out.