Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #17372
| From | Stefan Behnel <stefan_ml@behnel.de> |
|---|---|
| Subject | Re: Making the case for "typed" lists/iterators in python |
| Date | 2011-12-16 19:23 +0100 |
| References | <CAOFbRmL_w4QJaCdP8bo1YOi-u0i=SPtAcV51PsQOTytKhsJFVw@mail.gmail.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.3744.1324059823.27778.python-list@python.org> (permalink) |
Nathan Rice, 16.12.2011 18:48: > I realize this has been discussed in the past, I hope that I am > presenting a slightly different take on the subject that will prove > interesting. This is primarily motivated by my annoyance with using > comprehensions in certain circumstances. > > Currently, if you want to perform successive transformations on the > elements of a list, a couple of options: > > 1. Successive comprehensions: > > L2 = [X(e) for e in L1] > L3 = [Y(e) for e in L2] > L4 = [Z(e) for e in L3] > or > L2 = [e.X() for e in L1] > > This gets the job done and gives you access to all the intermediate > values, but isn't very succinct, particularly if you are in the habit > of using informative identifiers. > > 2. One comprehension: > > L2 = [Z(X(Y(e))) for e in L1] > or > L2 = [e.X().Y().Z() for e in L1] > > This gets the job done, but doesn't give you access to all the > intermediate values, and tends to be pretty awful to read. > > Having "typed" lists let you take preexisting string/int/etc methods > and expose them in a vectorized context and provides an easy way for > developers to support both vectors and scalars in a single function > (you could easily "fix" other people's functions dynamically to > support both). Additionally, "typed" lists/iterators will allow > improved code analysis and optimization. The PyPy people have already > stated that they are working on implementing different strategies for > lists composed of a single type, so clearly there is already community > movement in this direction. > > Just compare the above examples to their type-aware counterparts: > > L2 = X(L1) > L2 = L1.X() > > L2 = Z(Y(X(L1))) > L2 = L1.X().Y().Z() What keeps you from implementing this? You don't need to change the language for it, just wrap the list in a class that overrides __getattr__() to return something that does the appropriate transformation for each element. I would be surprised if you needed more than a couple of lines of Python code for that. Stefan
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: Making the case for "typed" lists/iterators in python Stefan Behnel <stefan_ml@behnel.de> - 2011-12-16 19:23 +0100
csiph-web