> Tim Peters <tim.one@home.com>: > > > It's not BINARY_ADD, it's the PyNumber_Add() called by BINARY_ADD, which, > > given two strings, calls binary_op1, which does a few failing tests, then > > calls PyNumber_CoerceEx, which fails quickly enough to coerce, and then > > pokes around a little looking for number methods, and finally says "hmm! > > maybe it's a sequence?". > > This seems to contradict what Guido just said about > centralised coercion having been removed. Is one or > the other of us talking nonsense, or do we misunderstand > each other? It's complicated. I didn't know everything that was going on when I wrote that before. Now I've seen a bit more. PyNumber_CoerceEx() is called in order to accommodate old-style numbers for backwards compatibility (and for complex, which hasn't been converted to new-style yet). We could add a new-style numeric add operation to strings so that s1+s2 takes an earlier path in binary_op1(). I also note that binary_op1() tries PyNumber_CoerceEx() even when both arguments have a NULL tp_as_number pointer -- at the cost of extra tests the call to PyNumber_CoerceEx() could be avoided. (I guess binary_op1() could add such a test at the top and save itself some work.) --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