Other syntax ideas and feature ideas for Python 3.0.

TableOfContents()

Optional Static Typing / Adaptation

• [http://www.artima.com/forums/flat.jsp?forum=106&thread=85551 Adding Optional Static Typing to Python] - article by Guido with responses

• [http://groups-beta.google.com/group/comp.lang.python/messages/a7960bedeffdf36b,9ff25b65c3523b32,ea183c14193161d8,b0f5feee912db455,4888ee248493142e,f96c9f8f1d65b439,dc16b1ac3c356751,7f95e63c5f791a07,c6afe85be43223db,b0de4d002834507d?thread_id=8ed8632b8c5a551a&mode=thread&noheader=1&q=optional+static+typing#doc_a7960bedeffdf36b "Optional Static Typing" thread]

• [http://groups-beta.google.com/group/comp.lang.python/messages/03553183983059e9,b505ef98e0436d24,dad1a48eee3248a4,7fac43f511f6bb21,ee614add572c34b1,7030280781fef1dc,6a852f4133c86be5,3a695733220ba136,4bec8d2fefbc0ce6,45b123013d82a365?thread_id=ff4df85e58d128bc&mode=thread&noheader=1&q=optional+static+typing#doc_03553183983059e9 "Adding static typing to Python" thread]

Lambda / Anonymous Methods / Closures

• AlternateLambdaSyntax

• Anonymous Methods / Closures

• [http://groups-beta.google.com/group/comp.lang.python/browse_frm/thread/81e17b1d3ccba538/41713ae1c0d7385a#41713ae1c0d7385a "Securing a future for anonymous functions in Python" thread]

• http://boo.codehaus.org/Closures

• http://logix.livelogix.com/tutorial/5-Standard-Logix.html#5.8 (uses same syntax as above except no multi-line support)

".." Sequences, Custom Infix Operators

• http://logix.livelogix.com/intro.html

• [http://groups-beta.google.com/group/comp.lang.python/browse_frm/thread/6fb45278f4a24648/93ce3e9a08f5e4c7#93ce3e9a08f5e4c7 "Other notes" thread]

Improved default value logic for Dictionaries

• The setdefault() method is badly named and poorly designed. In a typical call, d.setdefault.(k, []).append(v), the list may be unnecessarily instantiated and discarded on every call. At a minimum, default value should be a new empty list instead of None:  d.setdefault(k).append(v) .

• A more versatile idea is to realize that defaults generalize to the whole dictionary instead of an individual lookup. A call to setdefault would then change the whole dictionary's behavior when a key is not found:

    counts = {}
    counts.setdefault(value=0)
    for elem in data:
        counts[elem] += 1

    index = {}
    index.setdefault(function=list)
    for pageno, page in enumerate(pages):
        for line in page:
            for word in line.split():
                 index[word].append(line)

Better boolean logic

The and/or operators should only return boolean values. This makes their use less error-prone, less prone to abuse, and more closely match other languages. Also, it will simplify the underlying bytecode which currently inserts many POP_TOP instructions to complete conditionals. The need to insert these instructions also results in extra code paths and jump instructions. Overall, the language will become more intuitive, more reliable, simpler, and faster.

Disallow calling class methods from instances

Calling with a instance is almost never what you want. When it is done, the results are not especially readable, and the code suggests that it is doing something that it isn't:

{'a'=1}.fromkeys('poof') # what happened to 'a'? 

Simplify the syntax for raising exceptions

• Eliminate string exceptions entirely.

• Alway require instantation. IOW, prefer raise ValueError(dat) to raise ValueError, dat.

• Require that all exceptions subclass from Exception.

• Have Exception be a new-style class

Fix implementation of in-place operators

The current implementation will call __iadd__(), allowing it to do the in-place change, but then require that the method return the new value and then store it again. Ideally, all the responsibility for the update should lie with the __iadd__() method and it should return None. This simplifies the bytecode and eliminates some annoying behavior (such as a[0]+=1 succeeding and raising an error when a=([0],).

Remove the distinction between data and non-data decriptors

Having the distinction provides a tiny benefit but incurs a large cost in terms of implementation complexity and increasing the learning curve for descriptors. Using the presence or absence of a setter to distinquish the two is somewhat hackish and confuses the heck out of anyone first trying to master descriptors. Even after using descriptors for a while, that nuance remains an annoying distraction.

Reconsider the inclusion of __slots__ or re-evaluate its implementation

Guido has expressed that this is a highly popular, but badly misunderstood tool that is often used incorrectly.

• If __slots__ is misspelled, there is no visible indication of failure.

• The purpose of the tool is not to make it more difficult to assign attributes.

• __slots__ do not inherit.

• __slots__ complicates and slows the implementation of new-style classes.

Use iterators instead of tuples in argument parsing when applicable

This would allow code like:

   1 >>> def f(x, y, *args):
   2 ...     print x, y, repr(args)
   3 ...
   4 >>> f(*itertools.count())
   5 ... 0 1 'count(2)'

Currently, this code causes an infinite loop because Python's argument parsing mechanism fully expands an iterator into a tuple when used in a *args context as above. When iterators are the standard, I would hope that instead of fully expanding the iterator, only the elements from the iterator necessary to fill positional arguments would be extracted. See the thread "Python 3000, zip, *args and iterators" #a 1 for more discussion of this idea and a real life example of where this might be useful.

• Dare I even suggest that a ***args form could be used in some bizarre way? Personally I think the idea is unspeakably ugly. --JimD

  On the other hand I've often wished for something like: (a, b, *c) = foo.parse(filedescriptor.readline()) which would unpack the first arg into a, the next into b, and the rest into c. This desire is probably the result of years of shell scripting where I routinely use code like ps fax | while read pid x x x cmd args; do ... and don't care if args is empty or contains an interminately long list of items. I'm still not sure I'd seriously recommend it to Python. --JimD

  • Note that my proposal is not this extreme; I'm still only talking about *args in a function definition. All I'm suggesting is that since only the first N items of the iterator are needed, there's no need to convert the entire iterator into a tuple. Just pop off the necessary items from the front of the iterator and bind the args variable to the iterator containing the remaining items. The only change this makes to the language is that *args names in function definitions will be bound to iterator objects instead of tuple objects. -- StevenBethard

Anchor(a) [1] Python-List -- Python 3000, zip, *args and iterators: http://mail.python.org/pipermail/python-list/2004-December/257282.html