I think the consistency with Python is less of an issue than it seems. I wasn't aware that add.reduce(x) would generated the same results as the Python version of reduce(add,x) until Perry pointed it out to me.
It is an issue in much of my code, which contains stuff written with NumPy in mind as well as code using only standard Python operations (i.e. reduce()) which might however be applied to array objects. I also use arrays and nested lists interchangeably in many situations (NumPy functions accept nested lists instead of array arguments). Especially in interactive use, nested lists are easier to type.
There are some inconsistencies between Python the language and Numeric because the needs of the Numeric community. For instance, slices create views instead of copies as in Python. This was a correct break with
True, but this affects much fewer programs. Most of my code never modifies arrays after their creation, and then the difference in indexing behaviour doesn't matter.
I don't see choosing axis=-1 as a break with Python -- multi-dimensional arrays are inherently different and used differently than lists of lists
As I said, I often use one or the other as a matter of convenience. I have always considered them similar types with somewhat different specialized behaviour. The most common situation is building up some table with lists (making use of the append function) and then converting the final construct into an array or not, depending on whether this seems advantageous.
in Python. Further, reduce() is a "corner" of the Python language that has been superceded by list comprehensions. Choosing an alternative
List comprehensions work in exactly the same way, by looping over the outermost index.
2) Minimization of code breakage.
Fixes will be necessary for sure, and I wish that wasn't the case. They will be necessary if we choose a consistent interface in either case.
The current interface is not inconsistent. It follows a different logic than what some users expect, but there is a logic behind it. The current rules are the result of lengthy discussions and lengthy tests, though admittedly by a rather small group of people. If you arrange your arrays according to that logic, you almost never need to specify explicit axis arguments.
Choosing axis=0 or axis=-1 will not change what needs to be fixed -- only the function names searched for.
I disagree very much here. The fewer calls are concerned, the fewer mistakes are made, and the fewer modules have to be modified at all. Moreover, the functions that currently use axis=1 are more specialized and more likely to be called in similar contexts. They are also, in my limited experience, less often called with nested list arguments. I don't expect fixes to be as easy as searching for function names and adding an axis argument. Python is a very dynamic language, in which functions are objects like all others. They can be passed as arguments, stored in dictionaries and lists, assigned to variables, etc. In fact, instead of modifying any code, I'd rather write an interface module that emulates the old behaviour, which after all differs only in the default for one argument. The problem with this is that it adds another function call layer, which is rather expensive in Python. Which makes me wonder why we need this discussion at all. It is almost no extra effort to provide two different C modules that provide the same functions with different default arguments, and neither one needs to have any speed penalty.
True. But I can tell you that we're definitely doing something wrong now. We have a superior language that is easier to integrate with legacy code and less expensive than the best competing alternatives. And, though I haven't done a serious market survey, I feel safe in saying we have significantly less than 1% of the potential user base.
I agree with that. But has anyone ever made a serious effort to find out why the whole world is not using Python? In my environment (which is too small to be representative for anything), the main reason is inertia. Most people don't want to invest any time to learn any new language, no matter what the advantages are (they remain hypothetical until you actually start to use the new language). I don't know anyone who has started to use Python and then dropped it because he was not satisfied with some aspect of the language or a library module. On the other hand, I do know projects that collapsed after a split in the user community due to some disagreement over minor details. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------