Antoon Pardon wrote: > Op 2006-03-31, Georg Brandl schreef <[EMAIL PROTECTED]>: >> Antoon Pardon wrote: >> >>> Well that looks somewhat short sighted to me. It is also why python >>> seems to throws so many surprises at people. >>> >>> My impression is that quite frequently people come here with a question >>> about why something doesn't work, that normally could be expected to >>> work. >> >>> The reason why it doesn't work then seems to boil down to the >>> developpers not taking the trouble of implementing something >>> in general but only for the cases for which they could imagine >>> a use case. Which means that when someone comes up with a use >>> case later he is stuck. >> >> I think you're overgeneralizing here. Do you have other examples of >> such a strategy resulting in something that doesn't work although >> it should? > > That is a very subjective question. I'm sure some will think > there is no reason why subclassing slices or functions should > work and so will not even consider this as something that > doesn't work but should. > > But I will give you one example. > > Consider the following: > > lst[3:7:2] > > What does it do? It constructs a slice object which is then used > as an index in lst.
Which wasn't true in older versions of Python. lst[x:y] was a special syntax construct calling a special method __getslice__. Slice objects were merely introduced to simplify index handling. > So why doesn't this work: > > fun(3:7:2) > > What is wrong with expecting that a slice object would be constructed > here which would then be used as an argument for the function call? Point taken, now that slicing creates slice objects this would be consistent. IIRC, there was indeed a PEP suggesting to introduce a range literal which would have made this possible. >> Nota bene: Often developers run into a limitation that is the result >> of a deliberate design choice, such as "why aren't strings mutable?" > > Well that is fine, but in this case I haven't seen such a design > choice explained. On the contrary the only thing that I have > heard in this case is that is wasn't implemeted because noone > submitted a patch. So it seems hardly the result of a deliberate > design choice in this case. > >>> I know about practicality beating purity, but purity has it >>> practical aspects too. If the python people had been willing >>> to work a bit more at purity, that would have been a lot >>> of more practical for those who found something not working >>> as expected, although they had no reason to suspect so. >> >> I've told you already: if a developer wants a feature not currently >> implemented, he/she can >> - ask on python-dev why >> - submit a feature request >> - submit a patch >> >> If he/she's not able to do one of these, he/she can at least convince some >> other Python developer if the use case is strong enough. > > Yes you told this already, and it ignores completely the point > I am trying to make. There is a point here beside convincing > the devolopers to implement this. Being? I mean, developer time isn't available en masse, and an overly strict view on purity might sometimes actually prevent a feature being implemented. Georg -- http://mail.python.org/mailman/listinfo/python-list