
Hi Matthew,
Ah - well - I only meant that raising an error in the example would be no more surprising than raising an error at the python prompt. Do you agree with that? I mean, if the user knew that:
np.array([1], dtype=np.int8) + 128
would raise an error, they'd probably expect your offset routine to do the same.
I think they would be surprised in both cases, considering this works fine: np.array([1], dtype=np.int8) + np.array([128])
I agree it kind of feels funny, but that's why I wanted to ask you for some silly but specific example where the funniness would be more apparent.
Here are a couple of examples I slapped together, specifically highlighting the value of the present (or similar) upcasting behavior. Granted, they are contrived and can all be fixed by conditional code, but this is my best effort at illustrating the "real-world" problems people may run into. Note that there is no easy way for the user to force upcasting to avoid the error, unless e.g. an "upcast" keyword were added to these functions, or code added to inspect the data dtype and use numpy.add to simulate the current behavior. def map_heights(self, dataset_name, heightmap): """ Correct altitudes by adding a custom heightmap dataset_name: Name of HDF5 dataset containing altitude data heightmap: Corrections in meters. Must match shape of the dataset (or be a scalar). """ # TODO: scattered reports of errors when a constant heightmap value is used return self.f[dataset_name][...] + heightmap def perform_analysis(self, dataset_name, kernel_offset=128): """ Apply Frobnication analysis, using optional linear offset dataset_name: Name of dataset in file kernel_offset: Optional sequencing parameter. Must be a power of 2 and at least 16 (default 128) """ # TODO: people report certain files frobnicate fine in IDL but not in Python... import frob data = self.f[dataset_name][...] try: return frob.frobnicate(data + kernel_offset) except ValueError: raise AnalysisFailed("Invalid input data")