PEP scepticism

4 views
Skip to first unread message

Bernhard Reiter

unread,
Jun 28, 2001, 10:47:19 AM6/28/01
to
This a general warning against the second system syndrom in Python.

Maybe I am a hypocritical sceptic, but I have the impression that
some feeping creatureism is introduced into Python.
This might reduce the main advantage of Python to be clear and easy
and mostly have one good formulation on how to express what you want
to program in a structured way.

Examples are:
- augmented Assigments
- Lists comprehensions
- Simple Generators

To me it looks like these contructs do not add capabilities to
python which were missing. They seems to be rare cases in which I
prefer that the programmer got to have the overview anyway and
should use a longer version which is more explicit and explains more
about what is actually being done. The new syntatic additions still
require that the programmer has a full understanding about what is going on.
On the other the sum of language constructs is growing and harder to
understand as a complete system.

Please to not respond giving me the very good reasons on why these
features I have given as examples have been added or will be added
to python. I know that the reasons are well worked out and make sense.
You can easily convince me as I have to admit that I do not have the
time to follow all the arguments and work out my opinion.
On the other hand this is excatly the danger I want to warn you about.
It is a social reason for being careful:

Participation in the PEP debates about Python-enchancements
requires a certain level of knowledge and interest
about computer language design.

It is most likely that the participants
do understand complicated language constructs easily and
are python wizards. They might just not see how the addition
of syntatic sugar will lead to a higher learning curve for the masses.

(And we are missing the ability to make usability tests for these
kind of features because it is very hard to show and would require
tests with many programmers over long test periods.)

Mainly as a python user I urge you to take this into consideration.

Bernhard
ps.: I have similiar thoughts about some recent strategic
development ideas for Zope. Python and Zope both have 2.x version
number, please fight the 2nd system syndrom. :)

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)

James Logajan

unread,
Jun 28, 2001, 12:22:50 PM6/28/01
to
Bernhard Reiter wrote:
>
> This a general warning against the second system syndrom in Python.
[ Elided. ]

Thank you, Bernhard. I agree with your unease.

Roman Suzi

unread,
Jun 28, 2001, 12:57:56 PM6/28/01
to Bernhard Reiter, pytho...@python.org
On 28 Jun 2001, Bernhard Reiter wrote:

>This a general warning against the second system syndrom in Python.
>Maybe I am a hypocritical sceptic, but I have the impression that
>some feeping creatureism is introduced into Python.
>This might reduce the main advantage of Python to be clear and easy
>and mostly have one good formulation on how to express what you want
>to program in a structured way.
>
>Examples are:
> - augmented Assigments
> - Lists comprehensions
> - Simple Generators

I can't see these as bad things which make Python worse!
If you do not want to use them - please do so.

I do like functional style of Python and list comprehensions
make the approach more powerful and clear.
Augmented assigments are so common that their lack in Python
looked like a hole.

Generators make Python iteration facilities _much_ more robust without
sacrificing clarity for the users of such constructs.

>To me it looks like these contructs do not add capabilities to
>python which were missing. They seems to be rare cases in which I

It depends on the programmer. If you came from vanilla Pascal,
maybe you will avoid lot of things at first.

But programmers are lazy -- thus they use list comprehensions
and augmented =s.

>prefer that the programmer got to have the overview anyway and
>should use a longer version which is more explicit and explains more
>about what is actually being done.

There is limit after which more explanation is worse than less:

processed_list = []
for i in old_list:
processed_list.append(func(i))

adds nothing but noise, while:

processed_list = [func(i) for i in old_list]

makes it clear as day!

(I prefer map(), but this is personal)

>The new syntatic additions still
>require that the programmer has a full understanding about what is going on.
>On the other the sum of language constructs is growing and harder to
>understand as a complete system.

Language constructs aren't the pile of features. There is good logic
behind them, if you look with more attention.

>Please to not respond giving me the very good reasons on why these
>features I have given as examples have been added or will be added
>to python. I know that the reasons are well worked out and make sense.
>You can easily convince me as I have to admit that I do not have the
>time to follow all the arguments and work out my opinion.

Ok. Do not read then.

>On the other hand this is excatly the danger I want to warn you about.
>It is a social reason for being careful:
>
> Participation in the PEP debates about Python-enchancements
> requires a certain level of knowledge and interest
> about computer language design.

And intuition too.

>
>It is most likely that the participants
>do understand complicated language constructs easily and
>are python wizards. They might just not see how the addition
>of syntatic sugar will lead to a higher learning curve for the masses.

As I said, features of Python aren't illogical pile of things.
So, adding more features doesn't touch the mentioned curve.

>(And we are missing the ability to make usability tests for these
>kind of features because it is very hard to show and would require
>tests with many programmers over long test periods.)
>
>Mainly as a python user I urge you to take this into consideration.

As a python programmer, I think that Python must live, because it is live
language. Even latin has recent additions to it, which undoubtly lead to
"higher" curve.

Every language which is practical and useful changes over the time. If you
are dissatisfied with this, please fork Eternal Python project.

> Bernhard
>ps.: I have similiar thoughts about some recent strategic
>development ideas for Zope. Python and Zope both have 2.x version
>number, please fight the 2nd system syndrom. :)

I myself sometimes wish some things to be eternal. At least to
code eternal cybernetic soul and preserve it in a mausoleum ;-)

Sincerely yours, Roman Suzi
--
_/ Russia _/ Karelia _/ Petrozavodsk _/ r...@onego.ru _/
_/ Thursday, June 28, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "It is better to wear out than to rust out." _/


Steve Horne

unread,
Jun 28, 2001, 1:01:35 PM6/28/01
to
On 28 Jun 2001 14:47:19 GMT, bern...@intevation.de (Bernhard Reiter)
wrote:

>This a general warning against the second system syndrom in Python.

I think you may have a good point for the future, but I'm actually a
big fan of some of those recent additions to Python.

Although Python probably makes an excellent teaching language, I'd
imagine most Python programmers have used some other languages before.
Of the example changes you mentioned...

> - augmented Assigments

Extremely familiar to anyone with a C, C++ or Java background, and
something that I was annoyed to have to live without when I first used
Python. I don't remember ever finding the idea of += or -= operators
anything but completely natural, even when I first saw them. I'd
contest the use of % for mod (the meaning is not immediately obvious)
but += and -= are completely natural.

The augmented assignments beyond += and -= are simply extending the
same principle as far as possible - something Python has always done,
and which is a large part of its simplicity.

> - Lists comprehensions

Another large group of Python programmers have a background in
functional languages, and will immediately understand list
comprehensions. I can see how at first glance they might look strange,
but really they are just describing - rather than listing - the
required items. The second glance should be a revelation!

Functional languages provide a very useful and very simple approach to
many types of problem. The inclusion of functional features into
Python is one of its best attributes. Few other languages allow you to
switch paradigms to whatever suits your task. But without list
comprehensions, the functional features get pretty clunky.


I can understand the wish to only have one way to solve any problem,
but it really isn't that great an approach. If a task can be attempted
using two different approaches, then you have a choice - you don't
have to force the first approach to fit. I look forward to a day when
there are even more tools in the box. After all, have you ever met an
electrician who only owns a single screwdriver? - I think not. Doing a
good job means using the right tool for the job, not forcing a single
tool to do every job.


I first started using Python at version 1.4. The recent evolution of
Python has resulted in many of my commonly used scripts becoming much
more powerful and useful, yet smaller and much more readable - despite
the fact that I only get a chance to work on them at odd moments when
there is no rush.

If typical Python programs are simpler, more readable, yet at the same
time more useful and powerful than was possible in the past - all
without spending a lot of time in development - I don't think the time
has yet come when we need to worry about excess features.

--
Steve Horne
Home : st...@lurking.demon.co.uk
Work : s...@ttsoftware.co.uk

Bernhard Reiter

unread,
Jun 28, 2001, 1:31:53 PM6/28/01
to
In article <kklmjtkhk17011nkj...@4ax.com>,

Steve Horne <s...@ttsoftware.co.uk> writes:
> On 28 Jun 2001 14:47:19 GMT, bern...@intevation.de (Bernhard Reiter)
> wrote:
>
>>This a general warning against the second system syndrom in Python.
>
> I think you may have a good point for the future, but I'm actually a
> big fan of some of those recent additions to Python.

As I wrote in my post, I do not want to discuss the advantages or
disadvantages of single additions even though I have mentioned them.
I hope I can explain my cause without being specific.

> Extremely familiar to anyone with a C, C++ or Java background, and
> something that I was annoyed to have to live without when I first used
> Python.

I am not sure if this is good reasoning,
just because people know a feature from other languages might not
make it a good one (or we all end up with perl :) ).


