For those folks that might want to fiddle with list comprehensions I tweaked
Greg Ewing's list comprehensions patch to work with the current CVS tree.
The attached gzip'd patch contains diffs for
Grammar/Grammar
Include/graminit.h
Lib/test/test_grammar.py
Lib/test/output/test_grammar
Python/compile.c
Python/graminit.c
I would have updated the corresponding section of the language reference,
but the BNF there didn't match the contents of Grammar/Grammar, so I was a
bit unclear what needed doing. If it gets that far perhaps someone else can
contribute the necessary verbiage or at least point me in the right
direction.
--
Skip Montanaro | http://www.mojam.com/
skip(a)mojam.com | http://www.musi-cal.com/
On Fri, 21 Apr 2000, Guido van Rossum wrote:
>...
> * Base address for all extension modules updated. PC\dllbase_nt.txt
> also updated. Erroneous "libpath" directory removed for all
> projects.
Rather than specifying the base address in each DSP, the Apache project
has used a text file for this stuff. Here is the text file used:
--snip--
-- Begin New BaseAddr.ref --
; os/win32/BaseAddr.ref contains the central repository
; of all module base addresses
; to avoid relocation
; WARNING: Update this file by reviewing the image size
; of the debug-generated dll files; release images
; should fit in the larger debug-sized space.
; module name base-address max-size
aprlib 0x6FFA0000 0x00060000
ApacheCore 0x6FF00000 0x000A0000
mod_auth_anon 0x6FEF0000 0x00010000
mod_cern_meta 0x6FEE0000 0x00010000
mod_auth_digest 0x6FED0000 0x00010000
mod_expires 0x6FEC0000 0x00010000
mod_headers 0x6FEB0000 0x00010000
mod_info 0x6FEA0000 0x00010000
mod_rewrite 0x6FE80000 0x00020000
mod_speling 0x6FE70000 0x00010000
mod_status 0x6FE60000 0x00010000
mod_usertrack 0x6FE50000 0x00010000
mod_proxy 0x6FE30000 0x00020000
--snip--
And here is what one of the link lines looks like:
# ADD LINK32 ApacheCore.lib aprlib.lib kernel32.lib /nologo
/base:@BaseAddr.ref,mod_usertrack /subsystem:windows /dll /map /debug
/machine:I386 /libpath:"..\..\CoreD" /libpath:"..\..\lib\apr\Debug"
This mechanism could be quite helpful for Python. The .ref file replaces
the dllbase_nt.txt file, centralizes the management, and directly
integrates with the tools.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Fri, 21 Apr 2000, Brent Fulgham wrote:
>...
> The problem is that having to grab the global interpreter lock
> every time I want to manipulate Python objects from C seems wasteful.
> This is perhaps more of a "interpreter" issue, rather than a
> thread issue perhaps, but it does seem that if each thread (and
> therefore interpreter state from my perspective) kept internal
> track of itself, there would be much less lock contention as one
> interpreter drops out of Python into the C code for a moment, then
> releases the lock and returns, etc.
>
> So I think it's possible that free-threading changes might provide
> some benefit even on uniprocessor systems.
This is true. Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS become null
macros. Your C extensions operate within their thread of execution, but
have no central lock to worry about releasing before they block on
something.
And from an embedding standpoint, the same is true. You do not need to
acquire any locks to start manipulating Python objects. Each object
maintains its own integrity.
Note: embedding/extending *can* destroy integrity. For example, tuples
have no integrity locking -- Python programs cannot change them, so you
cannot have two Python threads breaking things. C code can certainly
destroy things with something this simple:
Py_DECREF(PyTuple_GET_ITEM(tuple, 3));
PyTuple_SET_ITEM(tuple, 3, ob);
Exercise for the reader on why the above code is a disaster waiting to
happen :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
> From: Milton L. Hankins [mailto:mlh@swl.msd.ray.com]
>
> On Fri, 21 Apr 2000, Christian Tismer wrote:
>
> > Are you shure that every thread user shares your opinion?
> > I see many people using threads just in order to have
> > multiple tasks in parallel, with none or quite few shared
> > variables.
>
> About the only time I use threads is when
> 1) I'm doing something asynchronous in an event loop-driven
> paradigm
> (such as Tkinter) or
> 2) I'm trying to emulate fork() under win32
>
3) I'm doing something that would block in an asynchronous FSM. (e.g.
Medusa, or an NT I/O completion port driven system)
> > Since Python has nothing really private, this implies in
> > fact to protect every single object for free threading,
> > although nobody wants this in the first place to happen.
>
> How does Java solve this problem? (Is this analagous to
> native vs. green
> threads?)
>
Java allows you to specifically mention whether something should be
seralized or not, and no, this doesn't have anything to do with native vs.
green threads)
> > Python is not designed for that. Why do you want to enforce
> > the impossible, letting every object pay a high penalty
> > to become completely thread-safe?
>
> Hmm, how about declaring only certain builtins as free-thread
> safe?
incref/decref are not type object specific, they're global macros.
Making them methods on the type object would be the sensible thing to do,
but would definately be non-backward compatible.
Bill
Just an FYI to those discussing Unicode issues. There is currently a big
debate over in Mozilla-land looking at how XPIDL (their interface definition
language) should deal with the various kinds of string types. Someone who
cares may want to follow up on that to see if some of their issues apply to
Python as well.
News server: news.mozilla.org
Newsgroup: netscape.public.mozilla.xpcom
Thread: Encoding wars -- more in the Big String Story
Cheers,
--david
I think it would be very nice for the Python standard library to
provide a messaging mechanism (you may know it as signals/slots,
publish/subscribe, listen/notify, etc.). This could be very useful,
especially for interactive applications where various components
need to keep each other up to date about things. I know of several
Tkinter programs where i'd like to use this mechanism.
The proposed interface is:
To add notification ability, mix in class notifier.Notifier.
object.notify(message, callback) - Set up notification for message.
object.denotify(message[, callback]) - Turn off notification.
object.send(message, **args) - Call all callbacks registered on
object for message, in reverse order of registration, passing
along message and **args as arguments to each callback.
If a callback returns notifier.BREAK, no further callbacks
are called.
(Alternatively, we could use signals/slots terminology:
connect/disconnect/emit. I'm not aware of anything the signals/slots
mechanism has that the above lacks.)
Two kinds of messages are supported:
1. The 'message' passed to notify/denotify may be a class, and
the 'message' passed to send may be a class or instance of
a message class. In this case callbacks registered on that
class and all its bases are called.
2. The 'message' passed to all three methods may be any other
hashable object, in which case it is looked up by its hash,
and callbacks registered on a hash-equal object are called.
Thoughts and opinions are solicited (especially from those who have
worked with messaging-type things before, and know the gotchas!).
I haven't run into many tricky problems with these things in
general, and i figure that the predictable order of callbacks should
reduce complication. (I chose reverse ordering so that you always
have the ability to add a callback that overrides existing ones.)
A straw-man implementation follows. The callback registry is
maintained in the notifier module so you don't have to worry
about it messing up the attributes of your objects.
-------- snip snip ---------------------------------- notifier.py --------
# If a callback returns BREAK, no more callbacks are called.
BREAK = "break"
# This number goes up every time a callback is added.
serial = 0
# This dictionary maps callback functions to serial numbers.
callbacks = {}
def recipients(sender, message):
"""Return a list of (serial, callback) pairs for all the callbacks
on this message and its base classes."""
key = (sender, message)
if callbacks.has_key(key):
list = map(lambda (k, v): (v, k), callbacks[key].items())
else:
list = []
if hasattr(message, "__bases__"):
for base in message.__bases__:
list.extend(recipients(sender, base))
return list
class Notifier:
def send(self, message, **args):
"""Call any callbacks registered on this object for the given message.
If message is a class or instance, callbacks registered on the class
or any base class are called. Otherwise callbacks registered on a
message of the same value (compared by hash) are called. The message
and any extra keyword arguments are passed along to each callback."""
if hasattr(message, "__class__"):
message = message.__class__
recip = recipients(self, message)
recip.sort()
recip.reverse()
for serial, callback in recip:
if callback(message, **args) == BREAK: return
def notify(self, message, callback):
"""Register a callback on this object for a given message. The
message should be a class (not an instance) or a hashable object."""
key = (self, message)
if not callbacks.has_key(key):
callbacks[key] = {}
callbacks[key][callback] = serial = serial + 1
def denotify(self, message, callback=None):
"""Unregister a particular callback or all existing callbacks on
this object for a given message. The message should be a class
(not an instance) or a hashable object."""
key = (self, message)
if callbacks.has_key(key):
if callback is None:
del callbacks[key]
elif callbacks[key].has_key(callback):
del callbacks[key][callback]
-------- snip snip ---------------------------------- notifier.py --------
-- ?!ng
"Je n'aime pas les stupides gar�ons, m�me quand ils sont intelligents."
-- Roople Unia
Hey guys,
You're the Smart Guys that I know, and it seems this is also the forum
where I once heard a long while back that DB can occasionally corrupt its
files.
True? Was it someone here that mentioned that? (Skip?)
Or maybe it was bsddb? (or is that the same as the Berkeley DB, now
handled by Sleepycat)
A question just came up elsewhere about DB and I seemed to recall somebody
mentioning the occasional corruption. Oh, maybe it was related to multiple
threads.
Any help appreciated!
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
>This definitely slows Python down. If an object is known to be visible to
>only one thread, then you can avoid the atomic inc/dec. But that leads to
>madness :-)
I would much rather see the language extended to indicate that a particular
variable is "shared" across free-threaded interpreters. The hit of taking
a mutex on every incref/decref is way bad.
As many of you have probably noticed, the moderators of
comp.lang.python.announce do not deal with pending messages in a
timely manner. There have been no new posts since Mar 27, and
delays of several weeks were common before then.
I wanted to ask a smallish group of potential readers of this group
what we should do about the problem. I have tried to contact the
moderators several times, but haven't heard a peep from them since
late February, when the response was: "Sorry. Temporary problem.
It's all fixed now."
Three possible solutions come to mind:
- Get more moderators. It appears that Marcus Fleck is the only
active moderator. I have never received a response to private email
sent to Vladimir Ulogov. I suggested to Marcus that we get more
moderators, but he appeared to reject the idea. Perhaps some peer
pressure from other unsatisfied readers would help.
- De-couple the moderation of comp.lang.python.announce and of
python-annouce(a)python.org. We could keep the gateway between the
lists going, but have different moderators for the mailing list. This
would be less convenient for people who prefer to read news, but would
at least get announcement out in a timely fashion.
- Give up on comp.lang.python.announce. Since moderation has been so
spotty, most people have reverted to making all anouncements to
comp.lang.python anyway. This option is unfortunate, because it makes
it harder for people who don't have time to read comp.lang.python to
keep up with announcements.
Any other ideas? Suggestions on how to proceed?
Jeremy