Hi,
I worked a lot on a script that created a page under my bot's user page, finally after tests I renamed ithttp://hu.wikipedia.org/w/index.php?title=Wikip%C3%A9dia:Elavult_m%C3%A1svitasablonok&diff=12816525&oldid=12815108to project namespace. At the next run the bot worked 8 minutes (hard to wait if you want to work with the result), and finally stopped at the last moment instead of saving the page.
Sorry, I forgot to copy the screen, the essence is that it claimed my page to be *locked* (what I thought to be protected). I didn't understand, and I spent a lot of time with investigating and understanding what happened. The page was not protected, of course.
The result of my investigation is that when the bot finds its own name in the last edit comment (that was the fact because of renaming), it supposes that the last edit was a revert of its previous edit (why?), and denies saving with a fake and misleading "page locked" exception.
The code in wikipedia.py is: elif self.comment() and username in self.comment(): raise LockedPage( u'Not allowed to edit %s because last edit maybe reverted' % self.title(asLink=True)) (line 1970) Of course, these type of messages in the argument of *raise* won't appear on user's screen, it is hidden into the source code. For some reason, Python does not show the message in user exceptions.
This was my first experience with this kind of error so I was first frightened and confused and finally found out that I should use a force=True parameter, and so after waiting another 8 minutes I could save the page. I solved the case and lost 15-20 minutes.
Is there really a serious reason to suppose that having found the name of the bot in the last edit comment marks a revert and to prevent the bot of saving the result of its work?
Bináris.unhappy.hu http://xn--binris-rta.unhappy.hu
Hi Bináris,
Op 30-12-2012 23:31, Bináris schreef:
The result of my investigation is that when the bot finds its own name in the last edit comment (that was the fact because of renaming), it supposes that the last edit was a revert of its previous edit (why?), and denies saving with a fake and misleading "page locked" exception.
I ran into that too some time ago while debugging (do an edit, revert it and try again). Not sure when this was added but you have my support to remove it (with fire!).
Maarten
2012/12/31 Maarten Dammers maarten@mdammers.nl
I ran into that too some time ago while debugging (do an edit, revert it and try again). Not sure when this was added but you have my support to remove it (with fire!).
Thanks. I am still waiting for an opinion from xqt or Merlijn.
Another problem vith this solution: this time the bot stopped after reverting *another* bot's edit. The other bot is also mine and it has a similar but longer name, so its name contains the name of the first bot.
On 30 December 2012 23:31, Bináris wikiposta@gmail.com wrote:
The code in wikipedia.py is: elif self.comment() and username in self.comment(): raise LockedPage( u'Not allowed to edit %s because last edit maybe reverted' % self.title(asLink=True)) (line 1970)
It was added by xql in r10769: http://svn.wikimedia.org/viewvc/pywikipedia/trunk/pywikipedia/wikipedia.py?r...
(you can find this yourself using the 'annotate' function in the repository browser.... or svn blame, but that takes ages)
Basically, I think there are two ways of improving this, as the basic idea of preventing reverts makes sense to me: a) using a less crude method to determine reverts of ourself - can't we detect the last revision's owner? I think that's p.userName()? b) using a different exception - one that more clearly signifies 'don't edit without user intervention' - on the other hand, that's sort of what LockedPage does! It tells the code: hey, you can only edit this with another user.
Of course, these type of messages in the argument of raise won't appear on user's screen, it is hidden into the source code. For some reason, Python does not show the message in user exceptions.
I cannot reproduce this:
raise wikipedia.LockedPage('something')
Traceback (most recent call last): File "<stdin>", line 1, in <module> pywikibot.exceptions.LockedPage: something
but maybe the exception was caught and rethrown without message (which would be the real wrongdo-er!)
This was my first experience with this kind of error so I was first frightened and confused and finally found out that I should use a force=True parameter, and so after waiting another 8 minutes I could save the page. I solved the case and lost 15-20 minutes.
Good to hear you have solved the problem - and sorry that it wasted that much time. But please also take from this that you should be prepared for exceptions when saving - you want to handle the exceptions in a sensible way, so the bot doesn't crash, wasting your time :-)
Anyway, I'd like xqt to make a note on this, so that we know the background of the original commit. I think the basic goals are OK, but maybe the implementation can use some improvements.
Merlijn
2012/12/31 Merlijn van Deen valhallasw@arctus.nl
It was added by xql in r10769:
http://svn.wikimedia.org/viewvc/pywikipedia/trunk/pywikipedia/wikipedia.py?r...
This happened quite recently, I did not know about that. Earlier I always
read the SVN notifies but since this spring I had no time for that. Anyhow, this is not a general expectation to bot owners. I think we should generally re-think our communication, and have a proper noticeboard or newsletter with the essence of talks and updates.
Basically, I think there are two ways of improving this, as the basic idea of preventing reverts makes sense to me:
Agree.
I cannot reproduce this:
raise wikipedia.LockedPage('something')
Traceback (most recent call last): File "<stdin>", line 1, in <module> pywikibot.exceptions.LockedPage: something
I don't know the difference but it should be tested from a script rather than command line. I never see such messages, although I tried to define some myself.>
Good to hear you have solved the problem - and sorry that it wasted
that much time. But please also take from this that you should be prepared for exceptions when saving - you want to handle the exceptions in a sensible way, so the bot doesn't crash, wasting your time :-)
Well, it's my fault. I wasn't prepared for a locked page as the bot works on these pages for users' wish and they have no reason to prevent bot of updating the page and I met this new case for the first time. I will be more careful (but the error was really not easy to understand).
Cheers and happy new year
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 31.12.2012 11:52, Bináris wrote:
2012/12/31 Merlijn van Deen <valhallasw@arctus.nl mailto:valhallasw@arctus.nl>
It was added by xql in r10769: http://svn.wikimedia.org/viewvc/pywikipedia/trunk/pywikipedia/wikipedia.py?r...
This happened quite recently, I did not know about that. Earlier I always read the SVN notifies but since this spring I had no time for that. Anyhow, this is not a general expectation to bot owners. I think we should generally re-think our communication, and have a proper noticeboard or newsletter with the essence of talks and updates.
Honestly I do not think this was that bad the joke - such things happen from time to time since we all do have time to meet every week in order to discuss about what happened recently. And even if you would read all those messages it might happen that the committer forgot to note the part important for you... It happend to me too that a simple change of scope in trunks query.py broke some code... I think it better to suppress an edit in case of doubt instead of writing to often and just by accident to wiki. May be it would be a good idea to output the suppressed page write to a local text-file in order not to waste your time! I do also strongly support improving the exceptions message if it was unclear! Last but not least I do think this kind of page edit suppression can be removed ideed, since you can use the parameter '-simulate' to prevent editing by accident.
Greetings and Happy New Year! DrTrigon
I too!
The interesting thing in my case is, that I was driving a sysop bot into it.wikivoyage. Why a nearly - omnipotent sysop bot should find a blocked page? A good quiz... But I discovered rather soon the cause of the block into the wikipedia.py script and I understood its logic, I removed temporary the blocking code and I will never write again the username of my bot into the comment field while editing :-)
Alex brollo
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 31.12.2012 15:42, Alex Brollo wrote:
I too!
The interesting thing in my case is, that I was driving a sysop bot into it.wikivoyage. Why a nearly - omnipotent sysop bot should find a blocked page? A good quiz... But I discovered rather soon the cause of the block into the wikipedia.py script and I understood its logic, I removed temporary the blocking code and I will never write again the username of my bot into the comment field while editing :-)
Which is useless anyway - or am I wrong...? :)
2012/12/31 Alex Brollo alex.brollo@gmail.com
I removed temporary the blocking code and I will never write again the username of my bot into the comment field while editing :-)
It's enough to use the force=True parameter in Page.put() if you are
prepared for this problem. This is easier than manipulate wikipedia.py. The trouble is that it will ignore the nobots template, too and thus spreads a bad custom.
It's enough to use the force=True parameter in Page.put() if you are
prepared for this problem. This is easier than manipulate wikipedia.py. The trouble is that it will ignore the nobots template, too and thus spreads a bad custom.
--
Maybe we should find a more differentiated way. But should there be really a difference? btw. The behavior of nobots/bots changed a bit in r10774/r10775 to give a more differentiated way which bot or (NEW!!!!) script is to be denied editing a page.
Greetings
xqt
Basically, I think there are two ways of improving this, as the basic idea of preventing reverts makes sense to me:
Agree.
I removed that exception in r10956 due to bug #3601530 and other problems while putting a page (e.g. logs). Maybe this restriction is good for a separate script like interwiki.py and not for the whole framework until we have a better solution for detecting reverts of bot edits. Sorry for that trouble.
Greetings xqt
Thank you!
2013/1/20 info@gno.de
I removed that exception in r10956 due to bug #3601530 and other problems while putting a page (e.g. logs). Maybe this restriction is good for a separate script like interwiki.py and not for the whole framework until we have a better solution for detecting reverts of bot edits. Sorry for that trouble.