[Todd Miller] > >>There has been some recent interest in the Numeric/numarray community > >>for using array objects as indices > >>for builtin sequences. I know this has come up before, but to make > >>myself clear, the basic idea is to make the > >>following work: > >> > >>class C: > >> def __int__(self): > >> return 5 > >> > >>object = C() > >> > >>l = "Another feature..." > >> > >>print l[object] > >>"h" > >> > >>Are there any plans (or interest) for developing Python in this direction? [Guido] > >I'm concerned that this will also make floats acceptable as indices > >(since they have an __int__ method) and this would cause atrocities > >like > > > >print "hello"[3.5] > > > >to work. [Todd] > That makes sense. What if we specifically excluded Float objects from > the conversion? Are there any types that need to be excluded? If > there's a chance of getting a patch for this accepted, STSCI is willing > to do the work. Hm, an exception for a specific type seems ugly. What if a user defines a UserFloat type, or a Rational type, or a FixedPoint type, with an __int__ conversion? This points to an unfortunate early design flaw in Python (inherited from C casts): __int__ has two different meanings -- sometimes it converts the type, sometimes it also truncates the value. I suppose you could hack something where you extract x.__int__() and x.__float__() and compare the two, but that could lead to a lot of overhead. I hesitate to propose a new special method, but that may be the only solution. :-( What's your use case? Why do you need this? --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