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
<https://www.mediawiki.org/wiki/Manual:Pywikibot/Development_guideline>
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(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
--
Amir
_______________________________________________
Pywikipedia-l mailing list
Pywikipedia-l(a)lists.wikimedia.org