PEP scepticism
Bernhard Reiter
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
>
> This a general warning against the second system syndrom in Python.
Thank you, Bernhard. I agree with your unease.
Roman Suzi
>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
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
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
>>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
> 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
[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
> On 28 Jun 2001, Bernhard Reiter wrote:
>
> >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
>
>
>
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
>>>>>> "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
>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
> 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
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
>>>>> "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
> 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
> ...
> 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
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
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
"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
> 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
> 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
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
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
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
> 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
>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
>
>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
>
>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
> 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
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
>>>>> "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
> 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
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
> 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
> 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
>
> Maybe I am a hypocritical sceptic, but I have the impression that
> some feeping creatureism is introduced into Python.
> and mostly have one good formulation on how to express what you want
> to program in a structured way.
>
> - augmented Assigments
> - Lists comprehensions
> - Simple Generators
>
> 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
> 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
[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
> 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
>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
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
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
>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
<...>
> 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
> 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
Ther's probably some truth in that... :-)
Andrew Kuchling
> 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
> 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
> Bernhard Reiter wrote:
>>
>> This a general warning against the second system syndrom in Python.
> 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
> 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
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
> "Tim Peters" <tim...@home.com> writes:
>> So what do you do about the curious disconnect between supply and demand in
> 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
[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
[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
[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
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
>
>> 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
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
> 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
standard library should be a goal of every release of Python. The more
quality batteries the better!
--
David Goodger dgoo...@bigfoot.com Open-source projects:
- Python Docstring Processing System: http://docstring.sf.net
- reStructuredText: http://structuredtext.sf.net
- The Go Tools Project: http://gotools.sf.net
Thomas Wouters
> Consider this feature:
> http://aspn.activestate.com/ASPN/Mail/Leaders/python-dev/
Aahh.. cute. Also scared me shitless; I couldn't believe I'm the 4th most
spammy py-dev'er. And that's not so weird, because I'm not -- I'm just
mail-address-monogamous, contrary to, apparently, most of python-dev :)
I-always-suspected-that-Tim-bastard-of-polemailgamy-ly y'rs ;P
--
Thomas Wouters <tho...@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Rainer Deyke
news:slrn9jq3rc...@comuno.freeserve.co.uk...
> 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.
Strange. In C++, I always use '//' for multiline comments in favor of
'/**/'. ('//' in C++ is equivalent to '#' in Python.) This makes the
comment more readable IMO. Why not just type the comment text first, and
add '#' marks later?
--
Rainer Deyke (ro...@rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
Emile van Sebille
This is very cool! Thanks.
What are the criteria for including a group in here? How often are they
updated?
In particular, it looks like you've got most of the Python, Zope and
ActiveState groups, but I note several MIAs, eg: pybsddb, ZODB, wxPython,
etc. I see you've even got the newly created PythonCard group in there.
Google-search-without-the-dash-monty-with-the-mailling-lists-ly y'rs
--
Emile van Sebille
em...@fenx.com
---------
"Paul Prescod" <pa...@ActiveState.com> wrote in message
news:mailman.993856425...@python.org...
<snip>
Emile van Sebille
--
Emile van Sebille
em...@fenx.com
---------
"Andrew Kuchling" <akuc...@mems-exchange.org> wrote in message
news:3d8zib1...@ute.cnri.reston.va.us...
> 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
>
Eric Merritt
I am new to python after having converted from java.
One of the problems I always had with java was the
lack of a native code compiler. Will python ever have
one of these? I have seen references to projects such
as py2c etc, but they all seem dead. Is there an
inherent problem in creating a compiler for python or
is it just very difficult. Unfortuanatly I am not a
big compiler guru though I would be willing to help if
I could. Just curious.
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
Aahz Maruch
Martijn Faassen <m.fa...@vet.uu.nl> wrote:
>
>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.
It's not mysterious at all: Guido invites you (cadging an invite from
Guido is an option, of course). But it doesn't take all that much to
get an invitation; I'm on the list, and I still have not contributed any
code to Python, and I've only submitted one formal PEP.
--
--- 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
Cristian Echeverria
McMillan Installer (http://www.mcmillan-inc.com/builder.html)
and
Py2exe (http://py2exe.sourceforge.net/).
These are not real compiler but are very close.
"Eric Merritt" <cybe...@yahoo.com> escribió en el mensaje
news:mailman.993870107...@python.org...
Tim Peters
>>> 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.
[Tim]
>> 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.
[Bernhard Reiter]
> Rethinking this I still think this are _the main_ advantages
> compared to other languages.
You're allowed to use Python for any reason that suits you <wink>.
> What do you think the main advantages are? :)
Python minimizes my unproductive programming time, and that's an *empirical*
observation over years of using Python along with many other languages. I'm
really not sure how it accomplishes it, but that's its main advantage to me
(and, BTW, that's the core problem with Second System Syndrome too: I'm not
sure Guido understands exactly how Python does it either).
Part of it is expressivity coupled with lack of tricks; as a
counter-example, APL is highly expressive provided you buy into the core
trick that "everything's an array". Python lets (more, encourages) me to
treat different things differently, yet is still highly expressive across
many different kinds of things.
Now when we get to:
>>> Examples are:
>>> - augmented Assigments
>>> - Lists comprehensions
>>> - Simple Generators
my reaction to all is the same: they increase expressivity, each
significantly reducing the gap between how I think of a problem and what I
have to type to get the machine to think the same way I do. They *increase*
"clear and easy" for me, so in that sense I'm a "clear and easy" fan too --
but people won't agree on what "clear and easy" mean. I've even been told
that some people find Perl clear and easy <wink>.
> ...
> However not having augmented assignment made me think about it and
> the clarity you gain when writing it more explicitly.
We won't agree on that, so good thing for me that I think more like Guido
here <wink>. I *think* "add y to x", or "bump x by y", not "add x and y and
then replace x with the sum so obtained", so
x += y
is much clearer to me than
x = x + y
and I really mean "much". Faced with the latter, I always have to *deduce*
"ah, OK, it's adding y to x", and that's a drag on my time. I hated that in
Fortran and Pascal, and in Python too before augmented assignment was added.
In Lisp it was easy to write macros, but then too easy to write so many
macros that you can't make head or tail of the mess a few months later.
Etc. Whenever Python changes to let me say what I intend more directly, I
like it.
I confess I don't care at all whether something is obvious at first glance.
The ABC language tried that as far as humanly possible, and while it may
have been great for teaching, it was a PITA for getting real work done.
Part of Guido's genius was in extracting the pieces of ABC "that worked" on
all levels (for both newbies and experts), tossing the parts that didn't,
and incorporting new gimmicks akin to the parts of ABC that worked best.
The acid test for me isn't whether a newcomer understands a gimmick at first
sight, but whether (a) they can be taught it, and (b) whether, once learned,
it's hard to *forget*. Picturing array indices as pointing *between*
elements is the canonical example of that: it makes no sense at all to many
newcomers, yet once learned it's compelling and endlessly fruitful. I'm all
in favor of Python adding thousands <wink> of new gimmicks like that, but--
alas --the supply of comparably jewel-like ideas appears severely limited.
>> Not even Scheme stayed *braindead* austere forever, you know <wink>.
> That's why fresh, small languages are designed sometimes... <wink>
And always will be. "Everything is an X" appeals to young language designers
(you can't get "small" without that), and whether X is macros, strings,
arrays, lists, classes, lambdas or combinators doesn't really matter: they
get a spare but trick-laden language in the end, and expressivity sucks
unless you share the delusion that everything's an X. Python's only nod in
this direction was "everything's an object", but the semantics shared by all
objects is so tiny (you can apply id() and repr() and str() and type() to
anything) it doesn't get in the way. Part of the danger in PEPs 252-254 is
in trying to expand this commonality.
> ...
> Maybe my subject of the original was suboptimal, but there is
> some connection and I had to start expression what my concern is
> somewhere.
Here's something else to consider: as with the examples above, almost all
changes to Python have been debated for years, and the backlog of old ideas
with a strong constituency decreased rapidly over the last year (as old
ideas finally got implemented or rejected). Changes that pop up out of thin
air (i.e., without a long history) are much rarer, and rarely significant in
the overall scheme of things. The strongest counter-example I can think of
is the addition of Unicode strings, which popped out of nowhere (wrt the
original language design and the initial year of "feature requests"), but
were added in such a way that most American users still have no idea Python
has them <0.7 wink>.
So I expect the pace of language (but not library) change to slow, simply
because we're running out of strong backed-up ideas for the core.
but-then-most-debates-are-about-yesterday's-problems<wink>-ly y'rs - tim
Tim Peters
> Which is why a system more or less *forcing* core developers to look
> at these issues *only* for a while may be good.
Afraid it can't be done: most development comes from volunteer time, and
volunteers can't be forced to do anything. If some area is lacking, what it
needs is new volunteers who *want* to work in that area, and, indeed, want
to work in that area so much that they'll freely contribute a good part of
their lives to do so.
it's-not-like-i-got-paid-to-write-tabanny.py-i-only-did-it-to-attract-
whitespace-groupies<wink>-ly y'rs - tim
Paul Prescod
>
> Hello All,
>
> I am new to python after having converted from java.
> One of the problems I always had with java was the
> lack of a native code compiler.
That's a strange thing to hold against a language. How does it affect
you? I could build an executable for you in either Java or Python that
was indistinguishable from one that was native code compiled without
disassembling it.
If your complaint is that Java (or Python) is too slow, I think you
should say that. If your complaint is that you can't write standalone
binaries in it (you can), you should say that. I'd like to understand
what you really need so I can tell you whether Python has what you need
or not.
> Will python ever have
> one of these? I have seen references to projects such
> as py2c etc, but they all seem dead. Is there an
> inherent problem in creating a compiler for python or
> is it just very difficult. Unfortuanatly I am not a
> big compiler guru though I would be willing to help if
> I could. Just curious.
Creating a compiler for Python is difficult and as it isn't really
needed to accomplish most people's goals, nobody has done it. We could
put a bunch of effort into it but we'd come back to that executable that
is basically indistinguishable from the one I could give you today
without the compiler.
Martijn Faassen
> In article <9hj3bb$bdu$8...@newshost.accu.uu.nl>,
> Martijn Faassen <m.fa...@vet.uu.nl> wrote:
>>
>>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.
> It's not mysterious at all: Guido invites you (cadging an invite from
> Guido is an option, of course). But it doesn't take all that much to
> get an invitation; I'm on the list, and I still have not contributed any
> code to Python, and I've only submitted one formal PEP.
Well, when I wanted to know last year, I asked Gordon McMillan and he
said the same thing but made it seem very mysterious. I wasn't in a hurry
so I gave up on it; perhaps that was accomplishing the goal. :)
It must be because Gordon is so high up in the PSU and all...
Martijn Faassen
> [Martijn Faassen]
>> Which is why a system more or less *forcing* core developers to look
>> at these issues *only* for a while may be good.
> Afraid it can't be done: most development comes from volunteer time, and
> volunteers can't be forced to do anything.
Of course, but even volunteers can self-impose restrictions. People
already do that. For instance, there's the restriction that things
don't go in if Guido doesn't like them. This is more or less a
self imposed restriction. So which is why I said 'more or less
forcing'. Actual forcing is of course undesirable, and we should
all be glad it's impossible (PSU excepted).
> If some area is lacking, what it
> needs is new volunteers who *want* to work in that area, and, indeed, want
> to work in that area so much that they'll freely contribute a good part of
> their lives to do so.
Of course this is needed. But a collective mental shift in focus once
every while from core language features to more 'peripheral' work could be
supportive of such people, if nothing else.
If-you're-channeling-Guido-there-goes-the-PEP-I-submitted-last-night-ly yours,
Guido van Rossum
> Aahz Maruch <aa...@panix.com> wrote:
> > In article <9hj3bb$bdu$8...@newshost.accu.uu.nl>,
> > Martijn Faassen <m.fa...@vet.uu.nl> wrote:
> >>
> >>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.
>
> > It's not mysterious at all: Guido invites you (cadging an invite from
> > Guido is an option, of course). But it doesn't take all that much to
> > get an invitation; I'm on the list, and I still have not contributed any
> > code to Python, and I've only submitted one formal PEP.
>
> Well, when I wanted to know last year, I asked Gordon McMillan and he
> said the same thing but made it seem very mysterious. I wasn't in a hurry
> so I gave up on it; perhaps that was accomplishing the goal. :)
Note that the policy has silently changed: if yourelly want to
subscribe, just do it. The moderator will silently subscribe you.
Please do this only if you are serious though!
--Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum
> Which is why a system more or less *forcing* core developers to look
> at these issues *only* for a while may be good.
As the main core developer, I object to this idea and your previous
post on this. Most of the needed library modules simply cannot be
written by me or other core developers because they require specific
application area knowledge that I don't have. (E.g. XML.)
On the other hand, very few folks have the knowledge, understanding
and vision to make changes to the language without breaking it.
So let's all do what we do best: the core developers (e.g. PythonLabs)
improve the language, and the community improves the library.
Brad Bollenbach
However, the issue of compiling Python is brought up /far/ too often.
Consider reading the FAQ. Had you done that, you'd not have asked this
question.
"Eric Merritt" <cybe...@yahoo.com> wrote in message
news:mailman.993870107...@python.org...
Eric Merritt
>
> That's a strange thing to hold against a language.
> How does it affect
> you? I could build an executable for you in either
> Java or Python that
> was indistinguishable from one that was native code
> compiled without
> disassembling it.
>
> If your complaint is that Java (or Python) is too
> slow, I think you
> should say that. If your complaint is that you can't
> write standalone
> binaries in it (you can), you should say that. I'd
> like to understand
> what you really need so I can tell you whether
> Python has what you need
> or not.
I wasn't trashing java as a language (or python for
that matter) they are both good languages, python
being better in my opinion. My complaint was about
speed. Most of the time the speed of java and python
is adiquate, but sometimes I require speed. Also it
would be nice to get a big speed increase by just
compiling. Anyhow, I did not meen it as a complaint
just a nice thing to have.
>
> Creating a compiler for Python is difficult and as
> it isn't really
> needed to accomplish most people's goals, nobody has
> done it. We could
> put a bunch of effort into it but we'd come back to
> that executable that
> is basically indistinguishable from the one I could
> give you today
> without the compiler.
Thats why I asked. Thanks four your reply.
Alex
> Buggered if I know. Perhaps they provide a frictionless method for
> transferring a business's money to consultants.
Yeah, that's what everyone who's used them tells me, but it's hard to
believe, given their ubiquity. :)
Alex.
Barry A. Warsaw
>>>>> "ph" == phil hunt <ph...@comuno.freeserve.co.uk> writes:
>> he PEP champion (a.k.a. Author) should first ttempt to ascertain
>> whether the idea is PEP-able.
ph> How do I ascertain this?
ph> Who decides whether something is a "small enhancement"?
ph> The changes i propose would be two separate PEPs (I assume) --
ph> or would they be added to PEP-42 (which is a list of small
ph> features)?
If you look at PEP 42, you'll see that most of those "small
enhancements" really fix minor limitations, bugs, or misfeatures in
the implementation, or library. An example of a PEP-42'ish small
enhancement (that never actually made it to PEP 42) is to extend
{}.update() to accept any "mapping" object instead of just concrete
dictionaries.
Anything that changes the language is almost by definition PEP-able,
and I would place optional-pass and multiline comments squarely in
that category. Very often, such ideas seem simple on the face of it,
but actually have quite subtle and complex implications on the
language (as you're brief outline of /*...*/ shows!)
-Barry
Terry Reedy
> 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/
Interesting if accurately done. The Python community is small enough that
almost all names are unique. This list needs to combine numbers for people
posting under multiple e-addresses (Guido has use 4). If this is done,
Guido wins with 1829 (654+557+383+235) and Tim is second with 1531
(860+671) [no counting any eaddresses with <64 posts that are not on the
list.
Carlos Ribeiro
>So let's all do what we do best: the core developers (e.g. PythonLabs)
>improve the language, and the community improves the library.
If you say so it's better for us all to listen <wink>. Anyway I would like
to make a distiction concerning PythonLabs work. You are not only
responsible by the language development, but you also define the reference
distribution. Improvements on the library - either by coding new modules or
optimizing existing ones - may be made by the community, as you said, but
that's not any good if these modules don't make it to the standard
distribution.
So I believe that PythonLabs should at least consider doing three things:
- Define clearly what goes and what does not go into the standard library.
I suggest that some guidelines should be written, stating what is needed
for a module to be considered for inclusion into the standard library. The
definition itself may be fairly broad. Quality matters, and the guidelines
spec would help making the decision process more clear.
- Help track the module development process. PEPs could be used for that,
or a different mechanism to track requests could be devised. Sometimes the
community will point out the need for a new module - one that still does
not exist. In this case, a PEP-like document could be written as a kind of
"requirements spec", allowing for anyone interested in contributing to know
what kinds of modules are most requested, and how is the implementation
expected to work. PythonLabs could coordinate this effort. The actual
development could be done by anyone: PythonLabs; volunteers; or even
companies, by donating working code.
- Compile the standard modules for all supported platforms. As someone else
said, many people find it difficult to compile extension modules
themselves. I myself can't do it on my Win98 home machine, as I dont have
VC++ installed (and I doubt many users have it at home).
One advantage of having such a well defined process to elect the standard
modules is that it will encourage people to improve the standard modules,
instead of re-inventing the wheel. After seeing so many half-baked modules
around one must wonder why doesn't people contribute to the existing
alternatives. Having one recognized standard helps. The repository may also
help to solve this problem.
Carlos Ribeiro
Paul Prescod
>
>...
>
> I wasn't trashing java as a language (or python for
> that matter) they are both good languages, python
> being better in my opinion. My complaint was about
> speed. Most of the time the speed of java and python
> is adiquate, but sometimes I require speed. Also it
> would be nice to get a big speed increase by just
> compiling. Anyhow, I did not meen it as a complaint
> just a nice thing to have.
Well, there are Java compilers now (in fact there have been for a long
time) but I would say that if what you need is speed, the best solution
is often to code in Python and then rewrite your inner loops in C. Or
even profile your Python and then optimize it. You'll be amazed how much
speed you can squeeze out if you concentrate on your problem areas.
Bernhard Reiter
Guido van Rossum <gu...@python.org> writes:
> Andrew Kuchling <akuc...@mems-exchange.org> writes:
>
>> It's also a matter of where effort is expended for the most benefit.
> Thanks, Andrew. That was a very good point you made in an otherwise
> "same-old-same-old" thread.
Having started the topic I cannot remember the original point
having been made ever before.
And I explicitly wrote that I did not want to discuss the advantages
and disadvantages of certain features again. :)
Bernhard
--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)
phil hunt
>"phil hunt" <ph...@comuno.freeserve.co.uk> wrote in message
>news:slrn9jq3rc...@comuno.freeserve.co.uk...
>> 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.
>
>Strange. In C++, I always use '//' for multiline comments in favor of
>'/**/'. ('//' in C++ is equivalent to '#' in Python.) This makes the
>comment more readable IMO. Why not just type the comment text first, and
>add '#' marks later?
That's what I do. I still find it an irritating hassle.
I appreciate your point that beginning all comment lines with //
makes for visibility. When I have long multi-line comment, I
usually enclose them like this:
/*********
Start of long comment
:
:
:
end of long comment
*********/
Which I find nice and visible.
Michael Manti
Which editor or IDE do you use that makes commenting such an "irritating
hassle"? I think just about every programming mode in Emacs has a convenient
function and keybinding for commenting--the modes for Python and C/C++
included--and I'd be genuinely surprised if other editors and IDEs didn't
have the same.
Martijn Faassen
>> Which is why a system more or less *forcing* core developers to look
>> at these issues *only* for a while may be good.
> As the main core developer, I object to this idea and your previous
> post on this. Most of the needed library modules simply cannot be
> written by me or other core developers because they require specific
> application area knowledge that I don't have. (E.g. XML.)
But isn't there the role of integration and approval of library
additions and changes to the core library? What about other infrastructure?
It would seem to me there is more to this than just implementation
by itself.
> On the other hand, very few folks have the knowledge, understanding
> and vision to make changes to the language without breaking it.
> So let's all do what we do best: the core developers (e.g. PythonLabs)
> improve the language, and the community improves the library.
(Note that with 'core developers' I meant everybody (presumably on
python-dev mostly) actively working on changes to the core language.)
It strikes me then that there appears to be no real team dealing with
improvements to the standard library then. Of course there are groups of people
such as the XML-SIG which deal with specific issues, but the
important supportive role of integrators seems to be partially
unfilled. Such integrators would actively evaluate new modules for
adoption to the standard library, integrate changes to existing modules,
and look to improving the overal architecture of the library.
(how the parts hang together)
Integration of changes to the standard library happens right now, but
appears to have a lesser priority (due to less interest, surely
not due to lack of expertise) in the minds of the developers of the core
language. Or did I understand you incorrectly?
Would the explicit formation of such a group of people be a good idea?
Such moves might addresses a concern, but only half of the two
concerns my proposal was trying to address.
The other worry is about these continuous changes to the core language.
My idea tried to address is to put some deliberate pause in the development
of core language features. Even though most of us like new features
and I certainly like to talk about them (idly and waving lots of hands,
too), the concern exists, among apparently quite a few people, that
eventually this pattern may lead to a language that doesn't fit in
people's minds comfortably anymore. Of course, we grow with the language,
but we'd also like Python to be easy to understand for beginners
(and to be able to read our own code half a year into the future).
[I really like new features; I generally enjoy thinking about them,
and learning about them and playing with them. Generators, microthreads,
coroutines, optional type annotations, the works! But I might certainly
have been overwhelmed by them as a beginner. Still could be,
especially when reading other people's code that uses them.]
I realize the core developers don't want to stop developing the core
language. It's what they do and like to do. So I proposed something
that could address two possible problems in one go, while still continuing
the language development, albeit at a slower rate.
Another way to address this concern could be by simply taking longer at
releasing new versions of Python (with new features). This is unlikely to
happen, as fortunately the Python core developers have had more time to
focus on developing Python in recent time.
But, how can the concern be addressed then? Should it be? Is the concern
invalid, do you think, and if so, for what reason? Is this a genuine
risk or not?
The issue is of course not an urgent one. But overcomplexity creeping
on us slowly is still overcomplexity; better do something about it
before it hurts, if it is indeed something to worry about.
So-Tim-was-channeling-correctly-ly yours,
Martijn Faassen
> At 12:53 30/06/01 +0000, Guido van Rossum wrote:
>>So let's all do what we do best: the core developers (e.g. PythonLabs)
>>improve the language, and the community improves the library.
> If you say so it's better for us all to listen <wink>. Anyway I would like
> to make a distiction concerning PythonLabs work. You are not only
> responsible by the language development, but you also define the reference
> distribution. Improvements on the library - either by coding new modules or
> optimizing existing ones - may be made by the community, as you said, but
> that's not any good if these modules don't make it to the standard
> distribution.
Ah, just wrote my own reply making a similar point. You make some specific
suggestions, good.
> So I believe that PythonLabs should at least consider doing three things:
> - Define clearly what goes and what does not go into the standard library.
[snip]
> - Help track the module development process.
[snip]
> - Compile the standard modules for all supported platforms.
[snip]
And as I suggested in my post, if standard library development is indeed
not part of the primary sets of interests of the core developers, perhaps
it would be good to set up an semi-formal group that *does* treat this
as their 'core business' (manage core library development and perhaps
even independent releases) A library-SIG, perhaps? Though I'm likely
not reading Guido correctly and running way ahead of myself.
In general, the idea is that perhaps we don't have hundreds of Adrew
Kuchlings (to quote Tim) is because there is no place or group to attract
them. A bit of a chicken and egg problem, of course. :)
(apologies to Andrew :)
Regards,
Martijn Faassen
[I express being mystified over some python-dev subscription
policies]
> Note that the policy has silently changed: if yourelly want to
> subscribe, just do it. The moderator will silently subscribe you.
> Please do this only if you are serious though!
I'm not serious enough right now (too many interests, too little
time and too lazy) to do so, I think, but I'll keep that in mind.
Thanks for letting us know! As I'm sure everybody knows now;
if people read *my* posts (they seem to!) they'd certainly read
yours. :)
Thanks,
Tim Peters
> ...
> 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.
Woo hoo! I pissed away an hour earlier this week trying to find an old
"dining philosophers" Python example (query on the Tutor list), with no
luck. Your archive took me straight to it in a few seconds. So it's
already been worth every penny I paid for it. My thanks to the wizards who
put this together!
a-fat-check-is-in-the-mail-ly y'rs - tim
Tim Peters
> ...
> And as I suggested in my post, if standard library development is indeed
> not part of the primary sets of interests of the core developers,
I'm not sure Guido expressed himself clearly enough there. All the core
developers have done major work on the libraries, so that's not a hangup.
What is a hangup is that people also want stuff the current group of core
developers has no competence (and/or sometimes interest) to write. Like SSL
support on Windows, or IPv6 support, etc. Expert-level work in a field
requires experts in that field to contribute. We also need a plan to keep
their stuff running after they go away again, the lack of which is one
strong reason Guido resists adding stuff to the library.
> perhaps it would be good to set up an semi-formal group that *does*
> treat this as their 'core business' (manage core library development
> and perhaps even independent releases) A library-SIG, perhaps?
Start by adding some meat to PEP 2.
> In general, the idea is that perhaps we don't have hundreds of Andrew
> Kuchlings (to quote Tim) is because there is no place or group to
> attract them. A bit of a chicken and egg problem, of course. :)
Part of what makes Andrew Andrew is that he didn't wait for anyone to take
him by the hand and tell him what to do. He saw things that needed to be
done, and *did* them, fighting when necessary to get his work out into the
world. That's how things get accomplished -- committees and study groups
and Usenet debates don't; even the Python SIGs have, overall, a poor track
record on delivering results (with notable exceptions). You don't need a
group; you need someone able to work and motivated enough to do it without
being pushed.
you-do-it-for-the-glory-or-not-at-all-ly y'rs - tim
Tim Peters
> ...
> So I believe that PythonLabs should at least consider doing three
> things:
A problem is that nobody at PythonLabs has any spare cycles. People can
suggest any number of things we should do for them, but we're already
overloaded -- it simply won't happen.
> - Define clearly what goes and what does not go into the standard
> library.
This is the province of PEP 2:
http://python.sourceforge.net/peps/pep-0002.html
While what's there is fine so far as it goes, it would help if someone added
a second sentence <wink>.
> - Help track the module development process.
> ...
> - Compile the standard modules for all supported platforms.
Good goal, but no way to get there from here: PythonLabs has access to only
a tiny percentage of all the platforms Python runs on. This *has* to come
from the community. There are a few people who contribute outstanding work
here (like Mark Favas for various 64-bit boxes), but to judge from the
initial crush of platform-specific bugs whenever we release an alpha
version, far too few people on "minority" platforms try to build from the
CVS tree. And this despite that compiling Python is more rewarding than
your work and more fun than sex <wink>.
If anyone out there is a knowledgeable fan of some non-Linux non-Windows
platform, they could help a lot just by scouring SourceForge for
platform-specific bug reports and lending a hand. Like, does *anyone* know
how to make threads work on HP-UX? There are always half a dozen bugs open
on that.
> ...
> One advantage of having such a well defined process to elect the
> standard modules is that it will encourage people to improve the
> standard modules, instead of re-inventing the wheel.
PEP 2 is indeed important.
François Pinard
> >Examples are:
> > - augmented Assigments
> > - Lists comprehensions
> > - Simple Generators
(About recent changes, I would sadly add the fact that join/split are now
string methods -- an horrible ugliness that still just cannot tame me!)
> I can't see these as bad things which make Python worse! If you do not
> want to use them - please do so.
Beware the PL/I syndrome. :-)
Quite granted that nobody is forced to use a feature. But when a language
becomes too featureful, people start programming in the subdialect they like
best, later creating difficulties to other wanting to read their programs,
who might like other parts better.
One of the reason behind Python legibility success, is that there is
almost only one way to do one thing (to contrast with Perl, say). We are
progressively sliding away of this virtue. The danger is real.
--
François Pinard http://www.iro.umontreal.ca/~pinard
Martijn Faassen
> [Martijn Faassen]
>> ...
>> And as I suggested in my post, if standard library development is indeed
>> not part of the primary sets of interests of the core developers,
> I'm not sure Guido expressed himself clearly enough there. All the core
> developers have done major work on the libraries, so that's not a hangup.
I figured it was like this. I realize of course that the library has
in a large part been written by the core developers.
> What is a hangup is that people also want stuff the current group of core
> developers has no competence (and/or sometimes interest) to write. Like SSL
> support on Windows, or IPv6 support, etc. Expert-level work in a field
> requires experts in that field to contribute.
This is understood.
> We also need a plan to keep
> their stuff running after they go away again, the lack of which is one
> strong reason Guido resists adding stuff to the library.
Agreed. And some people who make it their central business to keep the stuff
running (either by fixing it themselves or by harassing experts in the
community :) may be a good idea there. Of course it may not.
>> perhaps it would be good to set up an semi-formal group that *does*
>> treat this as their 'core business' (manage core library development
>> and perhaps even independent releases) A library-SIG, perhaps?
> Start by adding some meat to PEP 2.
I'll study PEP 2. :) Oh, done. Yes, this *really* needs more meat.
>> In general, the idea is that perhaps we don't have hundreds of Andrew
>> Kuchlings (to quote Tim) is because there is no place or group to
>> attract them. A bit of a chicken and egg problem, of course. :)
> Part of what makes Andrew Andrew is that he didn't wait for anyone to take
> him by the hand and tell him what to do. He saw things that needed to be
> done, and *did* them, fighting when necessary to get his work out into the
> world. That's how things get accomplished -- committees and study groups
> and Usenet debates don't; even the Python SIGs have, overall, a poor track
> record on delivering results (with notable exceptions). You don't need a
> group; you need someone able to work and motivated enough to do it without
> being pushed.
I realize this, and this is a good point. Of course this is idle
discussion. :)
I may still signal a need for such people before said people get
up and do all the work. :) If this need is very well recognized by the
developers and the community, they may be more welcoming to people
who stand up and the word..
> you-do-it-for-the-glory-or-not-at-all-ly y'rs - tim
Exactly! Right now there is not the feeling that there is much _glory_ in this
activity. Which is why I've been talking about a special 'status' for it.
It doesn't really matter how this is accomplished, but there should be
a feeling in the community that work on the standard library is wonderful,
doable (your patches have a reasonable chance at being studied and accepted)
and desirable.
I'll try to do some work on PEP 2.
Regards,
Guido van Rossum
> Having started the topic I cannot remember the original point
> having been made ever before.
It sounded to me like the usual complaint that Python was acquiring
too many new features. We've gone through endless rounds of that with
Python 2.0 and 2.1.
> And I explicitly wrote that I did not want to discuss the advantages
> and disadvantages of certain features again. :)
So I didn't.
Roy Smith
> 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.
Just out of curiosity, how long must one dislike something before that
dislike graduates from "knee-jerk reaction" to "considered opinion"?
Having now used python for about 4 years, I still think
indentation-for-grouping was a dumb idea. The problem is that it is just
too easy to add or delete whitespace by accident (and without noticing),
especially when cutting and pasting hunks of code from one place to
another. When such whitespace munging makes the code look ugly, it's
simply a minor annoyance. When it changes the meaning of the code, it's a
language design mistake.
The reason people rarely beat up on it anymore is becuase it's a lost
battle. I continue to use python (despite the indenting problem) because
there is enough other stuff in it that I like. But I don't think it's fair
to call it a "knee-jerk reaction".
Andrew Kuchling
> Just out of curiosity, how long must one dislike something before that
> dislike graduates from "knee-jerk reaction" to "considered opinion"?
At that point, it's certainly a considered opinion, because you've
actually used the language and found it to be a problem. I'm mostly
thinking of people who haven't actually used the language at all, yet
will vociferously maintain that it's an insurmountably bad decision.
(Exhibit A: Slashdot, or at least a subset of Slashdot posters.) Once
you've written some actual code using Python, if you still think it's
a problem, well, that's fair enough. There are a few other long-time
users who aren't enamored of the indentation rules, but who grit their
teeth and live with it, so you're not alone.
--amk
Paul Sidorsky
> Having now used python for about 4 years, I still think
> indentation-for-grouping was a dumb idea. The problem is that it is just
> too easy to add or delete whitespace by accident (and without noticing),
> especially when cutting and pasting hunks of code from one place to
> another. When such whitespace munging makes the code look ugly, it's
> simply a minor annoyance. When it changes the meaning of the code, it's a
> language design mistake.
I have to disagree here. I think this is one of the cases when forced
indentation is most valuable. It requires you to inspect the code more
closely so that you KNOW the code was pasted in the way you wanted it.
(This also helps avoid those cases when you're cutting-and-pasting to
make similar blocks of code and you forget to change one of the
blocks.) It also helps maintainability, because you don't end up with a
mess of differently-indented blocks. (Personally I almost always fixup
the indentation immediately in any language (C, Pascal, even HTML) so I
hardly even noticed that it was required in Python.)
Also, I can't count the number of times that I've been cutting C/C++
code and missed a brace. That's a minor thing, but it's nice to not
have to worry about it in Python.
Anyhow, I don't want to say anything more about indentation since it's
probably all been said 2000 times over already.
> The reason people rarely beat up on it anymore is becuase it's a lost
> battle. I continue to use python (despite the indenting problem) because
> there is enough other stuff in it that I like. But I don't think it's fair
> to call it a "knee-jerk reaction".
I don't think that was the implication. I think "knee-jerk" was just
referring to the fact that almost anybody who's done programming in any
mainstream language does indeed react with varying degrees of
"WTF-is-this"-ness when they see Python's indentation characteristics
for the first time.
That being said, you're right - I'm sure there is a sizeable contingent
of experienced Python programmers who dislike the indentation, and that
opinion is definitely valid. But I don't get the sense that opinion
isn't respected. I've only been on python-list/clp for a few weeks, so
when the anonymous person posted "the indentation for grouping thing" I
was expecting her/him to be dismissed as a troll almost immediately.
Instead there was a reasonable discussion about the matter, even though
(as is almost always the case) nobody changed anybody's mind. To me
that said a whole lot!
--
======================================================================
Paul Sidorsky Calgary, Canada
pau...@home.com http://members.home.net/paulsid/
Justin Sheehy
>> 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?
There's a huge amount of value in having a module that is known to be
the de facto standard for a given use added to the standard library.
First off, people new to Python will know that they have it when they
look at the standard library documentation. Python's rich standard
library is one of its big strengths.
Also, once something is part of the standard distribution, it is much
more likely to stick around and continue to have people pay attention
to it. This is a major positive point for long-term stability.
For another point, I'll give a personal datapoint. Part of my job
occasionally involves writing software that will run on a network of
several thousand computers, not all of which have the same
architecture or operating system. Any code that I write or use that
is pure-python other than modules in the standard library is
relatively easy to roll out. If I have to compile and deploy
separate module files for each architecture/OS in order to use a
fairly basic library, the degree of added work is really quite
enormous.
If a module is already considered to be "standard" by the Python
community, and is unencumbered license-wise, adding it to the standard
library helps everyone.
-Justin
phil hunt
>
>Which editor or IDE do you use that makes commenting such an "irritating
>hassle"? I think just about every programming mode in Emacs has a convenient
>function and keybinding for commenting--the modes for Python and C/C++
>included--and I'd be genuinely surprised if other editors and IDEs didn't
>have the same.
I use nedit.
Steve Horne
wrote:
>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.
I interpreted that as not wanting to get bogged down in arguments that
are perfectly well discussed in relation to the PEPs. If we are not
allowed to even mention the cases you mentioned, then surely you are
banning people from using any relevant evidence in counterarguments
;-)
>> 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 :) ).
No - not *just* because it's in other languages, but also because it's
so useful that people don't like to live without it. That really was
the key point I was trying to make - people *want* those features
because they make life easier.
>> 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.
Depends on the particular functional language - some seem to have
ignored the simple fact that infix notation is intuitive, for
instance, but others look remarkably similar to imperative languages.
Besides, Python is not turning into a functional language, it is
merely picking up the features that are genuinely useful, and - once
you get used to them - quite difficult to live without. That basically
means having flexible, intuitive list handling - such as list
comprehensions - but not having to deal with all those
migraine-causing recursive definitions.
>> 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.
Of course there is no point having so many tools you don't know how to
use them all, but I don't think this is the case yet. The question is,
of course - what is the precise definition of a 'small' number?
Python 2.0 and 2.1 added most of the tools that I had missed in the
past. It will be interesting to see what is added in 2.2.
--
Steve Horne
Home : st...@lurking.demon.co.uk
Work : s...@ttsoftware.co.uk
Steve Horne
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...
>
>RS> processed_list = [func(i) for i in old_list]
>
>RS> makes it clear as day!
>
>Not to me it doesn't -- it uses another piece of grammar that I've
>never seen before. To me, it's clear as mud.
I disagree. Just because you haven't seen it before, it doesn't proove
the meaning isn't obvious. On that logic, I'd have to claim the basic
for loop is clear as mud - I never saw a for loop work like that
before Python, yet I understood it the first time I saw it.
As it happens, although I did use a couple of functional languages
once, it was at college many years ago. I'd swear that list
comprehensions did not exist in either LISP or Miranda - at least at
the level I used them. I certainly didn't know what the term meant
until after I'd read some Python docs. Yet I did understand the syntax
on the first glance. After all, it is rather reminiscent of a maths
notation that I learnt when I was about 14 years old - the only
difference being the use of English words rather than wierd symbols.
Besides, the whole point of very high level language is that you don't
have to specify all the low level details of how to implement things.
Instead, you simply specify what you want and let the interpreter do
the rest. That is exactly what list comprehensions give you.
>RS> (I prefer map(), but this is personal)
>
>I would have used map(), too.
Lets examine that...
processed_list = [i * k for i in old_list]
processed_list = map (lambda i, k=k : i * k, old_list)
The first version is more compact - admittedly only a little in this
case, but more so for real examples. It also describes what it does,
making it easier for a Python-newbie to read.
Newbies would probably be tripped up several times by the second
example. The most blatant stumbling block is the lambda - lambda is
not exactly an everyday part of peoples vocabulary, and even if
someone guessed that it was a quick function definition which could be
mysteriously passed as a parameter, they'd certainly be worried by the
'k=k'.
Of course the 'k=k' could be avoided in Python 2.1 - but that's a new
feature. And besides, the meaning of lambda is still not exactly
obvious.
Now lets go a stage further...
processed_list = [cell_fn (x, y) for x in range (max_x)
for y in range (max_y)
if cell_valid (x, y) ]
processed_list = map (lambda j : j [2],
filter (lambda i : cell_valid (i[0], i[1]),
map (lambda x, y : [x, y, cell_fn (x,
y)],
range (max_x), range (max_y)
)
)
)
Clearly the list comprehensions remain much clearer as the list
requirements get more complex. It neatly expresses the idea of listing
all the cell_fn results for the valid cells in an x, y grid. Even more
important, it does not need an intermediate data structure to preserve
the x, y, result mapping as the data propogates through various
functions.
Of course no-one would ever write that kind of map/filter/map
expression for real - at least I hope not. I assume you'd switch to
using a couple of nested for loops and an if to build the list. But
IMO that simply doesn't compare to the list comprehension version for
clarity or convenience.
BTW - that last example was actually substantially simplified from a
real example which I don't have the time to translate/debug using map,
filter etc - yet it took no more than 1 minute to code the original as
a list comprehension, it worked first time, and it is as clear as day
to read.
Steve Horne
>indentation-for-grouping was a dumb idea. The problem is that it is just
>too easy to add or delete whitespace by accident (and without noticing),
>especially when cutting and pasting hunks of code from one place to
>another. When such whitespace munging makes the code look ugly, it's
>simply a minor annoyance. When it changes the meaning of the code, it's a
>language design mistake.
I've never had this problem. I'd say careful cutting and pasting -
generally meaning that when I cut large blocks they are made of
complete lines - was force of habit long before I used Python, simply
because the odds are I'll have to read the code later - and bad
indenting wastes a lot more time than taking care before you cut.
But yes - it is a valid, considered opinion.
Perhaps there would be some justification to wanting block structures
to be marked, and bad indentation could then perhaps cause an error
message to force you to tidy it up. But I don't know. I like Pythons
lack of clutter.
And so we return to the same old personal preferences.
Steve Horne
<akuc...@mems-exchange.org> wrote:
>Roman Suzi <r...@onego.ru> writes:
>> I think improving Python itself is also improving what you've
>> just mentioned.
>
>No it isn't.
It might make some libraries easier and quicker to write, and perhaps
even less prone to bugs. Though of course there is a balance to be
maintained.
Perhaps I should confess to being biassed. I rarely use more than the
basic string and file handling libraries - you know, doing scripting
and glue style things. I'll bet that describes a lot of what Python is
used for.
Python (or rather Jython) is no doubt extremely useful in combination
with Java - but I'm not sure there's any value to trying to compete
directly with Java. Sometimes I think that the drive to proove that
Python can do anything that other languages can do misses an essential
point - Python is extremely good (and getting better) at scripting and
glue style tasks. That is where its main strength lies. Being good at
everything is a pretty tall order.