This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author andybuckley
Recipients andybuckley, exarkun, ezio.melotti, georg.brandl, mark.dickinson
Date 2010-06-25.13:22:49
SpamBayes Score 0.17354147
Marked as misclassified No
Message-id <1277472171.28.0.978454929571.issue9080@psf.upfronthosting.co.za>
In-reply-to
Content
Still not convinced with the reasoning, I'm afraid, but I certainly agree that modifications to built-ins are not to be made lightly. Using deques, which are far less familiar, is not a particularly natural thing to do for a search path, and of course can't be used with a built-in list to which you might well wish to prepend: sys.path.

Personally, I would have no problem with a list pop_front method ;) I understand the connection of API availability and misuse of algorithmically inefficient methods -- for large lists -- but I don't find "be inconveniently absent so that users search for an answer and find out about complexity issues" a very compelling or Pythonic design aim. But I admit that l.insert(0, x) is not such a hard idiom to learn -- just a bit less syntactically elegant and self-explanatory than I would prefer for a simple task, especially where I've already conciously made the efficiency decision in my choice of container type.

But thanks for listening... as mentioned, this can stay here as a reference for further enquiries (I searched for a pre-existing prepend() request before submitting this ticket, of course!) and I'll go visit python-ideas. Cheers!
History
Date User Action Args
2010-06-25 13:22:51andybuckleysetrecipients: + andybuckley, georg.brandl, exarkun, mark.dickinson, ezio.melotti
2010-06-25 13:22:51andybuckleysetmessageid: <1277472171.28.0.978454929571.issue9080@psf.upfronthosting.co.za>
2010-06-25 13:22:50andybuckleylinkissue9080 messages
2010-06-25 13:22:49andybuckleycreate