Ideas for Python Enhancements

These are some notes on random ideas I've had, scribbled down here so I don't forget them. Maybe they'll turn into PEPs one day. Or maybe not.

Set constructors

If the colon and value part of an item of a dictionary constructor could be omitted, with the value defaulting to 1 or some other suitable value, you would be able to write
{42, "spam", 88.8}
which not only gives you a dict implementing a set, it looks like a set too!

Line continuation

The use of a backslash to signify line continuation is, in my opinion, one of the very few ugly things about Python syntax. The tragedy is that it's not even necessary! Indentation could perfectly well be used to infer continuation of an expression or statement over multiple lines, e.g.
fred = spam + (ham - eggs) *
  sqrt(lettuce / tomato)

Multi-line über-raw string literals

Raw strings and triple-quoted strings are interesting innovations, but they have some problems. Raw strings aren't completely raw -- you still need to escape embedded quotes, and there's no way to end one in a backslash. Triple-quoted strings don't blend in well with the indentation structure of Python code -- unless you can tolerate spurious whitespace at the beginning of each line of the string, you have to put it all the way over to the left. And the first and last lines are cluttered up with the intrusive triple-quote characters themselves, which is a pity because otherwise the contents of the string would appear in the code in a WYSIWYG fashion.

My solution to all of these problems is a new statement:
string my_string_literal:
  |  The string can contain any characters whatsoever, without
  |the need for any quoting or escaping. Everything up to and
  |including the leading | character is stripped off. There is
  |no newline after the last line; if you want the string to
  |end in a newline, a blank line must be appended, as in this
  |example.
  |

Unpacking with a *-argument

It should be possible to say:
a, b, c, *d = sequence

Overridable properties

The property constructor should accept method names to be looked up when the property is accessed. This would allow overriding of property accessors in subclasses without re-defining the whole property.

class C(object):

    def get_foo(self):
        return 'C.foo'

    c = property('get_foo')


class D(object):

    def get_foo(self):
        return 'D.foo'

A nicer lambda syntax

arglist -> expr

Examples:

x -> x.foo

(x, y) -> x * y

-> [] # The no-argument case should be really concise.

Documenting the syntax

Certain aspects of Python's syntax, particularly the parameter list of a def statement, are difficult to describe formally using a BNF-like notation in a way that's easy for a human to follow.

Railroad diagrams may be better for this. Here's the def parameter list described using a railroad diagram:




--