> Another large group of Python programmers have a background in
> functional languages, and will immediately understand

In my experiences a lot of functional programming language features
are too complex and abstract for most people to really
add them to their active programming vocabulary.

> I can understand the wish to only have one way to solve any problem,
> but it really isn't that great an approach.

> have you ever met an


> electrician who only owns a single screwdriver? - I think not. Doing a
> good job means using the right tool for the job, not forcing a single
> tool to do every job.

Of course this is a matter of balance, I prefer a minimal set of tools
which gives me maxmimum power. There will always be some overlap of course.
Still one aim is to keep the number of tools small.

Some additions to python are of course badly needed.
Bernhard

Bernhard Reiter

unread,
Jun 28, 2001, 1:43:02 PM6/28/01
to
In article <mailman.993747643...@python.org>,

Roman Suzi <r...@onego.ru> writes:
> On 28 Jun 2001, Bernhard Reiter wrote:

>>This a general warning against the second system syndrom in Python.

As I wrote in my original post I do not want to actually discuss the
advantages or disadvantages of the examples given.
This already has been done. Hopefully I can explain my concern on a
more general level.

> If you do not want to use them - please do so.

This is no argument.
I will have to read code of other people which will force me to use them.
(Now don't tell me: Don't do this.)

>>To me it looks like these contructs do not add capabilities to
>>python which were missing. They seems to be rare cases in which I
>
> It depends on the programmer.

It is my hope that python gives more clarity to everybody.
Right now python already does this compared to other programming
languages.

> But programmers are lazy

Good variables and comments are essential for each program.
Nodoy should be to lazy to make a program more clear.


>>The new syntatic additions still
>>require that the programmer has a full understanding about what is going on.
>>On the other the sum of language constructs is growing and harder to
>>understand as a complete system.
>
> Language constructs aren't the pile of features. There is good logic
> behind them, if you look with more attention.

I know.

>>Mainly as a python user I urge you to take this into consideration.
>
> As a python programmer, I think that Python must live

I agree as a python programmer (which I meant by "python user" btw).
There are important additions (e.g. unicode) and the language
has to be maintained.

But as Dennis Ritchie said about the C99 standard commitee:
"I wish they had resisted more firmly."
http://www.itworld.com/Comp/3380/lw-12-ritchie/

Andrew Kuchling

unread,
Jun 28, 2001, 2:23:17 PM6/28/01
to
bern...@intevation.de (Bernhard Reiter) writes:
> I agree as a python programmer (which I meant by "python user" btw).
> There are important additions (e.g. unicode) and the language
> has to be maintained.

It's also a matter of where effort is expended for the most benefit.
The new features such as static scoping, list comprehensions, &c., are
nice to have and I'm pleased that the list of language shortcomings is
shrinking. But would I rather have had list comprehensions or a
catalog of all Python extensions similar to CPAN? I'd have much
preferred the latter, because it would make a greater improvement in
my programming life than, say, list comprehensions do. This doesn't
imply that list comprehensions don't improve my life at all (they do),
but

I've noticed that in online forums, people now rarely beat up on
Python for the language itself, except for the old reliable
indentation knee-jerk reaction. Instead people write about how
convenient CPAN makes it to find modules, or how useful the XML
modules are, or how EJB lets them write elaborate business systems. I
don't think improving Python the language will win new converts at
this point; improving the standard library, development environments,
or the documentation is more likely to bear fruit.

--amk

Gordon McMillan

unread,
Jun 28, 2001, 3:26:37 PM6/28/01
to
Bernhard Reiter wrote:

[snip]

>As I wrote in my post, I do not want to discuss the advantages or
>disadvantages of single additions even though I have mentioned them.
>I hope I can explain my cause without being specific.

But features are added to Python on a case-by-case basis. There is
no "let's do everything!" bonanza underway (PEPs get rejected, after
all). So there's no general case to argue (except, maybe "I like my
Python 1.5.2").

- Gordon

steven...@isomedia.com

unread,
Jun 28, 2001, 3:26:08 PM6/28/01
to pytho...@python.org
On Thu, Jun 28, 2001 at 08:57:56PM +0400, Roman Suzi wrote:
> On 28 Jun 2001, Bernhard Reiter wrote:
>
> >This a general warning against the second system syndrom in Python.
> >Maybe I am a hypocritical sceptic, but I have the impression that
> >some feeping creatureism is introduced into Python.
> >This might reduce the main advantage of Python to be clear and easy
> >and mostly have one good formulation on how to express what you want
> >to program in a structured way.
> >
> >Examples are:
> > - augmented Assigments
> > - Lists comprehensions
> > - Simple Generators
>
> I can't see these as bad things which make Python worse!
> If you do not want to use them - please do so.
>
>
---end quoted text---

FWIW - I totally agree with the original premise. If Python already
offers a reasonable way to do something I would vote for not adding an
alternative.

Keystroke reduction saves the original programmer time. But it costs
other people more time when they read the code. The more language
idioms that exist to support a particular need the more chance the
code reader will have to work harder to understand the code writer.

Manditory indentation policy was a brilliant choice, IMO, precisely
because it assured that one programmer's style would be readable to
another. The same applies to language constructs. The fewer choices
that are available the more likely it is that the code-reader will
understand the work of the code-writer.

Regards,
Steve

--

\_O< \_O< \_O<
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steve Cooper Redmond, WA

Andrew Dalke

unread,
Jun 28, 2001, 4:24:56 PM6/28/01
to
Jason F. McBrayer wrote:
>>>>>> "RS" == Roman Suzi <r...@onego.ru> writes:
>RS> There is limit after which more explanation is worse than less:
>
>RS> processed_list = []
>RS> for i in old_list:
>RS> processed_list.append(func(i))
>
>RS> adds nothing but noise, while:
>
>In this trivial case, probably not, but...

A month or so I posted an example where I explained why I liked
list comprehensions

http://mail.python.org/pipermail/python-list/2001-May/042951.html

It boils down to that this trivial case occurs very frequently,
so I put the three lines or so into a function. But I couldn't
think of a good function name. By using list comprehensions
I traded off some strange syntax for the ability to describe
everything in one place - more legibility in the long run.

So my coding recommendation is to use list comprehensions solely
for that trivial case, and use functions for more complex ones.

Andrew

Roman Suzi

unread,
Jun 28, 2001, 3:08:52 PM6/28/01
to pytho...@python.org
On 28 Jun 2001, Andrew Kuchling wrote:

>bern...@intevation.de (Bernhard Reiter) writes:
>> I agree as a python programmer (which I meant by "python user" btw).
>> There are important additions (e.g. unicode) and the language
>> has to be maintained.
>

>I've noticed that in online forums, people now rarely beat up on
>Python for the language itself, except for the old reliable
>indentation knee-jerk reaction. Instead people write about how
>convenient CPAN makes it to find modules, or how useful the XML
>modules are, or how EJB lets them write elaborate business systems. I
>don't think improving Python the language will win new converts at
>this point; improving the standard library, development environments,
>or the documentation is more likely to bear fruit.

I think improving Python itself is also improving what you've
just mentioned.

Of course, libraries are important and they are being developed. I also
think that changes in Python were caused be need of practice and not some
aestetism of GvR.

Andrew Kuchling

unread,
Jun 28, 2001, 5:49:35 PM6/28/01
to
Roman Suzi <r...@onego.ru> writes:
> I think improving Python itself is also improving what you've
> just mentioned.

No it isn't. Adding language features does not improve the confusing
and incomplete MIME modules currently in the standard library. It
does not remove the outdated demo programs from the distribution. It
does not add more documentation. It does not bring us any closer to
having a module catalog. It does not increase Python's visibility
outside of the Python community. My point is that users are not
currently saying "Gosh, Python doesn't have generators, so I won't use
it." They're saying "Wow, there's a lot of useful libraries for Java;
I'd better use it to be able to use them."

--amk

Paul Prescod

unread,
Jun 28, 2001, 6:32:23 PM6/28/01
to bern...@intevation.de, pytho...@python.org
It annoys me when people equate the PEP process with the adding of
features. Features were added before there was a PEP process. Features
have been added with out a PEP even since the process existed. The PEP
process also handles things like library upgrades and distutils
improvements. If you think Python is changing to quickly, that's fine.
But what does it have to do with PEPs?
--
Take a recipe. Leave a recipe.
Python Cookbook! http://www.ActiveState.com/pythoncookbook

Barry A. Warsaw

unread,
Jun 29, 2001, 12:26:14 AM6/29/01
to pytho...@python.org

>>>>> "PP" == Paul Prescod <pa...@ActiveState.com> writes:

