I see where your going and I dont have any issues with it, you are keeping page.text as one function/property. Right now in core page.text() can refer to one of three methods. Either defining new_text, deleting new_text, or setting new_text. I actually like Ladsgroup 's idea and all that is needed is to convert the _text property of the page class to text. Doing that would avoid the headache that Im worried about.
On Sun, Jun 8, 2014 at 4:49 AM, Amir Ladsgroup <ladsgr...@gmail.com> wrote: > 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 <phoenixoverr...@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 > > > _______________________________________________ > Pywikipedia-l mailing list > Pywikipedia-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l > >
_______________________________________________ Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
