Be able to draw a tuple of vertices

[abodelot]

I was testing low-level custom drawables, and noticed that pysfml doesn't allow drawing a tuple of vertices:

render_target.draw((vertex1, vertex2), sf.LINES) (an AttributeError is raised)

You must use a list of vertices:

render_target.draw([vertex1, vertex2], sf.LINES)

Could tuples be allowed as well? (see sfml.pyx:3153) I believe using a tuple instead of a list can be faster when dealing with large amounts of vertices.

[bastienleonard]

This is implemented in commit 54b229bafb1cea7f1eb7aa28fcff1211fbc1e8cb. I don't really feel like it should improve performance in a noticeable way, but it's more user-friendly for people who prefer to use a tuple instead of constant list.

[AphonicChaos]

I think this, as well as issue #20 are a matter of too much hand-holding going on. That is, a common idiom to allow for duck-typing, rather than try and 'protect' your users. I mean, what happens if it turns out that, say, 20 types are now valid arguments for draw(), rather than simply list and tuple? Are you going to add the other 18 to the isinstance check?

That said, testing for iter is in fact the incorrect answer, considering that in python 3, strings received an iterr attribute. Were I to do it again, I'd try: from collections import Sequence isinstance(foo, Sequence)

Or better yet, not type-check at all.

[bastienleonard]

I still need to go to another code path if the object isn't meant to be a sequence of vertices. So if I want to use duck typing, I would need to pretend it's a sequence of vertices, and if it raises an exception, assume it's a user-defined drawable. In this case, testing the type directly in a condition is much more straightforward and doesn't really restrict the user.

If I just assume any sequence passed as an argument is meant to be a sequence of vertices to draw, it wouldn't work when a user creates a drawable that behaves like a sequence.