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

[Colin J. Williams]

konrad.hinsen at laposte.net wrote:

> On 02.03.2005, at 18:21, Colin J. Williams wrote:
> [snip]
>
>>> 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  number.

My understanding was that there was to be a new builtin multiarray/Array 
class/type which eventually would replace the existing array.ArrayType.  
Thus, for a time at least, there would be at least one new class/type.

In addition, it seemed to be proposed that the new class/type would not 
just be Array but Array_with_Int32, Array_with_Float64 etc..  I'm not 
too clear on this latter point but Konrad says that there would not be 
this multiplicity of basic class/type's.

>
>> 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...

Having spent little time with Unices, I'm not familiar with emacs.  
Another useful facility with PythonWin is that when one enters a class, 
function or method, followed by "(", the docstring is presented.  This 
is often helpful.  Finally, the PythonWin debug facility provides useful 
context information.  Suppose that f1 calls f2 which calls ... fn and 
that we have a breakpoint in fn, then the current values in each of 
these contexts is available in a PythonWin panel.

> [snip]
>
>> 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::
>         pass
>
> correctly.
>
> Konrad.

Yes, that it a problem which is not well resolved by requiring that a 
slice be terminated with a ")", "]", "}" or a space.  One of the 
difficulties is that the slice is not recognized in the current syntax.  
We have a "slicing" which ties a slice with a primary, but no "slice".  
Your earlier suggestion that a slice be [a:b:c] is probably better.  
Then a slicing would be:

    primary slice

which no doubt creates parsing problems.

Thomas Wouters proposed a similar structure for a range in PEP204 
(http://python.fyxm.net/peps/pep-0204.html), which was rejected.

Colin W.