Why not Python 3 for developing

Hello ERPNext and users,

as a Python, Frappé and ERPNext beginner, I was wondering, why you did not use Python 3 for developing those great framework and apps. Is there any reason?

Kind regards

Christoph

1 Like

Ubuntu 16.04 LTS will indeed drop python2 as the default version. (it will still be available but not by default)

@ci2016, can you explain which feature of Python3 do you need, that Python 2.7.6 dont can help you?

I can’t. It’s just about learning more about Frappé and their decisions. There are some features in Python3, which look nice, but I do not think there is something, what Python 2.x can’t do.

The point that Ubuntu will be dropping python2 as default version, which @Francois_Ifitwala already mentioned, is interesting though.

@ci2016, frappe is made in Python 2, because this project started in 2005, and is Open Source since 2008, so, in 2005, the active python version was 2.3, since this, frappe increased a lot of resources and 3rd party libs, currently I believe that the team, is focused in reduce the number of active issues, instead of look for changes to will afect directly the number of issues.

Maybe in the future, Python 3 will be included naturaly in the project!

3 Likes

@ci2016 yeah we could do Python3, its just going to be a great hassle getting everyone to upgrade.

We expect users to keep upgrading regularly, so this might have to be a major release. We will need to install a new python, spawn new ENVs for benches and get only Python3 compliant libraries.

CC @pdvyas

1 Like

@rmehta @max_morais_dmm Thank you for your replies.

@ci2016 you will see as you continue your journey in the Python world that Python3 or Python27 seems to be almost a religious question. The leadership of Python endorses Python3 while the community is still stuck in 2.7.

From what I can tell in most cases it’s the “never touch a running system” principle and its not assured that all the third party packages Frappe uses will work with Python3.

I am sure Python3 will have to happen some time, also for ERPNext and Frappe :smile:

1 Like

Butting in,

Porting might take a month of effort if not more and would result in zero new features. The Python2 end of life has got an extension and we should do it before 2020, peps: 76d43e52d978

This project should be on the foundation’s list, along with PostgreSQL migration.

@rmehta, upgrading should be manageable, we did it in the past with Python2.7 with lesser control of the environment. We have bench with virtualenv now :wink:

:+1:

3 Likes

Python3.6 is a major release. It has lot of improvements. A dictionary object that will take 300kb in Python2.7 will now take only 100 kb in Python3.6. So there is 200% memory reduction.

8 Likes

Also, Security. Python dicts < 3.4 actually have a real security issue.

A group of researchers were able to block the server cpu for 7 minutes straight.

3 Likes

Unicode support in python3 is what we are seeing as a desirable feature.

2 Likes

@JasonBrowne , python 2 already supports unicode, and as a Portuguese native speaker, I use the interface and input data into ERPNext without any kind of problem, using utf-8 (unicode)

1 Like

Yes, but it has to be implemented, in Python 3 it’s native.

2 Likes

@dfermiumlabs, I dont will aprofundate too much about that discussion, but before python3 existence, how do you think developers have made to use unicode in Python applications?

If you use frappe framework, it’s transparent for you!

And if any developer don’t understand about enconding, I don’t think that will be the standard or the missing standard support of utf-8 into a language that will make any kind of difference or prevent issues about enconding in his/her development, due the fact that utf-8 is only one, in bellow list!

