Python evolution: Unease

[Roman Suzi]

Re: Python evolution: Unease

On Tue, 4 Jan 2005, Ian Bicking wrote:
[color=blue]
>Umm... this isn't helpful. "Generic" and "concept" are not terms that
>belong to Boost or STL or whatever. They are just words. Coining the
>term doesn't mean anyone else knows what it means, nor that anyone
>*should* know what they mean -- personally I get very suspicious of
>ideas that are based on redefined words, that tends to be a way of
>hiding complexity or fuzziness.
>
>But anyway, if you use these terms, you really must provide references,
>otherwise no one will know what you mean. "Python could have honest
>support of concepts" is simply an incomplete sentence. "Python could
>have honest support of Concepts (url)" would be more reasonable.[/color]

Sorry. I use definitions from there sources:

1. http://www.cs.rpi.edu/~musser/gp/

2. "A Formalization of Concepts for Generic Programming"
(google could find PDF of that). If I am correct, this one:

http://www.osl.iu.edu/publications/pubs/2004/willcock04:_formal_concep_gener_progr.pdf

(it is safe to skip till example on Fig.1 to grasp the idea behind
a concept. Relations between concepts are also very logical and
remind of inheritance, association and aggregation)

3. "The Boost Graph Library" by Jeremy Siek, et al with A.Stepanov's
foreword is a good way to see GP != STL.

Probably Boost docs contain some knowledge on the topic, at least
Boost Graph Library's ones (which I read).

[color=blue]
>"Python could have honest support of Concepts (url)"[/color]

- of course, right now those sources are C++-specific. But I could see that
Python has even greater potential to have concepts ahead of C++ and with
greater usefulness at the same time.


Sincerely yours, Roman Suzi
--
rnd@onego.ru =\= My AI powered by GNU/Linux RedHat 7.3

[Roman Suzi]

Re: Python evolution: Unease

On Tue, 4 Jan 2005, Dave Brueck wrote:
[color=blue]
>Roman Suzi wrote:[color=green][color=darkred]
>>>The term "generic programming" is too... er... generic. :)[/color][/color][/color]
[color=blue][color=green]
>> Nope. It is not generic. It has it's definition made by the co-author
>> of STL - A.Stepanov. And the Boost C++ library (many of us know it as
>> Boost Python) standardise on the approach, AFAIK.[/color]
>
>Ok, "too broad" then; Python already supports at least some aspects of generic
>programming (at least, in the sense that I think you mean it), so it'd be good
>to spell out what specific features you're referring to.
>[color=green]
>> Python could have honest support of concepts. Everything else will be
>> available with them.[/color]
>
>"Concepts" is a pretty generic term too! ;-) Do you mean concepts as defined
>here: http://www.boost.org/more/generic_programming.html
>?[/color]

Yes.
[color=blue][color=green]
>> And BTW, are we really disputing?[/color]
>[/color]
[color=blue]
>No, not at all - I'm just trying to better understand what you mean. Words
>like "generic" and "concepts" don't yet have a widely recognized, strict
>definition in the context of programming. If somebody has assigned some
>specific definition to them, that's great, it's just not universal yet so
>references and additional explanations are helpful.[/color]

I apologize for not providing URLs to the exact definitions in the first
place! I really think there is ONE understanding of GP vs. multitudes of
understandings of OOP.


Sincerely yours, Roman Suzi
--
rnd@onego.ru =\= My AI powered by GNU/Linux RedHat 7.3

[Robert Kern]

Re: Python evolution: Unease

Terry Reedy wrote:[color=blue]
> "Bulba!" <bulba@bulba.co m> wrote in message
>[color=green]
>>E.g. right now I would kill for a standard, built-in matrix
>>type[/color]
>
>
> The array types of Numerical Python (NumPy) and now Numarray are, defacto,
> Python's standard 1 to n dimensional array types. Once installed, they are
> as builtin as anything else. Several other packages build on top of them.[/color]

