What's the point of implementing something and then discouraging its use? Confusing people? 
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.
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) TypesIn 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) CopyIn 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 emulatedIn 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.
Show Posts
The module time has everything for manipulating time. If I follow the same logic, we shouldn't implement sf.Time, sf.sleep, etc.