From songofacandy at gmail.com Thu May 6 16:48:22 2010 From: songofacandy at gmail.com (INADA Naoki) Date: Thu, 6 May 2010 23:48:22 +0900 Subject: [Doc-SIG] Question about SequenceMatcher.quick_ratio Message-ID: Hi, all. I am one of translator of Python document. But I am not good at English well. I can't understand one sentence in: http://docs.python.org/library/difflib.html#difflib.SequenceMatcher.quick_ratio > This isn?t defined beyond that it is an upper bound on ratio(), and is faster to compute. I see that quick_ratio() calculates upper bound of ratio(). But I can't get what "this isn't defined beyond that" means. May someone explain this in easy sentence for me? -- INADA Naoki From doug.hellmann at gmail.com Thu May 6 17:06:13 2010 From: doug.hellmann at gmail.com (Doug Hellmann) Date: Thu, 6 May 2010 11:06:13 -0400 Subject: [Doc-SIG] Question about SequenceMatcher.quick_ratio In-Reply-To: References: Message-ID: On May 6, 2010, at 10:48 AM, INADA Naoki wrote: > Hi, all. > > I am one of translator of Python document. > But I am not good at English well. > > I can't understand one sentence in: > http://docs.python.org/library/difflib.html#difflib.SequenceMatcher.quick_ratio > >> This isn?t defined beyond that it is an upper bound on ratio(), and >> is faster to compute. > > I see that quick_ratio() calculates upper bound of ratio(). > But I can't get what "this isn't defined beyond that" means. > May someone explain this in easy sentence for me? I think it means that the implementation of quick_ratio() is not defined in a lot of detail, except to say that the function will return a value that is an upper bound of the value returned by ratio(). So the value returned by ratio() will always be less than or equal to the value returned by quick_ratio(), and quick_ratio() is faster than ratio(). real_quick_ratio() has a similar relationship to quick_ratio(). Doug From brandon at rhodesmill.org Thu May 6 17:00:56 2010 From: brandon at rhodesmill.org (Brandon Craig Rhodes) Date: Thu, 06 May 2010 11:00:56 -0400 Subject: [Doc-SIG] Question about SequenceMatcher.quick_ratio In-Reply-To: (INADA Naoki's message of "Thu, 6 May 2010 23:48:22 +0900") References: Message-ID: <874oilrs5z.fsf@rhodesmill.org> INADA Naoki writes: > I am one of translator of Python document. But I am not good at > English well. I can't understand one sentence ... > >> This isn?t defined beyond that it is an upper bound on ratio(), and >> is faster to compute. The word "bound" works like this: a "bound" or "boundary" means a limit or edge, so often it gets used in math like this: "I am not sure what the exact value of 'pi' is, but I have done some work and established a lower bound of 3.0 and an upper bound of 3.2 for its true value." This means, more simply, that 'pi' lies "between 3.0 and 3.2", but math people have the specific names "lower bound" and "upper bound" for the limits that they work out for the value of an unknown or difficult-to- compute number. So when 'quick_ratio()' claims to return an "upper bound on ratio()", it means that it returns a number that 'ratio()' is guaranteed to be "less than"; it sets, in other words, an upper limit on what the actual value of 'ratio()' might be. So if 'quick_ratio()' returns 0.8, it means that 'ratio()' itself might be 0.8, or 0.6, or 0.003, or 0.00062, or even 0; that is, it might be any permissible ratio value (they run from 0 to 1) that is not more than 0.8 because 'quick_ratio()' has done some checking and is sure that the actual 'ratio()' is less than or equal to 0.8. So did my English make the docs any clearer? Or am I just as confusing? :-) -- Brandon Craig Rhodes brandon at rhodesmill.org http://rhodesmill.org/brandon From songofacandy at gmail.com Thu May 6 17:27:00 2010 From: songofacandy at gmail.com (INADA Naoki) Date: Fri, 7 May 2010 00:27:00 +0900 Subject: [Doc-SIG] Question about SequenceMatcher.quick_ratio In-Reply-To: References:

Message-ID: Thank you, Branodn and Doug for quick reply! The word "upper bound" is also used in Japan with mathematics. > I think it means that the implementation of quick_ratio() is not defined in > a lot of detail, except to say that the function will return a value that is > an upper bound of the value returned by ratio(). That's the answer I wanted!! I've got "This isn't defined beyond that" means "This method is not defined in detail more than". I've misread that "beyond" means "over the upper bound". Maybe, "more" is easier than "beyond" for non-native English readers. Thank you very well. -- INADA Naoki From doug.hellmann at gmail.com Sun May 9 16:19:21 2010 From: doug.hellmann at gmail.com (Doug Hellmann) Date: Sun, 9 May 2010 10:19:21 -0400 Subject: [Doc-SIG] Question about SequenceMatcher.quick_ratio In-Reply-To: References:

