[Numpy-discussion] Response to PEP suggestions
rkern at ucsd.edu
Sun Feb 20 01:52:09 CST 2005
konrad.hinsen at laposte.net wrote:
> On 20.02.2005, at 00:55, Robert Kern wrote:
>> understanding your proposition correctly, it also creates another
>> problem: rank-n arrays would then pass this check, although they
> No. My proposal is to have new Python scalar types, which are distinct
> from the array type(s). The new scalar types would use rank-0 arrays as
> their internal representation, but that would be an implementation
> detail not visible to users.
*Ahh!* Enlightenment dawns. That makes a *hell* of a lot more sense than
what I thought you were proposing. Thank you for bearing with my babbling.
I withdraw my objections.
I do have one comment, though. I still prefer the idea that arrays,
including rank-0 arrays, be containers. So I would suggest that there
only be a handful of new rank-0 types, int-like, float-like,
complex-like, object, and maybe a couple more. The differences between
the type objects would be solely for inheritance reasons. Different
precisions would be handled like they are for rank-n arrays.
>> I expect so, too. However, when considering additions to the standard
>> library, python-dev has to assume otherwise. If it's going to be so
>> limited in application, then something so large shouldn't be in the
>> standard library.
> I am not so sure about this. There is some very domain-specific stuff
> in the standard library.
I think my point was that a number hierarchy is something that *ought*
to have much wider applicability. If the implementation *doesn't*, then
it shouldn't be in the standard library. That's why I prefer the
arrangement I described above. It isn't a real number hierarchy and
doesn't purport to be one. It's just an implementation detail to make
multiarrays place nicer with the rest of the Python universe.
>> I think it would be great to have a more thorough number hierarchy in
>> the standard library. So would some others. See PEPs 228 and 242.
>> However, I think that the issue is orthogonal getting an multiarray
>> object into the standard library. I'm not convinced that it actually
>> solves the problems with
> The common point is just the community that is interested in this.
> However, there might be a wider interest in a re-working of the number
> hierarchy. There have been additions to the number hierarchy that don't
> come from the numerics community, such as the decimal number type. I
> think that a more open number hierarchy, into which modules could add
> their own types, could make it into the core if it doesn't cause any
> compatibility problems. In fact, this may be easier to argue for than
> having array methods on all scalar types.
Agreed. I think, though, that what Travis proposes in "PEP Updated" is
going to be easiest of all to swallow.
 Isn't it amazing how many design problems go away by claiming that
"it's just an implementation detail?" :-)
rkern at ucsd.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
More information about the Numpy-discussion