And one of the goals of numarray (which is a complete rewrite of
Numeric) *is* entry into the standard library.

--
Robert Kern
rkern@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Skip Montanaro]

Re: Python evolution: Unease


Terry> Numarray has a record array type. If there is not one publicly
Terry> available, perhaps you could write a CSV file to record-array
Terry> slurper and contribute it to the Recipes site or maybe even the
Terry> CSV module.

-1 on putting such a beast into the CSV module, especially if, as it seems,
it would rely on something outside the core.

Skip

[Carlos Ribeiro]

Re: Python evolution: Unease

On Tue, 4 Jan 2005 19:19:32 -0600, Skip Montanaro <skip@pobox.com > wrote:[color=blue]
>
> Terry> Numarray has a record array type. If there is not one publicly
> Terry> available, perhaps you could write a CSV file to record-array
> Terry> slurper and contribute it to the Recipes site or maybe even the
> Terry> CSV module.
>
> -1 on putting such a beast into the CSV module, especially if, as it seems,
> it would rely on something outside the core.[/color]

Although I see your point, in the long term it will be required.
Assuming that Numarray will, at some point in the future, be included
in the stdlib... why not give these people some help, easing the
integration? A recipe, or some code that can be provisionally included
in Numarray itself (as a submodule), and then later migrated to the
CSV module... it does make sense in the long run.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro@gmai l.com
mail: carribeiro@yaho o.com

[Alex Martelli]

Re: Python evolution: Unease

Dave Brueck <dave@pythonapo crypha.com> wrote:
...[color=blue]
> No, not at all - I'm just trying to better understand what you mean. Words
> like "generic" and "concepts" don't yet have a widely recognized, strict
> definition in the context of programming. If somebody has assigned some
> specific definition to them, that's great, it's just not universal yet so
> references and additional explanations are helpful.[/color]

Googling for "generic programming" (with the quotes) gets 100,000 +
hits. The first couple pages of hits, at least, seem to all be speaking
about exactly the same thing. The terminology appears to be settled
enough that Oxford's St Anne College feels they can organize a "Summer
School on Generic Programming", Nottingham University a "Workshop on
Generic Programming", etc, etc, without fearing ambiguity.

"Generic" by itself is one thing, but when we specifically mention
"Generic programming" I do not really see the ambiguity. Same for
"concepts" -- by itself it's too wide, to the point that it means
nothing, but put it next to "generic programming" and the resulting
26.000 hits seem to be mostly speaking about the very same thing, in as
much as one can tell from the first few pages of hits, "a concept is
defined as a family of abstractions that are all related by a common set
of requirements" to quote Musser.

Exactly what extra support Roman would want from Python for 'concepts',
beyond that offered by, say, C++, I'm not sure. Protocols, interfaces
and design-by-contract are other terms often used to try and capture
pretty similar issues. As far as I know the C++ community is unique in
routinely formalizing some PERFORMANCE requirements (pragmatics ahoy!-)
as part of their approach to generic programming -- but that's just an
important cultural issue, the LANGUAGE itself, C++ as it stands, offers
no way to say "this has O(N) perfrmance"... this kind of thing still
goes in comments, and in clauses in standardization documents.

When I say that a "protocol" includes pragmatics as well as syntax and
semantics, that's part of what I mean, in a handwaving kind of sense.

The *interface* to a Python dictionary/mapping includes a set of methods
with certain signatures; it expresses little beyond "syntax" issues.

The *semantics* of it include axioms that could and perhaps should be
formalized to define the connectedness among the methods, e.g. a long
list of things such as "for any x acceptable as a key and y acceptable
as a value into d, ...:

d[x] = y
assert x in d

del d[x]
assert x not in d

d[x] = y
z = d[x]
assert z is y

and so on, and so forth". The kind of things one would write in a unit
test... except that unit tests don't include universal quantifiers of
the form "for any x such that";-).

