builtin: add dir builtin

[sbinet]

Fixes #12.

[sbinet]

this is a WIP.

@ncw, for dir(), I need to be able to get at the content of the local scope.
how would I do that from within builtin_dir ?

[ncw]

The way I've done that in the past, eg for implementing locals() is to implement them as InternalMethods.

Eg here is where the magic is...

gpython/vm/eval.go

Lines 1578 to 1600 in eaa7d28

	func callInternal(fn py.Object, args py.Tuple, kwargs py.StringDict, f *py.Frame) (py.Object, error) {
	if method, ok := fn.(*py.Method); ok {
	switch x := method.Internal(); x {
	case py.InternalMethodNone:
	case py.InternalMethodGlobals:
	return f.Globals, nil
	case py.InternalMethodLocals:
	f.FastToLocals()
	return f.Locals, nil
	case py.InternalMethodImport:
	return py.BuiltinImport(nil, args, kwargs, f.Globals)
	case py.InternalMethodEval:
	f.FastToLocals()
	return builtinEval(nil, args, kwargs, f.Locals, f.Globals, f.Builtins)
	case py.InternalMethodExec:
	f.FastToLocals()
	return builtinExec(nil, args, kwargs, f.Locals, f.Globals, f.Builtins)
	default:
	return nil, py.ExceptionNewf(py.SystemError, "Internal method %v not found", x)
	}
	}
	return py.Call(fn, args, kwargs)
	}

This is where the other magic is!

$ git grep InternalMethodLocals
builtin/builtin.go:             py.MustNewMethod("locals", py.InternalMethodLocals, 0, locals_doc),
py/method.go:   InternalMethodLocals
vm/eval.go:             case py.InternalMethodLocals:

That is the only way I could find to avoid using global variables etc. It might be too limiting eventually.

[drew-512]

@sbinet after the py.Context merge, I could look at this out if we think dir() is worth it.

[drew-512]

@sbinet lmk if this is worth adding/improving so we can work towards a cleared PR section. Also, any suggestions on the next version/tag? I think we're worthy of a 0.1 or 1.0 -- open to discussion.

[sbinet]

in order to get the nice discoverability look and feel of CPython into gpython, having a working dir() builtin is definitely a plus.

but as we survived w/o it for almost 4 years, I don't think cleaning up this PR should be a blocker for the next tagged version of gpython.