> Actually, it wasn't the feebleness as much as the two different things you > seem to be wanting, Guido ;) Previously (in another thread, and perhaps in > the start of this thread as well) you argued that an index should always > call __getitem__, with a slice object if it's a slice of some kind, *even a > basic one*. So that we lose __getslice__ and rather teach people to use > __getslice__. That would be nice, but it would be b/w incompatible, so now we're trying (again) to figure out how to still support __getslice__. My proposal is to try and be b/w compatible if __getslice__ exists. See my previous mail. > So now you want to *extend* the 'special case' to extended, 3-argument > slices, but *not* Ellipses and tupled-slices (which aren't really tuples, > because you can do (1, 2:5, ...)) -- or am I reading this wrong ? :) Not sure what you mean by that. (1, 2:5, ...) by itself is illegal syntax; the special slice syntax can only occur directly in an indexing context, e.g. a[1, 2:5, ...]. > Don't worry, Guido, it isn't just you, I failed to grasp what those managers > were trying to tell me today, too... I may just be too dense, today. I hope they weren't telling you to stop working on Python! You seem made for this work... --Guido van Rossum (home page: http://www.pythonlabs.com/~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