Add raise_exception() to the _testcapi module. It isn't a test, but
the C API exists only to support test_exceptions. raise_exception()
takes two arguments -- an exception class and an integer specifying
how many arguments it should be called with.
test_exceptions uses BadException() to test the interpreter's behavior
when there is a problem instantiating the exception. test_capi1()
calls it with too many arguments. test_capi2() causes an exception to
be raised in the Python code of the constructor.
Also, add a clause to the big-if to handle message/delivery-status
content types. These create a message with subparts that are
Message instances, which best represent the header blocks of this
content type.
get_type(): Use a compiled regular expression, which can be shared.
_get_params_preserve(): A helper method which extracts the header's
parameter list preserving value quoting. I'm not sure that this
needs to be a public method. It's necessary because we want
get_param() and friends to return the unquoted parameter value,
however we want the quote-preserved form for set_boundary().
get_params(), get_param(), set_boundary(): Implement in terms of
_get_params_preserve().
walk(): Yield ourself first, then recurse over our subparts (if any).
Text.py and class Text => MIMEText.py and MIMEText
MessageRFC822.py and class MessageRFC822 => MIMEMessage.py and MIMEMessage
These are renamed so as to be more consistent; these are MIME specific
derived classes for when creating the object model out of whole cloth.
_handle_text(): If the payload is None, then just return (i.e. don't
write anything). Subparts of message/delivery-status types
will have this property since they are just blocks of headers.
Also, when raising the TypeError, include the type of the
payload in the error message.
_handle_multipart(), _handle_message(): When creating a clone of self,
pass in our _mangle_from_ and maxheaderlen flags so the clone
has the same behavior.
_handle_message_delivery_status(): New method to do the proper
printing of message/delivery-status type messages. These have
to be handled differently than other message/* types because
their payloads are subparts containing just blocks of headers.
In class DecodedGenerator:
_dispatch(): Skip over multipart/* messages since we don't care
about them, and don't want the non-text format to appear in
the printed results.
the local save/modify/restore of sys.stdout, but add machinery so that
regrtest can tell test_support the value of sys.stdout at the time
regrtest.main() started, and test_support can pass that out later to anyone
who needs a "visible" stdout.
- Made cls.__module__ writable.
- Ensure that obj.__dict__ is returned as {}, not None, even upon first
reference; it simply springs into life when you ask for it.
(*) The pickling support is provisional for the following reasons:
- It doesn't support classes with __slots__.
- It relies on additional support in copy_reg.py: the C method
__reduce__, defined in the object class, really calls calling
copy_reg._reduce(obj). Eventually the Python code in copy_reg.py
needs to be migrated to C, but I'd like to experiment with the
Python implementation first. The _reduce() code also relies on an
additional helper function, _reconstructor(), defined in
copy_reg.py; this should also be reimplemented in C.
property() (get, set, del; not set, get, del).
+ Change "Data defined/inherited in ..." header lines to
"Data and non-method functions defined/inherited in ...". Things like
the value of __class__, and __new__, and class vrbls like the i in
class C:
i = int
show up in this section too. I don't think it's worth a separate
section to distinguish them from non-callable attrs, and there's no
obvious reliable way to distinguish callable from non-callable attrs
anyway.
than <type 'ClassName'>. Exception: if it's a built-in type or an
extension type, continue to call it <type 'ClassName>. Call me a
wimp, but I don't want to break more user code than necessary.
same. I hope the test for structural equivalence is stringent enough.
It only allows the assignment if the old and new types:
- have the same basic size
- have the same item size
- have the same dict offset
- have the same weaklist offset
- have the same GC flag bit
- have a common base that is the same except for maybe the dict and
weaklist (which may have been added separately at the same offsets
in both types)
always been close to useless, because the <small>-ified docstrings
were too small to read, even after cranking up my default font size
just for pydoc. Now it reads fine under my defaults (as does most
of the web <0.5 wink>). If it's thought important to play tricks
with font size, tough, then someone should rework pydoc to use style
sheets, and (more) predictable percentage-of-default size controls.
+ Tried to ensure that all <dt> and <dd> tags are closed. I've read (but
don't know) that some browsers get confused if they're not, and esp.
when style sheets are in use too.
properties: the docstring (if any) is displayed, and the getter, setter
and deleter (if any) functions are named. All that is shown indented
after the property name.
+ Text-mode pydoc class display now draws a horizontal line between
class attribute groups (similar to GUI mode -- while visually more
intrusive in text mode, it's still an improvement).
- property() now takes 4 keyword arguments: fget, fset, fdel, doc.
Note that the real purpose of the 'f' prefix is to make fdel fit in
('del' is a keyword, so can't used as a keyword argument name).
- These map to visible readonly attributes 'fget', 'fset', 'fdel',
and '__doc__' in the property object.
- fget/fset/fdel weren't discoverable from Python before.
- __doc__ is new, and allows to associate a docstring with a property.
declarations and weird markup that we used to accept & ignore that recent
versions raised an exception for; the original behavior has been restored
and augmented (the user can decide what to do if they care; the default is
to ignore it as done in early versions).
Use a new internal method, error(), consistently to raise parse errors;
the new base class also uses this.
Adjust the parse_comment() method to return the new offset into the buffer
instead of the number of characters scanned; this was the only helper
method that did it this way, so we have better consistency now. Required
to share the new base class.
This fixes SF bug #448482 and #453706.
and HTMLParser modules (and indirectly for the htmllib.HTMLParser class).
This has all the support for scanning over DOCTYPE declarations; it warrants
having a base class since this is a fair amount of tedious code (since it's
fairly strict), and should be in a separate module to avoid compiling many
REs that are not used (which would happen if this were placed in either then
sgmllib or HTMLParser module).
+ Minor code cleanup, generalization and simplification.
+ "Do something" to make the attribute aggregation more apparent:
- In text mode, stick a "* " at the front of subgroup header lines.
- In GUI mode, display a horizontal rule between subgroups.
For GUI mode, this is a huge improvement, at least under IE.
mode (identify the source class for class attrs; segregate attrs according
to source class, and whether class method, static method, property, plain
method, or data; display data attrs; display docstrings for data attrs
when possible).
Alas, this is mondo ugly, and I'm no HTML guy. Part of the problem is
that pydoc's GUI mode has always been ugly under IE, largely because
<small> under IE renders docstrings unreadably small (while sometimes
non-docstring text is painfully large). Another part is that these
segregated listings of attrs would *probably* look much better as bulleted
lists. Alas, when I tried that, the bullets all ended up on lines by
themselves, before the method names; this is apparently because pydoc
(ab?)uses definition lists for format effects, and at least under IE
if a definition list is the first chunk of a list item, it gets rendered
on a line after the <li> bullet.
An HTML wizard would certainly be welcomed here.
This almost entirely replaces how pydoc pumps out class docs, but only
in text mode (like help(whatever) from a Python shell), not in GUI mode.
A class C's attrs are now grouped by the class in which they're defined,
attrs defined by C first, then inherited attrs grouped by alphabetic order
of the defining classes' names.
Within each of those groups, the attrs are subgrouped according to whether
they're plain methods, class methods, static methods, properties, or data.
Note that pydoc never dumped class data attrs before. If a class data
attr is implemented via a data descriptor, the data docstring (if any)
is also displayed (e.g., file.softspace).
Within a subgroup, the attrs are listed alphabetically.
This is a friggin' mess, and there are bound to be glitches. Please
beat on it and complain! Here are three glitches:
1. __new__ gets classifed as 'data', for some reason. This will
have to get fixed in inspect.py, but since the latter is already
looking for any clue that something is a method, pydoc will
almost certainly not know what to do with it when its classification
changes.
2. properties are special-cased to death. Unlike any other kind of
function or method, they don't have a __name__ attr, so none of
pydoc's usual code can deal with them. Worse, the getter and
setter and del'er methods associated with a property don't appear
to be discoverable from Python, so there's really nothing I can
think of to do here beyond just listing their names.
Note that a property can't be given a docstring, either (or at least
I've been unable to sneak one in) -- perhaps the property()
constructor could take an optional doc argument?
3. In a nested-scopes world, pydoc still doesn't know anything about
nesting, so e.g. classes nested in functions are effectively invisible.
<http://sf.net/projects/mimelib>. There /are/ API differences between
mimelib and email, but most of the implementations are shared (except
where cool Py2.2 stuff like generators are used).
point out, pydoc doesn't tell you where class attributes were defined,
gets several new 2.2 features wrong, and isn't aware of some new features
checked in on Thursday <wink>. pydoc is hampered in part because
inspect.py has the same limitations. Alas, I can't think of a way to
fix this within the current architecture of inspect/pydoc: it's simply
not possible in 2.2 to figure out everything needed just from examining
the object you get back from class.attr. You also need the class
context, and the method resolution order, and tests against various things
that simply didn't exist before. OTOH, knowledge of how to do that is
getting quite complex, so doesn't belong in pydoc.
classify_class_attrs takes a different approach, analyzing all
the class attrs "at once", and returning the most interesting stuff for
each, all in one gulp. pydoc needs to be reworked to use this for
classes (instead of the current "filter dir(class) umpteen times against
assorted predicates" approach).
easy for 2.2 new-style classes, but trickier for classic classes, and
different approaches are needed "depending". The function will allow
later code to treat all flavors of classes uniformly.
somewhere inside a line, use ndiff so that intraline difference marking
can point out what changed within a line. I don't remember diff-style
abbreviations either (haven't used it since '94, except to produce
patches), so say the rest in English too.
Lib/test/output/test_StringIO is no longer necessary.
Also, added a test of the iterator protocol that's just been added to
StringIO's and cStringIO's.
- if __getattribute__ exists, it is called first;
if it doesn't exists, PyObject_GenericGetAttr is called first.
- if the above raises AttributeError, and __getattr__ exists,
it is called.
the first difference, let the test run till completion, then gather
all the output and compare it to the expected output using difflib.
XXX Still to do: produce diff output that only shows the sections that
differ; currently it produces ndiff-style output because that's the
easiest to produce with difflib, but this becomes a liability when the
output is voluminous and there are only a few differences.
classes to __getattribute__, to make it crystal-clear that it doesn't
have the same semantics as overriding __getattr__ on classic classes.
This is a halfway checkin -- I'll proceed to add a __getattr__ hook
that works the way it works in classic classes.
elements which are not Unicode objects or strings. (This matches
the string.join() behaviour.)
Fix a memory leak in the .join() method which occurs in case
the Unicode resize fails.
Restore the test_unicode output.
their own test suite from a multitude of classes (like test_email.py
will be doing).
run_unittest(): Call run_suite() after making a suite from the
testclass.
inspect.getargspec(obj), test isfunction() directly in pydoc.py instead
of trying to indirectly deduce isfunction() in pydoc by virtue of
failing a combination of other tests. This shouldn't have any visible
effect, except perhaps to squash a TypeError death if there was some path
thru this code that was inferring isfunction() by mistake.
__init__.py module to raise errors which can be catched as LookupErrors
as well as SystemErrors.
Modified the error messages to include more information about the
failing module.
instance.
Split a string comparison test in two halves, replacing "a==b==a" with
separate tests for a==b and b==a. (Reason: while experimenting, this
test failed, and I wanted to know if it was the first or the second ==
operator that failed.)
hack, and it's even more disgusting than a PyInstance_Check() call.
If the tp_compare slot is the slot used for overrides in Python,
it's always called.
Add some tests that show what should work too.
#462270: sub-tle difference between pre.sub and sre.sub. PRE ignored
an empty match at the previous location, SRE didn't.
also synced with Secret Labs "sreopen" codebase.
on file.__methods__. Since the docs say "This module will become obsolete
in a future release", this is just a quick hack to stop it from blowing
up. If you care about this module, test it! It doesn't make much sense
on Windows.
to raise TypeError. In practice, a disallowed attribute assignment
can raise either TypeError or AttributeError (and it's unclear which
is better). So allow either. (Yes, this is in anticipation of a
code change that switches the exception raised. :-)
- Add a utility function, cantset(), which verifies that setting a
particular attribute to a given value is disallowed, and also that
deleting that same attribute is disallowed. Use this in the
test_func_*() tests.
- Add a new set of tests that test conformance of various instance
method attributes. (Also in anticipation of code that changes their
implementation.)
compile() becomes replacement for builtin compile()
compileFile() generates a .pyc from a .py
both are exported in __init__
compiler.parse() gets optional second argument to specify compilation
mode, e.g. single, eval, exec
Add AbstractCompileMode as parent class and Module, Expression, and
Interactive as concrete subclasses. Each corresponds to a compilation
mode.
THe AbstractCompileMode instances in turn delegate to CodeGeneration
subclasses specialized for their particular functions --
ModuleCodeGenerator, ExpressionCodeGeneration,
InteractiveCodeGenerator.
Remove the only test in the syntax module. It ends up that the
transformer must handle this error case.
In the transformer, check for a list compression in com_assign_list()
by looking for a list_for node where a comma is expected.
In pycodegen.compile() re-raise the SyntaxError rather than catching
it and exiting
Invoke compiler.syntax.check() after building AST. If a SyntaxError
occurs, print the error and exit without generating a .pyc file.
Refactor code to use compiler.misc.set_filename() rather than passing
filename argument around to each CodeGenerator instance.
Once upon a time, I put together a little function
that tries to find the canonical filename for a given
pathname on POSIX. I've finally gotten around to
turning it into a proper patch with documentation.
On non-POSIX, I made it an alias for 'abspath', as
that's the behavior on POSIX when no symlinks are
encountered in the path.
Example:
>>> os.path.realpath('/usr/bin/X11/X')
'/usr/X11R6/bin/X'
and are lists, and then just the string elements (if any)).
There are good and bad reasons for this. The good reason is to support
dir() "like before" on objects of extension types that haven't migrated
to the class introspection API yet. The bad reason is that Python's own
method objects are such a type, and this is the quickest way to get their
im_self etc attrs to "show up" via dir(). It looks much messier to move
them to the new scheme, as their current getattr implementation presents
a view of their attrs that's a untion of their own attrs plus their
im_func's attrs. In particular, methodobject.__dict__ actually returns
methodobject.im_func.__dict__, and if that's important to preserve it
doesn't seem to fit the class introspection model at all.
Both int and long multiplication are changed to be more careful in
their assumptions about when one of the arguments is a sequence: the
assumption that at least one of the arguments must be an int (or long,
respectively) is still held, but the assumption that these don't smell
like sequences is no longer true: a subtype of int or long may well
have a sequence-repeat thingie!
Remove the option to have nested scopes or old LGB scopes. This has a
large impact on the code base, by removing the need for two variants
of each CodeGenerator.
Add a get_module() method to CodeGenerator objects, used to get the
future features for the current module.
Set CO_GENERATOR, CO_GENERATOR_ALLOWED, and CO_FUTURE_DIVISION flags
as appropriate.
Attempt to fix the value of nlocals in newCodeObject(), assuming that
nlocals is 0 if CO_NEWLOCALS is not defined.
This patch adds the features from RFC 2487 (Secure SMTP
over TLS) to the smtplib module:
- A starttls() function
- Wrapper classes that simulate enough of sockets and
files for smtplib, but really wrap a SSLObject
- reset the list of known SMTP extensions at each call
of ehlo(). This should have been the case anyway.
keys are true strings -- no subclasses need apply. This may be debatable.
The problem is that a str subclass may very well want to override __eq__
and/or __hash__ (see the new example of case-insensitive strings in
test_descr), but go-fast shortcuts for strings are ubiquitous in our dicts
(and subclass overrides aren't even looked for then). Another go-fast
reason for the change is that PyCheck_StringExact() is a quicker test
than PyCheck_String(), and we make such a test on virtually every access
to every dict.
OTOH, a str subclass may also be perfectly happy using the base str eq
and hash, and this change slows them a lot. But those cases are still
hypothetical, while Python's own reliance on true-string dicts is not.
just by doing type(f) where f is any file object. This left a hole in
restricted execution mode that rexec.py can't plug by itself (although it
can plug part of it; the rest is plugged in fileobject.c now).
on to the tp_new slot (if non-NULL), as well as to the tp_init slot (if
any). A sane type implementing both tp_new and tp_init should probably
pay attention to the arguments in only one of them.
Andrew quite correctly notices that the next() method isn't quite what
we need, since it returns None upon end instead of raising
StopIteration. His fix is easy enough, using iter(self.next, None)
instead.
with the same value instead. This ensures that a string (or string
subclass) object's ob_sinterned pointer is always a str (or NULL), and
that the dict of interned strings only has strs as keys.
+ These were leaving the hash fields at 0, which all string and unicode
routines believe is a legitimate hash code. As a result, hash() applied
to str and unicode subclass instances always returned 0, which in turn
confused dict operations, etc.
+ Changed local names "new"; no point to antagonizing C++ compilers.
subclasses, all "the usual" ones (slicing etc), plus replace, translate,
ljust, rjust, center and strip. I don't know how to be sure they've all
been caught.
Question: Should we complain if someone tries to intern an instance of
a string subclass? I hate to slow any code on those paths.
#460112 by Gerhard Haering.
(With slight layout changes to conform to docstrings guidelines and to
prevent a line longer than 78 characters. Also fixed some docstrings
that Gerhard didn't touch.)
tuple(i) repaired to return a true tuple when i is an instance of a
tuple subclass.
Added PyTuple_CheckExact macro.
PySequence_Tuple(): if a tuple-like object isn't exactly a tuple, it's
not safe to return the object as-is -- make a new tuple of it instead.
Given an immutable type M, and an instance I of a subclass of M, the
constructor call M(I) was just returning I as-is; but it should return a
new instance of M. This fixes it for M in {int, long}. Strings, floats
and tuples remain to be done.
Added new macros PyInt_CheckExact and PyLong_CheckExact, to more easily
distinguish between "is" and "is a" (i.e., only an int passes
PyInt_CheckExact, while any sublass of int passes PyInt_Check).
Added private API function _PyLong_Copy.
If on Windows, we require the 'largefile' resource.
If not on Windows, we use a test that actually writes a byte beyond
the 2BG limit -- seeking alone is not sufficient, since on some
systems (e.g. Linux with glibc 2.2) the sytem call interface supports
large seek offsets but not all filesystem implementations do.
Note that on Windows, we do not use the write test: on Win2K, that
test can take a minute trying to zero all those blocks on disk, and on
Windows our code always supports large seek offsets (but again, not
all filesystems do). This may mean that on Win95, or on certain other
backward filesystems, test_largefile will *fail*.
horridly inefficient hack in regrtest's Compare class, but it's about as
clean as can be: regrtest has to set up the Compare instance before
importing a test module, and by the time the module *is* imported it's too
late to change that decision. The good news is that the more tests we
convert to unittest and doctest, the less the inefficiency here matters.
Even now there are few tests with large expected-output files (the new
cost here is a Python-level call per .write() when there's an expected-
output file).
iterable object. I'm not sure how that got overlooked before!
Got rid of the internal _PySequence_IterContains, introduced a new
internal _PySequence_IterSearch, and rewrote all the iteration-based
"count of", "index of", and "is the object in it or not?" routines to
just call the new function. I suppose it's slower this way, but the
code duplication was getting depressing.
saving instead a traceback string, but test_support's run_unittest was
still peeking into unittest internals and trying to pick apart unittest's
errors and failures vectors as if they contained exc_info() tuples instead
of strings.
Whatever, when a unittest-based test failed, test_support blew up. I'm
not sure this is the right way to fix it; it simply gets me unstuck.
capabilities of the Pentium FPU, so what should have been (and were on
Windows) exact results got fuzzy. Then it turns out test_support.fcmp()
isn't tolerant of tiny errors when *one* of the comparands is 0, but
test_complex's old check_close_real() is. Rather than fix gcc <wink>,
easier to revert this test and revisit after the release.
(1) Allow multiple -u options to extend each other (and the initial
value of use_resources passed into regrtest.main()).
(2) When a test is run stand-alone (not via regrtest.py), needed
resources are always granted.
added all the telnet options known to arpa/telnet.h
added all the options registered with IANA as of today
added the possibility for the user to have it's own option negotiation callback
This patch is similar to that proposed by Jeremy. The proposed patch altered
the interface of TestResult such that it would be passed the error
information as a string rather than an exc_info() tuple.
The implemented change leaves the interface untouched so that TestResults
are still passed the tracebacks, but stor them in stringified form for
later reporting.
Notes:
- Custom subclasses of TestResult written by users should be unaffected.
- The existing 'unittestgui.py' will still work with this module after the
change.
- Support can later be added to pop into the debugger when an error occurs;
this support should be added to a TestRunner rather than to TestCase itself,
which this change will enable.
(Jeremy, Fred, Guido: Thanks for all the feedback)
1. That seeking beyond the end of a file increases the size of a file.
2. That files so extended are magically filled with null bytes.
I find no support for either in the C std, and #2 in particular turns out
not to be true on Win32 (you apparently see whatever trash happened to be
on disk). Left #1 intact, but changed the test to check only bytes it
explicitly wrote. Also fiddled the "expected" vs "got" failure reports
to consistently use repr (%r) -- they weren't readable otherwise.
Curious: the MS docs say stati64 etc are supported even on Win95, but
Win95 doesn't support a filesystem that allows partitions > 2 Gb.
test_largefile: This was opening its test file in text mode. I have no
idea how that worked under Win64, but it sure needs binary mode on Win98.
BTW, on Win98 test_largefile runs quickly (under a second).
requires that errno ever get set, and it looks like glibc is already
playing that game. New rules:
+ Never use HUGE_VAL. Use the new Py_HUGE_VAL instead.
+ Never believe errno. If overflow is the only thing you're interested in,
use the new Py_OVERFLOWED(x) macro. If you're interested in any libm
errors, use the new Py_SET_ERANGE_IF_OVERFLOW(x) macro, which attempts
to set errno the way C89 said it worked.
Unfortunately, none of these are reliable, but they work on Windows and I
*expect* under glibc too.
32 characters per component. This makes mkdir() calls and such fail with EINVAL.
For now I am disabling the test on the Mac, and I'll open a bugreport.
bdist_wininst doesn't use the NT SCHEME any more, instead
a custom SCHEME is used, which is exchanged at installation
time, depending on the python version used.
Avoid a bogus warning frpom install_lib about installing
into a directory not on sys.path.
getting Infs, NaNs, or nonsense in 2.1 and before; in yesterday's CVS we
were getting OverflowError; but these functions always make good sense
for positive arguments, no matter how large).
"/" and "//", and doesn't really care what they *mean*, just that both
are tried (and that, whatever they mean, they act similarly for int and
long arguments).
the fiddling is simply due to that no caller of PyLong_AsDouble ever
checked for failure (so that's fixing old bugs). PyLong_AsDouble is much
faster for big inputs now too, but that's more of a happy consequence
than a design goal.
of PyMapping_Keys because we know we have a real dict. Tolerate that
objects may have an attr named "__dict__" that's not a dict (Py_None
popped up during testing).
test_descr.py, test_dir(): Test the new classic-class behavior; beef up
the new-style class test similarly.
test_pyclbr.py, checkModule(): dir(C) is no longer a synonym for
C.__dict__.keys() when C is a classic class (looks like the same thing
that burned distutils! -- should it be *made* a synoym again? Then it
would be inconsistent with new-style class behavior.).
bag. It's clearly wrong for classic classes, at heart because a classic
class doesn't have a __class__ attribute, and I'm unclear on whether
that's feature or bug. I'll repair this once I find out (in the
meantime, dir() applied to classic classes won't find the base classes,
while dir() applied to a classic-class instance *will* find the base
classes but not *their* base classes).
Please give the new dir() a try and see whether you love it or hate it.
The new dir([]) behavior is something I could come to love. Here's
something to hate:
>>> class C:
... pass
...
>>> c = C()
>>> dir(c)
['__doc__', '__module__']
>>>
The idea that an instance has a __doc__ attribute is jarring (of course
it's really c.__class__.__doc__ == C.__doc__; likewise for __module__).
OTOH, the code already has too many special cases, and dir(x) doesn't
have a compelling or clear purpose when x isn't a module.
mapping object", in the same sense dict.update(x) requires of x (that x
has a keys() method and a getitem).
Questionable: The other type constructors accept a keyword argument, so I
did that here too (e.g., dictionary(mapping={1:2}) works). But type_call
doesn't pass the keyword args to the tp_new slot (it passes NULL), it only
passes them to the tp_init slot, so getting at them required adding a
tp_init slot to dicts. Looks like that makes the normal case (i.e., no
args at all) a little slower (the time it takes to call dict.tp_init and
have it figure out there's nothing to do).
Fix list comp code generation -- emit GET_ITER instead of Const(0)
after the list.
Add CO_GENERATOR flag to generators.
Get CO_xxx flags from the new module
try/except or try/finally.
Previous versions had only track SETUP_LOOP blocks and ignored the
exception part. This meant that it allowed continue inside a
try/except but generated buggy code. Now it does the right thing.
As the doc string for _lookupName() explains:
This routine uses a list instead of a dictionary, because a
dictionary can't store two different keys if the keys have the
same value but different types, e.g. 2 and 2L. The compiler
must treat these two separately, so it does an explicit type
comparison before comparing the values.
Avoid if/elif/elif/else tests where the final else is supposed to
handle exactly one case instead of all other cases. When the list of
operators is extended, the catchall else treats all new operators as
the last operator in the set of tests. Instead, raise an exception if
an unexpected operator occurs.
Use a dictionary instead of a list to map objects to their offsets in
a const/name tuple of a code object.
XXX The conversion is perhaps incomplete, in that we shouldn't have to
do the list2dict to start.
Add support for floor division (// and //=)
The implementation of getChildren() and getChildNodes() is intended to
be faster, because it avoids calling flatten() on every return value.
But it's not clear that it is a lot faster, because constructing a
tuple with just the right values ends up being slow. (Too many
attribute lookups probably.)
The ast.txt file is much more complicated, with funny characters at
the ends of names (*, &, !) to indicate the types of each child node.
The astgen script is also much more complex, making me wonder if it's
still useful.
