Well, I posted working code, so I thought it should have been obvious that I knew how to handle my use case, and was (am) looking for a language-design level answer as opposed to a working-code level answer. Besides, the article above (although useful *and* freshly modified) doesn't explain how to handle the use case I posted with append(), or the ones I didn't post with extend(), insert(), remove(), dict.update(), and a bunch of others I can't think of off the top of my head.
I guess I have three responses to this. The first is that generations of Lisp programmers seem to have handled mutating *and* returning just fine for about the last 50 years; maybe it really isn't all that hard. ("Always know where your CONS cells are coming from." is pretty ingrained in my programming DNA; the Python analog isn't hard.) My second response is that if "... some other code ..." is so long and involved that you've forgotten that you already reversed lst, then your function probably needs to be refactored and/or rewritten. My third response is that it's *always* possible to shoot yourself in the foot. Protecting a naive user from one particular metatarsal projectile insertion at the expense of letting the power-user write more concise code seems a bad tradeoff to me -- but, I'm not involved with Python design, which brings me back to my original question above. Anyone? -- Brendon Towle, PhD Cognitive Scientist +1-412-690-2442x127 Carnegie Learning, Inc. The Cognitive Tutor Company ® Helping over 375,000 students in 1000 school districts succeed in math. |
-- http://mail.python.org/mailman/listinfo/python-list
