disclaimer: I'm a bit exhausted, so my replies might come off as curt. I certainly don't mean them to.
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.
A rather subjective opinion (which I think was your overall point as well. Often it happens that we use the term 'pythonic' to mean that which seems more in-spirit with the nature of core pythonistas. Unfortunately, like any other philosophy, what is 'true to' or 'correctly adheres to' a particular philosophy quickly gets lost in translation. I hadn't realized this until I reflected on his reply of yours.
I'm not even sure it's fair to say that his binding is more 'idiomatic' than yours, since it could be argued that yours, more closely resembling the c++ api is as well. While I do like his binding better (and for other reasons), I'm not sure that pythonic is a proper adjective here. I'll continue to use it simply for lack of a better term.
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.
Paradoxically, that something exists in the standard library doesn't qualify it as "pythonic". A lot of things existed before this PEP or that was written. As for your dict example, the python standard library is (seemingly) inconsistent with respect to this. Sets and dicts have a copy method, but lists and tuples do not. Also, there still exists copy methods in Sonkun's binding, they are just not preferred.
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.
I could argue that implementing __copy__ special methods is more object oriented because generic functions are then able to operate on those objects. Granted, I'm not stellar at c++, but in my case, its more natural to use these generic functions to operate on objects rather than have to hope that the object offers a copy method. Documentation isn't much of an argument, as anyone who is experienced with python will instantly recognize the significance of the existence of a __copy__ method. That, and they wouldn't be any worse documented than your copy method. As for overkill, just don't import deepcopy...
Again, the entire argument could be reversed (in fact, that's all I seem to have done, though it was done subconsciously).
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.
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.
As for rational, I've seen in occur a couple of times in your projects' issues system that a rational argument was given to implement a change yet still it wasn't. I guess my point in mentioning this is that either the kettle is calling the pot black, or what you view as rational is subjective. Beyond that, I fully agree with that notion.
There hasn't been any discussions on these forums which I suppose leads to your second assertion. However, I have found Sonkun rather receptive of constructive criticism. I've had meaningful conversations about the API, and have had plenty of my suggestions turned down with ample explanation. Ironically, the one time you turned down my pull request, it wasn't until he offered an explanation on an unrelated issue that I understood your logic for doing so (the request that allowed lists and tuples to be passed as an argument).
That isn't to say that you aren't generally responsive to user concerns (plenty of evidence in the main Python bindings forum). I just wanted to highlight that Sonkun isn't as irrational, argumentative, or haphazard as others seem to be suggesting here.
BTW, its rather difficult to have a 'rational debate' when the only response given is 'we already have one'. As far as I can gather, 'more pythonic' was an argument used when you first released your binding, wasn't it? The biggest difference here is that in addition to porting from 1.6 to 2.0, you also moved to cython (I think the original was using ctypes or swig; correct me if I'm mistaken).
Last few things:
- I'm not speaking on his behalf, nor was I asked to. It could very well be the case that once he comes back from vacation, he reads this and chastise me for potentially (and unintentionally) misrepresenting him
- I'm sure everyone here recognizes that without YOUR work, his wouldn't be here, and for that, we obviously owe you thanks.
- The biggest appeal to his version over yours is that his comes without caveats. That is, I am able to compile it cleanly without errors for python 2 and 3 from one code base, which has subsequently made it a breeze to start implementing an sfml backend for kivy. Another was that his bindings seem to come with more complete documentation. For those coming directly from SFML this isn't an issue, but for me, this was the deal breaker.
After writing all of that, I'm not entirely convinced that my comments contributed positively to the discussion. I do hope my words are taken into consideration. Beyond that, I suppose I'll go back to lurking.
Show Posts