Python evolution: Unease

[Iwan van der Kleyn]

Please ignore if you are allergic to ramblings :-)

Despite a puritan streak I've always tried to refrain from language wars
or syntax bickering; call it enforced pragmatism. That's the main reason
why I've liked Python: it's elegant and simple and still dynamic and
flexible. You could do worse for a clean and pragmatic language.

I do know my Smaltalk from my Common Lisp and my Ruby from my C#, so I
think I'm quite capable of escaping the "Blub paradox"
http://c2.com/cgi/wiki?BlubParadox. I do miss some slick features in
Python. But the nice thing about Python is that in those cases I can use
its dynamism to implement it myself (and usually somebody else has done
it for me, of course).

In the end I'm not a language guru nor a framework wizard, but a mere
mortal who designs and writes programs for end-users. For that task I
need: a better standard ide, an integrated db interface with a proper
set of db drivers (!!), a better debugger, a standard widget/windows
toolkit, something akin to a standard for web programming, better
documentation, a standard lib which is better organized, a formalized
set of protocols and patterns for program construction. And an
interpreter which is fast enough to avoid using C or Pyrex in most
obvious cases.

Many will say that Van Rossum's brainstorms/proposals as depicted in

http://www.artima.com/weblogs/viewpost.jsp?thread=86641

will help in the above mentioned. And I'm certainly not against Optional
ype checking.

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.

In short: I symphatize Patrick Logan's feeling:

http://patricklogan.blogspot.com/200...d-to-ruin.html


Regards,

Iwan van der Kleyn

[flamesrock]

Well, I'm not a seasoned programmer like you but I have to say Python
is the singlebest language I've worked with to date. In a matter of
weeks I learned to do things that took me months in other languages and
even found the process enjoyable.

Maybe you are right. If so, couldn't Python be forked into something
like you describe, while still remaining compatible at the core? (if
anyones willing)

Python++ anyone?

[Paul Rubin]

"flamesrock" <fl********@gmail.com> writes:

Maybe you are right. If so, couldn't Python be forked into something
like you describe, while still remaining compatible at the core? (if
anyones willing)

It's not an issue with the Python core (language); I read that post as
mostly bemoaning the poor state of the runtime library. I feel the
same concerns, however, fixing it is a lot of work.

[michele.simionato]

Maybe a PSF grant would help? I guess this has been considered ...
Michele Simionato

[Alex Martelli]

Iwan van der Kleyn <no**@none.net> wrote:

to be determine the way foreward for Python: more features, increased
complexity, less dynamism. Lots of syntax crud, without addressing the

As a student of human nature, I'm _really_ curious as to how one could
possibly read the key document:
http://www.python.org/peps/pep-3000.html
and think in consequence of "more features, increased complexity".

Also, you keep talking about "the core python team" on the basis, it
would appear, of reading one document by Guido. Have you bothered doing
a MINIMUM of homework, such as, looking at
http://www.amk.ca/diary/archives/cat_python.html
and specifically AMK's entry for September 30? I'm trying to understand
whether you completely missed doing the most elementary amount of
background searching before venting on the group, or if you did find and
read the obvious documents and somehow STILL manage to completely ignore
their contents or read them as saying exactly the opposite of what they
_do_ say...
Alex

[Iwan van der Kleyn]

Also, you keep talking about "the core python team" on the basis, it
would appear, of reading one document by Guido. Have you bothered doing
a MINIMUM of homework, such as, looking at
http://www.amk.ca/diary/archives/cat_python.html

Well, you being a member of that core team (meaning nog an
organisational unit, but the group of people doing the really hard job,
getting Python to work. An excellent job at that :-) I can repect you
if not branding me a lamer at least admonishing me for not coming up
with a thorough factual statement. But like I stated: "ramblings", remember.

I'm not completely unknown with the workings of our species myself,
though. Especially when discourse and policy is dictated by a select
group of people (meaning: the one who actually create python, no
criticism there) with final abritary powers for one indidual (again, no
criticism), mindset *is* just as important as stated fact. Mindset will
dictate future discourse and action.

