Status of PEPs?

[Thomas Reichelt]

Hello Python-Fans,

A few months in the past, I learned the Python language and was very pleased
of it. I have now written many scripts for myself and this opinion stayed,
not to say, it became more intensive.

Recently I have discovered the PEP Archive, and my question is now this:
There are many open ("under consideration") PEPs that would incorporate
useful features into the language, such as the do-while statement, the
switch statement or the __main__ function. However, most of these proposals
are several years old. Though implementations seem to exist for the
proposals, no action is taken about them. Why is this so? What has to be
done for a proposal to make it into the language?

Thank you for answering a dumb question...

 

[John Roth]

Hello Python-Fans,

A few months in the past, I learned the Python language and was very pleased
of it. I have now written many scripts for myself and this opinion stayed,
not to say, it became more intensive.

Recently I have discovered the PEP Archive, and my question is now this:
There are many open ("under consideration") PEPs that would incorporate
useful features into the language, such as the do-while statement, the
switch statement or the __main__ function. However, most of these proposals
are several years old. Though implementations seem to exist for the
proposals, no action is taken about them. Why is this so? What has to be
done for a proposal to make it into the language?

Thank you for answering a dumb question...

It's not a particularly dumb question. The missing piece is that there
are a limited number of core developers, and you need to get a
concensus among them on the Python Dev mailing list that this
particular proposal is more worthy of their time than other
competing proposals. You also need to get it past Guido. Also
note that in two cases you would be adding keywords, which
impose a significant forwards compatibility issue, while the
third has a major issue of non-obviousness.

The proposals you mention all fall into the category of "useful,
but there are other ways of doing that job that work, are well
accepted, and are not a significant burden in terms of either
developer time or comprehensibility."

Put another way, there was a significant against component in the
discussion from the "keep Python simple" crowd.

In other words, to move any of them forward would require submission
of a complete implementation that would work in the current
development tree, together with the necessary documentation
changes, thorough tests, and so on and so forth. That is, someone
who wants to see any of these in Python needs to do the work
themselves.

A good example of this is the work being done by Facundo Batista
on PEP 327 (Decimal Arithmetic). There's been widespread
agreement for a long time that something should be done about
decimal arithmetic, but until he stepped forward, it sat on dead
center. Now it looks like we're going to get it for Python 2.4,
so it may be possible for us to get a usable currency type in
Python 2.5 (building on the decimal type.)

John Roth

 

[Terry Reedy]

Hello Python-Fans,
Recently I have discovered the PEP Archive, and my question is now this:
There are many open ("under consideration") PEPs that would incorporate
useful features into the language, such as the do-while statement, the
switch statement or the __main__ function. However, most of these proposals
are several years old. Though implementations seem to exist for the
proposals, no action is taken about them. Why is this so? What has to be
done for a proposal to make it into the language?

Last question first: one of the initial PEP discusses the PEP approval
process.

Previous question: last step is approval by GvR, which, I believe, requires
a request for a yea/nay decision, which PEP writers may not bother to do
when they expect a nay, at least at the current time. I agree that this is
not helpful for a newcomer who has not read the discussions here for
several years.

Terry J. Reedy

 

[Thomas Reichelt]

It's not a particularly dumb question. The missing piece is that there
are a limited number of core developers, and you need to get a
concensus among them on the Python Dev mailing list that this
particular proposal is more worthy of their time than other
competing proposals. You also need to get it past Guido. Also
note that in two cases you would be adding keywords, which
impose a significant forwards compatibility issue, while the
third has a major issue of non-obviousness.

The proposals you mention all fall into the category of "useful,
but there are other ways of doing that job that work, are well
accepted, and are not a significant burden in terms of either
developer time or comprehensibility."

Put another way, there was a significant against component in the
discussion from the "keep Python simple" crowd.

In other words, to move any of them forward would require submission
of a complete implementation that would work in the current
development tree, together with the necessary documentation
changes, thorough tests, and so on and so forth. That is, someone
who wants to see any of these in Python needs to do the work
themselves.

A good example of this is the work being done by Facundo Batista
on PEP 327 (Decimal Arithmetic). There's been widespread
agreement for a long time that something should be done about
decimal arithmetic, but until he stepped forward, it sat on dead
center. Now it looks like we're going to get it for Python 2.4,
so it may be possible for us to get a usable currency type in
Python 2.5 (building on the decimal type.)

