Mailman 3 December 2002 - Python-Dev

What's the magic formula for regression-testing a single module?
by Eric S. Raymond Dec. 28, 2002

Dec. 28, 2002

What's the magic formula for regression-testing a single library module? I found a bug in ConfigParser -- the readfp() and write() functions are not perfect inverses in some situations. I think I have a fix, and want to verify correctness. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

2 1

linktree.py
by David MacQuigg Dec. 28, 2002

Dec. 28, 2002

Hello, I'm new to Python, and I'm very impressed with the potential of this language to simplify much of the software my company provides. As a first project, I'm looking to replace some tricky scripts written in csh for setting up our tool hierarchies. An example is a script to construct a "mock hierarchy" out of some patch files and links to a production hierarchy. Our hierarchies are typically two gigabytes, thousands of files, lots of strange links, many of which are broken. So the … [View More]script needs to be fairly robust. The functions in 'shutil' won't do it. 'copytree' works, but the cost is a huge amount of disk space. A mock hierarchy takes not much more space than the patch files themselves. After a brief search on the Python website, I couldn't find a suitable utility, and decided to write my own (see below). It seems like this could be a useful, general-purpose addition to 'shutil'. I've tested this on a large hierarchy on a Solaris workstation, and it seems to work. There are some dark corners which worry me however, so I thought I would get some advice from the experts. Has anything like this already been done or is it planned? Would a function like this be a useful addition to 'shutil'? I'm intending to continue work on it, and will be glad to contribute it to the library. import os, sys from os.path import * def linktree(oldtree, newtree): """linktree(oldtree, newtree) -> None Leave 'oldtree' undisturbed. Recursively add links to 'newtree', until it looks just like 'oldtree', but with the new files patched in. """ names = os.listdir(oldtree) print 'Candidates: ', names for name in names: oldpath = abspath(join(oldtree, name)) newpath = abspath(join(newtree, name)) if not exists(newpath) and not islink(newpath): if not exists(oldpath): # Don't link to a bad link. print '*** Error ***\nPath does not exist:\n', oldpath continue print 'New link: ', newpath os.symlink(oldpath, newpath) # OK if oldpath is a good link. elif isfile(newpath) and not islink(newpath): print 'As is: ', newpath pass # Leave new files as is. elif isdir(newpath) and not islink(newpath): print 'Down one level \n', newpath linktree(oldpath, newpath) # Recursive call print 'Up one level' else: print '*** Error ***\nNot a file or directory:\n', newpath - Dave ************************************************************* * * David MacQuigg * email: macquigg(a)cadence.com * * * Principal Product Engineer * phone: USA 520-721-4583 * * * * Analog Artist * * * * * 9320 East Mikelyn Lane * * * * Cadence Design Systems, Inc. * Tucson, Arizona 85710 * ************************************************************* * [View Less]

2 1

smtplib docs: has_option() or has_extn()?
by Greg Ward Dec. 27, 2002

Dec. 27, 2002

Doc/lib/libsmtplib.tex refers to a mythical has_option() method of SMTP objects. (The string 'has_option' occurs nowhere in Lib/smtplib.py. Neither does 'hasoption'.) I'm pretty sure that it should be talking about has_extn(), ie.: --- lib/libsmtplib.tex 24 Mar 2002 15:41:40 -0000 1.22 +++ lib/libsmtplib.tex 27 Dec 2002 21:03:40 -0000 @@ -138,9 +138,9 @@ Identify yourself to an ESMTP server using \samp{EHLO}. The hostname argument defaults to the fully qualified domain name of the … [View More]

1 0

New Import Hooks PEP, a first draft (and req. for PEP #)
by Just van Rossum Dec. 27, 2002

Dec. 27, 2002

PEP: XXX Title: New Import Hooks Version: $Revision:$ Last-Modified: $Date:$ Author: Just van Rossum <just(a)letterror.com>, Paul Moore <gustav(a)morpheus.demon.co.uk> Status: Draft Type: Standards Track Content-Type: text/plain Created: Python-Version: 2.3 Post-History: Abstract This PEP proposes to add a new set of import hooks that offer better customization of the Python import mechanism. Contrary to the current __import__ hook, a new-style hook can be … [View More]injected into the existing scheme, allowing for a finer grained control of how modules are found and how they are loaded. Motivation The only way to customize the import mechanism is currently to override the builtin __import__ function. However, overriding __import__ has many problems. To begin with: - An __import__ replacement needs to *fully* reimplement the entire import mechanism, or call the original __import__ before or after the custom code. - It has very complex semantics and responsibilities. - __import__ gets called even for modules that are already in sys.modules, which is almost never what you want, unless you're writing some sort of monitoring tool. The situation gets worse when you need to extend the import mechanism from C: it's currently impossible, apart from hacking Python's import.c or reimplementing much of import.c from scratch. There is a fairly long history of tools written in Python that allow extending the import mechanism in various way, based on the __import__ hook. The Standard Library includes two such tools: ihooks.py (by GvR) and imputil.py (Greg Stein), but perhaps the most famous is iu.py by Gordon McMillan, available as part of his Installer [1] package. Their usefulness is somewhat limited because they are written in Python; bootstrapping issues need to worked around as you can't load the module containing the hook with the hook itself. So if you want the entire Standard Library to be loadable from an import hook, the hook must be written in C. Use cases This section lists several existing applications that depend on import hooks. Among these, a lot of duplicate work was done that could have been saved if there had been a more flexible import hook at the time. This PEP should make life a lot easier for similar projects in the future. Extending the import mechanism is needed when you want to load modules that are stored in a non-standard way. Examples include modules that are bundled together in an archive; byte code that is not stored in a pyc formatted file; modules that are loaded from a database over a network. The work on this PEP was partly triggered by the implementation of PEP 273 [2], which adds imports from Zip archives as a builtin feature to Python. While the PEP itself was widely accepted as a must-have feature, the implementation left a few things to desire. For one thing it went through great lengths to integrate itself with import.c, adding lots of code that was either specific for Zip file imports or *not* specific to Zip imports, yet was not generally useful (or even desirable) either. Yet the PEP 273 implementation can hardly be blamed for this: it is simply extremely hard to do, given the current state of import.c. Packaging applications for end users is a typical use case for import hooks, if not *the* typical use case. Distributing lots of source or pyc files around is not always appropriate (let alone a separate Python installation), so there is a frequent desire to package all needed modules in a single file. So frequent in fact that multiple solutions have been implemented over the years. The oldest one is included with the Python source code: Freeze [3]. It puts marshalled byte code into static objects in C source code. Freeze's "import hook" is hard wired into import.c, and has a couple of issues. Later solutions include Fredrik Lundh's Squeeze [4], Gordon McMillan's Installer [1] and Thomas Heller's py2exe [5]. MacPython ships with a tool called BuildApplication. Squeeze, Installer and py2exe use an __import__ based scheme (py2exe currently uses Installer's iu.py, Squeeze used ihooks.py), MacPython has two Mac-specific import hooks hard wired into import.c, that are similar to the Freeze hook. The hooks proposed in this PEP enables us (at least in theory; it's not a short term goal) to get rid of the hard coded hooks in import.c, and would allow the __import__-based tools to get rid of most of their import.c emulation code. Before work on the design and implementation of this PEP was started, a new BuildApplication-like tool for MacOSX prompted one of the authors of this PEP (JvR) to expose the table of frozen modules to Python, in the imp module. The main reason was to be able to use the freeze import hook (avoiding fancy __import__ support), yet to also be able to supply a set of modules at runtime. This resulted in sf patch #642578 [6], which was mysteriously accepted (mostly because nobody seemed to care either way ;-). Yet it is completely superfluous when this PEP gets accepted, as it offers a much nicer and general way to do the same thing. Rationale While experimenting with alternative implementation ideas to get builtin Zip import, it was discovered that achieving this is possible with only a fairly small amount of changes to import.c. This allowed to factor out the Zip-specific stuff into a new source file, while at the same time creating a *general* new import hook scheme: the one you're reading about now. An earlier design allowed non-string objects on sys.path. Such an object would have the neccesary methods to handle an import. This has two disadvantages: 1) it breaks code that assumes all items on sys.path are strings; 2) it is not compatible with the PYTHONPATH environment variable. The latter is directly needed for Zip imports. A compromise came from Jython: allow string *subclasses* on sys.path, which would then act as importer objects. This avoids some breakage, and seems to work well for Jython (where it is used to load modules from .jar files), but it was perceived as an "ugly hack". This lead to a more elaborate scheme, (mostly copied from McMillan's iu.py) in which each in a list of candidates is asked whether it can handle the sys.path item, until one is found that can. This list of candidates is a new object in the sys module: sys.path_hooks. Traversing sys.path_hooks for each path item for each new import can be expensive, so the results are cached in another new object in the sys module: sys.path_importer_cache. It maps sys.path entries to importer objects. To minimize the impact on import.c as well as to avoid adding extra overhead, it was chosen to not add an explicit hook and importer object for the existing file system import logic (as iu.py has), but to simply fall back to the builtin logic if no hook on sys.path_hooks could handle the path item. If this is the case, a None value is stored in sys.path_importer_cache, again to avoid repeated lookups. (Later we can go further and add a real importer object for the builtin mechanism, for now, the None fallback scheme should suffice.) A question was raised: what about importers that don't need *any* entry on sys.path? (Builtin and frozen modules fall into that category.) Again, Gordon McMillan to the rescue: iu.py contains a thing he calls the "metapath". In this PEP's implementation, it's a list of importer objects that is traversed *before* sys.path. This list is yet another new object in the sys.module: sys.meta_path. Currently, this list is empty by default, and frozen and builtin module imports are done after traversing sys.meta_path, but still before sys.path. (Again, later we can add real frozen, builtin and sys.path importer objects on sys.meta_path, allowing for some extra flexibility, but this could be done as a "phase 2" project, possibly for Python 2.4. It would be the finishing touch as then *every* import would go through sys.meta_path, making it the central import dispatcher.) As a bonus, the idea from the second paragraph of this section was implemented after all: a sys.path item may *be* an importer object. This use is discouraged for general purpose code, but it's very convenient, for experimentation as well as for projects of which it's known that no component wrongly assumes that sys.path items are strings. Specification part 1: The Importer Protocol This PEP introduces a new protocol: the "Importer Protocol". It is important to understand the context in which the protocol operates, so here is a brief overview of the outer shells of the import mechanism. When an import statement is encountered, the interpreter looks up the __import__ function in the builtin name space. __import__ is then called with four arguments, amongst which are the name of the module being imported (may be a dotted name) and a reference to the current global namespace. The builtin __import__ function (known as PyImport_ImportModuleEx in import.c) will then check to see whether the module doing the import is a package by looking for a __path__ variable in the current global namespace. If it is indeed a package, it first tries to do the import relative to the package. For example if a package named "spam" does "import eggs", it will first look for a module named "spam.eggs". If that fails, the import continues as an absolute import: it will look for a module named "eggs". Dotted name imports work pretty much the same: if package "spam" does "import eggs.bacon", first "spam.eggs.bacon" is tried, and only if that fails "eggs.bacon" is tried. Deeper down in the mechanism, a dotted name import is split up by its components. For "import spam.ham", first an "import spam" is done, and only when that succeeds is "ham" imported as a submodule of "spam". The Importer Protocol operates at this level of *individual* imports. By the time an importer gets a request for "spam.ham", module "spam" has already been imported. The protocol involves two objects: an importer and a loader. An importer object has a single method: importer.find_module(fullname) This method returns a loader object if the module was found, or None if it wasn't. If find_module() raises an exception, it will be propagated to the caller, aborting the import. A loader object also has one method: loader.load_module(fullname) This method returns the loaded module. In many cases the importer and loader can be one and the same object: importer.find_module() would just return self. The 'fullname' argument of both methods is the fully qualified module name, for example "spam.eggs.ham". As explained above, when importer.find_module("spam.eggs.ham") is called, "spam.eggs" has already been imported and added to sys.modules. However, the find_module() method isn't neccesarily always called during an actual import: meta tools that analyze import dependencies (such as freeze, Installer or py2exe) don't actually load modules, so an importer shouldn't *depend* on the parent package being available in sys.modules. The load_module() method has a few responsibilities that it must fulfill *before* it runs any code: - It must create the module object. From Python this can be done via the new.module() function, the imp.new_module() function or via the module type object; from C with the PyModule_New() function or the PyImport_ModuleAdd() function. The latter also does the following step: - It must add the module to sys.modules. This is crucial because the module code may (directly or indirectly) import itself; adding it to sys.modules beforehand prevents unbounded recursion in the worst case and multiple loading in the best. - The __file__ attribute must be set. This must be a string, but it may be a dummy value, for example "<frozen>". The priviledge of not having a __file__ attribute at all is reserved for builtin modules. - If it's a package, the __path__ variable must be set. This must be a list, but may be empty if __path__ has no further significance to the importer (more on this later). - It should add an __importer__ attribute to the module, set to the loader object. This is mostly for introspection, but can be used for importer-specific extra's, for example getting data associated with an importer. If the module is a Python module (as opposed to a builtin module or an dynamically loaded extension), it should execute the module's code in the module's global name space (module.__dict__). Here is a minimal pattern for a load_module() method: def load_module(self, fullname): ispkg, code = self._get_code(fullname) mod = imp.new_module(fullname) sys.modules[fullname] = mod mod.__file__ = "<%s>" % self.__class__.__name__ mod.__importer__ = self if ispkg: mod.__path__ = [] exec code in mod.__dict__ return mod Specification part 2: Registering Hooks There are two types of import hooks: Meta hooks and Path hooks. Meta hooks are called at the start of import processing, before any other import processing (so that meta hooks can override sys.path processing, or frozen modules, or even builtin modules). To register a meta hook, simply add the importer object to sys.meta_path (the list of registered meta hooks). Path hooks are called as part of sys.path (or package __path__) processing, at the point where their associated path item is encountered. A path hook can be registered in either of two ways: - By simply including an importer object directly on the path. This approach is discouraged for general purpose hooks, as existing code may not be expecting non-strings to exist on sys.path. - By registering an importer factory in sys.path_hooks. sys.path_hooks is a list of callables, which will be checked in sequence to determine if they can handle a given path item. The callable is called with one argument, the path item. The callable must raise ImportError if it is unable to handle the path item, and return an importer object if it can handle the path item. The callable is typically the class of the import hook, and hence the class __init__ method is called. (This is also the reason why it should raise ImportError: an __init__ method can't return anything.) The results of path hook checks are cached in sys.path_importer_cache, which is a dictionary mapping path entries to importer objects. The cache is checked before sys.path_hooks is scanned. If it is necessary to force a rescan of sys.path_hooks, it is possible to manually clear all or part of sys.path_importer_cache. Just like sys.path itself, the new sys variables must have specific types: sys.meta_path and sys.path_hooks must be Python lists. sys.path_importer_cache must be a Python dict. Modifying these variables in place is allowed, as is replacing them with new objects. Packages and the role of __path__ If a module has a __path__ attribute, the import mechanism will treat it as a package. The __path__ variable is used instead of sys.path when importing submodules of the package. The rules for sys.path therefore also apply to pkg.__path__. So sys.path_hooks is also consulted when pkg.__path__ is traversed and importer objects as path items are also allowed (yet, are discouraged for the same reasons as they are discouraged on sys.path, at least for general purpose code). Meta importers don't neccesarily use sys.path at all to do their work and therefore may also ignore the value of pkg.__path__. In this case it is still advised to set it to list, which can be empty. Integration with the 'imp' module The new import hooks are not easily integrated in the existing imp.find_module() and imp.load_module() calls. It's questionable whether it's possible at all without breaking code; it is better to simply add a new function to the imp module. The meaning of the existing imp.find_module() and imp.load_module() calls changes from: "they expose the builtin import mechanism" to "they expose the basic *unhooked* builtin import mechanism". They simply won't invoke any import hooks. A new imp module function is proposed under the name "find_module2", with is used like the following pattern: loader = imp.find_module2(fullname, path) if loader is not None: loader.load_module(fullname) In the case of a "basic" import, one the imp.find_module() function would handle, the loader object would be a wrapper for the current output of imp.find_module(), and loader.load_module() would call imp.load_module() with that output. Note that this wrapper is currently not yet implemented, although a Python prototype exists in the test_importhooks.py script (the ImpWrapper class) included with the patch. Open Issues The new hook method allows for the possibility of objects other than strings appearing on sys.path. Existing code is entitled to assume that sys.path only contains strings (the Python documentation states this). It is not clear if this will cause significant breakage. In particular, it is much less clear that code is entitled to assume that sys.path contains a list of *directory names* - most code which assumes that sys.path items contain strings also rely on this extra assumption, and so could be considered as broken (or at least "not robust") already. Modules often need supporting data files to do their job, particularly in the case of complex packages or full applications. Current practice is generally to locate such files via sys.path (or a package __path__ variable). This approach will not work, in general, for modules loaded via an import hook. There are a number of possible ways to address this problem: - "Don't do that". If a package needs to locate data files via its __path__, it is not suitable for loading via an import hook. The package can still be located on a directory in sys.path, as at present, so this should not be seen as a major issue. - Locate data files from a standard location, rather than relative to the module file. A relatively simple approach (which is supported by distutils) would be to locate data files based on sys.prefix (or sys.exec_prefix). For example, looking in os.path.join(sys.prefix, "data", package_name). - Import hooks could offer a standard way of getting at datafiles relative to the module file. The standard zipimport object provides a method get_data(name) which returns the content of the "file" called name, as a string. To allow modules to get at the importer object, zipimport also adds an attribute "__importer__" to the module, containing the zipimport object used to load the module. If such an approach is used, it is important that client code takes care not to break if the get_data method (or the __importer__ attribute) is not available, so it is not clear that this approach offers a general answer to the problem. Requiring loaders to set the module's __importer__ attribute means that the loader will not get thrown away once the load is complete. This increases memory usage, and stops loaders from being lightweight, "throwaway" objects. As loader objects are not required to offer any useful functionality (any such functionality, such as the zipimport get_data() method mentioned above, is optional) it is not clear that the __importer__ attribute will be helpful, in practice. On the other hand, importer objects are mostly permanent, as they live or are kept alive on sys.meta_path, sys.path_importer_cache or sys.path, so for a loader to keep a reference to the importer costs us nothing extra. Whether loaders will ever need to carry so much independent state for this to become a real issue is questionable. Implementation A C implementation is available as SourceForge patch 652586. http://www.python.org/sf/652586 References [1] Installer by Gordon McMillan http://www.mcmillan-inc.com/install1.html [2] PEP 273, Import Modules from Zip Archives, Ahlstrom http://www.python.org/peps/pep-0273.html [3] The Freeze tool Tools/freeze/ in a Python source distribution [4] Squeeze http://starship.python.net/crew/fredrik/ipa/squeeze.htm [5] py2exe by Thomas Heller http://py2exe.sourceforge.net/ [6] imp.set_frozenmodules() patch http://www.python.org/sf/642578 Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End: [View Less]

9 26

inet_ntop/inet_pton
by Jp Calderone Dec. 24, 2002

Dec. 24, 2002

I'm curious if 2.3 is going to make these two functions available in the socket module. There seems to be some support for them (or at least an attempt at functionality on platforms that don't support them) in socketmodule.c, but I don't see a Python interface for them. Is someone working on this? Should I work up a patch myself? :) Jp -- 12:00am up 8 days, 9:45, 3 users, load average: 0.05, 0.06, 0.01

