Pywikipedia-l June 2014

pywikipedia-l@lists.wikimedia.org

27 participants
42 discussions

Wikidata API function "wbsetclaim" not available in pywikibot?
by Frank Wein 10 Jun '14

10 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

getters and setters
by Ricordisamoa 08 Jun '14

08 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

Wikidata project focused on economic data
by Alex Peek 08 Jun '14

08 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

Interested in hacking on pywikibot
by Travis Briggs 08 Jun '14

08 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

adding error handling to Bot.userPut()
by Ricordisamoa 08 Jun '14

08 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 06 Jun '14

06 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

lists vs tuples
by Ricordisamoa 06 Jun '14

06 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

Core
by John 06 Jun '14

06 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

help pages needing update
by Ricordisamoa 06 Jun '14

06 Jun '14

e.g. mw:Manual:Pywikibot/Gerrit <https://www.mediawiki.org/wiki/Manual:Pywikibot/Gerrit>

1 0

Test needing fix
by Ricordisamoa 04 Jun '14

04 Jun '14

https://travis-ci.org/wikimedia/pywikibot-core/jobs/26754246

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Pywikipedia-l June 2014