On Tue, Dec 08, 2009 at 10:17:20AM -0800, Dr. Phillip M. Feldman wrote: > > > > David Warde-Farley-2 wrote: > > > > > > A less harmful solution (if a solution is warranted, which is for the > > Council of the Elders to > > decide) would be to treat the Python complex type as a special case, so > > that the .real attribute is accessed instead of trying to cast to float. > > > > > > There are two even less harmful solutions: (1) Raise an exception.
This is not less harmful, since as I mentioned there is likely a lot of deployed code that is not expecting such exceptions. If such a change were to take place it would have to take place over several versions, where warnings are issued for a while (probably at least one stable release) before the feature being removed. Esoteric handling of ambiguous assignments may not speed adoption of NumPy, but monumental shifts in basic behaviour without any warning will make us even less friends. The best thing to do is probably to file an enhancement ticket on the bugtracker so that the issue doesn't get lost/forgotten. > (2) Provide the user with a top-level flag to control whether the attempt to > downcast a NumPy complex to a float should be handled by raising an > exception, by throwing away the imaginary part, or by taking the magnitude. I'm not so sure that introducing more global state is looked fondly upon, but it'd be worth including this proposal in the ticket. > P.S. As things stand now, I do not regard NumPy as a reliable platform for > scientific computing. One man's bug is another's feature, I guess. I rarely use complex numbers and when I do I simply avoid this situation. David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
