Tim Peters [Thu, 20 Sep 2001 05:13:38 +0000 (05:13 +0000)]
After much thrashing, I believe this is a truly minimal patch to teach
pydoc how to do something sensible with 2.2 descriptors. To see the
difference, browse __builtin__ via pydoc before and after the patch.
Fixed search function error reporting in the encodings package
__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.
Enable two checks for comparing a complex to a complex subtype
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.)
complex_coerce(): add explicit PyComplex_Check() test. Previously,
complex_coerce() would never be called with a complex argument,
because PyNumber_Coerce[Ex] doesn't bother calling the type's coercion
method if the values already have the same type. But now, of course,
it's possible to pass an instance of a complex *subtype*, and those
must be accepted.
Hopefully fix 3-way comparisons. This unfortunately adds yet another
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.
wrap_cmpfunc(): added a safety check for the __cmp__ wrapper. We can
only safely call a type's tp_compare slot if the second argument is
also an instance of the same type. I hate to think what
e.g. int_compare() would do with a second argument that's a float!
Tim Peters [Tue, 18 Sep 2001 05:40:24 +0000 (05:40 +0000)]
This module didn't work at all anymore -- blew up with AttributeError
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.
Redo the PyMethod attributes using a dir()-friendly approach, creating
descriptors for each attribute. The getattr() implementation is
similar to PyObject_GenericGetAttr(), but delegates to im_self instead
of looking in __dict__; I couldn't do this as a wrapper around
PyObject_GenericGetAttr().
XXX A problem here is that this is a case of *delegation*. dir()
doesn't see exactly the same attributes that are actually defined;
e.g. if the delegate is a Python function object, it supports
attributes like func_code etc., but these are not visible to dir(); on
the other hand, dynamic function attributes (stored in the function's
__dict__) *are* visible to dir(). Maybe we need a mechanism to tell
dir() about the delegation mechanism? I vaguely recall seeing a
request in the newsgroup for a more formal definition of attribute
delegation too. Sigh, time for a new PEP.
- Some tests that check that assignments are not allowed expect this
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.)
Sort the headers in PYTHON_HEADERS alphabetically. Add
structmember.h, which was missing (and caused me a snide comment by
Tim when he fixed something I missed because of the missed dependency
:-).
Tim Peters [Mon, 17 Sep 2001 23:56:20 +0000 (23:56 +0000)]
Rework akin to test_threaded_import, so that this can run under regrtest.
Also raise TestSkipped (intead of appearing to fail) if the import lock
is held.
Rewrite function attributes to use the generic routines properly.
This uses the new "restricted" feature of structmember, and getset
descriptors for some of the type checks.
Jeremy Hylton [Mon, 17 Sep 2001 21:02:51 +0000 (21:02 +0000)]
API change:
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.
Jeremy Hylton [Mon, 17 Sep 2001 20:16:30 +0000 (20:16 +0000)]
Fix calculation of hardest_arg.
The argument properties are ordered from easiest to hardest. The
harder the arg, the more complicated that code that must be generated
to return it from getChildren() and/or getChildNodes(). The old
calculation routine was bogus, because it always set hardest_arg to
the hardness of the last argument. Now use max() to always set it to
the hardness of the hardest argument.
Add support for restricting access based on restricted execution mode.
Renamed the 'readonly' field to 'flags' and defined some new flag
bits: READ_RESTRICTED and WRITE_RESTRICTED, as well as a shortcut
RESTRICTED that means both.
SF patch #461781 by Chris Lawrence: os.path.realpath - Resolve symlinks:
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.
Add cross-compilation defaults to most AC_TRY_RUN values. The
supplied values are the most "normal" or "common" values found for
recent 32 bit machines. This now seems to work to build Python 2.2
for the ARM processor used on the iPAQ.
Tim Peters [Mon, 17 Sep 2001 02:38:46 +0000 (02:38 +0000)]
PyObject_Dir(): Merge in __members__ and __methods__ too (if they exist,
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.
Tim Peters [Sun, 16 Sep 2001 08:40:16 +0000 (08:40 +0000)]
In a world with a growing number of subclassable types, replace
type(x) is T
tests with
isinstance(x, T)
Also got rid of a future-generators import, left over from code that
wasn't intended to get checked in.
Tim Peters [Sun, 16 Sep 2001 02:19:49 +0000 (02:19 +0000)]
Improve handling of docstrings. I had feared this was a case of
introspection incompatibility, but in fact it's just that calltips
always gave up on a docstring that started with a newline (but
didn't realize they were giving up <wink>).
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!
Tim Peters [Sat, 15 Sep 2001 02:35:15 +0000 (02:35 +0000)]
The 'p' (Pascal string) pack code acts unreasonably when the string size
and count exceed 255. Changed to preserve as much of the string as
possible (instead of count%256 characters).
Jeremy Hylton [Fri, 14 Sep 2001 22:49:08 +0000 (22:49 +0000)]
Various sundry changes for 2.2 compatibility
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.
Add call_maybe(): a variant of call_method() that returns
NotImplemented when the lookup fails, and use this for binary
operators. Also lookup_maybe() which doesn't raise an exception when
the lookup fails (still returning NULL).
- Don't turn a non-tuple argument into a one-tuple. Rather, the
caller must pass a format that causes Py_VaBuildValue() to return a
tuple.
- Speed things up by calling PyObject_Call (which is fairly low-level
and straightforward) rather than PyObject_CallObject (which calls
PyEval_CallObjectWithKeywords which calls PyObject_Call, and nothing
is really done in the mean time except some tests for NULL args and
valid types, which are already guaranteed).
- Cosmetics.
Other places:
- Make sure that the format argument to call_method() is surrounded by
parentheses, so it will cause a tuple to be created.
- Replace a few calls to PyEval_CallObject() with a surefire tuple for
args to calls to PyObject_Call(). (A few calls to
PyEval_CallObject() remain that have NULL for args.)
PyObject_CallObject(): this may as well call PyEval_CallObject()
directly, as the only thing done here (replace NULL args with an empty
tuple) is also done there.
XXX Maybe we should take one step further and equate the two at the
macro level? That's harder though because PyEval_Call* is declared in
a header that's not included standard. But it is silly that
PyObject_CallObject calls PyEval_CallObject which calls back to
PyObject_Call. Maybe PyEval_CallObject should be moved into this file
instead? All I know is that there are too many call APIs! The
differences between PyObject_Call and PyEval_CallObjectWithKeywords is
that the latter allows args to be NULL, and does explicit type checks
for args and kwds.
SF patch #461413 (Gerhard Häring): Add STARTTLS feature to smtplib
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.
Tim Peters [Fri, 14 Sep 2001 03:26:08 +0000 (03:26 +0000)]
The end of [#460467] file objects should be subclassable.
A surprising number of changes to split tp_new into tp_new and tp_init.
Turned out the older PyFile_FromFile() didn't initialize the memory it
allocated in all (error) cases, which caused new sanity asserts
elsewhere to fail left & right (and could have, e.g., caused file_dealloc
to try decrefing random addresses).
Tim Peters [Fri, 14 Sep 2001 00:25:33 +0000 (00:25 +0000)]
Changed the dict implementation to take "string shortcuts" only when
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.
Tim Peters [Thu, 13 Sep 2001 21:49:44 +0000 (21:49 +0000)]
Get rid of builtin_open() entirely (the C code and docstring, not the
builtin function); Guido pointed out that it could be just another
name in the __builtin__ dict for the file constructor now.
Tim Peters [Thu, 13 Sep 2001 21:01:29 +0000 (21:01 +0000)]
Now that file objects are subclassable, you can get at the file constructor
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).
Tim Peters [Thu, 13 Sep 2001 19:18:27 +0000 (19:18 +0000)]
type_call(): Change in policy. The keyword args (if any) are now passed
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.
Fred Drake [Thu, 13 Sep 2001 16:56:43 +0000 (16:56 +0000)]
Admit that we'll never add the args for a "call" event to the profile
and trace functions; this now declares that None will be passed for the
"call" event.
This closes SF bug/suggestion #460315.
SF bug #461073: mailbox __iter__ bug, by Andrew Dalke.
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.