Re: [Python-Dev] PEP 448 review

2015-02-27 Thread Nick Coghlan
On 27 Feb 2015 07:12, "Brett Cannon"  wrote:
>
>
>
> On Thu, Feb 26, 2015 at 3:38 PM Ethan Furman  wrote:
>>
>> On 02/26/2015 12:19 PM, Guido van Rossum wrote:
>>
>> > As a follow-up, Joshua updated the PEP to remove *comprehensions, and
it is now accepted.
>>
>> Congratulations Thomas, Joshua, and Neil!!
>
>
> I'll add a "thanks" to everyone involved with the PEP since it was an
involved one implementation-wise and discussion-wise.

Likewise! It was a hard slog to get there, but this will be a nice quality
of life improvement for 3.5+ users. Thanks to everyone involved in moving
it forward :)

Regards,
Nick.

>
> -Brett
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [RELEASED] Python 3.4.3 is now available

2015-02-27 Thread Geoffrey Spear
The download button (for Windows anyway) on the python.org Download
dropdown menu is broken; there's a small gray square where the 3.4.3 button
should be, with the 2.7.9 one working fine.

On Wed, Feb 25, 2015 at 8:07 AM, Larry Hastings  wrote:

>
>
>  On behalf of the Python development community and the Python 3.4 release
> team, I'm pleased to announce the availability of Python 3.4.3.   Python
> 3.4.3 has many bugfixes and other small improvements over 3.4.2.
>
> You can find it here:
>
> https://www.python.org/downloads/release/python-343/
>
>
> The release slipped by two or three days, depending on what time zone
> you're in.  This is my fault--I apologize for the inconvenience.
>
> Cheers,
>
>
> */arry*
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/geoffspear%40gmail.com
>
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [RELEASED] Python 3.4.3 is now available

2015-02-27 Thread Victor Stinner
Hum, it's probably an attack of the Python 2 mafia who fight against Python 3!

Victor

2015-02-27 13:51 GMT+01:00 Geoffrey Spear :
> The download button (for Windows anyway) on the python.org Download dropdown
> menu is broken; there's a small gray square where the 3.4.3 button should
> be, with the 2.7.9 one working fine.
>
> On Wed, Feb 25, 2015 at 8:07 AM, Larry Hastings  wrote:
>>
>>
>>
>> On behalf of the Python development community and the Python 3.4 release
>> team, I'm pleased to announce the availability of Python 3.4.3.   Python
>> 3.4.3 has many bugfixes and other small improvements over 3.4.2.
>>
>> You can find it here:
>>
>> https://www.python.org/downloads/release/python-343/
>>
>>
>> The release slipped by two or three days, depending on what time zone
>> you're in.  This is my fault--I apologize for the inconvenience.
>>
>> Cheers,
>>
>>
>> /arry
>>
>> ___
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/geoffspear%40gmail.com
>>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Update to PEP 11 to clarify garnering platform support

2015-02-27 Thread Brett Cannon
On Fri, Feb 20, 2015 at 1:47 PM Brett Cannon  wrote:

> I just realized I actually never committed this change. Assuming no new
> objections I'll commit this in the near future (promise this time =).
>

My proposed changes have now been committed. Thanks to everyone who
provided feedback!

This should hopefully make it much clearer what it takes to accept
platform-specific patches (i.e., core dev willing to maintain the
compatibility and a stable buildbot for the platform).

For those trying to get Python working on Android, this will mean a
conversation will be necessary about how to get a buildbot or some form or
regular testing set up in order to accept Android-specific patches (along
with a core dev willing to keep an eye on the compatibility).

-Brett


