The page.text is the correct approach. It may cause lots of function calls in backend but it's easier to use and one of the best advantage of this approach is you can change page's text several times and flush it away with a simple page.save() almost as the same as other objects in programing world. It has better compatibility with API and makes more sense. As an example if want to write a code in compat framework it would be like:

page= wikipedia.Page(site, name)
text = page.get()
new_text = text
if something:
    new_text = new_text.replace(something, something_else)
if new_text != text:
    page.put(new_text, summary)

(Just do "grep new_text *.py" in compat to see how many times it's used)
so you have to define a redundant variable named new_text and the code doesn't make sense for newbies and it has less readability than the core version of code:

page= pywikibot.Page(site, name)
if something:
    page.text = page.text.replace(something, something_else)
page.save(summary)

So please judge which one is more readable and smaller.
As a person who is using pywikibot more than six years and have patches in both core and compat, I have to admit core has tons of problems and it's hard to install BUT 1- compat has more issues 2- compat is not designed to work with API (do you recall Yuri's changes?) and it doesn't follow sense of mediawiki 3- it doesn't follow standards of python coding so it's not readable or easy to use 4- if people don't use core in different environments no one would see the issues so we have to make people to use it and report bugs

At the end I suggest to work on the standards (page.text instead of page.put() ) but keep compat compatibility. i.e. make a function like this in Page class:
def put(*args):
    page.text = args[0]
    page.save(args[1:])

or something like that
Best


On Sun, Jun 8, 2014 at 5:18 AM, John <phoenixoverride@gmail.com> wrote:
OK, Ive been involved in pywiki for 8 years now, and its not trolling. I have attempted to install "core" a dozen times over the last ~2 years. Each and every time within 2 minutes I run into a fatal problem where core is unusable. This time it was https://bugzilla.wikimedia.org/show_bug.cgi?id=66242 which caused core to crash within 10 seconds of attempting to use it.

Im sorry if you think that "core" is some golden masterpiece. Its not. Use of overloading function calls may be possible, but you wanna know something? it becomes a nightmare to debug in complex code if by accident you call the wrong version of page.text and end up with screwy output. I know this may sound obnoxious and "trolling", bit I have lived by the coders credo, KISS. Writing good strong base code and adopting methods that prevent accidental code nightmares is a good thing.

I often have to debug and/or isolate issues in complex scripts in the 10,000 line of code range. making sure that accidents and errors are kept to a minimum is very important. When you introduce identical functions that perform different actions you are begging for screwups.

Ive been contributing to pywiki on and off again for a long time, for the most part the old compat branch was extremely stable and worked very well, with the recent push use core, and to phase out compat more and more people will be using core. I have lost count of the number of users I have helped setup pywiki for on non-WMF wikis, the number that have been able to install core I can count on half of one hand. The number that have been able to get compat up and running with almost no problems far far exceeds that of the latter.

Im sorry if Im not all ass-kissing best product in the world. I have already submitted a few patches to core and will continue to do so as I review the code, and implement missing features. As most people who know me can iterate, if you need something done, report generated, tool created or software written, I probably have the code sitting around to do it, if I dont Ill write it for the person. For the most part these tools have resided in my personal repos, however given some of the issues I see repeatedly and other things that crop up I do feel that other can benefit from them. Since Im going to be re-writing most of the code in order to move from compat to core I thought I would review core, fix the glaring issues, fill in the missing components, and contribute some of the code that I have sitting on my shelf.

Given the fact that you have zero commits and just a handful of posts to this mailing list I'll ignore your drive by snarky comment. If you actually want to be productive and make core a good product feel free to submit patches, something I will be doing.

Pywikipedia has been a strong dependable and resourceful codebase for many years, however if the community of newer devs want to push code that is substandard and they are not interested in collaborating and improving the code, Ill just fork it leave the code that doesn't work behind me with those users who feel that politics should play a more important part of the project than the quality and usability of the code.

One other example where our code causes a crash is https://bugzilla.wikimedia.org/show_bug.cgi?id=66330 any time a user wants to have mwparserfromhell installed on windows, they cannot use core. Ive already submitted a patch for the fix. I dont recall the bug off hand but I know of at least one other major case where our lack of developers on windows systems caused headaches was with the usage of git and the calls to git.exe on windows, especially if git.exe either wasn't installed or wasn't listed in the system path variable.

How lets stop playing politics, calling a contributor who is actually willing to spend hours reviewing and improving the code a troll, and get back to providing a kickass framework for tools and bot development. 

_______________________________________________
Pywikipedia-l mailing list
Pywikipedia-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l




--
Amir