[Numpy-discussion] Some comments on the Numeric3 Draft of 1-Mar-05
Colin J. Williams
cjw at sympatico.ca
Thu Mar 3 08:47:34 EST 2005
konrad.hinsen at laposte.net wrote:
> On 02.03.2005, at 18:21, Colin J. Williams wrote:
>>> The Python standard library has hundreds of types, considering that
>>> the difference between C types and classes is an implementation
>> 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.
>> 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::
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:
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.
More information about the NumPy-Discussion