Xqt added a comment.

  Thanks @Multichill for your comment. Infact keeping 2.7 support means more 
developing time keeping backward compatible instead of using that time for** 
bringing forward the library** with bugfixes new features and don't forget 
reviewing. We have now 170 open patches ready to submit.
  
  **EOL** of Python 2.7 **is also important** for us because the most external 
libraries are also giving up Python 2 support (including pip btw). This means 
no further support, no bugfixes no new features. Ok you can say you never 
update libraries like requests or sseclient and what care about other stuff or 
about tests. On the other hand you don't need to update your bot. You can use 
every stable release submitted with their own tag; ask the HISTORY.rst file for 
their changes. Surely you will find a release running with Python 2.6. But this 
is not actually tested with current environments and external library 
dependencies.
  
  Test are also a notable point for some difficult problems, maybe a minor one. 
Currently complete tests need up to 4 hours to pass; dropping Python 2.7** 
decreases testing time** by 30%.
  
  There are a lot of improvements in Python 3 we cannot use currently like 
**ipaddress**, **Pathlib** or **Enum** (Enum is the preferred base for a 
Namespace implementation for example to simplify the code and make it more 
robust). OK there are libraries which can backport these libaries to Python 
2.7. But not doing this also leads to breakage if they are mandatory.
  
  Coroutines are available in Python 2.7 but simplified in Python 3. The 
addition of the **asyncio** library makes writing asynchronous programs easier.
  
  **Souped unpacking** is another advantage and could solve the 
getVersionHistory bug T136513 <https://phabricator.wikimedia.org/T136513> 
(where core implementation is not compatible with core) very easily for 
example. Currently we have a breaking change when porting compat to core 
without any hint how to proceed.
  
  **Chainging exceptions** can help for bug fixes because it gives a more 
detailes error report.
  
  Python 2 the concept of bytes and strings were pretty much interchangeable, 
and both came under the **str** type. In result we have still some 
UnicodeDecodeError bugs inside the code.
  
  Syntax changes of accessing parent **classes** and creating classes from 
metaclasses are heavy in Python 2 but simplier in Python 3.
  
  There are other syntactical changes e.g. related for interators/generators 
which are different on Python 2 and 3
  
  A lot of buildins uses **iterators instead of lists **which save significant 
amounts of memory.
  
  There are still other reasons to upgrade to Python 3 – not just because of 
the convenience of new features, but because random, obscure bugs in the 
language where fixed in Python 3 and other libraries depending from it, 
Pywikibot is not a never-need-to-change codebase because MediaWiki also is 
under development too. **Therefore we should find a way to drop the old and 
force the new** imho.
  
  Sure dropping Python 2.7 should not be made hastily but developers using 
pywikibot also have their own responsibility and I don't  agree that we have to 
support all deprecated items for the next few decades. There is always the way 
back to use an older release if the framework development is too fast. But I 
don't beleave that this is true when remembering that a lot of bugs can be 
solved immediately.

TASK DETAIL
  https://phabricator.wikimedia.org/T213287

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Xqt
Cc: Multichill, zhuyifei1999, Dalba, Eatcha, KTC, Lokal_Profil, Dvorapa, 
Aklapper, pywikibot-bugs-list, Xqt, Viztor, DannyS712, Wenyi, Tbscho, MayS, 
Framawiki, Mdupont, JJMC89, Altostratus, Avicennasis, mys_721tx, jayvdb, Masti, 
Alchimista, Rxy
_______________________________________________
pywikibot-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/pywikibot-bugs

Reply via email to