Finally, the *pragmatics* of a Python dictionary include "accessing d[x]
is pretty darn fast" although no doubt that could (I dunno if it should)
be formalized further.

As to how a "dictionary CONCEPT" might differ from a "dictionary
PROTOCOL", I'm not sure. They both should include syntax (interface),
semantics (behavior specs), and perhaps a sprinkling of pragmatics --
such as, O(...) performance specs for some operations, but mostly stuff
that's harder to formalize, such as, say:
x = malloc(N);
x = realloc(x, M):
when N is very very large, and M is MUCH smaller than N, SHOULD,
pragmatically, make some memory available for other uses (as opposed to
leaving it all in the block allocated for x) -- the kind of things that
don't get into formalized standards because handwaving is disliked
there, but can make a programmer's life miserable nevertheless (as this
very issue does with today's Python, which relies on these pragmatics in
a spot or two, and MacOSX' standard C library, which ignores them...).


Alex

[Skip Montanaro]

Re: Python evolution: Unease


Terry> Numarray has a record array type. If there is not one publicly
Terry> available, perhaps you could write a CSV file to record-array
Terry> slurper and contribute it to the Recipes site or maybe even the
Terry> CSV module.[color=blue][color=green]
>>
>> -1 on putting such a beast into the CSV module, especially if, as it
>> seems, it would rely on something outside the core.[/color][/color]

Carlos> Although I see your point, in the long term it will be required.
Carlos> Assuming that Numarray will, at some point in the future, be
Carlos> included in the stdlib... why not give these people some help,
Carlos> easing the integration?

I'm not sure they really need my help. I've never needed Numarray (or
Numeric) in my own work. If it's deemed useful I'm sure someone from that
community could whip something out in a few minutes. The concepts
represented by the csv module are a lot shallower than those represented by
Numarray.

Skip

[Roman Suzi]

Re: Python evolution: Unease

On Wed, 5 Jan 2005, Alex Martelli wrote:
[color=blue]
>Dave Brueck <dave@pythonapo crypha.com> wrote:
> ...[color=green]
>> No, not at all - I'm just trying to better understand what you mean. Words
>> like "generic" and "concepts" don't yet have a widely recognized, strict
>> definition in the context of programming. If somebody has assigned some
>> specific definition to them, that's great, it's just not universal yet so
>> references and additional explanations are helpful.[/color]
>
>Googling for "generic programming" (with the quotes) gets 100,000 +
>hits. The first couple pages of hits, at least, seem to all be speaking
>about exactly the same thing. The terminology appears to be settled
>enough that Oxford's St Anne College feels they can organize a "Summer
>School on Generic Programming", Nottingham University a "Workshop on
>Generic Programming", etc, etc, without fearing ambiguity.[/color]

That is why I was pretty sure people undestand me.
[color=blue]
>Exactly what extra support Roman would want from Python for 'concepts',
>beyond that offered by, say, C++, I'm not sure. Protocols, interfaces
>and design-by-contract are other terms often used to try and capture
>pretty similar issues.[/color]

I just happen to like the term 'concept' more than Protocols, interfaces,
and design-by-contract ;-)

Alex, I think you are +10 for adding interfaces into Python. "Concept"
is more compact word and I am sure it is not used as a name in existing
projects, unlike other words.

Also, Python concept collection could be used as a teaching example or
templates for high quality code. Concepts need not appear in every
script out there, but as a result of design.

What else Python needs to support GP? A possibility to formally
define a concept (and concept relations) with (optionally)
checks of implementations .

I do not even insist in making it all run-time! Perhaps concepts could
be checked in PyChecker. And (perhaps) the whole type-checking
could be done this way.

However sweety it is, I also hope to have keystrokes saved when
I use ready-maid concept in my program.

Just imagine we have a concept for table and use (as adaptor) it for
db-connectivity, CSV-readers/writers, XML/HTML parsers/writers, arrays,
lists, ...

