ANNOUNCE: cCopy 0.1

[Tom]

Robin,

Thanks for cCopy.

Browsing the code brings to some comments about the implementation and
documentation of cCopy and copy.py.

Some object types are described as 'atomics', some as 'special', and the
rest aren't supported.  (It appears that the atomics don't actually get
copied, but just have their reference counts increased.)

The atomic types are:
NoneType,IntType,LongType,FloatType,StringType,CodeType,TypeType,XRangeType,
ClassType.
The special types are: ListType,TupleType,DictionaryType,InstanceType.

My Comments:

- XRange isn't atomic, it is a compound.  I presume that the reason that it
can be copied in this manner is because it is only composed of immutables?
- Class & Code aren't atomic either.  To me they appear to belong with the
other unsupported types in the un-named third category - those that don't
really have a regular value and are composed entirely of special attributes.
- Instances are not compound objects (as the other 'special' types are).  I
suppose that it can be copied (unlike a similar type like a class) because
multiple identical instances are allowed?

It doesn't seem to me that the 'atomic/compound/no-value' trichotomy (is
that a real word?) is really the issue for copying purposes, but I don't
have a better alternative.

I realize these weren't your decisions - I am just making these comments to
see if my understanding of this module is accurate.

Thanks,

Tom.

"Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
news:of$bgXAf9b15EwhO at jessikat.fsnet.co.uk...
> As an exercise I have tried to duplicate the functionality of Python's
> copy module in a C extension. My tests indicate that it works, but it
> obviously wants to be let out to be stamped on.
>
> You can find cCopy.zip at http://www.jessikat.fsnet.co.uk/
> --
> Robin Becker