437
850
852
855
857
860
861
862
863
865
866
869
ANSI_X3.4-1968
ANSI_X3.4-1986
ARABIC
ARMSCII-8
ASCII
ASMO-708
ATARI
ATARIST
BIG-5
BIG-FIVE
BIG5
BIG5-2003
BIG5-HKSCS
BIG5-HKSCS:1999
BIG5-HKSCS:2001
BIG5-HKSCS:2004
BIG5HKSCS
BIGFIVE
C99
CHINESE
CN
CN-BIG5
CN-GB
CN-GB-ISOIR165
CP-GR
CP-IS
CP1046
CP1124
CP1125
CP1129
CP1133
CP1161
CP1162
CP1163
CP1250
CP1251
CP1252
CP1253
CP1254
CP1255
CP1256
CP1257
CP1258
CP1361
CP154
CP367
CP437
CP737
CP775
CP819
CP850
CP852
CP853
CP855
CP856
CP857
CP858
CP860
CP861
CP862
CP863
CP864
CP865
CP866
CP869
CP874
CP922
CP932
CP936
CP943
CP949
CP950
CSASCII
CSBIG5
CSEUCKR
CSEUCPKDFMTJAPANESE
CSEUCTW
CSGB2312
CSHALFWIDTHKATAKANA
CSHPROMAN8
CSIBM1161
CSIBM1162
CSIBM1163
CSIBM855
CSIBM857
CSIBM860
CSIBM861
CSIBM863
CSIBM864
CSIBM865
CSIBM866
CSIBM869
CSISO14JISC6220RO
CSISO159JISX02121990
CSISO2022CN
CSISO2022JP
CSISO2022JP2
CSISO2022KR
CSISO57GB1988
CSISO58GB231280
CSISO87JISX0208
CSISOLATIN1
CSISOLATIN2
CSISOLATIN3
CSISOLATIN4
CSISOLATIN5
CSISOLATIN6
CSISOLATINARABIC
CSISOLATINCYRILLIC
CSISOLATINGREEK
CSISOLATINHEBREW
CSKOI8R
CSKSC56011987
CSKZ1048
CSMACINTOSH
CSPC775BALTIC
CSPC850MULTILINGUAL
CSPC862LATINHEBREW
CSPC8CODEPAGE437
CSPCP852
CSPTCP154
CSSHIFTJIS
CSUCS4
CSUNICODE
CSUNICODE11
CSUNICODE11UTF7
CSVISCII
CYRILLIC
CYRILLIC-ASIAN
DEC-HANYU
DEC-KANJI
ECMA-114
ECMA-118
ELOT_928
EUC-CN
EUC-JISX0213
EUC-JP
EUC-KR
EUC-TW
EUCCN
EUCJP
EUCKR
EUCTW
EXTENDED_UNIX_CODE_PACKED_FORMAT_FOR_JAPANESE
GB18030
GB2312
GBK
GB_1988-80
GB_2312-80
GEORGIAN-ACADEMY
GEORGIAN-PS
GREEK
GREEK8
HEBREW
HP-ROMAN8
HZ
HZ-GB-2312
IBM-1161
IBM-1162
IBM-1163
IBM-CP1133
IBM1161
IBM1162
IBM1163
IBM367
IBM437
IBM775
IBM819
IBM850
IBM852
IBM855
IBM857
IBM860
IBM861
IBM862
IBM863
IBM864
IBM865
IBM866
IBM869
ISO-10646-UCS-2
ISO-10646-UCS-4
ISO-2022-CN
ISO-2022-CN-EXT
ISO-2022-JP
ISO-2022-JP-1
ISO-2022-JP-2
ISO-2022-JP-3
ISO-2022-KR
ISO-8859-1
ISO-8859-10
ISO-8859-11
ISO-8859-13
ISO-8859-14
ISO-8859-15
ISO-8859-16
ISO-8859-2
ISO-8859-3
ISO-8859-4
ISO-8859-5
ISO-8859-6
ISO-8859-7
ISO-8859-8
ISO-8859-9
ISO-CELTIC
ISO-IR-100
ISO-IR-101
ISO-IR-109
ISO-IR-110
ISO-IR-126
ISO-IR-127
ISO-IR-138
ISO-IR-14
ISO-IR-144
ISO-IR-148
ISO-IR-149
ISO-IR-157
ISO-IR-159
ISO-IR-165
ISO-IR-166
ISO-IR-179
ISO-IR-199
ISO-IR-203
ISO-IR-226
ISO-IR-230
ISO-IR-57
ISO-IR-58
ISO-IR-6
ISO-IR-87
ISO646-CN
ISO646-JP
ISO646-US
ISO8859-1
ISO8859-10
ISO8859-11
ISO8859-13
ISO8859-14
ISO8859-15
ISO8859-16
ISO8859-2
ISO8859-3
ISO8859-4
ISO8859-5
ISO8859-6
ISO8859-7
ISO8859-8
ISO8859-9
ISO_646.IRV:1991
ISO_8859-1
ISO_8859-10
ISO_8859-10:1992
ISO_8859-11
ISO_8859-13
ISO_8859-14
ISO_8859-14:1998
ISO_8859-15
ISO_8859-15:1998
ISO_8859-16
ISO_8859-16:2001
ISO_8859-1:1987
ISO_8859-2
ISO_8859-2:1987
ISO_8859-3
ISO_8859-3:1988
ISO_8859-4
ISO_8859-4:1988
ISO_8859-5
ISO_8859-5:1988
ISO_8859-6
ISO_8859-6:1987
ISO_8859-7
ISO_8859-7:1987
ISO_8859-7:2003
ISO_8859-8
ISO_8859-8:1988
ISO_8859-9
ISO_8859-9:1989
JAVA
JIS0208
JISX0201-1976
JIS_C6220-1969-RO
JIS_C6226-1983
JIS_X0201
JIS_X0208
JIS_X0208-1983
JIS_X0208-1990
JIS_X0212
JIS_X0212-1990
JIS_X0212.1990-0
JOHAB
JP
KOI8-R
KOI8-RU
KOI8-T
KOI8-U
KOREAN
KSC_5601
KS_C_5601-1987
KS_C_5601-1989
KZ-1048
L1
L10
L2
L3
L4
L5
L6
L7
L8
LATIN-9
LATIN1
LATIN10
LATIN2
LATIN3
LATIN4
LATIN5
LATIN6
LATIN7
LATIN8
MAC
MACARABIC
MACCENTRALEUROPE
MACCROATIAN
MACCYRILLIC
MACGREEK
MACHEBREW
MACICELAND
MACINTOSH
MACROMAN
MACROMANIA
MACTHAI
MACTURKISH
MACUKRAINE
MS-ANSI
MS-ARAB
MS-CYRL
MS-EE
MS-GREEK
MS-HEBR
MS-TURK
MS936
MS_KANJI
MULELAO-1
NEXTSTEP
PT154
PTCP154
R8
RISCOS-LATIN1
RK1048
ROMAN8
SHIFT-JIS
SHIFT_JIS
SHIFT_JISX0213
SJIS
STRK1048-2002
TCVN
TCVN-5712
TCVN5712-1
TCVN5712-1:1993
TDS565
TIS-620
TIS620
TIS620-0
TIS620.2529-1
TIS620.2533-0
TIS620.2533-1
UCS-2
UCS-2-INTERNAL
UCS-2-SWAPPED
UCS-2BE
UCS-2LE
UCS-4
UCS-4-INTERNAL
UCS-4-SWAPPED
UCS-4BE
UCS-4LE
UHC
UNICODE-1-1
UNICODE-1-1-UTF-7
UNICODEBIG
UNICODELITTLE
US
US-ASCII
UTF-16
UTF-16BE
UTF-16LE
UTF-32
UTF-32BE
UTF-32LE
UTF-7
UTF-8
VISCII
VISCII1.1-1
WINBALTRIM
WINDOWS-1250
WINDOWS-1251
WINDOWS-1252
WINDOWS-1253
WINDOWS-1254
WINDOWS-1255
WINDOWS-1256
WINDOWS-1257
WINDOWS-1258
WINDOWS-874
WINDOWS-936
X0201
X0208
X0212

We hit a bug in importing our chart of accounts because it was UTF-8 encoded. Imported fine when we converted our file to ASCII. So, maybe not so automatic/transparent as you might say? If ERPnext were using Python 3, this certainly would not be an issue.

2 Likes

It builds and runs on Python 3.x. Of course, doing a bit of encoding is far easier than upgrading all current users (and codebase) to py-3.x. Of course, it will come in time, especially with some help!

In the meantime, if you import direct to db, it’s a no-brainer to config the developer environment to ensure that you or any foreign language contractors or one-off datasets have the login clients set-up for UTF-8, and the server can enforce it :wink:

You kids and your unicode :stuck_out_tongue:

-matto

I think it’s the case if a file doesn’t contain the charset tag on the beginning of the file. Since I am no python expert, I can’t say it with 100% confidence.

However, as I saw in some changes, they are preparing Frappe/ERPNext for Python 3 already.

1 Like

Closing this topic since