PP> It annoys me when people equate the PEP process with the
PP> adding of features. Features were added before there was a PEP
PP> process. Features have been added with out a PEP even since
PP> the process existed. The PEP process also handles things like
PP> library upgrades and distutils improvements. If you think
PP> Python is changing to quickly, that's fine. But what does it
PP> have to do with PEPs?

The other purpose for PEPs -- IMO more important and often overlooked
-- is to provide a concrete historical record for decisions made about
the language, its implementations, and its environments. Python's
been around a long time, and as Tim is fond of saying, there are
almost no new feature suggestions that haven't been brought up many
times before. The PEP is now the place which records the decision
making process and in that, it serves a very useful function, even
(and it some cases more) for when the idea is rejected as when it's
accepted.

That's quite apart from how the PEP process has influenced the pace of
changes to Python. My own personal opinion is that the pace hasn't
really changed much over time. What /has/ changed is the size and
scope of Python's user base, and the relatively smaller advancement in
elegance or power that current changes make, compared to what you can
already do in the language.

That's not to say that Andrew doesn't make a very important point. In
one concrete example though, I know that with my own attempt at
improving Python's MIME offerings, I've found that features like
extended print have definitely helped the elegance of the library. If
I was willing to target Python 2.2 then iterators and generators would
as well (I think ;).

I have a nagging feeling that `creeping featurism' is like pork-barrel
politics. In one breath people will decry the special interests that
they don't like or don't care about, while in the next, ask for their
own pet project to be funded. It was quite funny to see the same
effect at work at IPC9. Lots of hands went up when Guido took a poll
on whether the pace of change was too fast. But as the session
continued, there were certainly no shortages of new features
suggested!

-Barry

Tim Peters

unread,
Jun 29, 2001, 12:25:11 AM6/29/01
to pytho...@python.org
[Bernhard Reiter]

> This a general warning against the second system syndrom in Python.
>
> Maybe I am a hypocritical sceptic, but I have the impression that
> some feeping creatureism is introduced into Python.

These are different issues to me: while feature bloat is a symptom of
Second System Syndrome, the latter goes much deeper than *just* the former.

> This might reduce the main advantage of Python to be clear and easy
> and mostly have one good formulation on how to express what you want
> to program in a structured way.

While I expect everyone would agree those are advantages of Python, I doubt
there's consensus that those 4 advantages are "the main" <wink> advantage.
Language design is more complex than that.

> Examples are:
> - augmented Assigments
> - Lists comprehensions
> - Simple Generators

Two of those were widely debated over the course of a decade, and augmented
assignments in particular were "approved" in the mid-90's, just awaiting
someone to implement them. They aren't legitimate examples of Second System
Syndrome, in part because of that: they aren't examples of the system
designer taking large leaps of faith on untested and unreviewed ideas.

They're features you may or may not like, but they're *just* features, and
isolated features at that.

If you want a SSS *prospect* to worry about, try PEPs 252 through 254
inclusive: rethinking the type/class system from scratch is a radical
change affecting every corner of the language. I'm more uncomfortable about
that than about all preceding changes combined, and real-life experience
with "the metaclass hook/hack" is too spotty to make a case that we really
know the ultimate effects of these changes. Push ahead anyway, and *that's*
SSS material -- possibly. Nothing else even gets close to it.

> ...


> On the other the sum of language constructs is growing and harder to
> understand as a complete system.

Not even Scheme stayed *braindead* austere forever, you know <wink>.

BTW, I agree with Paul that this has nothing to do with the PEP process. In
fact, the decisions to add the three features you named were made before
PEPs existed. What the PEPs did in these cases was gather and organize the
(sometimes ancient) c.l.py threads in which they were first debated.

python-today-is-still-guido's-first-python-design-ly y'rs - tim


Tim Peters

unread,
Jun 29, 2001, 1:09:37 AM6/29/01
to pytho...@python.org
[Andrew Kuchling]
> ...

> But would I rather have had list comprehensions or a catalog of all
> Python extensions similar to CPAN? I'd have much preferred the latter,
> because it would make a greater improvement in my programming life
> than, say, list comprehensions do. This doesn't imply that list
> comprehensions don't improve my life at all (they do) ...

So what do you do about the curious disconnect between supply and demand in
Open Source projects? You got list comprehensions because Greg Ewing (and
later Thomas Wouters) generously volunteered to supply them, not because,
e.g., Guido *decided* they were more important at the time than was a CPAN
workalike. The Python distribution is the sum of what Python users have
contributed. That's why, e.g., why we ship tabnanny.py instead of a GUI
builder.

But note that "instead of" is dead wrong, and so possibly <wink> misleading:
nothing I ever worked on took away from the time I would have spent on a GUI
builder instead, because I never would have worked on the latter regardless
(it's not my thing -- no interest, and no competence). A similar dynamic
holds in case after case. Even if *everyone* wants some gimmick X, it won't
happen unless volunteers work on X. Speaking of which, we really need a web
app to match up Python projects with potential volunteers <wink>.

things-will-be-different-when-microsoft-owns-python-ly y'rs - clipitimbot


Bernhard Reiter

unread,
Jun 29, 2001, 4:52:21 AM6/29/01
to
In article <mailman.993788863...@python.org>,

ba...@digicool.com (Barry A. Warsaw) writes:
>>>>>> "PP" == Paul Prescod <pa...@ActiveState.com> writes:
>
> PP> It annoys me when people equate the PEP process with the
> PP> adding of features.

True. In general I like the PEP process.
As Barry continues to explain its value as a documentation of the
debate and the decisions is also high.

My general warning has something do to with the process though,
as a non-technical reason exist why people participating in the
processes will have higher chances to vote for inclusing of features,
because being exceptional python programmers.

I want the people participating to aware of this situation so they
can have it in the back of their mind and be more conservative about
some feature request namely complicated syntactic sugar.

> The other purpose for PEPs -- IMO more important and often overlooked
> -- is to provide a concrete historical record for decisions made

> I have a nagging feeling that `creeping featurism' is like pork-barrel


> politics. In one breath people will decry the special interests that
> they don't like or don't care about, while in the next, ask for their
> own pet project to be funded.

My motivation to raise the issue came after discussing my unprecise
feeling about this with Bernhard Herzog.
I track python language development for quite a bit of time and
generally we all do a good job. However I can't help that I feel we
should resist a bit more against feature additions which does not
mean there should not be any.

Bernhard

Bernhard Reiter

unread,
Jun 29, 2001, 5:04:44 AM6/29/01
to
In article <mailman.993788804...@python.org>,

"Tim Peters" <tim...@home.com> writes:
> [Bernhard Reiter]
>> This a general warning against the second system syndrom in Python.
>>
>> Maybe I am a hypocritical sceptic, but I have the impression that
>> some feeping creatureism is introduced into Python.
>
> These are different issues to me: while feature bloat is a symptom of
> Second System Syndrome, the latter goes much deeper than *just* the former.

Agreed. It is good to see that you are aware of the problem (as expected).
Take my voice on the stack of people that think we should be even
more conservative about the additions.

>> This might reduce the main advantage of Python to be clear and easy
>> and mostly have one good formulation on how to express what you want
>> to program in a structured way.
>
> While I expect everyone would agree those are advantages of Python, I doubt
> there's consensus that those 4 advantages are "the main" <wink> advantage.
> Language design is more complex than that.

Rethinking this I still think this are _the main_ advantages
compared to other languages. What do you think the main advantages
are? :)

>> Examples are:
>> - augmented Assigments
>> - Lists comprehensions
>> - Simple Generators
>
> Two of those were widely debated over the course of a decade,

I know. I've participated once IIRC.

> They aren't legitimate examples of Second System
> Syndrome, in part because of that: they aren't examples of the system
> designer taking large leaps of faith on untested and unreviewed ideas.

Agreed.
However not having augmented assignment made me think about it and
the clarity you gain when writing it more explicitly.

> If you want a SSS *prospect* to worry about, try PEPs 252 through 254

>> On the other the sum of language constructs is growing and harder to
>> understand as a complete system.
>
> Not even Scheme stayed *braindead* austere forever, you know <wink>.

That's why fresh, small languages are designed sometimes... <wink>

> BTW, I agree with Paul that this has nothing to do with the PEP process.

See my response to him and Barry.
Maybe my subject of the original was suboptimal, but there is some connection
and I had to start expression what my concern is somewhere.

Guido van Rossum

unread,
Jun 29, 2001, 8:26:22 AM6/29/01
to
Andrew Kuchling <akuc...@mems-exchange.org> writes:

