Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(6)

Side by Side Diff: Doc/faq/design.rst

Issue 27671: FAQ: len() is still function for good reason.
Patch Set: Created 3 years, 3 months ago
Left:
Right:
Use n/p to move between diff chunks; N/P to move between comments. Please Sign in to add in-line comments.
Jump to:
View unified diff | Download patch
« no previous file with comments | « no previous file | no next file » | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
OLDNEW
1 ====================== 1 ======================
2 Design and History FAQ 2 Design and History FAQ
3 ====================== 3 ======================
4 4
5 Why does Python use indentation for grouping of statements? 5 Why does Python use indentation for grouping of statements?
6 ----------------------------------------------------------- 6 -----------------------------------------------------------
7 7
8 Guido van Rossum believes that using indentation for grouping is extremely 8 Guido van Rossum believes that using indentation for grouping is extremely
9 elegant and contributes a lot to the clarity of the average Python program. 9 elegant and contributes a lot to the clarity of the average Python program.
10 Most people learn to love this feature after a while. 10 Most people learn to love this feature after a while.
(...skipping 192 matching lines...) Expand 10 before | Expand all | Expand 10 after
203 <file object>` support the iterator protocol, so you can write simply:: 203 <file object>` support the iterator protocol, so you can write simply::
204 204
205 for line in f: 205 for line in f:
206 ... # do something with line... 206 ... # do something with line...
207 207
208 208
209 209
210 Why does Python use methods for some functionality (e.g. list.index()) but funct ions for other (e.g. len(list))? 210 Why does Python use methods for some functionality (e.g. list.index()) but funct ions for other (e.g. len(list))?
211 -------------------------------------------------------------------------------- -------------------------------- 211 -------------------------------------------------------------------------------- --------------------------------
212 212
213 The major reason is history. Functions were used for those operations that were 213 Guido says:
214 generic for a group of types and which were intended to work even for objects
215 that didn't have methods at all (e.g. tuples). It is also convenient to have a
216 function that can readily be applied to an amorphous collection of objects when
217 you use the functional features of Python (``map()``, ``zip()`` et al).
218 214
219 In fact, implementing ``len()``, ``max()``, ``min()`` as a built-in function is 215 There are two bits of "Python rationale" that I'd like to explain first.
220 actually less code than implementing them as methods for each type. One can 216
221 quibble about individual cases but it's a part of Python, and it's too late to 217 First of all, I chose len(x) over x.len() for HCI reasons (def
222 make such fundamental changes now. The functions have to remain to avoid massive 218 __len__() came much later). There are two intertwined reasons
223 code breakage. 219 actually, both HCI:
220
221 (a) For some operations, prefix notation just reads better than
222 postfix -- prefix (and infix!) operations have a long tradition in
223 mathematics which likes notations where the visuals help the
224 mathematician thinking about a problem. Compare the easy with which we
225 rewrite a formula like x*(a+b) into x*a + x*b to the clumsiness of
226 doing the same thing using a raw OO notation.
227
228 (b) When I read code that says len(x) I *know* that it is asking for
229 the length of something. This tells me two things: the result is an
230 integer, and the argument is some kind of container. To the contrary,
231 when I read x.len(), I have to already know that x is some kind of
232 container implementing an interface or inheriting from a class that
233 has a standard len(). Witness the confusion we occasionally have when
234 a class that is not implementing a mapping has a get() or keys()
235 method, or something that isn't a file has a write() method.
236
237 Saying the same thing in another way, I see 'len' as a built-in
238 *operation*. I'd hate to lose that. I can't say for sure whether you
239 meant that or not, but 'def len(self): ...' certainly sounds like you
240 want to demote it to an ordinary method. I'm strongly -1 on that.
241
242 The second bit of Python rationale I promised to explain is the reason
243 why I chose special methods to look __special__ and not merely
244 special. I was anticipating lots of operations that classes might want
245 to override, some standard (e.g. __add__ or __getitem__), some not so
246 standard (e.g. pickle's __reduce__ for a long time had no support in C
247 code at all). I didn't want these special operations to use ordinary
248 method names, because then pre-existing classes, or classes written by
249 users without an encyclopedic memory for all the special methods,
250 would be liable to accidentally define operations they didn't mean to
251 implement, with possibly disastrous consequences. Ivan Krstić
252 explained this more concise in his message, which arrived after I'd
253 written all this up.
224 254
225 .. XXX talk about protocols? 255 https://mail.python.org/pipermail/python-3000/2006-November/004643.html
226
227 .. note::
228
229 For string operations, Python has moved from external functions (the
230 ``string`` module) to methods. However, ``len()`` is still a function.
231 256
232 257
233 Why is join() a string method instead of a list or tuple method? 258 Why is join() a string method instead of a list or tuple method?
234 ---------------------------------------------------------------- 259 ----------------------------------------------------------------
235 260
236 Strings became much more like other standard types starting in Python 1.6, when 261 Strings became much more like other standard types starting in Python 1.6, when
237 methods were added which give the same functionality that has always been 262 methods were added which give the same functionality that has always been
238 available using the functions of the string module. Most of these new methods 263 available using the functions of the string module. Most of these new methods
239 have been widely accepted, but the one which appears to make some programmers 264 have been widely accepted, but the one which appears to make some programmers
240 feel uncomfortable is:: 265 feel uncomfortable is::
(...skipping 556 matching lines...) Expand 10 before | Expand all | Expand 10 after
797 "fee", 822 "fee",
798 "fie" 823 "fie"
799 "foo", 824 "foo",
800 "fum" 825 "fum"
801 ] 826 ]
802 827
803 This list looks like it has four elements, but it actually contains three: 828 This list looks like it has four elements, but it actually contains three:
804 "fee", "fiefoo" and "fum". Always adding the comma avoids this source of error. 829 "fee", "fiefoo" and "fum". Always adding the comma avoids this source of error.
805 830
806 Allowing the trailing comma may also make programmatic code generation easier. 831 Allowing the trailing comma may also make programmatic code generation easier.
OLDNEW
« no previous file with comments | « no previous file | no next file » | no next file with comments »

RSS Feeds Recent Issues | This issue
This is Rietveld 894c83f36cb7+