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 ob
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.
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
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
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 PROTECTE
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
[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
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,
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', 'PriorityQ
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__',
> '_
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']
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
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
> PyOb
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 y
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 do
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
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
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
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 d
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 durati
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
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
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 bec
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
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 whe
25 matches
Mail list logo
