At 05:23 PM 2/11/2008 +1300, Greg Ewing wrote:
>Aahz wrote:
> > On Mon, Feb 11, 2008, Greg Ewing wrote:
> >
> >>There are bound to be things that you *don't* want to copy from
> >>the original order, e.g. the order ID, the date...
> >
> > Certainly -- that's why __copy__() exists, right?
>
>Yes, bu
itertools.count() maybe ? Well not really infinite, it stops with
OverflowError...
But then (don't try this at home)...
>>> 4 in itertools.cycle(range(3)) # ups!
I seems that implicitely supporting containment testing for any
iterable is not always good idea.
On 2/9/08, Neil Toronto <[EMAIL PRO
>> I don't think we'll ever get another chance to clean-up the mapping API and
>> to remove duplicate functionality (the code for
>> dict.__copy__ and dict.copy share the same implementation).
>
> I find the use of a copy operation that purports to copy any object
> suspect (regardless whether it
Guido van Rossum wrote:
> On Feb 11, 2008 7:31 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> [GvR]
>>> The problem is that if you have two instance x,
>>> y such that isinstance(x, TotalOrdering) and isinstance(y,
>>> TotalOrdering) you still don't know if x < y is defined. (For example,
>>>
On Feb 11, 2008 8:10 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Was the concensus on this to move UserList into the collections module and to
> remove UserString?
> Any objections?
I ain't going to object.
-Brett
___
Python-3000 mailing list
Py
On Feb 11, 2008 7:58 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Where did we end-up on dict.copy()?
>
> Is the copy(obj) function sufficiently universal to replace the obj.copy()
> method used in sets and in dict imitators? Or does the
> need for import preclude it from consideration?
>
>
On Feb 11, 2008 6:58 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> During the discussion of PEP 3141, what use cases were envisioned for the
> Integral type? Were there some examples of concrete implementations other
> than or I'm asking because I'm unclear about what a class is stating a
During the discussion of PEP 3141, what use cases were envisioned for the
Integral type? Were there some examples of concrete implementations other than
or #t and (integer? 8/4) ==> #t but in our current
implementation Rational(8,4) is not Integral like it is for Scheme.
Also, Scheme seems a
Was some thought given to providing a mixin for boolean inequalities in total
orderings (define __le__ and get the rest for free)?
One of the motivating examples in the ABC pep was that the presence of
__getitem__ was insufficient to distinguish between a sequence and a mapping.
By registering
I don't know about consensus, but personally I'm +1 on this.
On Feb 11, 2008 8:10 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Was the concensus on this to move UserList into the collections module and to
> remove UserString?
> Any objections?
>
>
> Raymond
>
>
>
> -
Was the concensus on this to move UserList into the collections module and to
remove UserString?
Any objections?
Raymond
---
>> [Brett]
>> > +1 on collections.
>>
>> [Steven Bethard]
>> > +1 for putting them in the collections module.
>>
>> How
Where did we end-up on dict.copy()?
Is the copy(obj) function sufficiently universal to replace the obj.copy()
method used in sets and in dict imitators? Or does the
need for import preclude it from consideration?
To me it seems that relationship between __copy__ and the copy() function is
ju
On Feb 11, 2008 4:43 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Was some thought given to providing a mixin for boolean inequalities in total
> orderings (define __le__ and get the rest for free)?
I think it was briefly mentioned but we didn't get beyond the stage of
"you can do this with
On Feb 11, 2008 7:31 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [GvR]
> > Hold on. We went down that road quite a bit and then discovered it
> > wasn't going to work.
>
> I figured that it was missing for a reason.
>
> > The problem is that if you have two instance x,
> > y such that isinst
[GvR]
> Hold on. We went down that road quite a bit and then discovered it
> wasn't going to work.
I figured that it was missing for a reason.
> The problem is that if you have two instance x,
> y such that isinstance(x, TotalOrdering) and isinstance(y,
> TotalOrdering) you still don't know if x
>> Was some thought given to providing a mixin for boolean
>> inequalities in total orderings (define __le__ and get
>> the rest for free)
[GvR]
> IOW it's messy.
Would it make sense to do something in numbers.py modeled
after Exact/InExact? Those don't have any behavior; they
just make a sta
Raymond Hettinger wrote:
> Was the concensus on this to move UserList into the collections module and to
> remove UserString?
> Any objections?
You have my +1 as well.
Christian
___
Python-3000 mailing list
[email protected]
http://mail.python.or
Hold on. We went down that road quite a bit and then discovered it
wasn't going to work. The problem is that if you have two instance x,
y such that isinstance(x, TotalOrdering) and isinstance(y,
TotalOrdering) you still don't know if x < y is defined. (For example,
if x is a string and y is a numb
[GvR]
> I think you can probably get something that is reasonable given the
> kind of assumptions that prevail in an ABC world by having a
> "Sortable" metaclass (itself a subclass of ABCMeta) with the implied
> semantics that objects x and y can be sorted if the nearest common
> ancestor of x.__cl
19 matches
Mail list logo
