[changing the subject; was: 'where' statement in Python?] I think this is an interesting idea (whether worth adding is a different question). I think it would be confusing that a[x] = (y,z) does something entirely different when x is 1 or (1,2). If python *were* to add something like this, I think perhaps a different syntax should be considered: a[[x]] = y y = a[[x]] which call __setitems__ and __getitems__ respectively. This makes it clear that something different is going on and eliminates the ambiguity for dicts. --- Bruce http://www.vroospeak.com http://google-gruyere.appspot.com On Tue, Jul 20, 2010 at 10:18 AM, Sturla Molden <sturla@molden.no> wrote:
Den 21.07.2010 01:38, skrev Carl M. Johnson:
Does this need new syntax? Couldn’t it just be a method? Perhaps .where()? ;-)
It is just a library issue. And adding it would not break anything, because lists and tuples don't accept iterables as indexers now. The problem is the dict and the set, which can take tuples as index. A .where() method would work, if it e.g. took a predicate as argument. But we would still need no pass the return value (e.g. a tuple) to the [] operator. That is all legal syntax today (which is why NumPy can do this), but lists are implemented to only accept integers to __setitem__ and __getitem__. Sturla
x = a[[y]] would be approximately equivalent to x = [a[i] for i in y] and a[[x]] = y would be approximately equivalent to for (i,j) in zip(x,y): a[i] = j except that zip throws away excess values in the longer sequence and I think [[..]] would throw an exception. --- Bruce http://www.vroospeak.com http://google-gruyere.appspot.com On Tue, Jul 20, 2010 at 3:51 PM, Mathias Panzenböck < grosser.meister.morti@gmx.net> wrote:
On Tue, Jul 20, 2010 at 4:43 PM, Bruce Leban <bruce@leapyear.org> wrote:
You realize that syntax /already/ has a valid meaning in Python, right? Namely, using a single-element list as a subscript:
Making this syntax do something else would lead to some surprising inconsistencies to say the least; albeit I don't know how common it is to use lists as subscripts. Cheers, Chris -- http://blog.rebertia.com
Den 21.07.2010 00:51, skrev Mathias Panzenböck:
No, that is slicing. A fancy index is a more flexible slice, as it has no regular structure. It's just a list, tuple or array of indexes, in arbitrary order, possibly repeated. It would e.g. work like this:
If know SQL, it means that you can do with indexing what SQL can do with WHERE and JOIN. You can e.g. search a list in O(N) for indexes where a certain condition evaluates to True (cf. SQL WHERE), and then apply these indexes to any list (cf. SQL JOIN). It is not just for queries, but also for things like sorting. It is what lets NumPy have an "argsort" function. It does not return a sorted array, but an array of indices, which when applied to the array, will return a sorted instance. These indices can in turn be applied to other arrays as well. Think about what happens when you sort each row in an Excel spreadsheet by the values in a certain column. One column is sorted, the other columns are reordered synchroneously. That is the kind of thing that fancy indexing allows us to do rather easily. Yes there are other ways of doing this in Python now, but not as elegent I think. And it is not a syntax change to Python (NumPy can do it), it is just a library issue. This is at least present in NumPy, MATLAB, C# and LINQ, SQL, Fortran 95 (in two ways), Scilab, Octave, and C++ (e.g. Blitz++). The word "fancy indexing" is the name used for it in NumPy. Sturla
Den 21.07.2010 01:38, skrev Carl M. Johnson:
Does this need new syntax? Couldn’t it just be a method? Perhaps .where()? ;-)
It is just a library issue. And adding it would not break anything, because lists and tuples don't accept iterables as indexers now. The problem is the dict and the set, which can take tuples as index. A .where() method would work, if it e.g. took a predicate as argument. But we would still need no pass the return value (e.g. a tuple) to the [] operator. That is all legal syntax today (which is why NumPy can do this), but lists are implemented to only accept integers to __setitem__ and __getitem__. Sturla
x = a[[y]] would be approximately equivalent to x = [a[i] for i in y] and a[[x]] = y would be approximately equivalent to for (i,j) in zip(x,y): a[i] = j except that zip throws away excess values in the longer sequence and I think [[..]] would throw an exception. --- Bruce http://www.vroospeak.com http://google-gruyere.appspot.com On Tue, Jul 20, 2010 at 3:51 PM, Mathias Panzenböck < grosser.meister.morti@gmx.net> wrote:
On Tue, Jul 20, 2010 at 4:43 PM, Bruce Leban <bruce@leapyear.org> wrote:
You realize that syntax /already/ has a valid meaning in Python, right? Namely, using a single-element list as a subscript:
Making this syntax do something else would lead to some surprising inconsistencies to say the least; albeit I don't know how common it is to use lists as subscripts. Cheers, Chris -- http://blog.rebertia.com
Den 21.07.2010 00:51, skrev Mathias Panzenböck:
No, that is slicing. A fancy index is a more flexible slice, as it has no regular structure. It's just a list, tuple or array of indexes, in arbitrary order, possibly repeated. It would e.g. work like this:
If know SQL, it means that you can do with indexing what SQL can do with WHERE and JOIN. You can e.g. search a list in O(N) for indexes where a certain condition evaluates to True (cf. SQL WHERE), and then apply these indexes to any list (cf. SQL JOIN). It is not just for queries, but also for things like sorting. It is what lets NumPy have an "argsort" function. It does not return a sorted array, but an array of indices, which when applied to the array, will return a sorted instance. These indices can in turn be applied to other arrays as well. Think about what happens when you sort each row in an Excel spreadsheet by the values in a certain column. One column is sorted, the other columns are reordered synchroneously. That is the kind of thing that fancy indexing allows us to do rather easily. Yes there are other ways of doing this in Python now, but not as elegent I think. And it is not a syntax change to Python (NumPy can do it), it is just a library issue. This is at least present in NumPy, MATLAB, C# and LINQ, SQL, Fortran 95 (in two ways), Scilab, Octave, and C++ (e.g. Blitz++). The word "fancy indexing" is the name used for it in NumPy. Sturla
participants (5)
-
Bruce Leban -
Carl M. Johnson -
Chris Rebert -
Mathias Panzenböck -
Sturla Molden