And I do sense (reading planet python/this newsgroup) a mindset or at
least a tendency by the people who really matter in these discussion to
keep on adding features to the syntax; to add "structure" to Python. My
personal preference would be to leave the language alone for a while and
to improve its infrastructure.

Regards,
Iwan

[Ville Vainio]

>>>>> "Iwan" == Iwan van der Kleyn <no**@none.net> writes:

Iwan> And then I read the following sentence by Van Rossum:

Iwan> "In order to make type inferencing a little more useful, I'd
Iwan> like to restrict certain forms of extreme dynamic behavior
Iwan> in Python"

Iwan> In the end, it's mindset which counts. And I think that
Iwan> mindset is going to be determine the way foreward for
Iwan> Python: more features, increased complexity, less
Iwan> dynamism. Lots of syntax crud, without addressing the need
Iwan> to improve the infrastructure around the language.

What form of extreme dynamic behaviour have you been using lately? Do
you really think it's more worthwhile than the benefits provided by
type inference, least of which isn't the ability by IDEs to provide
you accurate code completion.

Also, Python is not a monolithic entity. Guido certainly isn't going
to write a better IDE for Python, so the time used on language
features isn't removed from improving the infrastructure around the
language.

--
Ville Vainio http://tinyurl.com/2prnb

[Paul Rubin]

Ville Vainio <vi***@spammers.com> writes:

Also, Python is not a monolithic entity. Guido certainly isn't going
to write a better IDE for Python, so the time used on language
features isn't removed from improving the infrastructure around the
language.

There aren't THAT many people working on Python. Any time spent on
feature X does tend to divert resources from feature Y.

I think there should be a moratorium on nontrivial language changes
(as opposed to library improvements) until PyPy is fully deployed.
Too much of Python as we know it today is shaped by the weirdness of
CPython. We ought to be able to get away from that.

[Ville Vainio]

>>>>> "Paul" == Paul Rubin <http://ph****@NOSPAM.invalid> writes:

Paul> Ville Vainio <vi***@spammers.com> writes:

Also, Python is not a monolithic entity. Guido certainly isn't
going to write a better IDE for Python, so the time used on
language features isn't removed from improving the
infrastructure around the language.

Paul> There aren't THAT many people working on Python. Any time
Paul> spent on feature X does tend to divert resources from
Paul> feature Y.

But the people working on wxPython, pygtk, pyqt, pydev, whatever, are
largely not the same guys that commit stuff to CPython CVS.

Paul> fully deployed. Too much of Python as we know it today is
Paul> shaped by the weirdness of CPython. We ought to be able to
Paul> get away from that.

Type declarations are a feature that might benefit IronPython and
Jython more than they would CPython.

--
Ville Vainio http://tinyurl.com/2prnb

[Paul Rubin]

Ville Vainio <vi***@spammers.com> writes:

But the people working on wxPython, pygtk, pyqt, pydev, whatever, are
largely not the same guys that commit stuff to CPython CVS.
Right, but for that reason, they don't count as being working on
Python.
Type declarations are a feature that might benefit IronPython and
Jython more than they would CPython.

CPython seems to be what drives quite a few language design decisions.

[Istvan Albert]

Iwan van der Kleyn wrote:

And I do sense (reading planet python/this newsgroup) a mindset or at
least a tendency by the people who really matter in these discussion to
keep on adding features to the syntax; to add "structure" to Python. My
personal preference would be to leave the language alone for a while and
to improve its infrastructure.

In all honesty this:

http://www.artima.com/weblogs/viewpost.jsp?thread=86641

scares me too. Reminds me of Larry Wall's writings on Perl 6
that make me tune out fairly quickly. I don't have the kind of
problems that the these features will solve so I can't relate
to them at all.

But others might do. Especially when using python in an environment
where enforcing a strict contract is important. But if python
were to become overly complicated I'll find something else.
Three years ago I have not not used python at all, now I'm
using it for everything.

