Tulip python does not follow python idioms

[rgiot]

In python, the natural syntax to test the existance of a thing in a container is to use the keyword in.
Sadly, it seems it is not the case with tulip bindings in python.

The following code:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from tulip import *

g = tlp.newGraph()
n1 = g.addNode()
n2 = g.addNode()
n3 = tlp.node()
e = g.addEdge(n1, n2)

# C++ way of life
assert g.isElement(n1)
assert g.isElement(n2)
assert g.isElement(e)
assert not g.isElement(n3)

# Python way of life ...
l = [n1, n2, e]
assert n1 in l
assert n2 in l
assert e in l
assert not n3 in l

# ... not compatible with tulip
assert n1 in g
assert e in g

is expected to work.

However assert n1 in g raises the following error:

Traceback (most recent call last):
  File "pythontest.py", line 28, in <module>
    assert n1 in g
TypeError: Graph.__getitem__(): argument 1 has unexpected type 'int'

I do not know at all sip, but I'm sure the error comes from Graph.sip where some cases are not taken into account in __getitem__.
No idea if it is technically feasible to fix this unexpected behavior.

By the way type(n1) gives <class '_tulip.node'> and not int as the error message suggest

[anlambert]

Hi Romain,

Good catch! I have just created PR #34 fixing the issue.

Cheers!

[rgiot]

@anlambert Thanks for proposing a patch so quickly. I have to admit that I'm surprised the solution is so short

[p-mary]

Thanks to both of you.

[rgiot]

In the same vein, addNodes accepts a tulip iterator, but not a list. It should be practical to allow such notation:

g.addNodes([node1, node2, node3])

where node1,node2 and node3 are valid nodes.

edit: here is the error message

    sg.addNodes(duplicated)
TypeError: Graph.addNodes(): arguments did not match any overloaded call:
  overload 1: argument 1 has unexpected type 'list'
  overload 2: argument 1 has unexpected type 'list'
  overload 3: argument 1 has unexpected type 'list'

[rgiot]

Sorry for the noise, tulip is able to add list of nodes without any issue...
I forget that my duplicated variable was a list of tuple instead of a list of nodes ...

However, the error message is misleading, as my variable was a list

[anlambert]

It seems that the API documentation is missing some methods, I will make a pass on it to add them.

I agree that the error message is confusing, I may have an idea to improve that.