Right now Python _almost_ has it. However, small differences in small details
do not allow to interchange even different dbm-modules! I remember
getting into trouble when I switched from bsddb to gdbm: some places needed
'r' to be explicitly specified! Same problems with db-api 2.0 "almost"
conformant modules, datetime types and other small details which are
similar but differ in small details at the same time. I think the same
has place with XML-DOM implementations and such.

I think concepts could be guards against such things and also make life easier
for those who implement some standard protocols. That is, concepts could be
internal (Python) standardizing and quality control technique. We can use
constant publicId, systemId a-la XML for concepts, so upgrade path will be
similar to HTMLs. This will make concept-changing visible between versions.


Sincerely yours, Roman Suzi
--
rnd@onego.ru =\= My AI powered by GNU/Linux RedHat 7.3

[Alex Martelli]

Re: Python evolution: Unease

Roman Suzi <rnd@onego.ru > wrote:
[color=blue]
> Alex, I think you are +10 for adding interfaces into Python. "Concept"
> is more compact word and I am sure it is not used as a name in existing
> projects, unlike other words.[/color]

Actually, I want protocols -- semantics (and pragmatics), too, not just
syntax (method names and signatures). Eby's PyProtocols comes closest
to my desiderata (though it possibly exceeds them). But if you start
coding a PyConcepts alternative to PyProtocols I'll be delighted to try
it out, contribute, &c -- I won't be a stickler for the name. Indeed,
"protocol" is no doubt more overloaded, since it's an established name
in networking, and if you google for "protocol adaptation" you get a mix
mostly related to networking with a few examples of the way PEP 246 uses
the phrase thrown in;-).


Alex

[Bulba!]

Re: Python evolution: Unease

On Wed, 5 Jan 2005 07:37:25 -0600, Skip Montanaro <skip@pobox.com >
wrote:
[color=blue]
>
> Terry> Numarray has a record array type. If there is not one publicly
> Terry> available, perhaps you could write a CSV file to record-array
> Terry> slurper and contribute it to the Recipes site or maybe even the
> Terry> CSV module.[color=green][color=darkred]
> >>
> >> -1 on putting such a beast into the CSV module, especially if, as it
> >> seems, it would rely on something outside the core.[/color][/color]
>
> Carlos> Although I see your point, in the long term it will be required.
> Carlos> Assuming that Numarray will, at some point in the future, be
> Carlos> included in the stdlib... why not give these people some help,
> Carlos> easing the integration?
>
>I'm not sure they really need my help. I've never needed Numarray (or
>Numeric) in my own work.[/color]

I've never needed numeric stuff either. I just need to do things like:

..>>> table.sort(colu mn_name) # that obviously would sort rows of table
by the values of column column_name

or

..>>> unique = table.unique(co lumn_name) # that would yield such
a subset of all the rows that would contain unique values from column
column_name

or

..>>> table1.union(ta ble2 [,drop_missing_c olumns |
,fill_missing_w ith_None])

or

..>>> common = table1.intersec tion(table2, column_name [, unique |
, redundant])

# that would yield all the rows that have the same values in
column_name in both table1 and table2; if optional keyword
"unique" were given, those could e.g. be only rows
from table1, when the "redundant" keyword were specified,
that could be a union of common rows from table1 and table2

or

..>>> complement = table.complemen t(complement_fu nction) # where
complement function could be anything, like (!cellvalue) or
string.upper; that obviously would run the complement_func tion
on every cell in table

(obviously, this could also be implemented as
map(table, complement_func tion) )

Now suppose a programmer could write a custom complement function
that detects all the irregularly distributed "anomalous" data points
(be it whatever, missing surnames from personnel records or values
from a physical experiments that are below some threshold) in this
table and returns, say, a list of tuples that are coordinates of those
data points. Getting it from a specific table would be a matter of one
instruction!

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?
[color=blue]
>If it's deemed useful I'm sure someone from that
>community could whip something out in a few minutes. The concepts
>represented by the csv module are a lot shallower than those represented by
>Numarray.[/color]

