Copy operator (was list.remove for Noivces)

[Arthur Siegel]

>> My argument, I guess, is  that copy is somehow different
>>from the other modules, in that it is as if  you  are importing
>>a built_in. Is that totally off-base?

Andreas responds -

>Well, then everything in sys, string (well this is being phased out), etc.
>should be builtin.

How far over  my head am I getting by arguing with you here.  I see *no*
similarity between the kind of functionality sys brings in to that of
copy.  Copy just operates - and only on objects  that are.  Sys provides
functionality and information, that among other things, is platform
and version specific. I feel better when someone clearly needs to
stretch to this extent to defeat a point I am trying to make.
I take it as a no, I am not totally off-base.

>And no, perhaps because I've learned Python quite late (numerically at
least
>in my list of programming languages), but I do not know what all the stuff
is
>in __builtin__ without looking at the documentation.

And perhaps also in the process you have gotten far out of touch with the
process of learning one's *first* language.

>Think again: You are talking about the copy module that in the current code
>base is rather seldom used. Why should a function that is that seldom used
be
>moved to __builtin__?

>
> What is the downside of copy and deepcopy as built_ins.  Unnecessary
> performance hits in the majority of mods which don't need it, I expect.

>>Nope. Namespace pollution. Actually, there is already more than enough
baggage
>>in __builtin__ that nowadays wouldn't be needed there.
>>And the need to be backwards compatible for the next decades.

Namespace pollution?  I assume you mean you might want to use "copy",
and its been taken. Not sure that in itself is a big thing.  I do assume
that back compatible issues - there could be a lot of custom defined
copy def and classes out there - could be a *big* issue.

>>,And if Python had no pretense towards being a language suitable
>> for learning, I would be totally out of place in saying much of
>> anything here.  But I have in fact put considerable effort into learning
>> programming - to the extent that I have (and I am coming along
>> fine, thank you) -  with Python as my first language. Which I think
>> makes me my own kind of 'expert' - on nothing more than learning to
>> program - to the extent that I have  -  with Python as a first language
>> (and I am coming along fine, thank you)

>Obviously there is some contradiction here. Either you are not coming along
>fine, because you don't understand the copy/deepcopy "wart" of Python, or
>it's not that significant a thing if you can be productive without
>understanding it all :)

The only wart I see is in "packaging".  I couldn't understand the importance
of gaining an understanding of these concepts *on my own*, until pretty far
down the road.  Knew I was missing something important, but had no
way to put my finger on what it was.  If it was fundamental, it would
somehow be built_in, was the implicit assumption I was making. Turns out
that assumption was wrong - is my current understanding.
In most other respects, the dialogue with Python and its fundamental
documentation has been *quite* satisfactory. So I am holding
Python to its own high standards, in leading a learner - while encouraging
him/her to explore on their own.

Art