pyvmomi==8.0.3.0.1 errors with mypy

[sodul]

Describe the bug

Run mypy on code using pyvmomi, mypy will throw an error:

AssertionError: Cannot find component 'ByTime' for 'pyVmomi.vim.event.EventFilterSpec.ByTime'

Reproduction steps

pip install pyvmomi==8.0.3.0.1 types-pyvmomi==8.0.0.6 mypy==1.10.1

Call mypy on code using pyvmomi:
mypy

To fix:
pip install pyvmomi==8.0.2.0.1

Expected behavior

No errors.

Additional context

Relates to #862 and #1048.

[phagara]

another incorrect typing stub:

$ cat foo.py
from pyVmomi import vim
print(vim.TaskInfo.State.success)

$ python3 foo.py
success

$ mypy foo.py
foo.py:2: error: Module has no attribute "State"  [attr-defined]
    print(vim.TaskInfo.State.success)
          ^~~~~~~~~~~~~~~~~~
Found 1 error in 1 file (checked 1 source file)

[IvarVirusiim]

Some more issues:

vm: vim.VirtualMachine
vm.runtime.powerState

error: RuntimeInfo? has no attribute "powerState"  

Something relating to ManagedEntity, because many objects get error for accessing name:

Datastore? has no attribute "name" 
Network? has no attribute "name" 
ManagedEntity? has no attribute "name" 

More examples:

TaskInfo? has no attribute "state" 
TaskInfo? has no attribute "result"
DatastoreBrowser? has no attribute "SearchDatastore_Task"  
VirtualDevice? has no attribute "connectable" 
VirtualDevice? has no attribute "uptCompatibilityEnabled" 
VirtualDevice? has no attribute "backing" 
VirtualHardware? has no attribute "device"

There seems to be an issue with the underlying generation issue. Those are some of the few examples.

[MajorDallas]

Here's another:

There are dozens of methods annotated with NoReturn as their return type. NoReturn is meant to indicate that a function/method does not return, not that it returns nothing (for that, None is the correct annotation). Functions whose final statement is raise SomeException() or that call eg. sys.exit()--things that completely stop the execution of the program instead of returning--should use NoReturn. The effect is that any code after a call to eg. View.Destroy() or ServiceSystem.Start() will be incorrectly flagged by type checkers (not just mypy) as unreachable.

Anything annotated with -> NoReturn should be changed to -> None.

Just from a glance at the following line from _typeinfo_vim.py:

CreateManagedType("vim.view.View", "View", "vmodl.ManagedObject", "vim.version.version2", None, [("destroy", "DestroyView", "vim.version.version2", (), (0, "void", "void"), "System.View", None)])

I will hazard a guess that void is the culprit. I don't know what vSphere's API is written in, but I've always assumed it's Java. So, I further guess that the meaning of void as "not having a return value" just doesn't translate well to Python, since all Python functions that don't raise an exception return some value, even if it's an implicit None. Eg. this is correctly typed:

def a_function() -> None:
    pass

# >>> result = a_function()
# >>> print(result)
# None

Oddly enough, I found this snippet in VmomiSupport.py:

_wsdlTypeMap = {
    # Note: xsd has no void type. This is a hack from before. Can be removed?
    (XMLNS_XSD, 'void'):
    NoneType,
    ...

If this is what I think it is, it looks like the type stubs should have None instead of NoReturn. Maybe the stubs just need to be regenerated?