Guido> Specific tasks, by the way:
Guido> - Add a 'string' built-in type that's the common base class for str
Guido> and unicode.
Guido> - Make buffer, xrange, and slice into new-stype types.
I'm working on xrange at the moment.
Guido> - Figure out which type names are commonly tested for that aren't
Guido> yet built-ins, and propose a way to expose their names.
Guido> - The 'new' module may also become deprecated; its functions
Guido> (instance, instancemethod, function, code, module, and
Guido> classobj) should be implementable by calling the appropriate
Guido> types (not all of these are their own factories yet, so that's
Guido> another task). Then for compatibility, a module "new.py" may
Guido> be provided that implements the interfaces in a
Guido> backward-compatible way.
If new is important enough to retain for backward compatibility, my guess is
types would be as well.
I am working on a PEP. If I can get a patch generated for the xrange type
builtin in the next little while I will release it for comments today,
skeletal though it is.
Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4