On 12/9/2010 9:19 AM, Dan wrote:
I tested the 4 line change anyway...removing it from 3.2 had no
detrimental effect, adding it to 3.1 had no effect. It must be
something else.
Then there must have been a change in the bytes object, which is deeper
than I want to go. 3.2 has a LOT of little i
On Dec 8, 9:05 pm, Terry Reedy wrote:
> On 12/8/2010 7:11 PM, Ned Deily wrote:
>
>
>
>
>
>
>
>
>
> > In article, Terry
> > Reedy wrote:
> >> On 12/8/2010 2:42 PM, Dan wrote:
> >>> I have a simple type derived from bytes...
>
> >>> class atom(bytes): pass
>
> >>> ... that I cannot deepcopy(). The
On 12/8/2010 7:11 PM, Ned Deily wrote:
In article, Terry
Reedy wrote:
On 12/8/2010 2:42 PM, Dan wrote:
I have a simple type derived from bytes...
class atom(bytes): pass
... that I cannot deepcopy(). The session below demonstrates
how deepcopy() of "bytes" works fine, but deepcopy() of "ato
In article ,
Terry Reedy wrote:
> On 12/8/2010 2:42 PM, Dan wrote:
> > I have a simple type derived from bytes...
> >
> > class atom(bytes):
> > pass
> >
> > ... that I cannot deepcopy(). The session below demonstrates how
> > deepcopy() of "bytes" works fine, but deepcopy() of "atom" does n
On 12/8/2010 2:42 PM, Dan wrote:
I have a simple type derived from bytes...
class atom(bytes):
pass
... that I cannot deepcopy(). The session below demonstrates how
deepcopy() of "bytes" works fine, but deepcopy() of "atom" does not.
What's going wrong?
Thanks,
Dan.
Python 3.1.2 (r312:7
I have a simple type derived from bytes...
class atom(bytes):
pass
... that I cannot deepcopy(). The session below demonstrates how
deepcopy() of "bytes" works fine, but deepcopy() of "atom" does not.
What's going wrong?
Thanks,
Dan.
Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.
