The following message is a courtesy copy of an article
that has been posted to comp.lang.python as well.
David Abrahams <dave(a)boost-consulting.com> writes:
> Aahz <aahz(a)pythoncraft.com> writes:
>> I think this thread might be better handled on c.l.py, at least
>> until it's understood well enough to be clear whether something does
>> need to change in Python.
> I'm pretty certain I understand what's going on. If it would be
> better for you to take this to c.l.py, I'm happy to do so, but AFAICT
> there _is_ a Python core issue here: there's no way to find out
> whether you've already got the GIL**, so if you _might_ have to acquire
> it, you must always acquire it.
> **If I'm wrong about that, please let me know. It isn't obvious from
> the documentation.
This is the continuation of a thread originated on python-dev; I was
asked to re-raise it here on python-list until the issue is better
The original posting was here:
The he essence of the problem is that there's no way to write code
that uses the Python 'C' API and which has no knowledge of whether it
is running on Python's main thread when it is entered.
The two respondents were left with some questions; you can read those,
and my responses, in the thread at the bottom of the page referenced
Thanks for your attention,
dave(a)boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
PAX - the "Pythonic API for XML" - is a XML-handling library.
Like with DOM, you're supposed to first parse the whole stream into the
internal representation, and then operate on it.
What distinguishes PAX is that its implementation is python-oriented; you
iterate trough child nodes via the normal ways (for, getitem, and in 2.2+,
an iterator), the attributes are dictionary-based, etc.
I used it to successfully reimplement TAL and PageTemplates (used in Zope).
This reimplementation (AltPT) is quite stable and in production users in a
few dozen servers around the world.
PAX also includes a powerful python-oriented transform engine, which I used
The code has been tested on Python 2.1, 2.2 and recent CVS checkouts. It
not only works, but transparently uses recent interesting features when
available - notably, enumerate().
Most of the code is in public domain, and of course I make no objections to
switching to PSL. In fact the package was designed all along with the
intention of offering it to the standard library (and I like to think that
this led me to cleaner design and a readable implementation).
It is in active maintenence; if not much development happened in the last
few months, it's because it reached some maturity. In fact I just released
1.0alpha1 before sending this mail (15k tar.bz2)
PAX has a small site at my very-slow (due to bad connectivity) Zope server
at http://python.laranja.org/pax/ - this site, btw, runs on AltPT. The
releases can be found there, and the cvs is (for hystorical reasons) at
module miscfiles/python/pax (because it was originally developed as I needed
an XML library for my "flyingcircus" pda project).
Should I write a PEP? Or a patch (silly, it would be a quite big patch)?
Those who trade freedom for security
lose both and deserve neither.
pgp key: http://www.laranja.org/pessoal/pgp
Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/
GNU: never give up freedom http://www.gnu.org/
test_pyclbr is failing due to the changes in random:
test test_pyclbr failed -- Traceback (most recent call last):
File "/home/neal/build/python/dist/src/Lib/test/test_pyclbr.py", line 146, in test_others
cm('random', ignore=('_verify',)) # deleted
File "/home/neal/build/python/dist/src/Lib/test/test_pyclbr.py", line 97, in checkModule
self.assertListEq(real_bases, pyclbr_bases, ignore)
File "/home/neal/build/python/dist/src/Lib/test/test_pyclbr.py", line 33, in assertListEq
self.fail("%r missing" % item)
File "/home/neal/build/python/dist/src/Lib/unittest.py", line 260, in fail
raise self.failureException, msg
AssertionError: 'Random' missing
I've finally come up with a patch I'm 90% happy with for this problem,
got my iBook's modem talking to my ISP right and created a diff.
Unfortunately, SF's tracker isn't behaving and I'm about to disappear
from the internet for a day or so and 2.3a1 is due tomorrow, so it's
There's one outstanding problem with the compiler package to do with
code of the form (unary operator)constant which is shown up by
test_grammar, but that aside I can compile the test suite and the
standard library using the patched compiler package and it runs fine.
I'd really like to see this patch in 2.3a1. I'll fix the -literal
thing for 2.3a2, but I bet noone notices it in the mean time :)
at any rate, I'm satisfied that not only do they know which end of
the pointy thing to hold, but where to poke it for maximum effect.
-- Eric The Read, asr, on google.com
Aahz <aahz(a)pythoncraft.com> writes:
> [Originally posted to comp.lang.python with no response; asking here
> before filing a bug report]
> Is garbage collection supposed to run when Python exits? The following
> program does not print any output, unless I uncomment the gc.collect()
> (or add a for loop that forces GC after creating the cycle):
> import gc
> class A:
> class B:
> def __del__(self):
> print "Bye-bye!"
> a = A()
> b = A()
> a.b = b
> b.a = a
> a.x = B()
> del a
> del b
One possibility is that the __del__ method *is* being run, but after
sys.stdout & so on has been torn down. python -v can help, maybe?
Unfortunately, nigh the whole world is now duped into thinking that
silly fill-in forms on web pages is the way to do user interfaces.
-- Erik Naggum, comp.lang.lisp
Oops, there something that's been on my todo list for quite a while but
that I haven't taken any action on (at least I can put part of the
blame on Just, it was his idea and he didn't take any action either:-):
moving Mac/Lib to Lib/plat-mac. The main reason for doing this is that
most (if not all) of those modules are useable in unix-Python on MacOSX
too, and moreover it would make the MacPython-OS9 tree look a little
more like the normal Python tree. site.py would get one extra line with
a special case (if sys.platform==darwin we not only add plat-darwin to
the path but also plat-mac).
Is it a good idea to try and get this in before 2.3a1? Is it a better
idea to try and get this in between 2.3a1 and the next release (2.3a2?
And on the technical implementation: I think I would ask the SF
maintainers to *copy* Mac/Lib to Lib/plat-mac, and then manually delete
Mac/Lib on the trunk and Lib/plat-mac on the 2.2 maintenance branch. Is
that a good idea?
A similar case can be made for other Mac subdirs (Mac/Tools->Tools/Mac,
Mac/scripts->Tools/Mac/scripts), but that is less essential and can
probably wait until later.
- Jack Jansen <Jack.Jansen(a)oratrix.com>
- If I can't dance I don't want to be part of your revolution -- Emma
Just van Rossum <just(a)letterror.com> writes:
> I find this rather ugly, and would only do that if it's crucial that the
> pathless importer should be invoked somewhere in the middle of sys.path.
> And I don't have a use case for that. There are plenty of use cases for
I've not really been following this discussion with utmost care, but
the name "meta_path" doesn't move me. Wouldn't sys.importers be
better name? Or maybe I'm misunderstanding it's intent -- which is
still an argument for a better name.
Also, remember to put the galaxy back when you've finished, or an
angry mob of astronomers will come round and kneecap you with a
small telescope for littering.
-- Simon Tatham, ucam.chat, from Owen Dunn's review of the year
Just van Rossum <just(a)letterror.com> writes:
> Michael Hudson wrote:
> > I've not really been following this discussion with utmost care, but
> > the name "meta_path" doesn't move me. Wouldn't sys.importers be
> > better name? Or maybe I'm misunderstanding it's intent -- which is
> > still an argument for a better name.
> I don't like the name much either, but it _does_ fit quite well as the
> idea is that sys.path importing gets invoked through an item on
> meta_path. Perhaps this sketch helps a little:
> sys.meta_path = [
> BuiltinImporter(), # handles builtin modules
> FrozenImporter(), # handles frozen modules
> PathImporter(), # handles sys.path
Right, that's what I thought was roughly the plan -- but I still don't
like the name. In this world, sys.path is sort-of subsidiary to
sys.meta_path -- which jars, to me at least. It makes sense with a
bit of historical knowledge, but not without, IMHO.
Of course, these mild gripes shouldn't delay the real work -- but
names are important.
Remember - if all you have is an axe, every problem looks
like hours of fun. -- Frossie
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>