[Python-ideas] Documenting Python warts on Stack Overflow

Wed Jan 2 00:57:00 CET 2013

On 02/01/13 09:16, Chris Angelico wrote:
> My understanding of a "Python wart" is that it's something that cannot
> be changed without readdressing some fundamental design. For example,
> Python has decided that indentation and line-endings are significant -
> that a logical statement ends at end-of-line. Python has further
> decided that line continuation characters are unnecessary inside
> parenthesized expressions. Resultant wart: Breaking a massive 'for'
> loop between its assignment list and its iterable list doesn't work,
> even though breaking it anywhere else does.

A truly poor example.
You can't break a for loop between its assignment and iterable for the
same reason you can't break any other statement at an arbitrary place.
That's not how Python does things: statements must be on a single logical
line.
> (This question came up on
> python-list a little while ago.) Why should it be an error to break it
> here, but not there? Why can't I split it like this:
>> for x,y,z in
> start_point,
> continuation_point,
> end_point
> :
> pass

As you say above, logical statements end at end-of-line. There is an
end-of-line following "for x,y,z in". Why would anyone think that you
should be able to split the statement there?
- is there a line-continuation that would let you continue over multiple
 physical lines? no
- is there a parenthesized expression that would let you continue over
 multiple physical lines? no
None of the conditions for splitting statements over multiple physical
lines apply, and so the standard rule applies: statements end at
end-of-line. This is not a wart any more than the inability to write:
y =
 x +
 1;
is a wart. Maybe you're used to being able to do that in some (but not
all) semi-colon languages, but they are not Python, any more than
Python is Forth where you might be used to writing:
x 1 + y !
To some degree warts are in the eye of the beholder, but failure of
Python to be "just like language Foo" is not a wart.
> when it's perfectly legal to split it like this:
>> for (
> x,y,z
> ) in (
> start_point,
> continuation_point,
> end_point
> ):
> pass
>> Well, because you can't. It's a little odd what you can and can't do,

"Why can't I drive straight through red lights, when I'm allowed to
drive through green lights? That's a little odd!"
No it is not. It is a fundamental aspect of Python's syntax.
> until you understand the underlying system fairly well. It's something
> that's highly unlikely to change; one of the premises would have to be
> sacrificed (or at least modified) to achieve it.
>> Something that could be changed if the devs had enough time is a
> tracker issue (or a "show me some code" issue - you want to complain,
> you can do the work to fix it). Something that could be changed, but
> would break backward compatibility is a prime candidate for __future__
> and/or Python 4 (like the change of the division operator - that
> change introduced its own oddities, some of which may be warts, eg
> that int/int->float but sqrt(float) !-> complex).

Are you talking about math.sqrt or cmath.sqrt or some other sqrt?
In general, Python 3 now extends float to complex under regular arithmetic:
py> (-100.0)**0.5
(6.123031769111886e-16+10j)
math.sqrt(-100.0) on the other hand continues to raise, because the math
module is by design limited to producing real-values. cmath.sqrt(-100.0)
continues to give a complex result, again by design.
-- 
Steven