Re: [Numpy-discussion] Numarray 0.5

[Todd M. <jm...@st...>]

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