Re: [Python-Dev] New math functions
Raymond Hettinger wrote:
> Was some thought given to possibly adding these as
> float methods instead of as separate functions?
>
> float.isinf()
> float.isnan()
>
> Also, it would be useful to have a new method, float.is_integer(). This
> would be better than the current approach where we make the
> test: if x == floor(x).
No, I haven't thought about it. I could add isinf (or better is_inf?) to
the float type but the methods in the math and cmath module should stay
as well. They can also deal with complex and integer numbers.
+1 for is_integer
static PyObject *
float_is_integer(PyObject *v)
{
double x = PyFloat_AsDouble(v);
PyObject *o;
if (x == -1.0 && PyErr_Occurred())
return NULL;
if (!Py_IS_FINITE(x))
Py_RETURN_FALSE;
PyFPE_START_PROTECT("is_integer", return 0)
o = (floor(x) == x) ? Py_True : Py_False;
PyFPE_END_PROTECT(x)
if (errno != 0) {
PyErr_SetFromErrno(errno == ERANGE ? PyExc_OverflowError :
PyExc_ValueError);
return NULL;
}
Py_INCREF(o);
return o;
}
Christian
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New math functions
On Tue, Feb 12, 2008 at 1:52 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > Also, it would be useful to have a new method, float.is_integer(). This > would be better than the current approach where we make the > test: if x == floor(x). > How common is this test? Given the inexact nature of floating-point arithmetic, checking whether a float is exactly an integer seems like something that one might actually want to discourage, just like comparing two floats for equality. Also, what about having float.is_finite, as a quicker way to spell "not isinf(x) and not isnan(x)" +1 on making these methods of float; they're fundamental properties. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k and asyncore/asynchat
On Thu, Feb 14, 2008 at 06:24:04PM -0800, Josiah Carlson wrote: > 1.a. Figure out what the hell is up with OOB data, how to handle it, > and stop making it use handle_expt(). Does OOB data actually need to be supported? For a long time TCP implementations usually had buggy OOB implementations because it was so rarely used; for all I know, that's still the case. Maybe the feature should just be dropped. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k and asyncore/asynchat
On Fri, Feb 15, 2008 at 09:24:14AM -0500, A.M. Kuchling wrote: > On Thu, Feb 14, 2008 at 06:24:04PM -0800, Josiah Carlson wrote: > > 1.a. Figure out what the hell is up with OOB data, how to handle it, > > and stop making it use handle_expt(). > > Does OOB data actually need to be supported? For a long time TCP > implementations usually had buggy OOB implementations because it was > so rarely used; for all I know, that's still the case. Maybe the > feature should just be dropped. Only if you're happy to make it impossible to implement some protocols using asyncore. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New math functions
Mark Dickinson wrote: > On Tue, Feb 12, 2008 at 1:52 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > >> Also, it would be useful to have a new method, float.is_integer(). This >> would be better than the current approach where we make the >> test: if x == floor(x). >> > > How common is this test? Given the inexact nature of floating-point > arithmetic, checking whether a float is exactly an integer seems like > something that one might actually want to discourage, just like comparing > two floats for equality. > > Also, what about having float.is_finite, as a quicker way to spell "not > isinf(x) and not isnan(x)" > > +1 on making these methods of float; they're fundamental properties. > > Mark Yes, and I don't know if this was mentioned, but should add to complex also. isfinite (complex_x): return isfinite (x.real) and isfinite (x.imag) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Tracker Issues
ACTIVITY SUMMARY (02/08/08 - 02/15/08) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1720 open (+39) / 12232 closed (+13) / 13952 total (+52) Open issues with patches: 449 Average duration of open issues: 745 days. Median duration of open issues: 1081 days. Open Issues Breakdown open 1695 (+37) pending25 ( +2) Issues Created Or Reopened (53) ___ PYO file permission problem 02/08/08 http://bugs.python.org/issue2051created stocker81 Lack of difflib.HtmlDiff unicode support 02/08/08 http://bugs.python.org/issue2052created josephoenix IDLE - standardize dialogs 02/09/08 http://bugs.python.org/issue2053created taleinat patch add ftp-tls support to ftplib - RFC 4217 02/09/08 http://bugs.python.org/issue2054created gregory.p.smith easy test_fcntl.py converted to unittest 02/09/08 http://bugs.python.org/issue2055created giampaolo.rodola patch install command rejects --compiler option02/10/08 CLOSED http://bugs.python.org/issue2056created kermode difflib: add patch capability02/10/08 http://bugs.python.org/issue2057created techtonik reduce tarfile memory footprint 02/10/08 http://bugs.python.org/issue2058created lars.gustaebel patch OptionMenu class is defined both in Tkinter and Tix 02/10/08 http://bugs.python.org/issue2059created isandler python2.6 -3 gives "warning: callable() not supported in 3.x" on 02/10/08 http://bugs.python.org/issue2060created eopadoan IDLE - autocompletion to support alternate patch separators 02/10/08 http://bugs.python.org/issue2061created taleinat patch IDLE - autocompletion logic optimization 02/10/08 http://bugs.python.org/issue2062created taleinat patch os.times() utime and stime exchanged on windows 02/11/08 CLOSED http://bugs.python.org/issue2063created kcwu patch List of Dicts problem02/11/08 CLOSED http://bugs.python.org/issue2064created sunaluak trunk version does not compile with vs8 and vc6 02/11/08 http://bugs.python.org/issue2065created amaury.forgeotdarc Adding new CNS11643, a *huge* charset, support in cjkcodecs 02/11/08 http://bugs.python.org/issue2066created hyeshik.chang file.__exit__ does not call subclass' close method 02/11/08 http://bugs.python.org/issue2067created belopolsky SimpleXMLRPCServer documentation about rpc_paths might be wrong 02/11/08 http://bugs.python.org/issue2072created schwarz asynchat push always sends 512 bytes (ignoring ac_out_buffer_siz 02/11/08 http://bugs.python.org/issue2073created mkc pprint._safe_repr() unsafe on ordering differently types objects 02/12/0
Re: [Python-Dev] Py3k and asyncore/asynchat
On 15 Feb, 03:24, "Josiah Carlson" <[EMAIL PROTECTED]> wrote: > As I stated 2+ and 6+ months ago, the patches I submitted 9+ months > ago work (I've been using them in my own projects without issue). The > only issue with the bugfix/rearrangement that I last heard about with > regards to the 2.x stuff was that I removed a class that no one was > using in the wild, which I believe Giampaolo added in a subsequent > patch in the last couple months. I provided the patch for the other issue (look at what is specified in ac_out_buffer_size) but I didn't re-add fifo and simple_producer classes. What should be done here? Re-add or discard them? However, I will send to you by e-mail the modified asynchat version. It is based on your patch therefore a first commit could be finally done. > My suggestion: > 1. Apply the most recent fixes to 2.6 asyncore/asynchat that Giampaolo > has updated. > 1.a. Figure out what the hell is up with OOB data, how to handle it, > and stop making it use handle_expt(). If we want to leave OOB untouched shouldn't handle_expt be the right place where manage such kind of events? Alternatively we could also remove the OOB management at all (e.g. Twisted does that by ignoring such kind of data). OOB could be actually useful to implement some protocols such as FTP (in details ABOR and STAT commands which require OOB data) but it would be probably better not having it than having it but not implemented properly. I am saying this also because later or soonish we might need to care of epoll and kqueue (http://bugs.python.org/issue1657). > * Scheduled tasks are not a valid enhancement for either; anyone who > wants them can trivially add them with their own asyncore.loop() > variant and call asyncore.poll() as necessary (I did it in about 15 > lines in the summer of 2002, I hope others can do better now). If you > want my opinion on other async-related features, feel free to email me > directly (use the gmail address you see here, then it ends up in my > inbox, not the overflowing python folder). How's your solution? Could you post it here or send it to me by mail? IMO scheduled tasks is a very important feature for implementing a lot of interesting stuff like connection timeouts and bandwidth throttling. A lot of people have to learn/use Twisted just because of that. Moreover I think that Bill Janssen could need that feature to make the ssl module work with asyncore. PS - I have been reading this mailing list for a short time therefore I have no clue whether or not someone has ever thought about including the Twisted core - only itself - in Python stdlib. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k and asyncore/asynchat
I think we should just replace the current "loop" with this (and add the "schedule" function). Then other folks won't have to figure out how the module works and write their own loop. I'll be happy to update the documentation to document it. Bill > Twisted core has been proposed, but I believe the consensus was that > it wasn't desirable, generally. > > I'm also pretty sure that people learn twisted because everyone learns > twisted. It's one of those buzz-words ;). > > As for task scheduling, I believe it was something like... > > import asyncore > import time > import heapq > > tasks = [] > > def schedule(delta, callme): > heapq.heappush(tasks, (time.time()+delta, callme)) > > def loop_with_schedule(timeout=30): > while 1: > now = time.time() > while tasks and tasks[0][0] < now: > callme = heapq.heappop(tasks)[1] > try: > callme() > except (KeyboardInterrupt, SystemExit): > raise > except: > #do something useful > pass > thistimeout = timeout > if tasks: > thistimeout = max(min(thistimeout, tasks[0][0]-now), 0) > > asyncore.poll(timeout=thistimeout) > > - Josiah > > > On Fri, Feb 15, 2008 at 11:45 AM, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > > On 15 Feb, 03:24, "Josiah Carlson" <[EMAIL PROTECTED]> wrote: > > > > > As I stated 2+ and 6+ months ago, the patches I submitted 9+ months > > > ago work (I've been using them in my own projects without issue). The > > > only issue with the bugfix/rearrangement that I last heard about with > > > regards to the 2.x stuff was that I removed a class that no one was > > > using in the wild, which I believe Giampaolo added in a subsequent > > > patch in the last couple months. > > > > I provided the patch for the other issue (look at what is specified in > > ac_out_buffer_size) but I didn't re-add fifo and simple_producer > > classes. > > What should be done here? Re-add or discard them? > > However, I will send to you by e-mail the modified asynchat version. > > It is based on your patch therefore a first commit could be finally > > done. > > > > > > > My suggestion: > > > 1. Apply the most recent fixes to 2.6 asyncore/asynchat that Giampaolo > > > has updated. > > > > > 1.a. Figure out what the hell is up with OOB data, how to handle it, > > > and stop making it use handle_expt(). > > > > If we want to leave OOB untouched shouldn't handle_expt be the right > > place where manage such kind of events? > > Alternatively we could also remove the OOB management at all (e.g. > > Twisted does that by ignoring such kind of data). > > OOB could be actually useful to implement some protocols such as FTP > > (in details ABOR and STAT commands which require OOB data) but it > > would be probably better not having it than having it but not > > implemented properly. > > I am saying this also because later or soonish we might need to care > > of epoll and kqueue (http://bugs.python.org/issue1657). > > > > > > > * Scheduled tasks are not a valid enhancement for either; anyone who > > > wants them can trivially add them with their own asyncore.loop() > > > variant and call asyncore.poll() as necessary (I did it in about 15 > > > lines in the summer of 2002, I hope others can do better now). If you > > > want my opinion on other async-related features, feel free to email me > > > directly (use the gmail address you see here, then it ends up in my > > > inbox, not the overflowing python folder). > > > > How's your solution? Could you post it here or send it to me by mail? > > IMO scheduled tasks is a very important feature for implementing a lot > > of interesting stuff like connection timeouts and bandwidth > > throttling. > > A lot of people have to learn/use Twisted just because of that. > > Moreover I think that Bill Janssen could need that feature to make the > > ssl module work with asyncore. > > > > > > PS - I have been reading this mailing list for a short time therefore > > I have no clue whether or not someone has ever thought about including > > the Twisted core - only itself - in Python stdlib. > > > > > > ___ > > Python-Dev mailing list > > [email protected] > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > http://mail.python.org/mailman/options/python-dev/josiah.carlson%40gmail.com > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/janssen%40parc.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Error in PEP3118?
Travis Oliphant schrieb: > Thomas Heller wrote: >> Travis Oliphant schrieb: >> >>> So, I think the example is correct (and intentional). >> >> Sorry, I do not think so. If you use a 2-d array in the example, you >> must describe it correctly. The difference between this pep and the old > > I don't understand what you mean by "must describe it correctly". The [...] Travis, it seems anyone except me understands what you say and thinks it is fine. So, IMO it would be best to live with this misunderstanding and close the discussion. Thanks and sorry about the confusion, Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k and asyncore/asynchat
Bill Janssen wrote: > I think we should just replace the current "loop" with this (and add > the "schedule" function). Then other folks won't have to figure out > how the module works and write their own loop. Having beaten my way down this road of broken glass, I would like args and kwargs if you are adding this: def schedule(delta, fn, *args, **kwargs): heap.heappush(tasks, (time.time()+delta, (fn, args, kwargs))) ... callme[0](*callme[1], **callme[2]) Joel ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Calling a builtin from C code; PEP 3101 format() builtin
Greg Ewing wrote: > Eric Smith wrote: > >> 1: exposing builtin_format(), probably giving it another name >> (PyObject_Format?) and moving it somewhere other than bltinmodule.c. > > PyObject_Format sounds more like an API for invoking the > __format__ lookup mechanism. Maybe something like > PyObject_DefaultFormat would be better. I see it like: PyObject_Str(o) gives you str(o), PyObject_Unicode(o) gives you unicode(o) so PyObject_Format(o, spec) give you format(o, spec). All 3 of them do things with __special__ methods. Eric. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k and asyncore/asynchat
On 15 Feb, 21:36, Bill Janssen <[EMAIL PROTECTED]> wrote: > I think we should just replace the current "loop" with this (and add > the "schedule" function). Then other folks won't have to figure out > how the module works and write their own loop. I'll be happy to update > the documentation to document it. > > Bill I'm -1. This does not permit to reset, cancel or "re-schedule" the scheduled tasks. Something like a connection timeout after a certain time of client's inactivity would not be possible to implement. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k and asyncore/asynchat
Twisted core has been proposed, but I believe the consensus was that it wasn't desirable, generally. I'm also pretty sure that people learn twisted because everyone learns twisted. It's one of those buzz-words ;). As for task scheduling, I believe it was something like... import asyncore import time import heapq tasks = [] def schedule(delta, callme): heapq.heappush(tasks, (time.time()+delta, callme)) def loop_with_schedule(timeout=30): while 1: now = time.time() while tasks and tasks[0][0] < now: callme = heapq.heappop(tasks)[1] try: callme() except (KeyboardInterrupt, SystemExit): raise except: #do something useful pass thistimeout = timeout if tasks: thistimeout = max(min(thistimeout, tasks[0][0]-now), 0) asyncore.poll(timeout=thistimeout) - Josiah On Fri, Feb 15, 2008 at 11:45 AM, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > On 15 Feb, 03:24, "Josiah Carlson" <[EMAIL PROTECTED]> wrote: > > > As I stated 2+ and 6+ months ago, the patches I submitted 9+ months > > ago work (I've been using them in my own projects without issue). The > > only issue with the bugfix/rearrangement that I last heard about with > > regards to the 2.x stuff was that I removed a class that no one was > > using in the wild, which I believe Giampaolo added in a subsequent > > patch in the last couple months. > > I provided the patch for the other issue (look at what is specified in > ac_out_buffer_size) but I didn't re-add fifo and simple_producer > classes. > What should be done here? Re-add or discard them? > However, I will send to you by e-mail the modified asynchat version. > It is based on your patch therefore a first commit could be finally > done. > > > > My suggestion: > > 1. Apply the most recent fixes to 2.6 asyncore/asynchat that Giampaolo > > has updated. > > > 1.a. Figure out what the hell is up with OOB data, how to handle it, > > and stop making it use handle_expt(). > > If we want to leave OOB untouched shouldn't handle_expt be the right > place where manage such kind of events? > Alternatively we could also remove the OOB management at all (e.g. > Twisted does that by ignoring such kind of data). > OOB could be actually useful to implement some protocols such as FTP > (in details ABOR and STAT commands which require OOB data) but it > would be probably better not having it than having it but not > implemented properly. > I am saying this also because later or soonish we might need to care > of epoll and kqueue (http://bugs.python.org/issue1657). > > > > * Scheduled tasks are not a valid enhancement for either; anyone who > > wants them can trivially add them with their own asyncore.loop() > > variant and call asyncore.poll() as necessary (I did it in about 15 > > lines in the summer of 2002, I hope others can do better now). If you > > want my opinion on other async-related features, feel free to email me > > directly (use the gmail address you see here, then it ends up in my > > inbox, not the overflowing python folder). > > How's your solution? Could you post it here or send it to me by mail? > IMO scheduled tasks is a very important feature for implementing a lot > of interesting stuff like connection timeouts and bandwidth > throttling. > A lot of people have to learn/use Twisted just because of that. > Moreover I think that Bill Janssen could need that feature to make the > ssl module work with asyncore. > > > PS - I have been reading this mailing list for a short time therefore > I have no clue whether or not someone has ever thought about including > the Twisted core - only itself - in Python stdlib. > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/josiah.carlson%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Calling a builtin from C code; PEP 3101 format() builtin
Eric Smith wrote: > Greg Ewing wrote: >> Eric Smith wrote: >> >>> 1: exposing builtin_format(), probably giving it another name >>> (PyObject_Format?) and moving it somewhere other than bltinmodule.c. >> PyObject_Format sounds more like an API for invoking the >> __format__ lookup mechanism. Maybe something like >> PyObject_DefaultFormat would be better. > > I see it like: > PyObject_Str(o) gives you str(o), > PyObject_Unicode(o) gives you unicode(o) > so > PyObject_Format(o, spec) give you format(o, spec). > > All 3 of them do things with __special__ methods. Having heard no objections, I'm going to call this PyObject_Format and put it in abstract.c. Eric. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] dir() and __all__
Should dir(module) use __all__ when defined? >>> dir(Queue) ['Empty', 'Full', 'LifoQueue', 'PriorityQueue', 'Queue', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', '_time', 'deque', 'heapq'] >>> Queue.__all__ ['Empty', 'Full', 'Queue', 'PriorityQueue', 'LifoQueue'] I like the second one better. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dir() and __all__
It's not consistent with what dir() of a class or instance does though. -1. On Fri, Feb 15, 2008 at 5:30 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > Should dir(module) use __all__ when defined? > > >>> dir(Queue) > ['Empty', 'Full', 'LifoQueue', 'PriorityQueue', 'Queue', '__all__', > '__builtins__', '__doc__', '__file__', '__name__', '__package__', '_time', > 'deque', 'heapq'] > > >>> Queue.__all__ > ['Empty', 'Full', 'Queue', 'PriorityQueue', 'LifoQueue'] > > I like the second one better. > > > Raymond > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dir() and __all__
Maybe classes should have __all__ too, then the people who complain about not being able to declare private class attributes could be pointed at that. regards Steve Guido van Rossum wrote: > It's not consistent with what dir() of a class or instance does though. > > -1. > > On Fri, Feb 15, 2008 at 5:30 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> Should dir(module) use __all__ when defined? >> >> >>> dir(Queue) >> ['Empty', 'Full', 'LifoQueue', 'PriorityQueue', 'Queue', '__all__', >> '__builtins__', '__doc__', '__file__', '__name__', '__package__', '_time', >> 'deque', 'heapq'] >> >> >>> Queue.__all__ >> ['Empty', 'Full', 'Queue', 'PriorityQueue', 'LifoQueue'] >> >> I like the second one better. >> >> >> Raymond >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > > -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dir() and __all__
Guido> It's not consistent with what dir() of a class or instance does Guido> though. -1. Agreed. The only official use I'm aware of is to restrict what is imported when you execute from mod import * Raymond> >>> Queue.__all__ Raymond> ['Empty', 'Full', 'Queue', 'PriorityQueue', 'LifoQueue'] >> I like the second one better. How would you easily ask an object for all its attributes? Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dir() and __all__
[Raymond] >> Should dir(module) use __all__ when defined? [GvR] > It's not consistent with what dir() of a class or instance does though. > > -1. Perhaps there is another solution. Have dir() exclude objects which are modules. For example, dir(logging) would exclude sys, os, types, time, string, cStringIO, and traceback. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] trunk-math
Dear all, I'd like to draw your attention to some of the work that's been going on in the trunk-math branch. Christian Heimes and I have been working on various aspects of Python mathematics, and we're hoping to get at least some of this work into Python 2.6/3.0. Most of the changes are completed or nearly complete, and 2.6/3.0 isn't very far away, so it seems like a good time to try to get some feedback from python-dev. Here's an overview of the changes (overview originally written by Christian, edited and augmented by me. I hope Christian will step in and correct me if I misrepresent him or his work here.) Many of the changes were motivated by Christian's work (already in the trunk) in making infinities and nans more accessible and portable for Python users. (See issue #1640.) * Structural reorganization: there are new files Include/pymath.h and Objects/pymath.c with math-related definitions and replacement functions for platforms without copysign, log1p, hypot and inverse hyperbolic functions. * New math functions: inverse hyperbolic functions (acosh, asinh, atanh). * New float methods: is_finite, is_inf, is_integer and is_nan. * New cmath functions: phase, polar and rect, isinf and isnan. * New complex method: is_finite. * Work on math and cmath functions to make them handle special values (infinities and nans) and floating-point exceptions according to the C99 standard. The general philosophy follows the ideas put forth by Tim Peters and co. many moons ago. and repeated in the issue #1640 thread more recently: where the C99 standard (or IEEE 754) specifies raising 'invalid' or 'divide-by-zero' Python should raise a ValueError. Where the C99 standard specifies raising 'overflow' Python should raise OverflowError. 'underflow' and 'inexact' flags are ignored. From a user's perspective, this means that infinities and nans are never produced by math or cmath operations on finite values (but see below). sqrt(-1) will always raise ValueError, instead of returning a NaN. See issue #711019 and the resulting warning at the bottom of the math module documentation. Although complex_abs doesn't live in cmathmodule.c, it was also fixed up this way. * The cmath module has been rescued: it's no longer numerically unsound (see issue #1381). For the majority of functions (sin, cos, tan, sinh, cosh, tanh, asin, acos, atan, asinh, acosh, atanh, exp, sqrt) the real and imaginary parts of the results are always within a few ulps of the true values. (In extensive but non-exhaustive testing I haven't found errors of more than 5 ulps in either the real or imaginary parts for these functions.) For log and log10 the errors can be larger when the argument has absolute value close to 1; this seems pretty much unavoidable without using multiple-precision arithmetic. pow and two-argument log are less accurate; again, this is essentially unavoidable without adding hundreds of extra lines of code. * Many more tests. In addition to a handful of extra test_* methods in test_math and test_cmath, there are over 1700 testcases (in a badly-named file Lib/test/cmath.ctest) for the cmath and math functions, with a testcase format inspired in no small part by the decimal .decTest file format. Most of the testcase values were produced independently of Python using MPFR and interval arithmetic (C code available on request); some were created by hand. * There's a per-thread state for division operator. In IEEE 754 mode 1./0. and 1.%0. return INF and 0./0. NAN. The contextlib has a new context "ieee754" and the math lib set_ieee754/get_ieee754 (XXX better place for the functions?) Some notes: * We've used the C99 standard (especially Annex F and Annex G) as a reference for deciding what the math and cmath functions should do, wherever possible. It seems to make sense to choose to follow some standard, essentially so that all the hard decisions have been thought through thoroughly by a group of experts. Two obvious choices are the C99 standard and IEEE 754(r); for almost all math issues the two say essentially the same thing. C99 has the advantage that it includes specifications for complex math, while IEEE 754(r) does not. (Actually, I've been using draft version N1124 of the C99 standard, not the standard itself, since I'm too cheap to pay up for a genuine version. Google 'N1124' for a copy.) * I'm offering to act as long-term maintainer for the cmath module, if that's useful. * The most interesting and exciting feature, by far (in my opinion) is the last one. By way of introduction, here's a snippet from Tim Peters, in a comp.lang.python posting ( http://mail.python.org/pipermail/python-list/2005-July/330745.html), answering a question from Michael Hudson about 1e300*1e300 and inf/inf. "I believe Python should raise exceptions in these cases by default, because, as above, they correspond to the overflow and invalid-operation signals respectively, and Python should raise exceptions on the overflow, invalid
Re: [Python-Dev] dir() and __all__
I'm not sure which use case you're after here, but I doubt it's what dir() was designed to do. dir() is meant to attempt to give you all attributes for which getattr() will succeed, barring dynamic overrides of __getattr[ibute]__. On Fri, Feb 15, 2008 at 7:18 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Raymond] > > >> Should dir(module) use __all__ when defined? > > [GvR] > > > It's not consistent with what dir() of a class or instance does though. > > > > -1. > > Perhaps there is another solution. Have dir() exclude objects > which are modules. For example, dir(logging) would exclude > sys, os, types, time, string, cStringIO, and traceback. > > > Raymond > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunk-math
Mark Dickinson wrote: > Dear all, > > I'd like to draw your attention to some of the work that's been going on > in the trunk-math branch. Christian Heimes and I have been working on > various aspects of Python mathematics, and we're hoping to get at least > some of this work into Python 2.6/3.0. Most of the changes are > completed or nearly complete, and 2.6/3.0 isn't very far away, so it > seems like a good time to try to get some feedback from python-dev. > > Here's an overview of the changes (overview originally written by > Christian, edited and augmented by me. I hope Christian will step in > and correct me if I misrepresent him or his work here.) Many of the > changes were motivated by Christian's work (already in the trunk) in > making infinities and nans more accessible and portable for Python > users. (See issue #1640.) > > * Structural reorganization: there are new files Include/pymath.h and > Objects/pymath.c with math-related definitions and replacement functions > for platforms without copysign, log1p, hypot and inverse hyperbolic > functions. > > * New math functions: inverse hyperbolic functions (acosh, asinh, atanh). > > * New float methods: is_finite, is_inf, is_integer and is_nan. > > * New cmath functions: phase, polar and rect, isinf and isnan. > > * New complex method: is_finite. > > * Work on math and cmath functions to make them handle special values > (infinities and nans) and floating-point exceptions according to the C99 > standard. The general philosophy follows the ideas put forth by Tim > Peters and co. many moons ago. and repeated in the issue #1640 thread > more recently: where the C99 standard (or IEEE 754) specifies raising > 'invalid' or 'divide-by-zero' Python should raise a ValueError. Where > the C99 standard specifies raising 'overflow' Python should raise > OverflowError. 'underflow' and 'inexact' flags are ignored. From a > user's perspective, this means that infinities and nans are never > produced by math or cmath operations on finite values (but see below). > sqrt(-1) will always raise ValueError, instead of returning a NaN. See > issue #711019 and the resulting warning at the bottom of the math module > documentation. Although complex_abs doesn't live in cmathmodule.c, it > was also fixed up this way. > > * The cmath module has been rescued: it's no longer numerically unsound > (see issue #1381). For the majority of functions (sin, cos, tan, sinh, > cosh, tanh, asin, acos, atan, asinh, acosh, atanh, exp, sqrt) the real > and imaginary parts of the results are always within a few ulps of the > true values. (In extensive but non-exhaustive testing I haven't found > errors of more than 5 ulps in either the real or imaginary parts for > these functions.) For log and log10 the errors can be larger when the > argument has absolute value close to 1; this seems pretty much > unavoidable without using multiple-precision arithmetic. pow and > two-argument log are less accurate; again, this is essentially > unavoidable without adding hundreds of extra lines of code. > > * Many more tests. In addition to a handful of extra test_* methods in > test_math and test_cmath, there are over 1700 testcases (in a > badly-named file Lib/test/cmath.ctest) for the cmath and math functions, > with a testcase format inspired in no small part by the decimal .decTest > file format. Most of the testcase values were produced independently of > Python using MPFR and interval arithmetic (C code available on request); > some were created by hand. > > * There's a per-thread state for division operator. In IEEE 754 mode > 1./0. and 1.%0. return INF and 0./0. NAN. The contextlib has a new > context "ieee754" and the math lib set_ieee754/get_ieee754 (XXX better > place for the functions?) > > Some notes: > > * We've used the C99 standard (especially Annex F and Annex G) as a > reference for deciding what the math and cmath functions should do, > wherever possible. It seems to make sense to choose to follow some > standard, essentially so that all the hard decisions have been thought > through thoroughly by a group of experts. Two obvious choices are the > C99 standard and IEEE 754(r); for almost all math issues the two say > essentially the same thing. C99 has the advantage that it includes > specifications for complex math, while IEEE 754(r) does not. (Actually, > I've been using draft version N1124 of the C99 standard, not the > standard itself, since I'm too cheap to pay up for a genuine version. > Google 'N1124' for a copy.) > > * I'm offering to act as long-term maintainer for the cmath module, if > that's useful. > > * The most interesting and exciting feature, by far (in my opinion) is > the last one. By way of introduction, here's a snippet from Tim Peters, > in a comp.lang.python posting > (http://mail.python.org/pipermail/python-list/2005-July/330745.html), > answering a question from Michae
Re: [Python-Dev] dir() and __all__
On Fri, Feb 15, 2008, Raymond Hettinger wrote: > > [Raymond] > >> Should dir(module) use __all__ when defined? > > [GvR] > > It's not consistent with what dir() of a class or instance does though. > > > > -1. > > Perhaps there is another solution. Have dir() exclude objects which > are modules. For example, dir(logging) would exclude sys, os, types, > time, string, cStringIO, and traceback. -1 I see what you're getting at, but I think this level of introspection breakage is a Bad Idea. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "All problems in computer science can be solved by another level of indirection." --Butler Lampson ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunk-math
Apologies for the bad formatting. Here's a repost with shorter lines. Dear all, I'd like to draw your attention to some of the work that's been going on in the trunk-math branch. Christian Heimes and I have been working on various aspects of Python mathematics, and we're hoping to get at least some of this work into Python 2.6/3.0. Most of the changes are completed or nearly complete, and 2.6/3.0 isn't very far away, so it seems like a good time to try to get some feedback from python-dev. Here's an overview of the changes (overview originally written by Christian, edited and augmented by me. I hope Christian will step in and correct me if I misrepresent him or his work here.) Many of the changes were motivated by Christian's work (already in the trunk) in making infinities and nans more accessible and portable for Python users. (See issue #1640.) * Structural reorganization: there are new files Include/pymath.h and Objects/pymath.c with math-related definitions and replacement functions for platforms without copysign, log1p, hypot and inverse hyperbolic functions. * New math functions: inverse hyperbolic functions (acosh, asinh, atanh). * New float methods: is_finite, is_inf, is_integer and is_nan. * New cmath functions: phase, polar and rect, isinf and isnan. * New complex method: is_finite. * Work on math and cmath functions to make them handle special values (infinities and nans) and floating-point exceptions according to the C99 standard. The general philosophy follows the ideas put forth by Tim Peters and co. many moons ago. and repeated in the issue #1640 thread more recently: where the C99 standard (or IEEE 754) specifies raising 'invalid' or 'divide-by-zero' Python should raise a ValueError. Where the C99 standard specifies raising 'overflow' Python should raise OverflowError. 'underflow' and 'inexact' flags are ignored. From a user's perspective, this means that infinities and nans are never produced by math or cmath operations on finite values (but see below). sqrt(-1) will always raise ValueError, instead of returning a NaN. See issue #711019 and the resulting warning at the bottom of the math module documentation. Although complex_abs doesn't live in cmathmodule.c, it was also fixed up this way. * The cmath module has been rescued: it's no longer numerically unsound (see issue #1381). For the majority of functions (sin, cos, tan, sinh, cosh, tanh, asin, acos, atan, asinh, acosh, atanh, exp, sqrt) the real and imaginary parts of the results are always within a few ulps of the true values. (In extensive but non-exhaustive testing I haven't found errors of more than 5 ulps in either the real or imaginary parts for these functions.) For log and log10 the errors can be larger when the argument has absolute value close to 1; this seems pretty much unavoidable without using multiple-precision arithmetic. pow and two-argument log are less accurate; again, this is essentially unavoidable without adding hundreds of extra lines of code. * Many more tests. In addition to a handful of extra test_* methods in test_math and test_cmath, there are over 1700 testcases (in a badly-named file Lib/test/cmath.ctest) for the cmath and math functions, with a testcase format inspired in no small part by the decimal .decTest file format. Most of the testcase values were produced independently of Python using MPFR and interval arithmetic (C code available on request); some were created by hand. * There's a per-thread state for division operator. In IEEE 754 mode 1./0. and 1.%0. return INF and 0./0. NAN. The contextlib has a new context "ieee754" and the math lib set_ieee754/get_ieee754 (XXX better place for the functions?) Some notes: * We've used the C99 standard (especially Annex F and Annex G) as a reference for deciding what the math and cmath functions should do, wherever possible. It seems to make sense to choose to follow some standard, essentially so that all the hard decisions have been thought through thoroughly by a group of experts. Two obvious choices are the C99 standard and IEEE 754(r); for almost all math issues the two say essentially the same thing. C99 has the advantage that it includes specifications for complex math, while IEEE 754(r) does not. (Actually, I've been using draft version N1124 of the C99 standard, not the standard itself, since I'm too cheap to pay up for a genuine version. Google 'N1124' for a copy.) * I'm offering to act as long-term maintainer for the cmath module, if that's useful. * The most interesting and exciting feature, by far (in my opinion) is the last one. By way of introduction, here's a snippet from Tim Peters, in a comp.lang.python posting (http://mail.python.org/pipermail/python-list/2005-July/330745.html), answering a question from Michael Hudson about 1e300*1e300 and inf/inf. "I believe Python should raise exceptions in these cases by default, because, as above, they correspond to the overflow and invalid-operation signals res
Re: [Python-Dev] dir() and __all__
On Sat, Feb 16, 2008 at 4:18 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Raymond] > >> Should dir(module) use __all__ when defined? > > [GvR] > > It's not consistent with what dir() of a class or instance does though. > > > > -1. > > Perhaps there is another solution. Have dir() exclude objects > which are modules. For example, dir(logging) would exclude > sys, os, types, time, string, cStringIO, and traceback. Don't forget that that would mean dir(os) would no longer show 'path'. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
