Every now and then we face the problems of separate needs of this old Python version. See just my previous letter about async_put or the lack of a basic conditional expression. 2.5 is a point where many things are much simpler to handle. Time is going on its way and one day we noticed the calendar showed the 2012th year. 2.4 is just as an old lumber in the middle of the room you have to go round about all the time. Let's throw it out. Last time I proposed this there were voices saying some people are forced to use this historical version. I would like to know how big this problem is and if it is still the reality. So I created a page to collect these cases here: https://www.mediawiki.org/wiki/User:Bin%C3%A1ris/Python_2.4_review
I propose three steps:
1. Move the above mentiond page to public space, e.g. Manual:Pywikipediabot/Python 2.4 review 2. From now on (after a few days of discussion) wikipedia.py should check for sys.version and if it turns out to be <2.5, then display a warning and ask the user to visit this page and explain his/her reasons or just sign it. (I think we are not allowed to collect automated feedbacks so this is the only way.) 3. After 2 months we review this page and with this information we may decide what to do with 2.4, keep or deprecate. In better case we will be able to determine a deadline for upgrading, in the worse case I will sadly accept the importance of 2.4 for the future.
(I think we should have been talking about Python 3000 for quite a time, not 2.4.) Btw, I see some 2.3 related code remnants in wikipedia.py lines 144 to 154 of current version, although 2.3 is no more supported, AFAIK. Are they necessary?
On 24 February 2012 00:21, Bináris wikiposta@gmail.com wrote:
Last time I proposed this there were voices saying some people are forced to use this historical version.
I think the main problem lies with RHEL and CentOS, both of which still ship Python 2.4. However, people running these OS'es are probably also smart enough to be able to do a manual python build.
As far as I am concerned, we should maybe even bump the minimum version to 2.6, which is the version the current debian stable uses. 2.5 was released in august 2006 (!), 2.6 in october 2008.
I also like the idea of using a wiki for getting responses - it allows people to stay anonymous if they want (by making a new account).
As for a date: I suggest something a few months in the future, say july or august. This gives people some time to update.
Last but not least: not supported does not necessarily mean we have to actively remove bits that work around quirks for a certain version; rather, it means we won't fix bugs due to an old python version.
Best, Merlijn
2012/2/26 Merlijn van Deen valhallasw@arctus.nl
I think the main problem lies with RHEL and CentOS, both of which still ship Python 2.4. However, people running these OS'es are probably also smart enough to be able to do a manual python build.
I hope so. :-) And what do those guys at Red Hat think about Python?
As far as I am concerned, we should maybe even bump the minimum version to 2.6, which is the version the current debian stable uses. 2.5 was released in august 2006 (!), 2.6 in october 2008.
Strong support, I just was not brave enough to propose that directly. 2.6 is the first version with Python 3000 features backported, and it is very close to 2.7 which may hope a longer support time. It may be a base to write code as close to 3.x syntax as possible.
As for a date: I suggest something a few months in the future, say july or august. This gives people some time to update.
That's OK, I suggested 2 month for deciding the further steps, not to deprecate 2.4 immediately.
Last but not least: not supported does not necessarily mean we have to actively remove bits that work around quirks for a certain version; rather, it means we won't fix bugs due to an old python version.
I would be more radical. What I would like to see is a cleaner code without unneccessary branches, and free use of some basic tools such as conditional (x if cond. else y) that is widely used in the world of programming. But let's see the survey first.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 27.02.2012 19:38, Bináris wrote:
2012/2/26 Merlijn van Deen <valhallasw@arctus.nl mailto:valhallasw@arctus.nl>
I think the main problem lies with RHEL and CentOS, both of which still ship Python 2.4. However, people running these OS'es are probably also smart enough to be able to do a manual python build.
I hope so. :-) And what do those guys at Red Hat think about Python?
...in the experimental or open branch "fedora" they use 2.7. ;))
On 27 February 2012 20:33, Dr. Trigon dr.trigon@surfeu.ch wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 27.02.2012 19:38, Bináris wrote:
2012/2/26 Merlijn van Deen <valhallasw@arctus.nl mailto:valhallasw@arctus.nl>
I think the main problem lies with RHEL and CentOS, both of which still ship Python 2.4. However, people running these OS'es are probably also smart enough to be able to do a manual python build.
I hope so. :-) And what do those guys at Red Hat think about Python?
...in the experimental or open branch "fedora" they use 2.7. ;))
not just that, also the new RHEL 6 (which is out since 2010-11-10 according to WP) is using python 2.6
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9L2nIACgkQAXWvBxzBrDDYxwCguoGyaUlGgIkKnnsAWN7NjkFt DIcAoODOdSf8ONPyR4yBnogWaHlr4cIO =1JcU -----END PGP SIGNATURE-----
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
pywikipedia-l@lists.wikimedia.org