about python 3 support

[jice]

Python 3 is not supported yet.

All strings in python 3 are unicode and must be converted back to ascii before being sent to libtcod.

The current wrapper might work with python3, but you'll have to convert all strings to ASCII (b"my string" syntax instead of "my string").

[Jotaf]

How about making a fast unicode->ascii conversion function in libtcod, and using it from python? I'm not an expert in the area of character codes but usually generic implementations deal with many cases that your specific application may not need to be concerned with. You only need to map 256 characters, after all...

[Hex Decimal]

Is there a reason why Python's ctypes function argtypes are not being defined?  Python uses that to convert Python values to C values and has to guess what C wants without it.

[jice]

How about making a fast unicode->ascii conversion function in libtcod, and using it from python? I'm not an expert in the area of character codes but usually generic implementations deal with many cases that your specific application may not need to be concerned with. You only need to map 256 characters, after all...

mmh that needs to be benchmarked. I'm not sure calling a conversion function through ctypes would be faster than python's native function.

Is there a reason why Python's ctypes function argtypes are not being defined?  Python uses that to convert Python values to C values and has to guess what C wants without it.

I think it's pure lazyness from me. That would represent hundreds more lines of codes to maintain for the same result. Python values are already converted by hand in the wrapping functions.

[Matt_S]

I've got the python wrapper running in python 3.  Well, two wrappers really, one that converts every string to bytes, and one that uses the unicode printing functions rather than converting.  Printing an 80*50 console with one string covering each line, both of the python 3 versions as well as the python 2.6 version (no psyco) get right around 15-16 fps.

[jice]

Awesome ! Which one should we keep ? Can you post the wrapper code here ?

[Matt_S]

Alright, here's the wrappers as well as the converted samples.  Version a converts everything to ascii, version b uses unicode functions when available.  Version b explicitly converts the input to c_wchar_p so there's no wacky antics if the user passes in bytes.  I also added a version c that uses the regular functions if bytes are passed to the function, and uses the unicode ones otherwise.  I don't know if there's any consequences to mixing unicode and ascii, so version c might not actually be a good idea.  If version c does work, that would be my recommendation, in case the user wants to use the ascii print functions.

[hawkeye_de]

Will 1.5.1 have python 3 support? The 'problem' is that I wanna use Python 3 for my new project^^

[( Tchey )]

Excuse me, i'm new to this world (programming).

If i want to use Python 3.2 to develop a small roguelike so i can learn things, where should i go ?

Thanks

[Nikolai]

Excuse me, i'm new to this world (programming).

Welcome!

If i want to use Python 3.2 to develop a small roguelike so i can learn things, where should i go ?

There's not much out there in terms of Python 3 Roguelike libraries.  I prefer Python 3 myself, but it's worth noting that more than one Python version can exist side-by-side on the same computer with no conflicts.  I do most of my coding in Python 3.2, but have Python 2.7 (plus pygame and a few other 2.7 libraries) installed for my Roguelike work. 

[Nikolai]

If i want to use Python 3.2 to develop a small roguelike so i can learn things, where should i go ?

Since I wrote to you, the pygcurse library has come out.

http://inventwithpython.com/blog/2011/09/10/pygcurse-a-curses-emulator-built-on-pygame/

It doesn't do everything the libtcod library does, but it does a lot -- and you can run it in Python 3.2 if you want.

[jaunmakenro]

Hi !

I'm trying to use some libtcod method with blender. (use blender for 3D rendering, and libtcod for fov, path-finding, BSP...)

The problem is that Blender use python 3.x...
So when i add  "import libtcodpy" in my python script launched by blender, i received something like that:

[...]libtcodpy.py in line 41, in <module>
  _lib = ctypes.cdll['./libtcod-mingw.dll']
[...]python\lib\ctypes\_init_.py", line 340, in __init__
    self._handle = _dlopen(self.nae, mode)
[error 126] specified module not found

I don't understand anything in ctypes and dll linking, so I'm not even sure the problem come from python 3.x compatibility...

(i tried the converted samples from Matt_S but i got :
[...]\libtcodpy3a.py", line 397, in console_set_custom_font
    _lib.TCOD_console_set_custom_font(c_char_p(fontFile), flags, nb_char_horiz, nb_char_vertic)
TypeError: string or integer address expected instead of str instanc


any idea ?

[jaunmakenro]

Ok, sorry, this is not a python version issue.

It's only a dll path problem... and i didn't find how to solve it. But it's no more a libtcod problem !

[Orillian]

Can we get an update on the state of libtcod in Python 3?
Is it predominantly just the unicode stuff that's causing the issues converting libtcod to python?

Did that wrapper that Matt_S  provided get added into the mix?

Just trying to get an idea as to whats actually been done or not?

O.

[jice]

ok I've spent some time to port Matt_S patch to the latest 1.5.1 version (sorry for my lack of answers during those... 3 years... )
But I get the same error as jaunmakenro :

Code:

TypeError: string or integer address expected instead of str instance

Apparently, what worked with python 3 does not work anymore with 3.2+ because automatic conversion from str to bytes has been removed in version 3.2 (see this).
The solution is to convert by hand all strings passed to libtcod to bytes, for example :

Code:

libtcod.console_init_root(80, 50, b'libtcod python sample', False)

instead of

Code:

libtcod.console_init_root(80, 50, 'libtcod python sample', False)

You can have another problem because python 3.2+ is more punctilious about types. You cannot pass a float where an int is expected. For example, this :

Code:

        textColor = libtcod.console_get_char_background(sample_console, SAMPLE_SCREEN_WIDTH / 2, 5)

triggers this error :

Code:

TypeError: int expected instead of float

so you have to use python's integer division operator :

Code:

        textColor = libtcod.console_get_char_background(sample_console, SAMPLE_SCREEN_WIDTH // 2, 5)

I've just commited a patch that make the samples works with both python 2.7.2 and 3.2.3. I can't assure everything works and I hope I didn't break things for python 2.7 users, but at least everything used in the samples work. I'm watching this topic now to avoid another 3 years of silence, so feel free to post issues/functions not working here.