Since we have plural support for i18n py2.4 is deprecated and does not fully support it except in a default way regarding to bug #3433609. Pre 2.5 releases cannot use plural.py and IMHO we shouldn't downgrade it (look at the code for the reason why). Maybe there is only this guy who is using that old stuff. I guess we should move a copy of the current 2.4 compatible release to the archive without further updates (and maybe make it available at pywikipedia nightly for downloading).
2.6 should be the new minimum version. But we have the unicode bug with all releases from 2.5 upto 2.7.1. This means 2.7.2 is the release which is strongly recommended I think.
Regards xqt
2012/2/29 info@gno.de
Since we have plural support for i18n py2.4 is deprecated
"Alea iacta est!" – sagte der Caesar. :-)
This means 2.7.2 is the release which is strongly recommended I think.
Great word, let's start that!
Please have a look at https://www.mediawiki.org/wiki/Pywikipediabot/Survey2012 all, and edit if neccessary. If nobody disagrees for a few days, I will start the project.
My plan is to write a notice to wikipedia.py somewhere around line 7875 where initial checks are. This will check the Python version and look for a config variable in order to not annoy people who have already visited the MW page. But this variable will be published on MW only. :-)
btw keep in mind that toolserver uses 2.7.1 but unicode bug is fixed there.
Regards xqt
----- Original Nachricht ---- Von: Bináris wikiposta@gmail.com An: Pywikipedia discussion list pywikipedia-l@lists.wikimedia.org Datum: 29.02.2012 12:56 Betreff: Re: [Pywikipedia-l] Proposal for farewell of good old Python 2.4
2012/2/29 info@gno.de
Since we have plural support for i18n py2.4 is deprecated
"Alea iacta est!" ? sagte der Caesar. :-)
This means 2.7.2 is the release which is strongly recommended I think.
Great word, let's start that!
Please have a look at https://www.mediawiki.org/wiki/Pywikipediabot/Survey2012 all, and edit if neccessary. If nobody disagrees for a few days, I will start the project.
My plan is to write a notice to wikipedia.py somewhere around line 7875 where initial checks are. This will check the Python version and look for a config variable in order to not annoy people who have already visited the MW page. But this variable will be published on MW only. :-)
-- Bináris
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Please have a look at https://www.mediawiki.org/wiki/Pywikipediabot/Survey2012 all, and edit if neccessary. If nobody disagrees for a few days, I will start the project.
My plan is to write a notice to wikipedia.py somewhere around line 7875 where initial checks are. This will check the Python version and look for a config variable in order to not annoy people who have already visited the MW page. But this variable will be published on MW only. :-)
I think this is a somewhat BIG DECISION and you should wait more than "a few days"! E.g. I myself noticed this just by accident.
Additionally I do not think it is appropriate to change the code (wikipedia.py, config.py, ...) just to add a notice for such a "short term survey" (as you planed it). Either you add this notice permanently (which would make sense since the support for all earlier version is up to be dropped forever) or you have to do this survey for much longer time... (in earlier mails something around august was mentioned - I think this is much more sensitive - in my oppinion you could even wait till august '13 ;)
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.
I would agree with the first statement! We should not waste time in actively remove code that handles older python versions. Also because other might still want to use older python versions (we do not support those anymore does NOT mean we activley have to prevent their usage!).
If you want to be that radical, I assume you should change to use the rewrite branch - since as I am aware there a more radical approach is implemented already (with cleaner code and and and).
2012/2/29 Dr. Trigon dr.trigon@surfeu.ch
I think this is a somewhat BIG DECISION and you should wait more than "a few days"! E.g. I myself noticed this just by accident.
You may misunderstand me, this relies to starting the survey, not to deprecating any version! We have just started to talk about this. The survey page is the current proposal, and everybody will notice it when gets a nice colour warning on the screen. :-)
The survey page is for those who are not members of this list. We can directly talk about it here and that page is a help in our decision which should be made on this mailing list as the primary forum of developers. (My call for edit it aimed editing the mboxes on top.)
Additionally I do not think it is appropriate to change the code (wikipedia.py, config.py, ...) just to add a notice for such a "short term survey" (as you planed it). Either you add this notice permanently (which would make sense since the support for all earlier version is up to be dropped forever) or you have to do this survey for much longer time... (in earlier mails something around august was mentioned - I think this is much more sensitive - in my oppinion you could even wait till august '13 ;)
Well, I have never spoken about the actual date of ceasing support for old versions. When I told this two/few months I meant it as a time for reading opinions on survey page, making a decision and creating a roadmap. Possibly with different deadlines for old versions depending on number of users. The transitial time will begin then. Is that OK like this? A key in user-config.py is useful for users who are annoyed by reading about the survey at each run. After we made our decison and published it on MW, we may write another warning that disregards this suppresssurvey key and it will be reasonable to leave permanently. (In the way as @deprecated does now.)
Having read your notes on toolserver, I think the warning should appear only for version < 2.7.1, and not for 2.7.1 itself as it is widely used (if we already know it has to remain, a survey is unneccessary).
I would agree with the first statement! We should not waste time in
actively remove code that handles older python versions.
I think cleaner code is always a programmer's preference and not waste of time (read the quotation herehttps://www.mediawiki.org/wiki/User:Bin%C3%A1ris), but let's talk about it. What about the Python 2.3 stuff in wikipedia.py? Any unneccessary old rubbish will make debugging harder. You may persuade me to leave it untouched, but from the point the decision is made I would like to write new code freely, either it works in ancient versions or not. (My favourite topic is "this if A else that" which is very practical. The magic we do sometimes with 2-element lists indexed by a logical value is marvellous, but much harder to read and uses a reversed logic having 'False' branch before 'True'. Or why not use a dictionary compehensionhttp://docs.python.org/whatsnew/2.7.html#python-3-1-featuresif appropriate?)
I tell you my secret purpose: after disconnecting 2.4 and 2.5 modules from our space station, I would like to bring the code as close to 3.x as possible. Someday we will face the task to switch to 3.x (trunk is not likely to survive this) and we may make it easier if from now on we try to keep this in mind when coding.
Also because other might still want to use older python versions (we do not support those anymore does NOT mean we activley have to prevent their usage!).
I like Xqt's idea to make a snapshot of the current version ("current" means the time we will determine) that will run forever.
If you want to be that radical, I assume you should change to use the rewrite branch - since as I am aware there a more radical approach is implemented already (with cleaner code and and and).
There are two reasons I am a bit averse to it: as far as I know it needs installing and I like the purity of trunk to simply copy it, and the last news I read on this list was that rewrite did not read XML dump that is very important for me, what about this? Sure, one day I will have to change, but here I don't speak about my personal needs -- as far as trunk is supported, its code management is our common interest.
On 29 February 2012 15:11, Bináris wikiposta@gmail.com wrote:
There are two reasons I am a bit averse to it: as far as I know it needs installing and I like the purity of trunk to simply copy it, and the last news I read on this list was that rewrite did not read XML dump that is very important for me, what about this? Sure, one day I will have to change, but here I don't speak about my personal needs -- as far as trunk is supported, its code management is our common interest.
No, it doesn't need installing. Maybe it doesn't have an XML reader yet. {{sofixit}}.
The problem with trunk is that it is a big heap of smelly code. There are no tests, so every time you change something, there is a large chance you will actually break something without noticing - until someone files a bug report. Because of this, porting it to 3.x is also neigh-impossible: how are you going to test everything actually works?
So as far as the future of the framework is concerned, blocking new features in trunk, and actively porting stuff to the rewrite (and adding tests for everything!) would be much, much better.
Merlijn
2012/2/29 Merlijn van Deen valhallasw@arctus.nl
No, it doesn't need installing. Maybe it doesn't have an XML reader yet. {{sofixit}}.
Let's have a deal. If someone writes the dump reader, I promise to try rewrite and familiarize myself with it. :-) My main field of botwork is text replacements and spelling correctionshttp://wikimania2012.wikimedia.org/wiki/Submissions/Efficient_and_flexible_text_manipulation,_spelling_correction_and_page_collections_with_Pywikibotwith replace.py (as I am * ill* of spelling mistakes people do all the time) thus dump is a primary tool for me.
So as far as the future of the framework is concerned, blocking new features in trunk, and actively porting stuff to the rewrite (and adding tests for everything!) would be much, much better.
Well, tests is a big lesson for me to learn. I would appreciate an introduction to them as they are really useful.
On 29 February 2012 15:30, Bináris wikiposta@gmail.com wrote:
Let's have a deal. If someone writes the dump reader, I promise to try rewrite and familiarize myself with it. :-)
;-) Unfortunately, I don't have large amounts of time, but I'll see what I can do.
My main field of botwork is text replacements and spelling correctionshttp://wikimania2012.wikimedia.org/wiki/Submissions/Efficient_and_flexible_text_manipulation,_spelling_correction_and_page_collections_with_Pywikibotwith replace.py (as I am
- ill* of spelling mistakes people do all the time) thus dump is a
primary tool for me.
Of course. XML support is something that definitely should be added.
Well, tests is a big lesson for me to learn. I would appreciate an
introduction to them as they are really useful.
The introduction is quite simple: instead of manually testing, you create
a script that tests for you. Even though you have this in different flavours ('unit testing', 'integration testing', etc), the idea is the same: because you create an automatic test, you can check a week, a month or even 5 years later whether the feature you added or bugfix you made still works as it should. Combined with testing before commit / automatic testruns ('continuous integration'), this makes bugs much easier to prevent.
And this is my last mail for tonight ;-)
Best, Merlijn
;-) Unfortunately, I don't have large amounts of time, but I'll see what I can do.
OK, so my Challenge Accepted image didn't survive all the scrubbers, it seems. Please imagine this image before the ;-) : http://fortnightlitpress.files.wordpress.com/2011/05/knapp01.png
(this is really my last mail for tonight :p)
Merlijn
There are two reasons I am a bit averse to it: as far as I know it needs installing and I like the purity of trunk to simply copy it, and the last news I read on this list was that rewrite did not read XML dump that is very important for me, what about this? Sure, one day I will have to change, but here I don't speak about my personal needs -- as far as trunk is supported, its code management is our common interest.
No, it doesn't need installing. Maybe it doesn't have an XML reader
Really? comm.threadedhttp e.g. needs to be installed otherwise you get "Error: You need the python module setuptools to use this module"
xqt
On 29 February 2012 17:36, info@gno.de wrote:
No, it doesn't need installing. Maybe it doesn't have an XML reader
Really? comm.threadedhttp e.g. needs to be installed otherwise you get "Error: You need the python module setuptools to use this module"
No, you need setuptools installed (and you should have that in any case), and you should have httplib2 installed. That's not the same as needing to install the framework, as far as I am concerned - after all, you need the json module for python <= 2.6 (?) for trunk, too.
Best, Merlijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29.02.2012 15:21, Merlijn van Deen wrote:
No, it doesn't need installing. Maybe it doesn't have an XML reader yet. {{sofixit}}.
The problem with trunk is that it is a big heap of smelly code. There are no tests, so every time you change something, there is a large chance you will actually break something without noticing - until someone files a bug report. Because of this, porting it to 3.x is also neigh-impossible: how are you going to test everything actually works?
I could write here {{sofixit}} too... ;)) (if a day could last longer than 24h... ;)
So as far as the future of the framework is concerned, blocking new features in trunk, and actively porting stuff to the rewrite (and adding tests for everything!) would be much, much better.
I agree with you, except of one point; why blocking features in trunk? To speed up migration to rewrite? I would propose starting the migration from trunk to rewrite and block the new features related to already migrated parts only!! That should work too and would make migration easier and smoother. Else you would have different sizes of code bunches to migrate (from tiny up to huge) changing at random depending what feature to implement.
Btw: Are all - even e.g. non-API - functions allowed to be migrated to rewrite?
Greetings DrTrigon
On 29 February 2012 17:44, Dr. Trigon dr.trigon@surfeu.ch wrote:
I could write here {{sofixit}} too... ;)) (if a day could last longer than 24h... ;)
Yes. Except that creating and XML lib in the rewrite is a lot less work than creating tests and cleaning up trunk (and after that, you pretty much end up where the rewrite is now).
I agree with you, except of one point; why blocking features in trunk? To speed up migration to rewrite?
For the same reason you block features after releasing a version: because new features introduce bugs. However, we might want to distinguish between the framework and bots here - it should be OK to add features to bots, as the rewrite did not clean up those parts (and adapting these few features should not be a huge issue).
Btw: Are all - even e.g. non-API - functions allowed to be migrated to
rewrite?
Yes. However, non-API functions (e.g. Special:Export or XML) should not go into the APISite class but in the, say, ClassicSite and XMLSite class.
Best, Merlijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Yes. Except that creating and XML lib in the rewrite is a lot less work than creating tests and cleaning up trunk (and after that, you pretty much end up where the rewrite is now).
Good point indeed. I am curious; I think to remember that your coverage report was at about 39% - I assume you did it for rewrite. Since I did the same for DrTrigonBot framework, which is essential pywikipedia with trunk some additional code, and had a coverage of about 40%. So what am I missing here? Since it looks to me that there are pretty much the same tests...?!?
For the same reason you block features after releasing a version: because new features introduce bugs. However, we might want to distinguish between the framework and bots here - it should be OK to add features to bots, as the rewrite did not clean up those parts (and adapting these few features should not be a huge issue).
Does this mean currently we have feature block in rewrite but not in trunk? Are the treated different?
Yes. However, non-API functions (e.g. Special:Export or XML) should not go into the APISite class but in the, say, ClassicSite and XMLSite class.
That are really good news to me! Thanks! :)) (last I heared was that API calls will be supported only in rewrite... or... may be I was "miss-hearing"... ;)
Why would there be 'features in trunk that never ever make it into rewrite'? The entire point of the rewrite was to be able to have features implemented cleanly, where every feature in trunk is currently a hack.
So this means all features in trunk are continously ported rewrite in order to catch up?! Which would be good news, since then some time in future we all can easily (more or less I think) convert to rewrite!
Greetings DrTrigon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
You may misunderstand me, this relies to starting the survey, not to deprecating any version! We have just started to talk about this. The survey page is the current proposal, and everybody will notice it when gets a nice colour warning on the screen. :-)
The survey page is for those who are not members of this list. We can directly talk about it here and that page is a help in our decision which should be made on this mailing list as the primary forum of developers. (My call for edit it aimed editing the mboxes on top.)
Yes, I definately missunderstood you! Good news for both of us! ;)
Well, I have never spoken about the actual date of ceasing support for old versions. When I told this two/few months I meant it as a time for reading opinions on survey page, making a decision and creating a roadmap. Possibly with different deadlines for old versions depending on number of users. The transitial time will begin then. Is that OK like this? A key in user-config.py is useful for users who are annoyed by reading about the survey at each run. After we made our decison and published it on MW, we may write another warning that disregards this suppresssurvey key and it will be reasonable to leave permanently. (In the way as @deprecated does now.)
Having read your notes on toolserver, I think the warning should appear only for version < 2.7.1, and not for 2.7.1 itself as it is widely used (if we already know it has to remain, a survey is unneccessary).
That makes sense!! This way you can also propose the future change to 2.7.2 which is a need because of the unicode bug - but has to be delayed until - at least - the toolserver has switched. And we have a central and permanent page to explain how to use older versions (according to Xqt's idea to make a snapshot of the current version you also mentioned) and to do further changes of that kind in future (e.g. to py3 ;).
I think cleaner code is always a programmer's preference and not waste of time (read the quotation here https://www.mediawiki.org/wiki/User:Bin%C3%A1ris), but let's talk about it. What about the Python 2.3 stuff in wikipedia.py? Any unneccessary old rubbish will make debugging harder. You may persuade me to leave it untouched, but from the point the decision is made I would like to write new code freely, either it works in ancient versions or not. (My favourite topic is "this if A else that" which is very practical. The magic we do sometimes with 2-element lists indexed by a logical value is marvellous, but much harder to read and uses a reversed logic having 'False' branch before 'True'. Or why not use a dictionary compehension http://docs.python.org/whatsnew/2.7.html#python-3-1-features if appropriate?)
This is what i wanted to cover with the proposal of the "we keep it until it sucks" position. If you work with that code and feel it becomes more handy when converting to newer python; do that! If debugging improves change the code! ;) But do not start searching all the code for old snipplets to wipe them out explicetly. (since you could end up spending a lot of time to convert code very rarely used at all or else...)
I tell you my secret purpose: after disconnecting 2.4 and 2.5 modules from our space station, I would like to bring the code as close to 3.x as possible. Someday we will face the task to switch to 3.x (trunk is not likely to survive this) and we may make it easier if from now on we try to keep this in mind when coding.
Why "is trunk not likely to survive this"? I have to admitt (because lack of time and need of the new features) I did not really look into py3 at all until now. But as far as I know a conversion should not be that hard at all... It can be done step by step, first making the code run at least and then polish it up... Is there something I am not aware of?
I like Xqt's idea to make a snapshot of the current version ("current" means the time we will determine) that will run forever.
I like this too!
There are two reasons I am a bit averse to it: as far as I know it needs installing and I like the purity of trunk to simply copy it, and the last news I read on this list was that rewrite did not read XML dump that is very important for me, what about this? Sure, one day I will have to change, but here I don't speak about my personal needs -- as far as trunk is supported, its code management is our common interest.
Last I heard was there are feature in trunk that will never ever make it into rewrite - so I will never ever have to chance to switch... (which is a pitty)
Greetings DrTrigon
On 29 February 2012 17:32, Dr. Trigon dr.trigon@surfeu.ch wrote:
Why "is trunk not likely to survive this"? I have to admitt (because lack of time and need of the new features) I did not really look into py3 at all until now. But as far as I know a conversion should not be that hard at all... It can be done step by step, first making the code run at least and then polish it up... Is there something I am not aware of?
There are no tests.
As such, there is no way to check if your conversion is actually correct.
As such, it makes much more sense to start with a version of the library that has automatic tests (hint: rewrite), so that you can change syntax without the fear of breaking everything.
Last I heard was there are feature in trunk that will never ever make it
into rewrite - so I will never ever have to chance to switch... (which
is a pitty)
Such as?
Why would there be 'features in trunk that never ever make it into rewrite'? The entire point of the rewrite was to be able to have features implemented cleanly, where every feature in trunk is currently a hack.
Best, Merlijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
2.6 should be the new minimum version. But we have the unicode bug with all releases from 2.5 upto 2.7.1. This means 2.7.2 is the release which is strongly recommended I think.
...as mentioned fedora uses newer python but "just" 2.7.1... I think you are right and the day we can go officially to 2.7.2 will become a "delightful holiday", but meanwhile I think this is slightly more radical than useful. Even the toolserver still uses a patched 2.7.1 (but 2.7.1 still... ;)) In my environment the 2.7.1 seems to be the magic and only one important... :)
2012/2/29 Dr. Trigon dr.trigon@surfeu.ch
radical than useful. Even the toolserver still uses a patched 2.7.1 (but 2.7.1 still... ;)) In my environment the 2.7.1 seems to be the magic and only one important... :)
One thing is what we write above the survey, and the other is what we decide after. As this bug does not involve me, I personally will be satisfied with any 2.7 version.
What is the real difference between 2.7.1 and 2.7.2? A cannot find a detailed comparison on python.org.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
What is the real difference between 2.7.1 and 2.7.2? A cannot find a detailed comparison on python.org http://python.org.
Look at http://hg.python.org/cpython/raw-file/eb3c9b74884c/Misc/NEWS
(the first about 500 lines... I did not read them... ;)
2012/2/29 Dr. Trigon dr.trigon@surfeu.ch
What is the real difference between 2.7.1 and 2.7.2? A cannot find a detailed comparison on python.org http://python.org.
Look at http://hg.python.org/cpython/raw-file/eb3c9b74884c/Misc/NEWS
As far as I see, mainly bug fixes. argparse has some changes if it is interesting.
I have started the process: http://www.mediawiki.org/wiki/Special:Code/pywikipedia/9971
If you use an old Python and don't want to see the message, put this line into your user-config.py: suppresssurvey = True
Now we have nothing to do but wait for answers.
This guy says a certain error occurs under Python 2.7.2 and not under 2.6.5. We should understand this issue before deprecating 2.6.
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3507957...
2.6 should be the new minimum version. But we have the unicode bug with all releases from 2.5 upto 2.7.1. This means 2.7.2 is the release which is strongly recommended I think.
...as mentioned fedora uses newer python but "just" 2.7.1... I think you are right and the day we can go officially to 2.7.2 will become a "delightful holiday", but meanwhile I think this is slightly more radical than useful. Even the toolserver still uses a patched 2.7.1 (but 2.7.1 still... ;)) In my environment the 2.7.1 seems to be the magic and only one important... :)
What I said before ;) Unfortunately we cannot fix other previous 2.7.2 releases regarding unicode bug which means that code is running on owners risk (and I don't take responsibility to it ;)
xqt