I guess I should give my opinion at some point. I find some of the changes in this binding interesting, and I will probably copy/adapt some of them. But overall, I find that your arguments actually don't support that such change is more pythonic, natural or makes more sense.
For example, you removed the copy() methods because “in Python copies are done via the copy module”. As it turns out, dict, one of the most basic classes in Python,
has a copy() method.
Consider the following reasons not to use the copy module. The most obvious one is that operations on objects should be done via methods, as it's more natural in an object oriented language. Another one is that copy provides two kinds of copies, and it's not obvious which are supported. On the other hand, it's very easy to see if a copy() method exists, either via the documentation or the interpreter in interactive mode. I also think that making use of the copy module is overkill in the sense that deep copies don't seem to be needed.
In your third point, you don't give any reason why your design is better. You say that Python doesn't support multiple methods definitions, but that only matters to the implementer. I probably don't need to explain why emulating method overloading is often better for the users, especially those who come from C++ SFML.
I'm not sure what's the best way to implement vectors and rectangles. I think that they way they currently work is good enough, though. I think the way you describe Python's type system is misguided; there is a difference between, say, int and float, and Python enforces it. There is no static type checking, but that doesn't mean that any types can be mixed together. SFML also uses the different vectors and rectangles types for different purposes, which means that users should care what they are. It seems to me that the only question is whether or not these classes should be considered as generic containers.
As for missing classes, I'm open to suggestions. If there's a good reason to add them, I will do it. Streaming will be available soon(ish).
Overall, it seems that by “natural” and “pythonic”, you mean which that follows your opinion of how an API should look like, even when there are objective reasons to consider alternatives. I think that we should be rational when designing APIs, and recognize when the reasons that guided us are subjective. To be honest, it often seems to me that you're more interested in spreading slogans for your binding than having rational debates.
Show Posts