[Python-3000] PEP 3125 -- a modest proposal
Ron Adam
rrr at ronadam.com
Tue May 8 10:28:56 CEST 2007
Raymond Hettinger wrote:
> [Andrew Koenig]
>> It has occurred to me that as Python stands today, an indent always begins
>> with a colon. So in principle, we could define anything that looks like an
>> indent but doesn't begin with a colon as a continuation. So the idea would
>> be that you can continue a statement onto as many lines as you wish,
>
> Too dangerous. The most common Python syntax error (by far, even for
> experienced users) is omission of a colon. If the missing colon starts
> to have its own special meaning, that would not be a good thing.
>
> If you're in the mood to propose something radical, how about dropping
> the colon altogether, leaving indention as the sure reliable cue and
> cleaning-up the appearance of code in a new world where colons
> are also being used for annotation as well as slicing:
>
> def f(x: xtype, y: type)
> result = []
> for i, elem in enumerate(x)
> if elem < 0
> result.append(y[:i])
> else
> result.append(y[i:])
> return result
>
> It looks very clean to my eyes.
So no more single line definitions?
If you think of the colon as meaning, 'associated to', it's use is both
clear and consistent in all cases except when used in slicing.
I also think it helps the code be more readable because when its used in
combination with indenting because it looks more like a common outline
definition that even non-programmers are familiar with. So it may have
value in this regard because it makes the intent of the code clearer to new
users.
Removing it may blur the difference of block headers and block bodies in
the mind. The computer may not need it, but I expect it helps us humans
keep things straight in our heads.
So maybe a more modest proposal is to change the colon in slicing to a
semi-colon where it can have it's own meaning.
def f(x: xtype, y: type):
result = []
for i, elem in enumerate(x):
if elem < 0:
result.append(y[;i])
else:
result.append(y[i;])
return result
Cheers,
Ron
More information about the Python-3000
mailing list