pywikibot June 2014

pywikibot@lists.wikimedia.org

27 participants
44 discussions

Re: [Pywikipedia-l] site.lang and site.code
by info＠gno.de 13 Jun '14

13 Jun '14

in core branch site.lang is reserved for i18n translations from twn and other language based issues where as site.code is for site related issues like L10N etc. Because i18n was backported to compat branch and compat does not distinguish between site.code and site.lang the i18n dictionary uses code not lang key. The "right" key is catched by a codemap inside translatewiki which also maps languages like "sr-ec" to "sr" or "tt-cyrl" to "tt" etc. when the dictionaries are exported. I agree if we went back to site.lang language code for i18n translations. The mapping at compat could easily done by i18n._altlang() (btw. its parameter is called "code" leftover from compat) Best xqt ----- Original Nachricht ---- Von: Ricordisamoa <ricordisamoa(a)openmailbox.org> An: Pywikipedia discussion list <pywikipedia-l(a)lists.wikimedia.org> Datum: 04.06.2014 14:44 Betreff: [Pywikipedia-l] site.lang and site.code > I am not sure it's always better to use site.code instead of site.lang. > If TranslateWiki uses language codes, 'be-tarask' should be used instead > of 'be-x-old', etc. > > _______________________________________________ > Pywikipedia-l mailing list > Pywikipedia-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l >

2 2

[Pywikipedia-l] mwparserfromhell
by Ricordisamoa 12 Jun '14

12 Jun '14

Since gerrit:131263 <https://gerrit.wikimedia.org/r/131263/> , it seems to me that the excellent mwpfh is going to be used more and more extensively within our framework. Am I right? For example, the DuplicateReferences detection and fix in reflinks.py could be brightly refactored without regular expressions. Or are we supposed to do the opposite conversion, where possible?

4 7

[Pywikipedia-l] Wikidata API function "wbsetclaim" not available in pywikibot?
by Frank Wein 11 Jun '14

11 Jun '14

Hi, do I see it correctly that there is no function in pywikibot-core (yet?) to call the Wikidata API function "wbsetclaim" (see http://www.wikidata.org/w/api.php for some docu)? I wanted to use that function to insert a new claim at a certain index position when a claim with the same property already exists. I found out there was(?) a patch for a setClaim function, but looks like it was backed out again (http://www.gossamer-threads.com/lists/wiki/mediawiki-cvs/384671?do=post_vie… Someone on IRC said I could use https://gerrit.wikimedia.org/r/#/c/125575/ as soon as it has been checked in to overwrite the whole item/entity with editEntity as some kind of workaround (not sure yet what the overhead of this compared to using wbsetclaim would be). Frank

2 2

[Pywikipedia-l] getters and setters
by Ricordisamoa 09 Jun '14

09 Jun '14

It seems to me that the current trend is to use the same attribute as both a getter and a setter, e.g. Page.text. Is this true? Should we convert Claim.getTarget() and .setTarget() to just "target" (which is already used internally)?

6 16

[Pywikipedia-l] Wikidata project focused on economic data
by Alex Peek 09 Jun '14

09 Jun '14

Project homepage: https://meta.wikimedia.org/wiki/The_Global_Economic_Map We are a new project looking for volunteers. Thanks, Alex

1 0

[Pywikipedia-l] Interested in hacking on pywikibot
by Travis Briggs 09 Jun '14

09 Jun '14

Hi, My name is Travis Briggs and I'm a software developer who currently works at Google in California. I've always had a soft spot for Wikipedia and wondered how I could get more involved and contribute more. Today, I was thinking about how it's a shame that Media Wiki is written in PHP, as that is a language that I'm not really interested in hacking on in my spare time. Then I found pywikibot. Python is probably the language I have the most current experience in, besides maybe Javascript, and I'm familiar with web API usages. All this to say, I'd like to see if I can help out on the pywikibot project itself, though I don't have a specific wiki that I work on or a specific bot that I'd like to write. I've gotten as far as installing a vagrant instance of Media Wiki and cloning the "core" branch of pywikibot, though I haven't gotten them talking to each other just yet. Thanks! -Travis

4 3

[Pywikipedia-l] adding error handling to Bot.userPut()
by Ricordisamoa 09 Jun '14

09 Jun '14

I'm in the process of converting several scripts to use the framework's generic Bot class (gerrit:137334 <https://gerrit.wikimedia.org/r/137334/>, gerrit:137346 <https://gerrit.wikimedia.org/r/137346/>, gerrit:137354 <https://gerrit.wikimedia.org/r/137354/>, gerrit:138219 <https://gerrit.wikimedia.org/r/138219/>) which provides a useful .userPut() method. However, while most implementations in scripts try to catch possible exceptions (e.g. LockedPage, EditConflict, SpamfilterError), the 'standard' one does not. Should we add such a thing? Maybe turned off by default?

2 1

Re: [Pywikipedia-l] lists vs tuples
by info＠gno.de 07 Jun '14

07 Jun '14

The performance searching in a list or a tuple is both the same and both bad. Better performance has searching inside a string or in indexed types like set and dict whereas instantiating them is time consuming. Using list may lead to unexpected side effects because they are mutable objects whereas tuples are immutable. I remember bugs with lists as parameters to methods or setting a view to lists inside family file content and change them instead of copy its values. That's the reason why I prefer tuples when the content never has to be changed. For the given example there is no difference. Greetings xqt ----- Original Nachricht ---- Von: Merlijn van Deen <valhallasw(a)arctus.nl> An: Pywikipedia discussion list <pywikipedia-l(a)lists.wikimedia.org> Datum: 07.06.2014 00:13 Betreff: Re: [Pywikipedia-l] lists vs tuples > On 6 June 2014 23:49, Ricordisamoa <ricordisamoa(a)openmailbox.org> wrote: > > > Should we always use tuples when instantiating them only once? E.g. > > *if* abc *in* ('e', 'f'): > > instead of > > *if* abc *in* ['e', 'f']: > > > > Performance-wise, I don't think it matters much; after all, most time is > spent inside the loop, not in instantiating a list or tuple. Conceptually, > a list often makes more sense (a list would be different items of the same > type, while a tuple represents different properties of the same item). > > Merlijn > > > -------------------------------- > > _______________________________________________ > Pywikipedia-l mailing list > Pywikipedia-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l >

1 0

[Pywikipedia-l] lists vs tuples
by Ricordisamoa 07 Jun '14

07 Jun '14

Should we always use tuples when instantiating them only once? E.g. *if*abc *in* ('e', 'f'): instead of *if* abc *in* ['e', 'f']: They appear to be slightly faster sometimes.

3 2

[Pywikipedia-l] Core
by John 07 Jun '14

07 Jun '14

Ive been waiting for core to get usable, and Im tired of waiting. In the next month or two Ill be taking a good look and probably end up re-writing half the code, and implementing quite a bit more new code so that we can actually make core into a respectable, non-crapy product that people can actually use. Hopefully we can get the changes merged without too much headache. Ive been sitting on a large amount of code that Ive written over the years and extended which extended the old compat branch into a powerhouse. Ive just done a SVN checkout from git and will start the process over the weekend, If anyone has any areas that they know that core currently sucks at and wants me to focus on that let me know John

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

pywikibot June 2014