> > I'm still unclear why this so important to have in the library when > > you can write it yourself in two lines. > > Probably "there should only be one way to do something." It's > something that is recreated over and over, mostly the same way but > sometimes with slight differences (e.g., copy-and-sort versus > sort-in-place). Like dict() growing keyword arguments, a copy/sort > method (function, classmethod, whatever) will standardize something > that is very commonly reimplemented. Another analogs might be True and > False (which before being built into Python may have been spelled > true/false, TRUE/FALSE, or just 0/1). These don't add any real > features, but they standardize these simplest of idioms. > > I think I've seen people in this thread say that they've written Big > Python Programs, and they didn't have any problem with this -- but this > is a feature that's most important for Small Python Programs. Defining > a sort() function becomes boilerplate when you write small programs. > Or alternatively you create some util module that contains these little > functions, which becomes like a site.py only somewhat more explicit. A > util module feels like boilerplate as well, because it is a module > without any conceptual integrity, shared between projects only for > convenience, or not shared as it grows organically. "from util import > sort" just feels like cruft-hiding, not real modularity. That's one of the best ways I've seen this formulated. If Alex's proposal to have list.sorted() as a factory function is acceptable to the non-English-speaking crowd, I think we can settle on that. (Hm, an alternative would be to add a "sort=True" keyword argument to list()...) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4