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)?
No, the pattern with page.text is evil and will be exterminated. Like I stated in my previous email im in the process of making core not suck. defining several functions with the same name but different actions is a recipe for headache and problematic code. use of get_<item>() and set_<item>() functions should always be used. Not sure who's bright idea it was to use the current page.text approach, but it wasnt a good idea.
On Sat, Jun 7, 2014 at 2:43 PM, Ricordisamoa ricordisamoa@openmailbox.org wrote:
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)?
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
On Sat, Jun 7, 2014 at 3:43 PM, John phoenixoverride@gmail.com wrote:
No, the pattern with page.text is evil and will be exterminated. Like I stated in my previous email im in the process of making core not suck. defining several functions with the same name but different actions is a recipe for headache and problematic code. use of get_<item>() and set_<item>() functions should always be used. Not sure who's bright idea it was to use the current page.text approach, but it wasnt a good idea.
Wow! So, your previous trolling didn't get anyone to rise to the bait, so you're going to continue and/or amplify?!?!
Software projects, open source or not, are social enterprises. Do you not understand that you need to get along with other folks in order to get your ideas implemented?
(And no, none of the "sucky" code belongs to me, so I don't have a dog in this fight)
Tom
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.
On Jun 7, 2014 8:48 PM, "John" phoenixoverride@gmail.com wrote:
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.
[I'm not reading your whole wall of text atm]
I'm familiar with function overloading from other langs like Java but as far as I know there is no such feature in python. (calling a different method depending on call signature)
Please clarify your statements and read the links I already sent to this thread.
-Jeremy
[I'm not reading your whole wall of text atm]
I'm familiar with function overloading from other langs like Java but as far as I know there is no such feature in python. (calling a different method depending on call signature)
Please clarify your statements and read the links I already sent to this thread.
I read you links, depending on call signatures is asking for problems, especially given the international utilization of our code. defining and using get<value> and set<value> command wrappers may add slightly to our code base but it ensures fewer problems. Ill stop here since you wont read much more that I type.
On Jun 7, 2014 9:44 PM, "John" phoenixoverride@gmail.com wrote:
I read you links, depending on call signatures is asking for problems,
especially given the international utilization of our code. defining and using get<value> and set<value> command wrappers may add slightly to our code base but it ensures fewer problems. Ill stop here since you wont read much more that I type.
It's very clear to me that you've not understood (or maybe not fully read) my message.
Please try again.
-Jeremy
No, I completely read your message and the links, however what the textbook suggests and what works in real life are not always the same thing.
Im laughing here, you said you wouldnt read my whole post, and are claiming that I dont understand an issue? I could go into details but you dont read anything over a few lines. (aka wall of text) and trying to make my points using soundbites just doesnt work.
Short version: maintaining a simple standardized access method and avoiding "function overloading" means we have easier to work with code that has lower risks of screwing something up.
On Sat, Jun 7, 2014 at 9:57 PM, Jeremy Baron jeremy@tuxmachine.com wrote:
On Jun 7, 2014 9:44 PM, "John" phoenixoverride@gmail.com wrote:
I read you links, depending on call signatures is asking for problems,
especially given the international utilization of our code. defining and using get<value> and set<value> command wrappers may add slightly to our code base but it ensures fewer problems. Ill stop here since you wont read much more that I type.
It's very clear to me that you've not understood (or maybe not fully read) my message.
Please try again.
-Jeremy
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
On Jun 7, 2014 10:08 PM, "John" phoenixoverride@gmail.com wrote:
and avoiding "function overloading" means we have easier to work with
code that has lower risks of screwing something up.
Please stop talking about function overloading. (as far as I can tell no one else here is talking about function overloading.)
Thanks!
-Jeremy
I guess it depends what language you are referring to, I refer it to it as "function overloading" and use quotes for that. Basically if you have several methods or functions like what we currently have with page.text where depending on the parameters that are passed you get different functions.
Good coding habits are to have one function/method name and a set of params that it accepts, instead of a set of functions/methods with different acceptable values. Using that practice can become a headache and hard to read complex code due to issues distinguishing what a particular call is trying to do vs actually doing.
On Sat, Jun 7, 2014 at 10:12 PM, Jeremy Baron jeremy@tuxmachine.com wrote:
On Jun 7, 2014 10:08 PM, "John" phoenixoverride@gmail.com wrote:
and avoiding "function overloading" means we have easier to work with
code that has lower risks of screwing something up.
Please stop talking about function overloading. (as far as I can tell no one else here is talking about function overloading.)
Thanks!
-Jeremy
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
I have also found core to be difficult to use in some cases, but it is a much better codebase in general than the 'compat' dumping ground, and I am thankful for the people who have worked hard to bring it to its current state.
It is close to being ready for general use. We need more people trying it and reporting errors. If there are problems with mwparserfromhell on Windows, we need to understand and fix the problem in mwparserfromhell, and then properly set the dependency version in pywikibot core. fwiw, Betacommand is talking about this issue: https://github.com/earwig/mwparserfromhell/issues/54 https://gerrit.wikimedia.org/r/#/c/138209
-- John Vandenberg
Oh, please note I am not attacking the code base in core, just that it is a good starting point and still needs a lot of work. Since Im one of the few users who develops on windows Im going to be addressing a lot of those issues and ensuring that the base that we currently have in core can mature into a solid project like what we have in compat. (I know the codebase in compat sucks, but its about 10 years old without any serious rewrites and supports way too many versions of mediawiki)
On Sat, Jun 7, 2014 at 10:09 PM, John Mark Vandenberg jayvdb@gmail.com wrote:
I have also found core to be difficult to use in some cases, but it is a much better codebase in general than the 'compat' dumping ground, and I am thankful for the people who have worked hard to bring it to its current state.
It is close to being ready for general use. We need more people trying it and reporting errors. If there are problems with mwparserfromhell on Windows, we need to understand and fix the problem in mwparserfromhell, and then properly set the dependency version in pywikibot core. fwiw, Betacommand is talking about this issue: https://github.com/earwig/mwparserfromhell/issues/54 https://gerrit.wikimedia.org/r/#/c/138209
-- John Vandenberg
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
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@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
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 ladsgroup@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 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
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
On Jun 7, 2014 3:43 PM, "John" phoenixoverride@gmail.com wrote:
defining several functions with the same name but different actions is a
recipe for headache and problematic code. use of get_<item>() and set_<item>() functions should always be used. Not sure who's bright idea it was to use the current page.text approach, but it wasnt a good idea.
See:
* https://stackoverflow.com/questions/6618002/python-property-versus-getters-a... * http://legacy.python.org/dev/peps/pep-0213/
-Jeremy
On Sat, Jun 7, 2014 at 2:43 PM, Ricordisamoa ricordisamoa@openmailbox.org wrote:
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)?
Using simple data attributes until more complexity is needed and then switching to Python properties is definitely more Pythonic than using Java-style getters and setters.
Consistency of style across the entire API will help consumers understand it more easily.
On Sun, Jun 8, 2014 at 4:49 AM, Amir Ladsgroup ladsgroup@gmail.com wrote:
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:])
Unless you want to support this syntax forever, you might want to consider either separating it into a compatibility layer or at least clearly marking it in the documentation as something which is deprecated and won't be supported forever. Otherwise you're permanently incurring the cost of the increased API surface area.
Tom
On Mon, Jun 9, 2014 at 12:01 AM, Tom Morris tfmorris@gmail.com wrote:
On Sat, Jun 7, 2014 at 2:43 PM, Ricordisamoa <ricordisamoa@openmailbox.org
wrote:
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)?
Using simple data attributes until more complexity is needed and then switching to Python properties is definitely more Pythonic than using Java-style getters and setters.
Consistency of style across the entire API will help consumers understand it more easily.
On Sun, Jun 8, 2014 at 4:49 AM, Amir Ladsgroup ladsgroup@gmail.com wrote:
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:])
Unless you want to support this syntax forever, you might want to consider either separating it into a compatibility layer or at least clearly marking it in the documentation as something which is deprecated and won't be supported forever. Otherwise you're permanently incurring the cost of the increased API surface area.
Of course I'm in favor of writing down this in documentation (or development guideline) and ask people not to use it.
Tom
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l