Port code to Python 3 #93

Closed
inquisb opened this Issue Jul 16, 2012 · 5 comments

Projects

None yet

3 participants

@inquisb
Member
inquisb commented Jul 16, 2012

Currently there is no pressure on Python projects to switch to the new version of Python interpreter, as the process of switching, especially on larger projects can be cumbersome (due to the few backward incompatibilities). The switch will take place eventually, but currently it is a very low priority task.

@chym chym referenced this issue Nov 10, 2012
Closed

error-based false #231

@stamparm
Member
stamparm commented Dec 8, 2012

As I've collected information regarding this over time, this will be maybe an impossible task to do because of one feature: "unicode strings". We currently extensively use unicode everywhere together with encoding/decoding for page responses. Problem is that Python 2 has a clear distinction between unicode (e.g. decoded page response using stated charset) and non-unicode data (e.g. raw page response), while Python 3 doesn't have.

Good reference: http://lucumr.pocoo.org/2010/1/7/pros-and-cons-about-python-3/

@inquisb inquisb closed this Feb 15, 2013
@stamparm stamparm was assigned Jul 17, 2013
@badbob
badbob commented Jul 16, 2015

Is there any news for this issue? Does Python 3.4 have required functionality?

@stamparm
Member

@badbob I would say no, but that's my opinion. Only small projects are prone to conversion from 2 to 3. I have a feeling that this is a futile task for sqlmap.

@badbob
badbob commented Jul 18, 2015

Looks like the only way to reuse sqlmap code in Python 3 solutions is a REST API. Thanks for developers sqlmap has it. I can't see any other variant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment