Re: Appending traceback from exception in child thread
On Fri, May 15, 2009 at 1:09 PM, Edd e...@nunswithguns.net wrote: Hi folks, I have a some threadpool code that works like this : tp = ThreadPool(number_of_threads) futures = [tp.future(t) for t in tasks] # each task is callable for f in futures: print f.value() # -- may propagate an exception The idea being that a Future object represents a value that may or may not have been computed yet and the .value() method will block until that value is ready. As the comment on the last line indicates, looking at the .value() of a Future may give the return value of the associated task, or it may also propagate an exception that was raised in a child thread. Inside the implementation I store caught exceptions with code that looks something like: try: self.return_value = self.task() except: self.exception = sys.exc_info()[1] The problem I have is that when an exception is propagated in to the parent thread by re-raising it, the part of the traceback from the child thread is lost. So if the program dies due to such an exception, I can't see what caused it by examining the printed traceback. To solve this problem, I could of course grab the traceback in the child thread and create some kind of custom exception that stashes the trace inside. This could then be caught on the fringes of my code in order to combine the tracebacks of parent and child together before printing it. But I was wondering if there might be a nicer way that keeps the original exception object. Perhaps something akin to gluing the tracebacks together at the point where the exception is re-raised? Kind regards, Edd -- http://mail.python.org/mailman/listinfo/python-list Take a look at the Deferred and Failure objects from Twisted. Deferred is a deferred result with callback (basically a Future without the blocking interface), and Failure is an asynchronous exception object. -- http://mail.python.org/mailman/listinfo/python-list
Re: A Twisted Design Decision
On Wed, Jan 28, 2009 at 10:05 AM, koranthala koranth...@gmail.com wrote: On Jan 28, 8:36 pm, Jean-Paul Calderone exar...@divmod.com wrote: On Wed, 28 Jan 2009 06:30:32 -0800 (PST), koranthala koranth...@gmail.com wrote: On Jan 28, 7:10 pm, Jean-Paul Calderone exar...@divmod.com wrote: On Wed, 28 Jan 2009 02:02:57 -0800 (PST), koranthala koranth...@gmail.com wrote: On Jan 27, 9:27 pm, koranthala koranth...@gmail.com wrote: On Jan 27, 6:57 pm, Jean-Paul Calderone exar...@divmod.com wrote: [snip] Thank you Jean-Paul. My code is more complex than what I have mentioned. When I mentioned msg.send, the msg object actually gets the data from DB etc to send. And there are many other items being done. I will try to see whether I can change the code to incorporate what you mentioned. I rewrote most of my code after learning just raw deferreds - I had planned to study inlineCallbacks - but then it slipped my mind - now it has come to bit me. :-( Hi, I tried to update the code as per the suggestion, but to no avail. My system uses Python2.4.3 (cannot move to 2.5) - so I tried to rewrite with deferredGenerators - since I thought inlineCallbacks are similar to deferredGenerators. But I cannot seem to rewrite it in a format where the functional encapsulation is not broken. i.e. as I mentioned in the first example - I have to pass SELF to child objects for them to modify it. Why? You don't do this in the original version of your code. Why do it after switching to Twisted (particularly since you seem to want *not* to)? Jean-Paul Without that, I am unable to increment success and failure counters which are part of the message handler object. In the original version, if send fails the return value of protocol.send is propogated back to msg.send and to msg handler.send. But in twisted, it is not so. So, I have to pass in SELF through to increment success and failure counter. Is it possible otherwise in twisted? Why isn't the return value of protocol.send propagated back to msg.send? It sounds like it should be. Jean-Paul Thank you very much again Jean-Paul for helping me out. I am unable to understand how I will be able to propogate the return value of protocol.send to msg.send. Maybe I am being foolish - but my understanding is as follows. In a non-reactor pattern scenario: msg_handler.send_message calls msg.send which inturn calls protocol.send. So, the reply to protocol.send actually goes up the stack till msg_handler.send_message wherein I can increment/decrement success/ failure counter. In reactor pattern: msg_handler.send_message calls msg.send which call protocol.send which causes a deferred to be created. Now, when the deferred finishes its work, reactor calls the callback associated - but the original context (stack etc) is lost. Now, the only mechanism of interaction is via the parameters passed in the callback. This means that msg_handler has to pass in its object to msg.send which inturn has to send either msg_handler or self to protocol.send so that it is stored in the parameter to the callback. When callback is hit, I use this parameter to call methods in each object. This is what I was trying to say in my first mail that - Twisted, being twisted in its behavior is causing quite a lot of confusion in design decisions - because now I have to break functional encapsulation - by asking lower layer objects to handler upper layer objects behaviors. As I said earlier, maybe I am being completely stupid - there might be a very easy and obvious solution. But I cannot seem to get it at all. I'm sure you're not completely stupid, but there is an easy and obvious solution - you should be returning the *deferred* up the callstack. That will allow the MessageHandler to attach callbacks/errbacks to it, without needing to pass self all the way down the call stack and have a proxy object manage it. -- http://mail.python.org/mailman/listinfo/python-list
Re: BadZipfile file is not a zip file
On Sat, Jan 10, 2009 at 1:32 PM, webcomm rya...@gmail.com wrote: On Jan 9, 7:33 pm, John Machin sjmac...@lexicon.net wrote: It is not impossible for a file with dummy data to have been handcrafted or otherwise produced by a process different to that used for a real-data file. I knew it was produced by the same process, or I wouldn't have shared it. : ) But you couldn't have known that. Not sure if you've seen this thread...http://groups.google.com/group/comp.lang.python/browse_thread/thread/... Yeah, I've seen it ... (sigh) ... pax Steve Holden, but *please* stick with one thread ... Thanks... I thought I was posting about separate issues and would annoy people who were only interested in one of the issues if I put them both in the same thread. I guess all posts re: the same script should go in one thread, even if the questions posed may be unrelated and may be separate issues. There are grey areas. Problem solved in John Machin's post at http://groups.google.com/group/comp.lang.python/browse_thread/thread/d84f42493fe81864/03b8341539d87989?hl=enlnk=raot#03b8341539d87989 It's worth pointing out (although the provider probably doesn't care) that this isn't really an XML document and this was a bad way of them to distribute the data. If they'd used a correctly formatted XML document (with the prelude and everything) with the correct encoding information, existing XML parsers should have just Done The Right Thing with the data, instead of you needing to know the encoding a priori to extract an XML fragment. -- http://mail.python.org/mailman/listinfo/python-list
Re: Slow network?
On Mon, Jan 12, 2009 at 1:13 PM, Laszlo Nagy gand...@shopzeus.com wrote: Hi All, To make the long story short, I have a toy version of an ORB being developed, and the biggest problem is slow network speed over TCP/IP. There is an object called 'endpoint' on both sides, with incoming and outgoing message queues. This endpoint object has a socket assigned, with nodelay: conn.setsockopt(socket.IPPROTO_TCP,socket.TCP_NODELAY,1) The endpoint is running two separate threads - those are dedicated for reading/writing messages from/into the socket object, as shown below: def _process_incoming(self): try: while not self.stop_requested.isSet(): data = self.read_str() while not self.stop_requested.isSet(): try: self.incoming.put(data,1) break except orb.util.smartqueue.Full: pass if not self.stop_requested.isSet(): if self.router: self.router.on_message_arrived(self) except Exception, e: if self.router: if not isinstance(e,TransportClosedError): self.router.logger.error(dumpexc(e)) self.router.unregister_endpoint(self) self.shutdown() raise SystemExit(0) def _process_outgoing(self): try: while not self.stop_requested.isSet(): data_ok = False while not self.stop_requested.isSet(): try: data = self.outgoing.get(1) data_ok = True break except orb.util.smartqueue.Empty: pass if data_ok: self.write_str(data) except Exception, e: if self.router: if not isinstance(e,TransportClosedError): self.router.logger.error(dumpexc(e)) self.router.unregister_endpoint(self) self.shutdown() raise SystemExit(0) The main point is that the sender does not need to wait for the message to be actually written into the socket (unless the outgoing queue becomes full). When I try to send a message and receive an answer for it, I can only get as much as 130 request+response message pairs per second. Apparently, it is the same from messages size =77bytes to message size=16 Kbytes. However, if I send 100 outgoing messages first, then read back all answers then the speed goes up to 1300 message pairs/sec. I suspect that this has something to do with TCP/IP. Since this will be used for RPC/RMI, it would be very important to lower the time needed to exchange messages. Is there any way I can speed this up? It is very likely that nodelay is actually hurting you here. Using the select module and doing non-blocking IO will be faster than using threads for this as well. -- http://mail.python.org/mailman/listinfo/python-list
Re: urllib2 - 403 that _should_ not occur.
On Mon, Jan 12, 2009 at 4:34 PM, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: On Mon, 12 Jan 2009 00:38:20 -0600, Chris Mellon wrote: Why Google would deny access to services by unknown User Agents is beyond me - especially since in most cases User Agents strings are not strict. If you look at the actual response text and not just the error code, you will get a clear explanation of why you were forbidden. You have a funny idea of what constitutes a clear explanation. H1Forbidden/H1 Your client does not have permission to get URL code/group/chromium- announce/feed/rss_v2_0_msgs.xml/code from this server. That hardly explains Why Google would deny access to services by unknown User Agents, does it? I suppose I should have checked that specific URL. The search results pages (last I checked) gave a detailed error message. -- http://mail.python.org/mailman/listinfo/python-list
Re: urllib2 - 403 that _should_ not occur.
On Sun, Jan 11, 2009 at 9:05 PM, James Mills prolo...@shortcircuit.net.au wrote: On Mon, Jan 12, 2009 at 12:58 PM, Philip Semanchuk phi...@semanchuk.com wrote: On Jan 11, 2009, at 8:59 PM, James Mills wrote: Hey all, The following fails for me: from urllib2 import urlopen f = urlopen(http://groups.google.com/group/chromium-announce/feed/rss_v2_0_msgs.xml;) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.6/urllib2.py, line 124, in urlopen return _opener.open(url, data, timeout) File /usr/lib/python2.6/urllib2.py, line 389, in open response = meth(req, response) File /usr/lib/python2.6/urllib2.py, line 502, in http_response 'http', request, response, code, msg, hdrs) File /usr/lib/python2.6/urllib2.py, line 427, in error return self._call_chain(*args) File /usr/lib/python2.6/urllib2.py, line 361, in _call_chain result = func(*args) File /usr/lib/python2.6/urllib2.py, line 510, in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) urllib2.HTTPError: HTTP Error 403: Forbidden However, that _same_ url works perfectly fine on the same machine (and same network) using any of: * curl * wget * elinks * firefox Any helpful ideas ? The remote server doesn't like your user agent? It'd be easier to help if you post a working sample. That was a working sample! The User-Agent didn't occur to me :) Thanks - I think that might be it. Why Google would deny access to services by unknown User Agents is beyond me - especially since in most cases User Agents strings are not strict. If you look at the actual response text and not just the error code, you will get a clear explanation of why you were forbidden. -- http://mail.python.org/mailman/listinfo/python-list
Re: BadZipfile file is not a zip file
On Fri, Jan 9, 2009 at 9:05 AM, webcomm rya...@gmail.com wrote: On Jan 9, 3:46 am, Carl Banks pavlovevide...@gmail.com wrote: The zipfile format is kind of brain dead, you can't tell where the end of the file is supposed to be by looking at the header. If the end of file hasn't yet been reached there could be more data. To make matters worse, somehow zip files came to have text comments simply appended to the end of them. (Probably this was for the benefit of people who would cat them to the terminal.) Anyway, if you see something that doesn't adhere to the zipfile format, you don't have any foolproof way to know if it's because the file is corrupted or if it's just an appended comment. Most zipfile readers use a heuristic to distinguish. Python's zipfile module just assumes it's corrupted. The following post from a while back gives a solution that tries to snip the comment off so that zipfile module can handle it. It might help you out. http://groups.google.com/group/comp.lang.python/msg/c2008e48368c6543 Carl Banks Thanks Carl. I tried Scott's getzip() function yesterday... I stumbled upon it in my searches. It didn't seem to help in my case, though it did produce a different error: ValueError, substring not found. Not sure what that means. -- http://mail.python.org/mailman/listinfo/python-list This is a ticket about another issue or 2 with invalid zipfiles that the zipfile module won't load, but that other tools will compensate for: http://bugs.python.org/issue1757072 -- http://mail.python.org/mailman/listinfo/python-list
Re: distinction between unzipping bytes and unzipping a file
On Fri, Jan 9, 2009 at 2:32 PM, webcomm rya...@gmail.com wrote:
On Jan 9, 3:15 pm, Steve Holden st...@holdenweb.com wrote:
webcomm wrote:
Hi,
In python, is there a distinction between unzipping bytes and
unzipping a binary file to which those bytes have been written?
The following code is, I think, an example of writing bytes to a file
and then unzipping...
decoded = base64.b64decode(datum)
#datum is a base64 encoded string of data downloaded from a web
service
f = open('data.zip', 'wb')
f.write(decoded)
f.close()
x = zipfile.ZipFile('data.zip', 'r')
After looking at the preceding code, the provider of the web service
gave me this advice...
Instead of trying to create a file, take the unzipped bytes and get a
Unicode string of text from it.
Not terribly useful advice, but one presumes he she or it was trying to
be helpful.
If so, I'm not sure how to do what he's suggesting, or if it's really
different from what I've done.
Well, what you have done appears pretty wrong to me, but let's take a
look. What's datum? You appear to be treating it as base64-encoded data;
is that correct? Have you examined it?
It's data that has been compressed then base64 encoded by the web
service. I'm supposed to download it, then decode, then unzip. They
provide a C# example of how to do this on page 13 of
http://forums.regonline.com/forums/docs/RegOnlineWebServices.pdf
If you have a minute, see also this thread...
http://groups.google.com/group/comp.lang.python/browse_thread/thread/d72d883409764559/5b9ec3e77dd4?hl=enlnk=gstq=webcomm#5b9ec3e77dd4
When they say zip, they're talking about a zlib compressed stream of
bytes, not a zip archive.
You want to base64 decode the data, then zlib decompress it, then
finally interpret it as (I think) UTF-16, as that's what Windows
usually means when it says Unicode.
decoded = base64.b64decode(datum)
decompressed = zlib.decompress(decoded)
result = decompressed.decode('utf-16')
--
http://mail.python.org/mailman/listinfo/python-list
Re: distinction between unzipping bytes and unzipping a file
On Fri, Jan 9, 2009 at 3:08 PM, Chris Mellon arka...@gmail.com wrote:
On Fri, Jan 9, 2009 at 2:32 PM, webcomm rya...@gmail.com wrote:
On Jan 9, 3:15 pm, Steve Holden st...@holdenweb.com wrote:
webcomm wrote:
Hi,
In python, is there a distinction between unzipping bytes and
unzipping a binary file to which those bytes have been written?
The following code is, I think, an example of writing bytes to a file
and then unzipping...
decoded = base64.b64decode(datum)
#datum is a base64 encoded string of data downloaded from a web
service
f = open('data.zip', 'wb')
f.write(decoded)
f.close()
x = zipfile.ZipFile('data.zip', 'r')
After looking at the preceding code, the provider of the web service
gave me this advice...
Instead of trying to create a file, take the unzipped bytes and get a
Unicode string of text from it.
Not terribly useful advice, but one presumes he she or it was trying to
be helpful.
If so, I'm not sure how to do what he's suggesting, or if it's really
different from what I've done.
Well, what you have done appears pretty wrong to me, but let's take a
look. What's datum? You appear to be treating it as base64-encoded data;
is that correct? Have you examined it?
It's data that has been compressed then base64 encoded by the web
service. I'm supposed to download it, then decode, then unzip. They
provide a C# example of how to do this on page 13 of
http://forums.regonline.com/forums/docs/RegOnlineWebServices.pdf
If you have a minute, see also this thread...
http://groups.google.com/group/comp.lang.python/browse_thread/thread/d72d883409764559/5b9ec3e77dd4?hl=enlnk=gstq=webcomm#5b9ec3e77dd4
When they say zip, they're talking about a zlib compressed stream of
bytes, not a zip archive.
You want to base64 decode the data, then zlib decompress it, then
finally interpret it as (I think) UTF-16, as that's what Windows
usually means when it says Unicode.
decoded = base64.b64decode(datum)
decompressed = zlib.decompress(decoded)
result = decompressed.decode('utf-16')
And of course as *soon* as I write that, I read the appendix on the
documentation in full and turn out to be wrong. Ignore me *sigh*.
It would really help if you could post a sample file somewhere.
--
http://mail.python.org/mailman/listinfo/python-list
Re: looking for tips on how to implement ruby-style Domain Specific Language in Python
On Wed, Jan 7, 2009 at 9:50 AM, J Kenneth King ja...@agentultra.com wrote: Jonathan Gardner jgard...@jonathangardner.net writes: On Jan 6, 12:24 pm, J Kenneth King ja...@agentultra.com wrote: Jonathan Gardner jgard...@jonathangardner.net writes: On Jan 6, 8:18 am, sturlamolden sturlamol...@yahoo.no wrote: On Jan 6, 4:32 pm, mark mark.fi...@googlemail.com wrote: I want to implement a internal DSL in Python. I would like the syntax as human readable as possible. Also beware that Python is not Lisp. You cannot define new syntax (yes I've seen the goto joke). This isn't really true. You can, for instance, write a program (in Python) that takes your pseudo-Python and converts it into Python. This is what a number of templating libraries such as Mako do. Which is not even close to being the same. Lisp - the program source is also the data format Python - the program source is a string I could go on a really long rant about how the two are worlds apart, but I'll let Google tell you if you're really interested. I get that Lisp is special because you can hack on the reader as it is reading the file in. This is strongly discouraged behavior, as far as I know, despite the number of cute hacks you can accomplish with it. It is generally discouraged unless there's a reason for it. But consider that this really isn't different than having a program read in the lisp-with-modification source and spitting out pure lisp, to be read by an honest-to-gosh lisp program later. If that's the case, then Lisp and Python really aren't that different in this regard, except that you don't have the option of modifying the reader as it reads in the file. I think you are missing the distinction. Lisp expressions are also data structures. A Lisp expression can be passed to functions and macros to be operated on before being executed. When you're writing Lisp source, you're basically looking at the AST on one level and when you start writing macros for your program, you're creating a DSL or interface to that AST. Lisp source is eventually expanded to a giant list that is consed by the evaluator (as far as I understand it. I'm just getting into the compiler stuff myself). Consider: (my-func 1 2 3) This is just a list, the primitive data-type in Lisp! This piece of data can be operated on by other bits of Lisp code because it is just a list as far as Lisp is concerned. In contrast, Python source is a string that needs to be parsed into bytecode which is then run through the interpreter. The AST is completely hidden from the source author. Python expressions are not data types either and hence no macros -- I can't write a python function that generates python code at compile time. I can only write a python program that parses some other string and generates code that can be run by another interpreter. Consider: for i in range(0, 100): do_something_interesting(i) That's a pretty straight forward Python expression, but I can't do anything with it -- it's not a unit of data, it's a string. The distinction is not subtle by any means. Ignoring reader macros for a moment, there is no way in either lisp, ruby, or python to change the syntax that the compiler understands, and the ability to work with your code directly as a data structure (which is what makes lisp macros powerful) isn't directly relevant to the idea of an internal' DSL. The OP wants a Ruby-style DSL by which he means something that lets me write words instead of expressions. The ruby syntax is amenable to this, python (and lisp, for that matter) syntax is not and you can't implement that style of internal DSL in those languages. The answer to the OP is you can't - use Ruby or modify your requirements. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is 3.0 worth breaking backward compatibility?
On Thu, Dec 11, 2008 at 12:21 PM, walterbyrd walterb...@iname.com wrote: On Dec 7, 12:35 pm, Andreas Waldenburger geekm...@usenot.de wrote: Plze. Python 3 is shipping now, and so is 2.x, where x 5. Python 2 is going to be around for quite some time. What is everybody's problem? A possible, potential, problem, could arise if you were using python 2.x, but some other code, that you wanted to include, was writen in python 3.x. A possible, potential, problem, could arise if you were using [Java], but some other code, that you wanted to include, was writen in [Pascal]. Surely the software industry is doomed? -- http://mail.python.org/mailman/listinfo/python-list
Re: Call by reference in SWIG?
On Thu, Dec 11, 2008 at 9:43 AM, Joe Strout j...@strout.net wrote: On Dec 10, 2008, at 10:19 PM, Nok wrote: I can't get call-by-reference functions to work in SWIG... Python doesn't have any call-by-reference support at all [1], so I'm not surprised that a straight translation of the call-by-reference C function doesn't work. Unfortunately I don't know enough about SWIG to suggest a work-around. Hopefully someone more versed in SWIG will have a bright idea. If you don't find anything in the Python space, you might try poking around in Java references, since Java has the same call semantics as Python. I'm not sure if SWIG has tools to do this for you or if you need to do the mapping by hand, but the usual idiom is to translate them into return values (keeping the original arg if the passed in value matters also). -- http://mail.python.org/mailman/listinfo/python-list
Re: Flushing PyQt's Event Queue
On Wed, Dec 10, 2008 at 6:30 AM, ff [EMAIL PROTECTED] wrote: Hi, I am writing an app which models growth of a system over time visually which is activated by button clicks, and when the loop finishes running i dont want any events [mainly clicking on buttons] that happened during the loop to be put into action since then it may run multiple times without the user realising what they have done, is there way to flush the event queue when the loop has finished?? This is a UI problem, not a programming problem. Instead of trying to find a code solution to the problem, consider changing your UI so that the actions aren't possible. For example, disable the buttons (perhaps showing by showing a progress dialog box with a cancel button) while the sim is running. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Tue, Dec 9, 2008 at 6:39 AM, Paul Boddie [EMAIL PROTECTED] wrote: On 9 Des, 05:52, alex23 [EMAIL PROTECTED] wrote: From my perspective, it was less the original complaint and more the sudden jump to CPython is dead! The GIL sucks! Academic eggheads! that prompted the comparisons to trolling. To be fair to the complainant, before mentioning the GIL, he did initially get the usual trite fragments of the Zen of Python right back at him (simple is better than complex, special cases aren't special enough to break the rules), albeit not the whole thing in its overused, unabridged form. I think I'd go on a rant if presented with that rather than the accepted reason for the noted shortcomings of the language: CPython's parsing technology isn't sufficiently powerful parser technology as GvR himself says [1]. Paul So hold up a second. I'm out of line for calling someone on making a trollish post that's not relevant to the topic, and for being pretty late to the party even with the part that *was* on topic, and for (even in the original post) going the ad-hominem route by not so subtly implying that Python is an ivory tower language that's not good enough for people with real problems - a clearly false statement by any standards, and doubly offensive from someone who *is* using it for real problems and who himself is a less than shining example of responsible software management, but the OPs lapse into ranting in response to trite but accurate answers to a question he could have answered for himself, in detail, had he bothered to read the threads from the time when the issue actually matter is a reasonable response that we should support and validate? Sometimes you're not a crusader for thinking differently and change by confrontation and speaking truth to power. Sometimes you're just an asshole. For clarification: The OPs original complaint is legitimate, if dated and partially his own fault. His phrasing of the problem, the tone and content of his email, and his lapse into flaming when he wasn't immediately hailed as a herald of sanity is not legitimate. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Wed, Dec 3, 2008 at 11:42 PM, Warren DeLano [EMAIL PROTECTED] wrote: Why was it necessary to make as a reserved keyword? I can't answer for the Python developers as to why they *did* make it a reserved word. But I can offer what I believe is a good reason why it *should* be a reserved word: Because simple is better than complex, and special cases aren't special enough to break the rules. So you prefer broken code to broken rules, eh? Your customers must love that! This is exactly the kind of ivory-tower thinking I feared might be behind the decision (form over function, damn the users to hell, etc.) remainder of creed skipped Honestly, based on the content and tenor of this post I think this is Yet Another Python Troll (the ivory tower reference, as well as the abrupt shift from complaining about keywords to multiprocessing), I have to point out that Python does add new keywords, it has done so in the past, and there was a considerable amount of warning, including an automated deprecation warning in the very version you are going to recommend to your customers' (I don't actually think you have any customers). If you suppressed or ignored the deprecation warning that all your code has been generating for at least 2 years it's pretty damn ballsy to come here and tell everyone how *Python* is doing something wrong. -- http://mail.python.org/mailman/listinfo/python-list
Re: as keyword woes
On Thu, Dec 4, 2008 at 8:45 AM, Steven D'Aprano [EMAIL PROTECTED] wrote: On Thu, 04 Dec 2008 20:53:38 +1000, James Mills wrote: Readability of your code becomes very important especially if you're working with many developers over time. 1. Use sensible meaningful names. 2. Don't use abbreviations. This is excellent advice, but remember, what is a sensible meaningful name is domain-specific. In a maths library, this would be sensible: def poly(x): return 4*x**3 -2*x**2 +3*x -7 and this ridiculous: def poly(real_number): return 4*real_number**3 -2*real_number**2 +3*real_number -7 I actually wonder. The former is sensible in a math context because there's a very long tradition in mathematics of using terse, inscrutable placeholders for terms. I'm not a mathematician and I don't know anything about the history of mathematical notation, but I'd guess this has something to do with the fact that maths has historically been done with a pencil and paper, and that terseness is an important quality when you have a limited canvas and lots of stuff to write. Aside from the cultural indoctrination, though (and that may be a real and strong force when dealing with math software, and I don't want to discount it in general, just for purposes of this discussion) why is it more sensible to use x here instead of number or real or real_number or something else? -- http://mail.python.org/mailman/listinfo/python-list
Re: To Troll or Not To Troll
On Thu, Dec 4, 2008 at 1:10 PM, Warren DeLano [EMAIL PROTECTED] wrote: Yet Another Python Troll (the ivory tower reference, as well as the abrupt shift from complaining about keywords to multiprocessing), I have to point out that Python does add new keywords, it has done so in the past, and there was a considerable amount of warning, including an automated deprecation warning in the very version you are going to recommend to your customers' (I don't actually think you have any customers). ROFL! I'm sorry, you're right -- this has all been a figment of my imagination... http://www.pymolwiki.org/index.php/Covers http://images.google.com/images?q=pymol So don't mind me -- I clearly don't know what I'm talking about. Peculiarities in usenet resulted in this discussion having several threads and I missed some messages before I wrote this email. So I apologize for calling you a troll, but only slightly - what you wrote had exactly the same content and tone that people who are intentionally trolling write every day. There are legitimate, interesting, and important discussions to be had about multithreading in Python, but nothing you wrote was of any use to any of them. I still would have to call your management of the problem considerably into question - your expertise at writing mathematical software may not be in question, but your skills and producing and managing a software product are. You have nobody at your organization, which sells a product that relies on Python, who follows python-dev? Or who even reads the changelogs for new python versions? You should have known about the as keyword change *over a year ago*, even if the import bug was masking the deprecation warning. Everything else aside, I can't get past that issue with your complaints. I *have* gone back now and read all the posts in all the threads and I still have not seen a single post from you even hinting that you might have any responsibility in the matter. Multithreading is a different discussion, and totally unrelated to the original complaint (which is why it's trolling, customers or not, to bring it up in this thread) and I'm not going to address it - everything of any interest in the conversation has been said already, and if you know enough to talk seriously about it you already know all the arguments on both sides. If you *don't* know them, a perusal of the python-dev and c.l.p archives should bring you up to speed easily. -- http://mail.python.org/mailman/listinfo/python-list
Re: To Troll or Not To Troll
On Thu, Dec 4, 2008 at 2:11 PM, Warren DeLano [EMAIL PROTECTED] wrote: I still would have to call your management of the problem considerably into question - your expertise at writing mathematical software may not be in question, but your skills and producing and managing a software product are. You have nobody at your organization, which sells a product that relies on Python, who follows python-dev? Or who even reads the changelogs for new python versions? You should have known about the as keyword change *over a year ago*, even if the import bug was masking the deprecation warning. Everything else aside, I can't get past that issue with your complaints. I *have* gone back now and read all the posts in all the threads and I still have not seen a single post from you even hinting that you might have any responsibility in the matter. Well then, let me set the record straight on that one point: I admit that it was entirely my mistake (and mine alone) to implicitly assume, by adopting such a logging persistence architecture (dating back to 1.5.2, mind you!), that new keywords would not be introduced into the Python language so as to potentially break all existing Python code. Silly me! How unreasonable. Pythons backwards compatibility policy is available here: http://www.python.org/dev/peps/pep-0005/ -- http://mail.python.org/mailman/listinfo/python-list
Re: using private parameters as static storage?
On Thu, Nov 13, 2008 at 10:25 PM, Steven D'Aprano
[EMAIL PROTECTED] wrote:
On Fri, 14 Nov 2008 13:35:02 +1100, Ben Finney wrote:
Instead, it looks like you're falling foul of one of the classic
mistakes in the How to ask questions the smart way document: you've
got a goal, but you're assuming that you need to use a specific tool to
get there. Instead, you're being shown that your assumption is false:
there's a better tool available to achieve your goal.
For the sake of the argument I will accept your characterization of Joe's
question. Even given that, you have still made an error: Joe hasn't been
shown that his assumption is wrong, he's merely had a bunch of people
declare, without evidence or even reason, that he is wrong. If anyone has
given any reason for avoiding the idiom that doesn't boil down to I
don't like it! (I need a smiley for pursed lips), I haven't read it.
I for one do not think he is wrong, and I have given reasons for
preferring the idiom:
def parrot(public_args, _cache={}) # or similar
for implementing caches and similar internal storage. It's quick, it's
easy, it's lightweight, and it exposes the cache to those who need it,
e.g. for testing.
If anyone has a *reason* why this idiom is harmful, please say so.
Repeating That's not the way to do it!!! Use an object!!! is not a
reason.
Without such a reason, then the decision whether or not to use a functor
(class with a __call__ method) in Python is a matter of personal taste.
Honestly given his attitude I don't think there's any reason to give
him the benefit of the doubt. Python doesn't have static storage - it
uses objects for the same purpose. Since anyone with the credentials
he's mentioned at least 3 times not only knew the history of OO
programming and how it addresses the same problems that people used
static storage to address, but also could have read one friggin python
tutorial and gotten all the answers he needed, I'm pretty much forced
to decide that he's either a troll or lazy.
Especially since in his email he gave no reason why just use a
fucking object isn't a good solution to the problem, and he still
hasn't.
This isn't an UberSpecialTypeFactoryInstance answer, if you'll forgive
me using an answer from a future email. There's a simple, obvious,
straightforward solution to the need to maintain state between
function calls.The entire idea of objects in programming was developed
to fill *exactly this need*.
And finally! You will note that in his email he asked for peoples
opinions and suggestions on how they solve this problem. I'd use an
object is a totally reasonable answer to the question he asked. Joe
seems to be pissed off that we didn't answer the question he didn't
ask, and we didn't respect articificial constraints that he didn't
fully express, and apparently that we don't all love RealBasic, which
he talks about a lot. So fuck that.
--
http://mail.python.org/mailman/listinfo/python-list
Re: using private parameters as static storage?
On Thu, Nov 13, 2008 at 11:16 AM, Joe Strout [EMAIL PROTECTED] wrote: One thing I miss as I move from REALbasic to Python is the ability to have static storage within a method -- i.e. storage that is persistent between calls, but not visible outside the method. I frequently use this for such things as caching, or for keeping track of how many objects a factory function has created, and so on. Today it occurred to me to use a mutable object as the default value of a parameter. A simple example: def spam(_count=[0]): _count[0] += 1 return spam * _count[0] spam() 'spam ' spam() 'spam spam ' This appears to work fine, but it feels a little unclean, having stuff in the method signature that is only meant for internal use. Naming the parameter with an underscore _count makes me feel a little better about it. But then, adding something to the module namespace just for use by one function seems unclean too. What are your opinions on this idiom? Is there another solution people generally prefer? Ooh, for a change I had another thought BEFORE hitting Send rather than after. Here's another trick: def spam2(): if not hasattr(spam2,'count'):spam2.count=0 spam2.count += 1 return spam2 * spam2.count This doesn't expose any uncleanliness outside the function at all. The drawback is that the name of the function has to appear several times within itself, so if I rename the function, I have to remember to change those references too. But then, if I renamed a function, I'd have to change all the callers anyway. So maybe this is better. What do y'all think? Static storage is a way of preserving state. Objects are a way of encapsulating state and behavior. Use an object. -- http://mail.python.org/mailman/listinfo/python-list
Re: Avoiding local variable declarations?
On Thu, Nov 13, 2008 at 2:22 PM, dpapathanasiou [EMAIL PROTECTED] wrote: I have some old Common Lisp functions I'd like to rewrite in Python (I'm still new to Python), and one thing I miss is not having to declare local variables. For example, I have this Lisp function: (defun random-char () Generate a random char from one of [0-9][a-z][A-Z] (if ( 50 (random 100)) (code-char (+ (random 10) 48)) ; ascii 48 = 0 (code-char (+ (random 26) (if ( 50 (random 100)) 65 97) ; ascii 65 = A, 97 = a My Python version looks like this: def random_char (): '''Generate a random char from one of [0-9][a-z][A-Z]''' if random.randrange(0, 100) 50: return chr( random.randrange(0, 10) + 48 ) # ascii 48 = 0 else: offset = 65 # ascii 65 = A if random.randrange(0, 100) 50: offset = 97 # ascii 97 = a return chr( random.randrange(0, 26) + offset ) Logically, it's equivalent of the Lisp version. But is there any way to avoid using the local variable (offset) in the Python version? Any time you port between languages, it's rarely a good idea to just convert code verbatim. For example: import random, string def random_char(): return random.choice(string.ascii_letters + string.digits) -- http://mail.python.org/mailman/listinfo/python-list
Re: Error importing wxPython
On Thu, Nov 6, 2008 at 8:09 AM, [EMAIL PROTECTED] wrote: Hi, I just installed wxPython from http://wxpython.org/download.php. When I import (import wx), I get this error: ImportError: DLL load failed: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log for more detail. Has anyone had this problem and how can I resolve it? Thanks in advance. downloading and installing this package should fix the problem: http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BFdisplaylang=en -- http://mail.python.org/mailman/listinfo/python-list
Re: Quality control in open source development
On Wed, Oct 8, 2008 at 10:43 AM, Dave [EMAIL PROTECTED] wrote: With the open source licenses that allow redistribution of modified code, how do you keep someone unaffiliated with the Python community from creating his or her own version of python, and declaring it to be Python 2.6, or maybe Python 2.7 without any approval of anyone at the PSF? Maybe their code is terrible, and not even compatible with the rest of Python! In some projects, there's trademarks on the project name (for example, Linus owns the Linux trademark), so you can mitigate confusion that way. I don't know if the PSF owns the Python trademarks or not. You can't stop them from forking and releasing their own code, even if it's really bad. That's freedom for you. How can the PSF, for example, maintain the quality and coheren of new code contributed to be part of Python, or derivative works that claim to be some future version of Python? If licensees can redisribute as they like, isn't this a huge problem? I think it's pretty self-evident that it's not a huge problem, don't you? Do you see lots of low quality python forks cluttering up the internet? Is this dealt with be restricting use of the Python trademarks? Just curious.. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: questions from a lost sheep
On Thu, Oct 2, 2008 at 2:22 PM, Joe Strout [EMAIL PROTECTED] wrote: Hi all, I used to by a big Python fan, many years ago [1]. I stopped using it after discovering REALbasic, because my main developmental need is to write desktop applications that are as native as possible on each platform, and because I really like a strongly-typed language with a good IDE. At the time (circa 2000), Python just didn't cut the mustard in this regard. (Indeed, none of the standard cross-platform C libraries -- Tk, QT, wxWidgets -- worked worth a darn on the Mac, at least at that time.) But REALbasic is a commercial, closed-source project with a small development team, and I find myself consistently frustrated by quality issues (read bugs). I've started to think fondly of the rock-solid stability of Python, and have been wondering if perhaps aggressive unit testing could mitigate most of the problems of weak typing. But that still leaves the other issue: creating high-quality desktop apps that look and feel just as good to users as anything written in the standard tools for each platform (Cocoa, .NET, etc.). REALbasic still does a great job of that (when it works at all). What's the state of the art in desktop app development in Python these days? Also, apart from simply searching with Google, is there anyplace I could go to find a good Python contractor to build a cross-platform desktop app demo? Many thanks, - Joe wxPython and Qts Mac support are leaps and bounds ahead of what they were in 2000, I would strongly suggest giving them another look. I know several that people in the wx community do contract work (or even just in bounties, if there are toolkit issues you'd like solved), take a look at wxwidgets.org for that. There's also the Python job board at python.org. -- http://mail.python.org/mailman/listinfo/python-list
Re: Linq to Python
On Wed, Sep 24, 2008 at 2:11 PM, [EMAIL PROTECTED] wrote: sturlamolden: No, because Python already has list comprehensions and we don't need the XML buzzword. LINQ is more than buzzwords. Python misses several of those features. So maybe for once the Python crowd may recognize such C# feature as much better than things present in Python. Said that, I presume Python will go on as usual, and LINQ-like capabilities will not be integrated in Python. In the meantime where I live lot of people will keep using C# instead of Python and CLisp, natural selection at work indeed. Why do you swing so widely between being an interesting poster with interesting, useful things to say and mindless trolling? There's a lot of reasons to use C# instead of Python or Lisp (or any other language for that matter), but I can't imagine that someone would make that decision based solely on LINQ. I'd go so far as to say that if they do, I question their professional competence. LINQ is an interesting implementation of an old idea. The place where it differs from list comps is that it has appropriate hooks for the specific linq implementation to override the way results are gathered, and such hooks in Python would be an interesting idea. I've taken a shot and figuring out where and how they should be implemented, but I haven't come up with anything I like. Maybe you should try it? LINQs native object API (not the syntax sugar available in C#) is not very different from Python ORMs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Are dictionaries the same as hashtables?
On Tue, Aug 26, 2008 at 11:12 AM, Fredrik Lundh [EMAIL PROTECTED] wrote: Martin Marcher wrote: Are dictionaries the same as hashtables? Yes, but there is nothing in there that does sane collision handling like making a list instead of simply overwriting. are you sure you know what collision handling means in this context? I think the confusion comes from thinking that dictionaries are (really) hash tables and thus that things like collision handling are exposed to the user of the data structure. In this sense, no, dictionaries are *not* hash tables. They are mappings of keys to values, and they use hash tables as part of their implementation. -- http://mail.python.org/mailman/listinfo/python-list
Re: exception handling in complex Python programs
On Tue, Aug 19, 2008 at 12:19 PM, eliben [EMAIL PROTECTED] wrote: Python provides a quite good and feature-complete exception handling mechanism for its programmers. This is good. But exceptions, like any complex construct, are difficult to use correctly, especially as programs get large. Most of the issues of exceptions are not specific to Python, but I sometimes feel that Python makes them more acute because of the free-n- easy manner in which it employs exceptions for its own uses and allows users to do the same. Lots of people seem to have this fear. They treat exceptions like they would treat error codes, trying to handle any possible case around any particular call. This is the wrong thing to do, and it only leads to more fragile code. There are only 2 reasonable things to do with an exception: 1) handle it, by which I mean catch the exception knowing what error condition it signifies, and take an appropriate action to correct the error and 2) pass it up so something else has a chance at it. Catching an exception when you don't know exactly what to do to fix it is an error. At best, it will make debugging a program harder (because you're losing context information about the error) and at worst it adds bugs to your program. The way Javas checked exceptions encourage empty or otherwise useless exception handlers is a major problem with them. There's some fear about presenting exceptions to the end user. That's a user interface issues, not a software quality or engineering issue, and it's resolvable with top-level handlers that log tracebacks somewhere a user can't see them if desired. Now, what do I mean more specifically... When a program starts growing large, I find myself a bit scared of all the exceptions that might be thrown: Python's exceptions as a result of runtime-detection of errors (Python's dynamic typing also comes into play here), exceptions from libraries used by the code, and exceptions from my lower-level classes. Python doesn't allow to specify which exceptions are thrown (C++'s feature adding 'throw' after a function/method declaration specifying the exceptions that can be thrown), and this leaves me at loss - what should be caught and where ? Which errors should be left to propagate ? You should catch anything that you can correct. If you don't have a specific answer for a specific exception, don't catch it. I've tried looking around the Python blogosphere, but there doesn't seem to be much concern with this topic. Apologies for the not-too-coherent post, but I suspect you feel the pain too and can understand my meaning. Eli P.S. There's a common case where a method is passed a filename, to do something with a file (say, read data). Should the method catch the errors possibly thrown by open(), or leave it to the caller ? Same rules apply. The only sort-of exception (no pun intended) is that sometimes you want to re-raise as a different type of exception. Make sure that you preserve all of the original information (including the original traceback) if you do this. P.P.S. There's a great post on conditions (Common Lisp's exceptions) here: http://dlweinreb.wordpress.com/2008/03/24/what-conditions-exceptions-are-really-about/ Not really CL specific, and can apply to Python's exceptions. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Graphics Contexts and DCs explanations?
On Tue, Aug 19, 2008 at 1:16 PM, RgeeK [EMAIL PROTECTED] wrote: Experimenting with graphics in an app: it's AUI based with a few panes, one of which has a panel containing a few sizers holding UI elements. One sizer contains a panel that needs some basic line-drawing graphics in it. I use the wxPython demo app heavily to figure this stuff out, and my experiments seem to work, but I'm flying blind somewhat. Can someone englighten me about the wx.GraphicsContext versus wx.PaintDC (BTW what does PaintDC stand for? Drawing Context perhaps?) The scrolledWindow and GraphicsContext examples are helpful, but it appears I can draw a rectangles, lines and text in either just a straight wxPaintDC, or can do: dc = wx.PaintDC(self) gc = wx.GraphicsContext.Create(dc) ...and do the same drawing with gc.DrawText etc... Can someone clarify the differences or added value of the gc over the dc, and is using the dc alone a valid approach? Where will it end up biting me - I don't mean which body part :) Perhaps I should say in which situation will it bite... This is probably better suited to the wxPython ML instead of c.l.p, because it's so specific. In short: wxDC (and friends) are traditional raster based drawing contexts. wxGraphicsContext is a vector/path based API. If you're doing drawing that's suited for a vector format (like line drawing probably is), using wxGraphicsContext will give you better image quality as well as the general vector features like free scaling, rotation, transforms, etc, -- http://mail.python.org/mailman/listinfo/python-list
Re: benchmark
On Thu, Aug 7, 2008 at 8:12 AM, alex23 [EMAIL PROTECTED] wrote: On Aug 7, 8:08 pm, [EMAIL PROTECTED] wrote: Really how silly can it be when you suggest someone is taking a position and tweaking the benchmarks to prove a point [...] I certainly didn't intend to suggest that you had tweaked -anything- to prove your point. I do, however, think there is little value in slavishly implementing the same algorithm in different languages. To constrain a dynamic language by what can be achieved in a static language seemed like such an -amazingly- artificial constraint to me. That you're a fan of Python makes such a decision even more confusing. It's great that you saw value in Python enough to choose it for actual project work. It's a shame you didn't endeavour to understand it well enough before including it in your benchmark. As for it being disappointing, the real question is: has it been disappointing for you in actual real-world code? Honestly, performance benchmarks seem to be the dick size comparison of programming languages. - I actually think that modelling this problem the way he chose to, with a Person class and by manually popping stuff out of a linked list instead of more simply representing the alive/dead state of the soldiers is a poor solution in general. Whenever you talk about performance, you need to have a context to evaluate it in and you need an idea of what you're trying to measure and why it's important for your purposes. A solution which models the soldiers as bits in a bitfield is going to run much, much, much faster in C/C++/D than the current OO/linked list one (not to mention in much less space), and the JIT in Java/C# and probably python with psyco can improve that as well. -- http://mail.python.org/mailman/listinfo/python-list
Re: benchmark
On Thu, Aug 7, 2008 at 9:09 AM, Steven D'Aprano [EMAIL PROTECTED] wrote: On Thu, 07 Aug 2008 06:12:04 -0700, alex23 wrote: On Aug 7, 8:08 pm, [EMAIL PROTECTED] wrote: Really how silly can it be when you suggest someone is taking a position and tweaking the benchmarks to prove a point [...] I certainly didn't intend to suggest that you had tweaked -anything- to prove your point. I do, however, think there is little value in slavishly implementing the same algorithm in different languages. To constrain a dynamic language by what can be achieved in a static language seemed like such an -amazingly- artificial constraint to me. I don't know about that... it can be very useful to (say) demonstrate that Lisp-style lists are fast in Lisp, and slow in Python. Or that try...except is fast in Python, and slow in Java. That's true, but note that the original post doesn't attempt to draw any conclusions about what's fast or slow from the benchmark, which is one reason why it's a poor example of benchmarking. And if your aim is to compare languages, then it's only fair to keep the algorithm constant. Imagine how we would holler and shout if the benchmark compared Ruby using Quicksort and Python using Bubblesort. That's definitely true, and (for example) the Alioth benchmarks are intended to benchmark specific algorithms for comparisons sake. I guess what some of us are complaining about is that the algorithm chosen doesn't suit Python's execution model very well, and hence Python is slow. If the algorithm chosen had suited Python, and hence Python came up looking really fast, we'd be ecstatic. How about that, hey? *wink* The best way to implement this problem, as bitfield manipulation, would actually show python in even worse light. I suspect the main thing that this benchmark is actually testing is loop overhead, and secondarily object allocation speed. Python is pretty slow in the former and reasonable in the latter, so I don't find the results very surprising at all. ... Honestly, performance benchmarks seem to be the dick size comparison of programming languages. I can't disagree with that one bit. As with genitals, the important thing about benchmark comparison is what you're going to do with the results. -- Steven -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: interpreter vs. compiled
On Tue, Aug 5, 2008 at 12:12 PM, castironpi [EMAIL PROTECTED] wrote:
On Aug 5, 9:21 am, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
On Aug 3, 1:26 am, castironpi [EMAIL PROTECTED] wrote:
Which is 12 bytes long and runs in a millisecond. What it does is set
a memory address to successive integers 0..9, then yields. Due to the
nature of program flow control, while it runs its first steps on any
x86 machine, the yield only succeeds if on Windows 98+, and crashes
the machine, or otherwise loses control if not. (That part depends on
those OSses.)
I can try something similar dynamically.
char* mem= alloc( 48 )
setpermission( mem, EXECUTE )
memcpy( mem+ 0, \x09\x0f\x00\x00, 4 )
for( int x= 0; x 10; ++x ) {
memcpy( mem+ 4* (x+ 1 ), '\x04\xA0\x00\x00', 4 )
mem[ 4* (x+ 1 )+ 3 ]= (char) x
memcpy( mem+ 44, '\x01\x20\x00\x01', 4 )
setjump
goto mem
Which with some imagination produces the contents of 'abinary.exe'
above (one difference, last word) in a memory block, at address 'mem',
then jumps to it, which then jumps back, and then exits. /fiction
I'll compare a C complation to the first example, 'abinary.exe', and a
JIT compilation to the second example, 'char* mem'. If the comparison
isn't accurate, say how, because these are places I can start from...
(yes, that is, instead of just repeating the claims).
When does a JIT do this, and what does it do in the meantime?
The JIT works like an assembler/linker that writes to memory. It will
load the
file(s) containing the bytecode and generate the required assembly
instructions into
memory.
In the case there are dependencies to other modules, they will be
loaded as well, and
compiled. Then the linker will take care that cross references between
modules are correct,
like memory addresses and branch targets.
So far this is the same as any compilation, except the first half is
done, and the output location, which is not any bottleneck.
A clever JIT might add instrumentation points, so that it can rewrite
the code using profile
guided optimizations, this means generating optimized code using as
input the program behaviour.
This makes JIT code usually faster than normal compiled code.
Here you need an example. You are suggesting that a compiler can make
better optimizations if it knows what functions are going to carry
what loads, run how many times, etc., and it can use profile
statistics as a partial indicator to do that.
Although
normal native code is
able to start executing faster, it only targets a specific set of
processors.
JIT code is independent of the processor, and a good JIT
implementation is able to explore the
processor better than a direct native compiler. There is however the
time penalty on program
startup.
Once again, you are asserting that knowing what the program has done
so far, say in the first 5 seconds ( or .5 ), can improve
performance. In this case it can make better use of what instructions
to use on the CPU. I need an example.
--
http://mail.python.org/mailman/listinfo/python-list
Is there a reason why you're expecting c.l.p to be your personal tutor
for Introduction to Compilers?
It's not that I want to dissuade you in your quest for
self-betterment, but you're being extremely confrontational as well as
vastly ignorant about terminology. Defining your own terms that don't
agree with formal definitions and then demanding (not even politely
asking, for goodness sake) that people justify to you, in excruciating
detail, why simple concepts are true is simply an inexcusable way to
behave.There seems to be something of a rash of this on c.l.p lately.
JIT has been around for decades now, it's well documented, well
understood, and quite common. You'd learn enough to answer every
single one of your demands in 20 minutes with Google, and if you're
seriously going to continue to argue that JIT doesn't exist (and this
is even granting your own bizarre definition of compile, which may as
well be called purplizing) you should be able to argue from a
position of knowledge instead of stunning, jaw dropping, soul
shattering ignorance.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Boolean tests [was Re: Attack a sacred Python Cow]
On Tue, Jul 29, 2008 at 3:37 AM, Carl Banks [EMAIL PROTECTED] wrote: On Jul 28, 8:15 pm, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: On Mon, 28 Jul 2008 13:22:37 -0700, Carl Banks wrote: On Jul 28, 10:00 am, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: Cutting to the crux of the discussion... On Sun, 27 Jul 2008 23:45:26 -0700, Carl Banks wrote: I want something where if x will do but a simple explicit test won't. Explicit tests aren't simple unless you know what type x is. If x could be of any type, you can't write a simple test. Does x have a length? Is it a number? Maybe it's a fixed-length circular length, and the length is non-zero even when it's empty? Who knows? How many cases do you need to consider? Use case, please. I'm asking for code, not arguments. Please give me a piece of code where you can write if x that works but a simple explicit test won't. I gave you a piece of code, actual code from one of my own projects. If you wouldn't accept that evidence then, why would you accept it now? I would accept as evidence something that satisfies my criteria, which your example did not: it could have easily (and more robustly) been written with a simple explicit test. I am looking for one that can't. You keep bringing up this notion of more complex with no benefit, which I'm simply not interested in talking about that at this time, and I won't respond to any of your points. I am seeking the answer to one question: whether if x can usefully do something a simple explicit test can't. Everyone already knows that if x requires fewer keystrokes and parses to fewer nodes. I'm really not sure where you're going with this or what you're trying to prove. if x is a duck-type test for a boolean value. Obviously if you know the type and want a more *specific* test, then you can use an explicit one. Any time you don't know or don't care about a more specific type than something which probably is boolean true, or any time where you know the boolean semantics of the type and want to drop some typing, you can use if x. The more specific test is what you'd use if you want more specific results. What's complicated about this idea? -- http://mail.python.org/mailman/listinfo/python-list
Re: Function References
On Thu, Jul 31, 2008 at 10:27 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Jul 31, 10:47 am, Diez B. Roggisch [EMAIL PROTECTED] wrote: I take the freedom to do so as I see fit - this is usenet... Fine, then keep beating a dead horse by replying to this thread with things that do nobody any good. It seems like there are a lot better way to waste time, though. The Python/C API can get me back further without reliance on third- party libraries than ctypes. It also isn't subject to the quirks that ctypes is on platforms other than Windows (the target application runs on Windows, Mac, and eventually Linux once the original distributor has drivers for the device). I'm not even sure ctypes could load the lib/driver the distributor packaged. Ctypes works fine on many platforms. Since you didn't even know about ctypes until you were told about it, don't you think it's a little premature to be speculating about problems you haven't actually experienced? So really, I appreciate the option in ctypes, it's good stuff. But it's not for this project. It's actually perfectly suited, but you're (I'm assuming) and adult and can make your own decisions... Once again, the original question stands for anyone who has experience with the Python/C API callbacks. -- If you know how to write a callback in C, you know how to do it with Python/C. It's not real flexible if the callback API you're using doesn't include user data, and it looks like it doesn't. Ctypes can generate dynamic thunks and therefore will let you use any Python object as a callback. It's a lot more flexible and it's a lot easier to not write your own thunk generation in C. -- http://mail.python.org/mailman/listinfo/python-list
Re: x, = y (???)
On Thu, Jul 17, 2008 at 2:55 PM, kj [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED] Erik Max Francis [EMAIL PROTECTED] writes: kj wrote: I just came across an assignment of the form x, = y where y is a string (in case it matters). 1. What's the meaning of the comma in the LHS of the assignment? It's unpacking a 1-tuple: (x,) = y The parentheses here are not necessary and are sometimes left out. I still don't get it. If we write y = 'Y' x, = y what's the difference now between x and y? And if there's no difference, what's the point of performing such unpacking? TIA! y = (1,) y (1,) x, = y x 1 -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug in floating-point addition: is anyone else seeing this?
On Wed, May 21, 2008 at 3:56 PM, Dave Parker [EMAIL PROTECTED] wrote: On May 21, 2:44 pm, Jerry Hill [EMAIL PROTECTED] wrote: My understand is no, not if you're using IEEE floating point. Yes, that would explain it. I assumed that Python automatically switched from hardware floating point to multi-precision floating point so that the user is guaranteed to always get correctly rounded results for +, -, *, and /, like Flaming Thunder gives. Correct rounding and accurate results are fairly crucial to mathematical and scientific programming, in my opinion. -- If you're going to use every post and question about Python as an opportunity to pimp your own pet language you're going irritate even more people than you have already. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug in floating-point addition: is anyone else seeing this?
On Wed, May 21, 2008 at 4:29 PM, Dave Parker [EMAIL PROTECTED] wrote: On May 21, 3:17 pm, Chris Mellon [EMAIL PROTECTED] wrote: If you're going to use every post and question about Python as an opportunity to pimp your own pet language you're going irritate even more people than you have already. Actually, I've only posted on 2 threads that were questions about Python -- this one, and the one about for-loops where the looping variable wasn't needed. I apologize if that irritates you. But maybe some Python users will be interested in Flaming Thunder if only to check the accuracy of the results that they're getting from Python, like I did on this thread. I think most people will agree that having two independent programs confirm a result is a good thing. -- Please don't be disingenuous. You took the opportunity to pimp your language because you could say that you did this right and Python did it wrong. When told why you got different results (an answer you probably already knew, if you know enough about IEEE to do the auto-conversion you alluded to) you treated it as another opportunity to (not very subtly) imply that Python was doing the wrong thing. I'm quite certain that you did this intentionally and with full knowledge of what you were doing, and it's insulting to imply otherwise. You posted previously that you wrote a new language because you were writing what you wanted every other language to be. This is very similar to why Guido wrote Python and I wish you the best of luck. He was fortunate enough that the language he wanted also happened to be the language that lots of other people wanted. You don't seem to be so fortunate, and anti-social behavior on newsgroups dedicated to other languages is unlikely to change that. You're not the first and you won't be the last. -- http://mail.python.org/mailman/listinfo/python-list
Re: Thread killing - I know I know!
On Mon, May 19, 2008 at 11:36 AM, Roger Heathcote [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On May 16, 11:40 am, Roger Heathcote [EMAIL PROTECTED] wrote:snip Despite many peoples insistence that allowing for the arbitrary killing of threads is a cardinal sin and although I have no particular threading problem to crack right now I remain interest in the taboo that is thread killing. The real world and it's data are messy and imperfect and I can snip In general, use processes when you can and threads only when you must. OS designers spent a lot of energy implementing protected memory, no sense throwing out a fair chunk of that hard work unless you actually need to. Fair point, but for sub processes that need to be in close contact with the original app, or very small functions that you'd like 100s or 1000s of it seems like a kludge having to spawn whole new processes build in socket communications and kill via explicit OS calls. I can't see that approach scaling particularly well but I guess there's no choice. It's not a kludge - the whole reason why killing a thread is undefined and a cardinal sin is because it's in your own address space and you can't guarantee anything about how it left things when you killed it. You simply can't have it both ways. If you want to be able to safely and sanely kill an uncooperative thread (*especially* third party code you don't control) you have to isolate it from your address space, and this means a process. This is a fundamental problem with the entire idea of shared-state concurrency. For the record, you can't use 1000s of threads either - if you really need 1000s of concurrent things running you need to re-think your concurrency model and possibly your choice of languages and environment. The messiness of the real world is *why* you should use processes, not a reason to avoid them. Does anyone think it likely that the threading module (and threading in general) will be improved and augmented with features like timeouts and arbitrary threadicide in the next year or two? Seems there's little scope for tapping the power of the current generation of multiple cores with the current pythons, tho I appreciate breakneck speed has never been a design objective it looks like multicore is set to be the next generation PC architecture. They absolutely should not be. Adding an API which can't work in the general case and is dangerous even when it can work does not do anyone any favors. Roger Heathcote - technicalbloke.com -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: py3k s***s
On Wed, Apr 16, 2008 at 11:40 AM, Aaron Watters [EMAIL PROTECTED] wrote: On Apr 16, 12:27 pm, Rhamphoryncus [EMAIL PROTECTED] wrote: On Apr 16, 6:56 am, Aaron Watters [EMAIL PROTECTED] wrote: I don't get it. It ain't broke. Don't fix it. So how would you have done the old-style class to new-style class transition? I'd ignore it. I never understood it and never had any need for it anyway. New-style classes and metaclasses were a complicated solution to an unimportant problem in my opinion. And also a fiendish way to make code inscrutible -- which I thought was more of a Perl thing than a Python thing, or should be. I must be missing some of the deeper issues here. Please educate me. Since you don't care about any of the changes or features, and you don't care if your users care, I'm not sure why you aren't just using python 2.1. It's not like it's being erased via time machine. Just keep using the old thing is a perfectly valid and extremely common futureproofing scenario. -- http://mail.python.org/mailman/listinfo/python-list
Re: Rationale for read-only property of co_code
On Wed, Apr 2, 2008 at 2:33 PM, João Neves [EMAIL PROTECTED] wrote: On Apr 2, 5:41 pm, Dan Upton [EMAIL PROTECTED] wrote: The thing I've been wondering is why _is_ it read-only? In what circumstances having write access to co_code would break the language or do some other nasty stuff? João Neves I can't speak to Python's implementation in particular, but self-modifying code in general is unpleasant. It certainly is possible to support it in runtime environments, but it's usually not easy to do so. That is, of course, somewhat dependent on the implementation of the runtime environment, and even to some degree the underlying hardware. (For instance, the compiled code you want to run could be in the hardware cache; if you then change the instructions at those addresses in memory, it's not always straightforward to get the processor to realize it needs to load the new data into the instruction cache.) Plus, I suppose it might be possible to break strong (even dynamic) typing if you start changing the code around (although I can't construct an example off the top of my head). Indeed, the caching issue is a relevant one I guess, and adding the mechanism to go around that might have a significant impact on performance. I haven't looked in detail into it, but I agree with your opinion concerning strong and dynamic typing. If type check is done while compiling to bytecode, there is no guarantee the modified bytecode will respect the rules, for instance. I don't know though, haven't really checked how it's done at this point. :) I will be fiddling around with the Python VM these days anyway, and since I'm going to muck around the bytecode, I might just try to see the effects of removing the read-only restriction from co_code. There is no need to overwrite co_code. Create a new code object with your desired bytecode and use that instead. -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help calling a proprietary C DLL from Python
On Thu, Mar 20, 2008 at 3:42 PM, Craig [EMAIL PROTECTED] wrote: On Mar 20, 2:38 pm, Craig [EMAIL PROTECTED] wrote: On Mar 20, 2:29 pm, sturlamolden [EMAIL PROTECTED] wrote: On 20 Mar, 19:09, Craig [EMAIL PROTECTED] wrote: The culprit i here: Before - X = 0, CacheSize = 0, OpenMode = 3, vHandle = 0 This binds these names to Python ints, but byref expects C types. Also observe that CacheSize and OpenMode should be c_short. I changed CacheSize and OpenMode to c_short, and commented out that line producing the Before message, and the output is the same. Further tinkering revealed that it is the byref on the fName and pw that are causing the error. The entire problem appears to be around the production of a BSTR and the passing of pointers (byref) to the BSTR. Can anyone shed some light on how to work with BSTR's? Since you didn't tell ctypes about the function signature, it assumes it returns int and gives you a python int. Provide a function signature (c_void_p should work for BSTR) for both functions and you should have an easier time of it. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Fast 2D Raster Rendering with GUI
On Tue, Mar 18, 2008 at 12:30 PM, sturlamolden [EMAIL PROTECTED] wrote:
On 18 Mar, 17:48, Miki [EMAIL PROTECTED] wrote:
Apart from PIL, some other options are:
1. Most GUI frameworks (wxPython, PyQT, ...) give you a canvas object
you can draw on
Yes, but at least on Windows you will get a GDI canvas. GDI is slow.
Of all the major platforms, GDI is probably the fastest for basic
pixel-level interaction with the screen. I have no idea why you think
it's slow.
2. A bit of an overkill, but you can use PyOpenGL
OpenGL gives you a fast 'bitblit' for drawing bitmaps to the fram
buffer (much faster than GDI). Here is some C code that does that (8-
bit color depth). Translating to Python is trivial. I prefer not to
use PyOpenGL as it has some unwanted overhead. It is better to use
ctypes.
void bitblt(void *frame, int w, int h)
{
glViewport(0,0,w,h);
glClearColor(0.0, 0.0, 0.0, 0.0);
glClear(GL_COLOR_BUFFER_BIT);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluOrtho2D(0.0, (GLfloat)w, 0.0, (GLfloat)h);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glRasterPos2i(0,0);
glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
glDrawPixels(w, h, GL_RGB, GL_UNSIGNED_BYTE_3_3_2, (GLvoid *)frame);
glFlush();
}
OpenGL is totally unsuitable if the goal is to implement your own
pixel-level raster drawing.
--
http://mail.python.org/mailman/listinfo/python-list
Re: wxPython graphics query (newbie)
On Mon, Mar 17, 2008 at 7:03 AM, Thomas G [EMAIL PROTECTED] wrote: I am exploring wxPython and would be grateful for some help. It is important to me to be able to slide words and shapes around by dragging them from place to place. I don't mean dragging them into a different window, which is what 'Drag and Drop' has come to mean, just moving them around within a canvas-like space. This is easy using Tkinter. Can anybody offer me a tiny, very simple example of how it would be done in wxPython, please? To make sure I convey what I'm looking for, here is what it looks like using Tkinter, written very simply. What I'm looking for is the same, quite simple functionality expressed in wxPython, again written very simply so that I can easily understand it. See the floatcanvas and OGL examples in the wxPython demo. -- http://mail.python.org/mailman/listinfo/python-list
Re: Attribute Doesnt Exist ... but.... it does :-s
On Thu, Mar 13, 2008 at 10:36 AM, Robert Rawlins [EMAIL PROTECTED] wrote: Hello Guys, I've got an awfully aggravating problem which is causing some substantial hair loss this afternoon J I want to get your ideas on this. I am trying to invoke a particular method in one of my classes, and I'm getting a runtime error which is telling me the attribute does not exist. I'm calling the method from within __init__ yet it still seems to think it doesn't exist. Code: # Define the RemoteDevice class. class remote_device: # I'm the class constructor method. def __init__(self, message_list=): self.set_pending_list(message_list) def set_pending_list(self, pending_list): # Set the message list property. self.pending_list = message_list And the error message which I receive during the instantiation of the class: File: /path/to/my/files/remote_device.py, line 22, in __init__ self.set_pending_list(message_list) AttributeError: remote_device instance has no attribute 'set_pending_list' Does anyone have the slightest idea why this might be happening? I can see that the code DOES have that method in it, I also know that I don't get any compile time errors so that should be fine. I know it mentions line 22 in the error, but I've chopped out a load of non relevant code for the sake of posting here. Perhaps I'm missing something really simple, but it's got my head spinning. Create a copy of your source file, confirm that it shows the problem, and start chopping out lines until all that is left is what you pasted here. See if it still shows the problem. If it does, and if you haven't found the problem yet, post again, attaching (not pasting inline) your chopped down file. -- http://mail.python.org/mailman/listinfo/python-list
Re: wxPython/wxWidgets ok for production use ?
On Tue, Mar 11, 2008 at 11:01 AM, Stefan Behnel [EMAIL PROTECTED] wrote: Sion Arrowsmith wrote: And before you blame wx* for crashes: what platform was this on? Because my experience was that wx on GTK was significantly more prone to glitches than on Windows (through to wxglade being unusably crashy) -- if the underlying toolkit has problems, that's going to be reflected in wx. :) Interesting. This was actually on GTK. Although I would still blame at least the wxWidgets-GTK bindings here. I never had any problems with GTK in my life. Gtk is much more finicky than windows about the timingof when you can and cannot use certain functions. wxPython has checks in place for many of these functions so you get an exception instead of a crash, but not everything is safe (and of course in the past even fewer things were). In particular, you need to have a wxApp object safely constructed before you can use almost any gui object, which is not the case under Windows. wx makes the attempt to make correct code work correctly on platforms, but doesn't necessarily guarantee that incorrect code fails the same (or at all) on all platforms. This is an unavoidable compromise due to the nature of a layering toolkit like this, although figuring out what correct code actually is can take some experience. Stefan -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Obtaining the PyObject * of a class
On Tue, Mar 11, 2008 at 12:13 PM, Terry Reedy [EMAIL PROTECTED] wrote: Cooper, Andrew [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | Are there any Python C API experts/SWIG experts out there that can help | me with this issue please. | I',m currently using SWIG to generate a python interface to a C DLL. Some people have switched to using ctypes for this, and many other SWIG users have stopped reading clp. But I hope someone answers who can. Using Pyrex or Cython is likely to be much easier than using SWIG for this. -- http://mail.python.org/mailman/listinfo/python-list
Re: I cannot evaluate this statement...
On Fri, Mar 7, 2008 at 2:38 PM, waltbrad [EMAIL PROTECTED] wrote: The script comes from Mark Lutz's Programming Python. It is the second line of a script that will launch a python program on any platform. import os, sys pyfile = (sys.platform[:3] == 'win' and 'python.exe') or 'python' Okay, run on a win32 machine, pyfile evaluates to python.exe That makes sense. Because the first condition is true and 'python.exe' is true. So the next comparison is 'python.exe' or 'python' Well, python.exe is true. So that value is returned to pyfile. Now. Run this on linux. The first condition evaluates sys.platform[:3] == 'win' as false. So, the next comparison should be 'False' or 'python' -- This is because 'and' returns the first false value. But, again, on linux pyfile evaluates to python.exe Where am I going wrong. And when will this statment make pyfile evaluate to 'python' ? -- http://mail.python.org/mailman/listinfo/python-list In Python 2.5, this is written: pyfile = 'python.exe' if 'win' in sys.platform else 'python' However, this is a pretty bad way of doing this at all. sys.executable is better. I'm not sure when sys.executable was added but I assume it's more recent than whatever version Lutz used in his book. -- http://mail.python.org/mailman/listinfo/python-list
Re: Want - but cannot get - a nested class to inherit from outer class
On Fri, Mar 7, 2008 at 3:00 PM, DBak [EMAIL PROTECTED] wrote: I want - but cannot get - a nested class to inherit from an outer class. (I searched the newsgroup and the web for this, couldn't find anything - if I missed an answer to this please let me know!) I would like to build a class for a data structure such that nodes of the data structure - of interest only to the data structure implementation itself and not to the consumer - are instances of one of two class types. I thought to encapsulate the nodes' classes like this: class Tree(object): ...class _MT(Tree): ..def isEmpty(self): return True ..def insert(self, X): return Tree._Node(X) ...class _Node(Tree): ..def isEmpty(self): return False ..def insert(self, X): return _Node(X, self, Tree._MT()) ...def merge(self, T): ..def __init__(): return _MT() ..code for merging tree T into self In other words, some methods would be implemented on instances' classes (like isEmpty and insert) and some on the outer class (like merge). Users of the data structure never need to know about the nodes, much less the nodes' classes, so I wanted to encapsulate them However I can't do this, because, of course, the name Tree isn't available at the time that the classes _MT and _Node are defined, so _MT and _Node can't inherit from Tree. Not only is the name not defined, the class doesn't even exist yet. What is the Pythonic thing I should be doing instead? Don't nest them. The single underscore is all you need to keep any from using them (don't forget that even if your method worked, they'd be perfectly visible as attributes of the Tree class, or as the types of returned values). Worrying too much about visibility is a waste of time in Python. (Easy answer: Put this code in a module, exposing only a factory function. I could do that, but wanted to know if I could encapsulate it as described so I could actually put several similar data structures into one module.) There's no reason to use a factory function. If you do put them in a module, you can use __all__ to document your exports. As with all visibility issues in Python, this is advisory only - the only code it affects is the symbols that are exported by from module import *. -- http://mail.python.org/mailman/listinfo/python-list
Re: What does this bogus code in urlparse do?
On Mon, Feb 25, 2008 at 11:04 PM, John Nagle [EMAIL PROTECTED] wrote: See http://svn.python.org/view/python/trunk/Lib/urlparse.py?rev=60163view=markup; Look at urljoin. What does the code marked # XXX The stuff below is bogus in various ways... do? I think it's an attempt to remove leading ../ components in URLs, which are generally ignored. But it also does something with commas, and it's not clear why. John Nagle -- You should probably invest in syntax highlighting ;), it doesn't do anything with commas (just '.', '..' , and ''). It appears to be trying to normalize relative URLs into a single absolute one, as the docstring implies. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article of interest: Python pros/cons for the enterprise
On Fri, Feb 22, 2008 at 4:56 AM, Nicola Musatti [EMAIL PROTECTED] wrote: On Feb 22, 12:24 am, Carl Banks [EMAIL PROTECTED] wrote: On Feb 21, 1:22 pm, Nicola Musatti [EMAIL PROTECTED] wrote: There are other downsides to garbage collection, as the fact that it makes it harder to implement the Resource Acquisition Is Initialization idiom, due to the lack of deterministic destruction. That's not a downside: it's at least a wash. In C++ you manage memory and the language manages resources. In Python you manage resources and the language manages memory. RAII is merely one way of minimizing complexity. Garbage collection is another way. In C++ memory is just another resource which you can handle just like any other one, possibly using RAII. GC deals with memory very reasonably, but makes it more complicate to deal with other resources. There are many different kinds of resource and they have different optimal handling techniques. Memory in particular is really easily handled by GC - it's a resource that you can reclaim under pressure, so deferring it's collection and release makes sense, and it's even common these days for high quality GC to beat manual management in performance (never mind correctness). Other kinds of resource are much more timely, and require tight control over scopes, like mutexes and other locks. RAII is fantastic for these sort of things. Shared but limited resources like files work best with refcounting (closing a file that something else holds a reference to is usually an error). Optimally, you would have a language that provides all three in easy, transparent ways. Python only provides two, but the first on is the least important so Python manages at least a B. C++ provides all 3, but importantly there's no language level enforcement of use, so you can (and people do, and this is a common source of bugs) accidentally bypass the mechanisms. If I had to use C++ these days, I'd use D instead. -- http://mail.python.org/mailman/listinfo/python-list
Re: advanced usage of python threads
On Fri, Feb 22, 2008 at 12:32 PM, hyperboreean [EMAIL PROTECTED] wrote: Well, I will be writing the application server of a three-tier architecture system. I will be using Twisted for the communication with the client but from there I have to make several calls to a database and this asks threading. The tables will be filled by another system that gathers some data. I want to implement several threads (workers) that takes care of each client and a coordinator thread that takes care of all the threads. But I have never worked with threads at this level and I feel like I need some coordination. I will be thankful with documentation on advanced threads, I probably can apply that in practice. Thanks to all. Twisted has an asynchronous database API (built on top of threads) already. Look at twisted.enterprise.adbapi. -- http://mail.python.org/mailman/listinfo/python-list
Re: The big shots
On Tue, Feb 19, 2008 at 5:31 PM, Diez B. Roggisch [EMAIL PROTECTED] wrote: May I insist? By the criteria you've mentioned so far, nothing rules out 'ext'. If it's still a bad idea, there's a reason. What is it? You imply that just because something is somehow working and even useful for a *some* people (some being maybe only you) that it would be worth including in the python standard lib. It is not. There are no really formal rules for inclusion, but these are certainly rules of thumb that are being considered: - is it useful for *a lot of people* - will it be mantained and maintainable for ever once it is part of the standard distribution - does it introduce external dependencies? If yes, this must be *very* carful considered. - is the design well-thought and mature - does it make sense tying the release cycle of python the cycle of the new lib And insulting the people who do work on python and do a marvellous job doing so is certainly *not* helping. And of course if ext was a good idea, we'd use Weave from scipy instead, which exists and works. -- http://mail.python.org/mailman/listinfo/python-list
Re: how to find current working user
On Feb 11, 2008 12:30 PM, Gabriel Genellina [EMAIL PROTECTED] wrote: En Mon, 11 Feb 2008 15:21:16 -0200, Praveena Boppudi (c) [EMAIL PROTECTED] escribi�: Can anyone tell me how to find current working user in windows? If it is just informational, use os.environ['USERNAME'] Using win32wnet (from the pywin32 package): py import win32wnet py win32wnet.WNetGetUser() 'gabriel' Using stdlib only: import getpass;getpass.getuser() -- http://mail.python.org/mailman/listinfo/python-list
Re: Python GUI toolkit
On Feb 4, 2008 9:19 AM, [EMAIL PROTECTED] wrote: Another toolkit you might look into is Tkinter. I think it is something like the official toolkit for python. I also think it is an adapter for other toolkits, so it will use gtk widgets on gnome, qt widgets on kde and some other strange widgets on windows. Not t so, AFAIK. Tkinter is the python adapter for Tk, the toolkit originally developed for Tcl language. The latest version of Tk (not yet integrated in Python, maybe in 2.6) has themes, which emulates the look-and-feel of native toolkit at list for XP and OS X. For unix, the last time I checked, there was only a theme that looked like a plainer version of Gtk default theme. No Gnome or Kde themes yet. Nitpick, but an important one. It emulates *look*. Not feel. Native look is easy and totally insufficient for a native app - it's the feel that's important. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python GUI toolkit
On Feb 4, 2008 9:57 AM, Kevin Walzer [EMAIL PROTECTED] wrote: Chris Mellon wrote: Nitpick, but an important one. It emulates *look*. Not feel. Native look is easy and totally insufficient for a native app - it's the feel that's important. Is this opinion based on firsthand experience with use of the Tile/ttk widgets on any of the relevant platforms? I'm not a Windows user, so I can't speak about that platform, but I have worked very hard to make my Python-Tile-Tk app consistent with both the look and feel of OS X: keyboard shortcuts, menu behavior, and so on. It's mainly a matter of attention to detail, and listening to user feedback. I've gotten good feedback on my applications in recent months as I've implemented more and more platform native behavior, and sales of these applications (I'm a shareware developer) reflect that. I'd be interested to hear how, in your experience, Tk/Tile is inherently unable to deliver native platform feel, in a way that reflects on the toolkit rather than the developer. It's fine to focus on Windows if that's your area of expertise. I didn't say inherently unable, I said the toolkit doesn't provide it. Note that you said that you did a lot of work to follow OS X conventions and implement behavior. The toolkit doesn't help you with any of this. A mac-native toolkit (or one that strives for native behavior, like wxPython) eliminates a lot of this work (although, of course, not all). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python GUI toolkit
On Feb 4, 2008 10:46 AM, Kevin Walzer [EMAIL PROTECTED] wrote:
Chris Mellon wrote:
I didn't say inherently unable, I said the toolkit doesn't provide it.
Note that you said that you did a lot of work to follow OS X
conventions and implement behavior. The toolkit doesn't help you with
any of this. A mac-native toolkit (or one that strives for native
behavior, like wxPython) eliminates a lot of this work (although, of
course, not all).
If the toolkit doesn't provide it, then I think that means inherently
unable.
Of course it doesn't, because you can implement it yourself. Which is
what you do. Tile itself is inherently unable to provide this because
it's a theming mechanism.
On the Mac, Tk provides a mechanism that allows hooking up arbitrary
events to arbitrary keyboard. Something like:
self.bind('Command-Key-N', lambda event:
self.authorizeCommand(self.installPackage))
I have to specify the key-combination--that's all. One line of code. No
implementing of keyboard bindings in C or at the Tcl/Tk or even
Python-Tkinter level--it's all already defined by the toolkit.
I know how toolkits work.
By contrast, Cocoa/Objective-C has a rather complex system for defining
keyboard events:
http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/HandlingKeyEvents/chapter_6_section_1.html#//apple_ref/doc/uid/1060i-CH7-SW1
PyObjC is a thin wrapper over Objective-C, so you'd have to do the
equivalent calls in Python to implement custom keyboard behavior.
It is true that Cocoa some convenience methods in Interface Builder,
i.e. common menu commands don't require any extra code: if you are
developing a document-based application, Command-C is implemented in
the menu and in the frameworks as copy (text, image, whatever) to
clipboard. But Command-C also works identically in the Tk console.
Tk does lack some things. It doesn't support drag-and-drop on the Mac.
It doesn't hook into some of the newer Mac visual styles. Getting access
to this would require an extension or patching Tk's core. In those
events, I emulate the behavior or appeareance, which Tk makes very easy.
I'm not sure how you keep referring to things you implement yourself
as something that the toolkit supports. As a brief example, some
features that wxPython provides to aid in native feel and not just
look:
Stock button support allows you to have native button location, order
and labelling.
Sizer support allows for differently sized controls to be positioned
with the same layout.
Stock menu IDs (like preferences and About this application...) will
be labelled and placed correctly.
Accelerators will automatically map between Command and Control.
Standard path support to find appropriate user directories.
All of these are things that you can do yourself, of course. You could
have implemented Tile yourself, too, to get the (mostly) native look.
The point is what the toolkit provides, and Tk+Tile, while it mostly
provides native look, does *not* provide native feel. If you want
native feel, you need to implement it yourself.
--
http://mail.python.org/mailman/listinfo/python-list
[issue1757072] Zipfile robustness
Chris Mellon added the comment: I agree that the zipfile is out of spec. Here are my arguments in favor of making the change anyway: Existing zip tools like 7zip, pkzip, and winzip handle these files as expected As far as I know, it won't break any valid zipfiles. Because the fix necessary is buried inside a private function in the zipfile module, it's difficult to monkey-patch the behavior into place and it's quite hard to figure out what needs to be done. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1757072 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Python for mobiles
On Jan 31, 2008 1:16 PM, Shawn Milochik [EMAIL PROTECTED] wrote: A better solution would surely be to get a Nokia S60 'phone, for which there is a native Python implementation. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Steve: Do you know if the Nokia E60i phone has this capability? Also, is wxPython supported? Or are you just knowledgeable about the S60? wxPython is not, but there are bindings for the S60s native gui provided. You can find out it your phone is supported a pys60.sf.net. -- http://mail.python.org/mailman/listinfo/python-list
Re: optional static typing for Python
On Jan 28, 2008 10:31 AM, John Nagle [EMAIL PROTECTED] wrote:
Arnaud Delobelle wrote:
On Jan 27, 11:00 pm, Russ P. [EMAIL PROTECTED] wrote:
On Jan 27, 2:49 pm, André [EMAIL PROTECTED] wrote:
Perhaps this:http://www.python.org/dev/peps/pep-3107/mightbe
relevant?
André
Thanks. If I read this correctly, this PEP is on track for Python 3.0.
Wonderful!
Note that annotations do not provide explicit typing, AFAIK:
def f(x:int) - int: return x*2
is stricly equivalent to
def f(x): return x*2
f.__annotations__ = {'x':int, 'return':int}
You still need to write a type-checking wrapper.
Unenforced static typing is somewhat pointless. If that
goes in, it should be enforced by implementations. Otherwise,
maintenance programmers can't trust the type information they see.
Enforced, it makes it possible to start getting serious about
optimizing compilers for Python, like Shed Skin. Shed Skin
can usually figure out typing within a module, but across module
boundaries, some help is needed if you want to push optimization from
run time to compile time.
Given the difficulty of statically analyzing Python, and the
limitations you need to add for either static typing or type inference
to be practical, I think that the real future for faster Python code
is JIT, not static optimizations. Languages which enforce static
typing are, of course, not Python - that's why they have different
names, like Pyrex or ShedSkin or RPython.
I think static Python is pretty much a waste of time, really - if I'm
going to write statically typed code using a traditional C/C++/Java
style type system, I'll use a language designed for it, like D. If I
want *real* strict typing - the kind where you can actually make a
useful inference from the fact that the program is type-correct - I'll
use Haskell or Ocaml. There is a lot of choice out there and there's
no reason to try to make Python into whatever your favorite paradigm
is.
--
http://mail.python.org/mailman/listinfo/python-list
Re: looking for a light weighted library/tool to write simple GUI above the text based application
On Jan 25, 2008 5:17 PM, Paul Boddie [EMAIL PROTECTED] wrote: On 25 Jan, 22:06, Lorenzo E. Danielsson [EMAIL PROTECTED] wrote: What you need then is something like SVGAlib (http;//svgalib.org). Only really old people like myself know that it exists. I've never heard of any Python bindings for it, but that might be where you come in. I haven't looked at SVGAlib for years, and I'm not sure about the state of the video drivers. I suggest you look at that first. I believe that SVGAlib was superseded by GGI and other projects, and I recall that SVGAlib was considered to be something of a nightware with respect to how it handles various resources. Certainly, I haven't been very impressed by the behaviour of software using it. You could also look at GGI (http://ggi-project.org). GGI has different output targets. IIRC, one of them is directfb. To tell you the truth I've never really used GGI. There seems to be a python wrapper for GGI, although it is fairly old. Maybe you could look at the code for some ideas. I've had to build software using GGI, and the biggest problem has been getting packages for it. That said, it seemed to work fairly acceptably once built and installed. Meanwhile, some people favour Allegro [1] for this kind of work, and I've been confronted with newly developed software which uses Allegro, so it's arguably in a different maintenance state than something like SVGAlib or GGI. You should also be able to compile SDL to be able to use directfb as a target. If your libSDL handles it, then that should apply to wrapper libraries as well, including pygame. I've never tried running SDL apps this way, but if it works well, that would probably be your 'best' option. I'd agree with these sentiments; SDL seems to be the best supported technology of this kind in the Python universe, and one of the most widely deployed in general; I've felt quite comfortable building software against it. It would be very interesting to see whether a framebuffer-based SDL could support Pygame, and I imagine that the Pygame mailing list might already have some answers in its archives on this topic. I agree that SDL is probably the best choice but for the sake of completeness, Gtk can (at least in theory - I've never tried it) be built against directfb and run without X. -- http://mail.python.org/mailman/listinfo/python-list
Re: translating Python to Assembler
On Jan 25, 2008 9:09 PM, Steven D'Aprano [EMAIL PROTECTED] wrote: On Wed, 23 Jan 2008 08:49:20 +0100, Christian Heimes wrote: It's even possible to write code with Python assembly and compile the Python assembly into byte code. Really? How do you do that? I thought it might be compile(), but apparently not. There are tools for it in the undocumented compiler.pyassem module. You have to pretty much know what you're doing already to use it - I spent a fun (but unproductive) week figuring out how to use it and generated customized bytecode for certain list comps. Malformed hand-generated bytecode stuffed into code objects is one of the few ways I know of to crash the interpreter without resorting to calling C code, too. -- http://mail.python.org/mailman/listinfo/python-list
Re: translating Python to Assembler
On Jan 24, 2008 9:14 AM, Bjoern Schliessmann [EMAIL PROTECTED] wrote: Tim Roberts wrote: Bjoern Schliessmann [EMAIL PROTECTED] So, how do processors execute Python scripts? :) Is that a rhetorical question? A little bit. Grant is quite correct; Python scripts (in the canonical CPython) are NOT compiled into assembly language. Scripts are compiled to an intermediate language. Processors execute Python scripts when the interpreter, written in a high-level language and compiled to assembly, interprets the intermediate language created by the Python compiler. So in the end, the program defined in the Python script _is_ compiled to the CPU's language. But never mind, it depends on how you define compile in the end. This is true if and only if you would agree that Powerpoint presentations, Word documents, and PNG images are likewise compiled to machine code. -- http://mail.python.org/mailman/listinfo/python-list
Re: strange syntax rules on list comprehension conditions
On Jan 18, 2008 12:53 PM, Nicholas [EMAIL PROTECTED] wrote: I was quite delighted today, after extensive searches yielded nothing, to discover how to place an else condition in a list comprehension. Trivial mask example: [True if i 5 else False for i in range(10)] # A [True, True, True, True, True, False, False, False, False, False] I then experimented to drop the else statement which yields an error [i if i3 for i in range(10)] Traceback ( File interactive input, line 1 this syntax works of course [i if i3 else i for i in range(10)] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] Does anybody else find this lack of symmetry odd? x if y else x is an expression - it's the Python equivalent of C's ternary operator. The mechanism for filtering in a list comp is [x for x in y if x]. Your stumbling upon the ternary expression was a happy accident, and your confusing comes from trying to generalize the wrong operation. -- http://mail.python.org/mailman/listinfo/python-list
Re: short path evaluation, why is f() called here: dict(a=1).get('a', f())
On Jan 14, 2008 12:39 PM, aspineux [EMAIL PROTECTED] wrote:
This append in both case
dict(a=1).get('a', f())
dict(a=1).setdefault('a', f())
This should be nice if f() was called only if required.
Think about the change to Python semantics that would be required for
this to be true, and then use collections.defaultdict instead.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
On Jan 11, 2008 9:10 AM, George Sakkis [EMAIL PROTECTED] wrote: On Jan 11, 8:59 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: George Sakkis a écrit : On Jan 11, 4:12 am, Bruno Desthuilliers bruno. [EMAIL PROTECTED] wrote: George Sakkis a écrit : On Jan 10, 3:37 am, Bruno Desthuilliers wrote: I fail to see how the existence of JIT compilers in some Java VM changes anything to the fact that both Java (by language specification) and CPython use the byte-code/VM scheme. Because these some Java VMs with JIT compilers are the de facto standard used by millions; Repeating an argument doesn't make it more true nor more relevant. Once again, this doesn't change anything to the fact exposed above. the spec is pretty much irrelevant I mentionned this because this kind of choice is usually not part of the language spec but of a specific implementation. Java is AFAIK the only language where this implementation stuff is part of the spec. (unless you're a compiler writer or language theorist). I thought it was quite clear and obvious that I was talking about points relating to these fields. No it wasn't, or is Python just too slow as an interpreted language Being interpreted is a quality of an implementation, not of a language. If that isn't clear enough what I'm talking about, then sorry but I can't help. Pedantic once again. For languages with a single (or practically single) implementation such as Python, the average user couldn't care less about the distinction. Your point might have more merit if PyPy or IronPython or Jython enter the same league with CPython in terms of usage. and besides the OP is most likely interested in these as a simple user so the distinction between a spec and a de facto standard implementation (such as JDK for Java and CPython for Python) are almost pedantic if not misleading. I can live with being called pedantic - even I'm not sure whether correcting a wrong statement about CPython's execution model is pedantic or not. But I *still* fail to see how it could be misleading, and *you* still fail to explain in which way it could be misleading. If your point is that saying that CPython uses a byte-code/VM scheme just like Java necessarily implies JIT compilation just because some JVM support this feature, then it would be time you pay more attention to what is effectively written. What three different people in this thread have been trying to tell you but you seem to miss is that claiming CPython's VM is just like Java is comparable to saying a Yugo's car engine is just like a BMW's (or humans are just like chimpanzees), which for some value of just like is technically correct but it's not what most people would call an accurate statement. The statement was in response to a claim that Python was slow because it is interpreted. This is a little like correcting someone who says that a Yugo is slow because it has a steam engine by telling that no, it's internal combustion, just like the BMW has. It's possible for this a claim like this to lead to a clarifying and informative discussion about JIT technology and how it improves Javas performance, and the use of corresponding techniques in Python. What we got instead was someone who felt some sort of juvenile urge to jump all over a what he thought of as a claim that Python is as fast as Java (which, of course, it sometimes is - the issue is more complicated than a sound bite). We're not Lisp (yet ;-)), with five major implementations and a dozen of minor ones. And ? In which way does it make the distinction between a language and a language implementation less true ? In the way that most plain users care (or not) about. Not that I think any of you care about anything except your e-penis at this point, but there is no reason to proscribe discussion to only what plain users want, even if the OP was such a person. -- http://mail.python.org/mailman/listinfo/python-list
Re: Strange problem: MySQL and python logging using two separate cursors
On Jan 9, 2008 11:52 AM, Dennis Lee Bieber [EMAIL PROTECTED] wrote:
On Wed, 9 Jan 2008 10:11:09 +0100, Frank Aune [EMAIL PROTECTED]
declaimed the following in comp.lang.python:
The only clue I have so far, is that the cursor in task 1 seems to be unable
to register any new entries in the log table produced by task 2 as soon as
task 1 perform an SQL query of some kind.
How often do you issue a commit? For some DB-API adapters (I forget
which database -- think it was SQLite) a select query does not complete
until the last data has been fetched from it -- meaning the transaction
(the DB-API spec is that auto-commit is OFF) is still open and other
transaction changes will not be seen. {I do find it perplexing that
transactions are started by cursor actions, but committed by the
connection!}
Im contemplating using the same cursor for task 1 and 2, but I think keeping
them separate is a better design - if it only worked :)
I'd probably suggest using a separate connection and cursor -- with
liberal usage of conn.commit() to ensure that transaction views are
flushed/refreshed.
The MySql api doesn't have a concept of a cursor, only connections. If
you want truly separate cursors in MySql you need to use individual
connections.
--
http://mail.python.org/mailman/listinfo/python-list
Re: how to use bool
On 03 Jan 2008 16:09:53 GMT, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: hi, i have some code where i set a bool type variable and if the value is false i would like to return from the method with an error msg.. being a beginner I wd like some help here class myclass: . def mymethod(self): success=True msg=all validation OK success=validateSthing() if(success==False): msg=sthing failed return (success,msg) dosomeprocessing() . success=validateSthingelse() if(success==False): msg=sthingelse failed return (success,msg) domoreprocessing() return(success,msg) i would like to know if this way of doing this is OK..I have need of many kinds of validations in this ..is there a better way of doing this ? With my philosophical programming hat on the first thing I'd say (as a fairly beginning python programmer) is avoid multiple returns from a function/method if at all possible. They breed all sorts of problems and errors, in particular if there's any clearing up to do you have to do it in lots of places (or you forget it in some places). This advice is highly controversial, and in the presence of exceptions it is, at best, voodoo coding. Since your function can exit at any point whether you do it intentionally or not, if you have crucial cleanup it's best to write your code in a way that does it correctly even if you return early. Following this style also often leads to odd contortions, like extra layers of indentation, and a proliferation of temporary flags and value-holders that aren't necessary if you write the code in a more straight forward manner. Make your decisions on a case by case basis of complexity, readability, and reliability instead of following pronouncements from on high (especially decades old pronouncements made in a different context). Forcing a single return site in the code below adds complexity, arguable harms readability, and provides *zero* benefit in the code at hand. So:- def mymethod(self): msg=sthing failed success=validateSthing() if success: dosomeprocessing() . success=validateSthingelse() if success: domoreprocessing() msg=all validation OK return (success,msg) I've lost the different messages for different errors but you get the idea. if success: rather than if (success==True), more readable. For the opposite if not success:. -- Chris Green -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: reassign to builtin possible !?
On Jan 3, 2008 8:05 AM, Tim Chase [EMAIL PROTECTED] wrote:
But you can't alter the values for True/False globally with this.
Are you sure ? what about the following example ?
Is this also shadowing ?
import __builtin__
__builtin__.True = False
__builtin__.True
False
It doesn't seem to screw things up globally
import __builtin__
t = __builtin__.True
__builtin__.True = False
__builtin__.False = t
True
False
False
True
1 == 1
True
import os
os.path.isdir('.')
True
#if they were globally redefined, this would be False
#you'd have to actually reference __builtin__.True
My thought would be if you do something as daft as
redefining/shadowing True and False, you get the headaches that
ensue. Fortunately, since Python is explicit, you can trace back
through the code and see where the inanity occurred.
Additionally, any scoping rules mean that programmer stupidity
can't leak too badly outside the scope of the block containing
the stupidity.
It's the old DIHWIDT! WDDT! (Doctor, it hurts when I do
this!, well don't do that!) syndrome.
In Py3k this will be a syntax error, like assigning to None is now.
Possibly also in 2.6.
--
http://mail.python.org/mailman/listinfo/python-list
Re: ElementTree should parse string and file in the same way
On Jan 2, 2008 8:56 AM, Fredrik Lundh [EMAIL PROTECTED] wrote: Steven D'Aprano wrote: Fredrik, if you're reading this, I'm curious what your reason is. I don't have an opinion on whether you should or shouldn't treat files and strings the same way. Over to you... as Diez shows, it's all about use cases. and as anyone who's used my libraries or read my code knows, I'm a big fan of minimalistic but highly composable object API:s and liberal use of short helper functions to wire them up to fit the task at hand. kitchen sink API design is a really bad idea, for more reasons than I can fit in this small editor window. On that note, I really don't like APIs that take either a file name or a file object - I can open my own files, thanks. File objects are fantastic abstractions and open(fname) is even shorter than StringIO(somedata). My take on the API decision in question was always that a file is inherently an XML *document*, while a string is inherently an XML *fragment*. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bizarre behavior with mutable default arguments
On Dec 31, 2007 2:08 PM, Odalrick [EMAIL PROTECTED] wrote: On 31 Dec, 18:22, Arnaud Delobelle [EMAIL PROTECTED] wrote: On Dec 31, 10:58 am, Odalrick [EMAIL PROTECTED] wrote: On 30 Dec, 17:26, George Sakkis [EMAIL PROTECTED] wrote: On Dec 29, 9:14 pm, bukzor [EMAIL PROTECTED] wrote: Here's the answer to the question:http://www.python.org/doc/faq/general/#why-are-default-values-shared-... It looks like Guido disagrees with me, so the discussion is closed. Note that the FAQ mainly explains *what* happens, not *why* was this decision taken. Although it shows an example where this feature can be useful, it's neither the only way to do it nor is memoization as common as wanting fresh default arguments on every call. I'm surprised noone has said anything about the why of default mutables. I think it is becasue it isn't easy to do it an other way. [...] There is an easy enough way: evaluate default values when the function is called rather than when it is defined. This behaviour comes with its own caveats as well I imagine, and it's not 'as easy' to implement as the current one. Adding overhead to *all* function calls, even the ones without mutable defaults. That doesn't sound like an attractive tradeoff. And also removing the only way you can currently do early binding in Python. I agree that it's a gotcha, but unless someone comes up with an answer to the following questions, I'll stick with the status quo (Note that this is not blind Python group-think as a previous poster implied, but a pragmatic decision that this is the most practical solution): a) If we don't evaluate default arguments at function compilation, when do we do it? b) If you do it at call time, how do you implement early binding? c) If you want to introduce new syntax for the current behavior, what is it and can you justify it? d) What are the performance implications of your proposal versus the current behavior? Note that the desired behavior can be implemented under the current behavior, at the expense of verbosity - using factories and sentinel values as the default arguments, and then expanding them in the function. It's not possible to implement the current behavior of early-bound arguments if default arguments are evaluated with every call. This alone is a good reason to keep the current behavior until someone actually has a good alternative that covers the current use cases and isn't just upset by the behavior. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python DLL in Windows Folder
On Dec 28, 2007 6:41 AM, Ross Ridge [EMAIL PROTECTED] wrote: Ross Ridge writes: As I said before, I know how futile it is to argue that Python should change it's behaviour. I'm not going to waste my time telling you what to do. If you really want to know how side-by-side installation works, you can try reading the Windows SDK documentation. [EMAIL PROTECTED] wrote: I did, and determined that it's not possible. We would have to use assembly manifests, and can't, as the tool chain doesn't support them. Your choice to use a tool chain that doesn't support side-by-side assemblies does not make it impossible. It's worth pointing out that when the choice was made,Windows didn't support SxS at all and there was no toolchain for it. No, simply by changing the name you've prevented backwards compatiblity with the old DLL. First, the requirement for backwards compatibility is not normative. Section 2.6 is entitled Install any shared files that are not side-by-side to the correct locations. python25.dll, as a matter of fact, *is* a shared file that is not side-by-side; the *only* location I can install in according to 2.6 is the System folder. No, the only thing that the guidelines require to be installed in the system directory are services and drivers. The only exception for other kinds of applications is when necessary for backwards compatibility. You're not reading the document correctly. The backwards compatability is supporting non SxS libraries. You can't argue you're trying to maintain backwards compatibilty with an old DLL when you've already broken compatibility with it. Furthermore, it says to ensure backward compatibility with those applications, not to ensure backward compatibility with the old DLL. Now you're just trying play pointless semantic games. If you change the DLL's name, the DLL is no longer compatibile with those applications. Python 2.5 already exists and has shipped. Since the existing applications have to be rebuilt to use the new DLL they also can be changed to use it from a new shared location. No, they can't, because there is not enough manpower available to change them. And that's what this all really comes down to. Because neither you nor anyone else is willing to do the work necessary to do the Right Thing, you have chosen not to follow Microsoft's recommended best practices for installing Windows applications. It's not because it's impossible, it's because you're unwilling. You're persisting in calling Python an application, which it clearly isn't. How relevant these guidelines are at all, since they're targeted toward end-user boxed software and not toward developers of third party libraries, is questionable, but lets see what it says. Section 2.6 *clearly* states that non side by side dlls (which Python is) can (and, in fact *must*) be placed in the System directory. Note that making your libraries SxS is *not* a requirement. So if we're going to follow this (questionable) document at all, Python is absolutely compliant. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python DLL in Windows Folder
On Dec 24, 2007 5:23 PM, Ross Ridge [EMAIL PROTECTED] wrote: Chris Mellon [EMAIL PROTECTED] wrote: What the python installer is doing is the Right Thing for making the standard python dll available to third party applications. Applications that want a specific version of a specific DLL should use the mechanisms available for doing so, instead of relying on there being a specific version of the python dll in the windows folder. This is just general best practice on Windows. No, it's not best practice for an application install any of its files in the Windows system directory. The system directory is ment only for drivers and system files. Installing application DLLs in the system directory is something that should only be done for backwards compatiblity. Python (when installed with for everyone) is not (just) an application, it's a runtime. I know that Microsoft has totally dropped the ball on handling shared libraries and has recently thrown up its arms and just said that all apps should ship with everything they need (Don't use shared libraries any more, versioning is hard) but that's not applicable to Python *the runtime*. system32 is precisely the correct spot for it, when installed by an administrator, as a system runtime. Note that for me only Python, doesn't install to there. -- http://mail.python.org/mailman/listinfo/python-list
Re: Releasing malloc'd memory using ctypes?
On Dec 23, 2007 12:36 PM, [EMAIL PROTECTED] wrote: I am starting to experiment with ctypes. I have a function which returns a pointer to a struct allocated in heap memory. There is a corresponding free function for that sort of struct, e.g.: from ctypes import * cdll.LoadLibrary(libthing.so) c_thing = CDLL(libthing.so) class THING(Structure): _fields_ = [(name, c_char_p), (value, c_int)] get_thing = c_thing.get_thing get_thing.restype = POINTER(THING) free_thing = c_thing.free_thing So I call get_thing() and get back this ctypes wrapper for a pointer to a thing. I can extract the name and value elements from the thing instance just fine: thing_p = get_thing() thing = thing_p.contents print thing.name, =, thing.value Now I need to call free_thing. What do I pass it? thing_p? Some attribute of thing_p? Something else altogether? The ctypes module docs seem to be strangely silent on the question of freeing heap memory which you've received from the underlying library's functions. You do it just like you'd do in C, and pass the return value of get_thing. Make sure that you declare free_thing as taking a pointer so ctypes knows to do the right thing. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python DLL in Windows Folder
On Dec 23, 2007 12:27 PM, Markus Gritsch [EMAIL PROTECTED] wrote: On 23/12/2007, Christian Heimes [EMAIL PROTECTED] wrote: Markus Gritsch wrote: why does the Python installer on Windows put the Python DLL into the Windows system32 folder? Wouldn't it be more clean to place it into the Python installation folder beside the python.exe file? It's the easiest and best way to expose Python for 3rd party applications and COM. The DLL is removed by the Windows Installer when its usage counter drops to 0. There is no need to worry ;) I am not worrying about an orphaned DLL. The Problem is that this way the Python DLL is being made available for 3rd party applications, which possibly need a version of Python which is compiled using another compiler. We are embedding Python into our application which gets compiled using MSVC 8.0. We like to link dynamically, so the Python interpreter is not statically linked into the program. The Python DLL from the Python installer in the Windows system32 folder is compiled using MSVC 7.1. What the python installer is doing is the Right Thing for making the standard python dll available to third party applications. Applications that want a specific version of a specific DLL should use the mechanisms available for doing so, instead of relying on there being a specific version of the python dll in the windows folder. This is just general best practice on Windows. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to in Python
On Dec 21, 2007 7:25 AM, [EMAIL PROTECTED] wrote: John Machin wrote: Use a proper lexer written by somebody who knows what they are doing, as has already been recommended to you. My lexer returns a MALFORMED_NUMBER token on '0x' or '0x '. Try that in Python. Is there some reason that you think Python is incapable of implementing lexers that do this, just because Python lexer accepts it? Note that if you're using your lexer to mark up or pretty print or whatever Python source, it's wrong - 0x is (rightly or not) a valid Python literal. -- http://mail.python.org/mailman/listinfo/python-list
Re: It's ok to __slots__ for what they were intended (was: Don't use __slots__ (was Re: Why custom objects take so much memory?))
On 20 Dec 2007 19:50:31 -0800, Aahz [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Carl Banks [EMAIL PROTECTED] wrote: On Dec 18, 4:49 pm, [EMAIL PROTECTED] (Aahz) wrote: In article [EMAIL PROTECTED], Chris Mellon [EMAIL PROTECTED] wrote: You can reduce the size of new-style classes (inherit from object) by quite a bit if you use __slots__ to eliminate the class dictionary. You can also reduce your functionality quite a bit by using __slots__. Someday I'll have time to write up a proper page about why you shouldn't use __slots__ Shouting absolute commands without full understanding of the situation is not going to help anyone. Maybe not, but at least it will get people to stop for a bit. No, it will just make people stop ignoring you because you give inappropriate advice forbidding reasonable solutions without a rational justification. The OP wanted to minimize memory usage, exactly the intended usage of slots. Without knowing more about the OP's situation, I don't think your or I or Chris Mellon can be sure it's not right for the OP's situation. The whole point about warning against __slots__ is that you should never use them unless you are certain they're the best solution. Consider what happens when the OP wants to subclass this __slots__-using class. Nothing. Subclasses of a class with __slots__ get a dict just like anything else, unless they also define slots. Why do you think you can subclass object to get something you can stick arbitrary attributes on? Avoiding __slots__ will almost never harm anyone, so I feel completely comfortable sticking with a blanket warning. -- Barking out your blanket warning in a thread on *the exact use case slots were implemented to address* just makes you look like a mindless reactionary. Stick to posting your warning in threads where people ask how to stop other people from setting attributes on their instances. -- http://mail.python.org/mailman/listinfo/python-list
Re: Beginner question!
On Dec 21, 2007 9:11 AM, SMALLp [EMAIL PROTECTED] wrote: Hy! I have error something like this TypeError: unbound method insert() must be called with insertData instance as first argument (got str instance instead) CODE: File1.py sql.insertData.insert(files, data) sql.py class insertData: def insert(self, dataTable, data): conn = self.openConnection.openConnection() cursor = conn.cursor() sql =INSERT INTO +dataTable+ (user_name, file_name, file_size, file_path_local, file_path_FTP, curent_location, FTP_valid_time, uploaded, last_modified, last_verified, file_type, file_category) VLAUES +data cursor.execute(sql) conn.Close() Help and advice neaded! -- You are unclear on the distinction between classes and instances of those classes. Following Python convention and naming your classes in CapsCase (InsertData not insertData) would help. I recommend taking 2 giant steps backward and working through the python tutorial and dive into python, then coming back to this project. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to in Python
On Dec 21, 2007 1:02 PM, [EMAIL PROTECTED] wrote: Chris Mellon wrote: Is there some reason that you think Python is incapable of implementing lexers that do this, just because Python lexer accepts it? Absolutely not. My opinion is that it's a bug. A very, very minor bug, but still six-legged. I understand the argument but I'm wondering why you're asking questions on this list about it. You don't seem to be implementing the lexer in Python (because otherwise the question wouldn't have come up), and you don't seem to be parsing Python code. Where's the python angle? Not that this list is totally intolerant of offtopic discussions, but you don't seem to even have a hint of Python interest here - the questions seem to be better suited for comp.parsers.general or something. Note that if you're using your lexer to mark up or pretty print or whatever Python source, it's wrong - 0x is (rightly or not) a valid Python literal. My lexer is for my language, Decaf, which, in this particular, is the same as Python. Here's what I find at at python.org/ref: (2.4.4). hexinteger ::= 0 (x | X) hexdigit+ Implementation differs from specification. In this case, I think the spec is more sensible. I tend to consider what the parser actually accepts rather than what the grammar specifies to be normative when writing pretty printers or syntax highlighters. -- http://mail.python.org/mailman/listinfo/python-list
Re: It's ok to __slots__ for what they were intended
On Dec 21, 2007 2:07 PM, Fredrik Lundh [EMAIL PROTECTED] wrote: John Nagle wrote: I'd like to hear more about what kind of performance gain can be obtained from __slots__. I'm looking into ways of speeding up HTML parsing via BeautifulSoup. If a significant speedup can be obtained when navigating large trees of small objects, that's worth quite a bit to me. The following micro-benchmarks are from Python 2.5 on a Core Duo machine. C0 is an old-style class, C1 is a new-style class, C2 is a new-style class using __slots__: # read access $ timeit -s import q; o = q.C0(); o.attrib = 1 o.attrib 1000 loops, best of 3: 0.133 usec per loop $ timeit -s import q; o = q.C1(); o.attrib = 1 o.attrib 1000 loops, best of 3: 0.184 usec per loop $ timeit -s import q; o = q.C2(); o.attrib = 1 o.attrib 1000 loops, best of 3: 0.161 usec per loop # write access $ timeit -s import q; o = q.C0(); o.attrib = 1 o.attrib = 1 1000 loops, best of 3: 0.15 usec per loop $ timeit -s import q; o = q.C1(); o.attrib = 1 o.attrib = 1 100 loops, best of 3: 0.217 usec per loop $ timeit -s import q; o = q.C2(); o.attrib = 1 o.attrib = 1 100 loops, best of 3: 0.209 usec per loop $ more q.py class C0: pass class C1(object): pass class C2(object): __slots__ = [attrib] Your mileage may vary. Here are my timings of object creation time. Note that as you add slots, the speed advantage disappears. C:\python -m timeit -s from objs import C0 as c c() 100 loops, best of 3: 0.298 usec per loop C:\python -m timeit -s from objs import C1 as c c() 1000 loops, best of 3: 0.172 usec per loop C:\python -m timeit -s from objs import C2 as c c() 1000 loops, best of 3: 0.164 usec per loop C:\python -m timeit -s from objs import C3 as c c() 100 loops, best of 3: 0.302 usec per loop #objs.py import string class C0: pass class C1(object): pass class C2(object): __slots__ = [foo] class C3(object): __slots__ = list(string.ascii_letters) -- http://mail.python.org/mailman/listinfo/python-list
Re: mac dashboad
On Dec 21, 2007 3:25 PM, Carl K [EMAIL PROTECTED] wrote: ianaré wrote: On Dec 21, 12:37 pm, Carl K [EMAIL PROTECTED] wrote: How do I hang an app off the mac dashboard? The goal is a python version of Weatherbug. something like: read xml data from a URL, display some numbers, mouse over shows more details Carl K What is the dashboard - is it anything like the taskbar in windows/ Gnome? If it is, take a look at this: http://www.wxwidgets.org/manuals/2.6.3/wx_wxtaskbaricon.html Yes. But I don't want to rely on wx - trying to use just native mac python (whatever they ship with) Dashboard widgets are written using HTML and Javascript. They are rendered by a WebKit instance which, as far as I know, has no mechanism for Python scripting. Unless it does, you can't write a widget in Python, and even so you wouldn't use wx (or any other GUI toolkit) to do so - your display medium is HTML and the Canvas object. There's lots of articles on developer.apple.com about writing Dashboard widgets. -- http://mail.python.org/mailman/listinfo/python-list
Re: Ping Implementation in Python
On Dec 20, 2007 9:41 AM, Mrown [EMAIL PROTECTED] wrote: Hi, I was wondering if there was a ping implementation written in Python. I'd rather using a Python module that implements ping in a platform/OS-independent way than rely on the underlying OS, especially as every OS has a different implementation. Furthermore, if you're going to ping a large number of IPs, using a module would probably be a lot faster. Any ideas if such a module exists? Thanks. There's no point in having a script that pings things, especially large numbers of IPs. If you really want to do network scanning other tools for that already exist. -- http://mail.python.org/mailman/listinfo/python-list
Re: wxPython FileDialog, select folder
On Dec 20, 2007 3:19 PM, SMALLp [EMAIL PROTECTED] wrote: How can i select folder either with wx.FileDialog or with any other. I managed to fine only how to open files but I need to select folder to get files from all sub folders. There's a separate dialog, wx.DirDialog. -- http://mail.python.org/mailman/listinfo/python-list
Re: Allowing Arbitrary Indentation in Python
On Dec 19, 2007 10:46 AM, Sam [EMAIL PROTECTED] wrote: On Dec 19, 11:09 am, gDog [EMAIL PROTECTED] wrote: Hi, Sam- I'm not wanting to start a flame war, either, but may I ask why does your friend want to do that? I'm always intrigued by the folks who object to the indentation rules in Python, even though I've always tried to keep consistent indentation in all the languages I've used (and I've been at this since the 1980's). Even my Perl coding friends tend to insist on indents being aligned. I'm just curious, that's all. Thanks, --greg His comments on the subject are in the LiveJournal comment I linked to in my original post. I think it's mostly an idiosyncratic thing; he's used to laying out GUI elements in a hierarchy using tabs (in some language that allows arbitrary tabs) and now that he's experimenting with the (new?) Python API for the same toolkit, he wishes he could use the same coding style. It's interesting that the solutions move away from the terrible abomination of a GUI toolkit and write Python wrappers that don't cause actual physical pain never occur to him. He's got a lot of years invested in this layout so I understand the hesitance to move away from it, but seriously - this is a really terrible way to do GUI layout. The context manager solution is probably the best way to maintain something close to the style he's used to. All those setParent calls! *shiver*. I notice he retreats to the well, *I* can read it, so it's not unreadable defense, which of course applies to anything (I know people who can read x86 assembly directly from hex dumps) without really addressing the merits of a particular case. -- http://mail.python.org/mailman/listinfo/python-list
Re: Allowing Arbitrary Indentation in Python
On Dec 19, 2007 4:05 PM, Gary [EMAIL PROTECTED] wrote: snipped a lot of stuff I'm not replying to Chris Mellon writes: It's interesting that the solutions move away from the terrible abomination of a GUI toolkit and write Python wrappers that don't cause actual physical pain never occur to him. Oh, but they have, and almost immediately. You're assuming, perhaps, however, that I have the chops for that at such an early stage in my new Python life, or that I'm excited about the prospect of jumping right into a new library, only to have to virtually start over, wrapping some 15-20 layouts, and maybe 50+ controls in wrappers. In either case, you would assume wrong. I overestimated your Python experience when I read the first (last? most recent) post. After I sent the email I went back through your LJ post where your level of experience with Python is made much more plain. I don't mean this in a bad way - you're a beginner and that's fine - but you don't have a grasp on Pythons fundamentals and thats why so many things about it seem strange to you. All of the things in your first post have reasons why they are that way, and there is internal consistency in all of them. You have been done a disservice by whoever wrote the Maya python bindings, as far as using this tool to improve your knowledge and understanding of Python goes. ...and continues: He's got a lot of years invested in this layout so I understand the hesitance to move away from it... Yes! I have lots of years invested! But, no! I'm not hesitant! I'm ready! Let's go! I'm totally prepped to be done with MEL :) ...and furthermore states: ...but seriously - this is a really terrible way to do GUI layout. Oh, c'mon, no it's not. It's nearly the same thing as HTML, as I said. Are you going to seriously denounce more than a decade of that, and tens of thousands, if not millions of people using it in every language, in countless implementations the world over? Yes, HTML is a very bad way of doing GUI layout. It's a textual markup language, not a layout format. HTML per se has almost no layout capabilities at all, and CSS while much better is still quite limited. This is the internet, we don't shy away from scoffing at millions of misguided souls here ;) I'm not saying it can't be better, but *terrible?* Yes, I'm being declarative of my layouts right inside my code, which might be weird, but that's only because I'm adaptable, and it was the best way to do it in MEL, which has been my only option in Maya since the mid 90s. It's been solid for me, and honestly, once you're past a bit of the strangeness of it, is very straightforward, and simple. It's not the best, but it's not *terrible.* It's very much like writing HTML using only the DOM apis, and not HTMLs syntatic markup, which *is* terrible. The structures you're defining are quite reasonable, it's the API that's bad. I tend to group stuff into categories of good, adequate, and terrible. This, from the API alone, falls squarely into terrible for me. ...and keeps on rolling with: All those setParent calls! *shiver*. Alright, I'll give you those :) I hated them for the first year. Still, they're basically just HTML close tags, with the added power that you can replace '..' with a specific layout to jump into that. You can also think of them as close braces in your choice of C-like languages. Don't be such a scaredy-cat. They aren't a close tag, they're state management, and the fact that you have to litter your code with them is a real flaw in the GUI toolkit. You'll note that my language of choice is Python, a language which explicitly *excluded* the need for an end block marker. I'm pretty sure that there's a way to write Python that looks like the UI, but it's not using the API you have. ...will he ever stop? I don't know: I notice he retreats to the well, *I* can read it, so it's not unreadable defense... I can read it, because it's a natural style, as seen all over the place in HTML, XML, many UI layout tools, folder trees, complicated task lists, book outlines, and the list goes on. Seriously, what is with you people? I'm not so much claiming it's unreasonable as dismissing your argument why it is. I have to re-iterate: It's *not* markup. It's imperative code full of explicit state management that you write in a way that *llooks* like markup, which is a good call on your part because theres a reason almost everyone uses declarative languages for UI layout these days. ...and is almost done with: I know people who can read x86 assembly directly from hex dumps I rather enjoyed coding in x86, and once created a SWF file (compiled Flash binary), by hand, entirely at the *bit* (not byte) level. It took hours to get only several hundred bytes, but it worked! This, I realize, is not a good argument in my favor. ...and FINALLY finishes: without really addressing the merits of a particular case. But I have, over and over. It's very
Re: Changing intobject to use int rather than long
On Dec 18, 2007 11:59 AM, Clarence [EMAIL PROTECTED] wrote: Does anyone think (or know) that it might cause any internal problems if the ival member of the struct defining an intobject were to be changed from its current long int to just int? When you move your application to a 64-bit system in order to get a bigger address space to store your millions/billions of integers in RAM, but they get twice as big, you don't gain very much. Your int objects get twice as large, but you get 4294967296 times more address space. (They don't always get twice as large, and you don't actually get that much address space, and there's lots of other things wrong with this answer, but the core truth - that your available address space grows at a greater rate than the size of your ints - is correct). Thanks. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Why custom objects take so much memory?
On Dec 18, 2007 1:26 PM, jsanshef [EMAIL PROTECTED] wrote: Hi, after a couple of days of script debugging, I kind of found that some assumptions I was doing about the memory complexity of my classes are not true. I decided to do a simple script to isolate the problem: class MyClass: def __init__(self,s): self.mystring = s mylist = [] for i in range(1024*1024): mylist.append(MyClass(str(i))) #allocation #stage 1 mylist = None gc.collect() #stage 2 I take measures of the memory consumption of the script at #stage1 and #stage 2 and I obtain: #stage1 - 238MB #stage2 - 15MB That means every object is around 223 bytes in size That's too much considering it only contains a string with a maximum size of 7 chars. Classes are fairly heavyweight - in your case you've got the size of the PyObject struct, a dictionary for class attributes (which itself is another pyobject), and the string object (yet another pyobject), and the actual string data. If you change the allocation line for this other: mylist.append(str(i)) #we don't create the custom class, but append the string directly into the list the numbers decrease substantially to: #stage1 - 47.6MB #stage2 - 15MB (so this time we can say string vars occupy around 32 bytesstill a lot, isn't it?) string objects don't have dictionaries and are smaller than regular python objects. So, what's exactly going on behind the scenes? Why is using custom objects SO expensive? What other ways of creating structures can be used (cheaper in memory usage)? If you're worried about per-instance memory costs Python is probably not the language for your purposes. On the other hand, odds are that you actually don't need to worry so much. You can reduce the size of new-style classes (inherit from object) by quite a bit if you use __slots__ to eliminate the class dictionary. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using 'property' in evolving code
On Dec 17, 2007 11:48 AM, Steven Clark [EMAIL PROTECTED] wrote: Hi all- I was reading http://dirtsimple.org/2004/12/python-is-not-java.html, in particular the part about getters and setters are evil: In Java, you have to use getters and setters because using public fields gives you no opportunity to go back and change your mind later to using getters and setters. So in Java, you might as well get the chore out of the way up front. In Python, this is silly, because you can start with a normal attribute and change your mind at any time, without affecting any clients of the class. So, don't write getters and setters. I understand the idea behind this, but how does this transition work in actuality? Lets say I define class Foo initially as... class Foo(object): def __init__(self, x): self.x = x def get_sqrt(self): return sqrt(self.x) Fine. I can read from x, and write to x: def test(): f = Foo(9) print 'sqrt of', f.x, 'is', f.get_sqrt() f.x = 16 print 'sqrt of', f.x, 'is', f.get_sqrt() Let's say later on I decide that f.get_sqrt will be called far more often than f.x is changed, and that it therefore makes sense to store the actual sqrt in the class, rather than calling math.sqrt each time f.get_sqrt is called. So I rewrite Foo: class Foo(object): def __init__(self, x): self._x = x self._my_root = sqrt(x) def _set_x(self, x): self._x = x self._my_root = sqrt(x) def get_sqrt(self): return self._my_root x = property(lambda self: self._x, _set_x) External to the class, everything behaves as before, except with the benefit of not having to wait for slow sqrt each time. self.x is now a property rather than an attribute. Internal to the class, I have to search replace all old occurences of self.x with self._x? Otherwise there is a collision between f.x the attribute and f.x the property? You only need to update uses of the attribute that *need* the raw attribute, and not the property. Quite often these are just your (new) getters and setters, as you see. There is no collision - properties and (raw) attributes are accessed the same way. Any use of f.x will go through the property. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
On Dec 14, 2007 2:07 AM, Dennis Lee Bieber [EMAIL PROTECTED] wrote: On Thu, 13 Dec 2007 10:43:18 +0100, Bruno Desthuilliers [EMAIL PROTECTED] declaimed the following in comp.lang.python: I still wait to see any clear, unambiguous definition of scripting language. Which one are you refering to here ? Strangely, once you leave the realm of shell languages (DCL, JCL, bash, etc.) I can think of only ONE language that I'd consider a true scripting language... ARexx on the Amiga, as it could address any application that created a compatible ARexx message port. This meant one could write ARexx programs that could, by changing the address, send application native commands to an application, retrieve returned data, and then send that data to a second application using its native commands. No hassle with subprocess spawning or pipe I/O blocking... Applescript works in a very similar way. -- http://mail.python.org/mailman/listinfo/python-list
Re: Compressing a text file using count of continous characters
On Dec 14, 2007 10:54 AM, nirvana [EMAIL PROTECTED] wrote: I need to count the number of continous character occurances(more than 1) in a file, and replace it with a compressed version, like below XYZDEFAAcdAA -- XYZ8ADEF2Acd2A This sounds like homework. Google for run length encoding for algorithms, or check your textbook. -- http://mail.python.org/mailman/listinfo/python-list
Re: state machine and a global variable
On Dec 14, 2007 10:52 AM, [EMAIL PROTECTED] wrote:
Dear list,
I'm writing very simple state machine library, like this:
_state = None
def set_state(state):
global _state
_state = state
def get_state():
print _surface
but I hate to use global variable. So, please, is there a better way
of doing this? All I want is that a user has to type as little as
possible, like:
Yes, don't do it.
from state_machine import *
set_state(3)
get_state()
This isn't a state machine, it's just state
I.e., nothing like:
import state_machine
my_machine = state_machine.new_machine()
my_machine.set_state(3)
my_machine.get_state()
Stop being afraid of objects, especially if your fear is caused by
straw-man C style APIs.
from state_machine import State
state = State()
print state.current_state
state.do_something('sadfsafsad') #does something based on the current state
print state.current_state
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is Python really a scripting language?
On Dec 14, 2007 2:09 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Dec 11, 10:34 pm, Terry Reedy [EMAIL PROTECTED] wrote: Ron Provost [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] But here's my problem, most of my coworkers, when they see my apps and learn that they are written in Python ask questions like, Why would you write that in a scripting language? Whenever I hear a comment like that I can feel myself boiling inside. === I don't blame you. Python is an full-fledged algorithm/programming language that was designed to *also* be used a scripting language. When you buy a new car, which is more important, the styling or what's under the hood? snip That's for the whole sequence, not a single term! 25.67 MINUTES compared to 17.65 HOURS! So, sure, some languages compile to .exe programs. In the trade, we call that polishing a turd. While I agree with the sentiment, surely this can't be a good example of F#s general performance? I would expect .NET code to smoke stock (non-Psycoed) Python in this benchmark. -- http://mail.python.org/mailman/listinfo/python-list
Re: state machine and a global variable
On Dec 14, 2007 4:43 PM, [EMAIL PROTECTED] wrote: On Dec 14, 11:06 pm, Bruno Desthuilliers [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] a écrit : Dear list, I'm writing very simple state machine library, like this: _state = None def set_state(state): global _state _state = state def get_state(): print _surface NameError here !-) but I hate to use global variable. aol / So, please, is there a better way of doing this? All I want is that a user has to type as little as possible, like: from state_machine import * set_state(3) get_state() I.e., nothing like: import state_machine my_machine = state_machine.new_machine() my_machine.set_state(3) my_machine.get_state() A possible solution: # state_machine.py class _StateMachine(object): def __init__(self): self._state = SomethingHere() def get_state(self): return self._state def set_state(self, xxx): # etc _s = _StateMachine() get_state = _s.get_state() set_state = _s.set_state() I guess you meant without the parentheses: get_state = _s.get_state set_state = _s.set_state You still have a global, but at least it's a machine instance, not it's state !-) Now the question is: why do you think it's so important for your users to only see functions ? What's so wrong with: from state_machine import * m = get_state_machine() m.set_state(42) Well, I guess I can see the advantages of using the class instances but ... um ... the world isn't like that! :) Consider this: how do you add up some numbers? - My sum is zero. - I add 3 to my sum. - I add 2 to my sum. Or: - Three. - plus two. Implicit context, some people call it. Sometimes it's useful to be as precise as possible (explicit is better than implict, right?) but sometimes, it seems to me, it's just more natural not to repeat the context all over again. You're way too hung up on context when you should be hung up on state. Implicit state is bad, implicit global state is worse. You've got a shared global state, with an interface that's designed to dispatch on and mutate that state. It's basically every bad thing you can imagine about global state. Using an object means that the state machine is *local* state. Local state is good, because you've got a way to attach a name to it, to manipulate it explicitly, and to pass it around to other places. Your example presupposes two different use cases anyway, but most importantly what you're describing with sum is a mutation of local state (a local name binding), which is a very different thing than your state machine API. Honestly, I can't even imagine why you would want to implement a state machine *library* this way. If you meant a library that has internal state it makes a little more sense - I use an approach kind of like the one Bruno showed to handle global configuration and logging - but if you meant a library for implementing state machines you're on totally the wrong track. -- http://mail.python.org/mailman/listinfo/python-list
Re: Clearing a DOS terminal in a script
On Dec 13, 2007 10:48 AM, Stephen_B [EMAIL PROTECTED] wrote:
This doesn't seem to work in a dos terminal at the start of a script:
from os import popen
print popen('clear').read()
Any idea why not? Thanks.
It opens clear with it's own virtual terminal and clears that
instead. There's an ANSI control code you can use to reset the screen,
try printing that.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is a real C-Python possible?
On Dec 13, 2007 12:04 PM, Patrick Mullen [EMAIL PROTECTED] wrote:
Kay Schluehr wrote:
Python 2.6 and 3.0 have a more Pythonic way for the problem:
class A(object):
@property
def foo(self):
return self._foo
@foo.setter
def foo(self, value)
self._foo = value
@foo.deletter
def foo(self)
del self._foo
class B(A):
# one can even overwrite the getter in a subclass
@foo.getter
def foo(self):
return self._foo * 2
Christian
On Dec 12, 2007 12:57 PM, George Sakkis [EMAIL PROTECTED] wrote:
1. The property name ('foo') is repeated *5* times for a single class.
Talk about DRY.
2. Total inconsistency: @property for the getter when it is defined
for the first time, @foo.setter/@foo.deletter for the setter/deletter,
@foo.getter when the getter is redefined. WTF ?!
Eww, I agree with George here, with respect to these two points. When
I looked at this my first wtf was the @property and then @foo.getter
business. I really don't mind the current way of doing things: attr =
property(get,set). Other mechanisms can be created with getattr
routines. I don't really like this new syntax at all.
For the record, this is not new syntax. It's implemented this way
specifically to avoid the creation of new syntax for properties.
Too many @
marks, inconsistancies, and too many foos everywhere. Not to mention
how long it reads. For only getters, it's not bad though, and a
little better than property().
I don't feel that it's especially inconsistent, and I like decorators.
Having to write foo everywhere isn't that nice, but it's only mildly
worse than C# to me - I find the extra block levels really atrocious.
Decorators really don't feel pythonic to me at all, mostly due to the
@ symbol, but it looks really awful in this instance.
What about this, somewhat similar but not ugly syntax:
class A:
foo = property()
def foo.get():
return self._foo
def foo.delete():
del self._foo
def foo.set(val):
self._foo = val
Defining something with a dot is currently a syntax error. Ok, so
it's still too many foos. At least it's consistent. I'm not really
proposing this btw. I'd rather not introduce more specialized syntax.
How about abusing with:
class A:
with property(foo):
def get
def set...
There's your thunk, and I really like with, but am saddened that it
has such limited use at the moment. Of course this isn't really what
with is for...
Can anyone tell me what's wrong about the current property() syntax,
besides namespace polution?
Nothing, except that people prefer decorators and they don't like the
namespace pollution. foo = property() isn't going away and if you
prefer it (I don't) you're free to use it. If you don't like
decorators in general it's fairly obvious that you won't be partial to
a decorator based feature.
It's not that big a deal anyway, of course, the use case for
properties in Python has a much smaller scope than in C#, and
getter-only properties (which you can create with just @property) are
the majority of those.
--
http://mail.python.org/mailman/listinfo/python-list
Re: python vs perl performance test
On Dec 13, 2007 12:11 PM, [EMAIL PROTECTED] wrote:
First, let me admit that the test is pretty dumb (someone else
suggested it :) but since I am new to Python, I am using it to learn
how to write efficient code.
my $sum = 0;
foreach (1..10) {
my $str = chr(rand(128)) x 1024;
foreach (1..100) {
my $substr = substr($str, rand(900), rand(100));
$sum += ord($substr);
}
}
print Sum is $sum\n;
Basically, the script creates random strings, then extracts random
substrings, and adds up the first characters in each substring. This
perl script takes 8.3 secs on my box and it can probably be improved.
When I first translated it to Python verbatim, the Python script took
almost 30 secs to run.
So far, the best I can do is 11.2 secs using this:
from random import randrange
from itertools import imap, repeat
from operator import getitem, add, getslice
result = 0
zeros = [0]*100
for i in xrange (10):
s = [chr(randrange(128))] * 1024
starts = repeat(randrange(900), 100)
ends = imap(add, starts, repeat(randrange(1,100), 100))
substrs = imap(getslice, repeat(s, 100), starts, ends)
result += sum(imap(ord, imap(getitem, substrs, zeros)))
print Sum is , result
There's got to be a simpler and more efficient way to do this.
Can you help?
Benchmarking is usually done to test the speed of an operation. What
are you trying to measure with this test? String slicing? Numerical
operations? Looping? You're doing all sorts of bogus work for no
reason. The use of randomness is also totally arbitrary and doesn't do
anything except make it harder to confirm the correctness of the test.
Is the ability to generate 0-length substrings (which perl claims have
an ordinal of 0) intentional?
For the record, taking the randomness out makes this take 4 seconds
for perl, and 6 seconds for a literal translation in python. Moving it
into a function drops the python function to 3.5 seconds.
--
http://mail.python.org/mailman/listinfo/python-list
Re: do as a keyword
On Dec 11, 2007 2:19 PM, Steven D'Aprano [EMAIL PROTECTED] wrote: On Tue, 11 Dec 2007 15:06:31 +, Neil Cerutti wrote: When I use languages that supply do-while or do-until looping constructs I rarely need them. ... However, did you have an specific need for a do-while construct? Perhaps we could show you the alternatives. Need is a strong word. After all, all looping constructs could be done with a conditional jump, so arguably we don't need while or for either. But loops that run at least once is a basic element of algorithms. Perhaps not as common as the zero or more times of the while loop, but still fundamental. It is a shame it has to be faked using: I agree that it's fundamental, but I'd like to mention that I've written many thousands of lines of Python code, from throwaway code for demonstration to enterprisey servers and all sorts of things in between and I've *never* written a 1 or more times loop except when I was demonstrating that exact thing. One thing that Python has definitely changed my thinking about is that I tend to formulate both problems and solutions in terms of iteration over sequence rather than as traditional conditional based looping. If I need a 1 or more loop I formulate the problem as a sequence of 1 or more elements. This isn't something I go out of my way to do, simply the way I think about problems in Python. I just did a scan of some of the code I've been working on for the use of while. This is a few thousand LOC (and one project, an SVN renderer, doesn't have any use if it at all) and I've got exactly 3 instances. I've got a while True: as the mainloop of a thread, which technically qualifies as a 1 or more loop but doesn't count because the exit condition is complicated and couldn't be easily written with do..until (you'd either break the same way or you'd have to set a flag instead, which is ugly). I've got the use of while as a counter in some code that unpacks bits from an integer (interop with C structures). It's a 0 or more loop. And I've got an iterator for a linked list, which is close but I don't want to yield anything if the head is None, so it's in a plain while: style: def linkedListIter(head, nextName=next): current = head while current: yield current current = getattr(current, nextName) -- http://mail.python.org/mailman/listinfo/python-list
Re: Is a real C-Python possible?
On Dec 12, 2007 8:36 AM, sturlamolden [EMAIL PROTECTED] wrote: On 12 Des, 12:56, George Sakkis [EMAIL PROTECTED] wrote: Ah, the 'make' statement.. I liked (and still do) that PEP, I think it would have an impact comparable to the decorator syntax sugar, if not more. I think it is one step closer to Lisp. I believe that it would be worth considering adding defmacro statement. Any syntax, including if, else, for, while, class, lambda, try, except, etc. would be implemented with defmacros. We would only need a minimalistic syntax, that would bootstrap a full Python syntax on startup. And as for speed, we all know how Lisp compares to Python. You say that as if one step closer to Lisp is a worthwhile goal. Python has not become what it is, and achieved the success it has, because a bunch of people really wanted to use Lisp but didn't think other people could handle it. The goal of these sorts of discussions should be to make Python a better Python. But what happens far too often (especially with Lispers, but not just them by any means) is that people want to make Python into a clone or better version of whatever other language they like. If you're the sort of person who views lisp as the goal that other languages should aspire to, and I know many of those people exist and even frequent this list, then you should probably spend your time and energy on making Lisp a better Lisp and addressing whatever weaknesses in Lisp have you using Python instead. Trying to fix Lisp (or whatever) by transforming Python into it isn't going to make you any happier, and it's just going to derail any discussion of making Python a better *Python*. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is a real C-Python possible?
On Dec 12, 2007 12:53 PM, George Sakkis [EMAIL PROTECTED] wrote: On Dec 12, 1:12 pm, Christian Heimes [EMAIL PROTECTED] wrote: Kay Schluehr wrote: class A(object): foo = property: def fget(self): return self._foo def fset(self, value): self._foo = value which was translated as follows: class A(object): def thunk(): def fget(self): return self._foo def fset(self, value): self._foo = value return vars() foo = propery(**thunk()) del thunk Python 2.6 and 3.0 have a more Pythonic way for the problem: class A(object): @property def foo(self): return self._foo @foo.setter def foo(self, value) self._foo = value @foo.deletter def foo(self) del self._foo class B(A): # one can even overwrite the getter in a subclass @foo.getter def foo(self): return self._foo * 2 Christian This is by definition Pythonic since it was conceived by the BDFL.It is also certainly an improvement over the current common practice of polluting the class namespace with private getters and setters. Still it's a kludge compared to languages with builtin support for properties. How exactly is this a kludge? This is almost identical syntax (but with less indentation) to a C# property declaration. The only thing that's simpler is auto-generation of trivial accessors via a decoration, but those are useless in Python so only the case of getters and setters that actually do something needs to be addressed. If the only thing that's not a kludge is direct syntax support for a feature, you've set a pretty high and uselessly arbitrary bar. -- http://mail.python.org/mailman/listinfo/python-list
Re: After running for four days, Python program stalled
On Dec 12, 2007 1:34 PM, John Nagle [EMAIL PROTECTED] wrote: Had a Python program stall, using no time, after running OK for four days. Python 2.4, Windows. Here's the location in Python where it's stalled. Any idea what it's waiting for? John Nagle 77FA1428 mov ecx,dword ptr [ebp-10h] 77FA142B mov dword ptr fs:[0],ecx 77FA1432 pop edi 77FA1433 pop esi 77FA1434 pop ebx 77FA1435 leave 77FA1436 ret 10h 77FA1439 cmp dword ptr [ebp-24h],0 77FA143D je 77FA1447 77FA143F pushdword ptr [ebp-24h] 77FA1442 call77F8B5DF 77FA1447 ret 77FA1448 ret 4 77FA144B int 3# STALLED HERE 77FA144C ret 77FA144D int 3 77FA144E ret 77FA144F mov eax,dword ptr [esp+4] 77FA1453 int 3 77FA1454 ret 4 77FA1457 mov eax,dword ptr [ebp-14h] 77FA145A mov eax,dword ptr [eax] 77FA145C mov eax,dword ptr [eax] -- Use a tool like sysinternal procexp to get more useful information about the programs state, like what threads there are and a stack trace with symbols of the each thread. -- http://mail.python.org/mailman/listinfo/python-list
Re: Dumb newbie back in shell
On Dec 11, 2007 8:23 AM, J. Clifford Dyer [EMAIL PROTECTED] wrote: The code you just posted doesn't compile successfully. It *compiles* fine, but it'll raise an error when run. However, in your code, you probably have char_ptr defined at the module level, and you're confused because you didn't declare it as global. Am I right? My crystal ball has a smudge on it, but I think I can still see okay. I assume that's what he think he's seeing also. You can still reference module level variables that aren't declared as global, but you can't assign to them. Or rather, when you try to, you create a new local variable that shadows the global one. No, the determination of what names are local and which are global happens at compile time. The code as posted will not run correctly. It could run if it weren't in a function and were executed in global scope. What's probably happening is that line_ptr last_line is not true and the body of the function isn't executed at all. The unbound local exception is a runtime error that occurs when the local is accessed, not when the function is compiled. -- http://mail.python.org/mailman/listinfo/python-list
Re: Dumb newbie back in shell
On Dec 11, 2007 8:51 AM, Bruno Desthuilliers [EMAIL PROTECTED] wrote: Chris Mellon a écrit : (snip) What's probably happening is that line_ptr last_line is not true Indeed. and the body of the function isn't executed at all. The unbound local exception is a runtime error that occurs when the local is accessed, not when the function is compiled. Now since the compiler already detected the name as local, why wait execution to signal this error ? Because detection assignment to a name in the first AST scan and then using LOAD_FAST and STORE_FAST for access to and assigning to that name is a simple, easy thing to implement, while doing execution analysis to detect that it can't possibly be set before being referenced is really hard. -- http://mail.python.org/mailman/listinfo/python-list
