Leo 4.4.4 beta 1 released
Leo 4.4.4 beta 1 is available at: http://sourceforge.net/project/showfiles.php?group_id=3458package_id=29106 Leo is a text editor, data organizer, project manager and much more. See: http://webpages.charter.net/edreamleo/intro.html The highlights of Leo 4.4.4: - A threading_colorizer plugin replaces the __jEdit_colorizer__ plugin. This plugin features much better performance. - Support for @auto nodes. Such nodes allow people to collaborate using Leo without inserting Leo sentinels in the files Leo generates. Links: -- Leo: http://webpages.charter.net/edreamleo/front.html Home: http://sourceforge.net/projects/leo/ Download: http://sourceforge.net/project/showfiles.php?group_id=3458 CVS: http://leo.tigris.org/source/browse/leo/ Quotes: http://webpages.charter.net/edreamleo/testimonials.html Edward K. Ream email: [EMAIL PROTECTED] Leo: http://webpages.charter.net/edreamleo/front.html -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Compyler 0.1
Compyler is a pre-alpha x86 native code compiler. So far it can generate primitive .pyds but not standalone executables. It can run some simple test cases including pystones (although there is a memory leak there). And no, I don't expect it'll ever be much faster than Cpython wink. I was primarily interested in being able to distribute low-footprint standalone executables written in python and code obfustication. The basic approach taken by compyler is to transliterate python bytecode into x86 assembly, instead of trying to generate assembly from the syntax tree. This is basically abandonware. I haven't touched this in six months, but did do a lot of up front work. I basically wanted to release it before my hardrive blows up in case anyone was looking for prior art. The code also contains a version of pyasm that has some more patches and features than the official distribution if you're one of pyasm's 3 users. More info can be found at: http://members.verizon.net/~olsongt/compyler/index.html -Grant -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Re: Threaded Design Question
[EMAIL PROTECTED] wrote: I ended up taking this route for the most part. The worker thread first moves the file to be processed into a temp directory, No, the watcher thread should do this itself *before* putting it into the work queue. Then there's no chance of it picking up the same file twice before a worker has gotten around to working on it, and there is no need for a custom queue class. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
deselect an iterm in ListBox wxPython
Hi, I am a newbie in wxPython and doing a program with ListBox, I want to select and deselect items in this box, I have use self.devlist = wx.ListBox(self, style=wx.LB_MULTIPLE) self.Bind(wx.EVT_LISTBOX, self.select_dev, self.devlist) to create this box, but don't know how to implement self.select_dev to find out which one is clicked deselect it, if it was selected ( this is not working at default) select it, if it was not (toggle) The default behavior is, the selection is increasing, I can't deselect any of them. Thanks. Lingyun -- http://mail.python.org/mailman/listinfo/python-list
Re: Destruction of generator objects
On Aug 9, 1:14 am, Stefan Bellon [EMAIL PROTECTED] wrote: On Wed, 08 Aug, MRAB wrote: Simple! :-) Sorry, I forgot to mention that I am forced to using Python 2.4. -- Stefan Bellon It doesn't matter. You can use try...finally as well in Python 2.4. It's just not possible to use except and finally clauses in one statement such as: try: 1/0 except ZeroDivisionError: print incident! finally: print cleanup However in theory you don't really need finally but you can simulate it using nested try...except statements: - try: try: 1/0 try: print cleanup except Exception: raise FinallyException( sys.exc_info() ) except ZeroDivisionError: print incident! try: print cleanup except Exception: raise FinallyException( sys.exc_info() ) except Exception: exc_cls, exc_value, exc_tb = sys.exc_info() if exc_cls == FinallyException: fin_exc_cls, fin_exc_value, fin_exc_tb = exc_value[0] raise fin_exc_cls, fin_exc_value, fin_exc_tb else: print cleanup except Exception: raise FinallyException( sys.exc_info() ) raise exc_cls, exc_value, exc_tb --- Note that this expression is regenerated from the above try...except..finally statement using Py25Lite ( see [1],[2] ) which is a tool used to provide some Python 2.5 constructs for programmers working with Python 2.4. [1] http://www.fiber-space.de/EasyExtend/doc/EE.html [2] http://www.fiber-space.de/EasyExtend/doc/Py25Lite/Py25Lite.html -- http://mail.python.org/mailman/listinfo/python-list
Re: The Future of Python Threading
Justin T. wrote: True, but Python seems to be the *best* place to tackle this problem, at least to me. It has a large pool of developers, a large standard library, it's evolving, and it's a language I like :). Languages that seamlessly support multi-threaded programming are coming, as are extensions that make it easier on every existent platform. Python has the opportunity to lead that change. I have to disagree. A dynamic scripting language, even a great one such as Python, is not the vehicle to lead an advance of pervasive threading. The features that draw people to Python do not play nicely with optimizing multi-core efficiency; they didn't play all that well with single-core efficiency either. Python is about making good use of our time, not our machines' time. Finer-grain locking sounds good, but realize how many items need concurrency control. Python offers excellent facilities for abstracting away complexity, so we programmers do not mentally track all the possible object interactions at once. In a real application, objects are more intertwingled than we realize. Whatever mistakes a Python programmer makes, the interpreter must protect its own data structures against all possible race errors. Run-time flexibility is a key Python feature, and it necessarily implies that most bindings are subject to change. Looking at a Python function, we tend to focus on the named data objects, and forget how many names Python is looking up at run time. How often do we take and release locks on all the name-spaces that might effect execution? The GIL both sucks and rocks. Obviously cores are becoming plentiful and the GIL limits how we can exploit them. On the other hand, correctness must dominate efficiency. We lack exact reasoning on what we must lock; with the GIL, we err on the side of caution and correctness. Instead of trying to figure out what we need to lock, we default to locking everything, and try to figure out what we can safely release. [Steve Holden:] Be my guest, if it's so simple. I knew somebody was going to say that! I'm pretty busy, but I'll see if I can find some time to look into it. If you want to lead fixing Python's threading, consider first delivering a not-so-grand but definite improvement. Have you seen how the 'threading' module in Python's standard library implements timeouts? -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
question: howto transfer objects between server and client?
Hello community, maybe one of you can help me out with a question regarding the transfer of objects betwen client an server: I have three files: ### ClassA.py ### class ClassA: def setA(self, newA): self.a = newA def getA(self): return self.a ### client.py ### import xmlrpclib from ClassA import * a = ClassA() a.setA(4711) server = xmlrpclib.ServerProxy(http://localhost:;) print server.getA(a)# = here I would like to hand over an object ### server.py ### import SimpleXMLRPCServer from ClassA import * class Handler: def getA(self, aClass): return aClass.getA() # - XMLRPC only transports simple types and dictionaries, but no objects handler_object = Handler() server = SimpleXMLRPCServer.SimpleXMLRPCServer((localhost, )) server.register_instance(handler_object) print Listening on port server.serve_forever() The problem is, that though I hand a ClassA object to the XMLRPC server, the server only receives a dictionary (only transfering simple objects is a XMLRPC feature: http://docs.python.org/lib/module-xmlrpclib.html) Since XMLRPC has limited features: Is there any other server/client technique to transfer objects (not strings, or dictionaries, but self defined object types) ? Regards Bernd -- http://mail.python.org/mailman/listinfo/python-list
Re: question: howto transfer objects between server and client?
OpenPavilion wrote: Since XMLRPC has limited features: Is there any other server/client technique to transfer objects (not strings, or dictionaries, but self defined object types) ? Take a look at Pyro; http://pyro.sourceforge.net --Irmen -- http://mail.python.org/mailman/listinfo/python-list
python 2.5 bug
Hello, I was install Python 2.5 and uninstall Python 2.4 now I cannot run my scripts, only from idle What should I do? Regards, Vedran -- http://mail.python.org/mailman/listinfo/python-list
Re: question: howto transfer objects between server and client?
On 11 Aug., 11:21, Irmen de Jong [EMAIL PROTECTED] wrote: OpenPavilion wrote: Since XMLRPC has limited features: Is there any other server/client technique to transfer objects (not strings, or dictionaries, but self defined object types) ? Take a look at Pyro; http://pyro.sourceforge.net --Irmen Thanks Irmen, just found out, that if I use pickle.dumps(object) (on client side) and pickle.loads(object) (on server side) before and after sending, I have access to the object. I love this python language ! Python is a really, really nice language and I often find that the solution is easier as I thought in the first place ... Thanks anyway !! Regards Bernd -- http://mail.python.org/mailman/listinfo/python-list
Re: python 2.5 bug
On 11 kol, 11:59, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: On Sat, 11 Aug 2007 02:41:26 -0700, vedrandekovic wrote: I was install Python 2.5 and uninstall Python 2.4 now I cannot run my scripts, only from idle What should I do? Install 2.4 again. Both can be installed in parallel. Ciao, Marc 'BlackJack' Rintsch I need python 2.5 for work becose python 2.4 module tokenizer has no attribute untokenize Regards, Vedran -- http://mail.python.org/mailman/listinfo/python-list
Re: Destruction of generator objects
On Sat, 11 Aug, Kay Schluehr wrote: On Aug 9, 1:14 am, Stefan Bellon [EMAIL PROTECTED] wrote: Sorry, I forgot to mention that I am forced to using Python 2.4. It doesn't matter. You can use try...finally as well in Python 2.4. It's just not possible to use except and finally clauses in one statement such as: [snip] The problem is yield inside try-finally which is not possible in 2.4. -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list
Re: python 2.5 bug
On Sat, 11 Aug 2007 02:41:26 -0700, vedrandekovic wrote: I was install Python 2.5 and uninstall Python 2.4 now I cannot run my scripts, only from idle What should I do? Install 2.4 again. Both can be installed in parallel. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: The Modernization of Emacs: keyboard shortcuts pain
The following is a FAQ from emacs modernization http://xahlee.org/emacs/modernization.html Q: Emacs's undo is superior, because the prevalent Undo/Redo system actually loss info. A: Emac's undo is very confusing and does not have a Redo command. To redo after a undo, people are told to type something then do a undo. Long time emacs user argue that it is technically superior because it lets user to revert to any possible state of the past. A practical problem with the way of emacs undo is that it repeats the states in the action record. In the prevalent undo model, the action record is linear, and each entry is unique. A user can easily arrive at a desired previous state using undo and redo. In emacs's model, it traverses the queue back and forth (or add existing states to the stack). It is hard for a user to know when to do undo or do some random typing followed by undo to get to the state he wants. In particular, once a person did more than once of some random typing followed by undo, the undo record becomes too convoluted for a person to keep in mind and often the undo action becomes useless at that point. If you take a survey among programers who use emacs for at least 1 year, perhaps more than 90% are confused by emacs's undo model and do not find it useful. If you take a survey of software users other than emacs, i do not think anyone will report their software's undo lacks something to be desired. It is reasonable to argue, that people work better with a simple undo/ redo model. Undo is practically used to erase a mistake or doing a simple one-time revision. Once a user did a sequence of undos and redos, we can assume that he arrived at a satisfactory point and intends to start fresh from that point. If he needs extra revision control, a more proper mechanism, one that people actually use, is to revert to the saved version. Xah [EMAIL PROTECTED] http://xahlee.org/ -- http://mail.python.org/mailman/listinfo/python-list
Re: The Future of Python Threading
In article [EMAIL PROTECTED], Seun Osewa [EMAIL PROTECTED] wrote: I think I've heard Guido say the last attempt at removing the Global Interpreter Lock (GIL) resulted in a Python that was much slower... What is it about Python that makes a thread-safe CPython version much slower? Why doesn'ttrue threading slow down other languages like Perl and Java? I'm thinking it might be the reference counting approach to memory management... but what do you guys think is the reason? Crudely, Perl threading is fragile, and Java requires coding at a lower level. Memory management is indeed important, and arguably deserves at least as much attention as multi-core accomodations. I know of no easy gains from here on, just engineering trade-offs. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Future of Python Threading
In article [EMAIL PROTECTED], Chris Mellon [EMAIL PROTECTED] wrote: . . . There's nothing undocumented about IPC. It's been around as a technique for decades. Message passing is as old as the hills. . . . ... and has significant successes to boast, including the highly-reliable and high-performing QNX real-time operating system, and the already-mentioned language Erlang. -- http://mail.python.org/mailman/listinfo/python-list
Re: Destruction of generator objects
On Aug 11, 12:16 pm, Stefan Bellon [EMAIL PROTECTED] wrote: On Sat, 11 Aug, Kay Schluehr wrote: On Aug 9, 1:14 am, Stefan Bellon [EMAIL PROTECTED] wrote: Sorry, I forgot to mention that I am forced to using Python 2.4. It doesn't matter. You can use try...finally as well in Python 2.4. It's just not possible to use except and finally clauses in one statement such as: [snip] The problem is yield inside try-finally which is not possible in 2.4. -- Stefan Bellon Oh, yeah... i overlooked this. Honestly, I'd recommend wrapping the generator into a function object, create the resource on construction ( or pass it ) and destroy it implementing __del__. def gen_value(self): while True: yield self.iter.next() class GeneratorObj(object): def __init__(self, obj, gen): self.iter = make_iter(obj) self.gen = gen(self) def __del__(self): destroy(self.iter) def next(self): return self.gen.next() -- http://mail.python.org/mailman/listinfo/python-list
Re: cookielib
Boris Ozegovic [EMAIL PROTECTED] writes:
Hi
I have HTTP client which accepts cookies. If client allready has cookie,
but that cookie has expired, server sends him new cookie, and in response
object Set-Cookie: header everything is fine, but if I reload request,
client sends expired cookie, and not the new one. In cookiejar there is
only new and valid cookie, and if I use regular browser everything is fine.
The code is following:
urlopen = urllib2.urlopen
Request = urllib2.Request
cj = cookielib.LWPCookieJar()
COOKIEFILE = 'cookies.lwp'
if os.path.isfile(COOKIEFILE):
# if we have a cookie file already saved
# then load the cookies into the Cookie Jar
cj.load(COOKIEFILE)
opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cj))
urllib2.install_opener(opener)
url = http://localhost:8000/files/index.html;
params = {'question':question}
data = urllib.urlencode(params)
Request(url, data)
try:
response = urlopen(Request)
etc.
Only if I create new request object the new cookie is send, but I don't
want to create new object. And idea?
You seem to suggest in your first paragraph that you call urlopen more
than once, but in the code you show, you call it only once.
This is the way HTTP cookies work: you can't send back a cookie before
you've received it. So, you need two HTTP requests: one to get the
cookie, and a second to send it back again.
However, some websites arrange things so that a single attempt to load
a URL results in multiple HTTP requests. One common way to do that is
by using an HTTP Refresh -- look at the top of the HTML to see if
there's a META tag something like this:
meta http-equiv=refresh content=1 /
This means that the browser should reload the page after a pause of
one second. Often, the reloaded page then does not contain another
meta refresh tag, so that the page does not reload every second
forever (the server knows not to include the tag because it received
the cookie).
This tag can be supported by appropriate Python code. So, two HTTP
requests needn't necessarily mean two urlopen calls. This library
handles refresh redirections, and supports essentially the same
interface as urllib2 and cookielib (the union of the two interfaces):
http://wwwsearch.sourceforge.net/mechanize/
John
--
http://mail.python.org/mailman/listinfo/python-list
Re: Something in the function tutorial confused me.
On 2007-08-11, Alex Martelli [EMAIL PROTECTED] wrote: Neil Cerutti [EMAIL PROTECTED] wrote: ... The Python Language Reference seems a little confused about the terminology. 3.4.7 Emulating numeric types 6.3.1 Augmented assignment statements The former refers to augmented arithmetic operations, which I think is a nice terminology, since assignment is not necessarily taking place. Then the latter muddies the waters. Assignment *IS* necessarily taking place; if you try the augmented assignment on something that DOESN'T support assignment, you'll get an exception. Consider: tup=([],) tup[0] += ['zap'] Traceback (most recent call last): File stdin, line 1, in module TypeError: 'tuple' object does not support item assignment Tuples don't support item ASSIGNMENT, and += is an ASSIGNMENT, so tuples don't allow a += on any of their items. If you thought that += wasn't an assignment, this behavior and error message would be very problematic; since the language reference ISN'T confused and has things quite right, this behavior and error message are perfectly consistent and clear. Thanks for the correction. I was under the illusion that sometimes augmented assignment would instead mutate the object. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: wxPython - drawing without paint event
[EMAIL PROTECTED] wrote: On a related topic, it seems like it would be nice to do *all* drawing in response to paint events. When I get an event from the timer, I would just tell wx that part of the window needs redrawing, and depend on it to give me a paint even when nothing of higher priority needs to be done. I've seen this kind of logic recommended in other GUI tookits. Is it a good idea in wxPython, and, if so, how does one do it? At least it is not required -- there are device contexts for use inside and outside of paint events. One nice strategy from an example in wxPython in Action is the following: * the frame has Draw methods that draw into a BufferedDC, which is chained to a bitmap member * inside the paint method, the bitmap member is drawn to screen Regards, Björn -- BOFH excuse #393: Interference from the Van Allen Belt. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Future of Python Threading
Justin T. wrote: On Aug 10, 2:02 pm, [EMAIL PROTECTED] (Luc Heinrich) wrote: Justin T. [EMAIL PROTECTED] wrote: What these seemingly unrelated thoughts come down to is a perfect opportunity to become THE next generation language. Too late: http://www.erlang.org/ :) -- Luc Heinrich Uh oh, my ulterior motives have been discovered! I'm aware of Erlang, but I don't think it's there yet. For one thing, it's not pretty enough. It also doesn't have the community support that a mainstream language needs. I'm not saying it'll never be adequate, but I think that making python into an Erlang competitor while maintaining backwards compatibility with the huge amount of already written python software will make python a very formidable choice as languages adapt more and more multi-core support. Python is in a unique position as its actually a flexible enough language to adapt to a multi-threaded environment without resorting to terrible hacks. Justin Multi-core or multi-CPU computers are more and more popular, especially in scientific computation. It will be a great great thing if multi-core support can be added to python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Ipc mechanisms and designs.
On Aug 10, 10:33 pm, Nikita the Spider [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], king kikapu [EMAIL PROTECTED] wrote: Hi King Kikapu There's a shared memory module for Python, but it is *nix only, I'm afraid. I realize you said mainly Windows but this module seems to do what you want so maybe you can work out a creative solution. http://NikitaTheSpider.com/python/shm/ Yes, i am currently developing mainly on windows but a cross-platform solution would surely interests me. I will check it out this! @Alex: Thanks, it looks very-very interesting... -- http://mail.python.org/mailman/listinfo/python-list
Re: The Future of Python Threading
Have you checked out the processing [1] package? I've currently the impression that people want to change the whole language before they checkout a new package. It would be nice to read a review. [1] http://cheeseshop.python.org/pypi/processing -- http://mail.python.org/mailman/listinfo/python-list
Re: Destruction of generator objects
On Sat, 11 Aug, Kay Schluehr wrote: Honestly, I'd recommend wrapping the generator into a function object, create the resource on construction ( or pass it ) and destroy it implementing __del__. def gen_value(self): while True: yield self.iter.next() class GeneratorObj(object): def __init__(self, obj, gen): self.iter = make_iter(obj) self.gen = gen(self) def __del__(self): destroy(self.iter) def next(self): return self.gen.next() Ok, I think there is an __iter__ missing in order to implement the iterator protocol, and I don't see why the generator cannot be inside the class itself. Anyway, I came up with this code now: class ListGenerator(object): def __init__(self, iter): print gen init self.iter = iter self.gen = self._value() def __del__(self): print gen del destroy(self.iter) def _value(self): print gen value while more(self.iter): yield next(self.iter) def __iter__(self): print gen iter return self def next(self): print gen next return self.gen.next() When iterating over such a generator, I see the following output: list(obj) gen init gen iter gen next gen value gen next gen next gen next gen next ['Item1', 'Item2', 'Item3', 'Item4'] But I do not see an output of gen del which makes me think that the destructor is not called, thus not releasing the resource. It seems I have not completely understood how generators work ... -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list
LRU cache?
Anyone got a favorite LRU cache implementation? I see a few in google but none look all that good. I just want a dictionary indexed by strings, that remembers the last few thousand entries I put in it. It actually looks like this is almost a FAQ. A well-written implementation would probably make a good standard library module. -- http://mail.python.org/mailman/listinfo/python-list
Re: Destruction of generator objects
On Aug 11, 2:00 pm, Stefan Bellon [EMAIL PROTECTED] wrote: On Sat, 11 Aug, Kay Schluehr wrote: Honestly, I'd recommend wrapping the generator into a function object, create the resource on construction ( or pass it ) and destroy it implementing __del__. def gen_value(self): while True: yield self.iter.next() class GeneratorObj(object): def __init__(self, obj, gen): self.iter = make_iter(obj) self.gen = gen(self) def __del__(self): destroy(self.iter) def next(self): return self.gen.next() Ok, I think there is an __iter__ missing in order to implement the iterator protocol, and I don't see why the generator cannot be inside the class itself. Sure. [...] But I do not see an output of gen del which makes me think that the destructor is not called, thus not releasing the resource. It seems I have not completely understood how generators work ... But why shall the destructor be called? Your example does not indicate that a ListGenerator object is somewhere destroyed neither explicitely using del nor implicitely by destroying the scope it is living in. -- http://mail.python.org/mailman/listinfo/python-list
Re: Deleting objects on the fly
On Aug 10, 1:49 pm, Terry Reedy [EMAIL PROTECTED] wrote: Campbell Barton [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]| Michele Simionato wrote: | Probably not, 'del x' just decrements the reference count, Or ashttp://docs.python.org/ref/del.html puts it, Deletion of a name removes the binding of that name from the local or global namespace, | del x will remove x from memory if nothing else is refering to it, This is implementation dependent: true for CPython, not for Jython, ??? for IronPython. Wait a second; do you mean to say that in Jython, del x will never remove x from memory? How do you free up RAM? -- http://mail.python.org/mailman/listinfo/python-list
Re: Deleting objects on the fly
Dustan [EMAIL PROTECTED] writes: | del x will remove x from memory if nothing else is refering to it, This is implementation dependent: true for CPython, not for Jython, ??? for IronPython. Wait a second; do you mean to say that in Jython, del x will never remove x from memory? How do you free up RAM? It stays around until the GC picks it up. -- http://mail.python.org/mailman/listinfo/python-list
Re: python 2.5 bug
* (Sat, 11 Aug 2007 02:41:26 -0700) I was install Python 2.5 and uninstall Python 2.4 now I cannot run my scripts, only from idle What should I do? 1. read How To Ask Questions The Smart Way[1] 2. read How to Report Bugs Effectively[2] 3. don't call something a bug if the bug is likely the person sitting in front of your computer 4. don't do something you don't fully understand (in this case installing Python 2.5 and uninstalling Python 2.4) Thorsten [1] http://catb.org/~esr/faqs/smart-questions.html [2] http://www.chiark.greenend.org.uk/~sgtatham/bugs.html -- http://mail.python.org/mailman/listinfo/python-list
Metaclass v.s. Property function.
I don't like the property function, usable in the new-style classes, because having to remember to manage a list of foo = property(...) assignments just plain sucks, so I wrote a metaclass that does things a little differently. Please have a look and tell me whether this is useful or impractical. The metaclass is here: http://pastebin.com/m5b06b571 and some simple testcode is here: http://pastebin.com/m382f2ae9. Notice the first line though. Thanks for any replies, Jens Thiede. -- http://mail.python.org/mailman/listinfo/python-list
Re: Destruction of generator objects
On Sat, 11 Aug, Kay Schluehr wrote: But why shall the destructor be called? Your example does not indicate that a ListGenerator object is somewhere destroyed neither explicitely using del nor implicitely by destroying the scope it is living in. After having constructed the list itself, the generator is exhausted and not iterated or referenced anymore, so the generator should be destroyed, shouldn't it? Ok, let's make the example easier and take out the external iterator resource and just concentrate on the Python part: class ListGenerator(object): def __init__(self): print gen init self.gen = self._value() def __del__(self): print gen del def _value(self): print gen value for i in xrange(4): yield i def __iter__(self): print gen iter return self def next(self): print gen next return self.gen.next() Now, doing the following: a = ListGenerator() gen init a __main__.ListGenerator object at 0x4020c3ec for i in a: print i ... gen iter gen next gen value 0 gen next 1 gen next 2 gen next 3 gen next del a So why is the destructor not called when the generator is even explicitly 'del'ed? Does somebody else still hold a reference on it? But then, even when terminating the interpreter, __del__ is not called. When taking out the yield statement, __del__ is called again. It looks to me that as soon as a generator function is involved in the class, the __del__ is not called anymore. -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list
Re: Destruction of generator objects
On Sat, 11 Aug 2007 14:50:33 +0200, Stefan Bellon wrote: On Sat, 11 Aug, Kay Schluehr wrote: But why shall the destructor be called? Your example does not indicate that a ListGenerator object is somewhere destroyed neither explicitely using del nor implicitely by destroying the scope it is living in. After having constructed the list itself, the generator is exhausted and not iterated or referenced anymore, so the generator should be destroyed, shouldn't it? Ok, let's make the example easier and take out the external iterator resource and just concentrate on the Python part: class ListGenerator(object): def __init__(self): print gen init self.gen = self._value() def __del__(self): print gen del def _value(self): print gen value for i in xrange(4): yield i def __iter__(self): print gen iter return self def next(self): print gen next return self.gen.next() Now, doing the following: a = ListGenerator() gen init a __main__.ListGenerator object at 0x4020c3ec for i in a: print i ... gen iter gen next gen value 0 gen next 1 gen next 2 gen next 3 gen next del a So why is the destructor not called when the generator is even explicitly 'del'ed? The generator is not ``del``\ed, just the name `a` is removed. Does somebody else still hold a reference on it? Yes, the interactive Python shell holds the last non-`None` result in `_`: from forum import ListGenerator a = ListGenerator() gen init a forum.ListGenerator object at 0xb7d12c4c for i in a: print i ... gen iter gen next gen value 0 gen next 1 gen next 2 gen next 3 gen next del a _ forum.ListGenerator object at 0xb7d12c4c 42 gen del 42 But then, even when terminating the interpreter, __del__ is not called. Because that is not guaranteed by the language reference. The reason why it is a bad idea to depend on `__del__` for important resource management. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Finding gurus (was Re: Something in the function tutorial confused me.)
In article [EMAIL PROTECTED], Alex Martelli [EMAIL PROTECTED] wrote: Because of this, a Google search for name surname python may sometimes help; when you get 116,000 hits, as for Steve Holden python, that may be a reasonable indication that the poster is one of the world's Python Gurus (in fact, the winner of the 2007 Frank WIllison Award -- congratulations, Steve!!!). Sometimes that precise search pattern isn't appropriate, of course. ;-) -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ And if that makes me an elitist...I couldn't be happier. --JMS -- http://mail.python.org/mailman/listinfo/python-list
Re: LRU cache?
Paul Rubin schrieb: Anyone got a favorite LRU cache implementation? I see a few in google but none look all that good. I just want a dictionary indexed by strings, that remembers the last few thousand entries I put in it. I don't know a module for that (although it might exist), but I could imagine how to implement it. Generally a LRU cache could be implemented as a (linked) list with a max. size of N. On usage of an object this object will be moved to the top of the list (and removed from the old position). If it's not yet stored in the cache, you (fetch it from the source and) add it on top and remove the last one, if the list exceeds N entries. So you need to do two things: 1) Maintain a list: Use a (linked) list. 2) Random access to that list: Use a dict (hash), that also has to be updated on removal/addition of objects. -- Thomas Wittek Web: http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED] GPG: 0xF534E231 -- http://mail.python.org/mailman/listinfo/python-list
Augmented assignment (was Re: Something in the function tutorial confused me.)
In article [EMAIL PROTECTED], Neil Cerutti [EMAIL PROTECTED] wrote: On 2007-08-11, Alex Martelli [EMAIL PROTECTED] wrote: Neil Cerutti [EMAIL PROTECTED] wrote: ... The Python Language Reference seems a little confused about the terminology. 3.4.7 Emulating numeric types 6.3.1 Augmented assignment statements The former refers to augmented arithmetic operations, which I think is a nice terminology, since assignment is not necessarily taking place. Then the latter muddies the waters. Assignment *IS* necessarily taking place; if you try the augmented assignment on something that DOESN'T support assignment, you'll get an exception. Consider: tup=([],) tup[0] += ['zap'] Traceback (most recent call last): File stdin, line 1, in module TypeError: 'tuple' object does not support item assignment Tuples don't support item ASSIGNMENT, and += is an ASSIGNMENT, so tuples don't allow a += on any of their items. If you thought that += wasn't an assignment, this behavior and error message would be very problematic; since the language reference ISN'T confused and has things quite right, this behavior and error message are perfectly consistent and clear. Thanks for the correction. I was under the illusion that sometimes augmented assignment would instead mutate the object. Although Alex is essentially correct, the situation is a bit more complex and you are correct that augmented assignment allows the object to decide whether to mutate in place. However, the critical part of Alex's point is what you need to focus on: it's the *tuple* in Alex's example that intercepts the assignment call, not the list contained in the tuple. Obviously, you can easily work around it: t = ([],) l = t[0] l += ['foo'] t (['foo'],) And this proves that you are correct about the list getting mutated in place and reflected back in the tuple. Generally speaking, augmented assignment with nested container objects is a Bad Idea IMO -- split out the bits you want to work with. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ And if that makes me an elitist...I couldn't be happier. --JMS -- http://mail.python.org/mailman/listinfo/python-list
Re: deselect an iterm in ListBox wxPython
On Aug 11, 2:53 am, Bailu [EMAIL PROTECTED] wrote:
Hi,
I am a newbie in wxPython and doing a program with ListBox,
I want to select and deselect items in this box,
I have use
self.devlist = wx.ListBox(self, style=wx.LB_MULTIPLE)
self.Bind(wx.EVT_LISTBOX, self.select_dev, self.devlist)
to create this box, but don't know how to implement self.select_dev
to find out which one is clicked
deselect it, if it was selected ( this is not working at default)
select it, if it was not (toggle)
The default behavior is, the selection is increasing, I can't deselect
any of them.
Thanks.
Lingyun
You should look at the wxPython demo's code for the wx.ListBox. It
looks like they use the wx.EVT_LISTBOX event. See below:
code
# this writes to a multiline TextCtrl
self.log.WriteText('EvtListBox: %s, %s, %s, %s\n' %
(event.GetString(),
event.IsSelection(),
event.GetSelection(),
event.GetClientData()))
/code
I'm not sure, but I think it uses the SetSelection() method to select
an item, which seems to deselect the previously selected item...at
least, that's how I interpret the demo.
The demo is here: http://wxpython.org/download.php
If you need additional help, try posting to the wxPython User's group:
http://wxpython.org/maillist.php
Regards,
Mike
--
http://mail.python.org/mailman/listinfo/python-list
Re: Finding gurus (was Re: Something in the function tutorial confused me.)
Aahz wrote: In article [EMAIL PROTECTED], Alex Martelli [EMAIL PROTECTED] wrote: Because of this, a Google search for name surname python may sometimes help; when you get 116,000 hits, as for Steve Holden python, that may be a reasonable indication that the poster is one of the world's Python Gurus (in fact, the winner of the 2007 Frank WIllison Award -- congratulations, Steve!!!). Sometimes that precise search pattern isn't appropriate, of course. ;-) Of course, Alex didn't mention that there are actually 117,000 hits, and the last thousand have nothing to do with programming ;-) Alex, thanks for your congratulations, as no public announcement has yet been made (apart from at OSCON) I haven't mentioned the Frank Willison Award until now. The certificate arrived this week, and I am humbled by the honor. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - -- http://mail.python.org/mailman/listinfo/python-list
Re: Destruction of generator objects
On Sat, 11 Aug, Marc 'BlackJack' Rintsch wrote: On Sat, 11 Aug 2007 14:50:33 +0200, Stefan Bellon wrote: But then, even when terminating the interpreter, __del__ is not called. Because that is not guaranteed by the language reference. The reason why it is a bad idea to depend on `__del__` for important resource management. Ok, but then we are back to my initial question of whether the destroy of def get_data(obj): iter = make_iter(obj) while more(iter): yield next(iter) destroy(iter) can be guaranteed somehow in Python 2.4 while it can be done in Python 2.5 like follows: def get_data(obj): iter = make_iter(obj) try: while more(iter): yield next(iter) finally: destroy(iter) And then the answer is: no, it cannot be done in 2.4 (like Alex Martelli already said ;-) -- Stefan Bellon -- http://mail.python.org/mailman/listinfo/python-list
Re: Deleting objects on the fly
Dustan wrote: On Aug 10, 1:49 pm, Terry Reedy [EMAIL PROTECTED] wrote: Campbell Barton [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]| Michele Simionato wrote: | Probably not, 'del x' just decrements the reference count, Or ashttp://docs.python.org/ref/del.html puts it, Deletion of a name removes the binding of that name from the local or global namespace, | del x will remove x from memory if nothing else is refering to it, This is implementation dependent: true for CPython, not for Jython, ??? for IronPython. Wait a second; do you mean to say that in Jython, del x will never remove x from memory? How do you free up RAM? Because the exact method of garbage collection is independent of the language definition, Jython uses the Java garbage collector, which works (approximately) as follows. In that language memory is allocated until a request cannot be satisfies, then a scan is performed for unreferenced objects whose space is reclaimed. Only if this doesn't yield enough space to allocate the new object is more memory requested from the OS by the process. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - -- http://mail.python.org/mailman/listinfo/python-list
A new french book on Python
Hello, A new french book is coming out on the 16th of august. It's focused on Python good practices, agility, and all the things that makes a Python developer loves the language. If you are interested, the web page is here : http://programmation-python.org/guide Regards Tarek -- http://mail.python.org/mailman/listinfo/python-list
Re: LRU cache?
Thomas Wittek wrote: Paul Rubin schrieb: Anyone got a favorite LRU cache implementation? I see a few in google but none look all that good. I just want a dictionary indexed by strings, that remembers the last few thousand entries I put in it. I don't know a module for that (although it might exist), but I could imagine how to implement it. Generally a LRU cache could be implemented as a (linked) list with a max. size of N. On usage of an object this object will be moved to the top of the list (and removed from the old position). If it's not yet stored in the cache, you (fetch it from the source and) add it on top and remove the last one, if the list exceeds N entries. So you need to do two things: 1) Maintain a list: Use a (linked) list. 2) Random access to that list: Use a dict (hash), that also has to be updated on removal/addition of objects. Paul's an old enough hand that he's well able to determine this for himself. He's also polite enough not to reply along those lines :-) *I* don't know of module for tracking how plants grow, but I could imagine how to implement it ... regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - -- http://mail.python.org/mailman/listinfo/python-list
Re: Augmented assignment (was Re: Something in the function tutorial confused me.)
Aahz schreef: In article [EMAIL PROTECTED], Neil Cerutti [EMAIL PROTECTED] wrote: On 2007-08-11, Alex Martelli [EMAIL PROTECTED] wrote: Neil Cerutti [EMAIL PROTECTED] wrote: ... The Python Language Reference seems a little confused about the terminology. 3.4.7 Emulating numeric types 6.3.1 Augmented assignment statements The former refers to augmented arithmetic operations, which I think is a nice terminology, since assignment is not necessarily taking place. Then the latter muddies the waters. Assignment *IS* necessarily taking place; if you try the augmented assignment on something that DOESN'T support assignment, you'll get an exception. Consider: tup=([],) tup[0] += ['zap'] Traceback (most recent call last): File stdin, line 1, in module TypeError: 'tuple' object does not support item assignment Tuples don't support item ASSIGNMENT, and += is an ASSIGNMENT, so tuples don't allow a += on any of their items. If you thought that += wasn't an assignment, this behavior and error message would be very problematic; since the language reference ISN'T confused and has things quite right, this behavior and error message are perfectly consistent and clear. Thanks for the correction. I was under the illusion that sometimes augmented assignment would instead mutate the object. Although Alex is essentially correct, the situation is a bit more complex and you are correct that augmented assignment allows the object to decide whether to mutate in place. However, the critical part of Alex's point is what you need to focus on: it's the *tuple* in Alex's example that intercepts the assignment call, not the list contained in the tuple. Obviously, you can easily work around it: t = ([],) l = t[0] l += ['foo'] t (['foo'],) I'm missing something here, I think. As far as I can tell, the language reference says that the target is evaluated before the augmented assignment is performed. If that's the case, I don't see how the tuple in Alex' example has anything to with it: the assignment is to the list, not the tuple. And watch this (Python 2.4.2): tup = ([],) tup[0] += ['zap'] Traceback (most recent call last): File pyshell#10, line 1, in -toplevel- tup[0] += ['zap'] TypeError: object does not support item assignment So far that's the same as Alex' example, but look at the value of the tuple now: tup (['zap'],) Despite the TypeError, the list *has* changed. -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
RE: Do you want to know about ISLAM
[EMAIL PROTECTED] wrote: Do you want to know about ISLAM, the fastest growing peril to the World ? If yes, this is the ONLY site you need visit: http://islamisbad.com Or, you could just read your newspapers with your BRAINS instead of your sheep's horns. S D Rodrian http://poems.sdrodrian.com http://physics.sdrodrian.com http://mp3s.sdrodrian.com All religions are local. Only science is universal. . -- http://mail.python.org/mailman/listinfo/python-list
Re: The Future of Python Threading
Bjoern Schliessmann [EMAIL PROTECTED] wrote: Nick Craig-Wood wrote: [GIL] That is certainly true. However the point being is that running on 2 CPUs at once at 95% efficiency is much better than running on only 1 at 99%... How do you define this percent efficiency? Those are hypothetical numbers. I guess that a finely locked python will spend a lot more time locking and unlocking individual objects than it currently does locking and unlocking the GIL. This is for two reasons 1) the GIL will be in cache at all times and therefore hot and quick to access 2) much more locking and unlocking of each object will need to be done. The truth is that the future (and present reality) of almost every form of computing is multi-core, Is it? 8) Intel, AMD and Sun would have you believe that yes! Strange, in my programs, I don't need any real concurrency (they are network servers and scripts). Or do you mean the future of computing hardware is multi-core? That indeed may be true. I meant the latter. I agree with you though that not all programs need to be multi-threaded. Hence my proposal for two python binaries. The question is: If it really was, how much of useful performance gain would you get? The linux kernel has been through these growing pains already... SMP support was initially done with the Big Kernel Lock (BKL) which is exactly equivalent to the GIL. So, how much performance gain would you get? Again, managing fine-grained locking can be much more work than one simple lock. Assuming that you are not IO bound, but compute bound and that compute is being done in python then you'll get a speed up proportional to how many processors you have, minus a small amount for locking overhead. The linux kernel has moved onwards to finer and finer grained locking. How do you compare a byte code interpreter to a monolithic OS kernel? In this (locking) respect they are quite similar actually. You can think of kernel code as being the python interpreter (BKL vs GIL), user space being as C extensions running with the GIL unlocked and calling back into the python interpreter / kernel. I'd like to see a python build as it is at the moment and a python-mt build which has the GIL broken down into a lock on each object. python-mt would certainly be slower for non threaded tasks, but it would certainly be quicker for threaded tasks on multiple CPU computers. From where do you take this certainty? For example, if the program in question involves mostly IO access, there will be virtually no gain. Multithreading is not Performance. Yes you are right of course. IO bound tasks don't benefit from multi-threading. In fact usually the reverse. Twisted covers this ground extremely well in my experience. However IO bound tasks probably aren't taxing your quad core chip either... The user could then choose which python to run. This would of course make C extensions more complicated... Also, C extensions can release the GIL for long-running computations. Provided they stay in C. If they call any python stuff then they need to take it again. -- Nick Craig-Wood [EMAIL PROTECTED] -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Augmented assignment (was Re: Something in the function tutorial confused me.)
In article [EMAIL PROTECTED],
Roel Schroeven [EMAIL PROTECTED] wrote:
Aahz schreef:
Although Alex is essentially correct, the situation is a bit more complex
and you are correct that augmented assignment allows the object to decide
whether to mutate in place. However, the critical part of Alex's point
is what you need to focus on: it's the *tuple* in Alex's example that
intercepts the assignment call, not the list contained in the tuple.
Obviously, you can easily work around it:
t = ([],)
l = t[0]
l += ['foo']
t
(['foo'],)
I'm missing something here, I think. As far as I can tell, the language
reference says that the target is evaluated before the augmented
assignment is performed. If that's the case, I don't see how the tuple
in Alex' example has anything to with it: the assignment is to the list,
not the tuple.
And watch this (Python 2.4.2):
tup = ([],)
tup[0] += ['zap']
Traceback (most recent call last):
File pyshell#10, line 1, in -toplevel-
tup[0] += ['zap']
TypeError: object does not support item assignment
So far that's the same as Alex' example, but look at the value of the
tuple now:
tup
(['zap'],)
Despite the TypeError, the list *has* changed.
Yup! Here's why:
def foo(bar): bar[0] += ['zap']
...
import dis
dis.dis(foo)
1 0 LOAD_FAST0 (bar)
3 LOAD_CONST 1 (0)
6 DUP_TOPX 2
9 BINARY_SUBSCR
10 LOAD_CONST 2 ('zap')
13 BUILD_LIST 1
16 INPLACE_ADD
17 ROT_THREE
18 STORE_SUBSCR
19 LOAD_CONST 0 (None)
22 RETURN_VALUE
Notice the critical sequence: BINARY_SUBSCR, INPLACE_ADD, STORE_SUBSCR.
It has to work that way to allow this:
l = [7]
l[0] += 1
l
[8]
There's simply no way to get augmented assignment to work correctly with
both lists and tuples when you allow both mutable and immutable elements.
Someone will always get surprised, and overall with strings and numbers
being the canonical list elements, I think making augmented assignment
work correctly with lists and immutables was the best decision.
But the unfortunate side-effect is that you get the TypeError with
augmented assignment in tuples only after the mutation has been done.
--
Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/
And if that makes me an elitist...I couldn't be happier. --JMS
--
http://mail.python.org/mailman/listinfo/python-list
Public Telnet Server?
Hi there. I'm a beginner at Python and I'm writing my first Python script. It's a text adventure about coffee and mixing drinks and being crazy and such. I keep updating it and want my friends to beta test it for me, but some of them don't have the right version of Python or don't want to get Python at all. Is there an easy way I can set up a public telnet server so they can just telnet the server and play it? If anyone could give me some options and/or advice, I'd really appreciate it! Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: I am giving up perl because of assholes on clpm -- switching to Python
Paul Boddie schreef: let us avoid comp.lang.python becoming some kind of linux-kernel ego trip where anyone who has stuck around has an interest in perpetuating a hostile atmosphere. When did you stop beating your wife? -- Affijn, Ruud Gewoon is een tijger. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am giving up perl because of assholes on clpm -- switching to Python
grocery_stocker schreef: In the beginning there was Mathematics And all was good Then one day God said Let there be the Lambda Calculus And hence the Lambda Calculus was born. However, God felt the the Lambda Calculus needed a mate So god said Let there be Lisp And thus, Lisp was born. As the years went on, god became depressed by how impure the Lisp had become. For from the Lisp, came Emacs Lisp, Java, Perl, Ruby, and Python. http://xkcd.com/224/ -- Affijn, Ruud Gewoon is een tijger. -- http://mail.python.org/mailman/listinfo/python-list
Re: I am giving up perl because of assholes on clpm -- switching to Python
RedGrittyBrick schreef: treasure the saints, tolerate the irritable and ignore the whiners. *You are what you read.* What is irritating to some, is to the point to others. That should say enough, but some people just can not stand short replies, they can not hold themselves back from reading all negative kinds of things into them. Too little attention maybe? (I am just making the same mistake to show how it works.) Only rarely someone mistakes the to the point for the irritating, without acknowledging their mistake in the first or second next reply. Newbies with the wrong focus, under pressure, probably suffering lack of sleep? (I am just making things worse.) -- Affijn, Ruud Gewoon is een tijger. -- http://mail.python.org/mailman/listinfo/python-list
Re: Metaclass v.s. Property function.
Jens Thiede [EMAIL PROTECTED] wrote: I don't like the property function, usable in the new-style classes, because having to remember to manage a list of foo = property(...) assignments just plain sucks, so I wrote a metaclass that does things a little differently. Please have a look and tell me whether this is useful or impractical. The metaclass is here: http://pastebin.com/m5b06b571 and some simple testcode is here: http://pastebin.com/m382f2ae9. Notice the first line though. Here's something I posted a while back which lets you use property as a decorator: class C(object): def __init__(self, colour): self._colour = colour @property.set def colour(self, value): self._colour = value @property.get def colour(self): return self._colour @property.delete def colour(self): self._colour = 'none' See: http://groups.google.co.uk/group/comp.lang.python/browse_thread/thread/b442d08c9a019a8/8a381be5edc26340 Whether you like that style is of course a matter of personal opinion. -- http://mail.python.org/mailman/listinfo/python-list
Who told str() to round my int()'s!!!
After a fair amount of troubleshooting of why my lists were coming back a handful of digits short, and the last digit rounded off, I determined the str() function was to blame: foonum 0.0071299720384678782 str(foonum) '0.00712997203847' Why in the world does str() have any business rounding my numbers, and how do I get around this? -- http://mail.python.org/mailman/listinfo/python-list
How to change a PyObject passed to the C extension
Hi, I have a Python C extension which is passed a PyObject containing an integer value. Is it possible to change this same PyObject so that now the integer is of a different value? Thanks and Regards, -MD -- http://mail.python.org/mailman/listinfo/python-list
Re: How to change a PyObject passed to the C extension
On Sat, 11 Aug 2007 09:43:19 -0700, MD wrote: I have a Python C extension which is passed a PyObject containing an integer value. Is it possible to change this same PyObject so that now the integer is of a different value? No it is not. Even if you poke around in the object ``struct`` this would have severe consequences for cached/shared objects. Just imagine: from your_module import bzzzt def f(): print 2 + 2 bzzzt(2) # This changes the value of 2 to 3. f()# This prints '6'! Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Ligmail bug?
#!/usr/bin/env python
import libgmail
from time import gmtime, strftime
fp = open('/tmp/python.list', 'w')
ga = libgmail.GmailAccount([EMAIL PROTECTED], mypass)
ga.login()
result = self.ga.getMessagesByLabel('python.list', True)
result_len = len(result)
cnt = 0
if result_len:
for thread in result:
cnt += 1
thread_len = len(thread)
print 'Thread: %d/%d Msg: %d %s' % (cnt,
result_len,
thread_len,
thread.subject)
for msg in thread:
print ' Msg: %d/%d %s' % (msg.number,
thread_len,
msg.subject)
source = msg.source.replace('\r','').lstrip()
fp.write('From - ' + \
strftime(%a %b %d %H:%M:%S %Y,
gmtime()) + '\n')
fp.write(source)
fp.write('\n\n')
Thread: 1/1244 Msg: 7 \u003cb\Deleting objects on the fly\u003c/b\
Msg: 1/7 Deleting objects on the fly
Msg: 2/7 Re: Deleting objects on the fly
Msg: 3/7 Re: Deleting objects on the fly
Msg: 4/7 Re: Deleting objects on the fly
Msg: 5/7 Re: Deleting objects on the fly
Msg: 6/7 Re: Deleting objects on the fly
Msg: 7/7 Re: Deleting objects on the fly
Thread: 2/1244 Msg: 1 \u003cb\A new french book on Python\u003c/b\
Msg: 1/1 A new french book on Python
Thread: 3/1244 Msg: 14 \u003cb\Destruction of generator objects\u003c/b\
Msg: 1/14 Destruction of generator objects
Msg: 2/14 Re: Destruction of generator objects
Msg: 3/14 Re: Destruction of generator objects
Msg: 4/14 Re: Destruction of generator objects
Msg: 5/14 Re: Destruction of generator objects
Msg: 6/14 Re: Destruction of generator objects
Msg: 7/14 Re: Destruction of generator objects
Msg: 8/14 Re: Destruction of generator objects
Msg: 9/14 Re: Destruction of generator objects
Msg: 10/14 Re: Destruction of generator objects
Msg: 11/14 Re: Destruction of generator objects
Msg: 12/14 Re: Destruction of generator objects
Msg: 13/14 Re: Destruction of generator objects
Msg: 14/14 Re: Destruction of generator objects
..
Thread: 307/1244 Msg: 1 MailingLogger 3.2.0 Released!
Msg: 1/1 MailingLogger 3.2.0 Released!
Thread: 308/1244 Msg: 13 Why no maintained wrapper to Win32?
Msg: 1/13 Why no maintained wrapper to Win32?
Msg: 2/13 Re: Why no maintained wrapper to Win32?
Msg: 3/13 Re: Why no maintained wrapper to Win32?
Msg: 4/13 Re: Why no maintained wrapper to Win32?
Msg: 5/13 Re: Why no maintained wrapper to Win32?
Msg: 6/13 Re: Why no maintained wrapper to Win32?
Msg: 7/13 Re: Why no maintained wrapper to Win32?
Msg: 8/13 Re: Why no maintained wrapper to Win32?
Msg: 9/13 Re: Why no maintained wrapper to Win32?
Msg: 10/13 Re: Why no maintained wrapper to Win32?
Msg: 11/13 Re: Why no maintained wrapper to Win32?
Msg: 12/13 Re: Why no maintained wrapper to Win32?
Msg: 13/13 Re: Why no maintained wrapper to Win32?
Thread: 309/1244 Msg: 5 Encryption recommendation
Msg: 1/5 Encryption recommendation
Msg: 2/5 Re: Encryption recommendation
Msg: 3/5 Re: Encryption recommendation
Msg: 4/5 Re: Encryption recommendation
Msg: 5/5 Re: Encryption recommendation
Thread: 310/1244 Msg: 3 Simple question about logging module.
Msg: 1/3 Simple question about logging module.
Msg: 2/3 Re: Simple question about logging module.
Msg: 3/3 Re: Simple question about logging module.
Thread: 311/1244 Msg: 5 Plotting Images
Msg: 1/5 Plotting Images
Msg: 2/5 Re: Plotting Images
Msg: 3/5 Re: Plotting Images
Msg: 4/5 Re: Plotting Images
Msg: 5/5 Re: Plotting Images
Thread: 312/1244 Msg: 33 From D
Thread: 313/1244 Msg: 4 get directory and file names
Thread: 314/1244 Msg: 7 Compiling 2.5.1 on OpenBSD 4.1
Thread: 315/1244 Msg: 2 how to add a toolbar to a Frame using wxpython
Thread: 316/1244 Msg: 1 create a toolbar + images using wxpython for windows
Thread: 317/1244 Msg: 4 Pysqlite storing file as blob example
Thread: 318/1244 Msg: 1 Nasm_with_C++_with_Python
Thread: 319/1244 Msg: 2 interaction of 'with' and 'yield'
Thread: 320/1244 Msg: 5 problems with logging module
Thread: 321/1244 Msg: 5 win32 question in Python
Thread: 322/1244 Msg: 6 File handle not being released by close
Thread: 323/1244 Msg: 6 Replacing overloaded functions with closures.
Thread: 324/1244 Msg: 1 Where can I get a complete user interface about
pylibpcap?
Thread: 325/1244 Msg: 7 making a variable available in a function from
decoratorThread: 326/1244 Msg: 1 www.cerocom.com
Thread: 327/1244 Msg: 6 OOP in Python book?
Thread: 328/1244 Msg: 3 Help text embedding in C code?
Thread: 329/1244 Msg: 16 128 or 96 bit integer types?
Thread: 330/1244 Msg: 2 Re: yield keyword usage
Thread: 331/1244 Msg: 11 How to write GUI and event separately in wxPython??
Thread: 332/1244 Msg: 2
Re: Who told str() to round my int()'s!!!
On Sat, 11 Aug 2007 16:40:02 +, Adam W. wrote: After a fair amount of troubleshooting of why my lists were coming back a handful of digits short, and the last digit rounded off, I determined the str() function was to blame: foonum 0.0071299720384678782 str(foonum) '0.00712997203847' Why in the world does str() have any business rounding my numbers, and how do I get around this? If `str()` would not round you would get very long numbers because of the inaccuracies of floating point values. I know Python is lying when 0.1 prints as 0.1, but do you really want to see 0.1555111512312578270211815834045410156250 instead? Use string formatting to tell the number of digits you want to see: In [16]: '%.56f' % 0.1 Out[16]: '0.1555111512312578270211815834045410156250' Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Who told str() to round my int()'s!!!
On Aug 11, 12:53 pm, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: If `str()` would not round you would get very long numbers because of the inaccuracies of floating point values. I know Python is lying when 0.1 prints as 0.1, but do you really want to see 0.1555111512312578270211815834045410156250 instead? I want str() to convert whatever I give it to a string and do nothing else. I will worry about long FP values in previous steps. I still find it very disturbing that str() is doing this AND it is undocumented in all of my books. Use string formatting to tell the number of digits you want to see: In [16]: '%.56f' % 0.1 Out[16]: '0.1555111512312578270211815834045410156250' The book I used to learn Python never introduced string formatting, I suppose I will have to use another and learn it if that is the only way... -- http://mail.python.org/mailman/listinfo/python-list
Re: Augmented assignment (was Re: Something in the function tutorial confused me.)
Aahz schreef:
def foo(bar): bar[0] += ['zap']
...
import dis
dis.dis(foo)
1 0 LOAD_FAST0 (bar)
3 LOAD_CONST 1 (0)
6 DUP_TOPX 2
9 BINARY_SUBSCR
10 LOAD_CONST 2 ('zap')
13 BUILD_LIST 1
16 INPLACE_ADD
17 ROT_THREE
18 STORE_SUBSCR
19 LOAD_CONST 0 (None)
22 RETURN_VALUE
Notice the critical sequence: BINARY_SUBSCR, INPLACE_ADD, STORE_SUBSCR.
It has to work that way to allow this:
l = [7]
l[0] += 1
l
[8]
There's simply no way to get augmented assignment to work correctly with
both lists and tuples when you allow both mutable and immutable elements.
Someone will always get surprised, and overall with strings and numbers
being the canonical list elements, I think making augmented assignment
work correctly with lists and immutables was the best decision.
Thank you, I get it now. With that disassembled code in mind I had
another look at the relevant section in the Language Reference; now I
have a much better understanding of what's really happening.
I used to interpret the target in 'The target is only evaluated once'
more like an L-value in C/C++. That's not correct, of course, but I
didn't understand exactly how wrong it was until now.
--
If I have been able to see further, it was only because I stood
on the shoulders of giants. -- Isaac Newton
Roel Schroeven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Who told str() to round my int()'s!!!
Adam W. schreef: After a fair amount of troubleshooting of why my lists were coming back a handful of digits short, and the last digit rounded off, I determined the str() function was to blame: foonum 0.0071299720384678782 str(foonum) '0.00712997203847' Why in the world does str() have any business rounding my numbers, and how do I get around this? You could use repr() instead of str() (AFAIK that's what the interactive interpreter used to print your foonum), but in any case you should be aware of the limits inherent in floating point arithmetic and in conversions between decimal and binary fractions. See e.g. http://docs.python.org/tut/node16.html -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
Re: Augmented assignment (was Re: Something in the function tutorial confused me.)
Aahz wrote: tup=([],) tup[0] += ['zap'] Traceback (most recent call last): File stdin, line 1, in module TypeError: 'tuple' object does not support item assignment snip Obviously, you can easily work around it: t = ([],) l = t[0] l += ['foo'] t (['foo'],) This is quite shocking to me, although after staring at the documentation for a while I guess I understand it. But it seems to me that the documentation is somewhat misleading on this point, where it says: An augmented assignment evaluates the target (which, unlike normal assignment statements, cannot be an unpacking) and the expression list, performs the binary operation specific to the type of assignment on the two operands, and assigns the result to the original target. This sentence is phrased as though it is the whole story, but it isn't, because the operation might not in fact wind up being an assignment. Shouldn't there be an except see below or something there, to alert the reader that in some cases a true assignment doesn't occur? (I realize that the exception follows quite closely on the heels of this sentence, but it doesn't follow immediately, and is separated by a paragraph break and intervening material about the parallel to unaugmented x = x + 1. On initial reading my tendency is to read the end of the sentence quoted above, see a paragraph break and apparently explanatory material, and go oh, okay, I now have the full specification of this syntax when in fact I don't.) -- --OKB (not okblacke) Brendan Barnwell Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail. --author unknown -- http://mail.python.org/mailman/listinfo/python-list
Re: Augmented assignment (was Re: Something in the function tutorial confused me.)
OKB (not okblacke) schreef: Aahz wrote: tup=([],) tup[0] += ['zap'] Traceback (most recent call last): File stdin, line 1, in module TypeError: 'tuple' object does not support item assignment snip Obviously, you can easily work around it: t = ([],) l = t[0] l += ['foo'] t (['foo'],) This is quite shocking to me, although after staring at the documentation for a while I guess I understand it. But it seems to me that the documentation is somewhat misleading on this point, where it says: An augmented assignment evaluates the target (which, unlike normal assignment statements, cannot be an unpacking) and the expression list, performs the binary operation specific to the type of assignment on the two operands, and assigns the result to the original target. This sentence is phrased as though it is the whole story, but it isn't, because the operation might not in fact wind up being an assignment. The way I understand this now, the assignment really always is an assignment. 1. - For immutable objects, the 'binary operation specific to the type of assignment on the two operands' doesn't modify any object, but only returns a new object which is the result of the operation. - For mutable objects that support the inplace-version of the operator, the operator modifies the object and then returns it. 3. In both cases that result is assigned to the target. In the second case the object was already modified so the assignment doesn't accomplish very much, but it still happens. That explains why tup[0] += ['zap'] both has an effect (tup[0] now contains 'zap') and raises an exception: tup[0] is modified because it is a list and lists support inplace addition, but the assignment fails because tuples don't support item assignment. -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
Re: python 2.5 bug
[EMAIL PROTECTED] wrote: On 11 kol, 11:59, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: On Sat, 11 Aug 2007 02:41:26 -0700, vedrandekovic wrote: I was install Python 2.5 and uninstall Python 2.4 now I cannot run my scripts, only from idle What should I do? Install 2.4 again. Both can be installed in parallel. Ciao, Marc 'BlackJack' Rintsch I need python 2.5 for work becose python 2.4 module tokenizer has no attribute untokenize IMHO Python 2.4 was registered for .py files, Python 2.5 take precedence when installed, but when Python 2.4 has been removed, it remove .py files association too (so break Python 2.5 association). * manually associate .py/.pyc/.pyo files to python.exe, .pyw files to pythonw.exe. * or reinstall Python 2.5 so that it re-setup ad-hoc associations. -- http://mail.python.org/mailman/listinfo/python-list
decorators - more than just syntactic sugar
Hi, are decorators more than just syntactic sugar in python 2.x and what about python 3k ? How can I find out the predefined decorators? Many thanks for your help, Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany -- http://mail.python.org/mailman/listinfo/python-list
Re: decorators - more than just syntactic sugar
On Sat, 11 Aug 2007 20:30:54 +0200, Helmut Jarausch wrote: are decorators more than just syntactic sugar in python 2.x and what about python 3k ? They are just syntactic sugar. @spam def ham(): pass is the same as def ham(): pass ham = spam(ham) How can I find out the predefined decorators? *The* predefined decorators? Decorators are just functions after all. There are some meant to be used as decorators but there are also ordinary functions that may make sense as decorators. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: python 2.5 bug
* Laurent Pointal (Sat, 11 Aug 2007 20:09:03 +0200) [EMAIL PROTECTED] wrote: On 11 kol, 11:59, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: On Sat, 11 Aug 2007 02:41:26 -0700, vedrandekovic wrote: I was install Python 2.5 and uninstall Python 2.4 now I cannot run my scripts, only from idle IMHO Python 2.4 was registered for .py files, Python 2.5 take precedence when installed, but when Python 2.4 has been removed, it remove .py files association too (so break Python 2.5 association). * manually associate .py/.pyc/.pyo files to python.exe, .pyw files to pythonw.exe. * or reinstall Python 2.5 so that it re-setup ad-hoc associations. Yeah. Did the Original Poster mention any details about his problem. Like - for instance - that he's using Windows? Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Who told str() to round my int()'s!!!
On Sat, 11 Aug 2007 17:10:05 +, Adam W. wrote: On Aug 11, 12:53 pm, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: If `str()` would not round you would get very long numbers because of the inaccuracies of floating point values. I know Python is lying when 0.1 prints as 0.1, but do you really want to see 0.1555111512312578270211815834045410156250 instead? I want str() to convert whatever I give it to a string and do nothing else. But those long numbers are very disturbing and nobody wants them as usual string representation. Most programming languages lie at this point to the user so it would be very unexpected too. I will worry about long FP values in previous steps. What do you mean here? Have you looked at the example above? That is the closest you get to 0.1 -- there's no way to round the floating point value, it can only be done by converting to `str()`. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Who told str() to round my int()'s!!!
Roel Schroeven wrote: Adam W. schreef: After a fair amount of troubleshooting of why my lists were coming back a handful of digits short, and the last digit rounded off, I determined the str() function was to blame: foonum 0.0071299720384678782 str(foonum) '0.00712997203847' Why in the world does str() have any business rounding my numbers, and how do I get around this? You could use repr() instead of str() (AFAIK that's what the interactive interpreter used to print your foonum), but in any case you should be aware of the limits inherent in floating point arithmetic and in conversions between decimal and binary fractions. See e.g. http://docs.python.org/tut/node16.html I should also point out that the subject line for this thread is inaccurate, as it wasn't rounding ints at all. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - -- http://mail.python.org/mailman/listinfo/python-list
Re: Who told str() to round my int()'s!!!
On Aug 11, 9:40 am, Adam W. [EMAIL PROTECTED] wrote: After a fair amount of troubleshooting of why my lists were coming back a handful of digits short, and the last digit rounded off, I determined the str() function was to blame: foonum 0.0071299720384678782 str(foonum) '0.00712997203847' Why in the world does str() have any business rounding my numbers, and how do I get around this? If 15 digit precision is a concern, I would suggest that you us the decimal class instead of floating points. Floating point problems on X86 machines are well documented. http://docs.python.org/lib/module-decimal.html http://pydoc.org/2.4.1/decimal.html http://gmpy.sourceforge.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Ligmail bug?
No.23 wrote: [way too much, ending with] File /usr/local/lib/python2.5/urllib2.py, line 1076, in do_open raise URLError(err) urllib2.URLError: urlopen error (-3, 'temporary failure in name resolution') other information: Shell:~ : uname -a OpenBSD ob41.org 4.1 ob41#0 i386 Shell:~ : python Python 2.5 (r25:51908, Mar 8 2007, 20:46:47) [GCC 3.3.5 (propolice)] on openbsd4 Type help, copyright, credits or license for more information. import libgmail print libgmail.Version 0.1.6 So why does a temporary failure in name resolution seem like a library bug? This is just the library reporting back an error from the network or transport layer. Is the error repeatable? How many times over what period of time have you experienced it? regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - -- http://mail.python.org/mailman/listinfo/python-list
ANN: Compyler 0.1
Compyler is a pre-alpha x86 native code compiler. So far it can generate primitive .pyds but not standalone executables. It can run some simple test cases including pystones (although there is a memory leak there). And no, I don't expect it'll ever be much faster than Cpython wink. I was primarily interested in being able to distribute low-footprint standalone executables written in python and code obfustication. The basic approach taken by compyler is to transliterate python bytecode into x86 assembly, instead of trying to generate assembly from the syntax tree. This is basically abandonware. I haven't touched this in six months, but did do a lot of up front work. I basically wanted to release it before my hardrive blows up in case anyone was looking for prior art. The code also contains a version of pyasm that has some more patches and features than the official distribution if you're one of pyasm's 3 users. More info can be found at: http://members.verizon.net/~olsongt/compyler/index.html -Grant -- http://mail.python.org/mailman/listinfo/python-list
Re: python 2.5 bug
On 11 kol, 20:58, Thorsten Kampe [EMAIL PROTECTED] wrote: * Laurent Pointal (Sat, 11 Aug 2007 20:09:03 +0200) [EMAIL PROTECTED] wrote: On 11 kol, 11:59, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: On Sat, 11 Aug 2007 02:41:26 -0700, vedrandekovic wrote: I was install Python 2.5 and uninstall Python 2.4 now I cannot run my scripts, only from idle IMHO Python 2.4 was registered for .py files, Python 2.5 take precedence when installed, but when Python 2.4 has been removed, it remove .py files association too (so break Python 2.5 association). * manually associate .py/.pyc/.pyo files to python.exe, .pyw files to pythonw.exe. * or reinstall Python 2.5 so that it re-setup ad-hoc associations. Yeah. Did the Original Poster mention any details about his problem. Like - for instance - that he's using Windows? Thorsten Hello, Now I was restart my windows and python 2.5 also.Now everything works fine except python and py2exe script install ( of course something must destroy my day ) now when I run: $ cd c:\Python25\Lib\site-packages\ $ python mysetup.py py2exe 'python' is not recognized as an internal or external command, operable program or batch file. why? Regards, Vedran -- http://mail.python.org/mailman/listinfo/python-list
SUCK my HUSBAND'S CUM from my CUNT
-- http://mail.python.org/mailman/listinfo/python-list
SUCK my HUSBAND'S CUM from my CUNT
-- http://mail.python.org/mailman/listinfo/python-list
Re: Something in the function tutorial confused me.
Neil Cerutti wrote: On 2007-08-11, Alex Martelli [EMAIL PROTECTED] wrote: Neil Cerutti [EMAIL PROTECTED] wrote: ... The Python Language Reference seems a little confused about the terminology. 3.4.7 Emulating numeric types 6.3.1 Augmented assignment statements The former refers to augmented arithmetic operations, which I think is a nice terminology, since assignment is not necessarily taking place. Then the latter muddies the waters. Assignment *IS* necessarily taking place; if you try the augmented assignment on something that DOESN'T support assignment, you'll get an exception. Consider: tup=([],) tup[0] += ['zap'] Traceback (most recent call last): File stdin, line 1, in module TypeError: 'tuple' object does not support item assignment Tuples don't support item ASSIGNMENT, and += is an ASSIGNMENT, so tuples don't allow a += on any of their items. If you thought that += wasn't an assignment, this behavior and error message would be very problematic; since the language reference ISN'T confused and has things quite right, this behavior and error message are perfectly consistent and clear. Thanks for the correction. I was under the illusion that sometimes augmented assignment would instead mutate the object. I too thought += was an assignment. And it bit me very painfully a few weeks ago. If it's an assignment, then wouldn't x += y mean the same thing as x = x + y? If so, why does an assignment to variable a, below, have the *side effect* of changing variable b ... ? a = [1, 2, 3] b = a b [1, 2, 3] a += [4] a [1, 2, 3, 4] b [1, 2, 3, 4] ... but using the x = x + y style, the assignment to variable c, below, does *not* have a side effect on variable d (as indeed it should not!)? c = [1, 2, 3] d = c d [1, 2, 3] c = c + [4] c [1, 2, 3, 4] d [1, 2, 3] -- http://mail.python.org/mailman/listinfo/python-list
Re: Something in the function tutorial confused me.
Gregory D. Weber schreef: Neil Cerutti wrote: On 2007-08-11, Alex Martelli [EMAIL PROTECTED] wrote: Neil Cerutti [EMAIL PROTECTED] wrote: ... The Python Language Reference seems a little confused about the terminology. 3.4.7 Emulating numeric types 6.3.1 Augmented assignment statements The former refers to augmented arithmetic operations, which I think is a nice terminology, since assignment is not necessarily taking place. Then the latter muddies the waters. Assignment *IS* necessarily taking place; if you try the augmented assignment on something that DOESN'T support assignment, you'll get an exception. Consider: tup=([],) tup[0] += ['zap'] Traceback (most recent call last): File stdin, line 1, in module TypeError: 'tuple' object does not support item assignment Tuples don't support item ASSIGNMENT, and += is an ASSIGNMENT, so tuples don't allow a += on any of their items. If you thought that += wasn't an assignment, this behavior and error message would be very problematic; since the language reference ISN'T confused and has things quite right, this behavior and error message are perfectly consistent and clear. Thanks for the correction. I was under the illusion that sometimes augmented assignment would instead mutate the object. I too thought += was an assignment. And it bit me very painfully a few weeks ago. It is an assignment, but not only an assignment: first either the creation of a new object (in case of immutable objects) or the modification of an existing object (in case of mutable objects), than an assignment. If it's an assignment, then wouldn't x += y mean the same thing as x = x + y? No: - x += y, x is only evaluated once - in x += y, the operation is performed in-place if possible, meaning that (quoting from the language reference): rather than creating a new object and assigning that to the target, the old object is modified instead If so, why does an assignment to variable a, below, have the *side effect* of changing variable b ... ? a = [1, 2, 3] - A list is created and assigned to a b = a - That list is also assigned to b b [1, 2, 3] a += [4] - The list is modified (the list [4] is added to it) and assigned to a. It was already assigned to a, so that assignment doesn't do very much in this case. But it is performed. a [1, 2, 3, 4] b [1, 2, 3, 4] - Both a and b are still bound to the original (but now modified) list object ... but using the x = x + y style, the assignment to variable c, below, does *not* have a side effect on variable d (as indeed it should not!)? c = [1, 2, 3] - A list is created and assigned to c d = c - That list is also assigned to d d [1, 2, 3] c = c + [4] - A new list object is created (the sum of the original one and the list [4]) and assigned to c c [1, 2, 3, 4] - c is now bound to the new list object d [1, 2, 3] - ... while d is still bound to the original list object I hope this clears up things a bit... -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven -- http://mail.python.org/mailman/listinfo/python-list
Re: Metaclass v.s. Property function.
On Aug 11, 7:33 am, Jens Thiede [EMAIL PROTECTED] wrote: I don't like the property function, usable in the new-style classes, because having to remember to manage a list of foo = property(...) assignments just plain sucks, so I wrote a metaclass that does things a little differently. Please have a look and tell me whether this is useful or impractical. The metaclass is here:http://pastebin.com/m5b06b571 and some simple testcode is here:http://pastebin.com/m382f2ae9. Notice the first line though. Are you overusing property, by any chance? In your example, bar seems to be an unneeded property; it could just be a normal attribute. -- http://mail.python.org/mailman/listinfo/python-list
Re: Augmented assignment (was Re: Something in the function tutorial confused me.)
In article [EMAIL PROTECTED], OKB (not okblacke) [EMAIL PROTECTED] wrote: This sentence is phrased as though it is the whole story, but it isn't, because the operation might not in fact wind up being an assignment. Shouldn't there be an except see below or something there, to alert the reader that in some cases a true assignment doesn't occur? (I realize that the exception follows quite closely on the heels of this sentence, but it doesn't follow immediately, and is separated by a paragraph break and intervening material about the parallel to unaugmented x = x + 1. On initial reading my tendency is to read the end of the sentence quoted above, see a paragraph break and apparently explanatory material, and go oh, okay, I now have the full specification of this syntax when in fact I don't.) That's a good idea -- doc patches are always welcome! -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ And if that makes me an elitist...I couldn't be happier. --JMS -- http://mail.python.org/mailman/listinfo/python-list
Re: Augmented assignment (was Re: Something in the function tutorial confused me.)
In article [EMAIL PROTECTED], Roel Schroeven [EMAIL PROTECTED] wrote: I used to interpret the target in 'The target is only evaluated once' more like an L-value in C/C++. That's not correct, of course, but I didn't understand exactly how wrong it was until now. It's true almost everywhere except augmented assignment. Augmented assignment is a prime example of the compromises one needs to make in adding features. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ And if that makes me an elitist...I couldn't be happier. --JMS -- http://mail.python.org/mailman/listinfo/python-list
Re: Who told str() to round my int()'s!!!
On Aug 12, 5:37 am, Zentrader [EMAIL PROTECTED] wrote: On Aug 11, 9:40 am, Adam W. [EMAIL PROTECTED] wrote: After a fair amount of troubleshooting of why my lists were coming back a handful of digits short, and the last digit rounded off, I determined the str() function was to blame: foonum 0.0071299720384678782 str(foonum) '0.00712997203847' Why in the world does str() have any business rounding my numbers, and how do I get around this? If 15 digit precision is a concern, I would suggest that you us the decimal class instead of floating points. Floating point problems on X86 machines are well documented.http://docs.python.org/lib/module-decimal.htmlhttp://pydoc.org/2.4.1/decimal.htmlhttp://gmpy.sourceforge.net/ If you are concerned with precision of *communication*: The problem is not with floating points in general; floating point arithmetic can be done using a decimal representation for the numbers. The problem is not with X86 machines in particular; just about all modern machines have floating point hardware which implements the IEEE 754 standard for binary flaoting point arithmetic. The problem is with trying to represent in one base (e.g. 10) a non-integer number that is expressed in a different base (e.g. 2) -- where the number can be represented exactly only in one base (e.g. 1./10.) or in neither (e.g. 1./3.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Something in the function tutorial confused me.
On 8/11/07, Gregory D. Weber [EMAIL PROTECTED] wrote: I too thought += was an assignment. And it bit me very painfully a few weeks ago. If it's an assignment, then wouldn't x += y mean the same thing as x = x + y? If so, why does an assignment to variable a, below, have the *side effect* of changing variable b ... ? a = [1, 2, 3] b = a b [1, 2, 3] a += [4] a [1, 2, 3, 4] b [1, 2, 3, 4] ... but using the x = x + y style, the assignment to variable c, below, does *not* have a side effect on variable d (as indeed it should not!)? c = [1, 2, 3] d = c d [1, 2, 3] c = c + [4] c [1, 2, 3, 4] d [1, 2, 3] help(list.__iadd__) Help on wrapper_descriptor: __iadd__(...) x.__iadd__(y) == x+=y For mutable (built-in) objects such as lists, __iadd__ modifies the list and then returns the list object; for immutable objects, __iadd__ is equivalent to __add__ and just returns the new value. However, in both cases, the result is then rebound to x. This can lead to some behaviors you might not normally expect: t = ([],) t[0] += [1] Traceback (most recent call last): File stdin, line 1, in module TypeError: 'tuple' object does not support item assignment t ([1],) -- David -- http://mail.python.org/mailman/listinfo/python-list
Re: Who told str() to round my int()'s!!!
Adam W. wrote: Why in the world does str() have any business rounding my numbers, You are at the floating point numbers precision limit. Using str, numbers are rounded to your machine's float precision in decimal notation. Since floats are internally represented in binary notation of constant precision, the decimal precision expressed in number of places is not constant. Thus, safe rounding must be applied to get consistent results. and how do I get around this? If you don't want this (and thus introduce random deviations if you assume greater precision than the number of places str gives you), use repr. You've been warned. foonum = .0071299720384678782 foonum 0.0071299720384678782 str(foonum) '0.00712997203847' repr(foonum) '0.0071299720384678782' Regards, Björn -- BOFH excuse #5: static from plastic slide rules -- http://mail.python.org/mailman/listinfo/python-list
Re: Public Telnet Server?
Dave wrote: Hi there. I'm a beginner at Python and I'm writing my first Python script. It's a text adventure about coffee and mixing drinks and being crazy and such. I keep updating it and want my friends to beta test it for me, but some of them don't have the right version of Python or don't want to get Python at all. Sounds like Windows users. Isn't py2exe an option? Regards, Björn -- BOFH excuse #339: manager in the cable duct -- http://mail.python.org/mailman/listinfo/python-list
Re: python 2.5 bug
Thorsten Kampe wrote: Yeah. Did the Original Poster mention any details about his problem. Like - for instance - that he's using Windows? Don't you know the empiric law of platforms? :) Users who ask about OS specific problems and not state their platform are Windows users. Regards, Björn -- BOFH excuse #284: Electrons on a bender -- http://mail.python.org/mailman/listinfo/python-list
Re: The Future of Python Threading
Nick Craig-Wood wrote: Bjoern Schliessmann [EMAIL PROTECTED] So, how much performance gain would you get? Again, managing fine-grained locking can be much more work than one simple lock. Assuming that you are not IO bound, but compute bound and that compute is being done in python then you'll get a speed up proportional to how many processors you have, minus a small amount for locking overhead. Assuming this: Agreed. Regards, Björn -- BOFH excuse #348: We're on Token Ring, and it looks like the token got loose. -- http://mail.python.org/mailman/listinfo/python-list
Re: python 2.5 bug
* (Sat, 11 Aug 2007 12:50:38 -0700) On 11 kol, 20:58, Thorsten Kampe [EMAIL PROTECTED] wrote: * Laurent Pointal (Sat, 11 Aug 2007 20:09:03 +0200) [EMAIL PROTECTED] wrote: On 11 kol, 11:59, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote: On Sat, 11 Aug 2007 02:41:26 -0700, vedrandekovic wrote: I was install Python 2.5 and uninstall Python 2.4 now I cannot run my scripts, only from idle IMHO Python 2.4 was registered for .py files, Python 2.5 take precedence when installed, but when Python 2.4 has been removed, it remove .py files association too (so break Python 2.5 association). * manually associate .py/.pyc/.pyo files to python.exe, .pyw files to pythonw.exe. * or reinstall Python 2.5 so that it re-setup ad-hoc associations. Yeah. Did the Original Poster mention any details about his problem. Like - for instance - that he's using Windows? Now I was restart my windows and python 2.5 also.Now everything works fine except python and py2exe script install ( of course something must destroy my day ) now when I run: $ cd c:\Python25\Lib\site-packages\ $ python mysetup.py py2exe 'python' is not recognized as an internal or external command, operable program or batch file. why? Because the directory containing python.exe is not in your path. By the way: the Python installation routine doesn't modify your path so it is likely unrelated to that. T. -- http://mail.python.org/mailman/listinfo/python-list
Re: The Future of Python Threading
On Aug 10, 5:13 pm, Chris Mellon [EMAIL PROTECTED] wrote: On 8/10/07, Ben Sizer [EMAIL PROTECTED] wrote: On 10 Aug, 15:38, Ben Finney [EMAIL PROTECTED] wrote: Last I checked, multiple processes can run concurrently on multi-core systems. That's a well-established way of structuring a program. It is, however, almost always more complex and slower-performing. Plus, it's underdocumented. Most academic study of concurrent programming, while referring to the separately executing units as 'processes', almost always assume a shared memory space and the associated primitives that go along with that. This is simply not true. Firstly, there's a well defined difference between 'process' and a 'thread' and that is that processes have private memory spaces. Nobody says process when they mean threads of execution within a shared memory space and if they do they're wrong. I'm afraid that a lot of what students will be taught does exactly this, because the typical study of concurrency is in relation to contention for shared resources, whether that be memory, a file, a peripheral, a queue, etc. One example I have close to hand is 'Principles of Concurrent and Distributed Programming', which has no mention of the term 'thread'. It does have many examples of several processes accessing shared objects, which is typically the focus of most concurrent programming considerations. The idea that processes have memory space completely isolated from other processes is both relatively recent and not universal across all platforms. It also requires you to start treating memory as arbitrarily different from other resources which are typically shared. And no, most academic study isn't limited to shared memory spaces. In fact, almost every improvement in concurrency has been moving *away* from simple shared memory - the closest thing to it is transactional memory, which is like shared memory but with transactional semantics instead of simple sharing. I think I wasn't sufficiently clear; research may well be moving in that direction, but you can bet that the typical student with their computer science or software engineering degree will have been taught far more about how to use synchronisation primitives within a program than how to communicate between arbitrary processes. There's nothing undocumented about IPC. It's been around as a technique for decades. Message passing is as old as the hills. I didn't say undocumented, I said underdocumented. The typical programmer these days comes educated in at least how to use a mutex or semaphore, and will probably look for that capability in any language they use. They won't be thinking about creating an arbitrary message passing system and separating their project out into separate programs, even if that has been what UNIX programmers have chosen to do since 1969. There are a multitude of different ways to fit IPC into a system, but only a few approaches to threading, which also happen to coincide quite closely to how low-level OS functionality handles processes meaning you tend to get taught the latter. That's why it's useful for Python to have good support for it. Hardly. Sure, so you don't have to worry about contention over objects in memory, but it's still completely asynchronous, and there will still be a large degree of waiting for the other processes to respond, and you have to develop the protocols to communicate. Apart from convenient serialisation, Python doesn't exactly make IPC easy, unlike Java's RMI for example. There's nothing that Python does to make IPC hard, either. There's nothing in the standard library yet, but you may be interested in Pyro (http://pyro.sf.net) or Parallel Python (http://www.parallelpython.com/). It's not erlang, but it's not hard either. At least, it's not any harder than using threads and locks. Although Pyro is good in what it does, simple RPC alone doesn't solve most of the problems that typical threading usage does. IPC is useful for the idea of submitting jobs in the background but it doesn't fit so well to situations where there are parallel loops both acting on a shared resource. Say you have a main thread and a network reading thread - given a shared queue for the data, you can safely do this by adding just 5 lines of code: 2 locks, 2 unlocks, and a call to start the networking thread. Implementing that using RPC will be more complex, or less efficient, or probably both. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: I am giving up perl because of assholes on clpm -- switching to Python
I had this very same problem with the doxygen mailing list... doxygen is such a great tool but full of assholes in their mailing list. On 8/2/07, Jamie [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], [EMAIL PROTECTED] mentions: Python is a better language, with php support, anyway, but I am fed up with attitudes of comp.lang.perl.misc. Assholes in this newsgroup ruin Perl experience for everyone. Instead of being helpful, snide remarks, back-biting, scare tactings, and so on proliferate and self reinforce. All honest people have left this sad newsgroup. Buy bye, assholes, I am not going to miss you!!! Martha I've heard people tell the same story, that perl folks are... rude. Actually, I've pretty much heard (and noticed) that about linux, too. Yet, linux is still a good operating environment, so is perl. You'll find rude people everywhere you look. While it may be true that there is a higher percentage of hard-core tech folks who might lack social skills, at least they don't err.. well, maybe they do.. byte. :-) Seriously, it is one of the problems facing perl (and linux) people ARE turned away by the attitude. It is rather embarassing/unflattering when someone is critical of your work. I see a lot of ideas about things should be made easier but I think thats the wrong course. We really just need to be nicer to new folks. Jamie -- http://www.geniegate.comCustom web programming Perl * Java * UNIXUser Management Solutions -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Something in the function tutorial confused me.
On 2007-08-11, Alex Martelli [EMAIL PROTECTED] wrote: Neil Cerutti [EMAIL PROTECTED] wrote: ... The Python Language Reference seems a little confused about the terminology. 3.4.7 Emulating numeric types 6.3.1 Augmented assignment statements The former refers to augmented arithmetic operations, which I think is a nice terminology, since assignment is not necessarily taking place. Then the latter muddies the waters. Assignment *IS* necessarily taking place; if you try the augmented assignment on something that DOESN'T support assignment, you'll get an exception. Consider: tup=([],) tup[0] += ['zap'] Traceback (most recent call last): File stdin, line 1, in module TypeError: 'tuple' object does not support item assignment Tuples don't support item ASSIGNMENT, and += is an ASSIGNMENT, so tuples don't allow a += on any of their items. If you thought that += wasn't an assignment, this behavior and error message would be very problematic; since the language reference ISN'T confused and has things quite right, this behavior and error message are perfectly consistent and clear. Thanks for the correction. I was under the illusion that sometimes augmented assignment would instead mutate the object. OK, I've thought about this some more and I think the source of my confusion was I thought assignment in Python meant binding a name to something, not mutating an object. But in the case of augmented assignment, assignment no longer means that? -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: The Future of Python Threading
On Aug 11, 5:43 am, Seun Osewa [EMAIL PROTECTED] wrote: I think I've heard Guido say the last attempt at removing the Global Interpreter Lock (GIL) resulted in a Python that was much slower... What is it about Python that makes a thread-safe CPython version much slower? Why doesn'ttrue threading slow down other languages like Perl and Java? I have no idea about Perl - but there's probably some hideous black magic going on ;-) As for Java, making code thread safe *does* slow down the code. It is the very reason that the language designers made the collections API non-thread safe by default (you have to wrap the standard collections in a synchronised wrapper to make them thread safe). -- Ant... -- http://mail.python.org/mailman/listinfo/python-list
Re: I am giving up perl because of assholes on clpm -- switching to Python
On 8/11/07, Robert Dailey [EMAIL PROTECTED] wrote: I had this very same problem with the doxygen mailing list... doxygen is such a great tool but full of assholes in their mailing list. I'm not defending any assholes you may have ran into, but I find the thing to do is only ask questions in such a way that no one can possibly have a reason to be an asshole. http://catb.org/~esr/faqs/smart-questions.html -- Greg Donald http://destiney.com/ -- http://mail.python.org/mailman/listinfo/python-list
Threading problem when many sockets open
Hi all, I have written a socket based service in python and under fairly heavy traffic it performs really well. But i have encountered the following problem: when the system runs out of file descriptors, it seems to stop switching control between threads. Here is some more detail: The system has n+2 threads, where n is usually around 10. This was implemented using the 'threading' and 'socket' modules in the python 2.5 standard library. -- The master thread accepts new socket connections and then enqueues the connection on a Queue (from the standard library). -- There are n handler threads that pop a connection off of the queue, read some number of bytes (~10), do some processing and then send ~100 bytes back over the connection and close it. -- The last thread is just a logging thread that has a queue of messages that it writes to either stdout or a file. Under pretty substantial load, the processing is quick enough that the connections do not pile up very quickly. But, in some cases they do. And what I found was that as soon as the size of the Queue of connections reached a high enough number (and it was always the same), all of the processing seemed to stay in the master thread. I created a siege client that opened up 1000+ connections and the server would go into a state where the master thread repeatedly polled the socket and printed an error. The Queue size stayed fixed at 997 even if i shut down all of the connectionso n the client side. Under normal operating conditions, those connections would be detected as broken in the handler thread and a message would be logged. So it seems that the handler threads aren't doing anything. (And they are still alive, i check that in the master thread). OK. I hope all of this is clear. Currently, I've solved the problem by putting a cap on the queue size and i haven't seen the problem reoccur. But it would be nice to understand exactly what went wrong. Thanks in advance. -- -- Philip Zigoris I SPOCK I 650.366.1165 Spock is Hiring! www.spock.com/jobs -- http://mail.python.org/mailman/listinfo/python-list
C++ Runtime Library error message - Pythonwin?
Hi, Doing GIS [Geographic Information Systems] scripts. I was running a batch clip script that worked OK for 126 iterations then I got the following message: Microsoft Visual C++ Runtime Library program: C:\python21\pythonwin\pythonwin.exe This application has requested the runtime to terminate in an unusual way. Please contact the applications support team for more information. What does this mean? Using XP. Is there a log on my system that gives more info? Thanks -- http://mail.python.org/mailman/listinfo/python-list
Binary, Hex, and Decimal string conversions
Hi, I was wondering if there is a built in module that supports conversion in any direction between Binary, Hex, and Decimal strings? Thanks. -- http://mail.python.org/mailman/listinfo/python-list
New Programms for free
http://www.pennergame.de/ref.php?uid=5572 -- http://mail.python.org/mailman/listinfo/python-list
Re: Something in the function tutorial confused me.
Neil Cerutti [EMAIL PROTECTED] wrote:
...
OK, I've thought about this some more and I think the source of
my confusion was I thought assignment in Python meant binding a
name to something, not mutating an object. But in the case of
augmented assignment, assignment no longer means that?
Plain assignment *to a plain name* does mean binding a name (the
LHS) to something (the RHS).
Other assignments (ones that are not plain assignments to names) may
have different meanings. For example:
class act(object):
... def __init__(self, c): self._c = c
... def getC(self): return self._c
... def setC(self, *ignore): self._c += 1
... c = property(getC, setC)
...
x = act(0)
x.c
0
x.c = 23
x.c
1
Here's an example where a plain assignment (to an attribute of x, not to
a plain name) obviously DOESN'T mean binding a name to something: the
something (the RHS) is completely ignored, so the plain assignment is
mutating an object (x) and not binding any name to anything.
Plain assignments to items and slices can also often be best seen as
mutating an object (the one being indexed or sliced on the LHS) rather
than binding a name. For example:
l=list('ciao')
l[1:3]='app'
l
['c', 'a', 'p', 'p', 'o']
If I was teaching Python and came upon this example, I would definitely
not try to weaselword the explanation of what's going on in terms of
binding a name (or several ``names'', including ``rebinding a new
``name'' l[4] to the 'o' that was previously ``bound'' to l[3], etc:-):
it's just orders of magnitudes simpler to explain this as mutating an
object, namely the list l.
I take almost 3 pages in Python in a Nutshell (47 to 49 in the second
edition) to summarily explain every kind assignment -- and that's in a
work in which I've tried (successfully, I believe from reviews) to be
very, *VERY* concise;-).
Summarizing that summary;-), a plain assignment to an identifier binds
that name; a plain assignment to an attribute reference x.y asks object
x (x can be any expression) to bind its attribute named 'y'; a plain
assignment to an indexing x[y] (x and y are arbitrary expressions) asks
object x to bind its item indicated by the value of y); a plain
assignment to a slicing is equivalent to the plain assignment to the
indexing with an index of slice(start, stop, stride) [[slice is a Python
builtin type]].
Plain assignment to an identifier just happens; all other cases of
plain assignment are requests to an object to bind one or more of its
attributes or items (i.e., requests for specific mutations of an object)
-- as for, say any method call (which might also be a request for some
kind of mutation), the object will do whatever it pleases with the
request (including, perhaps, refusing it, by raising an exception).
Then we get into unpacking assignments and augmented assignments, but I
don't really want to write two more pages worth of summary...;-).
Alex
--
http://mail.python.org/mailman/listinfo/python-list
Pausing and Unpausing Threads
Hello, This is a question about how to pause and unpause threads (as the title suggests). I've created an extension of threading.Thread which I'll call Server. Server has a collection of Controlers. A Controler has a method turn(), which lets it do various interesting things. While the Server is running, it loops through each of its Controlers and calls their turn() method. One of these Controlers is a subclass called DirectedControler. What a DirectedControler is meant to do is wait until it is given an Action object it can invoke. Actions are basically an implementation of the Command pattern. Actions are also invalid in certain circumstances; they return False when executed if they didn't do anything. Therefore, when a DirectedControler is given a turn, it waits while: - It has no Action - The last Action it was given didn't do anything Actions are sent to the DirectedControler by a Client that exists in the main thread. What I'm trying to figure out is how to make the DirectedControler pause while it is waiting for a valid Action. So far I just put it into a loop like this: def turn(self): while self.__action is None or not self.__action.execute(): self.__action = None # Throw away invalid actions pass self.__action = None # Action was valid. Clear the way for the # next turn's Action. Where the Action is set like this (by the Client): def setAction(self, action): if self.__action is None: self.__action = action I'm worried that this loop may wast some CPU cycles, and wonder if there's a better way through thread synchronization using such things as Events or Conditions. Thank you, Aaron J. M. -- http://mail.python.org/mailman/listinfo/python-list
Re: wxPython - drawing without paint event
On Aug 11, 3:31 am, Bjoern Schliessmann usenet- [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On a related topic, it seems like it would be nice to do *all* drawing in response topaintevents. When I get aneventfrom the timer, I would just tell wx that part of the window needs redrawing, and depend on it to give me apainteven when nothing of higher priority needs to be done. One nice strategy from an example in wxPython in Action is the following: * the frame has Draw methods that draw into a BufferedDC, which is chained to a bitmap member * inside thepaintmethod, the bitmap member is drawn to screen Okay, but how do I tell wx that it needs to send me a paint event? -- http://mail.python.org/mailman/listinfo/python-list
Re: python 2.5 bug
On Aug 11, 12:32 am, Thorsten Kampe [EMAIL PROTECTED] wrote: 4. don't do something you don't fully understand (in this case installing Python 2.5 and uninstalling Python 2.4) If we were all limited by that rule, none of us would never have used a computer in the first place. Operating a computer is a learning experience, no matter what level you're at (although admittedly the lessons learned can sometimes be hurtful). -- http://mail.python.org/mailman/listinfo/python-list
Re: Module imports during object instantiation
On Aug 11, 3:17 am, James Stroud [EMAIL PROTECTED] wrote: You do realize your import statement will only be called for nt and dos systems don't you? Yes. I would like to load a Windows Python Module (which is, say a specific implementation for Windows only) in such a condition where I find that the platform is Dos/NT. Loading it globally doesn't make sense because when from the same class an object is created on a non-windows platfom, it would be waste. It would either ImportError or else just load the module and never use it. As per my understanding __init__ is executed only once during object creation. For such situations (that I've explained above), I think __init__() is the correct place to put imports. Ritesh -- http://mail.python.org/mailman/listinfo/python-list
Re: Web based Reporting tool for Python
On Aug 8, 4:57 pm, Jon Rosebaugh [EMAIL PROTECTED] wrote: On 2007-08-07 23:35:26 -0500, Madhu Alagu [EMAIL PROTECTED] said: Thanking so much for all the informations and links.I would like to use Mako Templates(www.makotemplates.org).Ilike to use simple and python default module... Mako is an excellent template system, but you'll have a lot of work to do making it into a reporting system. Any reporting template in python ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Destruction of generator objects
On Aug 11, 2:50 pm, Stefan Bellon [EMAIL PROTECTED] wrote: So why is the destructor not called when the generator is even explicitly 'del'ed? Does somebody else still hold a reference on it? You ( we ) have produced a reference cycle. In that case __del__ doesn't work properly ( according to the docs ). The cycle is caused by the following assignment in your code: self.gen = self._value() So we have to refactor the solution to eliminate the cycle. I spent some time to create a generic decorator solution and a protocol for handling / releasing the resources. 1) Create a FinalizerGenerator class that is cycle free ( of course you can find a trick to shoot yourself in your foot ). Pass a generator function together with its arguments into the constructor. An additional callable attribute close is used together with __del__. class FinalizerGenerator(object): def __init__(self, gen, *args, **kwd): print gen init self._gen = gen# no cycle when passing the _value function self.close = lambda: sys.stdout.write(gen del) # assign cleanup function def __del__(self): self.close() def __iter__(self): print gen iter return self def next(self): print gen next return self.gen.next() 2) Define generators s.t. they yield the resource to be destroyed as their first value. def producer(resource): print gen value yield resource # yield resource before start iteration for item in resource: yield item 3) Define the destructor for the resource. The resource must be passed as a first argument. The return value is a callable without arguments that serves as a close() function within FinalizerGenerator.__del__ method. def close_resource(resource): return lambda: sys.stdout.write(close resource: %s%resource) 4) The finalize_with decorator def finalize_with(close_resource): def closing(func_gen): def fn(*args, **kwd): # fg serves as a replacement for the original generator func_def fg = FinalizerGenerator(func_gen)(*args, **kwd) # apply the closing protocol resource = fg.next() fg.close = close_resource(resource) return fg fn.__name__ = func_gen.__name__ return fn return closing 5) decorate the generator and check it out @finalize_with(close_resource) def producer(resource): print gen value yield resource for item in resource: yield item def test(): pg = producer([1,2,3]) pg.next() test() gen init gen next# request for resource in finalize_with gen value gen next close resource: [1, 2, 3] # yep -- http://mail.python.org/mailman/listinfo/python-list
