From: Nick H. <nic...@ho...> - 2014-04-09 11:33:24
|
Devs, I suggest the following schedule for the release of v4.1: 9th April - Code freeze for new features. 7th May - String freeze and creation of maintenance branch. 21st May - Release date. This gives us four weeks of testing and bug fixing, followed by two weeks for the translators. This will keep us on track for previous releases: v4.0.0 - 21st May 2013 v3.4.0 - 22nd May 2012 v3.3.0 - 13th Jun 2011 Any help you can give with testing and bug fixing would be appreciated. Regards, Nick. |
From: jerome <rom...@ya...> - 2014-04-09 13:23:23
|
It sounds good. J. Le Mercredi 9 avril 2014 13h33, Nick Hall <nic...@ho...> a écrit : Devs, I suggest the following schedule for the release of v4.1: 9th April - Code freeze for new features. 7th May - String freeze and creation of maintenance branch. 21st May - Release date. This gives us four weeks of testing and bug fixing, followed by two weeks for the translators. This will keep us on track for previous releases: v4.0.0 - 21st May 2013 v3.4.0 - 22nd May 2012 v3.3.0 - 13th Jun 2011 Any help you can give with testing and bug fixing would be appreciated. Regards, Nick. ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Gramps-devel mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Paul F. <pf....@gm...> - 2014-04-09 14:45:50
|
On 4/9/14, Nick Hall <nic...@ho...> wrote: > Devs, > > I suggest the following schedule for the release of v4.1: > > 9th April - Code freeze for new features. It was certainly nice of you to give us some warning. I assume that means I have until midnight tonight. |
From: Nick H. <nic...@ho...> - 2014-04-09 15:16:07
|
On 09/04/14 15:45, Paul Franklin wrote: >> I suggest the following schedule for the release of v4.1: >> > >> >9th April - Code freeze for new features. > It was certainly nice of you to give us some warning. > > I assume that means I have until midnight tonight. > > Paul, We can be flexible. What new feature have you been working on? Your work relating to event types is more of a bug fix than a new feature. Nick. |
From: Paul F. <pf....@gm...> - 2014-04-09 15:37:37
|
On 4/9/14, Nick Hall <nic...@ho...> wrote: > On 09/04/14 15:45, Paul Franklin wrote: >>> I suggest the following schedule for the release of v4.1: >>> > >>> >9th April - Code freeze for new features. >> It was certainly nice of you to give us some warning. >> >> I assume that means I have until midnight tonight. >> >> > Paul, > > We can be flexible. What new feature have you been working on? > > Your work relating to event types is more of a bug fix than a new feature. > > Nick. > > Thanks. I have several things in mind, but the only pure "feature" is to add translated output to the two graphic ancestor and descendant tree reports. I filed a feature request and attached a patch but I have only received one tester's comment so far, and I haven't looked into it yet. So I plan to commit that patch today, to trunk/master only. All my other pending work could accurately (I believe) be classified as bug fixing, although the proposed change of our "def format" methods to "def format_" is not easily put in that class. I still want to do it, though. (In master only, I guess.) I will try to put all of them into trunk/master today also, to maximize the time they are used. I would appreciate it if somebody, anybody, would provide me with a template for changing all our "ngettext" multi-variable strings from the "%" format operator to the ".format" way instead, so I can change all the ngettext strings in master to do it that way instead. But I assume that falls under your "string freeze" deadline instead. So there is no immediate hurry. And I haven't done a search so maybe all the ngettext uses are only single variable ones -- like ngettext("%d child", "%d children") % child_count |
From: Nick H. <nic...@ho...> - 2014-04-09 16:28:50
|
On 09/04/14 16:37, Paul Franklin wrote: > I have several things in mind, but the only pure > "feature" is to add translated output to the two > graphic ancestor and descendant tree reports. > > I filed a feature request and attached a patch > but I have only received one tester's comment > so far, and I haven't looked into it yet. So I plan > to commit that patch today, to trunk/master only. Yes. Go ahead with that. > > All my other pending work could accurately (I > believe) be classified as bug fixing, although the > proposed change of our "def format" methods > to "def format_" is not easily put in that class. > I still want to do it, though. (In master only, > I guess.) > I don't like this change. There are only 5 matches when I grep for "def format(". One method looks like that it isn't actually used. The others are probably better renamed "format_string" or "format_number". > I will try to put all of them into trunk/master > today also, to maximize the time they are used. > > I would appreciate it if somebody, anybody, would > provide me with a template for changing all our > "ngettext" multi-variable strings from the "%" format > operator to the ".format" way instead, so I can > change all the ngettext strings in master to do > it that way instead. But I assume that falls under > your "string freeze" deadline instead. So there > is no immediate hurry. And I haven't done a search > so maybe all the ngettext uses are only single > variable ones -- like > > ngettext("%d child", "%d children") % child_count > > No, this doesn't come under the string freeze deadline. It doesn't even look like a bug fix. Why do you want to do it? Most ngettext uses are indeed a single variable. I did find a couple of exceptions though. Nick. |
From: Paul F. <pf....@gm...> - 2014-04-09 17:17:40
|
On 4/9/14, Nick Hall <nic...@ho...> wrote: > On 09/04/14 16:37, Paul Franklin wrote: >> I have several things in mind, but the only pure >> "feature" is to add translated output to the two >> graphic ancestor and descendant tree reports. >> >> I filed a feature request and attached a patch >> but I have only received one tester's comment >> so far, and I haven't looked into it yet. So I plan >> to commit that patch today, to trunk/master only. > > Yes. Go ahead with that. OK. (I'm working on it. The trunk version of a library file has some changes from gramps40.) > > >> >> All my other pending work could accurately (I >> believe) be classified as bug fixing, although the >> proposed change of our "def format" methods >> to "def format_" is not easily put in that class. >> I still want to do it, though. (In master only, >> I guess.) >> > > > I don't like this change. There are only 5 matches when I grep for "def > format(". One method looks like that it isn't actually used. The others > are probably better renamed "format_string" or "format_number". Feel free to make that change, with the names you have chosen. I don't care about the new names. I only want a recursive grep of ".format(" to pull up legal Python-library uses of that name. Only. Not our methods (which will confuse me). > > >> I will try to put all of them into trunk/master >> today also, to maximize the time they are used. >> >> I would appreciate it if somebody, anybody, would >> provide me with a template for changing all our >> "ngettext" multi-variable strings from the "%" format >> operator to the ".format" way instead, so I can >> change all the ngettext strings in master to do >> it that way instead. But I assume that falls under >> your "string freeze" deadline instead. So there >> is no immediate hurry. And I haven't done a search >> so maybe all the ngettext uses are only single >> variable ones -- like >> >> ngettext("%d child", "%d children") % child_count >> >> > > No, this doesn't come under the string freeze deadline. It doesn't even > look like a bug fix. Why do you want to do it? > > Most ngettext uses are indeed a single variable. I did find a couple of > exceptions though. > > > Nick. > > The problem is in Arabic. One of our Arabic translators is /very/ unhappy that he can't translate the child/children ngettext strings the way he claims that his culture always does. Specifically -- and I don't read Arabic so this is my understanding, from what he said -- there are /six/ forms of Arabic plurals, and /some/ of those uses, the way he says his culture always uses them, do /not/ have a number. As an example, in my child/children example (which is indeed the case he complained of, in a report he wanted to give to family members), he said the one-child case would never be said as "1 child" in Arabic, but instead as a string which has no number, maybe "a child" (that's my guess), and the "2 children" string would also not have a number, instead a no-number string, maybe "two children" (that is also my guess). The problem is that the historic, legacy "%" Python format operator /insists/ there be a one-to-one match, of variable uses on the left side and variables on the right side. Whereas (the claim is) that the ".format" operator/function/whatever is happy if the left-hand string has no variable (no %d in my example) in the translated string. |
From: Nick H. <nic...@ho...> - 2014-04-09 18:33:59
|
On 09/04/14 18:17, Paul Franklin wrote: >> I don't like this change. There are only 5 matches when I grep for "def >> >format(". One method looks like that it isn't actually used. The others >> >are probably better renamed "format_string" or "format_number". > Feel free to make that change, with the names > you have chosen. I don't care about the new > names. I only want a recursive grep of ".format(" > to pull up legal Python-library uses of that name. > Only. Not our methods (which will confuse me). > On closer inspection, these method names appear to be carefully chosen. I don't think that we should change them. Nick. |
From: Paul F. <pf....@gm...> - 2014-04-09 19:07:56
|
On 4/9/14, Nick Hall <nic...@ho...> wrote: > On 09/04/14 18:17, Paul Franklin wrote: >>> I don't like this change. There are only 5 matches when I grep for "def >>> >format(". One method looks like that it isn't actually used. The >>> > others >>> >are probably better renamed "format_string" or "format_number". >> Feel free to make that change, with the names >> you have chosen. I don't care about the new >> names. I only want a recursive grep of ".format(" >> to pull up legal Python-library uses of that name. >> Only. Not our methods (which will confuse me). >> > > On closer inspection, these method names appear to be carefully chosen. > I don't think that we should change them. They conflict with the Python-library function of the same name (introduced in Python2.6 as I mentioned earlier). As I said earlier, the PEP08 style guide says that in such cases our names should be renamed to "def format_" instead. |
From: Nick H. <nic...@ho...> - 2014-04-09 19:46:48
|
On 09/04/14 20:07, Paul Franklin wrote: > On 4/9/14, Nick Hall <nic...@ho...> wrote: >> On 09/04/14 18:17, Paul Franklin wrote: >>>> I don't like this change. There are only 5 matches when I grep for "def >>>>> format(". One method looks like that it isn't actually used. The >>>>> others >>>>> are probably better renamed "format_string" or "format_number". >>> Feel free to make that change, with the names >>> you have chosen. I don't care about the new >>> names. I only want a recursive grep of ".format(" >>> to pull up legal Python-library uses of that name. >>> Only. Not our methods (which will confuse me). >>> >> On closer inspection, these method names appear to be carefully chosen. >> I don't think that we should change them. > They conflict with the Python-library function of > the same name (introduced in Python2.6 as I > mentioned earlier). As I said earlier, the PEP08 > style guide says that in such cases our names > should be renamed to "def format_" instead. > > Paul, There is no problem using "format" as a method name. The PEP08 guidelines that you refer to are suggesting a naming convention to avoid a clash with a reserved keyword. If you look at the keyword list, you will find that "format" is not a keyword in either python2 or python3. We should not change these method names. Nick. |
From: Paul F. <pf....@gm...> - 2014-04-09 22:04:40
|
On 4/9/14, Nick Hall <nic...@ho...> wrote: > There is no problem using "format" as a method name. The PEP08 > guidelines that you refer to are suggesting a naming convention to avoid > a clash with a reserved keyword. If you look at the keyword list, you > will find that "format" is not a keyword in either python2 or python3. Please provide a link to the "keyword list" you refer to, which I assume will be some piece of official Python documentation. Although in all honesty I don't understand why you are fighting this change. Even if you are right I don't see any good reason not to reduce possible confusion, especially when the change is quasi-offically sanctioned. It's too bad no other developers have seen fit to offer any opinions on the matter. |
From: Nick H. <nic...@ho...> - 2014-04-09 22:38:15
|
On 09/04/14 23:04, Paul Franklin wrote: > On 4/9/14, Nick Hall <nic...@ho...> wrote: >> There is no problem using "format" as a method name. The PEP08 >> guidelines that you refer to are suggesting a naming convention to avoid >> a clash with a reserved keyword. If you look at the keyword list, you >> will find that "format" is not a keyword in either python2 or python3. > Please provide a link to the "keyword list" you > refer to, which I assume will be some piece of > official Python documentation. From a python prompt: > import keyword > keyword.kwlist > > Although in all honesty I don't understand why > you are fighting this change. > > Even if you are right I don't see any good reason > not to reduce possible confusion, especially when > the change is quasi-offically sanctioned. > > It's too bad no other developers have seen fit > to offer any opinions on the matter. > > There isn't a good enough reason to make this change. Nick. |
From: Paul F. <pf....@gm...> - 2014-04-09 22:57:38
|
On 4/9/14, Nick Hall <nic...@ho...> wrote: >> Although in all honesty I don't understand why >> you are fighting this change. >> >> Even if you are right I don't see any good reason >> not to reduce possible confusion, especially when >> the change is quasi-offically sanctioned. > There isn't a good enough reason to make this change. I've given what I consider to be good reasons. Not only will it reduce confusion but it follows official style guidelines. I don't feel you have offered any reason to counter those two. You have merely expressed your opinion. Without offering any reason at all, that I can see, why it would be a bad idea. |
From: Nick H. <nic...@ho...> - 2014-04-09 23:38:16
|
On 09/04/14 23:57, Paul Franklin wrote: >> There isn't a good enough reason to make this change. > I've given what I consider to be good reasons. > Not only will it reduce confusion but it follows > official style guidelines. > > I don't feel you have offered any reason to counter > those two. You have merely expressed your opinion. > Without offering any reason at all, that I can see, > why it would be a bad idea. > > I can't believe we are actually discussing this! The original code follows the PEP08 guidelines, and the original choice of method name is a good one. In two cases you propose changing the public API. This will only increase confusion. If we make the change, we should deprecate the old methods and then remove them in a later version. Changing code always has the risk of introducing bugs. If you can convince Benny I won't argue though. Nick. |
From: Paul F. <pf....@gm...> - 2014-04-10 00:01:23
|
On 4/9/14, Nick Hall <nic...@ho...> wrote: > On 09/04/14 23:57, Paul Franklin wrote: >>> There isn't a good enough reason to make this change. >> I've given what I consider to be good reasons. >> Not only will it reduce confusion but it follows >> official style guidelines. >> >> I don't feel you have offered any reason to counter >> those two. You have merely expressed your opinion. >> Without offering any reason at all, that I can see, >> why it would be a bad idea. >> >> > > I can't believe we are actually discussing this! Me either! You are starting to convince me that in the future I shouldn't bother sending any message to the list, providing a courtesy notice of what I plan to do. Perhaps I'll just do it. And leave you to revert it when you notice, like you have done before. > The original code follows the PEP08 guidelines, and the original choice > of method name is a good one. While I haven't checked, I would strongly guess that all those methods were written before Python 2.6 came into existence, and thus when the .format did also. So while they may have originally conformed, they don't any more. At least in spirit, if not technically. > In two cases you propose changing the public API. This will only > increase confusion. If we make the change, we should deprecate the old > methods and then remove them in a later version. As far as I understand it, any API is allowed to change in trunk/master. That's where I'm going to make the change, if it's allowed. > Changing code always has the risk of introducing bugs. Is that what it is boiling down to? That you don't trust me to make that change? Do you feel proprietary towards trunk/master, since you have volunteered to turn it into gramps41? |
From: John R. <jr...@ce...> - 2014-04-10 01:05:03
|
On Apr 9, 2014, at 5:01 PM, Paul Franklin <pf....@gm...> wrote: > On 4/9/14, Nick Hall <nic...@ho...> wrote: >> On 09/04/14 23:57, Paul Franklin wrote: >>>> There isn't a good enough reason to make this change. >>> I've given what I consider to be good reasons. >>> Not only will it reduce confusion but it follows >>> official style guidelines. >>> >>> I don't feel you have offered any reason to counter >>> those two. You have merely expressed your opinion. >>> Without offering any reason at all, that I can see, >>> why it would be a bad idea. >>> >>> >> >> I can't believe we are actually discussing this! > > Me either! > > You are starting to convince me that in the future > I shouldn't bother sending any message to the > list, providing a courtesy notice of what I plan to > do. Perhaps I'll just do it. And leave you to revert > it when you notice, like you have done before. > >> The original code follows the PEP08 guidelines, and the original choice >> of method name is a good one. > > While I haven't checked, I would strongly guess > that all those methods were written before Python > 2.6 came into existence, and thus when the .format > did also. So while they may have originally conformed, > they don't any more. At least in spirit, if not technically. > >> In two cases you propose changing the public API. This will only >> increase confusion. If we make the change, we should deprecate the old >> methods and then remove them in a later version. > > As far as I understand it, any API is allowed to > change in trunk/master. That's where I'm going > to make the change, if it's allowed. > >> Changing code always has the risk of introducing bugs. > > Is that what it is boiling down to? That you > don't trust me to make that change? Do you > feel proprietary towards trunk/master, since > you have volunteered to turn it into gramps41? > Paul, Do you have even the vaguest understanding of polymorphism and object-oriented programming? It matters not at all if two separate classes have methods with the same name. It's a *feature* that they can, and a good design practice to do so: It provides another form of polymorphism from class hierarchy: You can write a generic method that will work with an instance of any class that implements a 'format' method. Consider, for example, GrampsLocale.format(). It is at present a simple override of https://docs.python.org/3/library/locale.html#locale.format so that in future it will be possible to introduce an ICU implementation when ICU is available. As Nick said, it's appropriately named considering what it does. Notice that in Python2.7 that besides string and locale, calendar, Logging.Formmatter and pprint also declare a format() method. One more shot: By extension, your argument reduces to not using any method name in any Gramps class if that method name is used by any class in the Python Standard Library. I count 248 separate modules in the library reference; `egrep -r --include=*.py 'def \w+\(self' ~/Development/Gramps-Build/gramps-master-git/inst/lib/python2.7/ | wc -l` tells me that there are 23601 member functions. I don't know how many are unique, but even if only 10% are it's an awful lot of function names to prohibit for no reason other than "it confuses" you. On the other side of the argument, changing a class API even by one character is a very big deal. API affects not only Gramps itself, it also affects addons, published or private, which might use a method. Suggesting that one should make such a change gratuitously at all is rude; suggesting it a month before release is irresponsible. Regards, John Ralls |
From: Paul F. <pf....@gm...> - 2014-04-10 01:29:14
|
You have convinced me. In light of my ignorance and the chance of making a mistake, I will let somebody else change all the uses of ngettext to use .format instead of %. When they want to do it will be up to them. |
From: Paul F. <pf....@gm...> - 2014-04-10 10:47:51
|
On 4/9/14, Paul Franklin <pf....@gm...> wrote: > In light of my ignorance and the chance of making a > mistake, I will let somebody else change all the uses > of ngettext to use .format instead of %. |
From: Benny M. <ben...@gm...> - 2014-04-10 16:30:43
|
2014-04-10 3:29 GMT+02:00 Paul Franklin <pf....@gm...>: > You have convinced me. > > In light of my ignorance and the chance of making a > mistake, I will let somebody else change all the uses > of ngettext to use .format instead of %. > > When they want to do it will be up to them. > An uncalled response of John. To elaborate, .format is method of a python string, like split , join, capitalize and many other methods, https://docs.python.org/2/library/stdtypes.html Just as we can use string.split, or string.join in other classes, we can use format in other classes. ngettext only enters the discussion in what string it returns. So indeed, ngettext("%d child", "%d children", child_count) % child_count should be replaced by format method of strings now that that is available and the new 'default'. For plural forms, it should be allowed for translators to return a string without a number. Benny > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Benny M. <ben...@gm...> - 2014-04-10 16:46:22
|
2014-04-10 18:30 GMT+02:00 Benny Malengier <ben...@gm...>: > > > > 2014-04-10 3:29 GMT+02:00 Paul Franklin <pf....@gm...>: > > You have convinced me. >> >> In light of my ignorance and the chance of making a >> mistake, I will let somebody else change all the uses >> of ngettext to use .format instead of %. >> >> When they want to do it will be up to them. >> > > An uncalled response of John. > To elaborate, .format is method of a python string, like split , join, > capitalize and many other methods, > https://docs.python.org/2/library/stdtypes.html > > Just as we can use string.split, or string.join in other classes, we can > use format in other classes. > > ngettext only enters the discussion in what string it returns. > So indeed, > ngettext("%d child", "%d children", child_count) % child_count > should be replaced by format method of strings now that that is available > and the new 'default'. > For plural forms, it should be allowed for translators to return a string > without a number. > > Benny > Note, to quickly find the string operation .format, it should suffice to grep on '.format( ".format( and ).format( as other calls of format will almost certainly be [a-zA-Z0-9_].format and not one of the above (though possible for the third one). Benny > > > >> >> ------------------------------------------------------------------------------ >> Put Bad Developers to Shame >> Dominate Development with Jenkins Continuous Integration >> Continuously Automate Build, Test & Deployment >> Start a new project now. Try Jenkins in the cloud. >> http://p.sf.net/sfu/13600_Cloudbees >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > |
From: Paul F. <pf....@gm...> - 2014-04-10 17:51:37
|
On 4/10/14, Benny Malengier <ben...@gm...> wrote: > should be replaced by format method of strings now that that is available > and the new 'default'. > For plural forms, it should be allowed for translators to return a string > without a number. OK. In light of some of the responses I am willing to do the conversion from "%" to the string.format way. But I will ask if I have questions. The most important question is whether there is a deadline/schedule/goal involved? That is, should the change be put into gramps40? Or should it go into gramps41? Or should it not go into gramps41 and only go into master, once gramps41 is split off from it? |
From: Nick H. <nic...@ho...> - 2014-04-10 18:06:55
|
On 10/04/14 18:51, Paul Franklin wrote: > In light of some of the responses I am willing to > do the conversion from "%" to the string.format > way. Thanks Paul. I have raised a bug for this: 7596: Translation of plurals does not allow the translator to omit the number https://gramps-project.org/bugs/view.php?id=7596 Please feel free assign it to yourself. > > But I will ask if I have questions. > > The most important question is whether there > is a deadline/schedule/goal involved? That is, > should the change be put into gramps40? Or > should it go into gramps41? Or should it not > go into gramps41 and only go into master, once > gramps41 is split off from it? The gramps41 branch doesn't exist yet. I have reported it as a bug in gramps40, so I suggest you fix it in gramps40 and master. The deadline for v4.1 is 7th May, but you may have to be quick for gramps40. Nick. |
From: Paul F. <pf....@gm...> - 2014-04-10 18:16:03
|
On 4/10/14, Nick Hall <nic...@ho...> wrote: > I have reported it as a bug in gramps40, so I suggest you fix it in > gramps40 and master. The deadline for v4.1 is 7th May, but you may have > to be quick for gramps40. Are you sure? Won't that mean that every existing old-way string in the gramps40 po/xx.po files will become invalid, until 1) a new gramps40 gramps.pot is made, and then 2) every translator updates their file? Wouldn't it be better to start it in gramps41? (By putting it in master now, if you haven't made the gramps41 fork yet.) Also, I think the massive Windows work is done or about done, and so 4.0.4 might be made soon. I dislike delaying its release, since it's already been delayed a lot. |
From: Josip <jo...@pi...> - 2014-04-10 18:20:58
|
Dana 10.4.2014. 19:51, Paul Franklin je napisao: > The most important question is whether there > is a deadline/schedule/goal involved? That is, > should the change be put into gramps40? Or > should it go into gramps41? Or should it not > go into gramps41 and only go into master, once > gramps41 is split off from it? Do this in master their translation is mostly outdated anyway. -- Josip |
From: Paul F. <pf....@gm...> - 2014-04-10 00:05:13
|
> Changing code always has the risk of introducing bugs. I said earlier that it was fine with me if you wanted to make the change. Perhaps if you did it there would be no bugs introduced. |