Languages should evolve with time, adapt to the needs
of its users. Sometimes that means that in some areas
it might feel worse. But it could also mean that the
problem is with us, so it would be unfair to spend effort
towards holding back this evolution just because
we don't need it.

Istvan.

PS. why can't decorators solve this optional type checking
problem? I clearly remember this as being one of the
selling points for having decorators in the first place...

[Aahz]

In article <11**********************@c13g2000cwb.googlegroups .com>,
<mi***************@gmail.com> wrote:

Maybe a PSF grant would help? I guess this has been considered ...

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.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing." --Alan Perlis

[michele.simionato]

Aahz:

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.

Here is the link you forgot to post ;-)

http://www.python.org/psf/grants/

The one about the docs seems more about teaching scientists how to use
Python.

Michele Simionato

[Michael Hobbs]

Ville Vainio <vi***@spammers.com> wrote:

What form of extreme dynamic behaviour have you been using lately?

One real-world example: in my new coverage analysis tool (to be
released any month now), I need to trace threads without changing any
code. To do so, I redefine the thread.start_new_thread() function from
outside the thread module, like so:
orig_start_new_thread = thread.start_new_thread

def traced_start_new_thread(func, args, kwargs={}):
return orig_start_new_thread(traced_func_call, (func, args, kwargs))

def traced_func_call(func, args, kwargs):
sys.settrace(my_trace_func)
func(*args, **kwargs)

thread.start_new_thread = traced_start_new_thread
Granted, doing something like this on a regular basis is really bad
coding style, but the ability to do something like this when I really
need it is what I love about Python.

[Doug Holton]

Istvan Albert wrote:

But if python
were to become overly complicated I'll find something else.
Three years ago I have not not used python at all, now I'm
using it for everything.
You're in luck, python 2.4 won't be significantly changing anytime soon.
PS. why can't decorators solve this optional type checking
problem? I clearly remember this as being one of the
selling points for having decorators in the first place...

Because they are quite obviously an ugly and overly complicated
solution. Even Guido understood this:
http://mail.python.org/pipermail/pyt...er/048518.html

"A warning: some people have shown examples of extreme uses of
decorators. I've seen decorators proposed for argument and return type
annotations, and even one that used a decorator to create an object
that did a regular expression substitution. Those uses are cute, but I
recommend being conservative when deciding between using a decorator
or some other approach, especially in code that will see a large
audience (like 3rd party library packages). Using decorators for type
annotations in particular looks tedious, and this particular
application is so important that I expect Python 3000 will have
optional type declarations integrated into the argument list."

[Hans Nowak]

Alex Martelli wrote:

Iwan van der Kleyn <no**@none.net> wrote:

to be determine the way foreward for Python: more features, increased
complexity, less dynamism. Lots of syntax crud, without addressing the

As a student of human nature, I'm _really_ curious as to how one could
possibly read the key document:
http://www.python.org/peps/pep-3000.html
and think in consequence of "more features, increased complexity".

Also, you keep talking about "the core python team" on the basis, it
would appear, of reading one document by Guido. Have you bothered doing
a MINIMUM of homework, such as, looking at
http://www.amk.ca/diary/archives/cat_python.html
and specifically AMK's entry for September 30? I'm trying to understand
whether you completely missed doing the most elementary amount of
background searching before venting on the group, or if you did find and
read the obvious documents and somehow STILL manage to completely ignore
their contents or read them as saying exactly the opposite of what they
_do_ say...

Optimistic documents about a cleaner and smaller language (and an
improved stdlib) are all well and good, but if you look what has
actually been happening to Python over the last few years, then the OP's
worries don't seem so far-fetched. "More features, increased
complexity, less dynamism" pretty much sums it up.

Guido's posts about optional static typing seem to suggest that this
development will continue in the same vein. (He may just be putting his
thoughts on paper, but it's the BDFL, so what is one supposed to think?)

I for one will NOT welcome our new static typing overlords. ;-)