True, and I may scratch enough time together to learn all the
necessary stuff (I'm not even half done in learning Python)
to write it myself.

That is not the point, however: the biggest boost and one of the
main points of getting into Python, at least for me, but I'm sure
this is also motivation for quite a lot of other people, is precisely
the ease of exploiting capabilities of data structures like
dictionaries and lists, which when coupled with this data structure's
object-style .method are simply very convenient and fast. This is
where IMHO Python excels among the VHLL languages.

I'm about to post reworked version of my program that doesn't
use a _single_ traditional loop to do all the data transformations
I need (I just still need to solve some problems there / polish
it).

This is not just about that damn CSV file that I already have
the way I wanted it and sent it to customer, this is about _terse
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?

If Pythoners say a=['A'], it's only logical to say a.append('B'). :-)




--
It's a man's life in a Python Programming Association.

[Robert Kern]

Re: Python evolution: Unease

Bulba! wrote:[color=blue]
> On Wed, 5 Jan 2005 07:37:25 -0600, Skip Montanaro <skip@pobox.com >
> wrote:[/color]
[color=blue]
> I've never needed numeric stuff either. I just need to do things like:
>
> .>>> table.sort(colu mn_name) # that obviously would sort rows of table
> by the values of column column_name[/color]

[snip for brevity]
[color=blue]
> Now suppose a programmer could write a custom complement function
> that detects all the irregularly distributed "anomalous" data points
> (be it whatever, missing surnames from personnel records or values
> from a physical experiments that are below some threshold) in this
> table and returns, say, a list of tuples that are coordinates of those
> data points. Getting it from a specific table would be a matter of one
> instruction!
>
> 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?[/color]

I'm not sure what you mean by "written by hand." 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.

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.
[color=blue][color=green]
>>If it's deemed useful I'm sure someone from that
>>community could whip something out in a few minutes. The concepts
>>represented by the csv module are a lot shallower than those represented by
>>Numarray.[/color]
>
>
> True, and I may scratch enough time together to learn all the
> necessary stuff (I'm not even half done in learning Python)
> to write it myself.
>
> That is not the point, however: the biggest boost and one of the
> main points of getting into Python, at least for me, but I'm sure
> this is also motivation for quite a lot of other people, is precisely
> the ease of exploiting capabilities of data structures like
> dictionaries and lists, which when coupled with this data structure's
> object-style .method are simply very convenient and fast. This is
> where IMHO Python excels among the VHLL languages.
>
> I'm about to post reworked version of my program that doesn't
> use a _single_ traditional loop to do all the data transformations
> I need (I just still need to solve some problems there / polish
> it).
>
> This is not just about that damn CSV file that I already have
> the way I wanted it and sent it to customer, this is about _terse
> 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?[/color]

Sure. We're working on it! 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. 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.

--
Robert Kern
rkern@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Steve Holden]

Re: Python evolution: Unease

Aahz wrote:
[color=blue]
> In article <1104831798.408 560.228940@c13g 2000cwb.googleg roups.com>,
> <michele.simion ato@gmail.com> wrote:
>[color=green]
>>Maybe a PSF grant would help? I guess this has been considered ...[/color]
>
>
> The first three PSF grants were all in some way not directly related to
> changing the core language. One was for a library, one for improving
> Jython, and one for improving docs. Giving the PSF more money increases
> the chances for additional work.[/color]

I would, however, like to make the point that the Foundation is much
more likely to fund work that actually gets proposed for a grant, since
the officers don't generally have the time to inspire teams and promote
specific topics. So if a bunch of like-minded people wanted to get
together to propose a specific set of changes, it would then at least be
possible to consider such changes for funding.

There's also a lot of good work that goes on unfunded, of course, and I
wouldn't like to see the grants process subvert such public-spirited
efforts in any way. So there's nothing to stop a bunch of like-minded
individuals proposing changes anyway, through the existing process.

Lastly, the Foundation has only just started to make grants, and so we
need a little time to see how the existing projects go before we can
evaluate the success or failure of the process (at least on the existing
projects, whose outcomes may or may not be related to the grant process).

regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119

[Bulba!]

Re: Python evolution: Unease

On Wed, 05 Jan 2005 17:25:08 -0800, Robert Kern <rkern@ucsd.edu >
wrote:
[color=blue][color=green]
>> 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?[/color][/color]
[color=blue]
>I'm not sure what you mean by "written by hand."[/color]

I mean the same way as you do mylist.sort() in Python
instead of writing the list sorting function yourself in
the application / script.
[color=blue]
>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.[/color]

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).
[color=blue]
>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.[/color]