>
>
> On Fri May 16 2014 at 1:51:00 PM Brett Cannon  wrote:
>
>> Here is some proposed wording. Since it is more of a clarification of
>> what it takes to garner support -- which is just a new section -- rather
>> than a complete rewrite I'm including just the diff to make it easier to
>> read the changes.
>>
>>
>> *diff -r 49d18bb47ebc pep-0011.txt*
>>
>> *--- a/pep-0011.txt Wed May 14 11:18:22 2014 -0400*
>>
>> *+++ b/pep-0011.txt Fri May 16 13:48:30 2014 -0400*
>>
>> @@ -2,22 +2,21 @@
>>
>>  Title: Removing support for little used platforms
>>
>>  Version: $Revision$
>>
>>  Last-Modified: $Date$
>>
>> -Author: [email protected] (Martin von Löwis)
>>
>> +Author: Martin von Löwis ,
>>
>> +Brett Cannon 
>>
>>  Status: Active
>>
>>  Type: Process
>>
>>  Content-Type: text/x-rst
>>
>>  Created: 07-Jul-2002
>>
>>  Post-History: 18-Aug-2007
>>
>> +  16-May-2014
>>
>>
>>
>>
>>
>>  Abstract
>>
>>  
>>
>>
>>
>> -This PEP documents operating systems (platforms) which are not
>>
>> -supported in Python anymore.  For some of these systems,
>>
>> -supporting code might be still part of Python, but will be removed
>>
>> -in a future release - unless somebody steps forward as a volunteer
>>
>> -to maintain this code.
>>
>> +This PEP documents how an operating system (platform) garners
>>
>> +support in Python as well as documenting past support.
>>
>>
>>
>>
>>
>>  Rationale
>>
>> @@ -37,16 +36,53 @@
>>
>>  change to the Python source code will work on all supported
>>
>>  platforms.
>>
>>
>>
>> -To reduce this risk, this PEP proposes a procedure to remove code
>>
>> -for platforms with no Python users.
>>
>> +To reduce this risk, this PEP specifies what is required for a
>>
>> +platform to be considered supported by Python as well as providing a
>>
>> +procedure to remove code for platforms with little or no Python
>>
>> +users.
>>
>>
>>
>> +Supporting platforms
>>
>> +
>>
>> +
>>
>> +Gaining official platform support requires two things. First, a core
>>
>> +developer needs to volunteer to maintain platform-specific code. This
>>
>> +core developer can either already be a member of the Python
>>
>> +development team or be given contributor rights on the basis of
>>
>> +maintaining platform support (it is at the discretion of the Python
>>
>> +development team to decide if a person is ready to have such rights
>>
>> +even if it is just for supporting a specific platform).
>>
>> +
>>
>> +Second, a stable buildbot must be provided [2]_. This guarantees that
>>
>> +platform support will not be accidentally broken by a Python core
>>
>> +developer who does not have personal access to the platform. For a
>>
>> +buildbot to be considered stable it requires that the machine be
>>
>> +reliably up and functioning (but it is up to the Python core
>>
>> +developers to decide whether to promote a buildbot to being
>>
>> +considered stable).
>>
>> +
>>
>> +This policy does not disqualify supporting other platforms
>>
>> +indirectly. Patches which are not platform-specific but still done to
>>
>> +add platform support will be considered for inclusion. For example,
>>
>> +if platform-independent changes were necessary in the configure
>>
>> +script which was motivated to support a specific platform that would
>>
>> +be accepted. Patches which add platform-specific code such as the
>>
>> +name of a specific platform to the configure script will generally
>>
>> +not be accepted without the platform having official support.
>>
>> +
>>
>> +CPU architecture and compiler support are viewed in a similar manner
>>
>> +as platforms. For example, to consider the ARM architecture supported
>>
>> +a buildbot running on ARM would be required along with support from
>>
>> +the Python development team. In general it is not required to have
>>
>> +a CPU architecture run under every possible platform in order to be
>>
>> +considered supported.
>>
>>
>>
>>  Unsupporting platforms
>>
>>  --
>>
>>
>>
>> -If a certain platform that currently has special code in it is
>>
>> -deemed to be without Python users, a note must be posted in this
>>
>> -PEP that this platform is no longer actively supported.  This
>>
>> +If a certain platfor

Re: [Python-Dev] Update to PEP 11 to clarify garnering platform support

2015-02-27 Thread Ethan Furman
On 02/27/2015 06:40 AM, Brett Cannon wrote:

> My proposed changes have now been committed. Thanks to everyone who provided 
> feedback!

Thanks, Brett!

> For those trying to get Python working on Android, this will mean a 
> conversation will be necessary about how to get a
> buildbot or some form or regular testing set up in order to accept 
> Android-specific patches (along with a core dev
> willing to keep an eye on the compatibility).

Noted.

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
[email protected]
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

2015-02-27 Thread Thomas Wouters
On Thu, Feb 26, 2015 at 12:37 PM, Ethan Furman  wrote:

> On 02/26/2015 12:19 PM, Guido van Rossum wrote:
>
> > As a follow-up, Joshua updated the PEP to remove *comprehensions, and it
> is now accepted.
>
> Congratulations Thomas, Joshua, and Neil!!
>

Wot, me? No, no, all credit goes to Joshua and Neil. All I did was propose
the change too late for Python 3, then procrastinate until someone else
picked it up. (My procrastination goes so far that I *still* mean to review
the latest patch, as soon as I get round tuits...) I do stand behind the
idea, though, and I'm happy with the PEP and with the final decision.

-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Summary of Python tracker Issues

2015-02-27 Thread Python tracker

ACTIVITY SUMMARY (2015-02-20 - 2015-02-27)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open4788 (+18)
  closed 30510 (+26)
  total  35298 (+44)

Open issues with patches: 2245 


Issues opened (34)
==

#23458: [2.7] random: make the file descriptor non-inheritable (on POS
http://bugs.python.org/issue23458  reopened by haypo