--
Hans Nowak
http://zephyrfalcon.org/

[Alex Martelli]

Iwan van der Kleyn <no**@none.net> wrote:
...

And I do sense (reading planet python/this newsgroup) a mindset or at
least a tendency by the people who really matter in these discussion to
keep on adding features to the syntax; to add "structure" to Python. My
personal preference would be to leave the language alone for a while and
to improve its infrastructure.

I happen to agree with this preference as stated here -- the time to
change the language is at 3.0 release time (say a few years from now).

It _is_, of course, perfectly sensible for Guido to start musing out
loud on the only major addition he really wants to make at that distant
time a few years from now, namely optional static typing -- it will be a
biggie when it comes, so it should not be sprung on us all by surprise;
the more (and the earlier) feedback comes to help him decide the exact
details of that addition, the merrier.

Meanwhile, over on python-dev, the discussion is on completing the
AST-branch (so the standard library may finally include a full
python-coded Python compiler when 2.5 is released, likely in 2006),
dealing (in distutils, mostly) with the fact that the Mac may use some
case-sensitive filesystems but its default one is case-preserving but
insensitive, issues with memory allocation strategies triggered by
Darwin's weird realloc behavior (a realloc there never shrinks an
allocation, eek), the best maintenance strategy for old FAQs, what
functionality is to be added to the zipfile module (e.g., removing files
from a zip archive), and the fix of a misspelling in the docs.

I kid you not: these are the threads going on today in the python-dev
list, where most of [the discussion about] Python's development really
takes place. Not sure who you believe "really matter in these
discussion" (sic), but the discussants today included Guido van Rossum,
Tim Peters, Martin v. Loewis, and many others. How one can possibly
infer from such raw data "a mindset or at least a tendency ... to keep
adding features to the syntax" is really hard to explain, at least for
me. Almost invariably, the great majority of proposals to change the
language, most particularly the syntax, come on this list, fortunately,
since that leaves python-dev essentially free to keep focusing on the
huge nitty-gritty daily work of enhancing the implementation (and other
aspects of the infrastruture, such as the spelling of the docs...);
almost invariably, moreover, the great majority of such proposals come
from clueless or semi-clueless newbies or semi-newbies.

You appear to have taken the fact that Guido appears to want lot of
early discussion about his ideas on optional static typing, presumably
to help those ideas develop, and drawn from that tiny speck of 'fact'
the most absurdly extrapolated conclusions, totally and utterly ignoring
the overwhelming countervailing mass of facts and evidence that point
exactly in the opposite direction.

Of course, what YOU think should happen regarding the infrastructure,
and what the people who donate their time to actually make things happen
want, may be totally at odds. For example, you appear to keenly want
one standard IDE to be blessed and receive all attention, one standard
web framework ditto, and so on, and so forth; most core developers, on
the other hand, appear to be very modestly inclined to spend their time
and energy in that direction, so that only a rather minor fraction of
the python-dev effort is channeled that way. Innovative efforts are
best kept OUT of the core Python standard, many of us believe, as long
as their innovative fervor continues: once something does get into the
standard Python library &c, it won't and shouldn't develop very fast,
nor at all freely, due to the tiranny of backwards compatibility, cross
platform support, and the huge increase in maintenance/support efforts
that comes when something suddenly becomes much more widespread and
widely used than it previously used to be. Enhancements in library
organization and functionality, fixing typos in the docs, or deciding
whether and how to work around some platform's quirks, are definitely
less glamorous than inventing new grand unification projects, but
nevertheless this kinds of things IS by far the vastest part of the work
in a large and mature open-source project.

Wonderfully innovative projects, *OUT* of the core language/library, are
very abundant. Come to PyCon in March and you'll probably hear several
eye-opening, possibly mind-boggling talks about such things as the type
inferencing and optimizations of the pypy project, or Enthought's
breathtaking Traits and Envisage technologies -- all "infrastructure",
btw, no language changes involved. It's perfectly fit and proper that
such work takes place exactly where it's taking place now. If and when
it matures and stabilizes, to the point of not needing any more
innovation but rather consolidation and spreading, _then_ some part of
it may be merged into the standard core. Many people contributing to
such innovative projects are also Python core committers, of course.
Alex

[Istvan Albert]

Doug Holton wrote:

application is so important that I expect Python 3000 will have
optional type declarations integrated into the argument list."

I think that *optional* part of the "optional type declaration"
is a myth.

It may be optional in the sense that the language will
accept missing declarations but as soon as the feature
is available it will become "mandatory" to use it
(peer pressure, workplace practices).

Istvan.

[Aahz]

In article <11**********************@f14g2000cwb.googlegroups .com>,
<mi***************@gmail.com> wrote:

Aahz:

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.
Here is the link you forgot to post ;-)

http://www.python.org/psf/grants/

Didn't forget, was lazy and short of time.
The one about the docs seems more about teaching scientists how to use
Python.

True, but that's still an expansion of Python's usability as opposed to
changing the core language.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing." --Alan Perlis

[Bulba!]

On Tue, 4 Jan 2005 11:15:54 +0100, al*****@yahoo.com (Alex Martelli)
wrote:

Also, you keep talking about "the core python team" on the basis, it
would appear, of reading one document by Guido. Have you bothered doing
a MINIMUM of homework, such as, looking at
http://www.amk.ca/diary/archives/cat_python.html
and specifically AMK's entry for September 30?

This complaint about "syntax cruft" is really weird, as while
browsing through the old and new docs I got the impression that
Python hasn't really changed so much as just added new, and
mostly well-chosen features. What's not to like in sets for
instance?!

However, I do have to concede that Python as environment
still has a way to go - not the language features are missing, but
better _standard_ IDE and debugger. E.g. Pythonwin debugger
sometimes simply dies on me, I have no idea why.

This is not to criticize the great work that you
guys are doing and the results of which we get FOR
FREE (something in principle I don't believe), but merely
to indicate that Python has grown and so did the
expectations. People tend to get spoilt: they expect to
find in a free product the gazillion of VS-like features. :-)
As we say here, "appetite tends to grow as you eat".

E.g. right now I would kill for a standard, built-in matrix
type that would be as flexible as lists and dictionaries are
in Python, so that I could slurp the whole CSV file or some
other table in one instruction into a matrix that could
accomodate data types likes strings and floats (just like
dictionaries do - just, say, declare, "column 1 of matrix
contains strings, and please convert the values in column 2
into floats"), and then easily do some fancy matrix
transformations.

Clean and expressive syntax plus flexibility of lists and
dictionaries are the main reasons I got into Python.

Where else could I do smth as neat as writing a
CSV header with:

DictWriterInstance.writerow(dict(zip(titles,titles )))

Note I didn't have to do any operations myself:
all that was necessary for me as a programmer was to
figure out how to connect the Lego pieces together.

We need more of this sort of expressive power in a
standard library and built-in types. This is the subconscious
power of attraction in Python I think. :-) I'm not a language
designer. I don't know how to get there. I just would love
to see more of that around.

To summarize, it's not the language that is would be
nice to develop further. Those are:

- more of the rich, flexible data types

- more extensive standard debugger

- possibly standard IDE with more features
that are typically found in commercial products

<now the evil me sits back, relaxes and watches
how properly motivated Alex and others get to work>

No, really, guys, great thanks for all that work.
--

Real world is perfectly indifferent to lies that
are the foundation of leftist "thinking".

[Dave Brueck]

Istvan Albert wrote:

Doug Holton wrote:

application is so important that I expect Python 3000 will have
optional type declarations integrated into the argument list."

I think that *optional* part of the "optional type declaration"
is a myth.

It may be optional in the sense that the language will
accept missing declarations but as soon as the feature
is available it will become "mandatory" to use it
(peer pressure, workplace practices).

That's my fear - type declarations could become one of the most abused language
features because they'd get used too often.

-Dave

[Roman Suzi]

On Tue, 4 Jan 2005, Dave Brueck wrote:

It may be optional in the sense that the language will
accept missing declarations but as soon as the feature
is available it will become "mandatory" to use it
(peer pressure, workplace practices).

What about generic programming coming into fashion anytime soon?
That's my fear - type declarations could become one of the most abused language
features because they'd get used too often.

-Dave

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

[Doug Holton]

Istvan Albert wrote:

Doug Holton wrote:

application is so important that I expect Python 3000 will have
optional type declarations integrated into the argument list."

I think that *optional* part of the "optional type declaration"
is a myth.

It may be optional in the sense that the language will
accept missing declarations but as soon as the feature
is available it will become "mandatory" to use it
(peer pressure, workplace practices).

I didn't write that, Guido did. I agree with you, and others who have
made the same point you made. I would have to think Guido is already
aware of this issue (keep python simple). I'm not sure what his
motivations are for wanting to add static typing to python, not that I'm
against it.

It doesn't matter a whole lot either way since Python 3000 is still
years away and you can already do static typing now with Pyrex or boo,
as well as many other things that people have requested for python from
little things like ++i to bigger features like multi-line anonymous
methods/closures.

[Dave Brueck]

Roman Suzi wrote:

On Tue, 4 Jan 2005, Dave Brueck wrote:

It may be optional in the sense that the language will
accept missing declarations but as soon as the feature
is available it will become "mandatory" to use it
(peer pressure, workplace practices).

What about generic programming coming into fashion anytime soon?

Roman, I think I've read every single thread in the past year or three wherein
you've brought up generic programming, and I think you'd do well to choose a new
term for the idea you're trying to convey.

The term "generic programming" is too... er... generic. :) As you know, Python
already includes a _lot_ of support for generic programming (a function that
iterates over a sequence can easily process a list, or a string, or a tuple as
input; a function that takes a file-like object can often work just as will with
a true file object or a cStringIO object; etc.). So when you bring up "generic
programming", it's too easy to dismiss the comment because (1) it's too vague
and (2) Python already does a lot of it.

So, what is your term for the type of generic programming that Python doesn't
yet support? Interfaces? Protocols? Adapters? Metatype hierarchies?

-Dave

[Roman Suzi]

On Tue, 4 Jan 2005, Dave Brueck wrote:

Roman Suzi wrote:

It may be optional in the sense that the language will
accept missing declarations but as soon as the feature
is available it will become "mandatory" to use it
(peer pressure, workplace practices).

What about generic programming coming into fashion anytime soon?

Roman, I think I've read every single thread in the past year or three wherein
you've brought up generic programming, and I think you'd do well to choose a new
term for the idea you're trying to convey.

IIRC, I did it only once: at fall 2004.
The term "generic programming" is too... er... generic. :)
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.
As you know, Python
already includes a _lot_ of support for generic programming (a function that
iterates over a sequence can easily process a list, or a string, or a tuple as
input; a function that takes a file-like object can often work just as will with
a true file object or a cStringIO object; etc.). So when you bring up "generic
programming", it's too easy to dismiss the comment because (1) it's too vague
and (2) Python already does a lot of it.

So, what is your term for the type of generic programming that Python doesn't
yet support? Interfaces? Protocols? Adapters? Metatype hierarchies?

Python could have honest support of concepts. Everything else will be
available with them.

That is the whole point that Python supports GP. It is only one step
to do concepts right (and GvR it seems want type-checking into Python 3.0
anyway), so support for concepts/concept checking is very logical,
isn't it?

Right now concepts in Python are things which experienced Python programmers
know from practise. Sometimes, they feel them unconsciously.
Concepts could be veryfied and this, for example, could prevent errors
like DB-API-complient module doesn't have some small, but necessary
to comply, attributes.

Standard concepts could be part of standard concept "metalibrary", along with
verification mechanisms (this could be done even on C++, why not in a candy
like Python?). So every programmer could verify that his/her class, created to
satisfy concept XYZ is (formally) such. Your example - cStringIO - does
it really satisfy concept of STRING? It does. Partially. Those "partially"
here and there could lead to madness.

Unit testing will be simplified too, because structural tests will be
built into concept-checking mechanism.

And BTW, are we really disputing? What do you propose instead? Old-fashioned
Pascal-like type definitions? Java-like interface/implementaion ...? IMHO it
could be a big mistake to play catch-up.
Sincerely yours, Roman Suzi
--
rn*@onego.ru =\= My AI powered by GNU/Linux RedHat 7.3

[Terry Reedy]

"Bulba!" <bu***@bulba.com> wrote in message

E.g. right now I would kill for a standard, built-in matrix
type
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.
that would be as flexible as lists and dictionaries are
in Python, so that I could slurp the whole CSV file or some
other table in one instruction into a matrix that could
accomodate data types likes strings and floats (just like
dictionaries do - just, say, declare, "column 1 of matrix
contains strings, and please convert the values in column 2
into floats"), and then easily do some fancy matrix
transformations.

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

Terry J. Reedy

[Ian Bicking]

Roman Suzi wrote:

The term "generic programming" is too... er... generic. :)

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.

As you know, Python
already includes a _lot_ of support for generic programming (a function that
iterates over a sequence can easily process a list, or a string, or a tuple as
input; a function that takes a file-like object can often work just as will with
a true file object or a cStringIO object; etc.). So when you bring up "generic
programming", it's too easy to dismiss the comment because (1) it's too vague
and (2) Python already does a lot of it.

So, what is your term for the type of generic programming that Python doesn't
yet support? Interfaces? Protocols? Adapters? Metatype hierarchies?

Python could have honest support of concepts. Everything else will be
available with them.

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.

--
Ian Bicking / ia**@colorstudy.com / http://blog.ianbicking.org

[Roman Suzi]

On Tue, 4 Jan 2005, Dave Brueck wrote:

What about generic programming coming into fashion anytime soon?

Roman, I think I've read every single thread in the past year or three
wherein you've brought up generic programming, and I think you'd do well to
choose a new term for the idea you're trying to convey.

Or, yes, and I forgot to mention that generic programming is much clearer idea
than OO programming, as it is not so vague. At least for me:
I still don't fully comprehend OOP (after N years of "studying" it!) and
understanding of GP came after just one book on the topic.
Sincerely yours, Roman Suzi
--
rn*@onego.ru =\= My AI powered by GNU/Linux RedHat 7.3

[holger krekel]

Hi Roman,

On Wed, Jan 05, 2005 at 00:44 +0300, Roman Suzi wrote:

Python could have honest support of concepts. Everything else will be
available with them.

That is the whole point that Python supports GP. It is only one step
to do concepts right (and GvR it seems want type-checking into Python 3.0
anyway), so support for concepts/concept checking is very logical,
isn't it?

As an innocent by-dropper into this thread:

a) do you know Armin Rigo's "semantic model" page dealing
with concepts?

http://arigo.tunes.org/semantic_models.html

b) do you have some concise definition of what you mean
by "concept"?

Myself, i appreciate the combination of testing and python's
flexibility so much that i don't long for type declarations,
at least not to the degree that would warrant syntax additions.

Now for interfaces, for me this references more a documentation issue
than a syntax one: I'd like to have a full-featured runtime browser
that allows to quickly navigate cross-referenced life python objects.
Back and forth in execution time, preferably. This probably requires
the interpreter to help, track and record more information (which is one
of the possibilities with PyPy). It doesn't neccessarily require any new
syntax though.

And I don't really see the point of adding interface
hierarchies to already large frameworks. To me this adds to -
what i call - "naming complexity", i.e. the number of names a
programmer needs to remember to deal with a library or
framework. For me, it's not really the syntax that is the
problem with interfaces in Zope3 or twisted, but the sheer
amount of names (each indicating certain concepts and
behaviours) i am confronted with.

Not sure why i am saying all this here
but have fun,

holger

[Dave Brueck]

Roman Suzi wrote:

The term "generic programming" is too... er... generic. :)

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.

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.
Python could have honest support of concepts. Everything else will be
available with them.
"Concepts" is a pretty generic term too! ;-) Do you mean concepts as defined
here: http://www.boost.org/more/generic_programming.html
?
And BTW, are we really disputing?

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.

-Dave

[Roman Suzi]

On Tue, 4 Jan 2005, Ian Bicking wrote:

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.
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/p...ener_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).

"Python could have honest support of Concepts (url)"

- 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
--
rn*@onego.ru =\= My AI powered by GNU/Linux RedHat 7.3

[Roman Suzi]

On Tue, 4 Jan 2005, Dave Brueck wrote:

Roman Suzi wrote:

The term "generic programming" is too... er... generic. :)

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

Python could have honest support of concepts. Everything else will be
available with them.

"Concepts" is a pretty generic term too! ;-) Do you mean concepts as defined
here: http://www.boost.org/more/generic_programming.html
?

Yes.

And BTW, are we really disputing?

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.

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
--
rn*@onego.ru =\= My AI powered by GNU/Linux RedHat 7.3

[Robert Kern]

Terry Reedy wrote:

"Bulba!" <bu***@bulba.com> wrote in message

E.g. right now I would kill for a standard, built-in matrix
type

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.

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

--
Robert Kern
rk***@ucsd.edu

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

[Skip Montanaro]

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]

On Tue, 4 Jan 2005 19:19:32 -0600, Skip Montanaro <sk**@pobox.com> wrote:

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.

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: ca********@gmail.com
mail: ca********@yahoo.com

[Alex Martelli]

Dave Brueck <da**@pythonapocrypha.com> wrote:
...

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.

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]

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.

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]

On Wed, 5 Jan 2005, Alex Martelli wrote:

Dave Brueck <da**@pythonapocrypha.com> wrote:
...

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

That is why I was pretty sure people undestand me.
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.

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
--
rn*@onego.ru =\= My AI powered by GNU/Linux RedHat 7.3

[Alex Martelli]

Roman Suzi <rn*@onego.ru> wrote:

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.

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!]

On Wed, 5 Jan 2005 07:37:25 -0600, Skip Montanaro <sk**@pobox.com>
wrote:

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.

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.

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

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

or

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

or

..>>> table1.union(table2 [,drop_missing_columns |
,fill_missing_with_None])

or

..>>> common = table1.intersection(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.complement(complement_function) # where
complement function could be anything, like (!cellvalue) or
string.upper; that obviously would run the complement_function
on every cell in table

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

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

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]

Bulba! wrote:

On Wed, 5 Jan 2005 07:37:25 -0600, Skip Montanaro <sk**@pobox.com>
wrote: I've never needed numeric stuff either. I just need to do things like:

.>>> table.sort(column_name) # that obviously would sort rows of table
by the values of column column_name
[snip for brevity]
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?

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.

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.

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?

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
rk***@ucsd.edu

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

[Steve Holden]

Aahz wrote:

In article <11**********************@c13g2000cwb.googlegroups .com>,
<mi***************@gmail.com> wrote:

Maybe a PSF grant would help? I guess this has been considered ...

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.

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 [phone] [phone]

[Bulba!]

On Wed, 05 Jan 2005 17:25:08 -0800, Robert Kern <rk***@ucsd.edu>
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.

[Jarek Zgoda]

Iwan van der Kleyn wrote:

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.

I saw this once somewhere:

http://groups.google.com/groups?selm...ru.matavnet.hu

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

[Robert Kern]

Bulba! wrote:

On Wed, 05 Jan 2005 17:25:08 -0800, Robert Kern <rk***@ucsd.edu>
wrote:

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.

http://stsdas.stsci.edu/numarray/num...y.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
rk***@ucsd.edu

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