[Numpy-discussion] Some comments on the Numeric3 Draft of 1-Mar-05

konrad.hinsen at laposte.net konrad.hinsen at laposte.net
Thu Mar 3 00:34:18 EST 2005

On 02.03.2005, at 18:21, Colin J. Williams wrote:

> Sub-types in the sense that, given an instance a of Array,  
> a.elementType gives us the type of the data elements contained in a.

Ah, I see, it's just about how to access the type object. That's not my  
first worry in design questions. Once you can get the object somehow,  
you can make it accessible in nearly any way you like.

>> The Python standard library has hundreds of types, considering that  
>> the difference between C types and classes is an implementation  
>> detail.
> I was thinking of the objects in the types module.

Those are just the built-in types. There are no plans to increase their  

> Yes, it is built into Mark Hammond's PythonWin and is a valuable tool.  
>  Unfortunately, it is not available for Linux.  However, I believe  
> that SciTE and boa-constructor are intended to have the "completion"  
> facility.  These open source projects are available both with Linux  
> and Windows.

The number of Python IDEs seems to be growing all the time - I haven't  
even heard of those. And I am still using Emacs...

>> The equivalent of "rank" is "number of dimensions", which is a bit  
>> long for my taste.
> Perhaps nDim, numDim or dim would be acceptable.

As a variable name, fine. As a pseudo-word in normal language, no. Not  
for me at least. I like sentences to use real, pronouncable words.

>> - No problems with code that does explicit typechecks (isinstance(x,  
>> float)
>>   or type(x) == types.FloatType). Although explicit typechecks are  
>> considered
>>   bad practice in general, there are a couple of valid reasons to use  
>> them.
> I would see this as supporting the conversion to a scalar.  For  
> example:

But technically it isn't, so some code would cease to work.

> Thanks.  It would be nice if a:b or a:b:c could return a slice object.

That would be difficult to reconcile with Python syntax because of the  
use of colons in the block structure of the code. The parser (and the  
programmers' brains) would have to handle stuff like

	if slice == 1::


Konrad Hinsen
Laboratoire Leon Brillouin, CEA Saclay,
91191 Gif-sur-Yvette Cedex, France
Tel.: +33-1 69 08 79 25
Fax: +33-1 69 08 82 61
E-Mail: khinsen at cea.fr

More information about the NumPy-Discussion mailing list