Another python binding: python-sfml2

[Sonkun]

A MORE RECENT VERSION IS AVAILABLE! HERE

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)

• network module implemented.
• sound module rewrited.
• some current limitation of the module have been fixed such the derivability of sf.Drawable.
• modules are implemented separately; you can import each module independently.
• support cython 0.16 (faster).
• many official examples are available and new examples have been added (such integrating with pyqt4).
• an extra-layer to the sfml has been added to avoid dealing with type and to provide more flexibility
• available trough depot in launchpad for ease of installation.

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

[Sonkun]

I must add for Windows users I didn't try to compile on this platform and feedbacks would be appreciated.

[zsbzsb]

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. 

[Sonkun]

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

[Sonkun]

The next version (compatible with the release candidate) will be available this Monday night.

The bug-tracker has been disabled temporarily.

[TaeZ]

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.

[Sonkun]

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).

[Haze]

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.

[Nexus]

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

[Sonkun]

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 ?

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.

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.

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.

[Laurent]

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).

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?

I don't think so, the Python subforum was created before pysfml-cython becomes the official binding.

True

[Nexus]

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.

[Klaim]

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

[Nexus]

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.

[Sonkun]

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.

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.

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.

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 The module time has everything for manipulating time. If I follow the same logic, we shouldn't implement sf.Time, sf.sleep, etc.