#23494: adding timedelta to datetime object is not timezone aware
http://bugs.python.org/issue23494  opened by gilsho

#23495: The writer.writerows method should be documented as accepting 
http://bugs.python.org/issue23495  opened by Steven.Barker

#23496: Steps for Android Native Build of Python 3.4.2
http://bugs.python.org/issue23496  opened by chaselton

#23498: Expose http.cookiejar.split_header_words()
http://bugs.python.org/issue23498  opened by vadmium

#23500: Argument Clinic: multiple macro definition
http://bugs.python.org/issue23500  opened by serhiy.storchaka

#23501: Argument Clinic: generate code into separate files by default
http://bugs.python.org/issue23501  opened by serhiy.storchaka

#23502: pprint: added support for mapping proxy
http://bugs.python.org/issue23502  opened by serhiy.storchaka

#23503: undefined behavior in Objects/obmalloc.c
http://bugs.python.org/issue23503  opened by dwight.guth

#23504: Add __all__ into types
http://bugs.python.org/issue23504  opened by serhiy.storchaka

#23505: Urlparse insufficient validation leads to open redirect
http://bugs.python.org/issue23505  opened by yaaboukir

#23507: Tuple creation is too slow
http://bugs.python.org/issue23507  opened by serhiy.storchaka

#23508: Document & unittest the subprocess.getstatusoutput() status va
http://bugs.python.org/issue23508  opened by gregory.p.smith

#23509: Speed up Counter operators
http://bugs.python.org/issue23509  opened by joern

#23510: multiprocessing bug SyncManager and 'with'
http://bugs.python.org/issue23510  opened by Cezary.Wagner

#23512: List of builtins is not alphabetical on https://docs.python.or
http://bugs.python.org/issue23512  opened by edsouza

#23513: Add support for classes/object model in multiprocessing/pickle
http://bugs.python.org/issue23513  opened by Cezary.Wagner

#23514: multiprocessing documentation - little more examples for paral
http://bugs.python.org/issue23514  opened by Cezary.Wagner

#23516: pip: urllib3 does not encode userinfo section of URL with auth
http://bugs.python.org/issue23516  opened by leotan

#23517: datetime.utcfromtimestamp parses timestamps incorrectly
http://bugs.python.org/issue23517  opened by tbarbugli

#23520: test_os failed (python-3.4.3)
http://bugs.python.org/issue23520  opened by avoevodkin

#23521: OverflowError from timedelta * float in datetime.py
http://bugs.python.org/issue23521  opened by belopolsky

#23522: Misleading note in Statistics module documentation
http://bugs.python.org/issue23522  opened by Journeyman08

#23524: Use _set_thread_local_invalid_parameter_handler in posixmodule
http://bugs.python.org/issue23524  opened by steve.dower

#23525: isbuiltin, isroutine, etc.
http://bugs.python.org/issue23525  opened by abarnert

#23526: Silence resource warnings in test_httplib
http://bugs.python.org/issue23526  opened by ashkop

#23527: test_smtpnet uses incorrect port for STARTTLS
http://bugs.python.org/issue23527  opened by ashkop

#23528: Limit decompressed data when reading from GzipFile
http://bugs.python.org/issue23528  opened by vadmium

#23529: Limit decompressed data when reading from LZMAFile and BZ2File
http://bugs.python.org/issue23529  opened by vadmium

#23530: os and multiprocessing.cpu_count do not respect cpuset/affinit
http://bugs.python.org/issue23530  opened by jtaylor

#23531: SSL operations cause entire process to hang
http://bugs.python.org/issue23531  opened by johnkw

#23532: add example of 'first match wins' to regex "|"  documentation?
http://bugs.python.org/issue23532  opened by Rick Otten

#23534: `test_longdouble` fails on Mac when using system libffi (versi
http://bugs.python.org/issue23534  opened by Maxime Belanger

#23536: Add explicit information on config file format not supporting 
http://bugs.python.org/issue23536  opened by piotr.dobrogost



Most recent 15 issues with no replies (15)
==

#23536: Add explicit information on config file format not supporting 
http://bugs.python.org/issue23536

#23527: test_smtpnet uses incorrect port for STARTTLS
http://bugs.python.org/issue23527

#23525: isbuiltin, isroutine, etc.
http://bugs.python.org/issue23525

#23522: Misleading note in Statistics module documentation
http://bugs.python.org/issue23522

#23520: test_os failed (python-3.4.3)
http://bugs.python.org/issue23520

#23512: List of builtins is not alphabetical on https://docs.python.or
http://bugs.python.org/issue23512

#23504: Add __all__ into types
http://bugs.python.org/issue23504

Re: [Python-Dev] [RELEASED] Python 3.4.3 is now available

2015-02-27 Thread Guido van Rossum
There's a GitHub tracker for the website:
https://github.com/python/pythondotorg/issues

