[Numpy-discussion] Numarray 0.5
Todd Miller
jmiller at stsci.edu
Wed May 7 05:35:20 EDT 2003
On Wed, 2003-05-07 at 05:16, Peter Verveer wrote:
> > > I am not sure if this is a bug, or intended behaviour, but the possibilty
> > > to compare an array type object to 'Any' would be very useful for me.
> >
> > 'Any' grew up from the C-API, rather than down from the Python design,
> > so it's not very well thought out. Right now, it is a placeholder used
> > to mark arrays with undefined types and to indicate "no type constraint"
> > in C API calls. In normal contexts, you can't make an array of type
> > 'Any'. I think there are two reasonable behaviors for comparisons with
> > 'Any', both used in C. The first behavior is literal comparison; here
> > comparison to Any would generally return "not equal". The second
> > behavior is wild-card matching; here, comparison to Any would generally
> > return "equal". Which makes sense to you? How do you want to use
> > this?
>
> I use 'Any' right now in C functions to indicate 'no type constraint'. You
> could use both literal comparison and wild-card matching behaviour for that,
> if you want to do this in Python, I think. But maybe one should not do such a
> thing in Python by comparison to 'Any' at all.
>
> Literal comparison is what I generally expect from Python objects, so anything
> else may just be confusing (at least to me). However, the name 'Any' does
> suggest the wild-card matching behaviour.
>
> Is there specific reason why you exposed 'Any' in python?
Initially it was not exposed. As the API type functions evolved, it
made Any less of a special case to expose it.
> Maybe it would be
> better not to expose such a type object since it seems to be a 'special
> case'. I am starting to think that my use for it at the Python level is not
> appropiate.
> For instance, I could easily use 'None' instead, and I think I
> will do that in the future.
Yes. That's probably what I should have done in C as well: tNone rather
than tAny.
>
> You mentioned that 'Any' is really a C-API thing. Unless somebody has a good
> use for it I would now actually say that it maybe should not be exposed at
> the Python API level at all...
I agree with this. It might be as simple as renaming it to _Any in
Python, but I still hesitate to change this until I have a little more
time to think about it. Too often, things go from "bad" to "not so
good"...
Thanks for the input,
Todd
More information about the NumPy-Discussion
mailing list