Re: [Python-Dev] Preserving the definition order of class namespaces.
On 24 May 2015 at 15:53, Eric Snow wrote: > > On May 23, 2015 10:47 PM, "Guido van Rossum" wrote: >> >> How will __definition_order__ be set in the case where __prepare__ doesn't >> return an OrderedDict? Or where a custom metaclass's __new__ calls its >> superclass's __new__ with a plain dict? (I just wrote some code that does >> that. :-) > > I was planning on setting it to None if the order is not available. At the > moment that's just a check for OrderedDict. Is it specifically necessary to save the order by default? Metaclasses would be able to access the ordered namespace in their __new__ method regardless, and for 3.6, I still like the __init_subclass__ hook idea proposed in PEP 487, which includes passing the original namespace to the new hook. So while I'm sold on the value of making class execution namespaces ordered by default, I'm not yet sold on the idea of *remembering* that order without opting in to doing so in the metaclass. If we leave __definition_order__ out for the time being then, for the vast majority of code, the fact that the ephemeral namespace used to evaluate the class body switched from being a basic dictionary to an ordered one would be a hidden implementation detail, rather than making all type objects a little bigger. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Preserving the definition order of class namespaces.
On 24/05/15 10:35, Nick Coghlan wrote: On 24 May 2015 at 15:53, Eric Snow wrote: On May 23, 2015 10:47 PM, "Guido van Rossum" wrote: How will __definition_order__ be set in the case where __prepare__ doesn't return an OrderedDict? Or where a custom metaclass's __new__ calls its superclass's __new__ with a plain dict? (I just wrote some code that does that. :-) I was planning on setting it to None if the order is not available. At the moment that's just a check for OrderedDict. Is it specifically necessary to save the order by default? Metaclasses would be able to access the ordered namespace in their __new__ method regardless, and for 3.6, I still like the __init_subclass__ hook idea proposed in PEP 487, which includes passing the original namespace to the new hook. So while I'm sold on the value of making class execution namespaces ordered by default, I'm not yet sold on the idea of *remembering* that order without opting in to doing so in the metaclass. If we leave __definition_order__ out for the time being then, for the vast majority of code, the fact that the ephemeral namespace used to evaluate the class body switched from being a basic dictionary to an ordered one would be a hidden implementation detail, rather than making all type objects a little bigger. and a little slower. Cheers, Mark. ___ 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] Preserving the definition order of class namespaces.
On 24 May 2015 at 19:44, Mark Shannon wrote: > On 24/05/15 10:35, Nick Coghlan wrote: >> If we leave __definition_order__ out for the time being then, for the >> vast majority of code, the fact that the ephemeral namespace used to >> evaluate the class body switched from being a basic dictionary to an >> ordered one would be a hidden implementation detail, rather than >> making all type objects a little bigger. > and a little slower. The runtime namespace used to store the class attributes is remaining a plain dict object regardless, it's only the ephemeral one that's used to evaluate the class body at definition time that Eric's proposing to switch to an ordered dictionary. That approach avoids any new runtime overhead when using the defined class, while still making the order of attribute assignment available to custom metaclasses by default. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] [python-committers] Reminder: Python 3.5 beta 1 will be tagged tomorrow
On Sat, May 23, 2015 at 4:25 PM, Nick Coghlan wrote: > On 23 May 2015 at 19:29, Tal Einat wrote: >> On Sat, May 23, 2015 at 1:34 AM, Berker Peksağ >> wrote: >>> >>> * The C implementation should be in Modules/mathmodule.c >>> * Tests should be in Lib/test/test_math.py >>> * Documentation should be in Doc/library/math.rst >>> * Add an entry to Doc/whatsnew/3.5.rst >>> * If I remember correctly, we don't need the Python implementation and its >>> tests >> >> I'll happily review the patch once it's on the bug tracker as Berker >> described. > > I filed http://bugs.python.org/issue24270 to track this, but there's a > fair bit of work to be done to integrate the changes into the existing > math module's code, tests and documentation. Done. Patch attached to the issue. Awaiting review! - Tal Einat ___ 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] [python-committers] Reminder: Python 3.5 beta 1 will be tagged tomorrow
On Sun, May 24, 2015 at 4:40 AM, Tal Einat wrote: > > I filed http://bugs.python.org/issue24270 to track this, but there's a > > fair bit of work to be done to integrate the changes into the existing > > math module's code, tests and documentation. > > Done. Patch attached to the issue. Awaiting review! > Wow! thanks so much! I'm a bit tied up with my day job right now: (http://incidentnews.noaa.gov/incident/8934) so wasn't sure I could do that fiddly work soon enough. I should find a couple hours to look over it all today, I hope. What do folks think about adding one to cmath as well, while we are at it? It should be pretty straightforward -- I could focus what time I have to do that. -Chris -- 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] [python-committers] Reminder: Python 3.5 beta 1 will be tagged tomorrow
On Sun, May 24, 2015 at 6:40 PM, Chris Barker wrote: > > What do folks think about adding one to cmath as well, while we are at it? > It should be pretty straightforward -- I could focus what time I have to do > that. I prefer focusing on getting math.isclose() in before tackling cmath.isclose(), though it would indeed be very straightforward given the work already done. Larry has stated he's willing to make an exception to the "no new features" rule for this, so I think we should have time to get the cmath version in for 3.5 even if we wait a few days with it. So if you have time, I'd prefer that you thoroughly review the patch. - Tal Einat ___ 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] An yocto change proposal in logging module to simplify structured logs support
Hi,
1. The problem
For now, when you want to write a log message, you concatenate the data
from your context to generate a string: In fact, you convert your
structured data to a string.
When a sysadmin needs to debug your logs when something is wrong, he must
write regular expressions to extract interesting data.
Often, he must find the beginning of the interesting log and follow the
path. Sometimes, you can have several requests in the same time in the log,
it's harder to find interesting log.
In fact, with regular expressions, the sysadmin tries to convert the log
lines strings to structured data.
2. A possible solution
You should provide a set of regular expressions to your sysadmins to help
them to find the right logs, however, another approach is possible:
structured logs.
Instead of to break your data structure to push in the log message, the
idea is to keep the data structure, to attach that as metadata of the log
message.
For now, I know at least Logstash and Journald that can handle structured
logs and provide a query tool to extract easily logs.
3. A concrete example with structured logs
As most Web developers, we build HTTP daemons used by several different
human clients in the same time.
In the Python source code, to support structured logs, you don't have a big
change, you can use "extra" parameter for that, example:
[handle HTTP request]
LOG.debug('Receive a create_or_update request', extra={'request_id':
request.request_id,
'account_id': account_id,
'aiohttp_request': request,
'payload': str(payload)})
[create data in database]
LOG.debug('Callflow created', extra={'account_id': account_id,
'request_id':
request.request_id,
'aiopg_cursor': cur,
'results': row})
Now, if you want, you can enhance the structured log with a custom logging
Handler, because the standard journald handler doesn't know how to handle
aiohttp_request or aiopg_cursor.
My example is based on journald, but you can write an equivalent version
with python-logstash:
from systemdream.journal.handler import JournalHandler
class Handler(JournalHandler):
# Tip: on a system without journald, use socat to test:
# socat UNIX-RECV:/run/systemd/journal/socket STDIN
def emit(self, record):
if record.extra:
# import ipdb; ipdb.set_trace()
if 'aiohttp_request' in record.extra:
record.extra['http_method'] =
record.extra['aiohttp_request'].method
record.extra['http_path'] =
record.extra['aiohttp_request'].path
record.extra['http_headers'] =
str(record.extra['aiohttp_request'].headers)
del(record.extra['aiohttp_request'])
if 'aiopg_cursor' in record.extra:
record.extra['pg_query'] =
record.extra['aiopg_cursor'].query.decode('utf-8')
record.extra['pg_status_message'] =
record.extra['aiopg_cursor'].statusmessage
record.extra['pg_rows_count'] =
record.extra['aiopg_cursor'].rowcount
del(record.extra['aiopg_cursor'])
super().emit(record)
And you can enable this custom handler in your logging config file like
this:
[handler_journald]
class=XX.utils.logs.Handler
args=()
formatter=detailed
And now, with journalctl, you can easily extract logs, some examples:
Logs messages from 'lg' account:
journalctl ACCOUNT_ID=lg
All HTTP requests that modify the 'lg' account (PUT, POST and DELETE):
journalctl ACCOUNT_ID=lg HTTP_METHOD=PUT
HTTP_METHOD=POST HTTP_METHOD=DELETE
Retrieve all logs from one specific HTTP request:
journalctl REQUEST_ID=130b8fa0-6576-43b6-a624-4a4265a2fbdd
All HTTP requests with a specific path:
journalctl HTTP_PATH=/v1/accounts/lg/callflows
All logs of "create" function in the file "example.py"
journalctl CODE_FUNC=create CODE_FILE=/path/example.py
If you already do a troubleshooting on a production system, you should
understand the interest of this:
In fact, it's like to have SQL queries capabilities, but it's logging
oriented.
We use that since a small time on one of our critical daemon that handles a
lot of requests across several servers, it's already adopted from our
support team.
4. The yocto issue with the Python logging module
I don't explain here a small part of my professional life for my pleasure,
but to help you to understand the context and the usages, because my patch
for logging is very small.
If you're an expert of Python logging, you already know that my Handler
class example I provided above can't run on a classical Python logging,
because LogRecord doesn't have an extra attribute.
extra parameter exists in the Logger, but, in the LogRecord, it's merged as
attributes of LogRecord:
https://github.com/python/cpython/blob/master/Lib/logging/__init__.py#L1386
It means,
Re: [Python-Dev] [python-committers] Reminder: Python 3.5 beta 1 will be tagged tomorrow
On Sun, May 24, 2015 at 10:00 AM, Tal Einat wrote: > On Sun, May 24, 2015 at 6:40 PM, Chris Barker > wrote: > > What do folks think about adding one to cmath as well, while we are at > it? > > It should be pretty straightforward -- I could focus what time I have to > do > > that. > > I prefer focusing on getting math.isclose() in before tackling > cmath.isclose(), though it would indeed be very straightforward given > the work already done. Larry has stated he's willing to make an > exception to the "no new features" rule for this, so I think we should > have time to get the cmath version in for 3.5 even if we wait a few > days with it. So if you have time, I'd prefer that you thoroughly > review the patch. > makes sense. stay tuned. -CHB -- 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] Preserving the definition order of class namespaces.
On May 24, 2015 3:35 AM, "Nick Coghlan" wrote: > Is it specifically necessary to save the order by default? Metaclasses > would be able to access the ordered namespace in their __new__ method > regardless, and for 3.6, I still like the __init_subclass__ hook idea > proposed in PEP 487, which includes passing the original namespace to > the new hook. > > So while I'm sold on the value of making class execution namespaces > ordered by default, I'm not yet sold on the idea of *remembering* that > order without opting in to doing so in the metaclass. > > If we leave __definition_order__ out for the time being then, for the > vast majority of code, the fact that the ephemeral namespace used to > evaluate the class body switched from being a basic dictionary to an > ordered one would be a hidden implementation detail, rather than > making all type objects a little bigger. It's too late for 3.5 to negotiate much so I'll try to make my case here for __definition_order__ one last time. If that's not sufficient then I'll defer further discussion to 3.6. My premise for storing the definition order on the class is that Guido was okay with using OrderedDict for cls.__dict__, which is a bigger change. Regardless, there are two reasons why it makes sense: * If it makes sense to use OrderedDict by default for class definition then it makes sense to preserve the extra information OrderedDict provides. * As I noted at the beginning of the thread, you could still preserve that info manually, but that makes it less convenient for library authors. If you still think that's not enough justification then we can table __definition_order__ for now. -eric ___ 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] Preserving the definition order of class namespaces.
On Sun, May 24, 2015 at 1:36 PM, Eric Snow wrote: > On May 24, 2015 3:35 AM, "Nick Coghlan" wrote: > > Is it specifically necessary to save the order by default? Metaclasses > > would be able to access the ordered namespace in their __new__ method > > regardless, and for 3.6, I still like the __init_subclass__ hook idea > > proposed in PEP 487, which includes passing the original namespace to > > the new hook. > > > > So while I'm sold on the value of making class execution namespaces > > ordered by default, I'm not yet sold on the idea of *remembering* that > > order without opting in to doing so in the metaclass. > > > > If we leave __definition_order__ out for the time being then, for the > > vast majority of code, the fact that the ephemeral namespace used to > > evaluate the class body switched from being a basic dictionary to an > > ordered one would be a hidden implementation detail, rather than > > making all type objects a little bigger. > > It's too late for 3.5 to negotiate much so I'll try to make my case here > for __definition_order__ one last time. If that's not sufficient then > I'll defer further discussion to 3.6. > > My premise for storing the definition order on the class is that Guido was > okay with using OrderedDict for cls.__dict__, which is a bigger change. > Regardless, there are two reasons why it makes sense: > > * If it makes sense to use OrderedDict by default for class definition > then it makes sense to preserve the extra information OrderedDict provides. > * As I noted at the beginning of the thread, you could still preserve that > info manually, but that makes it less convenient for library authors. > > If you still think that's not enough justification then we can table > __definition_order__ for now. > Let's table it. It's hard to compare alternatives on a single dimension of "which is a bigger change". -- --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] Preserving the definition order of class namespaces.
On 25 May 2015 07:26, "Guido van Rossum" wrote: > > On Sun, May 24, 2015 at 1:36 PM, Eric Snow wrote: >> >> My premise for storing the definition order on the class is that Guido was okay with using OrderedDict for cls.__dict__, which is a bigger change. Regardless, there are two reasons why it makes sense: >> >> * If it makes sense to use OrderedDict by default for class definition then it makes sense to preserve the extra information OrderedDict provides. >> * As I noted at the beginning of the thread, you could still preserve that info manually, but that makes it less convenient for library authors. It occurs to me that even the basic change makes it possible to provide initialisation helpers that accept locals() from a currently running class definition and return a definition ordered list of fields (perhaps restricted to values of a certain type, such as database column definitions, or webform field definitions). >> If you still think that's not enough justification then we can table __definition_order__ for now. > > > Let's table it. It's hard to compare alternatives on a single dimension of "which is a bigger change". Right, it isn't that I think __definition_order__ is necessarily a bad idea, I just suspect it's redundant if we end up going ahead with __init_subclass__ (which would allow a base class to opt in to preserving the definition order, either of all fields or selected ones), and the latter change is definitely out of scope for 3.5 at this point. There are also other open questions, like whether or not dir() should respect the order when reporting attribute names, or if dict_proxy should respect the order when iterating. Regards, Nick. > > -- > --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] An yocto change proposal in logging module to simplify structured logs support
Please post your idea to the python-ideas list. -- Terry Jan Reedy ___ 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] [RELEASED] Python 3.5.0b1 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm pleased to announce the availability of Python 3.5.0b1. Python 3.5 has now entered "feature freeze". By default new features may no longer be added to Python 3.5. (However, there are a handful of features that weren't quite ready for Python 3.5.0 beta 1; these were granted exceptions to the freeze, and are scheduled to be added before beta 2.) This is a preview release, and its use is not recommended for production settings. Three important notes for Windows users about Python 3.5.0b1: * If you have previously installed Python 3.5.0a1, you may need to manually uninstall it before installing Python 3.5.0b1 (issue23612). * If installing Python 3.5.0b1 as a non-privileged user, you may need to escalate to administrator privileges to install an update to your C runtime libraries. * There is now a third type of Windows build for Python 3.5. In addition to the conventional installer and the web-based installer, Python 3.5 now has an embeddable release designed to be deployed as part of a larger application's installer for apps using or extending Python. During the 3.5 alpha releases, this was an executable installer; as of 3.5.0 beta 1 the embeddable build of Python is now shipped in a zip file. You can find Python 3.5.0b1 here: https://www.python.org/downloads/release/python-350b1/ Happy hacking, //arry/ ___ 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] Reminder: 3.5 now has its own branch! "default" branch is now 3.6!
I've now pushed the 3.5.0 beta 1 release-engineering checkins to hg.python.org. At the same time I did this, I also created the 3.5 branch. Quick FAQ: Q: Where should I check in bugfixes for 3.5? A: In the "3.5" branch. You should also merge them forward into "default". Q: Where should I check in new features for 3.5? A: You sillyhead! New features aren't allowed for 3.5 anymore, it's in feature freeze. Q: What is "default" now? A: "default" is now 3.6. Meaning, you can now start on new features for 3.6! You don't have to wait until 3.5 final is released, like how we used to do it. Q: What's all this about bitbucket and push requests? A: We don't start doing that until 3.5.0 release candidate 1. Don't worry about it for now. When the time comes, I'll post instructions here and to the devguide. A new day is dawning, //arry/ ___ 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] Preserving the definition order of class namespaces.
On May 24, 2015 4:52 PM, "Nick Coghlan" wrote: > > > On 25 May 2015 07:26, "Guido van Rossum" wrote: > > > > On Sun, May 24, 2015 at 1:36 PM, Eric Snow wrote: > >> If you still think that's not enough justification then we can table __definition_order__ for now. > > > > > > Let's table it. It's hard to compare alternatives on a single dimension of "which is a bigger change". Sounds good. > > Right, it isn't that I think __definition_order__ is necessarily a bad idea, I just suspect it's redundant if we end up going ahead with __init_subclass__ (which would allow a base class to opt in to preserving the definition order, either of all fields or selected ones), > and the latter change is definitely out of scope for 3.5 at this point. > > There are also other open questions, like whether or not dir() should respect the order when reporting attribute names, or if dict_proxy should respect the order when iterating. Yeah, I'll start up a thread on python-ideas once I've gotten the other stuff wrapped up. Thanks for the feedback. -eric ___ 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.5.0b1 is now available
: On Sun, May 24, 2015 at 04:39:00PM -0700, Larry Hastings wrote: > > You can find Python 3.5.0b1 here: > >https://www.python.org/downloads/release/python-350b1/ Source tarballs (both .tgz and .tar.xz) are missing ... -[]z. -- Zero Piraeus: vive ut vivas http://etiol.net/pubkey.asc ___ 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] Reminder: 3.5 now has its own branch! "default" branch is now 3.6!
On Mon, May 25, 2015 at 9:49 AM, Larry Hastings wrote: > I've now pushed the 3.5.0 beta 1 release-engineering checkins to > hg.python.org. At the same time I did this, I also created the 3.5 branch. > > Quick FAQ: Additional Q. What does this mean for buildbots? Will they immediately pick up the new branch? Apologies if this is a dumb question. My buildbot is temporarily down (hardware failure, working on it) so I can't easily check what it's doing. (And I'm not sure I'd know for sure if I saw the right result anyway.) ChrisA ___ 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.5.0b1 is now available
In article <20150525001522.GA30305@piedra>, Zero Piraeus wrote: > On Sun, May 24, 2015 at 04:39:00PM -0700, Larry Hastings wrote: > > You can find Python 3.5.0b1 here: > >https://www.python.org/downloads/release/python-350b1/ > Source tarballs (both .tgz and .tar.xz) are missing ... They seem to be there now. Are you still not able to download them? -- Ned Deily, [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] Reminder: 3.5 now has its own branch! "default" branch is now 3.6!
On 05/24/2015 06:01 PM, Chris Angelico wrote: Additional Q. What does this mean for buildbots? Will they immediately pick up the new branch? I don't know about "immediately", but yes the buildbots should get configured to point at the 3.5 branch, preferably soon. //arry/ ___ 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: math.isclose()
I don't think I have permissions to comment on the issue,so I'm posting here. If there is a way for me to post to the issue, someone let me know... In the issue (http://bugs.python.org/issue24270) Tal wrote """ I have a question regarding complex values. The code (from Chris Barker) doesn't support complex values (only things that can be converted into doubles). However, the PEP states the following under "Non-float types": "complex : for complex, the absolute value of the complex values will be used for scaling and comparison. If a complex tolerance is passed in, the absolute value will be used as the tolerance." """ right -- that was written before it was decided that isclose() needed to be written in C -- the python version supported that. """ Should math.isclose() support complex values? """ nope -- the math module is all about floats. """ Should an equivalent function be added to cmath? """ I think so -- lets see if we can do that in time for 3.5 -- but first get the float one done. """ Should we just leave things as they are and remove mention of complex values from the PEP (it isn't mentioned in the docs)? """ I'll update the PEP. -Chris -- 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: math.isclose()
On Mon, May 25, 2015 at 7:53 AM, Chris Barker wrote: > I don't think I have permissions to comment on the issue,so I'm posting > here. If there is a way for me to post to the issue, someone let me know... You just need to register on the issue tracker. On bugs.python.org, there is a "register" link under the "User" section on the navigation bar. > In the issue (http://bugs.python.org/issue24270) Tal wrote > > [...] > > """ > Should we just leave things as they are and remove mention of complex > values from the PEP (it isn't mentioned in the docs)? > """ > I'll update the PEP. If we're going to add a separate complex version of isclose() to the cmath module, then you should probably leave the PEP as it is. While we're on the subject of the PEP, is there a reason that the cmath version should accept complex values for the tolerances? I'd expect it to accept only floats, and I think that allowing complex values would be more confusing than useful. - Tal Einat ___ 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: math.isclose()
And a few comments on the patch ( I have not idea how to patch a patch...) Is there a branch somewhere with this patch applied? I'm going through PEP 7, and cleaned up the docstring a bit: diff -r 15af4f58d143 Modules/mathmodule.c --- a/Modules/mathmodule.c Sun May 24 22:27:00 2015 -0700 +++ b/Modules/mathmodule.c Sun May 24 22:57:52 2015 -0700 @@ -2051,8 +2051,8 @@ } PyDoc_STRVAR(math_isclose_doc, -"Determine if two floating point numbers are in value\n\n" - +"is_close(a, b, rel_tol, abs_tol) -> bool\n\n" +"Determine if two floating point numbers are similar in value\n\n" "Returns True if a is close in value to b. False otherwise\n\n" ":param a: one of the values to be tested\n\n" ":param b: the other value to be tested\n\n" and there is a missing space in the docs: in math.rst: Return ``True`` if the values *a* and *b* are close to each other and ``False`` otherwise. need a space between "each" and "other" But it all looks good otherwise -- thanks! -Chris On Sun, May 24, 2015 at 9:53 PM, Chris Barker wrote: > I don't think I have permissions to comment on the issue,so I'm posting > here. If there is a way for me to post to the issue, someone let me know... > > In the issue (http://bugs.python.org/issue24270) Tal wrote > > """ > I have a question regarding complex values. The code (from Chris Barker) > doesn't support complex values (only things that can be converted into > doubles). However, the PEP states the following under "Non-float types": > > "complex : for complex, the absolute value of the complex values will be > used for scaling and comparison. If a complex tolerance is passed in, the > absolute value will be used as the tolerance." > """ > > right -- that was written before it was decided that isclose() needed to > be written in C -- the python version supported that. > > """ > Should math.isclose() support complex values? > """ > nope -- the math module is all about floats. > > """ > Should an equivalent function be added to cmath? > """ > > I think so -- lets see if we can do that in time for 3.5 -- but first get > the float one done. > > """ > Should we just leave things as they are and remove mention of complex > values from the PEP (it isn't mentioned in the docs)? > """ > I'll update the PEP. > > -Chris > > > > -- > > 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] > -- 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