Thank you for your explanation. What I don't understand, though, is that the
PEPs for which an implementation exists aren't discussed further, but are
just lying around in a corner, though there is a significant advantage in
the PEP's proposal. I understand that the introduction of a new keyword is
a drastic change, but Python has good capabilities to compensate for that
(from __future__ ...).

It is clear that most of the proposed syntactic enhancements can be rebuilt
with the existing language, but sometimes only with code duplication or
clumsy constructs.

 

[Ville Vainio]

Thomas> Thank you for your explanation. What I don't understand,
Thomas> though, is that the PEPs for which an implementation
Thomas> exists aren't discussed further, but are just lying around
Thomas> in a corner, though there is a significant advantage in
Thomas> the PEP's proposal. I understand that the introduction of
Thomas> a new keyword is

Even if something has a significant advantage, it's might not be
significant enough to warrant bloating the language. The cost of
implementing a feature is trivial compared to the cost of increased
language complexity. In that way python is different from perl or
ruby, where everything that someone bothers to provide a patch for
gets included.

Thomas> It is clear that most of the proposed syntactic
Thomas> enhancements can be rebuilt with the existing language,
Thomas> but sometimes only with code duplication or clumsy
Thomas> constructs.

Many features are only attractive because some other language has it,
and people mistakenly believe that python should have it too. do-while
is an example of a worthless feature that people think they want, but
that really adds nothing to


while 1:
do stuff
if condition:
break

 

[Thomas Reichelt]

Ville Vainio wrote:

Many features are only attractive because some other language has it,
and people mistakenly believe that python should have it too. do-while
is an example of a worthless feature that people think they want, but
that really adds nothing to


while 1:
do stuff
if condition:
break

Well, in my opinion this kind of defeats the purpose of a while-loop. The
original intention is to test the condition in the while-statement, and not
to set up an infinite loop and break out somewhere. The behavior of while
(1) { } even generates a warning in other languages...

 

[Ville Vainio]

Thomas> Well, in my opinion this kind of defeats the purpose of a
Thomas> while-loop. The original intention is to test the
Thomas> condition in the while-statement, and not to set up an

Original intention for whom? You can imagine "while 1:" as an alias
for "loop:", i.e. an eternal loop.

The distrust of 'while 1' just needs to be unlearned, which is a
matter of education.

Thomas> infinite loop and break out somewhere. The behavior of
Thomas> while (1) { } even generates a warning in other
Thomas> languages...

That's because 1 is not a conditional statement. It needs to be
spelled out as "while(true)", or "for (;" in boolean-challenged old
c++.

 

[Neil Benn]

Thomas> Well, in my opinion this kind of defeats the purpose of a
Thomas> while-loop. The original intention is to test the
Thomas> condition in the while-statement, and not to set up an

Original intention for whom? You can imagine "while 1:" as an alias
for "loop:", i.e. an eternal loop.

The distrust of 'while 1' just needs to be unlearned, which is a
matter of education.

Thomas> infinite loop and break out somewhere. The behavior of
Thomas> while (1) { } even generates a warning in other
Thomas> languages...

That's because 1 is not a conditional statement. It needs to be
spelled out as "while(true)", or "for (;" in boolean-challenged old
c++.

Hello,

Hmm, respectfully - I disagree with that - I think that
while(true) is horrible. When reading through code - I expect something
like :

while <this statement == true>, keep repeating

So for while(true), I read :

while <true == true>, keep repeating

The use of the break statement is non-obvious to me, a flag to
escape the loop is more typing but avoids the while(true) - which IMO
compilers for many languages throw warnings about. The ideal thing to
me would be to declare a flag (if needed) in the definition of the while
statement which would limit the scope to exactly the correct field. I
also agree however that do/while is not needed as flags work equally as
well.

It's a matter of syntactical reading of code and a philosophical
point. I must admit that there are some constructs commonly used in
Python that make me cringe (throwing exceptions as a matter of
convenience when you could detect that situation and not throw the
exception in the first place - for example) - however and this is the
important point, if these constructs are in common use in a language,
you basically just have to accept them and move on. Life is too short!!

Have a good weekend!

Cheer,

Neil

--

Neil Benn
Senior Automation Engineer
Cenix BioScience
BioInnovations Zentrum
Tatzberg 47
D-01307
Dresden
Germany

Tel : +49 (0)351 4173 154
e-mail : (e-mail address removed)
Cenix Website : http://www.cenix-bioscience.com

 

[Ville Vainio]

