> I am not sure what you are trying to propose here. The slice object
> isn't special, it's just a regular built-in type.
The idea is to have slice objects be generators. You could make a
slice like 1:10:2 , and that would make a slice object which could be
used as a list index. The list woul
Hi Phillip,
On Sun, Mar 09, 2008 at 07:05:12PM -0400, Phillip J. Eby wrote:
> I did not, however, need the equality of bound methods to be based on
> object value equality, just value identity.
>
> ...at least until recently, anyway. I do have one library that wants
> to have equality-based co
At 12:26 PM 3/10/2008 +0100, Armin Rigo wrote:
>Hi Phillip,
>
>On Sun, Mar 09, 2008 at 07:05:12PM -0400, Phillip J. Eby wrote:
> > I did not, however, need the equality of bound methods to be based on
> > object value equality, just value identity.
> >
> > ...at least until recently, anyway. I do
Forrest Voight wrote:
>> I am not sure what you are trying to propose here. The slice object
>> isn't special, it's just a regular built-in type.
>
> The idea is to have slice objects be generators. You could make a
> slice like 1:10:2 , and that would make a slice object which could be
> use
Phillip J. Eby wrote:
> At 12:26 PM 3/10/2008 +0100, Armin Rigo wrote:
>> In general, "x.append" is interchangeable with "x.append" even if
>> "x.append is not x.append", so let's go for the least surprizing
>> behavior: "m1.im_self is m2.im_self and m1.im_func==m2.im_func".
>> Objection?
>
> Nope
> Since both strerror() and memmove() are both in C89 (they are listed
> in K&R), can we ditch these files?
I think they can safely be deleted.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
On Mon, Mar 10, 2008 at 4:26 AM, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Phillip,
>
>
> On Sun, Mar 09, 2008 at 07:05:12PM -0400, Phillip J. Eby wrote:
> > I did not, however, need the equality of bound methods to be based on
> > object value equality, just value identity.
> >
> > ...at lea
Hello again,
Guido van Rossum wrote:
> Well, there you have hit the nail on the head -- should we document
> the actual or the guaranteed O() expression? I think this is a can of
> worms better left unopened. At best we should include some hints to
I will open this can and say that average case c
Fred Drake wrote:
> On Mar 9, 2008, at 10:22 AM, Aahz wrote:
>> This has been discussed before and rejected for two reasons:
>>
>> * Other Python implementations (Jython, PyPy, IronPython) may not be
>> able to provide the same type implementations
>>
>> * Algorithmic information does sometimes cha
> I will open this can and say that average case complexity is the most
> important. For example sorting O(nlogn) and dict lookup O(1).
I would still debate the complexity of dict lookup. What are you
averaging over? In absence of any distribution property of hash
functions in the average case,
On Sun, Mar 9, 2008 at 9:22 AM, Aahz <[EMAIL PROTECTED]> wrote:
> There probably would be some value in a wiki page on python.org that
> provides this information, particularly across versions. You may be
> able to find volunteers to help on comp.lang.python.
I just created a very basic one at
On Mon, Mar 10, 2008, Daniel Stutzbach wrote:
> On Sun, Mar 9, 2008 at 9:22 AM, Aahz <[EMAIL PROTECTED]> wrote:
>>
>> There probably would be some value in a wiki page on python.org that
>> provides this information, particularly across versions. You may be
>> able to find volunteers to help on
> I just created a very basic one at
> http://wiki.python.org/moin/TimeComplexity?action=show
I just knew that this could be a field of endless nitpicking.
I think the dict.copy classification is incorrect. A dict.copy
can take unbounded time, if the dict has seen many recent
deletions (which did
On Mon, Mar 10, 2008 at 5:06 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > I just created a very basic one at
> > http://wiki.python.org/moin/TimeComplexity?action=show
>
> I just knew that this could be a field of endless nitpicking.
Certainly. I am hoping that this thread will soon win
> I assume there is a reason that PyDict_DelItem never calls dictresize?
Yes - the assumption is that more del calls will follow, so that the
dictionary eventually ends up empty. Only when new inserts are made,
that assumption is proven wrong, and the shrinking can be done in
one sweep.
Regards,
On Mon, Mar 10, 2008 at 9:20 AM, Adam Olsen <[EMAIL PROTECTED]> wrote:
>
> On Mon, Mar 10, 2008 at 4:26 AM, Armin Rigo <[EMAIL PROTECTED]> wrote:
> > Hi Phillip,
> >
> >
> > On Sun, Mar 09, 2008 at 07:05:12PM -0400, Phillip J. Eby wrote:
> > > I did not, however, need the equality of bound m
Martin v. Löwis wrote:
> Yes - the assumption is that more del calls will follow, so that the
> dictionary eventually ends up empty. Only when new inserts are made,
> that assumption is proven wrong, and the shrinking can be done in
> one sweep.
Hmmm. So the most efficient way to copy a dict that
Martin v. Löwis wrote:
> I would still debate the complexity of dict lookup. What are you
> averaging over?
All the Python programs I've ever run. :-)
> I also disagree that the average complexity is "most important".
> I find the worst-case complexity most important.
While in theory the worst
Forrest Voight wrote:
> Slice objects that are produced in a list index area would be different,
> and optionally the syntax for slices in list indexes would be expanded
> to work everywhere.
Something like this was quite close to getting in a while
back, but it was eventually dropped. Anyone advo
Dimitrios Apostolou wrote:
> On the other hand notes could be added for various oddities according to
> experience. For example that for sets up to 10(?) elements, a list would
> probably be better because of the hashing overhead.
That's the sort of thing that tends to be *very*
implementation
On Mon, Mar 10, 2008 at 3:57 AM, Forrest Voight <[EMAIL PROTECTED]> wrote:
> > I am not sure what you are trying to propose here. The slice object
> > isn't special, it's just a regular built-in type.
>
> The idea is to have slice objects be generators. You could make a
> slice like 1:10:2 ,
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|| Yeah, there's no substitute for having at least a
| rough idea of how the object you're using is implemented,
| e.g. array vs. linked list.
As I understand it, the new 2.6 docs include a new one on CPython
specifically.
22 matches
Mail list logo
