Python 2 support about esper HOT 6 CLOSED

There was a PR here: #9

But Ben decided against incorporating it, as it would add a dependency.

from esper.

Sorry, did not think to check in the PR... from what I see in your current branch, though, the dependency was removed, no? I do not use the CachedWorld, so I can not say if it is working with Python2, but at least your branch works fine out of the box for me.

The objection still standing is the experimenting with the async features. Any update on this, @benmoran56 ? I agree that maintaining both 2 and 3 while looking into this sort of thing would be complicated, but I would simply like to add my voice to the opinion that, eventually, a version of esper that works with both would be sweet.

from esper.

from what I see in your current branch, though, the dependency was removed, no?

The change removing the dependency on the future module was lost in a rebase on the master branch and then I decided to leave it that way, because the PR was already closed, so I thought I might as well keep the dependency, since it makes things a lot easier.

from esper.

@baudren, If I could ask, which library are you depending on that only supports Python2?

from esper.

Sure, @benmoran56, I am using libtcod, a roguelike engine with some python bindings, only available for Python 2 at the moment. There is, as I discovered today actually, a native python port, there, which seems a bit behind the official library, but with the added bonus of supporting Python 3.

Since the original library is c++, and the python bindings are just provided for convenience, I don't think porting the bindings to Py3 is a top priority for the team, but I could ask there.

from esper.

Ah, interesting library. I understand the desire for dual Python2/3 support, but I'm not sure if it's something I want to commit to at this point for several reasons. No external dependencies is not something I wish to compromise on (as it's one of the reasons I started this project).

The CachedWorld branch is still something that is being experimented with, and I think it makes sense to explore this more in the future.

I'm very interested in the current work being done by the Python devs with regards to multiple core programs (there is a long running thread called "solving multi-core python"). This is something I'm lookign into actively. (By the way, I have an experimental muliprocessing based branch of esper, but it doesn't work with ctypes based libraries such as PySDL2).

Another (selfish) reason is that I haven't used Python2 personally or professionally since the Python 3.2 release, which was in 2011. I don't have the personal desire to work on it myself, but I will do what I can to keep esper easily portable when possible.

from esper.