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

--
greetz tom

[John Roth]

"Thomas Reichelt" <XX********@gib ts.net> wrote in message
news:2k******** ****@uni-berlin.de...

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 comprehensibili ty."

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


--
greetz tom

[Terry Reedy]

"Thomas Reichelt" <XX********@gib ts.net> wrote in message
news:2k******** ****@uni-berlin.de...

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]

John Roth wrote:

"Thomas Reichelt" <XX********@gib ts.net> wrote in message
news:2k******** ****@uni-berlin.de...

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 comprehensibili ty."

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.

--
greetz tom

[Ville Vainio]

>>>>> "Thomas" == Thomas Reichelt <XX********@gib ts.net> writes:

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
--
Ville Vainio http://tinyurl.com/2prnb

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

--
greetz tom

[Ville Vainio]

>>>>> "Thomas" == Thomas Reichelt <XX********@gib ts.net> writes:

while 1:
do stuff
if condition:
break

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

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

[Neil Benn]

Ville Vainio wrote:

>>"Thomas " == Thomas Reichelt <XX********@gib ts.net> writes:
>>
>> >> while 1:
>> do stuff
>> if condition:
>> break

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 : [phone]
e-mail : be**@cenix-bioscience.com
Cenix Website : http://www.cenix-bioscience.com

[Ville Vainio]

>>>>> "Neil" == Neil Benn <be**@cenix-bioscience.com> writes:

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.

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

[Heather Coppersmith]

On 02 Jul 2004 15:37:30 +0300,
Ville Vainio <vi***@spammers .com> wrote:

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

--
Heather Coppersmith
That's not right; that's not even wrong. -- Wolfgang Pauli