This is an HTML version of the original MS Word document. To see change bars on latest revisions, you can access the original by changing .htm to .doc in your web browser.
Goal: Simple unambiguous syntax for cloning objects and for inheriting functions and data from existing objects.
Migration: Easy. Python "clones" objects from classes, so it will be easy for an auto-translator to tell whether Python is cloning an object or calling a function.
Status: 4/2/04 decision on syntax postponed until fundamental operations worked out. Do we really need constructors?
q = boink(x)
Is q the value returned by the function boink, or a new boink object?
q = p; q = p(); q = clone p < or q = p.clone >
It's an alias; a function call; a cloned object.
q = clone p ( arg1, arg2 ) < or q = p.clone( arg1, arg2 ) >
It's a new working object needing two arguments to the constructor.
P3 = inherit( q, P1, P2 )
It's a new prototype object, inheriting from q, P1, and P2.
inherit( q, P1, P2 ) makes a prototype from multiple objects. clone P1 makes a clone of a single object and runs its constructor ( a function with a special name __init__,if it exists.)
Notes:
1) Cloning is done from a single object (prototype or instance). The inherit function is needed only when multiple inheritance is necessary. This should be taught *after* students are comfortable with the simple 'clone' syntax ( including arguments to the constructor ).
Objections:
1) Cloning an object is an internal feature of the language that users should not be made aware of. The user interface should be made to look just like a function call.
Discussion:
1) Cloning is a unique and perhaps even central feature of Python. Compared to a function call, there is extra overhead in memory usage and CPU time, which may be significant to some users. See http://lists.prothon.org/mailman/listinfo/prothon-user March 2004 "create objects" for further discussion.
Goal: Provide an easy break out of deeply-nested loops. Eliminate the continue keyword, and make all the variations of break self explanatory.
Migration: Easy. break top and break end are one-for-one with Python. Others are pure enhancements.
NextPage: for page in website:
...
NextSection: for section in page:
...
InitParser: ... # clear stack and set max length
for tag in section:
...
if err: break top # skip current tag
if done: break end # end section early
if err>2: break InitParser # try again with reset
if err>5: break NextSection # abandon section
if err>10: break NextPage # abandon page
if err>20: break Done # give up
print >> outfile, results
Done: pass
Notes: A simple 'break' with no qualifier is equivalent to 'break end'. 'continue' is equivlent to 'break top'.
Question: Would 'out' be a better qualifier than 'end' ?
Objections:
This feature could be abused to achieve a general GOTO.
while True: break <anywhere>
Discussion:
Current implementation restricts break tags to just loop statements. This will not stop users from adding dummy loops.
See [Prothon-user] Prothon Syntax 4/1/04
.x0 = 0; .y0 = 0
.move = def(x,y): < or .move(x,y) : >
.x0 = x; .y0 = y
name! .sort! .reverse! .append!
integer?() isfile?() exists?()
Allow either (...) or [...]. Use name! to indicate mutable lists.
window1.pane2.xaxis.label.font.size = 12
Should be as easy as simple name assignment.
See Extension Syntax for more complete examples and discussion.
print @f=myfile x, y, z
Eliminate >> print wart, change default spacing, etc.
def @generator f(x,y): < or .f = @generator def(x,y): >
Extend function syntax to allow generators, static methods, type checking, etc.
@x,y:x*x+y*y < or @(x,y): x*x + y*y >
Compact (nameless) functions. Eliminate lambda verbosity and confusion.
raise @<test>, <data>
Treat oddball assert statement as a normal exception.
Goal: Allow the advantages of tabs, without the hidden and uncontrollable effects.
Status: Rejected 3/30/04. Decided to allow all spaces or all tabs, but no mix in the same file. Indentation is not a problem for the writer with a good code editor. This proposal would be a benefit only for readers who must use a program inappropriate for viewing code.
import os, shutil
def dump_module_contents (M):
. print M.__doc__
. keys = dir(M)
. for k in keys:
. . if not k.startswith('__'):
. . . v = M.__dict__[k]
. . . print "%s:\t%9d\t%s" % (k, id(v), v)
def grab_contents (M):
. d = {}
. for k, v in M.__dict__.items():
. . if not k.startswith ("__"):
. . . d[k] = v
. return d
The dot-space style of indentation is particularly advantageous in deeply nested code that spans page boundaries. To avoid extra typing, the code editor should translate the tab key to the desired dot-space sequence. This style can be made compatible with normal space-only indentation by having the interpreter ignore any leading isolated dots.
The advantages of tabs are:
a) Minimum typing in code editors that don't auto-indent.
b) Each programmer can set the preferred tab spacing.
c) Two or more extra tabs can indicate a continuation line.
The use of tabs for indentation is bad, however, because many programs (particularly email and news readers) mess up the tabs. This causes problems with code snippets in such programs.