Message-ID: On May 6, 2010, at 11:27 AM, INADA Naoki wrote: > Thank you, Branodn and Doug for quick reply! > > The word "upper bound" is also used in Japan with mathematics. > >> I think it means that the implementation of quick_ratio() is not >> defined in >> a lot of detail, except to say that the function will return a >> value that is >> an upper bound of the value returned by ratio(). > > That's the answer I wanted!! > > I've got "This isn't defined beyond that" means > "This method is not defined in detail more than". > > I've misread that "beyond" means "over the upper bound". > Maybe, "more" is easier than "beyond" for non-native English > readers. I agree that the current English phrasing is confusing to non-native speakers. You should open a ticket in the tracker and ask for that text to be clarified. Doug > > Thank you very well. > -- > INADA Naoki > _______________________________________________ > Doc-SIG maillist - Doc-SIG at python.org > http://mail.python.org/mailman/listinfo/doc-sig From ncoghlan at gmail.com Tue May 11 13:01:32 2010 From: ncoghlan at gmail.com (Nick Coghlan) Date: Tue, 11 May 2010 21:01:32 +1000 Subject: [Doc-SIG] Question about SequenceMatcher.quick_ratio In-Reply-To: References:

Message-ID: <4BE9390C.7040101@gmail.com> Doug Hellmann wrote: >> I've got "This isn't defined beyond that" means >> "This method is not defined in detail more than". >> >> I've misread that "beyond" means "over the upper bound". >> Maybe, "more" is easier than "beyond" for non-native English >> readers. > > I agree that the current English phrasing is confusing to non-native > speakers. You should open a ticket in the tracker and ask for that text > to be clarified. Or, as Georg pointed out recently, email docs at python.org mentioning the problem (tracker is best, but an email to the docs address is better than not reporting it directly at all). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- From songofacandy at gmail.com Tue May 11 13:14:53 2010 From: songofacandy at gmail.com (INADA Naoki) Date: Tue, 11 May 2010 20:14:53 +0900 Subject: [Doc-SIG] Question about SequenceMatcher.quick_ratio In-Reply-To: <4BE9390C.7040101@gmail.com> References:

<4BE9390C.7040101@gmail.com> Message-ID: I've posted it as a bug 8686. http://bugs.python.org/issue8686# -- INADA Naoki From amk at amk.ca Wed May 12 16:44:15 2010 From: amk at amk.ca (A.M. Kuchling) Date: Wed, 12 May 2010 10:44:15 -0400 Subject: [Doc-SIG] Library: generic OS services chapter Message-ID: <20100512144415.GA3459@amk-desktop.matrixgroup.net> Random thoughts on the Generic Operating System Services chapter of the library guide: http://docs.python.org/dev/library/allos.html * There are four sections that are very long and complex, nesting down to four levels: argparse, optparse, logging, and ctypes. Should any of them become chapters of their own? logging and ctypes seem like the most plausible ones to move. We could move argparse/optparse/getopt into a chapter by themselves, but that wouldn't reduce the nesting depth at all. * The usual rationale for the ordering is from more widely used modules to more esoteric or little-used. Should we therefore move optparse to follow getopt instead of preceding it? * I thought we were going to add a warning to the optparse docs suggesting people use argparse instead. Shall I go ahead and write that, or was it decided to not do that? --amk From fuzzyman at voidspace.org.uk Wed May 19 20:40:35 2010 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 19 May 2010 19:40:35 +0100 Subject: [Doc-SIG] Library: generic OS services chapter In-Reply-To: <20100512144415.GA3459@amk-desktop.matrixgroup.net> References: <20100512144415.GA3459@amk-desktop.matrixgroup.net> Message-ID: <4BF430A3.8030706@voidspace.org.uk> On 12/05/2010 15:44, A.M. Kuchling wrote: > [snip...] > * I thought we were going to add a warning to the optparse docs > suggesting people use argparse instead. Shall I go ahead and write > that, or was it decided to not do that? > > Yes - I think we definitely should, please go ahead. This was part of the rationale for bringing in a new argument handling module into the standard library. All the best, Michael > --amk > _______________________________________________ > Doc-SIG maillist - Doc-SIG at python.org > http://mail.python.org/mailman/listinfo/doc-sig > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.