For review: PEP 308 - If-then-else expression

[Christian Tismer]

James J. Besemer wrote:
> 
>>> James J. Besemer wrote:
...

>>> If it's good enough for Python, the implementation -- then it's good 
>>> enough for Python, the language.
> 
>> Christian Tismer wrote:
> 
>> Great idea!
>> Could you do the same statistics over the usage of switch
>> statements, semicolons, {} braces, and of course MACROS ?
>>
>> With the same reasoning you can introduce every construct
>> to Python. :-)
> 
> Fallacious reasoning.

Just consequently continuing your's. See below.

> Cond. expression is optional in C, as it would be in Python.  Most of 
> the other constructs you mention are necessary in C, and thus there's no 
> comparison.

I left it as an exercise to the reader to find the others.
Well, how about:

switch satements are optional in C, and the whole
interpreter is implemented using switch.
So you will ak for switch.

Macro defines as constants are used widely.
They are optional, you can do everything without them.
In Python, you have to use global variables.

Could continue a while, but the real point lies deeper.

> Some have argued that the conditional expression construct is 
> intrinsically hard to understand.  If this were true, one would expect 
> that the right honorable BDFL would avoid using it in his own code.

Then you misunderstood me.
I don't argue against conditional expressions in C.
I am also not completely against them in Python.
But these languages have very little in common:

- the languages are very different
- the programmers are very different

For that reason, your argument makes really no sense.
You are comparing different people, programming in
different languages. The common set can clearly not
be used as a measure for what is good for all the
Python community.
The Python source is written in a very readable
way, by the world's best C programmers, I guess.
*they* can use any construct of any obfuscated
programming language in a readable manner, since
they are doing their best to get the best out of it.

You might get the false perception that C is readable.
To cure you, I suggest to read something else, try
the Perl sourcecode, for instance. I did that many years
ago and compared it with the Python source. This was
the last spot that made me switch to Python. I can read
the source.

On the other hand, Python has a built-in readability,
and it carefully tries to help the professional by
expressiveness, but also the beginner to produce
readable code from the beginning.

/This/ is an invaluable property of Python which you
find in very few other languages, and /this/ exactly
is what I fear the most could be lost.
The decision is therefore not how much we win, but
an order of magnitude more how much we /loose/!

> My point is that since BDFL clearly sees fit to use it ROUTINELY in his 
> own C code, then it must not materially impair readability nor be all 
> that hard to understand.

He does not abuse it. The Python source is written
in a special style, which I'd call pythonic C.
If something is badly readable, it will be rewritten.
Guido does not design Python for his high level style
of coding, but for everybody.

This is why I'm convinced that your reasoning was
Fallacious reasoning.
And I had to point that out since people might find
your idea obvious. "Obvious" is the most subtle liar.

> Furthermroe, if you took the time to read His cited code, all are 
> examples of things that one might reasonably want to do in a Python 
> program.

Thanks, I did read *all* of his code several times.

>> C has as much to do with Python as the machine code which
>> gcc emits for the C code.

This still holds, and I'd like to augment it:
The coding style of the Python interpreter written by Guido
is totally unrelated to user programs written in Python.

> Your response shows an IRRATIONAL prejudice against C, which I believe 
> drives the bulk of the anti-PEP308 sentiment.

pre-judice? pre-what, please. After reading and coding
millions of C source lines, this is post-judice.

Yes, I am anti-PEP308, for two reasons:
- I don'tlike the proposed syntax
- I don't want the subject to be closed for years

Instead, I want us to come up with a real good
proposal. Nothing against conditional expressions,
but the improvement must be much bigger than the
price to pay. We still have not found it, and we
should refuse to do the vote until we either found
a good (in the common subjective sense of "good"
solution, or we found that it does not exist.

OT:
You are right, I strongly believe that Python should
not be coded in C. C should be used for bootstrap
purposes, generated like assembly input, but not
be written by hand in a larger scale. This is the reason,
why it is so hard/almost impossible to try certain
new constructs for the Python implementation.
Python should be implemented in a high level language.
How this can work will be examined in the Minimal Python
project:
    http://codespeak.net/pypy

I'm asking everybody to join, who wants to
put his spare time into a constructive project,
instead of wasting energy fighting in a lost battle.

less-words-more-code--codespeak -- ly 'rs  chris

-- 
Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/