1 0

ANN: PyObjC 0.8
by Bill Bumgarner Dec. 23, 2002

Dec. 23, 2002

PyObjC version 0.8 is now available for download. See... http://pyobjc.sourceforge.net/ ... for more information. The installer package includes a Project Builder project template for easily creating new Cocoa-Python projects and a slew of examples. Alternatively, the developer can choose to develop applications without using Apple's developer tools. Full support for Interface Builder documents is included. The PyObjC Python module provides a feature complete bridge between … [View More]the Python programming language and Objective-C. With PyObjC, it is possible to transparently message Objective-C objects from Python and Python objects from Objective-C. Objective-C objects can be subclassed from within Python. Support is also included for using the various functions, enumerated types, and global variables found throughout the Objective-C framework. References to python dictionaries pass into Objective-C act like a well behaved member of the NSDictionary class cluster. Likewise, Python List references behave like a member of the NSArray class cluster. Strings are transparently converted to the native type. NSArray and NSDictionary references passed into Python behave like native Python lists and dictionaries; including the ability to enumerate either using the 'in' operator and to slice NSArray and NSMutableArray instances. PyObjC fully supports creating full featured Cocoa applications written in pure Python. There are aspects of PyObjC that are more powerful than Cocoa in pure Obj-C (the ability to automatically define classes/outlets based on the contents of a NIB file, for example). PyObjC requires OS X 10.2 or greater. 10.1 support is possible and will likely happen soon-- contact me if you need 10.1 support and are willing to do a bit of grunt work to generate the appropriate files (easy to do-- just need a 10.1 development machine). The installer package is designed to work with the built-in Python provided in OS X 10.2. Source is included on the disk image and the pyobjc module works with Python 2.2 or greater as installed directly from the Python Source, with the MacPython packages, and with the Fink build of python. PyObjC also provides an awesome environment for exploring frameworks. The following transcript was copied out of a Terminal window-- it is an example of working directly with the Objective-C runtime from Python within the terminal. >>> from objc import * >>> from Foundation import * >>> b = NSBundle.bundleWithPath_("/System/Library/PrivateFrameworks/ PBXCore.framework") >>> b.principalClass() <objective-c class PBXProducerTarget at 0xa9030034> >>> NSBundle.searchPathsForSupportFilesWithSubpath_("FooBar") ( "/Volumes/Data/Users/bbum/Developer/ProjectBuilder Extras/FooBar", "/Network/Developer/ProjectBuilder Extras/FooBar", "/Developer/ProjectBuilder Extras/FooBar" ) >>> PBXProject = lookUpClass("PBXProject") >>> p = PBXProject.projectWithFile_("/Developer/Examples/AppKit/TextEdit/ TextEdit.pbproj") >>> p.targets() (<PBXApplicationTarget:0x00a76830:6FE2093EFE93D5F211CA2CEA:name='TextEdi t'>) >>> p.buildStyles() ( <PBXBuildStyle:0x00a77d30:011ADBA3FF9FD52E11CA0C5D:name='Development':bu ildSettings.count=2>, <PBXBuildStyle:0x00a82180:011ADBA4FF9FD52E11CA0C5D:name='Deployment':bui ldSettings.count=1> ) The version # of 0.8 indicates that documentation is lacking, unit tests are incomplete and there may be a bug or two lurking within. In practice, the module has proven to be very stable and to allow for the development of extremely complex Cocoa projects in pure Python or a mix of Python and Objective-C. [View Less]

