Re: [Edu-sig] Fw: Python sequences by reference - how to make
Guido writes -
What Kirby describes can be had by doing
from copy import copy, deepcopy
Which is obviously why I can't come up with a code example for my position. If wel are willing to make that the answer there is clearly nothing to discuss.
copy() nor deepcopy() is a built-in, because it is a potentially expensive operation, and I feel that its presence as a built-in would cause beginning and intermediate programmers to overuse it.
My only counter argument is that this decision was made when Python had much, much fewer very,very specialized libraries. The expectation/perception of what it means to import a library module has evolved to the point to where it is counter-intututive to expect to need to import functionality like that added by copy - IMO. But my argument is circular in some sense - because I am contending that copy represents core functionality, or more accurately, a core conceptual idea. I am emphasizing *that* - the conceptual clues that one is given by seeing copy as a built-in, and you are emphasizing other concerns. I understand that you are often in the trade-off business - and I guess there is no harm in having some disagreement as to where the trade-offs might fall at this particular stage of the game. Art
At 11:42 AM 9/20/2002 -0400, Art wrote:
My only counter argument is that this decision was made when Python had much, much fewer very,very specialized libraries. The expectation/perception of what it means to import a library module has evolved to the point to where it is counter-intututive to expect to need to import functionality like that added by copy - IMO.
I dunno about this argument. Even 'math' (sin, cos etc.) is an import.
But my argument is circular in some sense - because I am contending that copy represents core functionality, or more accurately, a core conceptual idea.
I think if the decision is to go with 'from copy import copy, deepcopy' then the workaround is to address copying for centrally in the tutorials. Copying might be a good segue into a subject heading like "...indeed, a lot of Python's functionality is tucked away in libraries, for example...". Python inherits from C in this respect, wherein even such basic stuff as file i/o is in libraries. Python is being 'liberal' vis-a-vis C in allowing 'open' as a built-in. Kirby
I think if the decision is to go with 'from copy import copy, deepcopy'
^^^^^^^ stay with
then the workaround is to address copying for centrally in the tutorials. ^^^^^^^^^^^^^ more centrally
Since understanding the variablename -> object relationship is so central to Python, one could argue that hiding 'copy' in a library is a way to *ensure* newbies will keep stubbing their toe on this missing capability, until the relationship is "gotten". Because the distinction between copy and deepcopy requires a fairly clear appreciation of this same relationship, just including them in the builtins without a lot of explanation would be unlikely to address core confusions. I understand your side of it though: having them be there would encourage earlier, deeper investigation of the whole topic, and remind the user that a=b does *not* necessarily get that job done. Guido's school of thought says 'these are power tools that need to be on a higher shelf, so the casual tinkerer won't abuse them -- if you're not ready to tackle importing, you're not ready to start copying, let alone deepcopying.' Kirby
participants (2)
-
Arthur -
Kirby Urner