On 10 December 2011 14:16, Richard Prosser <richard.prosser@mail.com> wrote:
Although I love Python there are some aspects of the language design which are disappointing and which can even lead to problems in some cases.

A classic example is a mutable default argument having the potential to produce unexpected side-effects, as a consequence of the non-intuitive scoping rules.

The default argument "problem" is not intuitive (and does need highlighting to people new to Python). But it is still better than the alternatives. It isn't to do with scoping but when the default arguments are evaluated. If instead the default values were evaluated at call time, what would the following code do:

a = 3
def function(arg=a):
del a

In addition you have added extra overhead cost to each function call (argument evaluation). Plus Python exposes the default arguments to introspection. If the default arguments aren't evaluated until call time you lose that capability.

Another awkward 'feature' is the requirement for a trailing comma in singleton tuples, due I believe to the use of expression parentheses rather than (say) the use of special brackets like chevrons.

Well, parentheses are only part of the syntax for an empty tuple: ()

For non-empty tuple literals it is *only* the commas that are significant.

    single = 1,
    double = 2, 3

So although the syntax for a single member tuple does feel a bit awkward I wonder what alternative you would suggest?

Something that I personally wish for is the ability to declare variable types 'up front' but that facility is missing from Python.

That runs counter to the basic principles of Python where types are determined at runtime. What effect would declaring types have and how would that interact with the rest of the language? (Do you want every assignment to do a runtime type check?)

This is an important issue, so I propose that the Python tutorial be updated to highlight such problems. I would be willing to write a draft section myself but obviously it would need to be reviewed.

This is a good idea however. :-) Just do it. Create a documentation patch (for Python 3) and attach it to an issue in the bug tracker:

I am not sure if this is the appropriate place to make such a comment but it seems to be a good starting point. Any advice on making a more formal proposal would be welcome.


Richard Prosser
PS Is it too late to fix such warts in version 3?

For the issues you've raised, yes. Unless you have specific proposals that don't break backwards compatibility.

All the best,

Michael Foord


Python-ideas mailing list


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html