> It's also a matter of where effort is expended for the most benefit.
> The new features such as static scoping, list comprehensions, &c., are
> nice to have and I'm pleased that the list of language shortcomings is
> shrinking. But would I rather have had list comprehensions or a
> catalog of all Python extensions similar to CPAN? I'd have much
> preferred the latter, because it would make a greater improvement in
> my programming life than, say, list comprehensions do. This doesn't
> imply that list comprehensions don't improve my life at all (they do),
> but
>
> I've noticed that in online forums, people now rarely beat up on
> Python for the language itself, except for the old reliable
> indentation knee-jerk reaction. Instead people write about how
> convenient CPAN makes it to find modules, or how useful the XML
> modules are, or how EJB lets them write elaborate business systems. I
> don't think improving Python the language will win new converts at
> this point; improving the standard library, development environments,
> or the documentation is more likely to bear fruit.

Thanks, Andrew. That was a very good point you made in an otherwise
"same-old-same-old" thread.

I'm guilty of this myself: by nature, I'm more interested in making
the language better than in adding convenience to finding 3rd party
modules. (I did once have an interest in creating a better IDE, but
that interest has waned now there are so many commercial offerings.)

How is the catalog-sig doing, by the way?

--Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum

unread,
Jun 29, 2001, 8:32:26 AM6/29/01
to
Andrew Kuchling <akuc...@mems-exchange.org> writes:

> No it isn't. Adding language features does not improve the confusing
> and incomplete MIME modules currently in the standard library.

