From: Konrad H. <hi...@cn...> - 2002-06-15 08:55:56
|
> I'd be strongly against this. This has the same problem that other > customized array objects have (whether regarding slicing behavior, > operators, coercion...). In particular, it is clear which kind it > is when you create it, but you may pass it to a module that > presumes different array behavior. Having different kind of arrays We already have that situation with lists and arrays (and in much of my code netCDF arrays, which have copy semantics) , but in my experience this has never caused confusion. Most general code working on sequences doesn't modify elements at all. When it does, it either clearly requires view semantics (a function you call in order to modify (parts of) an array) or clearly requires copy semantics (a function that uses an array argument as an initial value that it then modifies). > floating around just seems like an invitation for confusion. I'm > very much in favor of picking one or the other behaviors and then > making some means of explicitly getting the other behavior. Then the only solution I see is the current one: default behaviour is view, and when you want a copy yoy copy explicitly. The inverse is not possible, once you made a copy you can't make it behave like a view anymore. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hi...@cn... 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 ------------------------------------------------------------------------------- |