Please report issues with the website there.

On Fri, Feb 27, 2015 at 5:59 AM, Victor Stinner 
wrote:

> Hum, it's probably an attack of the Python 2 mafia who fight against
> Python 3!
>
> Victor
>
> 2015-02-27 13:51 GMT+01:00 Geoffrey Spear :
> > The download button (for Windows anyway) on the python.org Download
> dropdown
> > menu is broken; there's a small gray square where the 3.4.3 button should
> > be, with the 2.7.9 one working fine.
> >
> > On Wed, Feb 25, 2015 at 8:07 AM, Larry Hastings 
> wrote:
> >>
> >>
> >>
> >> On behalf of the Python development community and the Python 3.4 release
> >> team, I'm pleased to announce the availability of Python 3.4.3.   Python
> >> 3.4.3 has many bugfixes and other small improvements over 3.4.2.
> >>
> >> You can find it here:
> >>
> >> https://www.python.org/downloads/release/python-343/
> >>
> >>
> >> The release slipped by two or three days, depending on what time zone
> >> you're in.  This is my fault--I apologize for the inconvenience.
> >>
> >> Cheers,
> >>
> >>
> >> /arry
> >>
> >> ___
> >> Python-Dev mailing list
> >> [email protected]
> >> https://mail.python.org/mailman/listinfo/python-dev
> >> Unsubscribe:
> >>
> https://mail.python.org/mailman/options/python-dev/geoffspear%40gmail.com
> >>
> >
> >
> > ___
> > Python-Dev mailing list
> > [email protected]
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> >
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
> >
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] PEP 485 review (isclose())

2015-02-27 Thread Guido van Rossum
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)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [RELEASED] Python 3.4.3 is now available

2015-02-27 Thread Carol Willing

Appears to be fixed now on the MacOSx tab.

On 27/02/2015 09:30, Guido van Rossum wrote:
There's a GitHub tracker for the website: 
https://github.com/python/pythondotorg/issues


Please report issues with the website there.

On Fri, Feb 27, 2015 at 5:59 AM, Victor Stinner 
mailto:[email protected]>> wrote:


Hum, it's probably an attack of the Python 2 mafia who fight
against Python 3!

Victor

2015-02-27 13:51 GMT+01:00 Geoffrey Spear mailto:[email protected]>>:
> The download button (for Windows anyway) on the python.org
 Download dropdown
> menu is broken; there's a small gray square where the 3.4.3
button should
> be, with the 2.7.9 one working fine.
>
> On Wed, Feb 25, 2015 at 8:07 AM, Larry Hastings
mailto:[email protected]>> wrote:
>>
>>
>>
>> On behalf of the Python development community and the Python
3.4 release
>> team, I'm pleased to announce the availability of Python
3.4.3.   Python
>> 3.4.3 has many bugfixes and other small improvements over 3.4.2.
>>
>> You can find it here:
>>
>> https://www.python.org/downloads/release/python-343/
>>
>>
>> The release slipped by two or three days, depending on what
time zone
>> you're in.  This is my fault--I apologize for the inconvenience.
>>
>> Cheers,
>>
>>
>> /arry
>>
>> ___
>> Python-Dev mailing list
>> [email protected] 
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>>
https://mail.python.org/mailman/options/python-dev/geoffspear%40gmail.com
>>
>
>
> ___
> Python-Dev mailing list
> [email protected] 
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
>

https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
>
___
Python-Dev mailing list
[email protected] 
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/guido%40python.org




--
--Guido van Rossum (python.org/~guido )


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/willingc%40willingconsulting.com



--
*Carol Willing*
Developer | Willing Consulting
https://willingconsulting.com
___
Python-Dev mailing list
[email protected]
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())

2015-02-27 Thread Chris Barker
Thank you Guido.

It'll be nice to see this all come to something.

Thanks to all who contributed to the discussion -- despite this being a
pretty simple function, I learned a lot and far more fully appreciate the
nuance of all of this.

I'll edit the text as you suggest, 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.

-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

[email protected]
___
Python-Dev mailing list
[email protected]
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())

2015-02-27 Thread Gary Herron

On 02/27/2015 12:07 PM, Chris Barker wrote:

Thank you Guido.

It'll be nice to see this all come to something.

Thanks to all who contributed to the discussion -- despite this being 
a pretty simple function, I learned a lot and far more fully 
appreciate the nuance of all of this.


I'll edit the text as you suggest, 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.


-Chris



There's another typo:  The "Large tolerances" section, references a 
"string test".  Perhaps that should be "strong test", but that would 
seem to contradict the sentence which follows.


--
Dr. Gary Herron
Department of Computer Science
DigiPen Institute of Technology
(425) 895-4418








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

[email protected] 


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/gherron%40islandtraining.com


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com