Barry Warsaw is working on mimelib (http://mimelib.sourceforge.net/)
and I expect that this will be added to the 2.2 CVS tree soon!

> It does not remove the outdated demo programs from the distribution.

Maybe, in the light of the successful PEP 260, someone should write a
PEP about removing deadwood from the demos? I'm all for it! (Also
more ancient library modules can be deprecated, like all the irix5
cruft. Again, I need help here!

> It does not add more documentation.

I don't think that's an area where Python is currently particularly
lacking. Fred has done a great job. (BTW, when are you going to add
all the new Python books to the Python bookstore? :-)

> It does not bring us any closer to having a module catalog. It does
> not increase Python's visibility outside of the Python community.

We're working on that. I hope that the Python events at the O'Reilly
conference next month and LinuxWorld in August will reach a lot of
outsiders.

> My point is that users are not currently saying "Gosh, Python
> doesn't have generators, so I won't use it." They're saying "Wow,
> there's a lot of useful libraries for Java; I'd better use it to be
> able to use them."

Point taken.

Alex Martelli

unread,
Jun 29, 2001, 8:43:47 AM6/29/01
to
"Bernhard Reiter" <bern...@intevation.de> wrote in message
news:9hfqb5$dsllb$3...@ID-89274.news.dfncis.de...
...

> But as Dennis Ritchie said about the C99 standard commitee:
> "I wish they had resisted more firmly."
> http://www.itworld.com/Comp/3380/lw-12-ritchie/

...but as Ritchie ALSO said in the very same interview...:
"""
What is changing is that higher-level languages are becoming
much more important as the number of computer-involved people
increases. Things that began as neat but small tools, like Perl
or Python, say, are suddenly more central in the whole scheme
of things. ... higher-level ways of instructing machines will
continue to occupy more of the center of the stage.
"""

*Higher-level ways of instructing machines* include list
comprehensions as compared to fully-written-out-loops,
generators as compared to laborious saving of state, etc.

I read Ritchie as saying he wished C could remain C (though
he does admit that some evolution is absolutely inevitable,
and refuses to second-guess the C99's committee work, having
chosen not to participate in it), but also that, while C has
its niches (and they'll remain!), the "higher-level" way of
like *has JUST begun* and has a way to go towards "occupying
more of the center of the stage"

Simplicity is an important Pythonic value, as it was (and to
some extent still is) for C (albeit for different reasons
and with different slant) -- Python must not become Perl, just
like C must not become C++. As Python *sheds* unused features
(xrange's deadweight parts, etc -- and maybe one day those
parts of the standard library that are little-used and specific
to peculiar platforms), it can hardly be accused of not keeping
simplicity firmly in its sights.

But that simplicity must not be pursued at the cost of "the
higher-level ways" of doing things. Now *THAT* would be
language suicide by inaction!-)


Alex

Chris Gonnerman

unread,
Jun 29, 2001, 9:07:15 AM6/29/01
to pytho...@python.org
----- Original Message -----
From: "Guido van Rossum" <gu...@python.org>
> Andrew Kuchling <akuc...@mems-exchange.org> writes:
>
> > No it isn't. Adding language features does not improve the confusing
> > and incomplete MIME modules currently in the standard library.
>
> Barry Warsaw is working on mimelib (http://mimelib.sourceforge.net/)
> and I expect that this will be added to the 2.2 CVS tree soon!

That's good news!

<hack hack>

> > My point is that users are not currently saying "Gosh, Python
> > doesn't have generators, so I won't use it." They're saying "Wow,
> > there's a lot of useful libraries for Java; I'd better use it to be
> > able to use them."
>
> Point taken.

I'll second this motion. List comprehensions, iterators, generators, etc.
are all cool, but frankly I stopped *needing* new language features around
1.5.2 to 2.0, and most of the Python I write will run in 1.5.2 just fine.

On the other hand, I'm always happy to find a Python module to do something
for me so I don't have to, and I spend considerable time looking for them...

Aahz Maruch

unread,
Jun 29, 2001, 10:19:02 AM6/29/01
to
In article <9hhfk5$e50ak$1...@ID-89274.news.dfncis.de>,

Bernhard Reiter <bern...@intevation.de> wrote:
>
>My general warning has something do to with the process though,
>as a non-technical reason exist why people participating in the
>processes will have higher chances to vote for inclusing of features,
>because being exceptional python programmers.

I am hardly an exceptional Python programmer, or even an exceptional
programmer in any language. I'm not even sure I qualify as "very good"
(I *am* sure I qualify as "good"). To the extent that Guido pays
attention to me, it's because I've been participating and have done a
small amount of good work. That's it. That is quite literally all it
takes.

Well, no, I take that back. I think I'm a pretty good writer, too, and
I express myself clearly. The ability to communicate is highly prized in
the Python community, and I believe that's one of the major reasons for
Python's success.
--
--- Aahz <*> (Copyright 2001 by aa...@pobox.com)

Hugs and backrubs -- I break Rule 6 http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista

"Nothing fails like prayer" --bumper snicker

Andrew Kuchling

unread,
Jun 29, 2001, 10:18:19 AM6/29/01
to
"Tim Peters" <tim...@home.com> writes:
> So what do you do about the curious disconnect between supply and demand in
> Open Source projects? You got list comprehensions because Greg Ewing (and

Beats me. This is nothing new, in that interesting tasks get worked
on, and boring ones don't. I haven't updated the bookstore in a
while, or tried to kick the catalog-sig into life, or released various
bits of software sitting on my disk, because such tasks would be
pretty boring, and I have more entertaining possibilities open to me.
Greg Ward moved back to Montreal, and now does practically no hacking
or writing in his spare time at all. Unfortunately, practically
*everyone* considers these tasks dull.

--amk (www.amk.ca)
"For interrogation? Good, I enjoy interrogations."
"Yes, you look the type."
-- General Raven and the Doctor, in "Genesis of the Daleks"

phil hunt

unread,
Jun 29, 2001, 9:28:58 AM6/29/01
to
On Fri, 29 Jun 2001 00:26:14 -0400, Barry A. Warsaw <ba...@digicool.com> wrote:
>The other purpose for PEPs -- IMO more important and often overlooked
>-- is to provide a concrete historical record for decisions made about
>the language, its implementations, and its environments. Python's
>been around a long time, and as Tim is fond of saying, there are
>almost no new feature suggestions that haven't been brought up many
>times before.

Is there a PEP for multi-line comments?

Or one for making ``pass'' optional?

>I have a nagging feeling that `creeping featurism' is like pork-barrel
>politics. In one breath people will decry the special interests that
>they don't like or don't care about, while in the next, ask for their
>own pet project to be funded.

That could be a problem, yes.


--
==== Philip Hunt == ph...@comuno.freeserve.co.uk ====
Want to stop global warming? Do you support the Kyoto
Treaty? Then boycott Esso (ExxonMobil in the USA).
See www.stopesso.com for details.

phil hunt

unread,
Jun 29, 2001, 9:34:51 AM6/29/01
to
On 28 Jun 2001 14:23:17 -0400, Andrew Kuchling <akuc...@mems-exchange.org> wrote:
>
>I've noticed that in online forums, people now rarely beat up on
>Python for the language itself, except for the old reliable
>indentation knee-jerk reaction. Instead people write about how
>convenient CPAN makes it to find modules, or how useful the XML
>modules are, or how EJB lets them write elaborate business systems. I
>don't think improving Python the language will win new converts at
>this point; improving the standard library, development environments,
>or the documentation is more likely to bear fruit.

Good point.

phil hunt

unread,
Jun 29, 2001, 9:26:35 AM6/29/01
to
On Thu, 28 Jun 2001 12:26:08 -0700, steven...@isomedia.com <steven...@isomedia.com> wrote:
>
>Keystroke reduction saves the original programmer time.

True.

> But it costs
>other people more time when they read the code.

Really?

Is this:

self.total[player] += s

any harder to understand than this:

self.total[player] = self.total[player] + s

I don't think so.

Neil Schemenauer

unread,
Jun 29, 2001, 10:44:43 AM6/29/01
to pytho...@python.org
Guido van Rossum wrote:
> I'm guilty of this myself: by nature, I'm more interested in making
> the language better than in adding convenience to finding 3rd party
> modules.

I think many people on the python-dev list are guilty. We should
concentrate more on improving the standard library. IMHO, there is lots
of room there for improvement.

Neil

Roman Suzi

unread,
Jun 29, 2001, 11:02:36 AM6/29/01
to pytho...@python.org

Is there a formal TODO list of the libraries and respective priorities?

For example, I think that some sort of standard GUI could help Python to
fight Java with it's Swing/AWT...

It could be also interesting to have time module as powerful as mxDateTime
in standard library. And so on.


Sincerely yours, Roman A.Suzi
--
- Petrozavodsk - Karelia - Russia - mailto:r...@onego.ru -


Barry A. Warsaw

unread,
Jun 29, 2001, 11:50:13 AM6/29/01
to phil hunt, pytho...@python.org

>>>>> "ph" == phil hunt <ph...@comuno.freeserve.co.uk> writes:

ph> Is there a PEP for multi-line comments?

ph> Or one for making ``pass'' optional?

Nope, so obviously no one thought there was enough controversy or need
in either of these two areas.

The only requirements for PEP authors is that you have some ability to
write well, can communicate your ideas clearly and succinctly, and
that you be open to criticism and discussion from the community. IOW,
almost /anybody/ can be a PEP author.

If you think multiline comments or optional-pass are subjects worthy
of PEP-hood, follow the guidelines in PEP 1 and submit your own
offerings!

-Barry

Guido van Rossum

unread,
Jun 29, 2001, 12:18:10 PM6/29/01
to
Roman Suzi <r...@onego.ru> writes:

> Is there a formal TODO list of the libraries and respective priorities?

No, although there's a PEP for small feature requests (PEP 42).

If you want to start making a list of missing libraries and submit a
PEP, please do! I'm sure many people will want to contribute.

> For example, I think that some sort of standard GUI could help Python to
> fight Java with it's Swing/AWT...

This was tried many times -- there was even a GUI-sig with this goal.
Nothing ever came to fruition. The problem is that designing and
implementing a standard GUI that can compete with the existing
offerings it an enormous amount of work, and folks always ran out of
steam before they were even done with the requirements gathering.

The folks who produced wrappers for existing GUI toolkits available
for C or C++ were much more successful, so that's what we got. Python
has more GUI choices than Java, and that's a good thing.

> It could be also interesting to have time module as powerful as mxDateTime
> in standard library. And so on.

Well, propose one. But what exactly is the point of adding it to the
standard library when you can get mxDateTime if you need it? I'd say
your energy is better spent on reviving the catalog-sig (Python's
CPAN-like effort, which needs new energy!)

Mike C. Fletcher

unread,
Jun 29, 2001, 1:46:28 PM6/29/01
to pytho...@python.org
My suggestions for the TODO list...


ConfigStorage:
Read/write, storage of Python values for configuration variables,
potentially use .ini, .whatever, or registry for storage, use human-editable
formats wherever possible. Replace registry settings for Python with such
repositories to allow for cross-platform scripts (see config below).
Purpose here is to provide a convenient and robust way for applications to
store their configuration settings as Python data without needing to think
about the storage mechanism. Should prevent storing huge objects in the
windows registry.


ZipDirectory/Virtual FileSystem:
Make reading/writing into/out of archive files as trivial as
reading/writing from directories (i.e. zipdirectory.open(
'z:/temp/test.zip/path/to/myfile.txt','r').read() would work). Allow for
reading, modifying (the tricky one), and writing files. Should handle .zip,
(.jar), .tar, potentially also .hqx (or whatever the mac standard is).
Creation would follow virtual filesystem model, you create a zip
"directory", then populate it with files...

zipdirectory.makedirectory( 'z:/temp/test.zip', compress=1 )
zipdirectory.open('z:/temp/test.zip/path/to/myfile.py', 'w').write(
somedata )

On a larger level, provide hooks for virtual filesystems of all types, so
that, for instance, the ftp modules could be given a similar api, as could
the urllib.retrieve stuff:

file = open( 'http://www.python.org/','r')
file.readline()
file.read()

With file being a class providing file-like semantics, a buffer into which
the data is downloaded, as well as the http-specific stuff.


Configure:
Allow (potentially persistent) configuration of the running Python
interpreter. Modify path values, modify list of scripts run at startup,
modify shell action bindings (for win32). Should allow for user interaction
to prevent unwanted changes I suppose.


From other threads:
Cross-platform SerialPortIO
Micro-threads :)
GUI Front-end to Py2EXE to make inclusion/exclusion of items easier

Enjoy all,
Mike

-----Original Message-----
From: python-l...@python.org
[mailto:python-l...@python.org]On Behalf Of Guido van Rossum
Sent: June 29, 2001 12:18
To: pytho...@python.org
Subject: Re: Not enough Python library development [was PEP scepticism]


Roman Suzi <r...@onego.ru> writes:

> Is there a formal TODO list of the libraries and respective priorities?

No, although there's a PEP for small feature requests (PEP 42).

If you want to start making a list of missing libraries and submit a
PEP, please do! I'm sure many people will want to contribute.

...


Alex

unread,
Jun 29, 2001, 2:05:19 PM6/29/01
to

> Instead people write about how convenient CPAN makes it to find
> modules, or how useful the XML modules are, or how EJB lets them write
> elaborate business systems.

What's EJB got going for it, anyway?

Alex.

Andrew Kuchling

unread,
Jun 29, 2001, 2:34:00 PM6/29/01
to
Alex <new_...@mit.edu> writes:
> What's EJB got going for it, anyway?

Buggered if I know. Perhaps they provide a frictionless method for
transferring a business's money to consultants.

--amk

mch...@destiny.com

unread,
Jun 29, 2001, 2:43:24 PM6/29/01
to pytho...@python.org
> This a general warning against the second system syndrom in Python.
>
> Maybe I am a hypocritical sceptic, but I have the impression that
> some feeping creatureism is introduced into Python.
> This might reduce the main advantage of Python to be clear and easy
> and mostly have one good formulation on how to express what you want
> to program in a structured way.
>
> Examples are:
> - augmented Assigments
> - Lists comprehensions
> - Simple Generators
>
> To me it looks like these contructs do not add capabilities to
> python which were missing.
[....]
> Please to not respond giving me the very good reasons on why these
> features I have given as examples have been added or will be added
> to python.
[....]
> On the other hand this is excatly the danger I want to warn you about.
> It is a social reason for being careful:
>
> Participation in the PEP debates about Python-enchancements
> requires a certain level of knowledge and interest
> about computer language design.
>
> It is most likely that the participants
> do understand complicated language constructs easily and
> are python wizards. They might just not see how the addition
> of syntatic sugar will lead to a higher learning curve for the masses.
[....]
> Mainly as a python user I urge you to take this into consideration.


First of all, thank you Bernhard, for raising an important point.
I completely agree with you: one of the strengths of Python is its
simplicity, and I would never want to see it go the way of Perl
or C++. And you are (IMHO) RIGHT that those who discuss PEPs are
probably more savy than the typical Python user, and they need to
keep that in mind.

On the other hand, I find your list of examples sorely lacking.
Without trying to convince you, let me just state that in MY opinion:

Augmented Assignment -- perhaps not a good idea, but I guess
we got tired of being laughed at by people coming from C
and java. It's awefully convenient anyhow.

List Comprehensions -- one of my new arguments for why Python
is so much BETTER than other languages. Their elegence and
simplicity (for a task which is incredibly common) makes the
language SIMPLER to read, and the syntax is so "obvious"
that beginners can pick it up after seeing 2 or 3 examples.

Simple Generators -- this, too, is elegant and simple to
understand. If you use them in wierd ways you might be able
to create confusion (eg: add methods to a generator-iterator),
but used straightforwardly, I think these will be powerful
in some very common situations, and fairly easy to explain.

So I guess what I'm saying here is that I *agree* strongly with
your point, and we *must* keep this in mind as we consider new
language additions, but IMHO, we've already been doing a good job
of this. The features we're adding (except for print>>) are
well-chosen and not excessive. If we keep your advice in mind,
maybe we can continue that record.

-- Michael Chermside


Carsten Geckeler

unread,
Jun 29, 2001, 3:33:09 PM6/29/01
to Python
On Fri, 29 Jun 2001, phil hunt wrote:

> On Thu, 28 Jun 2001 12:26:08 -0700, steven...@isomedia.com <steven...@isomedia.com> wrote:
> >
> >Keystroke reduction saves the original programmer time.
>
> True.
>
> > But it costs
> >other people more time when they read the code.
>
> Really?
>
> Is this:
>
> self.total[player] += s
>
> any harder to understand than this:
>
> self.total[player] = self.total[player] + s
>
> I don't think so.

It is harder to understand, when the statements do different things.

Cheers, Carsten
--
Carsten Geckeler


Carsten Geckeler

unread,
Jun 29, 2001, 3:30:53 PM6/29/01
to Python
On Fri, 29 Jun 2001, Roman Suzi wrote:
[snip] [snipsnip]

> Generators are necessary to drop memory usage while leaving
> existing usage of functions the same. And I think after
> generator's introduction, in things like:
>
> for line in file.readlines():
> ...
>
> people will _expect_ generators to be used and will look at
> the source to check it.

Hopefully, people will NOT expect this to be a generator. If
file.readlines() would be a generator you could not get a list of all
lines of a file with

lines = file.readlines()

> So, I can't see how all these advanced features could
> harm anybody's ability to read code!

See above.

Tim Peters

unread,
Jun 29, 2001, 3:56:21 PM6/29/01
to pytho...@python.org
[Tim]

> So what do you do about the curious disconnect between supply
> and demand in Open Source projects?

[Andrew Kuchling]


> Beats me. This is nothing new, in that interesting tasks get worked
> on, and boring ones don't.

It's too glib: the canonical example is CPAN, and is there some reason CPAN
is *not* "boring" in the Perl world but is in the Python world? Doubt it.
People have different interests, and Python just doesn't seem to attract
those with really boring interests <wink>.

> I haven't updated the bookstore in a while, or tried to kick the
> catalog-sig into life, or released various bits of software sitting
> on my disk, because such tasks would be pretty boring, and I have
> more entertaining possibilities open to me.

The real question is why someone else hasn't popped up to do these things.
This isn't a question about you (or me, or any of the rest of the usual
masochists), it's about why Python hasn't attracted hundreds of Andrews.

> Greg Ward moved back to Montreal, and now does practically no hacking
> or writing in his spare time at all.

Well, of course -- there's also an automatic IQ shift of 50 points whenever
crossing the US-Canadian border <wink>.

although-i-won't-say-in-which-direction-ly y'rs - tim


phil hunt

unread,
Jun 29, 2001, 3:35:33 PM6/29/01
to
On Fri, 29 Jun 2001 16:18:10 GMT, Guido van Rossum <gu...@python.org> wrote:
>Roman Suzi <r...@onego.ru> writes:
>
>> Is there a formal TODO list of the libraries and respective priorities?
>
>No, although there's a PEP for small feature requests (PEP 42).
>
>If you want to start making a list of missing libraries and submit a
>PEP, please do! I'm sure many people will want to contribute.
>
>> For example, I think that some sort of standard GUI could help Python to
>> fight Java with it's Swing/AWT...
>
>This was tried many times -- there was even a GUI-sig with this goal.

I thought Tkinter was the standard GUI???

>Nothing ever came to fruition. The problem is that designing and
>implementing a standard GUI that can compete with the existing
>offerings it an enormous amount of work,

Just a random idea: would it be possible to create a GUI with the
same python interface as Tkinter, but which talks to the KDE
or GNOME libraries instead? Or are their object models and internal
concepts too different -- e.g. in packing functionality?

> and folks always ran out of
>steam before they were even done with the requirements gathering.

My Parrot project has as one of its goals the ability to define
a gui (in a gui definition language) which can then be compiled
into source code for whatever language/library combination the
user desires. So there could be a python/tkinter output module,
a python/KDE one and a python/GNOME one. These would not be fully
compatible; a parrot class for output to Python/Tkinter would
require different functionality code than one for Python/KDE. But
it could be written in such a way that required changes are minimal.

(see <http://www.vision25.demon.co.uk/oss/parrot/intro.html> for details)

Parrot's not my top priority right now, but I expect I'll be making
more changes to it later this year to bring it up to a workable state,

>> It could be also interesting to have time module as powerful as mxDateTime
>> in standard library. And so on.
>
>Well, propose one. But what exactly is the point of adding it to the
>standard library when you can get mxDateTime if you need it?

Because Python should be "Batteries included". I wasn't aware mxDateTime
existed, and was semi-seriously thinking of writing a high-level
date/time library, with stuff like:

d1 = dateToday()
d2 = Date("1 Jan 1975")
daysDifferent = d1 - d2

(you'd also be able to add/subtract time values, differences would
be expressed in seconds, etc)

>I'd say
>your energy is better spent on reviving the catalog-sig (Python's
>CPAN-like effort, which needs new energy!)

I thought Vaults of Parnassus was for that?

--
## Philip Hunt ## ph...@comuno.freeserve.co.uk ##


phil hunt

unread,
Jun 29, 2001, 2:20:58 PM6/29/01
to

Now there's a challenge!

PEP1 says:
The PEP champion (a.k.a. Author) should first
attempt to ascertain whether the idea is PEP-able.
Small
enhancements or patches often don't need a PEP and can be injected
into the Python development work flow with a patch submission to
the SourceForge patch manager[2] or feature request tracker[3].

How do I ascertain this?

Who decides whether something is a "small enhancement"?

The changes i propose would be two separate PEPs (I assume) --
or would they be added to PEP-42 (which is a list of small
features)?

It seems to me that optional-pass is obvious in its meaning,
but multi-liner comments aren't. There are three issues:

1. what should be the character sequences to begin/end multi
line comments

I propose /* to start multi-line comments and */ to
end them. Eg:

/* this is a multi-line comment.
this is part of the samer comment.
so is this. */

Rationale: similar to C and many other languages; the combination
/* isn't legal anywhere in current python code (AFAIK) so won't
break it. I did consider using one of @$? which are not currently
used by python, but it's best to leave these unused so they
are still available for extra operators (or whatever) at a later
date.

2. how will this interact with python's indent/dedent mechanism

In particular, how do we treat this:

def myfunction():
print "hello"
print "start" /* start of comment
middle of comment
end of comment */ print "goodbye"

IMO the best way to prevent unexpected wierdness like this is
to forbid any code in any line after the */ closing-comment
sequence; or perhaps to give a warning and ignore it (it
shouldn't just be silently ignored, as this will confuse people
familiar to how it works in C).

3. will it break any old code

AFAIK my proposal as it stands won't.

Tim Peters

unread,
Jun 29, 2001, 4:01:30 PM6/29/01
to pytho...@python.org
[Bernhard Reiter and Alex Martelli quote from an interview with
Dennis Ritchie, at

http://www.itworld.com/Comp/3380/lw-12-ritchie/
]

One more from that not to be missed:

On the other hand, the "open evolution" idea has its own drawbacks,
whether in official standards bodies or more informally, say over
the Web or mailing lists. When I read commentary about suggestions
for where C should go, I often think back and give thanks that it
wasn't developed under the advice of a worldwide crowd.


Roman Suzi

unread,
Jun 29, 2001, 4:29:58 PM6/29/01
to pytho...@python.org
On Fri, 29 Jun 2001, Guido van Rossum wrote:

>Roman Suzi <r...@onego.ru> writes:
>
>> Is there a formal TODO list of the libraries and respective priorities?
>
>No, although there's a PEP for small feature requests (PEP 42).
>
>If you want to start making a list of missing libraries and submit a
>PEP, please do! I'm sure many people will want to contribute.

Python could have better CPAN than CPAN by having non-existent modules
included ;-)

import cpan.load.non_existent

will cause "NotImplemented" exceptions ;-)

I think, for having TODO list is sufficient to have Wiki somewhere and a
preamble which says what is this about and there will be lots of
suggestions...

CPyAN is much more complex task, because there are:

- security considerations
- integration with distutils
- probably, one day python will allow the "import" shown above
(I even think it is already possible)
- dependency resolution framework...

Oh... It's already put on catalog-SIG.

>> For example, I think that some sort of standard GUI could help Python to
>> fight Java with it's Swing/AWT...
>
>This was tried many times -- there was even a GUI-sig with this goal.

>Well, propose one. But what exactly is the point of adding it to the


>standard library when you can get mxDateTime if you need it? I'd say
>your energy is better spent on reviving the catalog-sig (Python's
>CPAN-like effort, which needs new energy!)

catalog-sig is dead?

Sincerely yours, Roman Suzi
--
_/ Russia _/ Karelia _/ Petrozavodsk _/ r...@onego.ru _/
_/ Friday, June 29, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "I failed attitude in school." _/


Bruce Sass

unread,
Jun 29, 2001, 5:04:49 PM6/29/01
to Roman Suzi, pytho...@python.org
On Sat, 30 Jun 2001, Roman Suzi wrote:
<...>

> CPyAN is much more complex task, because there are:
>
> - security considerations
> - integration with distutils

Don't forget (at least considering the issues surrounding) integration
with something like...

http://packages.debian.org/unstable/admin/auto-apt.html


- Bruce


Tim Peters

unread,
Jun 29, 2001, 5:43:34 PM6/29/01
to pytho...@python.org
[phil hunt]

> Now there's a challenge!
>
> PEP1 says:
> The PEP champion (a.k.a. Author) should first
> attempt to ascertain whether the idea is PEP-able.
> Small enhancements or patches often don't need a PEP and can be
> injected into the Python development work flow with a patch
> submission to the SourceForge patch manager[2] or feature request
> tracker[3].
>
> How do I ascertain this?
>
> Who decides whether something is a "small enhancement"?

It's like judging pornography: "contemporary community standards". If you
have to ask, you're either a pornographer or a juror <wink>.

> The changes i propose would be two separate PEPs (I assume) --
> or would they be added to PEP-42 (which is a list of small
> features)?

Separate PEPs are much more visible. Like the Answer to Everything, PEP 42
may be a long time coming.

> It seems to me that optional-pass is obvious in its meaning,

Sorry, I have no idea what it means. Like you want to be able to use "pass"
in more places, but optionally? Or want not to have to use pass in some
places where you must use it now? Or ...?

> but multi-liner comments aren't. There are three issues:
>
> 1. what should be the character sequences to begin/end multi
> line comments

What do you have against the existing method? That is,

"""This is a multi-line comment.
this part of the same comment.
so is this."""

It's truly a comment: a statement consisting of just a string is thrown
away by the compiler, unless it's in a docstring position (is the first
non-comment statement in a module, def or class).

Or the other existing method:

# This is a multi-line comment.
# Although it sure looks like a sequence of
# single-line comments <wink>.

There's really no point answering these questions on c.l.py: that they've
been *asked* means the proposals are already controversial, so need PEPs to
lay out all sides of the case. I don't know what "optional pass" means, but
the multi-line comment business has come up many times, so it would be
especially good to PEP that one, in order to lay it to rest (one way or
another) for good.


phil hunt

unread,
Jun 29, 2001, 5:47:58 PM6/29/01
to

Ther's probably some truth in that... :-)

Andrew Kuchling

unread,
Jun 29, 2001, 6:37:07 PM6/29/01
to
"Tim Peters" <tim...@home.com> writes:
> It's too glib: the canonical example is CPAN, and is there some reason CPAN
> is *not* "boring" in the Perl world but is in the Python world? Doubt it.

Not at all; CPAN has had bits which were broken for a long time, such
as the scripts submission, which I think was broken for a few years.
However, the primary catalog feature kept working, probably because:
1) someone wrote it initially, and not much subsequent maintenance
was needed.

2) lots of people used it, so if it broke, the resulting screams
ensured that someone kept it running.

I suspect that an ambitious person could jumpstart the catalog into
existence, even if they ignored the catalog SIG completely. Write an
initial implementation that's reasonably good, seed it with data from
Parnassus or wherever, and push it hard for a few months; if enough
people begin adding their new modules, then it'll just bootstrap
itself into indispensability, much as Parnassus did.

> The real question is why someone else hasn't popped up to do these things.

That's another good one; I don't know. Perhaps people think you have
to be a serious wizard to contribute, but that's really not true;
there's lots you can do without being a genius who rewrites ceval.c at
the drop of a hat. People who wanted to gain experience on a free
software project would be much better starting off on Python, which
you can write docs or write Python code or hack C code, than by
initiating yet another small application that never gets finished.
I've wondered if a document on how to work with the Python dev team
would be a useful thing, and if it would encourage more people to help
out.

--amk

Andrew Kuchling

unread,
Jun 29, 2001, 6:41:25 PM6/29/01
to
Roman Suzi <r...@onego.ru> writes:
> CPyAN is much more complex task, because there are:
>
> - security considerations
> - integration with distutils
> - probably, one day python will allow the "import" shown above
> (I even think it is already possible)
> - dependency resolution framework...

Not necessarily. An annoying habit of the Python community is to
write an initial requirement list that's so forbiddingly long that
everyone is frightened away and nothing is ever implemented. But you
don't have to implement everything to have something useful. Case in
point: Parnassus, which does exactly 0 of the above 4 items, yet it's
definitely not useless.

--amk

Martijn Faassen

unread,
Jun 29, 2001, 7:08:18 PM6/29/01
to
James Logajan <Jam...@lugoj.com> wrote:

> Bernhard Reiter wrote:
>>
>> This a general warning against the second system syndrom in Python.
> [ Elided. ]

> Thank you, Bernhard. I agree with your unease.

I have the same unease. It would seem to me that the features that
most trouble people are new syntax or changes to syntax. Semantic
changes are strangely enough not seen as so troubling, as often
it's an attempt to make the semantics more general (healing the type/class
split, for instance).

Perhaps it would be a good idea to consider a strategy to slow down
the syntactic changes by saying we can only have new ones every
other Python release (let's say the uneven ones, though no
parallel with Linux stable/development kernel is implied). The even releases
would focus on:

a) tweaking with the interpreter (making it faster, fixing bugs, also
perhaps 'generalizing' semantics such as type/class and the number
system)

b) *adding to the standard library*!

The latter does not appear to get a lot of focus in the PEPs, though
it may be my selective reading that does it. But a clear focus on
the standard library by the core developers couldn't be bad, right?

The even releases would have a moratorium on changes that would
involve changes to the language syntax, and any change that really
should require such a change (but we're submitting the PEP anyway as
we want it so badly, and we'll just do a hackish application of the
current syntax instead. This is of course bad too).

What do people think about the general idea?

Regards,

Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?

Martijn Faassen

unread,
Jun 29, 2001, 7:11:42 PM6/29/01
to
Andrew Kuchling <akuc...@mems-exchange.org> wrote:
> I don't think improving Python the language will win new converts at

> this point; improving the standard library, development environments,
> or the documentation is more likely to bear fruit.

Ah, very much like the point I was making in a post I just made.

What do you think about formalizing this, and restricting some releases
of Python to be focused on bugfixes and library development, avoiding
syntax changes (which frequently entail relatively large changes in
semantics)?

Martijn Faassen

unread,
Jun 29, 2001, 7:17:45 PM6/29/01
to

I was in a huge thread about those some weeks ago.

The whole Java stuff offers:

* standardized APIs. Makes it easier to learn systems, and easier
to find programmers who know the system. This goes from
a templating engine to persistence to relational/object integration.

* help with scalability of the system (clustering for instance),
if you use the APIs you're sort of assured you can scale it all up.

Of course I'm skipping over a lot of stuff.

Python (and many Python frameworks such as Zope) could do with a few more
standardized APIs (and protocols/interfaces). I think Python actually has
most of the pieces, though, but you have to worker harder to collect
them together into an application.

Martijn Faassen

unread,
Jun 29, 2001, 7:25:26 PM6/29/01
to
Andrew Kuchling <akuc...@mems-exchange.org> wrote:

> "Tim Peters" <tim...@home.com> writes:
>> So what do you do about the curious disconnect between supply and demand in
>> Open Source projects? You got list comprehensions because Greg Ewing (and

> Beats me. This is nothing new, in that interesting tasks get worked

> on, and boring ones don't. I haven't updated the bookstore in a


> while, or tried to kick the catalog-sig into life, or released various
> bits of software sitting on my disk, because such tasks would be
> pretty boring, and I have more entertaining possibilities open to me.

> Greg Ward moved back to Montreal, and now does practically no hacking

> or writing in his spare time at all. Unfortunately, practically
> *everyone* considers these tasks dull.

Which is why a system more or less *forcing* core developers to look
at these issues *only* for a while may be good. See my earlier post
on that. We could propose that all uneven release of Python have
no changes to the interpreter that change the language syntax/semantics.
(this is more strict than I proposed in my previous post, as I saw
Tim is actually more afraid of the 'make the semantics more coherent'
attempts than new syntactic features).

That would force the core developers to focus on:

a) bug fixes

b) optimizations to the interpreter

c) library changes

d) infrastructure improvements (catalog, etc)

for a while, until the next release comes around. Wouldn't that help?
Of course this measure could be considered rather draconian. :)

Martijn Faassen

unread,
Jun 29, 2001, 7:29:36 PM6/29/01
to
mch...@destiny.com wrote:
[snip]

> First of all, thank you Bernhard, for raising an important point.
> I completely agree with you: one of the strengths of Python is its
> simplicity, and I would never want to see it go the way of Perl
> or C++.

This slide is particularly scary in that sense. The slides are for
a talk given at Yet Another Perl Conference that just occurred in Montreal.

http://prometheus.frii.com/~gnat/yapc/2001-80-20/slide006.html

Note the 'signs of pragmatism in a formerly ideological world' comment!
This is praise coming from Perl, and I'm not sure what to think. :)

(Please note that I've already given the author of the slides some suggestions
on how to improve the Python on this particular slide so don't bother
mailing him about it. Nathan's a nice guy.)

Martijn Faassen

unread,
Jun 29, 2001, 7:35:07 PM6/29/01
to
Andrew Kuchling <akuc...@mems-exchange.org> wrote:
[snip good analysis]

> I suspect that an ambitious person could jumpstart the catalog into
> existence, even if they ignored the catalog SIG completely.

This of course similar to what happened with the Vaults of Parnassus. We didn't
really have a good comprehensive site with links to Python modules
before it. Tim Middleton wrote something up and filled it up, and
poof, people complain when it's down or slow in accepting submissions. :)

> Write an
> initial implementation that's reasonably good, seed it with data from
> Parnassus or wherever, and push it hard for a few months; if enough
> people begin adding their new modules, then it'll just bootstrap
> itself into indispensability, much as Parnassus did.

That's probably the way to go about it. Now we only need to find a person
willing to do all the work.

[snip good question]


> I've wondered if a document on how to work with the Python dev team
> would be a useful thing, and if it would encourage more people to help
> out.

The somewhat mysterious way to get accepted to the dev mailing list
at all is a hurdle all by itself.. Perhaps this document could help
there too.

Ben Wolfson

unread,
Jun 29, 2001, 7:44:19 PM6/29/01
to
On Fri, 29 Jun 2001 15:56:21 -0400, "Tim Peters" <tim...@home.com> wrote:

[CPAN-for-Python]

>The real question is why someone else hasn't popped up to do these things.

I thought Sean Reifschneider DID pop up and do those things. Has Swalow
development stopped?

--
Barnabas T. Rumjuggler
Yet when he came down from the mountain, he had not gained any wisdom.
In no way had he been able to solve the riddle of this story. And he had
lost his faith. But he had discovered that he had an affinity for
Dixieland music. -- Joe Frank, "The Road to Calvary"

Paul Prescod

unread,
Jun 29, 2001, 7:12:17 PM6/29/01
to pytho...@python.org

I agree. We've decided at ActiveState to try and push the penny ahead a
few inches by the O'Reilly Open Source conference. We're working on a
minimalist repository that can evolve into the repository of our dreams.
It isn't a trivial job but we can at least leverage some of our existing
security infrastructure, proficiency with Zope, etc. One good example of
what our web team has put together is here:

http://aspn.activestate.com/ASPN/Python/Mail

I find these archives to be better than other Python archives available
on the Web. Consider this feature:

http://aspn.activestate.com/ASPN/Mail/Leaders/python-dev/

We hope to do the same thing with module repositories. We'd also like to
integrate some of the security, commenting, rating and reviewing
features from the Python cookbook:

http://aspn.activestate.com/ASPN/Cookbook/Python

But this is mostly a spare-time project because it is not product -- so
I don't want to lift expectations too high...we're doing what we can do
just like any other contributors to open source. Nevertheless, I have
high hopes that we can plant the seeds and the community will help us
harvest.

I'm holding a BOF on the topic at the O'Reilly conference (just like at
the last Python conference) and we'll share our progress and see what
other people are up to.
--
Take a recipe. Leave a recipe.
Python Cookbook! http://www.ActiveState.com/pythoncookbook

phil hunt

unread,
Jun 29, 2001, 7:29:48 PM6/29/01
to
On Fri, 29 Jun 2001 17:43:34 -0400, Tim Peters <tim...@home.com> wrote:
>
>> It seems to me that optional-pass is obvious in its meaning,
>
>Sorry, I have no idea what it means. Like you want to be able to use "pass"
>in more places, but optionally? Or want not to have to use pass in some
>places where you must use it now? Or ...?

It means where now you have to say:

class myClass:
pass

or

def myfun():
pass

when you create an initially-empty construct, you will in
future be able to say:

class MyClass:
def myfun():

and the pass keywords will be implied by the compiler. Perhaps
implied-pass is a better name?

>> but multi-liner comments aren't. There are three issues:
>>
>> 1. what should be the character sequences to begin/end multi
>> line comments
>
>What do you have against the existing method? That is,
>
> """This is a multi-line comment.
> this part of the same comment.
> so is this."""
>
>It's truly a comment: a statement consisting of just a string is thrown
>away by the compiler, unless it's in a docstring position (is the first
>non-comment statement in a module, def or class).

I don't like this, because it just doesn't feel right to me. A
Comment should look different, syntactically, from a string literal.
Also, I suspect that docstrings are a source of inefficiency (OK,
I admit that's not a real problem when you have a short python program
and 128M of RAM).

>Or the other existing method:
>
> # This is a multi-line comment.
> # Although it sure looks like a sequence of
> # single-line comments <wink>.

This is truly bad, because it makes it harder to add new lines;
you have to type "# " repeatedly when adding new comment text, which
breaks the flow of thought -- at least it dores for me.

>There's really no point answering these questions on c.l.py: that they've
>been *asked* means the proposals are already controversial, so need PEPs to
>lay out all sides of the case. I don't know what "optional pass" means, but
>the multi-line comment business has come up many times, so it would be
>especially good to PEP that one, in order to lay it to rest (one way or
>another) for good.

I wasn't aware that you could just plonk a string literal around anywhere
and it get ignored, thus forming a comment. In the light of that,
my multi-line comment proposal may seem a bit pointless. So here's
what I will do: write a PEP for it if at least 2 people on this
newsgroup say they support the idea.

Ben Wolfson

unread,
Jun 29, 2001, 8:22:25 PM6/29/01
to
On Sat, 30 Jun 2001 00:29:48 +0100, ph...@comuno.freeserve.co.uk (phil
hunt) wrote:

>On Fri, 29 Jun 2001 17:43:34 -0400, Tim Peters <tim...@home.com> wrote:
>>Or the other existing method:
>>
>> # This is a multi-line comment.
>> # Although it sure looks like a sequence of
>> # single-line comments <wink>.
>
>This is truly bad, because it makes it harder to add new lines;
>you have to type "# " repeatedly when adding new comment text, which
>breaks the flow of thought -- at least it dores for me.

You don't need to write them that way. I write long comments by just
writing a bunch of stuff, letting it get colorized &c, and then going back
and adding # at the appropriate place. No breakage in the flow of thought,
no problem.

David Goodger

unread,
Jun 29, 2001, 8:37:00 PM6/29/01
to
on 2001-06-29 12:18 PM, Guido van Rossum (gu...@python.org) wrote:
> But what exactly is the point of adding it to the
> standard library when you can get mxDateTime if you need it?

Several points! (Impatient? See #6.)

If a module is part of the standard distribution:

1. It gets wide exposure, hopefully resulting in bugs being found out and
improvements being made.

2. Bugs reports and patches can be contributed to a much larger developer
community than any solo module enjoys.

3. There's a greater chance of continuity if/when the module is abandoned by
the original author.

4. There should be a regression test for the module. It therefore has a
better chance of being kept up-to-date with the latest language features
(i.e., the module won't break when feature X changes, is added, or is
deprecated).

5. The module tends to have decent documentation, and that documentation is
placed in a central location and indexed.

6. (perhaps most importantly:) C extension modules get compiled for every
platform with a binary Python distribution. Not all of us have a C compiler
at hand, want to use one, or have the knowledge & experience necessary to
overcome code porting issues. (I used to know my way around a C compiler,
but I've been spoiled by Python! :-) For example, I don't see any Mac builds
of mxDateTime 2.0 on the net.

I think "Batteries Included" is a great goal. Adding to and improving the