Two mypy related issues

[elParaguayo]

I've got two issues related to mypy: 1) The py.typed file is not included in the pip package so mypy reports errors like Skipping analyzing 'dbus_next.service': found module but no type hints or library stubs 2) If I add a py.typed file, those errors disappear but I still get messages like error: Name 's' is not defined when defining service methods etc.

Have I missed something on the second one that's making mypy fail?

[acrisci]

That was done by @trickeydan . I haven't used it.

A PR to fix the first issue would be appreciated. For the second one, I think there's an annotation needed that tells the type checker it's not a normal type annotation. The type is actually determined by that annotation, but in a complicated way. I don't know if they support making that work.

[elParaguayo]

Thanks for the quick reply.

Let me see if I can do the PR for point 1 and I'll do some digging on point 2 to see if there's a fix.

[FFY00]

That is expected because this library is hijacking the type system to specify the dbus signature.

I think there's an annotation needed that tells the type checker it's not a normal type annotation.

You can do typing.Annotated[MyRealType, 'dbus-signature']. This would require custom handling, but should be fairly straightforward.

I have done some work designing an interface that does introspection from python type hints and generates the dbus signature, maybe we could integrate that here. https://github.com/FFY00/dbus-objects

[acrisci]

If you're talking about converting Python types to DBUS types, that's a terrible idea because there is no clear relationship that way and you will end up confusing your users and making certain things impossible. For instance, Python int can map to one of several DBUS int types. There will be ambiguities with containers too. There are official guidelines against guessing types like this. DBUS type strings cannot be abstracted away from the user.

If I wanted to do this the normal way, I would use decorators for the user to specify type strings. If the fancy decorators cannot be supported in the future, I'll go that way.

[FFY00]

All that can be supported with the type system, but supporting complex types such as containers explicitly would require PEP 646.

See https://dbus-objects.readthedocs.io/en/latest/api.html#module-dbus_objects.types.

As far as containers go, there is a pretty direct matching to python containers. Python lists are dbus arrays, python tuples are dbus structures, python dictionaries are dbus dictionaries, and dbus variants are tuple[str, Any].

If you don't want that direct mapping, with PEP 646 you will be able to do something like

import dbus

def my_function(param: dbus.Array[dbus.Byte]) -> dbus.Structure[dbus.String, dbus.Int32]:
    ...

you will end up confusing your users

Well, given that we can let users do everything explicitly, I disagree. My implementation allows using native python containers, using the mapping I provided above, but that does not need to be the case, you can force them to use a notation like the one in the example.

and making certain things impossible

Can you provide examples?

[acrisci]

I don't want to hijack this to talk about library design. If you want to continue the discussion, come to my discord chat (link in the readme) or start a new thread.

[FFY00]

I am in the discord, same nick, if you want to reply there feel free to ping me.