Re: [Python-Dev] PEP 448 review
Hi everyone,
The patch is ready for review now, and I should have time this week to make
changes and respond to comments.
Best,
Neil
On Wed, Feb 25, 2015 at 2:42 PM, Guido van Rossum wrote:
> I'm back, I've re-read the PEP, and I've re-read the long thread with "(no
> subject)".
>
> I think Georg Brandl nailed it:
>
> """
>
>
>
>
>
>
>
>
> *I like the "sequence and dict flattening" part of the PEP, mostly because
> itis consistent and should be easy to understand, but the comprehension
> syntaxenhancements seem to be bad for readability and "comprehending" what
> the codedoes.The call syntax part is a mixed bag on the one hand it is nice
> to be consistent with the extended possibilities in literals (flattening),
> but on the other hand there would be small but annoying inconsistencies
> anyways (e.g. the duplicate kwarg case above).*
> """
>
> Greg Ewing followed up explaining that the inconsistency between dict
> flattening and call syntax is inherent in the pre-existing different rules
> for dicts vs. keyword args: {'a':1, 'a':2} results in {'a':2}, while f(a=1,
> a=2) is an error. (This form is a SyntaxError; the dynamic case f(a=1,
> **{'a': 1}) is a TypeError.)
>
> For me, allowing f(*a, *b) and f(**d, **e) and all the other combinations
> for function calls proposed by the PEP is an easy +1 -- it's a
> straightforward extension of the existing pattern, and anybody who knows
> what f(x, *a) does will understand f(x, *a, y, *b). Guessing what f(**d,
> **e) means shouldn't be hard either. Understanding the edge case for
> duplicate keys with f(**d, **e) is a little harder, but the error messages
> are pretty clear, and it is not a new edge case.
>
> The sequence and dict flattening syntax proposals are also clean and
> logical -- we already have *-unpacking on the receiving side, so allowing
> *x in tuple expressions reads pretty naturally (and the similarity with *a
> in argument lists certainly helps). From here, having [a, *x, b, *y] is
> also natural, and then the extension to other displays is natural: {a, *x,
> b, *y} and {a:1, **d, b:2, **e}. This, too, gets a +1 from me.
>
> So that leaves comprehensions. IIRC, during the development of the patch
> we realized that f(*x for x in xs) is sufficiently ambiguous that we
> decided to disallow it -- note that f(x for x in xs) is already somewhat of
> a special case because an argument can only be a "bare" generator
> expression if it is the only argument. The same reasoning doesn't apply (in
> that form) to list, set and dict comprehensions -- while f(x for x in xs)
> is identical in meaning to f((x for x in xs)), [x for x in xs] is NOT the
> same as [(x for x in xs)] (that's a list of one element, and the element is
> a generator expression).
>
> The basic premise of this part of the proposal is that if you have a few
> iterables, the new proposal (without comprehensions) lets you create a list
> or generator expression that iterates over all of them, essentially
> flattening them:
>
> >>> xs = [1, 2, 3]
> >>> ys = ['abc', 'def']
> >>> zs = [99]
> >>> [*xs, *ys, *zs]
> [1, 2, 3, 'abc', 'def', 99]
> >>>
>
> But now suppose you have a list of iterables:
>
> >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
> >>> [*xss[0], *xss[1], *xss[2]]
> [1, 2, 3, 'abc', 'def', 99]
> >>>
>
> Wouldn't it be nice if you could write the latter using a comprehension?
>
> >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
> >>> [*xs for xs in xss]
> [1, 2, 3, 'abc', 'def', 99]
> >>>
>
> This is somewhat seductive, and the following is even nicer: the *xs
> position may be an expression, e.g.:
>
> >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
> >>> [*xs[:2] for xs in xss]
> [1, 2, 'abc', 'def', 99]
> >>>
>
> On the other hand, I had to explore the possibilities here by
> experimenting in the interpreter, and I discovered some odd edge cases
> (e.g. you can parenthesize the starred expression, but that seems a
> syntactic accident).
>
> All in all I am personally +0 on the comprehension part of the PEP, and I
> like that it provides a way to "flatten" a sequence of sequences, but I
> think very few people in the thread have supported this part. Therefore I
> would like to ask Neil to update the PEP and the patch to take out the
> comprehension part, so that the two "easy wins" can make it into Python 3.5
> (basically, I am accepting two-thirds of the PEP :-). There is some time
> yet until alpha 2.
>
> I would also like code reviewers (Benjamin?) to start reviewing the patch
> , taking into account that the
> comprehension part needs to be removed.
>
> --
> --Guido van Rossum (python.org/~guido)
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 448 review
Where is the patch?
Victor
Le lundi 2 mars 2015, Neil Girdhar a écrit :
> Hi everyone,
>
> The patch is ready for review now, and I should have time this week to
> make changes and respond to comments.
>
> Best,
>
> Neil
>
> On Wed, Feb 25, 2015 at 2:42 PM, Guido van Rossum > wrote:
>
>> I'm back, I've re-read the PEP, and I've re-read the long thread with
>> "(no subject)".
>>
>> I think Georg Brandl nailed it:
>>
>> """
>>
>>
>>
>>
>>
>>
>>
>>
>> *I like the "sequence and dict flattening" part of the PEP, mostly
>> because itis consistent and should be easy to understand, but the
>> comprehension syntaxenhancements seem to be bad for readability and
>> "comprehending" what the codedoes.The call syntax part is a mixed bag on
>> the one hand it is nice to be consistent with the extended possibilities in
>> literals (flattening), but on the other hand there would be small but
>> annoying inconsistencies anyways (e.g. the duplicate kwarg case above).*
>> """
>>
>> Greg Ewing followed up explaining that the inconsistency between dict
>> flattening and call syntax is inherent in the pre-existing different rules
>> for dicts vs. keyword args: {'a':1, 'a':2} results in {'a':2}, while f(a=1,
>> a=2) is an error. (This form is a SyntaxError; the dynamic case f(a=1,
>> **{'a': 1}) is a TypeError.)
>>
>> For me, allowing f(*a, *b) and f(**d, **e) and all the other combinations
>> for function calls proposed by the PEP is an easy +1 -- it's a
>> straightforward extension of the existing pattern, and anybody who knows
>> what f(x, *a) does will understand f(x, *a, y, *b). Guessing what f(**d,
>> **e) means shouldn't be hard either. Understanding the edge case for
>> duplicate keys with f(**d, **e) is a little harder, but the error messages
>> are pretty clear, and it is not a new edge case.
>>
>> The sequence and dict flattening syntax proposals are also clean and
>> logical -- we already have *-unpacking on the receiving side, so allowing
>> *x in tuple expressions reads pretty naturally (and the similarity with *a
>> in argument lists certainly helps). From here, having [a, *x, b, *y] is
>> also natural, and then the extension to other displays is natural: {a, *x,
>> b, *y} and {a:1, **d, b:2, **e}. This, too, gets a +1 from me.
>>
>> So that leaves comprehensions. IIRC, during the development of the patch
>> we realized that f(*x for x in xs) is sufficiently ambiguous that we
>> decided to disallow it -- note that f(x for x in xs) is already somewhat of
>> a special case because an argument can only be a "bare" generator
>> expression if it is the only argument. The same reasoning doesn't apply (in
>> that form) to list, set and dict comprehensions -- while f(x for x in xs)
>> is identical in meaning to f((x for x in xs)), [x for x in xs] is NOT the
>> same as [(x for x in xs)] (that's a list of one element, and the element is
>> a generator expression).
>>
>> The basic premise of this part of the proposal is that if you have a few
>> iterables, the new proposal (without comprehensions) lets you create a list
>> or generator expression that iterates over all of them, essentially
>> flattening them:
>>
>> >>> xs = [1, 2, 3]
>> >>> ys = ['abc', 'def']
>> >>> zs = [99]
>> >>> [*xs, *ys, *zs]
>> [1, 2, 3, 'abc', 'def', 99]
>> >>>
>>
>> But now suppose you have a list of iterables:
>>
>> >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>> >>> [*xss[0], *xss[1], *xss[2]]
>> [1, 2, 3, 'abc', 'def', 99]
>> >>>
>>
>> Wouldn't it be nice if you could write the latter using a comprehension?
>>
>> >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>> >>> [*xs for xs in xss]
>> [1, 2, 3, 'abc', 'def', 99]
>> >>>
>>
>> This is somewhat seductive, and the following is even nicer: the *xs
>> position may be an expression, e.g.:
>>
>> >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>> >>> [*xs[:2] for xs in xss]
>> [1, 2, 'abc', 'def', 99]
>> >>>
>>
>> On the other hand, I had to explore the possibilities here by
>> experimenting in the interpreter, and I discovered some odd edge cases
>> (e.g. you can parenthesize the starred expression, but that seems a
>> syntactic accident).
>>
>> All in all I am personally +0 on the comprehension part of the PEP, and I
>> like that it provides a way to "flatten" a sequence of sequences, but I
>> think very few people in the thread have supported this part. Therefore I
>> would like to ask Neil to update the PEP and the patch to take out the
>> comprehension part, so that the two "easy wins" can make it into Python 3.5
>> (basically, I am accepting two-thirds of the PEP :-). There is some time
>> yet until alpha 2.
>>
>> I would also like code reviewers (Benjamin?) to start reviewing the patch
>> , taking into account that the
>> comprehension part needs to be removed.
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>>
>
___
Python-Dev mailing list
Pyt
Re: [Python-Dev] PEP 448 review
http://bugs.python.org/issue2292
On Mon, Mar 2, 2015 at 3:17 PM, Victor Stinner
wrote:
> Where is the patch?
>
> Victor
>
> Le lundi 2 mars 2015, Neil Girdhar a écrit :
>
> Hi everyone,
>>
>> The patch is ready for review now, and I should have time this week to
>> make changes and respond to comments.
>>
>> Best,
>>
>> Neil
>>
>> On Wed, Feb 25, 2015 at 2:42 PM, Guido van Rossum
>> wrote:
>>
>>> I'm back, I've re-read the PEP, and I've re-read the long thread with
>>> "(no subject)".
>>>
>>> I think Georg Brandl nailed it:
>>>
>>> """
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *I like the "sequence and dict flattening" part of the PEP, mostly
>>> because itis consistent and should be easy to understand, but the
>>> comprehension syntaxenhancements seem to be bad for readability and
>>> "comprehending" what the codedoes.The call syntax part is a mixed bag on
>>> the one hand it is nice to be consistent with the extended possibilities in
>>> literals (flattening), but on the other hand there would be small but
>>> annoying inconsistencies anyways (e.g. the duplicate kwarg case above).*
>>> """
>>>
>>> Greg Ewing followed up explaining that the inconsistency between dict
>>> flattening and call syntax is inherent in the pre-existing different rules
>>> for dicts vs. keyword args: {'a':1, 'a':2} results in {'a':2}, while f(a=1,
>>> a=2) is an error. (This form is a SyntaxError; the dynamic case f(a=1,
>>> **{'a': 1}) is a TypeError.)
>>>
>>> For me, allowing f(*a, *b) and f(**d, **e) and all the other
>>> combinations for function calls proposed by the PEP is an easy +1 -- it's a
>>> straightforward extension of the existing pattern, and anybody who knows
>>> what f(x, *a) does will understand f(x, *a, y, *b). Guessing what f(**d,
>>> **e) means shouldn't be hard either. Understanding the edge case for
>>> duplicate keys with f(**d, **e) is a little harder, but the error messages
>>> are pretty clear, and it is not a new edge case.
>>>
>>> The sequence and dict flattening syntax proposals are also clean and
>>> logical -- we already have *-unpacking on the receiving side, so allowing
>>> *x in tuple expressions reads pretty naturally (and the similarity with *a
>>> in argument lists certainly helps). From here, having [a, *x, b, *y] is
>>> also natural, and then the extension to other displays is natural: {a, *x,
>>> b, *y} and {a:1, **d, b:2, **e}. This, too, gets a +1 from me.
>>>
>>> So that leaves comprehensions. IIRC, during the development of the patch
>>> we realized that f(*x for x in xs) is sufficiently ambiguous that we
>>> decided to disallow it -- note that f(x for x in xs) is already somewhat of
>>> a special case because an argument can only be a "bare" generator
>>> expression if it is the only argument. The same reasoning doesn't apply (in
>>> that form) to list, set and dict comprehensions -- while f(x for x in xs)
>>> is identical in meaning to f((x for x in xs)), [x for x in xs] is NOT the
>>> same as [(x for x in xs)] (that's a list of one element, and the element is
>>> a generator expression).
>>>
>>> The basic premise of this part of the proposal is that if you have a few
>>> iterables, the new proposal (without comprehensions) lets you create a list
>>> or generator expression that iterates over all of them, essentially
>>> flattening them:
>>>
>>> >>> xs = [1, 2, 3]
>>> >>> ys = ['abc', 'def']
>>> >>> zs = [99]
>>> >>> [*xs, *ys, *zs]
>>> [1, 2, 3, 'abc', 'def', 99]
>>> >>>
>>>
>>> But now suppose you have a list of iterables:
>>>
>>> >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>>> >>> [*xss[0], *xss[1], *xss[2]]
>>> [1, 2, 3, 'abc', 'def', 99]
>>> >>>
>>>
>>> Wouldn't it be nice if you could write the latter using a comprehension?
>>>
>>> >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>>> >>> [*xs for xs in xss]
>>> [1, 2, 3, 'abc', 'def', 99]
>>> >>>
>>>
>>> This is somewhat seductive, and the following is even nicer: the *xs
>>> position may be an expression, e.g.:
>>>
>>> >>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>>> >>> [*xs[:2] for xs in xss]
>>> [1, 2, 'abc', 'def', 99]
>>> >>>
>>>
>>> On the other hand, I had to explore the possibilities here by
>>> experimenting in the interpreter, and I discovered some odd edge cases
>>> (e.g. you can parenthesize the starred expression, but that seems a
>>> syntactic accident).
>>>
>>> All in all I am personally +0 on the comprehension part of the PEP, and
>>> I like that it provides a way to "flatten" a sequence of sequences, but I
>>> think very few people in the thread have supported this part. Therefore I
>>> would like to ask Neil to update the PEP and the patch to take out the
>>> comprehension part, so that the two "easy wins" can make it into Python 3.5
>>> (basically, I am accepting two-thirds of the PEP :-). There is some time
>>> yet until alpha 2.
>>>
>>> I would also like code reviewers (Benjamin?) to start reviewing the
>>> patch
Re: [Python-Dev] PEP 448 review
On 03/02/2015 12:18 PM, Neil Girdhar wrote: > On Mon, Mar 2, 2015 at 3:17 PM, Victor Stinner wrote: >> Le lundi 2 mars 2015, Neil Girdhar a écrit : >>> >>> The patch is ready for review now, and I should have time this week to >>> make changes and respond to comments. >> >> Where is the patch? > > http://bugs.python.org/issue2292 The latest file there is from Feb 26, while your message that the patch was ready for review is from today -- so is the patch from five days ago the most recent? -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 448 review
It's from five days ago. I asked Joshua to take a look at something, but I
guess he is busy.
Best,
Neil
—
The latest file there is from Feb 26, while your message that the patch was
ready for review is from today -- so is the
patch from five days ago the most recent?
--
~Ethan~
On Mon, Mar 2, 2015 at 3:18 PM, Neil Girdhar wrote:
> http://bugs.python.org/issue2292
>
> On Mon, Mar 2, 2015 at 3:17 PM, Victor Stinner
> wrote:
>
>> Where is the patch?
>>
>> Victor
>>
>> Le lundi 2 mars 2015, Neil Girdhar a écrit :
>>
>> Hi everyone,
>>>
>>> The patch is ready for review now, and I should have time this week to
>>> make changes and respond to comments.
>>>
>>> Best,
>>>
>>> Neil
>>>
>>> On Wed, Feb 25, 2015 at 2:42 PM, Guido van Rossum
>>> wrote:
>>>
I'm back, I've re-read the PEP, and I've re-read the long thread with
"(no subject)".
I think Georg Brandl nailed it:
"""
*I like the "sequence and dict flattening" part of the PEP, mostly
because itis consistent and should be easy to understand, but the
comprehension syntaxenhancements seem to be bad for readability and
"comprehending" what the codedoes.The call syntax part is a mixed bag on
the one hand it is nice to be consistent with the extended possibilities in
literals (flattening), but on the other hand there would be small but
annoying inconsistencies anyways (e.g. the duplicate kwarg case above).*
"""
Greg Ewing followed up explaining that the inconsistency between dict
flattening and call syntax is inherent in the pre-existing different rules
for dicts vs. keyword args: {'a':1, 'a':2} results in {'a':2}, while f(a=1,
a=2) is an error. (This form is a SyntaxError; the dynamic case f(a=1,
**{'a': 1}) is a TypeError.)
For me, allowing f(*a, *b) and f(**d, **e) and all the other
combinations for function calls proposed by the PEP is an easy +1 -- it's a
straightforward extension of the existing pattern, and anybody who knows
what f(x, *a) does will understand f(x, *a, y, *b). Guessing what f(**d,
**e) means shouldn't be hard either. Understanding the edge case for
duplicate keys with f(**d, **e) is a little harder, but the error messages
are pretty clear, and it is not a new edge case.
The sequence and dict flattening syntax proposals are also clean and
logical -- we already have *-unpacking on the receiving side, so allowing
*x in tuple expressions reads pretty naturally (and the similarity with *a
in argument lists certainly helps). From here, having [a, *x, b, *y] is
also natural, and then the extension to other displays is natural: {a, *x,
b, *y} and {a:1, **d, b:2, **e}. This, too, gets a +1 from me.
So that leaves comprehensions. IIRC, during the development of the
patch we realized that f(*x for x in xs) is sufficiently ambiguous that we
decided to disallow it -- note that f(x for x in xs) is already somewhat of
a special case because an argument can only be a "bare" generator
expression if it is the only argument. The same reasoning doesn't apply (in
that form) to list, set and dict comprehensions -- while f(x for x in xs)
is identical in meaning to f((x for x in xs)), [x for x in xs] is NOT the
same as [(x for x in xs)] (that's a list of one element, and the element is
a generator expression).
The basic premise of this part of the proposal is that if you have a
few iterables, the new proposal (without comprehensions) lets you create a
list or generator expression that iterates over all of them, essentially
flattening them:
>>> xs = [1, 2, 3]
>>> ys = ['abc', 'def']
>>> zs = [99]
>>> [*xs, *ys, *zs]
[1, 2, 3, 'abc', 'def', 99]
>>>
But now suppose you have a list of iterables:
>>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>>> [*xss[0], *xss[1], *xss[2]]
[1, 2, 3, 'abc', 'def', 99]
>>>
Wouldn't it be nice if you could write the latter using a comprehension?
>>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>>> [*xs for xs in xss]
[1, 2, 3, 'abc', 'def', 99]
>>>
This is somewhat seductive, and the following is even nicer: the *xs
position may be an expression, e.g.:
>>> xss = [[1, 2, 3], ['abc', 'def'], [99]]
>>> [*xs[:2] for xs in xss]
[1, 2, 'abc', 'def', 99]
>>>
On the other hand, I had to explore the possibilities here by
experimenting in the interpreter, and I discovered some odd edge cases
(e.g. you can parenthesize the starred expression, but that seems a
syntactic accident).
All in all I am personally +0 on the comprehension part of the PEP, and
I like that it provides a way to "flatten" a sequence of seq
Re: [Python-Dev] PEP 485 review (isclose())
On Fri, Feb 27, 2015 at 12:07 PM, Chris Barker wrote: > I'll edit the text as you suggest, > Done. > and then work on a patch -- I'm sure I'll have questions for Python-dev > when I actually do that, but I'll get started on my own and see how far I > get. > OK -- big question 1: As far as I can tell, the math module is entirely a C extension. So I can: 1) write isclose() in C -- I could probably do that (It's been a while -- I'm a big Cython fan these days...) and I'd probably punt on having it work with anything other than floats if I did that -- which would fit how most of the match module works anyway. 2) Write it in Python, and monkey-patch it in to the math module -- I honestly have no idea how to do that, but as I can add a new name to the math module after importing it, it should be doable --but I have no idea where the code would go. Suggestions?? Thanks, -Chris > -Chris > > > > > > On Fri, Feb 27, 2015 at 11:38 AM, Guido van Rossum > wrote: > >> I think it's time to accept PEP 485. I've re-read it once more, and it >> looks like the text is in great shape. (My only recommendation would be to >> update the Abstract to state that we're specifically adding math.isclose().) >> >> A wording question: "This implementation has a flag that lets the user >> select which relative tolerance test to apply -- this PEP does not suggest >> that that be retained, but rather than the weak test be selected." -- I >> think this was meant to say "... rather *that* the weak test be selected", >> right? (It would be nice if the sample implementation defaulted to the >> choice in the PEP.) >> >> However, those are just minor edits, and I hereby approve the PEP. Thanks >> Chris and everyone else for the fruitful discussion (and thanks especially >> to Chris for eventually ending the bikeshedding and writing a PEP that >> explains each of the choices). Congrats! >> >> -- >> --Guido van Rossum (python.org/~guido) >> > > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar...@noaa.gov > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 485 review (isclose())
It should be written in C. I thought you knew. :-) I guess it's okay to drop Decimal support (*). Complex support probably should be in cmath. But this is an amendmend to the PEP as accepted. If anyone cares about these changes they should speak up, otherwise the PEP should be updated. (*) Adding it to the decimal module would require a discussion with Raymond Hettinger, but Decimal users can probably copy and paste the formula from the PEP. On Monday, March 2, 2015, Chris Barker wrote: > On Fri, Feb 27, 2015 at 12:07 PM, Chris Barker > wrote: > >> I'll edit the text as you suggest, >> > > Done. > > >> and then work on a patch -- I'm sure I'll have questions for Python-dev >> when I actually do that, but I'll get started on my own and see how far I >> get. >> > > OK -- big question 1: > > As far as I can tell, the math module is entirely a C extension. So I can: > > 1) write isclose() in C -- I could probably do that (It's been a while -- > I'm a big Cython fan these days...) and I'd probably punt on having it work > with anything other than floats if I did that -- which would fit how most > of the match module works anyway. > > 2) Write it in Python, and monkey-patch it in to the math module -- I > honestly have no idea how to do that, but as I can add a new name to the > math module after importing it, it should be doable --but I have no idea > where the code would go. > > Suggestions?? > > Thanks, > -Chris > > > > > > > > >> -Chris >> >> >> >> >> >> On Fri, Feb 27, 2015 at 11:38 AM, Guido van Rossum > > wrote: >> >>> I think it's time to accept PEP 485. I've re-read it once more, and it >>> looks like the text is in great shape. (My only recommendation would be to >>> update the Abstract to state that we're specifically adding math.isclose().) >>> >>> A wording question: "This implementation has a flag that lets the user >>> select which relative tolerance test to apply -- this PEP does not suggest >>> that that be retained, but rather than the weak test be selected." -- I >>> think this was meant to say "... rather *that* the weak test be selected", >>> right? (It would be nice if the sample implementation defaulted to the >>> choice in the PEP.) >>> >>> However, those are just minor edits, and I hereby approve the PEP. >>> Thanks Chris and everyone else for the fruitful discussion (and thanks >>> especially to Chris for eventually ending the bikeshedding and writing a >>> PEP that explains each of the choices). Congrats! >>> >>> -- >>> --Guido van Rossum (python.org/~guido) >>> >> >> >> >> -- >> >> Christopher Barker, Ph.D. >> Oceanographer >> >> Emergency Response Division >> NOAA/NOS/OR&R(206) 526-6959 voice >> 7600 Sand Point Way NE (206) 526-6329 fax >> Seattle, WA 98115 (206) 526-6317 main reception >> >> chris.bar...@noaa.gov >> >> > > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar...@noaa.gov > > -- --Guido van Rossum (on iPad) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 485 review (isclose())
On Mon, Mar 2, 2015 at 10:39 PM, Guido van Rossum wrote: > It should be written in C. I thought you knew. :-) > It crossed my mind when we talked about the math module -- but I didn't really think about it... I guess it's okay to drop Decimal support (*). Complex support probably > should be in cmath. > fair enough -- and easy enough to do if we do float-only in math, and complex-only in cmath. But this is an amendmend to the PEP as accepted. If anyone cares about > these changes they should speak up, otherwise the PEP should be updated. > will do. > (*) Adding it to the decimal module would require a discussion with > Raymond Hettinger, but Decimal users can probably copy and paste the > formula from the PEP. > > yup -- but maybe worth putting in there while we're at it. though as Decimal is arbitrary precision, maybe it's not needed -Chris > On Monday, March 2, 2015, Chris Barker wrote: > >> On Fri, Feb 27, 2015 at 12:07 PM, Chris Barker >> wrote: >> >>> I'll edit the text as you suggest, >>> >> >> Done. >> >> >>> and then work on a patch -- I'm sure I'll have questions for Python-dev >>> when I actually do that, but I'll get started on my own and see how far I >>> get. >>> >> >> OK -- big question 1: >> >> As far as I can tell, the math module is entirely a C extension. So I can: >> >> 1) write isclose() in C -- I could probably do that (It's been a while -- >> I'm a big Cython fan these days...) and I'd probably punt on having it work >> with anything other than floats if I did that -- which would fit how most >> of the match module works anyway. >> >> 2) Write it in Python, and monkey-patch it in to the math module -- I >> honestly have no idea how to do that, but as I can add a new name to the >> math module after importing it, it should be doable --but I have no idea >> where the code would go. >> >> Suggestions?? >> >> Thanks, >> -Chris >> >> >> >> >> >> >> >> >>> -Chris >>> >>> >>> >>> >>> >>> On Fri, Feb 27, 2015 at 11:38 AM, Guido van Rossum >>> wrote: >>> I think it's time to accept PEP 485. I've re-read it once more, and it looks like the text is in great shape. (My only recommendation would be to update the Abstract to state that we're specifically adding math.isclose().) A wording question: "This implementation has a flag that lets the user select which relative tolerance test to apply -- this PEP does not suggest that that be retained, but rather than the weak test be selected." -- I think this was meant to say "... rather *that* the weak test be selected", right? (It would be nice if the sample implementation defaulted to the choice in the PEP.) However, those are just minor edits, and I hereby approve the PEP. Thanks Chris and everyone else for the fruitful discussion (and thanks especially to Chris for eventually ending the bikeshedding and writing a PEP that explains each of the choices). Congrats! -- --Guido van Rossum (python.org/~guido) >>> >>> >>> >>> -- >>> >>> Christopher Barker, Ph.D. >>> Oceanographer >>> >>> Emergency Response Division >>> NOAA/NOS/OR&R(206) 526-6959 voice >>> 7600 Sand Point Way NE (206) 526-6329 fax >>> Seattle, WA 98115 (206) 526-6317 main reception >>> >>> chris.bar...@noaa.gov >>> >> >> >> >> -- >> >> Christopher Barker, Ph.D. >> Oceanographer >> >> Emergency Response Division >> NOAA/NOS/OR&R(206) 526-6959 voice >> 7600 Sand Point Way NE (206) 526-6329 fax >> Seattle, WA 98115 (206) 526-6317 main reception >> >> chris.bar...@noaa.gov >> > > > -- > --Guido van Rossum (on iPad) > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