1 0

Re: [Python-Dev] New Import Hooks PEP, a first draft (and req. for PEP #)
by Moore, Paul Dec. 20, 2002

Dec. 20, 2002

Aahz said: > Any reason we can't require importer objects to be new-style > classes, which could then use __new__? (I vaguely recall > some discussion about this, but it should be documented in > the PEP.) Basically, why bother? It just makes writing importers (mildly) more complex (most people know about __init__ whereas __new__ is ... err ... newer), where the existing proposal works fine. But you're right, a comment in the PEP would be good. Paul

1 0

Hi everyone!!
by 김재혁 Dec. 20, 2002

Dec. 20, 2002

I’m a new member of python mailing list. I’ve developed some programs with python for 2 years ( especially, Database programs using Oracle , MS-SQL , DB2 ) I hope to be a good helper and friend to you Have a nice day ------------------------------------ Kim Jae Hyuk Customer Engineer Development Division I-ON Communications TEL : 82-2-574-1080 Mail : airkjh(a)i-on.net ------------------------------------

1 0

Strange crash in import
by Jack Jansen Dec. 19, 2002

Dec. 19, 2002

I'm getting a strange crash in import, and it turns out that there's a refcount 0 object on sys.path. Has any of the code for zip imports been checked in yet? Otherwise, does anyone have a clue what could be going on (i.e. what silly mistake did I make:-)? The situation I'm in (the stack trace is below) is that I'm in the tp_init routine of an object when a macos-error occurs. I then call PyMac_Error to format the error. PyMac_Error then needs to import a pure Python module (which … [View More]will give it the pretty huge list of MacOS error codes and the corresponding strings). This crashes, because the second entry on sys.path is a refcount 0 object: #1 0x003fcf10 in find_module (realname=0x46f2cc "", path=0x13b310, buf=0xbfffeac0 "macresource.pyc", buflen=1025, p_fp=0xbfffeed0) at ../Python/import.c:987 987 if (PyUnicode_Check(v)) { (gdb) p _PyObject_Dump(path) object : ['', <refcnt 0 at 0x13e548>, '/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat- darwin', '/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib- tk', '/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib- dynload', '/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site- packages', '/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib', '/Library/Frameworks/Python.framework/Versions/2.3/Mac/Lib/lib- scriptpackages'] If I manually import the "macresource" module beforehand everything works as expected, and sys.path[1] isn't a refcount zero object. Here's the full stack trace: (gdb) where #0 PyType_IsSubtype (a=0x0, b=0x457d44) at ../Objects/typeobject.c:704 #1 0x003fcf10 in find_module (realname=0x46f2cc "", path=0x13b310, buf=0xbfffeac0 "macresource.pyc", buflen=1025, p_fp=0xbfffeed0) at ../Python/import.c:987 #2 0x003fe520 in import_submodule (mod=0x4522b8, subname=0xbfffefc0 "macresource", fullname=0xbfffefc0 "macresource") at ../Python/import.c:1998 #3 0x003fe034 in load_next (mod=0x4522b8, altmod=0x4522b8, p_name=0xbfffefc0, buf=0xbfffefc0 "macresource", p_buflen=0xbffff3d0) at ../Python/import.c:1863 #4 0x003ffef0 in import_module_ex (name=0x0, globals=0x457d44, locals=0x1b6, fromlist=0x13b390) at ../Python/import.c:1714 #5 0x003ff0d4 in PyImport_ImportModuleEx (name=0x145b9c "macresource", globals=0x148780, locals=0x148780, fromlist=0x13b390) at ../Python/import.c:1755 #6 0x003ce2fc in builtin___import__ (self=0x0, args=0x457d44) at ../Python/bltinmodule.c:40 #7 0x00370b98 in PyObject_CallFunction (callable=0x12efd0, format=0x0) at ../Objects/abstract.c:1675 #8 0x003feb40 in PyImport_Import (module_name=0x145b88) at ../Python/import.c:2160 #9 0x003fefb8 in PyImport_ImportModule (name=0x0) at ../Python/import.c:1686 #10 0x004108a0 in PyMac_StrError (err=-43) at ../Python/mactoolboxglue.c:107 #11 0x00410e00 in PyMac_Error (err=-43) at ../Python/mactoolboxglue.c:169 #12 0x00265af4 in myPyMac_GetFSRef (v=0x18c760, fsr=0x13e4f8) at /Users/jack/src/python/Mac/Modules/file/_Filemodule.c:2400 #13 0x00263ef8 in FSRef_tp_init (self=0x13e4f0, args=0x457d44, kwds=0x1b6) at /Users/jack/src/python/Mac/Modules/file/_Filemodule.c:1243 #14 0x003b407c in type_call (type=0x268454, args=0x14fed0, kwds=0x0) at ../Objects/typeobject.c:438 #15 0x00374028 in PyObject_Call (func=0x0, arg=0x457d44, kw=0x1b6) at ../Objects/abstract.c:1675 #16 0x003da754 in do_call (func=0x45e88c, pp_stack=0xbffff8fc, na=1, nk=4443236) at ../Python/ceval.c:3398 #17 0x003da53c in call_function (pp_stack=0xbffff8fc, oparg=4554052) at ../Python/ceval.c:3268 #18 0x003d8044 in eval_frame (f=0xa37c0) at ../Python/ceval.c:2009 #19 0x003d9354 in PyEval_EvalCodeEx (co=0x141660, globals=0x457d44, locals=0x3fcf10, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:2554 #20 0x003dbfe0 in PyEval_EvalCode (co=0x0, globals=0x457d44, locals=0x1b6) at ../Python/ceval.c:478 #21 0x0040b788 in run_node (n=0x0, filename=0x457d44 "", globals=0x148780, locals=0x148780, flags=0x0) at ../Python/pythonrun.c:1089 #22 0x0040ac88 in PyRun_InteractiveOneFlags (fp=0xa390c, filename=0x141660 "", flags=0xbffffc50) at ../Python/pythonrun.c:593 #23 0x0040aa80 in PyRun_InteractiveLoopFlags (fp=0x44aaac, filename=0x137140 "", flags=0x14a4c0) at ../Python/pythonrun.c:522 #24 0x0040c604 in PyRun_AnyFileExFlags (fp=0xa0000cd4, filename=0x444fdc "<stdin>", closeit=669964, flags=0xbffffc50) at ../Python/pythonrun.c:485 #25 0x00416db0 in Py_Main (argc=-1610609452, argv=0x0) at ../Modules/main.c:442 #26 0x00001b5c in _start (argc=673326145, argv=0x0, envp=0x44653c) at /SourceCache/Csu/Csu-45/crt.c:267 #27 0x000019dc in start () -- - Jack Jansen <Jack.Jansen(a)oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - [View Less]

2 2

MacOSX build broken
by Just van Rossum Dec. 19, 2002

Dec. 19, 2002

A plain ./configure ends like this, without creating a Makefile: checking for --with-universal-newlines... --without-universal-newlines is unsupported, see README The README confirms --with-universal-newlines is no longer supported. Yet I didn't specify --with-universal-newlines and the README doesn't tell me what to do either. What's up? Just

2 1