[Python-Dev] Slow tests involving bsddb - timeout
I noticed that test_anydbm and test_bsddb seemed to hang, so I -x'd them. Later on while test_whichdb was running and I was off doing something else (so didn't notice the delay), it eventually spewed this traceback: Traceback (most recent call last): File "/Users/skip/src/python/trunk/Lib/test/test_whichdb.py", line 49, in test_whichdb_name f = mod.open(_fname, 'c') File "/Users/skip/src/python/trunk/Lib/dbhash.py", line 16, in open return bsddb.hashopen(file, flag, mode) File "/Users/skip/src/python/trunk/Lib/bsddb/__init__.py", line 310, in hashopen d.open(file, db.DB_HASH, flags, mode) DBFileExistsError: (17, 'File exists -- __fop_file_setup: Retry limit (100) exceeded') Looking at _bsddb.so I see it's linked against Berkeley DB 4.5. This is on Mac OSX 10.4.11 using the MacPorts version of Berkeley DB (4.5.20). Have I somehow strayed out of the support cocoon without realizing it? I wouldn't have thought so, since the max version listed in setup.py is 4.6. Thx, Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
I just want to let you all know that the name issue was settled and committed to py3k branch a few days ago. It was chosen to simply rename the module __builtin__ to builtins. -- Alexandre On Nov 29, 2007 6:15 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Given that the *effect* of __builtins__ is to make the contents of the > __builtin__ module implicitly available in every module's global > namespace, why not call it __implicit__? > > I really don't like all of these __root__ inspired names, because > __builtin__ isn't the root of any Python hierarchy that I know of. > > >>> import sys > >>> import __builtin__ > >>> __builtin__.sys > Traceback (most recent call last): >File "", line 1, in > AttributeError: 'module' object has no attribute 'sys' > > The builtin namespace doesn't know anything about other modules, the > current module's global namespace, the current function's local > variables, or much of anything really. To me, the concept of "root" in a > computing sense implies a node from which you can reach every other node > - from the root of the filesystem you can get to every other directory, > as the root user you can access any other account, etc. To those that > like these names, what do you consider __root__ to be the root of? > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Oh, sorry for the noise. I thought people were still arguing about the name issue, but it was in fact 5-day late emails that I am still receiving. (Gmail seems to have delivery issues lately...) -- Alexandre On Dec 4, 2007 12:49 PM, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote: > I just want to let you all know that the name issue was settled and > committed to py3k branch a few days ago. It was chosen to simply > rename the module __builtin__ to builtins. > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Non-string keys in namespace dicts
PJE wrote: > Isn't the simplest way to cache attribute > lookups to just have a cache dictionary in the type, > and update that dictionary whenever a change is > made to a superclass? That's essentially how > __slotted__ attribute changes on base classes > work now, isn't it? Neil Toronto wrote: > The nice thing about caching pointers to dict > entries is that they don't change as often as > values do. Is this really true for namespaces? I was thinking that the typical namespace usage is a bunch of inserts (possibly with lookups mixed in), followed by never changing it again until it is deallocated. > There are fewer ways to invalidate an > entry pointer: inserting set, resize, clear, and delete. I'm not sure how to resize without an inserting set. I'm not sure I've ever seen clear on a namespace. (I have seen it on regular dicts being used as a namespace, such as tcl config options.) I have seen deletes (deleting a temp name) and non-inserting sets ... but they're both rare enough that letting them force the slow path might be a good trade, if the optimization is otherwise simpler. > Rare updating also means it's okay to invalidate the > entire cache rather than single entries Changing __bases__ seems to do that already. (See http://svn.python.org/view/python/trunk/Objects/typeobject.c?rev=59106&view=markup functions like update_subclasses.) So I think an alternate version PJE's question would be: Why not just extend that existing mechanism to work on non-slot, non-method attributes? -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Mac _OSA extension doesn't build on Leopard
On OSX 10.5 with Xcode 3.0, whenever I build either the trunk or the py3k or 25 branches, I get a series of errors when setup.py tries to build the _OSA module. On OSX 10.4 it builds fine. Can anybody help? I don't even know what OSA is! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mac _OSA extension doesn't build on Leopard
> Can anybody help? > I don't even know what OSA is! I can help with that: It's the Open Scripting Architecture, http://developer.apple.com/documentation/AppleScript/Conceptual/AppleScriptX/Concepts/osa.html (Probably not the kind of help you were asking for :-) Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mac _OSA extension doesn't build on Leopard
I shifted to Leopard a couple of weeks ago. Seems to build and test fine, but I disable all the various poorly documented/maintained Mac modules, so my configure looks like this: ./configure --disable-universalsdk --disable-framework --disable-toolbox-glue I believe OSA is "toolbox glue", so I'll see what happens. Sure enough, looks like the API to the OSA changed with 10.5. Not unreasonable. I'd say, just add "--disable-toobox-glue". Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mac _OSA extension doesn't build on Leopard
On 4 Dec, 2007, at 22:49, Guido van Rossum wrote: > On OSX 10.5 with Xcode 3.0, whenever I build either the trunk or the > py3k or 25 branches, I get a series of errors when setup.py tries to > build the _OSA module. On OSX 10.4 it builds fine. Can anybody help? > I don't even know what OSA is! I'll try to do a crude fix later this week. The Carbon bindings also wrap some deprecated API's, some of which were dropped in Leopard. We're kind of lucky that _OSA is the only one that no longer compiles. A correct fix will take some more time, as this will require retargeting the bgen tool to use System headers instead of the OS9 (!) headers that were used to generate the current Carbon bindings. Ronald ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