I have downloaded it, playing with it and like it. I esp. like things
like:
[color=blue][color=green][color=darkred]
>>> print a + a[/color][/color][/color]
[2 4 6]

or
[color=blue][color=green][color=darkred]
>>> b.getshape()[/color][/color][/color]
(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:
[color=blue][color=green][color=darkred]
>>> transpose([('phone1', 12345), ('phone2', 67890)])[/color][/color][/color]
Traceback (most recent call last):
File "<interacti ve 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(recar ray)
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.
[color=blue][color=green]
>> 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?[/color][/color]
[color=blue]
>Sure. We're working on it![/color]

Excellent! Great, I'm really grateful to you all for doing that.
Honestly.
[color=blue]
>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.[/color]

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.
[color=blue]
>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.[/color]

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.

[Jarek Zgoda]

Re: Python evolution: Unease

Iwan van der Kleyn wrote:
[color=blue]
> But I see little to no efforts from the core python team to address my
> needs as listed above. They seem mainly to focus on the core attributes
> and syntax of the language. Very little or no efforts are taken to
> improve the infrastructure around the language.
>
> And then I read the following sentence by Van Rossum:
>
> "In order to make type inferencing a little more useful, I'd like to
> restrict certain forms of extreme dynamic behavior in Python"
>
> In the end, it's mindset which counts. And I think that mindset is going
> to be determine the way foreward for Python: more features, increased
> complexity, less dynamism. Lots of syntax crud, without addressing the
> need to improve the infrastructure around the language.[/color]

I saw this once somewhere:

http://groups.google.com/groups?selm=cf38ph%242f8%241%40namru.matavnet.hu

--
Jarek Zgoda
http://jpa.berlios.de/ | http://www.zgodowie.org/

[Robert Kern]

Re: Python evolution: Unease

Bulba! wrote:[color=blue]
> On Wed, 05 Jan 2005 17:25:08 -0800, Robert Kern <rkern@ucsd.edu >
> wrote:[/color]
[color=blue][color=green]
>>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.[/color]
>
>
> I have downloaded it, playing with it and like it. I esp. like things
> like:
>
>[color=green][color=darkred]
>>>>print a + a[/color][/color]
>
> [2 4 6]
>
> or
>
>[color=green][color=darkred]
>>>>b.getshape( )[/color][/color]
>
> (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:
>
>[color=green][color=darkred]
>>>>transpose ([('phone1', 12345), ('phone2', 67890)])[/color][/color]
>
> Traceback (most recent call last):
> File "<interacti ve 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.[/color]

http://stsdas.stsci.edu/numarray/numarray-1.1.html/module-numarray.objects.html

In [1]: from numarray import objects, transpose

In [2]: a = objects.array([['phone1', 12345], ['phone2', 67890]])

In [3]: a
Out[3]:
ObjectArray([['phone1', 12345],
['phone2', 67890]])

In [4]: transpose(a)
Out[4]:
ObjectArray([['phone1', 'phone2'],
[12345, 67890]])

Note the use of lists. Using tuples makes the constructor think you want
a vector of tuple objects.

--
Robert Kern
rkern@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter