Python evolution: Unease

[Hans Nowak]

Re: Python evolution: Unease

Alex Martelli wrote:[color=blue]
> Iwan van der Kleyn <none@none.ne t> wrote:
>
>[color=green]
>>to be determine the way foreward for Python: more features, increased
>>complexity, less dynamism. Lots of syntax crud, without addressing the[/color]
>
>
> 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...[/color]

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]

Re: Python evolution: Unease

Iwan van der Kleyn <none@none.ne t> wrote:
...[color=blue]
> 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.[/color]

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]

Re: Python evolution: Unease

Doug Holton wrote:
[color=blue]
> application is so important that I expect Python 3000 will have
> optional type declarations integrated into the argument list."[/color]

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]

Re: Python evolution: Unease

In article <1104852554.684 821.297400@f14g 2000cwb.googleg roups.com>,
<michele.simion ato@gmail.com> wrote:[color=blue]
>Aahz:[color=green]
>>
>> 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]
>
>Here is the link you forgot to post ;-)
>
>http://www.python.org/psf/grants/[/color]

Didn't forget, was lazy and short of time.
[color=blue]
>The one about the docs seems more about teaching scientists how to use
>Python.[/color]

True, but that's still an expansion of Python's usability as opposed to
changing the core language.
--
Aahz (aahz@pythoncra ft.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!]

Re: Python evolution: Unease

On Tue, 4 Jan 2005 11:15:54 +0100, aleaxit@yahoo.c om (Alex Martelli)
wrote:
[color=blue]
>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?[/color]

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:

DictWriterInsta nce.writerow(di ct(zip(titles,t itles)))

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]

Re: Python evolution: Unease

Istvan Albert wrote:[color=blue]
> Doug Holton wrote:
>[color=green]
>> application is so important that I expect Python 3000 will have
>> optional type declarations integrated into the argument list."[/color]
>
>
> 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).[/color]

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]

Re: Python evolution: Unease

On Tue, 4 Jan 2005, Dave Brueck wrote:
[color=blue][color=green]
>> 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).[/color][/color]

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

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

[Doug Holton]

Re: Python evolution: Unease

Istvan Albert wrote:[color=blue]
> Doug Holton wrote:
>[color=green]
>> application is so important that I expect Python 3000 will have
>> optional type declarations integrated into the argument list."[/color]
>
>
> 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).[/color]

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]

Re: Python evolution: Unease

Roman Suzi wrote:[color=blue]
> On Tue, 4 Jan 2005, Dave Brueck wrote:
>
>[color=green][color=darkred]
>>>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).[/color][/color]
>
>
> What about generic programming coming into fashion anytime soon?[/color]

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]

Re: Python evolution: Unease

On Tue, 4 Jan 2005, Dave Brueck wrote:
[color=blue]
>Roman Suzi wrote:[color=green][color=darkred]
>>>>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).[/color]
>>
>>
>> What about generic programming coming into fashion anytime soon?[/color]
>
>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.[/color]

IIRC, I did it only once: at fall 2004.
[color=blue]
>The term "generic programming" is too... er... generic. :)[/color]

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

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 "metalibrar y", 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
--
rnd@onego.ru =\= My AI powered by GNU/Linux RedHat 7.3

[Terry Reedy]

Re: Python evolution: Unease


"Bulba!" <bulba@bulba.co m> wrote in message[color=blue]
> 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=blue]
> 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 .[/color]

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]

Re: Python evolution: Unease

Roman Suzi wrote:[color=blue][color=green]
>>The term "generic programming" is too... er... generic. :)[/color]
>
>
> 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=green]
>>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?[/color]
>
>
> Python could have honest support of concepts. Everything else will be
> available with them.[/color]

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 / ianb@colorstudy .com / http://blog.ianbicking.org

[Roman Suzi]

Re: Python evolution: Unease

On Tue, 4 Jan 2005, Dave Brueck wrote:
[color=blue][color=green]
>> What about generic programming coming into fashion anytime soon?[/color][/color]
[color=blue]
>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.[/color]

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

[holger krekel]

Re: Python evolution: Unease

Hi Roman,

On Wed, Jan 05, 2005 at 00:44 +0300, Roman Suzi wrote:[color=blue]
> 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?[/color]

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]

Re: Python evolution: Unease

Roman Suzi wrote:[color=blue][color=green]
>>The term "generic programming" is too... er... generic. :)[/color]
>
>
> 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=blue]
> 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=blue]
> And BTW, are we really disputing?[/color]

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