Neil> Hmm, respectfully - I disagree with that - I think that
Neil> while(true) is horrible. When reading through code - I expect
Neil> something like :

Neil> while <this statement == true>, keep repeating

Neil> So for while(true), I read :

Neil> while <true == true>, keep repeating

My brain immediately converts 'while 1' to 'loop forever' when it is
seen in code.

Neil> The use of the break statement is non-obvious to me, a flag
Neil> to escape the loop is more typing but avoids the while(true)
Neil> - which IMO compilers for many languages throw warnings
Neil> about. The ideal thing to

If you get a warning, use 'for (;'. Some environments (Symbian OS)
define a FOREVER macro, but I don't really see the point.

There are two highly idiomatic ways to use while 1:

while 1:
a = getobject()
if a is None:
break # flag doesn't work, you'd need to do "continue"
process(a)
morestuff(a)


while 1:
dostuff()
done = morestuff()
if done:
break


Neither really benefit from the flag approach. For both cases, it's
obvious that the break applies for 'while 1' condition.

Neil> important point, if these constructs are in common use in a
Neil> language, you basically just have to accept them and move
Neil> on. Life is too short!!

My advise would be that if something deeply bothers you in Python
design, it's better first to explore why you feel that way, and
whether the problem could really be with your own preconceptions and
expectations. For me, that has been the case on several occasions.

And believe me, as a C++ programmer, I don't hesitate to question the
decisions of language designers. After a decent amount of C++
exposure, Python's flaws seem ridiculously small.

 

[Heather Coppersmith]

while 1:
a = getobject()
if a is None:
break # flag doesn't work, you'd need to do "continue"
process(a)
morestuff(a)

keep_trying = True
while keep_trying:
a = getobject( )
if a:
process( a )
morestuff( a )
else:
keep_trying = False

Or:

a = getobject( )
while a:
process( a )
morestuff( a )
a = getobject( )

although some people dislike the redundancy more than the extra flag or
the break statement.

OTOH, these arguments have all been had before. Google for things like
"loop and a half."

Regards,
Heather

 

[Duncan Booth]

keep_trying = True
while keep_trying:
a = getobject( )
if a:
process( a )
morestuff( a )
else:
keep_trying = False

Or:

a = getobject( )
while a:
process( a )
morestuff( a )
a = getobject( )

Or for those of a less masochistic inclination, just use a for loop:

for a in iter(getobject, None):
process(a)
morestuff(a)

 

[Ville Vainio]

Duncan> Or for those of a less masochistic inclination, just use a
Duncan> for loop:

Duncan> for a in iter(getobject, None):

Cute. For those too lazy to check:

iter(callable, sentinel) -> iterator

Get an iterator from an object. In the first form, the argument
must supply its own iterator, or be a sequence.

In the second form, the callable is called until it returns the
sentinel.

(I bet many, including me, haven't heard of this).

It kinda loses some of its appeal when getobject() takes arguments,
though - you'll have to go for lambda then:

for a in iter(lambda : getobject(2,"hi"), None):

 

[Aahz]

A good example of this is the work being done by Facundo Batista on PEP
327 (Decimal Arithmetic). There's been widespread agreement for a long
time that something should be done about decimal arithmetic, but until
he stepped forward, it sat on dead center. Now it looks like we're
going to get it for Python 2.4, so it may be possible for us to get a
usable currency type in Python 2.5 (building on the decimal type.)

Just for the record, I actually started Decimal.py with a lot of help
from Tim Peters, and then Eric Price moved it forward quite a bit before
Facundo picked it up. I don't care that much about the credit for me,
but I think it's important to remember that Open Source projects are
usually the result of collaboration from many people.

 

[Tim Peters]

[Aahz]

Just for the record, I actually started Decimal.py with a lot of help
from Tim Peters, and then Eric Price moved it forward quite a bit before
Facundo picked it up. I don't care that much about the credit for me,
but I think it's important to remember that Open Source projects are
usually the result of collaboration from many people.

That's right. There's no way this module could have gotten in to 2.4
if any one of Aahz, Eric Price, Facundo Batista, or Raymond Hettinger
hadn't contributed major effort to pushing it through its development
phases -- or if IBM's Mike Cowlishaw hadn't devoted years to studying
the issues and crafting a complete, coherent standard for decimal
arithmetic, then made it and extensive test vectors freely available
over the web. It could well have made it without me -- but it would
have sucked then <wink>.