Python-Dev April 2000

python-dev@python.org

63 participants
125 discussions

list comprehensions patch - updated for current CVS version
by Skip Montanaro 25 Apr '00

25 Apr '00

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/

1 0

Re: [Python-checkins] CVS: python/dist/src/PCbuild winsound.dsp,NONE,1.1 _socket.dsp,1.1,1.2 _sre.dsp,1.2,1.3 _tkinter.dsp,1.13,1.14 bsddb.dsp,1.9,1.10 mmap.dsp,1.2,1.3 parser.dsp,1.8,1.9 pyexpat.dsp,1.2,1.3 python.dsp,1.10,1.11 python16.dsp,1.2,1.3 pythonw.dsp,1.8,1.9 select.dsp,1.1,1.2 unicodedata.dsp,1.1,1.2 zlib.dsp,1.10,1.11
by Greg Stein 24 Apr '00

24 Apr '00

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/

3 3

Inspiration
by Guido van Rossum 22 Apr '00

22 Apr '00

http://www.perl.com/pub/2000/04/whatsnew.html --Guido van Rossum (home page: http://www.python.org/~guido/)

3 4

RE: [Thread-SIG] Re: marking shared-ness
by Greg Stein 21 Apr '00

21 Apr '00

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/

1 0

RE: [Thread-SIG] Re: [Python-Dev] Re: marking shared-ness
by Bill Tutt 21 Apr '00

21 Apr '00

> 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

1 0

String issues -- see the JavaScript world
by David Ascher 20 Apr '00

20 Apr '00

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

1 0

Generic notifier module
by Ka-Ping Yee 20 Apr '00

20 Apr '00

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

4 8

[OT] [Q] corruption in DB files?
by Greg Stein 20 Apr '00

20 Apr '00

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/

2 1

RE: [Thread-SIG] Re: [Python-Dev] baby steps for free-threading
by Salz, Rich 20 Apr '00

20 Apr '00

>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.

5 4

comp.lang.python.announce
by Jeremy Hylton 20 Apr '00

20 Apr '00

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

8 13

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev April 2000