Python 3.x Support

[GoogleCodeExporter]

PassLib definitely needs to support Python 3. 

The main issue is, as always, ensuring unicode encoding/decoding is handled 
correctly. 

Original issue reported on code.google.com by elic%astllc.org@gtempaccount.com on 25 Mar 2011 at 7:31

[GoogleCodeExporter]

On further study, b'' format support is essential for porting to Python 3. 
Python2.6 supports this string prefix, but Python2.5 does not.
Thus, making passlib compatible w/ 2to3 would require moving
the codebase to python 2.6, sprinkling in b'' prefixes,
and choosing one of the following -

1. abandon python 2.5, since it doesn't support b'' strings
2. complicate the python 2.5 build process by using a subset of the 3to2 
project to 
   strip out the b'' prefixes.

Original comment by elic%astllc.org@gtempaccount.com on 4 Apr 2011 at 5:10

[GoogleCodeExporter]

Original comment by elic%astllc.org@gtempaccount.com on 29 Apr 2011 at 7:31

• Changed state: Chatting

[GoogleCodeExporter]

Alternately, there appears to be a choice 3:

3. hack a preprocessor/macro system into 2to3, ala what SQLAlchemy does. 

This route might be more viable, and would allow maintaining py25 compatibility 
as-is. 

Original comment by elic%astllc.org@gtempaccount.com on 3 May 2011 at 7:27

[GoogleCodeExporter]

Original comment by elic%astllc.org@gtempaccount.com on 11 May 2011 at 7:00

• Changed state: Discussing

[GoogleCodeExporter]

Original comment by elic%astllc.org@gtempaccount.com on 11 May 2011 at 7:01

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Conversion: settled on choice 3; given that this seems to be working for 
SQLAlchemy; and that 2to3 does not reveal any fundamental flaws in the 
structure of the source code. 

-------------------------------------------

One last decision blocking work on this issue: 

Under py3, should encypted hashes be returned as ascii-encoded bytes, or as 
unicode?

1. Current Py2 behavior returns ascii-encoded bytes - want to remain compatible 
under Py2 regardless of Py3. 
2. stdlib crypt module seems to have chosen ascii-bytes under Py2, and unicode 
under Py3; though that module hasn't been actively engineered much, may have 
just be the behavior that happened due to automatic conversion. 
3. Would need to study use-cases before deciding on this (eg Django on py3, etc)

4. Regardless of the outcome of this, could also offer CryptContext option to 
encode/decode hashes as user desires, though this shouldn't be offered by the 
hashes themselves, in order to reduce complication of implementation. (separate 
enhancement?)

Original comment by elic%astllc.org@gtempaccount.com on 23 May 2011 at 4:17

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

After studying Django-3k project's password code, it looks like they adopted a 
behavior similar to crypt; so going with similar to that for passlib:

1. input passwords can be unicode or bytes. unicode passwords will be encoded 
to utf-8 unless hash specifies a unicode policy. bytes passwords will be 
treated as a opaque, allowing app to use custom locale encoding for passwords 
if needed. _this matches current py2 behavior, and will not change for py3._

2. returned hashes will always be of type 'str'. under py2, these will be 7-bit 
ascii encoded bytes. under py3, these will be unicode objects. _This does not 
change current py2 behavior, but will require apps moving to py3 to handle 
unicode encoding if needed - though context objects should be given featuring 
allowing auto-encoding._

3. input hashes can be unicode or bytes. unicode hashes may be parsed directly, 
or encoded to 7bit ascii internally, depending on the algorithm. _This is 
current py2 behavior, and will not change for py3._ byte hashes are assumed to 
be 7 bit ascii, and will be decoded or parsed directly, depending on the 
algorithm. _This is current py2 behavior, and will not change for py3 - though 
assuming 7bit ascii may bite us in future, this is common case and compatible 
with py2; and apps which have issue can just decode before handing str to 
passlib._

This shouldn't result in any changes to existing py2 behavior; the main issue 
is going to be apps transitioning from py2->py3 and using passlib will have to 
be aware hashes are returned as unicode.

Original comment by elic%astllc.org@gtempaccount.com on 31 May 2011 at 8:29

[GoogleCodeExporter]

As of r3ffb915bd4fd, passlib can run under python3 (providing the source has 
been run through a moneypatched version of 2to3).

setup.py has been modified so that "python3.2 setup.py install" should take 
care of all this. 

hopefully have new release soon, once more testing & polishing has been done.

Original comment by elic%astllc.org@gtempaccount.com on 20 Jun 2011 at 10:06

• Changed state: Accepted

[GoogleCodeExporter]

Python 3 support has landed.

Original comment by elic%astllc.org@gtempaccount.com on 11 Jul 2011 at 6:20

• Changed state: Done

[GoogleCodeExporter]

Original comment by elic@astllc.org on 12 Sep 2011 at 2:29