SFML community forums

General => General discussions => Topic started by: Sonkun on May 11, 2012, 03:24:59 pm

Title: Another python binding: python-sfml2
Post by: Sonkun on May 11, 2012, 03:24:59 pm
A MORE RECENT VERSION IS AVAILABLE! HERE (http://en.sfml-dev.org/forums/index.php?topic=8247.0)

http://en.sfml-dev.org/forums/index.php?topic=8247.0

Hello everybody,

I wanted to let you know about my project, a python binding for sfml2. Also written with cython and it was forked from the official python binding written by Bastien Lénoard on the 20th November 2011 because I needed some features at once to write my current C++ projects in Python.

It has since then widely improved and I decided to share my work.

The release I'm about to introduce is based on a snapshot of sfml2 which was available on the 20th November 2011 that I used to call sfm1.9. I decided to stay and work with this version because maintaining a binding up-to-date with the very latest changes is time consuming (also because I have projects which depend on the binding and a change made in sfml2 involves a change in the binding which involves changes in all my projects).

This release version is v0.9 and I hope to provide for the next one (v1.0) a binding compatible with the release candidate; I've already started working on it.

Despite its dependency on the snapshot, it provides some features that may interest people.

What has changed since its fork ? (copy-paste from the documentation)

I suggest you to read the documentation to know more: http://openhelbreath.net/python-sfml2/0.9/doc/introduction.html

How to install ?
Just read the doc about compiling and if you are on ubuntu 12.04, packages are available trough a launchpad ppa. Type:
Code: [Select]
sudo apt-add-repository ppa:sonkun/sfml
sudo apt-get update
sudo apt-get install libsfml2-dev python-sfml2

Notes that the packages provide examples too, you may want to install sfml2-examples or/and python-sfml2-examples, then you just have to type:
sfml2-<examples name>
python-sfml2-<examples names>

For examples:
Code: [Select]
python-sfml2-pyqt4 # will run script pyqt4.py that use the binding.
sfml2-sound
pyton-sfml2-shader

If you are interested in following the version 1.0 development and having automatic updates, I'll set up another depot named sfml-development with sfml2-rc in and the binding as well.

Links:
Main website: http://openhelbreath.net/python-sfml2/
Documentation: http://openhelbreath.net/python-sfml2/0.9/doc/
Downloads: http://openhelbreath.net/python-sfml2/downloads/ or https://github.com/Sonkun/python-sfml2/downloads
Bug-tracker: http://openhelbreath.net/python-sfml2/flyspray/
Launchpad ppa: https://launchpad.net/~sonkun/+archive/sfml
Title: Re: Another python binding: python-sfml2
Post by: Sonkun on May 11, 2012, 08:36:35 pm
I must add for Windows users I didn't try to compile on this platform and feedbacks would be appreciated.
Title: Re: Another python binding: python-sfml2
Post by: zsbzsb on May 12, 2012, 02:52:34 am
Sound great even though I don't use python. One suggestion though, how about updating it to the SFML 2.0 RC. I know you said it is a lot of hard work to keep the binding up to date, but the SFML 2.0 RC API is currently frozen for quite a while so you should not have trouble with that. On reason I suggest to update the binding is because so much has changed since 1.9 and SFML 2.0 RC. Also using 1.9 will cause issues if users try to follow the updated tutorials. Just a small suggestion, take it or leave it.  ;)
Title: Re: Another python binding: python-sfml2
Post by: Sonkun on May 12, 2012, 07:06:43 pm
That's what I planned :p Actually I stopped working on the binding in the middle of January because I had to leave abroad but now I'm back, I wanted to release my work before going on and update the project with the sfml2-rc. I worked hard to provide a nice documentation, tutorials, etc but now everything has changed and I must redo. But thanks for this piece of advice anyway, I'll take it :)
Title: Re: Another python binding: python-sfml2
Post by: Sonkun on May 26, 2012, 06:16:22 pm
The next version (compatible with the release candidate) will be available this Monday night.

The bug-tracker has been disabled temporarily.
Title: Re: Another python binding: python-sfml2
Post by: TaeZ on May 28, 2012, 02:50:08 pm
Hey, Bastien is still working on his bindings.
http://en.sfml-dev.org/forums/index.php?topic=5311.105

Maybe you could join him and help to maintain the project, so you two wouldn't be working separately on a same thing.
Title: Re: Another python binding: python-sfml2
Post by: Sonkun on June 01, 2012, 12:06:07 am
Hello, as promised the next release is out. I created a new topic: http://en.sfml-dev.org/forums/index.php?topic=8115.0

Hey, Bastien is still working on his bindings.
http://en.sfml-dev.org/forums/index.php?topic=5311.105
I know he is still working on his binding but I primarily maintain my own one because I don't want the same interface and I work on other projects that use the binding and need features that Bastien's binding doesn't provide and won't provide (the network module for example).
Title: Re: Another python binding: python-sfml2
Post by: Haze on June 04, 2012, 01:19:08 pm
I know he is still working on his binding but I primarily maintain my own one because I don't want the same interface
What's wrong with the interface of Bastien's implementation?
Regarding the network module, Python already provides sockets and ftp library (but I bet you already know this).
Did you just want to copy the SFML API?

While I salute the initiative of enhancing the binding, I think a lot of users will be confused if two python bindings are proposed, especially since the both of them are up-to-date and look-alike.
Title: Re: Another python binding: python-sfml2
Post by: Nexus on June 04, 2012, 05:48:57 pm
Even more crucial, only bastien's pysfml2 is official, so you need good arguments to convince people of using your binding instead ("I don't like the API" without being concrete is none).

And don't forget, the Python subforum has been created for pysfml2 support ;)
Title: Re: Another python binding: python-sfml2
Post by: Sonkun on June 04, 2012, 09:34:35 pm
Quote
Regarding the network module, Python already provides sockets and ftp library (but I bet you already know this).

Yes, Python standard library already provides network stuff for socket, ftp, etc... and ? It offers built-in classes, written in C with its own interface while SFML has its own implementation with its own interface, why shouldn't we provide it ? The standard library has also a time module that provides everything for handling time, is it a reason not to implement sf::Time, sf::sleep, sf::seconds, etc ?

Quote
While I salute the initiative of enhancing the binding, I think a lot of users will be confused if two python bindings are proposed, especially since the both of them are up-to-date and look-alike.
I don't want people to be confused and I'll do my job to avoid this and highlight the difference. However, they may look-alike but acutally they are not.

Quote
Even more crucial, only bastien's pysfml2 is official, so you need good arguments to convince people of using your binding instead ("I don't like the API" without being concrete is none).
I don't need any arguments to convince people of using my binding. I'm just sharing a work that I use for personal projects. Take it or leave it.

Quote
And don't forget, the Python subforum has been created for pysfml2 support ;)
I don't think so, the Python subforum was created before pysfml-cython becomes the official binding. And if Laurent minds, he's old enough to tell himself.
Title: Re: Another python binding: python-sfml2
Post by: Laurent on June 04, 2012, 11:10:59 pm
Quote
Yes, Python standard library already provides network stuff for socket, ftp, etc... and ? It offers built-in classes, written in C with its own interface while SFML has its own implementation with its own interface, why shouldn't we provide it ? The standard library has also a time module that provides everything for handling time, is it a reason not to implement sf::Time, sf::sleep, sf::seconds, etc ?
If something's implemented and widely used in the standard library of the language, there's no reason to provide a binding for it. Is there a chance that SFML's binding is better than the language standard library?
By the way, many things of the new C++ standard already makes some SFML classes deprecated (thread and time, for example).

Quote
I don't need any arguments to convince people of using my binding. I'm just sharing a work that I use for personal projects. Take it or leave it.
I think that other  people want to highlight the fact that it's such a waste to put so much effort on two similar libraries. Can't they be somehow merged? What are the main differences that makes them incompatible?

Quote
I don't think so, the Python subforum was created before pysfml-cython becomes the official binding.
True ;)
Title: Re: Another python binding: python-sfml2
Post by: Nexus on June 06, 2012, 10:46:37 pm
The standard library has also a time module that provides everything for handling time, is it a reason not to implement sf::Time, sf::sleep, sf::seconds, etc ?
If you mean <ctime>, it doesn't provide high resolution clocks, which is the application field of sf::Clock.

I don't need any arguments to convince people of using my binding. I'm just sharing a work that I use for personal projects. Take it or leave it.
Okay. It's very nice to share your hard work, however a long-term user wants to know if the binding remains your personal project fitted for your needs or if you support it actively. You should probably clarify your strategy to avoid frustrated users ;)

I don't think so, the Python subforum was created before pysfml-cython becomes the official binding.
Anyway, now the forum description says "Questions related to the Python binding of SFML (pysfml)". And it can easily confuse users if two bindings are discussed in the same subforum. For example, people read something and try to apply it to their project, but it doesn't work because it concerns the other binding. Or thread starters need to specify every time which binding they refer to.
Title: Re: Another python binding: python-sfml2
Post by: Klaim on June 07, 2012, 05:21:58 am
The standard library has also a time module that provides everything for handling time, is it a reason not to implement sf::Time, sf::sleep, sf::seconds, etc ?
If you mean <ctime>, it doesn't provide high resolution clocks, which is the application field of sf::Clock.


I think he is talking about chrono, not ctime.

See http://en.cppreference.com/w/cpp/chrono and, just::chrono and  boost.chrono implementation
Title: Re: Another python binding: python-sfml2
Post by: Nexus on June 07, 2012, 10:42:13 am
Chrono is only available in C++11, so SFML is still an alternative for C++98. The same with threads and (to some extent) unicode.
Title: Re: Another python binding: python-sfml2
Post by: Sonkun on June 14, 2012, 10:49:11 pm
Quote
If something's implemented and widely used in the standard library of the language, there's no reason to provide a binding for it. Is there a chance that SFML's binding is better than the language standard library?
By the way, many things of the new C++ standard already makes some SFML classes deprecated (thread and time, for example).
True, but it can be implemented to provide an exhaustive binding and its use discouraged at the same time :) It's not my major argument, even if I use this module in my projects.

