On Wed, 05 Jan 2005 17:25:08 -0800, Robert Kern <[EMAIL PROTECTED]>
wrote:
>> Yes, I know, it can be written by hand. But by this line of logic why
>> bother learning VHLL and not just stay with C?
>I'm not sure what you mean by "written by hand."
I mean the same way as you do mylist.sort() in Python
instead of writing the list sorting function yourself in
the application / script.
>Someone is going to
>have to write the functions in the first place. Sure, they can be
>written once, well, and placed in the standard library so they don't
>have to be *re*written by anyone else again.
Well of course - the only point I mean here is getting
high-level stuff is one of the main motives of getting
into VHLL (aside from issues like automatic memory
management, of course).
>I still think numarray is a good start for this. It handles more than
>just numbers. And RecArray (an array that has different types in each
>column, as you seem to require) can be subclassed to add these methods
>to it.
I have downloaded it, playing with it and like it. I esp. like things
like:
>>> print a + a
[2 4 6]
or
>>> b.getshape()
(4,3)
Very Pythonic. :-)
However, not all things are generic enough like I meant. That
is not to criticize, but merely to point out that the library is for
obvious reasons slanted towards numerical work, so e.g. while the
following works:
.>>> from numarray import transpose
.>>> transpose([[1,2],[3,4]])
array([[1, 3],
[2, 4]])
...this doesn't:
>>> transpose([('phone1', 12345), ('phone2', 67890)])
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
[....]
TypeError: Expecting a python numeric type, got something else.
Why would someone want to do such a thing: suppose he
wants 'phone1' and 'phone2' and number records sequenced
horizontally instead vertically, while when he read that from
a file, such was the file structure. It's a boneheaded example,
but you get the idea.
It's obvious why that exception happens: in recarray I have to have
the same type of the data type in every column, so transpose(recarray)
cannot be done.
This is not the situation with other builtin Python data types, where
whatever with can be mixed, i.e. placed in any "cell" of data type
and all the functions will still work as long as the operand type is
proper.
This is obviously the consequence of numarray being based on
the matrices designed for working on numerical data, so it's
probably very fast and I'm sure people who use it find it useful.
But personally I would happily sacrifice much or even most of that
speed for sake of flexibility. Because, sure, I can keep the
matrix header with strings separately in a list, do the transformation
just on numbers, adjust the list as well - it's not like I'm just lazy
to make an additional programming effort, but that eliminates
one of the greatest advantages of Python: terseness without
foregoing clarity.
Yes, now it's probably much harder to do once the simpler things
have been done. All I'm saying is that it would be so frigging nice
to have it with even richer data structures.
>> and clear_ manipulations of rich data structures in Python. Why not
>> extend them with flexible tables / matrices / arrays that would work
>> in as "Pythonic" ways as dictionaries and lists already do?
>Sure. We're working on it!
Excellent! Great, I'm really grateful to you all for doing that.
Honestly.
>Come check out numarray; I think you'll like
>it. And if, along the way, you write a CSV-to-RecArray converter, we'd
>*love* to include it in the distribution.
First I have to learn Python (and programming in general) well enough
to produce smth that isn't as bug-infested as a software of certain
well-known vendor and that I would not be ashamed of to show to the
world. :-) I'm afraid it will take me some time.
>I think that a more complete
>integration with the other core Python facilities like the csv module
>will help numarray become more suited for inclusion into the standard
>library.
I'm sure people would find it useful. I play with numarray to get the
idea how I could apply it in my work.
--
It's a man's life in a Python Programming Association.
--
http://mail.python.org/mailman/listinfo/python-list
