Currently, the cygwinccompiler.py compiler handling in
distutils is invoking the cygwin and mingw compilers
with the -static option.
Logically, this means that the linker should choose to
link to static libraries instead of shared/dynamically
linked libraries.
Current win32 binutils expect import libraries to have
a .dll.a suffix and static libraries to have .a suffix.
If -static is passed, it will skip the .dll.a
libraries. This is pain if one has a tree with both
static and dynamic libraries using this naming
convention, and wish to use the dynamic libraries.
The -static option being passed in distutils is to get
around a bug in old versions of binutils where it would
get confused when it found the DLLs themselves.
The decision to use static or shared libraries is site
or package specific, and should be left to the setup
script or to command line options.
These never failed in 2.3, and the tests confirm it. They still blow up
in the 2.2 branch, despite that all the gc-vs-__del__ fixes from 2.3
have been backported (and this is expected -- 2.2 needs more work than
2.3 needed).
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code. Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.
Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.
To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong: if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__". But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted. gc was
therefore incorrect in believing that the object had a finalizer.
The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.
While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer": not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time. Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.
So I believe the new method is better on all counts.
Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
externally unreachable objects with finalizers, and externally unreachable
objects without finalizers reachable from such objects. This allows us
to call has_finalizer() at most once per object, and so limit the pain of
nasty getattr hooks. This fixes the failing "boom 2" example Jeremy
posted (a non-printing variant of which is now part of test_gc), via never
triggering the nasty part of its __getattr__ method.
the Standard_Suite, but various other suites do expect it (the Finder
implements get() without declaring it itself). It is probably another
case of OSA magic. Adding them to the global base class.
within a certain context. Give them an _Prop_ prefix, so they don't
accidentally obscure an element from another suite (as happened with
the Finder). Comparisons I'm not sure about, so I left them as global
names.
Also got rid of the lists if declarations, they serve no useful purpose.
you to say something like "talker.count(want=Address_Book.people)" in
stead of having to manually create the aetypes.Type(Address_Book.people.want)
OSA type.
platforms which have dup(2). The makefile() method is built directly on top
of the socket without duplicating the file descriptor, allowing timeouts to
work properly. Includes a new test case (urllibnet) which requires the
network resource.
Closes bug 707074.
This is a first step towards regenerating the modules with newer, MacOSX,
versions of these programs, and using the programmatic interface to
get at the terminology in stead of poking in resource files.
Clean up section headings; make the bars on the left less fat.
Adjust the display of properties slightly.
Don't show stuff inherited from the base 'object' type.
Jason Tishler
Jack Jansen
Andrew M. Kuchling
Skip Montanaro
Tim Peters
Raymond Hettinger
Jeremy Hylton
Martin v. Löwis
Walter Dörwald
Barry Warsaw
Neal Norwitz
Ka-Ping Yee
Gregory P. Smith