Quote
I think that other  people want to highlight the fact that it's such a waste to put so much effort on two similar libraries. Can't they be somehow merged? What are the main differences that makes them incompatible?
They can't be merged since the code is totally different. Although it has used the official binding as starting point, all the code has been rewritten and re-thought following different implementation/technical choices. The binding is separated in fives modules: system, window, graphics, audio and network. The vector mechanism is not the same and involves modification everywhere (SFML uses massively vectors). The way I handle events works very differently. All classes are provided, for example you don't find Window in the official binding.

Quote
Okay. It's very nice to share your hard work, however a long-term user wants to know if the binding remains your personal project fitted for your needs or if you support it actively. You should probably clarify your strategy to avoid frustrated users ;)
You are right. I'll be clearer for the next release. It is of course, long-term support.


Quote
Quote
The standard library has also a time module that provides everything for handling time, is it a reason not to implement sf::Time, sf::sleep, sf::seconds, etc ?
If you mean <ctime>, it doesn't provide high resolution clocks, which is the application field of sf::Clock.
I was talking about the python standard library :D The module time has everything for manipulating time. If I follow the same logic, we shouldn't implement sf.Time, sf.sleep, etc.
Title: Re: Another python binding: python-sfml2
Post by: Laurent on June 15, 2012, 07:54:09 am
Quote
True, but it can be implemented to provide an exhaustive binding and its use discouraged at the same time
What's the point of implementing something and then discouraging its use? Confusing people? :P
I think it's important to stick to the native classes and functions, so that SFML code can interact nicely with the rest of the code, and not require type conversions and duplicated functions everywhere. A binding must look natural, as if it was directly developed in the target language.
Title: Re: Another python binding: python-sfml2
Post by: Sonkun on June 25, 2012, 04:45:54 am
Quote
What's the point of implementing something and then discouraging its use? Confusing people? :P

Maybe should I have said "preferred" instead" of "discouraged". I find more confusing not to have the sfml network module implemented than having it.

It allows you to port C++ projects more easily. With minor syntactic changes (all of which are documented), you can port your code without having to trod through the standard library's documentation. Later, you can replace bits and pieces you like with the standard Python's built-in equivalents.

Quote
I think it's important to stick to the native classes and functions, so that SFML code can interact nicely with the rest of the code, and not require type conversions and duplicated functions everywhere. A binding must look natural, as if it was directly developed in the target language.

That's exactly what my binding offer compared to the official's one, a more natural look and on many points:

1) Types
In Python, numeric types (integer, float, complex, long) are inferred. Users shouldn't care about the Vector's type or Rect's type.

In my binding, instead of writing:
sf.Vector2f()
sf.Vector2i()
sf.IntRect()
sf.FloatRect()

You write:
sf.Vector2()
sf.Rectangle()

2) Copy
In the official binding, there are plenty of copy() methods to make copies but in Python copies are done via the copy module.

In my binding instead of writing:
image = sf.Image.load_from_file("myimage.png")
image2 = image.copy()

You write:
from copy import copy, deepcopy

image = sf.Image.from_file("myimage.png")
image2 = copy(image)

3) C++ multiple definitions are not emulated

In Python, there are no multiple definitions. Instead of emulating this C++ feature and make Python functions take any argument then check whether they match a C++ function definition, I split functions.

For example, instead of writing this:
texture.update(window)
texture.update(image)

You write:
texture.update_from_window(window)
texture.update_from_image(image)

Another typical example is with multiple constructors. Here are the C++ Shader constructors.

bool loadFromFile (const std::string &filename, Type type
bool loadFromFile (const std::string &vertexShaderFilename, const std::string &fragmentShaderFilename)

Instead of writing this:
shader = sf.Shader.load_from_file("vertex.vert", "fragment.frag")
vertex = sf.Shader.load_from_file("vertex.vert", sf.Shader.VERTEX)
fragment = sf.Shader.load_from_file("fragment.frag", sf.Shader.FRAGMENT)

In my binding, you write:
shader = sf.Shader.from_file("vertex.vert", "fragment.frag")
vertex = sf.Shader.from_file(vertex="vertex.vert")
fragment = sf.Shader.from_file(fragment="fragment.frag")

4) Methods/function's name more pythonic.
The standard Python library traditionally uses from_foo() and to_bar() to respectively load/open and save objects. The binding does that as well.

music = sf.Music.from_file() # pythonic
music = sf.Music.open_from_file() # less pythonic

5) All of SFML's native classes are found.

You don't find Window, VertexArray and probably others in Bastien's binding.
Title: Re: Another python binding: python-sfml2
Post by: bastien on June 25, 2012, 10:26:42 pm
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 (http://docs.python.org/library/stdtypes.html#dict.copy).

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.
Title: Re: Another python binding: python-sfml2
Post by: aspidites on June 27, 2012, 04:58:16 am
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 (http://docs.python.org/library/stdtypes.html#dict.copy).

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:

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.