Re: Convert all images to JPEG
Thomas [EMAIL PROTECTED] wrote: I got a bunch of different images of different types ( bmp, gif, png, tiff etc ) and I want to convert them all to JPEGs using PIL. Is this possible? When I try I get all sorts of errors, doing something like : im = Image.open(srcImage) # might be png, gif etc, for instance test1.png im.thumbnail(size, Image.ANTIALIAS) # size is 640x480 im.save(targetName, JPEG) # targetname is test1.jpg produces an exception. Any clues? the exception contains a pretty strong clue: IOError: cannot write mode P as JPEG adding if im.mode != RGB: im = im.convert(RGB) between the open and thumbnail calls fixes this. /F -- http://mail.python.org/mailman/listinfo/python-list
Problem in threading
I have written a code to figure out the difference in excecution time of a func before and after using threading... [CODE] #!/usr/bin/env python import threading import time loops = [5000,5000] def loop(self, nsec): for i in range(1,nsec): t=i*5000 s=t/10*1 def main(): threads = [] nloops = [0,1] for i in nloops: print '\nSpawning Thread',i,' value: ',loops[i] t = threading.Thread(target=loop,args=(i, loops[i])) threads.append(t) for i in nloops: # start threads threads[i].start() for i in nloops: # wait for all threads[i].join if __name__ == '__main__': start = time.clock() loop(1,5000) print 'Time Taken: ', time.clock()-start start = time.clock() main() print 'Time Taken: ', time.clock()-start [/CODE] Some times this code executes and some times it hangs to death :o( Am I am doing something wrong?? Also the difference of time is not much... How do we best optimize our task by using threads... please help... Thanks and Regards, Gurpreet Singh -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem in threading
Gurpreet Sachdeva wrote: for i in nloops: # wait for all threads[i].join threads[i].join() /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem in threading
Gurpreet Sachdeva [EMAIL PROTECTED] wrote: for i in nloops: # wait for all threads[i].join Missing () after 'join'. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem in threading
threads[i].join() Oh thanks I corrected that but still the time taken after using thread is more without using them Please Advice... Thanks, Gurpreet Singh -- http://mail.python.org/mailman/listinfo/python-list
MDaemon Warning - virus found: Python-list@python.org
*** WARNING ** Este mensaje ha sido analizado por MDaemon AntiVirus y ha encontrado un fichero anexo(s) infectado(s). Por favor revise el reporte de abajo. AttachmentVirus name Action taken -- message.zip I-Worm.Mydoom.m Removed ** Your message was not delivered due to the following reason: Your message could not be delivered because the destination server was unreachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message could not be delivered within 3 days: Mail server 216.135.199.86 is not responding. The following recipients could not receive this message: python-list@python.org Please reply to [EMAIL PROTECTED] if you feel this message to be in error. -- http://mail.python.org/mailman/listinfo/python-list
what would you like to see in a 2nd edition Nutshell?
I'm considering proposing to O'Reilly a 2nd edition of Python in a Nutshell, that I'd write in 2005, essentially to cover Python 2.3 and 2.4 (the current 1st edition only covers Python up to 2.2). What I have in mind is not as complete a rewrite as for the 2nd vs 1st edition of the Cookbook -- Python hasn't changed drastically between 2.2 and 2.4, just incrementally. Language and built-ins additions I'd of course cover -- decorators, custom descriptors (already in 2.2 but not well covered in the 1st edition), importing from zipfiles, extended slicing of built-in sequences, sets, genexps, ... and also major new standard library modules such as (in no special order) optparse, tarfile, bsddb's new stuff, logging, Decimal, cookielib, datetime, email... and new capabilities of existing modules, such as thread-local storage. Outside of the standard library, I was thinking of expanding the coverage of Twisted and adding just a few things (numarray -- perhaps premature to have it _instead_ of Numeric, though; dateutils, paramiko, py2app...). Since the book's size can't change much, I'll also have to snip some stuff (the pre-email ways to deal with mail, for example; modules asyncore and asynchat, probably) to make space for all of the additions. I haven't take any real decisions about it, yet, except one: I'll keep covering Tkinter, rather than moving to, say, wxPython (no space to _add_ wx coverage while leaving Tk intact - having to choose, I still believe Tkinter coverage is going to help more readers). Just about everything else is still to be finalized in my mind... So, if there's any advice or request about a 2nd edition of the Nutshell, this is the right time for y'all to let me know. Feedback is welcome, either privately or right here. Thanks in advance -- _and_ apologies in advance because I know I just won't be able to accomodate all the requests/advice, given the constraints on book size c. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like 's?
[EMAIL PROTECTED] wrote:
Wouldn't it have been better to define tuples with 's or {}'s or
something else to avoid this confusion??
Well, to comment on the part that nobody else did...
and are binary operators, a la 3 1, one two
and {}'s are clearly already used for dictionaries.
--
Brian Beck
Adventurer of the First Order
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter vs wxPython
Sure wxGlade/Boa/etc can help speed design and layout up, but what happens when you want to do non standard things or just get stuck because some thing just isn't working. Then you add the necesary hand crafted code to the automatic generated code. At least is what I did when I needed. -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem in threading
Gurpreet Sachdeva wrote: Also the difference of time is not much... How do we best optimize our task by using threads... please help... For most tasks splitting the processing into separate threads will result in an increase in the total time to complete the task. The only times when it may result in a decrease in the running time are when the time the task takes does not entirely depend on the time taken by the CPU, or when multiple CPU's are involved. Unfortunately the latter case isn't handled well by Python, so don't expect multiple CPU's to help speed up a multi-threaded Python program by very much. That leaves the former case: if your task has to stop and wait for something else to happen (e.g. data to be read from a network, or to be read from a disc file), then splitting it into multiple threads may allow the waits to be overlapped with useful processing which could result in an overall decrease in processing time. A good use of threads is to improve responsiveness of a system. For example if you ensure that GUI processing happens on a separate thread from some CPU intensive computation then you can ensure that the GUI remains responsive while the computation is running. It won't make the computation complete any faster (in fact it will probably be slower), but the user will remain happier. Similarly network applications are usually multi-threaded so that all requests get a fair chance to complete instead of having to wait for the slowest to complete before others can run. If you do have multiple processors available and want to speed up a Python program then you probably have to look at multiple processes rather than multiple threads. Alternatively you could move parts of the processing out of the Python environment by rewriting inner loops in C and releasing the interpreter lock, but that isn't usually the best option. -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
On Wed, 29 Dec 2004 11:35:18 +0100, rumours say that [EMAIL PROTECTED] (Alex Martelli) might have written: [snip: things to cover in a tentative 2nd edition of the nutshell] and new capabilities of existing modules, such as thread-local storage. ...which I most surely missed learning about it. Sometimes it's hard following all the changes, and amk's _What's New_ didn't mention it too (I'm sending a copy of this post to amk). In case others didn't know too, Google's first hit using the obvious query points to: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302088 which is providing code and hints how to find out more about threading.local . Yes, Alex, I am sure a second version of the Nutshell would be much needed; now and then there are discussions about good Python books, and I believe recently someone proposed the Nutshell among others, only to get the reply but it only covers up to 2.2. -- TZOTZIOY, I speak England very best. Be strict when sending and tolerant when receiving. (from RFC1958) I really should keep that in mind when talking with people, actually... -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode entries on sys.path
Martin v. Löwis [EMAIL PROTECTED] writes: Thomas Heller wrote: How should these patches be approached? Please have a look as to how posixmodule.c and fileobject.c deal with this issue. On windows, it would probably be easiest to use the MS generic text routines: _tcslen instead of strlen, for example, and to rely on the _UNICODE preprocessor symbol to map this function to strlen or wcslen. No. This fails for two reasons: 1. We don't compile Python with _UNICODE, and never will do so. This macro is only a mechanism to simplify porting code from ANSI APIs to Unicode APIs, so you don't have to reformulate all the API calls. For new code, it is better to use the Unicode APIs directly if you plan to use them. 2. On Win9x, the Unicode APIs don't work (*). So you need to chose at run-time whether you want to use wide or narrow API. Unless a) we ship two binaries in the future, one for W9x, one for NT+ (I hope this won't happen), or b) we drop support for W9x. I'm in favour of doing so sooner or later, but perhaps not for Python 2.5. I wasn't asking about the *W functions, I'm asking about string/unicode handling in Python source files. Looking into Python/import.c, wouldn't it be required to change the signature of a lot of functions to receive PyObject* arguments, instead of char* ? For example, find_module should change from static struct filedescr *find_module(char *, char *, PyObject *, char *, size_t, FILE **, PyObject **); to static struct filedescr *find_module(char *, char *, PyObject *, PyObject **, FILE **, PyObject **); where the fourth argument would now be either a PyString or PyUnicode object pointer? (*) Can somebody please report whether the *W file APIs fail on W9x because the entry points are not there (so you can't even run the binary), or because they fail with an error when called? I always thought that the *W apis would not be there in win98, but it seems that is wrong. Fortunately, how could Python, which links to the FindFirstFileW exported function for example, run on win98 otherwise... Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: Mutable objects which define __hash__ (was Re: Why are tuples immutable?)
Sections cut where I don't feel I have anything to add to what Bengt already said Bengt Richter wrote: A second time a key may be hashed is when it is used as a lookup key. This can be a reference to the identical key object first used, or it can be a new object. A new object has to be hashed in order to have a hash value to use in finding candidate keys to compare to. If _this_ object is used as a key again, it must be hashed again -- unless it is an object that caches its own hash and invalidates it when mutated so it can rehash itself if its __hash__ method is subsequently called. Thus re-use of a different lookup key than the original provides an opportunity for a performance gain in the lookup if the key object caches it hash value for return by __hash__. That's what I meant by why not? in response to your assertion that the constant hash restriction doesn't (ok, I took that as a can't ;-) provide any performance gain. I'm not sure I'm following here. . . for the case of an object caching its own hash, that seems to be a performance gain that is independent of the dictionary implementation. From the dictionary's point of view, it just calls hash() and works with the result, exactly as it does now. I agree hash caching gives good optimisation - my point was that hash caching can be just as effective in the presence of mutable keys, so long as there is some way to invalidate the cached hash values when a mutation occurs. Given that you assume you know when rehashing is going to be necessary -- meaning you know when keys mutate. Well, yes. Antoon's original complaint was that mutable objects could not be used as keys in dictionary, even if the application guaranteed key stability for the lifetime of the relevant dictionary entry. I gave dict.rehash as a method equivalent to list.sort when working with mutables keys or list entries, respectively. Or resist the temptation to guess, and have rehash() raise an exception :) Easy out ;-) I certainly thought so }: The identity keyed dict was based on Antoon's posted use case: he wanted to classify mutable objects, and then check for membership in those groups. I thought he just wanted to use mutables as if they were immutable, so that equal mutable keys would look up the same value in a dict. That was in the original post, yes. Later, he gave an example that ran something like: for node in graph: if node in some_dict: # Do NOT mutate this node # Possibly do other things continue # Do something that mutates the (non-key) node You can use lists for this, but the lookup is slow. Conventional dictionaries and sets give a fast lookup, but require that the items in use be hashable. A constant hash works. But since it clogs a single bucket and gives no clue of value mismatch, we'd have to time it to see how it compares with list.index. Did the Timbot do both? Write them both? I don't know. However, list.index is a simple linear search of the array of objects (I was reading that code recently for unrelated reasons). The dict hash collision resolution was almost certainly written by Tim - he definitely wrote the comments at the top of the file trying to explain how the heck it works. I have no real clue as to the performance of the lookup algorithm in the degenerate case of a large number of distinct keys having the same hash value, but reading the code suggests it would perform worse than the simple integer increment that list.index uses (as the dict lookup requires multiple if-tests and so forth on each iteration). An identity dictionary (or set) solves the 'object classification' problem perfectly. I missed the definition of those terms I'm afraid ;-) It was in some other part of this rambling thread. It's easier to repeat the idea than it is to go find where that was :) An 'identity dictionary' is just a dict that looks up keys based on identity rather than value. It ignores the keys' actual hash and comparison operations, and forces use of the default hash for hashing, and identity comparison for equality testing. It maps from key _objects_ to values, rather than from key values to other values. An 'identity set' is simply the same idea applied to a set instead of a dictionary. Conceptually, it stores sets of arbitrary objects, rather than sets of values. The 'object classification' problem is simply the situation where you have an existing collection of objects (e.g. graphs of a node), and you want to classify them according to some criteria. Dictionaries or sets are a nice way to do that, but the standard types are a pain if your original objects are mutable (this inconvenience being the basis of Antoon's original complaint). For a classification problem, though, we're likely only interested in what categories each of the original objects falls into - so identity-based storage will usually be entirely adequate (and, in some cases, actually better then value-based storage, since we
Re: what would you like to see in a 2nd edition Nutshell?
On Wed, 29 Dec 2004 11:35:18 +0100, [EMAIL PROTECTED] (Alex Martelli) wrote: So, if there's any advice or request about a 2nd edition of the Nutshell, this is the right time for y'all to let me know. Feedback is welcome, either privately or right here. Thanks in advance -- _and_ apologies in advance because I know I just won't be able to accomodate all the requests/advice, given the constraints on book size c. I understand in advance that my comments are not fully practical: The gap in the market against which I am currently bumpiong up against a wall is in gaining an understanding of threads, sub-processes, sockets, signals and such in Python - having no background in these concepts from outside of Python. Programming concepts up to this level can all (or mostly all) succesfully be learned and understood from materials out there speaking in Python. As to these concepts, the implicit point of view seems to be to leave Python to learn the concepts, and return to Python to understand its implementation of the details, once the concepts are well grasped. It seems to me important that this gap be filled. somehow at some point. The advice of go learn threads in Java and come back then seems a pity. Some of the other concepts which I am confronting I understand to be basic for the C programmer. This is how Python implements these C concepts, which we of course all understand. My hand has been held nicely, too this point then Learn C and come back? Love to. Don't have the time. I am a practicing Python programmer, hoping that can be enough. If I want to no more than be able to follow, say, the current Idle code of the PyShell module, I can find very little guidance from within the canon of Python literature. Help? Art -- http://mail.python.org/mailman/listinfo/python-list
Re: Are tuple really immutable?
I'm suing Google Groups (beta) which has a treeview and my thanks were a reply to Fredrik Lundh. In fact I simply clicked a reply link below his post. Of course you all helped me to better understand the mutable/immutable concept but Fredrik Lundh deserves more thanks since he replied to all my questions ;-) Chris -- http://mail.python.org/mailman/listinfo/python-list
Python + Lisp integration?
Hi, I'm wondering (after a bit of googling) whether there exists a Python binding to any open source Lisp environment (like librep or some Scheme or Common Lisp implementation) that could be recommended for non-toy use? My intention would be to use the Lisp environment to augment and help my Python programming (and/or conversely: have access to the wealth of Python libraries and Python code from a lispy language), which yields at least the following requirements: - the type and runtime environment system would need to be quite transparently integrated, e.g. being able to use (pass, call, set/get attr) Python objects in Lisp and vice versa with minimum hassle - the performance should match at least that of Python's. That probably requires a native interpreter, although the ability to compile Lisp to Python bytecode could do (if the lispy language could be efficiently implemented in the Python bytecode) There are many Scheme/Lisp interpreters written in Python, but those I've found and looked at I consider to be more of proof of concepts. Nesting different interpreters costs probably an order of magnitude in speed. -- http://mail.python.org/mailman/listinfo/python-list
Re: Unicode entries on sys.path
Thomas Heller wrote: I wasn't asking about the *W functions, I'm asking about string/unicode handling in Python source files. Looking into Python/import.c, wouldn't it be required to change the signature of a lot of functions to receive PyObject* arguments, instead of char* ? Yes, that would be one solution. Another solution would be to provide an additional Py_UNICODE*, and to allow that pointer to be NULL. Most systems would ignore that pointer (and it would be NULL most of the time), except on NT+, which would use the Py_UNICODE* if available, and the char* otherwise. I always thought that the *W apis would not be there in win98, but it seems that is wrong. Fortunately, how could Python, which links to the FindFirstFileW exported function for example, run on win98 otherwise... Thanks, that is convincing. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Python + Lisp integration?
On 29 Dec 2004 14:50:53 +0200, Simo Melenius [EMAIL PROTECTED] wrote: Hi, I'm wondering (after a bit of googling) whether there exists a Python binding to any open source Lisp environment (like librep or some Scheme or Common Lisp implementation) that could be recommended for non-toy use? Not sure this is going to help much, but Lush - Lisp Universal Shell - is mature and has bindings to the Python C API. http://lush.sourceforge.net/lush-manual/f0288067.html The bindings are specific to Python22. I had trouble getting all the demos working against Python23. Art -- http://mail.python.org/mailman/listinfo/python-list
Re: portable text user interface
Hello Maxim, Are there widely used and recommended Python libraries that will let me makes a portable text user interface? If you just need a text-like interface you can use Tkinter. See (shameless plug) http://developer.berlios.de/projects/bcd/ and http://developer.berlios.de/dbimage.php?id=1112 for example. If you need something that runs through telnet/ssh ... than curses is what your looking for. There's a win32 port to it somewhere. Bye. -- Miki Tebeka [EMAIL PROTECTED] http://tebeka.bizhat.com The only difference between children and adults is the price of the toys -- http://mail.python.org/mailman/listinfo/python-list
Re: Python + Lisp integration?
Simo Melenius wrote: Hi, I'm wondering (after a bit of googling) whether there exists a Python binding to any open source Lisp environment (like librep or some Scheme or Common Lisp implementation) that could be recommended for non-toy use? My intention would be to use the Lisp environment to augment and help my Python programming (and/or conversely: have access to the wealth of Python libraries and Python code from a lispy language), which yields at least the following requirements: - the type and runtime environment system would need to be quite transparently integrated, e.g. being able to use (pass, call, set/get attr) Python objects in Lisp and vice versa with minimum hassle - the performance should match at least that of Python's. That probably requires a native interpreter, although the ability to compile Lisp to Python bytecode could do (if the lispy language could be efficiently implemented in the Python bytecode) There are many Scheme/Lisp interpreters written in Python, but those I've found and looked at I consider to be more of proof of concepts. Nesting different interpreters costs probably an order of magnitude in speed. When I looked for one I oculdn't find one. As Common Lisp generally runs *considerably* faster than Python it could be a useful thing to have. (Writing python extensions in CLISP would be more 'Pythonic' than writing them in C ?). A two way binding to GNU CLISP would seem a sensible one to implement. Don't think it's already been done though. Regards, Fuzzy http://www.voidspace.org.uk/python/index.shtml -- http://mail.python.org/mailman/listinfo/python-list
Re: Using python to deploy software
Sounds interesting. Do you know if he/she would be willing to share the code? Anand wrote: I haven't but one of my friends have used Pyro (Python Remote Objects) to do so. You basically need to write a custom Pyro server and run it on a central machine. Your pyro clients can be installed on the machines where the software need to be installed. For more details and similar ideas refer the project page of pyro at http://pyro.sourceforge.net/projects.html . -Anand -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: GallerPy 0.6.0
Nice one Freddie. You beat me to it - I had adding a 'header_file' type thingy to gallerpy on my list of things to do. gallerpy will be replacing my static galleries on voidspace 'soon'. Regards, Fuzzy http://www.voidspace.org.uk/python/index.shtml -- http://mail.python.org/mailman/listinfo/python-list
MySQLdb Windows Installer (2.4) published [was: Problems installing MySQLdb on Windows [newbie]]
Alex Meier wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] says... http://pydish.holdenweb.com/pwp/MySQL-python.exe-1.0.0.win32-py2.4.exe That's a ready-to-go no-compilation-required installer for Windows Python 2.4, and will get you going straight away. Thanx a lot, Steve! This worked without a hitch. Great. I don't know what Andy Dustman's situation is right now, but he's clearly not got time to maintain MySQLdb. Since it's likely other people will want this I've added it to the Holden Web public domain Python page at http://www.holdenweb.com/Python/index.html -- that way Google might pick it up, who knows. regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like 's?
Marius Bernklev wrote: * [EMAIL PROTECTED] Perhaps ()'s are a good idea for some other reason I don't know? One-element tuples are written as (4,). And, even there, the parenthesis is only required when it would otherwise be embiguous: x = 4, x (4,) print 4, 4 regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
[Poll] Frameworks for Web Development
Dear all, I want to propose a small "poll" about frameworks tools that you use to develop web applicationsin Python. I think it would be interesting if you could list your favourite tools as well as explain the reasons for your choice. Thanks in advance, Antonio--My programming blog: http://antoniocangiano.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter vs wxPython
Alejandro Weinstein wrote: Sure wxGlade/Boa/etc can help speed design and layout up, but what happens when you want to do non standard things or just get stuck because some thing just isn't working. Then you add the necesary hand crafted code to the automatic generated code. At least is what I did when I needed. I've tried a number of these tools, including BlackAdder, wxDesigner, wxGlade and BoaConstructor. I even paid money for some of them. They all have their problems, and I keep coming back to good old PythonCard. It's kinda clunky (though I have most experience with the 0.7 prototype, and the newer releases are improving), but it's definitely the most usable of all the ones I've tried. Dammit, you can actually *do stuff* with it rather than spend all your time fighting the tool. The only complaint I have is the need to add components from a menu rather than a tool, but I patched 0.7 to fix that, and I believe it will be possible to patch the 0.8 series to operate the same way. Whether I'll ever persuade Kevin Altis to include the patch in a live release is, of course, a question for another day :-) regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like 's?
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Tuples are defined with regards to parentheses ()'s as everyone knows.
To expand on what Alex Martelli said:
Tuples don't use parentheses except for the special case of the
empty tuple. Those are expression parentheses. The two most
obvious cases of this are in the return statement and sequence
unpacking in assignment statements.
Grouping syntax is used for both unary operators and operands.
Parentheses are used for expressions (operands) and
function/method parameter lists (operators). Brackets ([])
are used for lists (operands) and subscripts/slices (operators).
Braces ({}) are used for dictionarys (operands). They aren't
currently used for unary operators.
John Roth
Please enlighten me as I really want to know.
Chris
P.S. I love Python!
--
http://mail.python.org/mailman/listinfo/python-list
Re: portable text user interface
Miki Tebeka wrote: Hello Maxim, Are there widely used and recommended Python libraries that will let me makes a portable text user interface? If you just need a text-like interface you can use Tkinter. See (shameless plug) http://developer.berlios.de/projects/bcd/ and http://developer.berlios.de/dbimage.php?id=1112 for example. Hello Miki, Your project looks very interesting. It would be better if it displayed an error message if it can't find the '_bcdrc' file. If you run it from windoze it just appears and disapears. How about allowing the '_bcdrc' file to be in the same directory as the script as well. Any chance of you releasing the Tkinter text interface as a separate library, with a less restrictive license ? It looks very good - but I can't use it in my projects if it is GPL. Regards, Fuzzy http://www.voidspace.org.uk/python/index.shtml If you need something that runs through telnet/ssh ... than curses is what your looking for. There's a win32 port to it somewhere. Bye. -- Miki Tebeka [EMAIL PROTECTED] http://tebeka.bizhat.com The only difference between children and adults is the price of the toys -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
On Wed, 29 Dec 2004 14:05:18 +0200, rumours say that Christos TZOTZIOY Georgiou [EMAIL PROTECTED] might have written: [snip: things to cover in a tentative 2nd edition of the nutshell] [Alex] and new capabilities of existing modules, such as thread-local storage. [I] ...which I most surely missed learning about it. Sometimes it's hard following all the changes, and amk's _What's New_ didn't mention it too (I'm sending a copy of this post to amk) ...and most promptly amk replied by pointing to http://docs.python.org/whatsnew/node13.html where it is indeed mentioned. So I stand corrected, mea culpa etc :) -- TZOTZIOY, I speak England very best. Be strict when sending and tolerant when receiving. (from RFC1958) I really should keep that in mind when talking with people, actually... -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like 's?
On 2004-12-29, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Tuples are defined with regards to parentheses ()'s as everyone knows. Except they're not. x = 1,2,3,4 type(x) type 'tuple' Tuples are defined by the infix comma operator. -- Grant Edwards grante Yow! I'm working under at the direct orders of WAYNE visi.comNEWTON to deport consenting adults! -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
[EMAIL PROTECTED] (Alex Martelli) writes: I'm considering proposing to O'Reilly a 2nd edition of Python in a Nutshell, that I'd write in 2005, essentially to cover Python 2.3 and 2.4 (the current 1st edition only covers Python up to 2.2). What I have in mind is not as complete a rewrite as for the 2nd vs 1st edition of the Cookbook -- Python hasn't changed drastically between 2.2 and 2.4, just incrementally. Language and built-ins additions I'd of course cover -- decorators, custom descriptors (already in 2.2 but not well covered in the 1st edition), importing from zipfiles, extended slicing of built-in sequences, sets, genexps, ... and also major new standard library modules such as (in no special order) optparse, tarfile, bsddb's new stuff, logging, Decimal, cookielib, datetime, email... and new capabilities of existing modules, such as thread-local storage. Outside of the standard library, I was thinking of expanding the coverage of Twisted and adding just a few things (numarray -- perhaps premature to have it _instead_ of Numeric, though; dateutils, paramiko, py2app...). Since the book's size can't change much, I'll also have to snip some stuff (the pre-email ways to deal with mail, for example; modules asyncore and asynchat, probably) to make space for all of the additions. I haven't take any real decisions about it, yet, except one: I'll keep covering Tkinter, rather than moving to, say, wxPython (no space to _add_ wx coverage while leaving Tk intact - having to choose, I still believe Tkinter coverage is going to help more readers). Just about everything else is still to be finalized in my mind... So, if there's any advice or request about a 2nd edition of the Nutshell, this is the right time for y'all to let me know. Feedback is welcome, either privately or right here. Thanks in advance -- _and_ apologies in advance because I know I just won't be able to accomodate all the requests/advice, given the constraints on book size c. I found the discussion of unicode, in any python book I have, insufficient. Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
I found the discussion of unicode, in any python book I have, insufficient. Thomas +1 Don -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like 's?
In article [EMAIL PROTECTED], Grant Edwards [EMAIL PROTECTED] wrote: On 2004-12-29, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Tuples are defined with regards to parentheses ()'s as everyone knows. Except they're not. x = 1,2,3,4 type(x) type 'tuple' Tuples are defined by the infix comma operator. Well, the syntax is a little more complicated than that. Commas don't form tuples in a lot of places: f (1, 2, 3)# function call gets three scalar arguments [1, 2, 3] # list of three integers, not list of tuple [x, 1 for x in blah] # syntax error, needs to be [(x, 1) for ...] I'm sure there are others. The meaning of , depends on the context in which it appears. In most cases, the parens around tuples are optional except when necessary to disambiguate, but there's one degenerate special case, the empty tuple (zerople?), where the parens are always required. It's just one of those little warts you have to live with. If Python had originally been invented in a unicode world, I suppose we wouldn't have this problem. We'd just be using guillemots for tuples (and have keyboards which made it easy to type them). -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
As an already-experienced programmer, I came to Python via this book and still use it as my primary reference. As a Python beginner, I had a difficult time with the section on Slicing a sequence (p. 47). In particular, a better explanation and examples of negative indicies would be helpful. This is nitpicking in what I consider to be a very good book. I hope the second edition flies. Cheers, Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: extract news article from web
On 22 Dec 2004 09:22:15 -0800, Zhang Le [EMAIL PROTECTED] wrote: Hello, I'm writing a little Tkinter application to retrieve news from various news websites such as http://news.bbc.co.uk/, and display them in a TK listbox. All I want are news title and url information. Well, the BBC publishes an RSS feed[1], as do most sites like it. You can read RSS feed with Mark Pilgrim's Feed Parser[2]. Granted, you can't read *every* site like this. But I daresay that *most* news related sites publish feeds of some kind these days. Where they do, using the feed is a *far* better idea than trying to parse the HTML. -- Cheers, Simon B, [EMAIL PROTECTED], http://www.brunningonline.net/simon/blog/ [1] http://news.bbc.co.uk/2/hi/help/3223484.stm [2] http://feedparser.org/ -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
Alex Martelli wrote: I'm considering proposing to O'Reilly a 2nd edition of Python in a Nutshell, that I'd write in 2005, essentially to cover Python 2.3 and 2.4 (the current 1st edition only covers Python up to 2.2). So, if there's any advice or request about a 2nd edition of the Nutshell, this is the right time for y'all to let me know. Feedback is welcome, either privately or right here. Thanks in advance -- _and_ apologies in advance because I know I just won't be able to accomodate all the requests/advice, given the constraints on book size c. * code coverage tools for python code (testing your tests). * new-style classes forward and old-style shrunk. best practices such as always super(class, self).__init__(...) and why even if why is only a forward reference. Using Left(object), Right(object), Top(Left, Right) would be good for the example. ** Fix the examples in Inheritance in new-style object model, the diagram, and the following example in cooperative superclass method calling to use the same hierarchy. I personally prefer the A(object), B(A), C(A), D(B,C) hierarchy, but they should match. * implementing types/classes in C -- a checklist w/ advice on testing. --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
I second that Regards, Fuzzy http://www.voidspace.org.uk/python/index.shtml -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
I like the current edition. Since it is a reference work, I would like to see it in a CD-ROM as well as in print, either packaged with a book or as part of a Python CD Bookshelf, analogous to the other CD bookshelves O'Reilly offers. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why are tuples immutable?
Antoon Pardon wrote: Op 2004-12-23, Scott David Daniels schreef [EMAIL PROTECTED]: This is half the problem. In the period where an element is in the wrong hash bucket, a new entry for the same value can be created in the proper hash bucket. Then the code will have to determine how to merge two entries at rehash time. But similar problems can happen in a sorted list, where the sort is done on a key of the data and where you don't want duplicate keys. If you then mutate a key, it may be possible to insert a duplicate key in the sorted list because the list isn't sorted anymore. If you then resort your list you also have to determine how to merge the two items with the same key I'd say this is a stretch. The key argument to sort is very new, and it is a function from data to a value. The key can be mutated only if the key function is picking out a mutable part of a data element. This just to show that repairing sorted lists can be just as troublesome as repairing dictionaries. People who think sorted lists of mutable objects is less bothersome as dictionaries with mutable keys, haven't thought things through IMO. But Python has no sorted list data type, so it is perfectly reasonable to expect such lists to go through transitional representations. A set should not briefly have duplicate elements, a list should not vary in length when elements are replaced, an integer being continuously incremented should not be viewable from a separate thread as anything but monotonicly increasing; dictionaries are primitives and should not have observable transitional states. --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: learning about threads and processes (was Re: what would you like to see in a 2nd edition Nutshell?)
In article [EMAIL PROTECTED], Alex Martelli [EMAIL PROTECTED] wrote: Hmmm - have you looked at Deitel, Deitel, Liperi, Wiedermann, Python how to program, chapters 18 (Process Management) and 19 (Multithreading), pages 613-687? They seem to do a rather workmanlike job -- of course, they can't do full justice to the subjects in 75 pages; and if you don't want to buy a vast, costly 1300-pages tome for the sake of those 75 pages, I can't really blame you, either. Except that it's a really, really piss-poor book. That's an opinion which I believe you've agreed with previously. And what about Norman Matloff's http://heather.cs.ucdavis.edu/~matloff/Python/PyThreads.pdf, the first google hit if you're looking for python threads ? I haven't looked into it, but, again, without some specific explanation of how it fails to meet your needs, it's hard to offer alternatives. That's actually pretty good. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis -- http://mail.python.org/mailman/listinfo/python-list
Re: objects as mutable dictionary keys
On 2004-12-29 14:04:19, Nick Coghlan wrote: This *is* a bug (since Guido called it such), but one not yet fixed as the obvious solution (removing object.__hash__) causes problems for Jython, and a non-obvious solution has not been identified. class object: def __hash__(self): # Need to check if our instance has defined some other # comparison functions without overloading __hash__ for f in __cmp__ __eq__.split(): if not hasattr(self, f): continue # It has the function, but is it the same as in # object? f1 = getattr(self, f) f2 = getattr(object, f) if f1.im_func != f2.im_func: raise TypeError, unhashable instance return id(self) (..) Of course this won't work, as self.__cmp__ and it's like are so-called method-wrapper objects, and I can't immediately see a way to retrieve the original function behind this. Also, it might be possible that someone does something like this: class A(object): def __init__(self, use_id=True): self.use_id = use_id def __eq__(self, other): if self.use_id: return super(A, self).__eq__(other) else: return something_else def __hash__(self, other): if self.use_id: return super(A, self).__hash__(other) else: return something_else This will break the object.__hash__ shown above.. What about checking if __hash__ has been overridden as well, and if so, always return id()? -- Stian Søiland Work toward win-win situation. Win-lose Trondheim, Norway is where you win and the other lose. http://soiland.no/ Lose-lose and lose-win are left as an exercise to the reader. [Limoncelli/Hogan] Og dette er en ekstra linje -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like 's?
Roy Smith [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] In article [EMAIL PROTECTED], Grant Edwards [EMAIL PROTECTED] wrote: On 2004-12-29, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Tuples are defined with regards to parentheses ()'s as everyone knows. Except they're not. x = 1,2,3,4 type(x) type 'tuple' Tuples are defined by the infix comma operator. Well, the syntax is a little more complicated than that. Commas don't form tuples in a lot of places: f (1, 2, 3)# function call gets three scalar arguments [1, 2, 3] # list of three integers, not list of tuple [x, 1 for x in blah] # syntax error, needs to be [(x, 1) for ...] I'm sure there are others. The meaning of , depends on the context in which it appears. This is true, however all three cases you mention are part of the grammar. In any case, the function call syntax isn't dependent on it following a function name; it's dependent on it appearing where an operator is expected in the expression syntax. In most cases, the parens around tuples are optional except when necessary to disambiguate, but there's one degenerate special case, the empty tuple (zerople?), where the parens are always required. It's just one of those little warts you have to live with. That one doesn't require the comma, either. It's a very definite special case. If Python had originally been invented in a unicode world, I suppose we wouldn't have this problem. We'd just be using guillemots for tuples (and have keyboards which made it easy to type them). I suppose the forces of darkness will forever keep Python from requiring utf-8 as the source encoding. If I didn't make a fetish of trying to see the good in everybody's position, I could really work up a dislike of the notion that you should be able to use any old text editor for Python source. There are a lot of Unicode characters that would be quite helpful as operators. A left pointing arrow would be a vast improvement over the equal sign for assignment, for example. There wouldn't be any chance of mixing it up with the double equal for comparisons. The same thing goes for multiplication and division. We've allowed ourselves to be limited by the ASCII character set for so long that improving that seems to be outside of most people's boxes. John Roth -- http://mail.python.org/mailman/listinfo/python-list
calling functions across threads
I'm playing around with some threading stuff right now, and I'm having a
little trouble calling a function from one thread that affects another.
Here's my setup:
py import os, threading, time
py def write(file_in, input_lines):
... for line in input_lines:
... time.sleep(0.5)
... file_in.write(line)
... file_in.flush()
... file_in.close()
...
py def read(file_out, output_list):
... while True:
... line = file_out.readline()
... if not line:
... break
... output_list.append(line)
...
py def runthreads(lst):
... file_in, file_out, file_err = os.popen3('cat')
... write_thread = threading.Thread(
... target=write, args=(file_in,
... ['%s\n' % x for x in range(10)]))
... read_thread = threading.Thread(target=read,
...args=(file_out, lst))
... write_thread.start()
... read_thread.start()
... write_thread.join()
... read_thread.join()
...
Basically, I start one thread to read and one thread to write (from a
os.pipe). This all works fine for me:
py lst = []
py runthreads(lst)
py lst
['0\n', '1\n', '2\n', '3\n', '4\n', '5\n', '6\n', '7\n', '8\n', '9\n']
I run into a problem though when I try to call an update method every
time I read a line:
py class updatinglist(list):
... def __init__(self, updater):
... super(updatinglist, self).__init__()
... self.updater = updater
... def append(self, item):
... super(updatinglist, self).append(item)
... self.updater(len(self))
...
py def update(i):
... print i
...
py lst = updatinglist(update)
py runthreads(lst)
1
2
3
4
5
6
7
8
9
10
py lst
['0\n', '1\n', '2\n', '3\n', '4\n', '5\n', '6\n', '7\n', '8\n', '9\n']
I get the correct output, but if you run this yourself, you'll see that
the numbers 1 through 10 aren't printed in sync with the writes (i.e.
every half second); they're all printed at the end. Could someone
explain to me why this happens, and how (if possible) I can get the
numbers printed in sync with the appends to the list?
Thanks,
Steve
--
http://mail.python.org/mailman/listinfo/python-list
Re: Other notes
[EMAIL PROTECTED] writes:
@infix
def interval(x, y): return range(x, y+1) # 2 parameters needed
This may allow:
assert 5 interval 9 == interval(5,9)
I don't like the idea of turning words into operators. I'd much rather
see something like:
@infix('..')
def interval(x, y):
return range(x, y + 1)
assert 5 .. 9 == interval(5, 10)
This would also allow us to start working on doing away with the magic
method names for current operators, which I think would be an
improvement.
As others have pointed out, you do need to do something about operator
precedence. For existing operators, that's easy - they keep their
precedence. For new operators, it's harder.
You also need to worry about binding order. At the very least, you
can specify that all new operators bind left to right. But that might
not be what you want.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
RE: Best GUI for small-scale accounting app?
Title: RE: Best GUI for small-scale accounting app? From: Paul Rubin [mailto:http://phr.cx@NOSPAM.invalid] This still seems way too complicated. Why execute a bunch of separate statements when what you're trying to set up is a single structure? IMHO, i think that the code to create elements is the less important one. I put myself to learn python toolkits in one day. I picked up gtk, tk and wxWindow. I learned how to create the elements in seconds. all have a fairly good documentation on that. But when it cames down to position stuff... that was hell. Or you have a easy way to position things, but are limited for text direction (important in multi-locale programs), limited in font size (important for multiple resolutions) and mainly limited in window resizing (you have to write code for resize). Or you have to add two hundred panes and invisible elements to have flexibility on the above issues. What i'm doing now, is to learn very all Tk, and make a xml scheme for UI. window spliter width=100% direction=vertical resizable=yes pane width=60% button label=this one is on the left / /pane pane label text=this pane has a implicit size of 40% / button text=this one is on the right click=methodName / /pane /spliter /window Easy to visualize. I'm just struggling with the best way to deal with runtime modifications of the GUI... apreciate any comments (this will be up on sourceforce soon) Gabriel -- http://mail.python.org/mailman/listinfo/python-list
RE: Best GUI for small-scale accounting app?
Title: RE: Best GUI for small-scale accounting app? But even then, if DaBo ever becomes as easy to use as Delphi/VB for this type of applications, while remaining cross-platform, that might easily double the number of Python developers. ;-) VB/delphi are ridiculous. dont' aim to that direction. the ONLY reason both are sucessful is that they're widely deployed. There's thousands of college professors that only got their positions because they have M$certs or are in the institution long enough to know people who can keep their positions and never minded learning something else then pascal and cobol. Then, they show VB/delphi to the newcomers, how get a pirated copy and start wasting time over it. -- http://mail.python.org/mailman/listinfo/python-list
RE: Best GUI for small-scale accounting app?
Title: RE: Best GUI for small-scale accounting app? - speed where it matters (ie. no 20s load time) Load what? The app, or the data? Users don't care how long the app takes to start up, since they usually run it all day long. Data response is a whole 'nother matter, and Dabo is extremely fast in that regard. After all, a data set is nothing more than lists of lists, and Python is wicked fast with list handling. as a jEdit, mozilla, and bloated games user i can assure you that you're right at some point, but as a openoffice hater, you can see it's not the lawn even with one single user. So, to be more direct: If you create one app that opens one window with one button in wxWindow and exit (exit, so that 'time' can canculate it for you), and then the same thing in Dabo, what's the time diference? Thanks, Gabriel -- http://mail.python.org/mailman/listinfo/python-list
Re: Other notes
Mike Meyer wrote:
[EMAIL PROTECTED] writes:
@infix
def interval(x, y): return range(x, y+1) # 2 parameters needed
This may allow:
assert 5 interval 9 == interval(5,9)
I don't like the idea of turning words into operators. I'd much rather
see something like:
@infix('..')
def interval(x, y):
return range(x, y + 1)
assert 5 .. 9 == interval(5, 10)
This would also allow us to start working on doing away with the magic
method names for current operators, which I think would be an
improvement.
Well, perhaps you can explain how a change that's made at run time
(calling the decorator) can affect the parser's compile time behavior,
then. At the moment, IIRC, the only way Python code can affect the
parser's behavior is in the __future__ module, which must be imported at
the very head of a module.
As others have pointed out, you do need to do something about operator
precedence. For existing operators, that's easy - they keep their
precedence. For new operators, it's harder.
Clearly you'd need some mechanism to specify preference, either
relatively or absolutely. I seem to remember Algol 68 allowed this.
You also need to worry about binding order. At the very least, you
can specify that all new operators bind left to right. But that might
not be what you want.
Associativity and precedence will also have to affect the parsing of the
code, of course. Overall this would be a very ambitious change.
regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 94 3119
--
http://mail.python.org/mailman/listinfo/python-list
Re: Other notes
On Wed, 29 Dec 2004 11:42:00 -0600, Mike Meyer [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: @infix def interval(x, y): return range(x, y+1) # 2 parameters needed This may allow: assert 5 interval 9 == interval(5,9) I don't like the idea of turning words into operators. I'd much rather see something like: Really? I like not, and, or, is, and in. It would not be nice if they were replaced with punctuation. This aside, not even Python 3.0 will be flexible enough to let you define an infix decorator. The language developers are strongly against supporting macros, which is what an infix decorator would amount to. Now, they might be convinced to add a new syntax that makes a function into an infix operator. Perhaps something like this: def (..)(x, y): return range(x, y + 1) This is much better than supporting macros because it will lead to a 6 month long debate over the exact syntax and adds exactly zero other features to the language (whereas macros let you pick your own syntax and give you essentially unlimited other abilities). Jp -- http://mail.python.org/mailman/listinfo/python-list
copying classes?
Hi all, In the documentation of module 'copy' it is said that This version does not copy types like module, class, function, method, stack trace, stack frame, file, socket, window, array, or any similar types. Does anyone know another way to (deep)copy objects of type class? What is special about the objects of these types that they cannot be easily copied? Any help appreciated, - harold - -- I like pigs. Dogs look up to us. Cats look down to us. Pigs treat us as equal. -- Winston Churchill -- http://mail.python.org/mailman/listinfo/python-list
RE: A scoping question
Title: RE: A scoping question myBaseClass.AddChild(file2.NextClass()) [snip] class NextClass: def __init__(self): for eachChild in myBaseClass.MyChilds: # - ERROR ... I never assumes globals in my classes. always pass them as parameters. it's safer and better to understand later. Also, makes it easier to reuse the code later on. myBaseClass.AddChild( file2.NextClass( myBaseClass ) ) Gabriel -- http://mail.python.org/mailman/listinfo/python-list
Re: Using python to deploy software
Would the pyro client need to be installed as a service on the machine so it could run the installer as the system acct? Otherwise, it would run with the current user's credentials. Anand wrote: I haven't but one of my friends have used Pyro (Python Remote Objects) to do so. You basically need to write a custom Pyro server and run it on a central machine. Your pyro clients can be installed on the machines where the software need to be installed. For more details and similar ideas refer the project page of pyro at http://pyro.sourceforge.net/projects.html . -Anand -- http://mail.python.org/mailman/listinfo/python-list
Re: Other notes
Jp Calderone [EMAIL PROTECTED] writes: On Wed, 29 Dec 2004 11:42:00 -0600, Mike Meyer [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: @infix def interval(x, y): return range(x, y+1) # 2 parameters needed This may allow: assert 5 interval 9 == interval(5,9) I don't like the idea of turning words into operators. I'd much rather see something like: Really? I like not, and, or, is, and in. It would not be nice if they were replaced with punctuation. They can't be turned into operators - they already are. This aside, not even Python 3.0 will be flexible enough to let you define an infix decorator. The language developers are strongly against supporting macros, which is what an infix decorator would amount to. Could you please explain how allowing new infix operators amount to supporting macros? Now, they might be convinced to add a new syntax that makes a function into an infix operator. Perhaps something like this: def (..)(x, y): return range(x, y + 1) And while you're at it, explain how this method of defining new infix operators differs from using decorators in such a way that it doesn't amount to supporting macros. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Other notes
Steve Holden [EMAIL PROTECTED] writes:
Mike Meyer wrote:
[EMAIL PROTECTED] writes:
@infix
def interval(x, y): return range(x, y+1) # 2 parameters needed
This may allow:
assert 5 interval 9 == interval(5,9)
I don't like the idea of turning words into operators. I'd much
rather
see something like:
@infix('..')
def interval(x, y):
return range(x, y + 1)
assert 5 .. 9 == interval(5, 10)
This would also allow us to start working on doing away with the
magic
method names for current operators, which I think would be an
improvement.
Well, perhaps you can explain how a change that's made at run time
(calling the decorator) can affect the parser's compile time behavior,
then. At the moment, IIRC, the only way Python code can affect the
parser's behavior is in the __future__ module, which must be imported
at the very head of a module.
By modifying the parsers grammer at runtime. After all, it's just a
data structure that's internal to the compiler.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: copying classes?
copy.deepcopy() should do the trick. This URL answers a little bit of your question about the difficulties in copying complex data structures. http://pydoc.org/2.3/copy.html -Bob On Wed, 2004-12-29 at 19:29 +0100, harold fellermann wrote: Hi all, In the documentation of module 'copy' it is said that This version does not copy types like module, class, function, method, stack trace, stack frame, file, socket, window, array, or any similar types. Does anyone know another way to (deep)copy objects of type class? What is special about the objects of these types that they cannot be easily copied? Any help appreciated, - harold - -- I like pigs. Dogs look up to us. Cats look down to us. Pigs treat us as equal. -- Winston Churchill -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem in threading
Duncan Booth [EMAIL PROTECTED] writes: That leaves the former case: if your task has to stop and wait for something else to happen (e.g. data to be read from a network, or to be read from a disc file), then splitting it into multiple threads may allow the waits to be overlapped with useful processing which could result in an overall decrease in processing time. If you're on a Unix-like system, you'll use less aspirin if you do this kind of thing with async I/O and the select module. If you're on Windows, the restrictions on what you can select on make it much less useful. Python's threading models is pretty primitive. You get the C model (which is error-prone), the Java model (in 2.4, and also error-prone), or Queues. Queues aren't error-prone, but result in the same kind of behavior as you get with select: start I/O, do computing while I/O is going on, block until I/O is complete. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for small-scale accounting app?
On Dec 29, 2004, at 1:06 PM, Gabriel Cosentino de Barros wrote: So, to be more direct: If you create one app that opens one window with one button in wxWindow and exit (exit, so that 'time' can canculate it for you), and then the same thing in Dabo, what's the time diference? I used the timeit module to run the programs you suggested 10 times apiece, and the average times for each were: plain wxPython: 0.57768230438 Dabo: 0.6913671494 When you consider that the main app in Dabo also sets up a number of things that the wx.PySimpleApp doesn't, this is better than I imagined. Thanks for the impetus to run this test. ___/ / __/ / / Ed Leafe http://leafe.com/ http://dabodev.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: calling functions across threads
Steven Bethard [EMAIL PROTECTED] writes: I get the correct output, but if you run this yourself, you'll see that the numbers 1 through 10 aren't printed in sync with the writes (i.e. every half second); they're all printed at the end. Could someone explain to me why this happens, and how (if possible) I can get the numbers printed in sync with the appends to the list? I tried your code, and got the expected behaviour, i.e. the numbers are printed every half second. Maybe you have a buffering problem? $ python2.4 -V Python 2.4 $ uname -a Linux thomas 2.6.9 #6 Sun Dec 19 17:45:53 CET 2004 i686 GNU/Linux - Thomas -- If you want to reply by mail, substitute my first and last name for 'foo' and 'bar', respectively, and remove '.invalid'. -- http://mail.python.org/mailman/listinfo/python-list
Re: copying classes?
Ha. I just read down to the bottom of pyDoc page. This version does not copy types like module, class, function, method, nor stack trace, stack frame, nor file, socket, window, nor array, nor any similar types. However, I actually tried it and it worked at least in the simple case: class x: ... def __init__(self): ... self.y = 1 ... obj = x() obj.y 1 import copy z = copy.deepcopy(obj) z.y 1 obj.y = 4 obj.y 4 z = copy.deepcopy(obj) z.y 4 -Bob On Wed, 2004-12-29 at 10:42 -0800, Bob Van Zant wrote: copy.deepcopy() should do the trick. This URL answers a little bit of your question about the difficulties in copying complex data structures. http://pydoc.org/2.3/copy.html -Bob On Wed, 2004-12-29 at 19:29 +0100, harold fellermann wrote: Hi all, In the documentation of module 'copy' it is said that This version does not copy types like module, class, function, method, stack trace, stack frame, file, socket, window, array, or any similar types. Does anyone know another way to (deep)copy objects of type class? What is special about the objects of these types that they cannot be easily copied? Any help appreciated, - harold - -- I like pigs. Dogs look up to us. Cats look down to us. Pigs treat us as equal. -- Winston Churchill -- http://mail.python.org/mailman/listinfo/python-list
Re: Other notes
On Wed, 29 Dec 2004 12:38:02 -0600, Mike Meyer [EMAIL PROTECTED] wrote: Jp Calderone [EMAIL PROTECTED] writes: On Wed, 29 Dec 2004 11:42:00 -0600, Mike Meyer [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: @infix def interval(x, y): return range(x, y+1) # 2 parameters needed This may allow: assert 5 interval 9 == interval(5,9) I don't like the idea of turning words into operators. I'd much rather see something like: Really? I like not, and, or, is, and in. It would not be nice if they were replaced with punctuation. They can't be turned into operators - they already are. They weren't operators at some point (if necessary, select this point prior to the creation of the first programming language). Later, they were. Presumably in the interim someone turned them into operators. This aside, not even Python 3.0 will be flexible enough to let you define an infix decorator. The language developers are strongly against supporting macros, which is what an infix decorator would amount to. Could you please explain how allowing new infix operators amount to supporting macros? You misread - I said what an infix decorator would amount to. Adding new infix operators is fine and in no way equivalent to macros. As you said in your reply to Steve Holden in this thread, one way support for @infix could be done is to allow the decorator to modify the parser's grammar. Doesn't this sound like a macro to you? Now, they might be convinced to add a new syntax that makes a function into an infix operator. Perhaps something like this: def (..)(x, y): return range(x, y + 1) And while you're at it, explain how this method of defining new infix operators differs from using decorators in such a way that it doesn't amount to supporting macros. Simple. You can't do anything except define a new infix operator with the hypothetical def ( operator ) syntax. With real macros, you can define new infix operators, along with any other syntactic construct your heart desires. Jp -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
Alex Martelli wrote: the coverage of Twisted and adding just a few things (numarray -- perhaps premature to have it _instead_ of Numeric, though; dateutils, You might want to keep in touch with the scipy/numarray gang on this particular topic. An effort is currently under way to make scipy work with numarray, and matplotlib already works with numarray out of the box. These two facts will, I think, greatly accelerate the adoption of numarray and the transition away from Numeric. There are a few people (like me, unfortunately), who can simply not use numarray because of the small array instatiation overhead. But that subcommunity tends to know enough to be able to deal with the problems by itself. Since numarray is indeed the long-term array core for Python, I think the book would be better off by covering it. Numarray is actively developed, and vastly better documented than Numeric. A mention of the particular problems with numarray might be a good idea, so that readers are aware of Numeric and where it may still be preferable to numarray, but with the understanding that it's a (shrinking) niche. Hopefully one day that niche will shrink to zero, but that is going to take time and work. Finally, I think in this section a mention of the overall scipy project would be a good idea. Scipy is the central meeting point for most scientific computing projects in python, and therefore a natural reference for most users of numarray/numeric. Amongst other useful things at the scipy site, there's a community maintained wiki of links to python-based projects of scientific interest: http://www.scipy.org/wikis/topical_software/TopicalSoftware Regards, f -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
On Wed, 2004-12-29 at 23:54, Thomas Heller wrote: I found the discussion of unicode, in any python book I have, insufficient. I couldn't agree more. I think explicit treatment of implicit conversion, the role of sysdefaultencoding, the u'' constructor and unicode() built in, etc would be helpful to many. A clear explanation of why Python strings, despite being assumed to be ASCII, can contain any 8-bit data in any text encoding (or no text encoding at all) may also help newbies. I spent a while fighting to understand the way python handles encodings a while ago and benefited significantly from it - but there really needs to be a good explanation. The relationship between 'str' and 'unicode' objects, the way implicit conversion works with sysdefaultencoding, and how explicit conversions between encodings and to/from unicode, in particular, need attention. It'd also be REALLY good to mention the role of, and importance of, the coding: line. An explanation of its relationship with the interpretation of strings in the script, and with the sysdefaultencoding, would also be helpful, as IMO the script encodings PEP only really makes sense once you already understand it. It wouldn't hurt to point C extension authors at things like the 'es' encoded string format for PyArg_ParseTuple to help them make their code better behaved with non-ascii text. -- Craig Ringer -- http://mail.python.org/mailman/listinfo/python-list
Re: calling functions across threads
Steven Bethard wrote: I get the correct output, but if you run this yourself, you'll see that the numbers 1 through 10 aren't printed in sync with the writes (i.e. every half second); they're all printed at the end. Could someone explain to me why this happens, and how (if possible) I can get the numbers printed in sync with the appends to the list? This is just a shot in the dark, as I'm quite ignorant of threading details. But what happens if you try adding a sys.stdout.flush() call after the print statement in your custom update() method? It may just be a flushing problem what makes the output appear out of sync... Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: copying classes?
You copied an instance, not a class. Here's an example of attempting to deepcopy a class: class X: pass ... import copy X is copy.deepcopy(X) Traceback (most recent call last): File stdin, line 1, in ? File /usr/lib/python2.2/copy.py, line 179, in deepcopy raise error, \ copy.Error: un-deep-copyable object of type type 'class' In theory, one could provide a metaclass that allows copying of instances of that metaclass. I'll leave this as an exercise to the reader. Jeff pgpjJrXN93ruF.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: objects as mutable dictionary keys
Nick Coghlan [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] This *is* a bug (since Guido called it such), but one not yet fixed as the obvious solution (removing object.__hash__) causes problems for Jython, and a non-obvious solution has not been identified. Since object was added in 2.2 and the most recently released Jython I know about is 2.1, are you referring to a newer version in development? tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: calling functions across threads
Fernando Perez wrote: Steven Bethard wrote: I get the correct output, but if you run this yourself, you'll see that the numbers 1 through 10 aren't printed in sync with the writes (i.e. every half second); they're all printed at the end. Could someone explain to me why this happens, and how (if possible) I can get the numbers printed in sync with the appends to the list? This is just a shot in the dark, as I'm quite ignorant of threading details. But what happens if you try adding a sys.stdout.flush() call after the print statement in your custom update() method? It may just be a flushing problem what makes the output appear out of sync... Strangely enough, that causes PythonWin to hang... Why that would be true, I have no idea... Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like 's?
John Roth [EMAIL PROTECTED] wrote:
If Python had originally been invented in a unicode world, I suppose we
wouldn't have this problem. We'd just be using guillemots for tuples
(and have keyboards which made it easy to type them).
I suppose the forces of darkness will forever keep Python from
requiring utf-8 as the source encoding. If I didn't make a fetish
of trying to see the good in everybody's position, I could really
work up a dislike of the notion that you should be able to use
any old text editor for Python source.
You can't use any old text editor for Python source. You can only use
a hardware/software combination which supports the required character
set (which AFAICT means ASCII, including *both* cases of the alphabet).
You would probably find it difficult to enter Python code on a 029
keypunch, or an ASR-33, or even an IBM-3270.
Granted, those are all dinosaurs these days, but 30 years ago, they
represented the norm. At that time, C was just hitting the streets, and
it was a pain to edit on many systems because it used weird characters
like { and }, which weren't in EBCDIC, or RAD-50, or SIXBIT, or whatever
character set your system used. ASCII was supposed to solve that
nonsense once and for all, except of course for the minor problem that
it didn't let most people in the world spell their names properly (if at
all).
In any case, it's a good thing that Python can be edited with any old
text editor, because that lowers the price of entry. I like emacs, the
next guy likes vi, or vim, or notepad, or whatever. Nothing is keeping
folks who like IDEs from inventing and using them, but I would have been
a lot less likely to experiment with Python the first time if it meant
getting one of them going just so I could run Hello, world.
With google as my witness, I predict that in 30 years from now, ASCII
will be as much a dinosaur as a keypunch is today, and our children and
grandchildren will both wonder how their ancestors ever managed to write
programs without guillemots and be annoyed that they actually have to
type on a keyboard to make the computer understand them.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter vs wxPython
Jarek Zgoda [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Cameron Laird wrote: Well, while on Windows native look exists, on X11 native has other meaning. On my wife's desktop it's KDE that is native, GNUStep is native on mine and I strongly object calling GTK native, as one can read on SWT/Eclipse website. There's no universally native look on X11. Some toolkits look better, but this is a matter of personal taste, for software developer clean, stable API and suitable widgets are of much higher value. What I think people mean by native is that it follows the design scheme selected for the desktop. When run under Linux, my wxPython programs follow the look and feel of my Gnome desktop. When the same program is run on Windows, it follows that desktop theme. Both Gnome and Windows XP alter the the controls design according to user preferences. wxPython GUIs reflect this automatically and the controls always look and work like the underlying system. I may be wrong but I don't think you get that with TKinter! Thomas Bartkus -- http://mail.python.org/mailman/listinfo/python-list
Re: Other notes
Mike Meyer wrote: Steve Holden [EMAIL PROTECTED] writes: [...] Well, perhaps you can explain how a change that's made at run time (calling the decorator) can affect the parser's compile time behavior, then. At the moment, IIRC, the only way Python code can affect the parser's behavior is in the __future__ module, which must be imported at the very head of a module. By modifying the parsers grammer at runtime. After all, it's just a data structure that's internal to the compiler. But the parser executes before the compiled program runs, was my point. What strange mixture of compilation and interpretation are you going to use so the parser actually understands that .. (say) is an operator before the operator definition has been executed? regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter vs wxPython
On Wed, 29 Dec 2004 13:37:22 -0600, Thomas Bartkus [EMAIL PROTECTED] wrote: Jarek Zgoda [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Cameron Laird wrote: Well, while on Windows native look exists, on X11 native has other meaning. On my wife's desktop it's KDE that is native, GNUStep is native on mine and I strongly object calling GTK native, as one can read on SWT/Eclipse website. There's no universally native look on X11. Some toolkits look better, but this is a matter of personal taste, for software developer clean, stable API and suitable widgets are of much higher value. What I think people mean by native is that it follows the design scheme selected for the desktop. When run under Linux, my wxPython programs follow the look and feel of my Gnome desktop. When the same program is run on Windows, it follows that desktop theme. Both Gnome and Windows XP alter the the controls design according to user preferences. wxPython GUIs reflect this automatically and the controls always look and work like the underlying system. I think you're right about what native means. I may be wrong but I don't think you get that with TKinter! Tk has native widgets for many platforms. Jp -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like 's?
Roy Smith wrote: John Roth [EMAIL PROTECTED] wrote: If Python had originally been invented in a unicode world, I suppose we wouldn't have this problem. We'd just be using guillemots for tuples (and have keyboards which made it easy to type them). I suppose the forces of darkness will forever keep Python from requiring utf-8 as the source encoding. If I didn't make a fetish of trying to see the good in everybody's position, I could really work up a dislike of the notion that you should be able to use any old text editor for Python source. In any case, it's a good thing that Python can be edited with any old text editor, because that lowers the price of entry. I like emacs, the next guy likes vi, or vim, or notepad, or whatever. Nothing is keeping folks who like IDEs from inventing and using them, but I would have been a lot less likely to experiment with Python the first time if it meant getting one of them going just so I could run Hello, world. Perl6 experiments with the use of guillemots as part of the syntax. I shall be curious to see how this is accepted, of course only if Perl6 is ever going to see the light of day, which is an exciting matter of its own... With google as my witness, I predict that in 30 years from now, ASCII will be as much a dinosaur as a keypunch is today, and our children and grandchildren will both wonder how their ancestors ever managed to write programs without guillemots and be annoyed that they actually have to type on a keyboard to make the computer understand them. Well, it's not clear if they will still write programs... Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: Other notes
Steven Bethard [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I'll second that. Please, Bearophile, do us the courtesy of checking (1) Google groups archive of the mailing list: http://groups-beta.google.com/group/comp.lang.python and (2) The Python Enhancement Proposals: http://www.python.org/peps/ before posting another such set of questions. While most of the people on this list are nice enough to answer your questions anyway, the answers are already out there for at least half of your questions, if you would do us the courtesy of checking first. I also suggest perusing the archived PyDev (Python Development mailing list) summaries for the last couple of years (see python.org). Every two weeks, Brett Cannon has condensed everything down to a few pages. You can easily focus on the topics of interest to you. For instance, there was discussion of making lists truly double-ended, but it was decided to settle for certain improvements in the list implementation while adding collections.deque (sp?) in 2.4. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000, zip, *args and iterators
[Steven Bethard] I'm just suggesting that in a function with a *args in the def, the args variable be an iterator instead of a tuple. So people would lose the useful abilities to check len(args) or extract an argument with args[1]? Besides, if a function really wants an iterator, then its signature should accept one directly -- no need for the star operator. Likewise, he considers zip(*args) as a transpose function to be an abuse of the *arg protocol. Ahh, I didn't know that. Is there another (preferred) way to do this? I prefer the abusive approach ;-) however, the Right Way (tm) is probably nested list comps or just plain for-loops. And, if you have numeric, there is an obvious preferred approach. So basically what I've done here is to transpose (to use your word) the iterators, apply my function, and then transpose the iterators back. If you follow the data movements, you'll find that iterators provide no advantage here. To execute transpose(map(f, transpose(iterator)), the whole iterator necessarily has to be read into memory so that the first function application will have all of its arguments present -- using the star operator only obscures that fact. Realizing that the input has to be in memory anyway, then you might as well take advantage of the code simplication offered by indexing: def twistedmap(f, iterable): ... data = list(iterable) ... rows = range(len(data)) ... for col in xrange(len(data[0])): ... args = [data[row][col] for rows in rows] ... yield f(*args) Raymond Hettinger -- http://mail.python.org/mailman/listinfo/python-list
Re: Other notes
Mike Meyer [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Steve Holden [EMAIL PROTECTED] writes: Well, perhaps you can explain how a change that's made at run time (calling the decorator) can affect the parser's compile time behavior, then. At the moment, IIRC, the only way Python code can affect the parser's behavior is in the __future__ module, which must be imported at the very head of a module. By modifying the parsers grammer at runtime. After all, it's just a data structure that's internal to the compiler. Given that xx.py is parsed in its entirety *before* runtime, that answer is no answer at all. Runtime parser changes (far, far from trivial) could only affect the result of exec and eval. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like 's?
On 2004-12-29, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: Perl6 experiments with the use of guillemots as part of the syntax. As if Perl didn't look like bird-tracks already... http://www.seabird.org/education/animals/guillemot.html http://www.birdguides.com/html/vidlib/species/Uria_aalge.htm -- Grant Edwards grante Yow! There's enough money at here to buy 5000 cans of visi.comNoodle-Roni! -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like 's?
[EMAIL PROTECTED] wrote: Why tuples use parentheses ()'s instead of something else like 's? Please enlighten me as I really want to know. So to summarize: Commas define tuples, except when they don't, and parentheses are only required when they are necessary. I hope that clears up any confusion. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3000, zip, *args and iterators
Raymond Hettinger wrote: [Steven Bethard] I'm just suggesting that in a function with a *args in the def, the args variable be an iterator instead of a tuple. So people would lose the useful abilities to check len(args) or extract an argument with args[1]? No more than you lose these abilities with any other iterators: def f(x, y, *args): args = list(args) # or tuple(args) if len(args) == 3: print args[0], args[1], args[2] True, if you do want to check argument counts, this is an extra step of work. I personally find that most of my functions with *args parameters look like: def f(x, y, *args): do_something1(x) do_something2(y) for arg in args: do_something3(arg) where having *args be an iterable would not be a problem. So basically what I've done here is to transpose (to use your word) the iterators, apply my function, and then transpose the iterators back. If you follow the data movements, you'll find that iterators provide no advantage here. To execute transpose(map(f, transpose(iterator)), the whole iterator necessarily has to be read into memory so that the first function application will have all of its arguments present -- using the star operator only obscures that fact. I'm not sure I follow you here. Looking at my code: labels, feature_dicts = starzip(generator) for label, feature_window in izip(labels, window(feature_dicts)): write_instance(label, combine_dicts(feature_widow)) A few points: (1) starzip uses itertools.tee, so it is not going to read the entire contents of the generator in at once as long as the two parallel iterators do not run out of sync (2) window does not exhaust the iterator passed to it; instead, it uses the items of that iterator to generate a new iterator in sync with the original, so izip(labels, window(feature_dicts)) will keep the labels and feature_dicts iterators in sync. (3) the for loop just iterates over the izip iterator, so it should be consuming (label, feature_window) pairs in sync. I assume you disagree with one of these points or you wouldn't say that iterators provide no advantage here. Could you explain what doesn't work here? Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like 's?
Grant Edwards wrote: On 2004-12-29, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: Perl6 experiments with the use of guillemots as part of the syntax. As if Perl didn't look like bird-tracks already... http://www.seabird.org/education/animals/guillemot.html http://www.birdguides.com/html/vidlib/species/Uria_aalge.htm Well, (1,1,2,3,5) »+« (1,2,3,5,8); # results in (2,3,5,8,13) (+ being an operator) just isn't something I would like to read in my code... Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: calling functions across threads
Fernando Perez wrote: Steven Bethard wrote: Fernando Perez wrote: Steven Bethard wrote: I get the correct output, but if you run this yourself, you'll see that the numbers 1 through 10 aren't printed in sync with the writes (i.e. every half second); they're all printed at the end. Could someone explain to me why this happens, and how (if possible) I can get the numbers printed in sync with the appends to the list? This is just a shot in the dark, as I'm quite ignorant of threading details. But what happens if you try adding a sys.stdout.flush() call after the print statement in your custom update() method? It may just be a flushing problem what makes the output appear out of sync... Strangely enough, that causes PythonWin to hang... Why that would be true, I have no idea... Mmh. I wouldn't be surprised if under pythonwin, sys.stdout is not the true python sys.stdout. Check the following: sys.stdout is sys.__stdout__ The answer is probably false. In that case, they may have implemented some incomplete object whose flush method is broken, or something similar. I can't confirm, as I don't have windows access, so this is just a guess. Just to verify, yes, the answer is False: py import sys py sys.stdout is sys.__stdout__ False Is there a list to ask PythonWin specific questions somewhere, or should I just wait for a PythonWin expert around here? Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: learning about threads and processes (was Re: what would you like to see in a 2nd edition Nutshell?)
On Wed, 29 Dec 2004 16:41:23 +0100, Alex Martelli wrote: Hmmm, well, the concepts are reasonably independent of the programming language involved. If anything, threads and processes may be more tied to whatever _operating system_ you're using. A very fundamental but good introduction to processes (and other such basics) is for example at http://en.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/, but it will be only partially applicable if you need to understand in depth the process-model of Windows. But of course this is about the concepts, not the practice of programming to interact with them. Too basic. Doesn't speak to the intermediate. I'll have you know, sir, you are speaking to someone who is quite intermediate, at least in mediocre way. Hummph ;) If I want to no more than be able to follow, say, the current Idle code of the PyShell module, I can find very little guidance from within the canon of Python literature. Help? Hmmm - have you looked at Deitel, Deitel, Liperi, Wiedermann, Python how to program, chapters 18 (Process Management) and 19 (Multithreading), pages 613-687? They seem to do a rather workmanlike job -- of course, they can't do full justice to the subjects in 75 pages; and if you don't want to buy a vast, costly 1300-pages tome for the sake of those 75 pages, I can't really blame you, either. Still, without some clarification of how (if at all) those 75 pages fail to meet your learning needs, it's hard to know what else to suggest. And what about Norman Matloff's http://heather.cs.ucdavis.edu/~matloff/Python/PyThreads.pdf, the first google hit if you're looking for python threads I never gotten to page 613 of any book in my life ;) But the Matloff piece you site is in fact helpful to the intermediate. Frankly not sure how I missed it in past searches. Python threading as a google buries it a bit, but not that deeply. This also comes up on a fresh search, and is to the point and at the level of interest. It is also recent: http://linuxgazette.net/107/pai.html ? I haven't looked into it, but, again, without some specific explanation of how it fails to meet your needs, it's hard to offer alternatives. The problem is when one starts off explaining threads by reference to processes, I already have a practical problem. Which, under what circumstances. Again referring back to the Idle code, class ModifiedInterpreter in the PyShell module: Within the space of a simple class, we are spawning a subprocess via: self.rpcpid = os.spawnv(os.P_NOWAIT, sys.executable, args) and a rpc client listening to a socket via: self.rpcclt = MyRPCClient(addr) which can be interrupted via a thread ala: threading.Thread(target=self.__request_interrupt).start() And then it gets a little complicated, to an intermediate ;) Guess I am hoping to get to understand it as architecture, as well as as code. This happens to be another piece of code I am trying to digest, which allows one to experiment with building PyGTK widgets from an interactive prompt: http://www.pygtk.org/pygtktutorial/examples/pygtkconsole.py which uses os.fork and signals in its architecture, but no threads, as opposed to this CookBook recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65109 which accomplishes a very similar functionality using threads as a fundamental part of its strategy. The closest thing I can think of as the kind of book I would love to see is one similar to Steve Holden's book on web programming, which explained lower level internet proctocols at the same time as it explained their Python implementation. Wonder what Steve's are doing this week? ;) Art -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Alex Martelli) wrote: I'm considering proposing to O'Reilly a 2nd edition of Python in a Nutshell, that I'd write in 2005, essentially to cover Python 2.3 and 2.4 (the current 1st edition only covers Python up to 2.2). ... Since you were kind enough to ask...what I'd really like is a better better index and better organization, so I can more quickly and easily locate info on a particular topic. Nutshell has some wonderful in-depth discussions of certain topics and I'm glad I own it, but I find it too hard to use for everyday questions (which was not at all what I expected for a nutshell book). I usually start with the html help (if I know the module I need or have a firm guess as to which other manual to read) or Python Essential Reference (other cases), then go to Nutshell if I'm still lost or if I remember it has a good section on the topic of interest. -- Russell -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like 's?
In article [EMAIL PROTECTED], Reinhold Birkenfeld [EMAIL PROTECTED] wrote: + being an operator Looks more like a smiley for guy wearing a bowtie -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like 's?
On 2004-12-29, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: Perl6 experiments with the use of guillemots as part of the syntax. As if Perl didn't look like bird-tracks already... http://www.seabird.org/education/animals/guillemot.html http://www.birdguides.com/html/vidlib/species/Uria_aalge.htm Well, (1,1,2,3,5) »+« (1,2,3,5,8); # results in (2,3,5,8,13) I was pretty sure that « and » were guillmots, but google sure preferred the sea bird when I asked it. -- Grant Edwards grante Yow! I've been WRITING at to SOPHIA LOREN every 45 visi.comMINUTES since JANUARY 1ST!! -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
Alex Martelli ([EMAIL PROTECTED]) wrote: : I'm considering proposing to O'Reilly a 2nd edition of Python in a : Nutshell, that I'd write in 2005, essentially to cover Python 2.3 and : 2.4 (the current 1st edition only covers Python up to 2.2). : So, if there's any advice or request about a 2nd edition of the : Nutshell, this is the right time for y'all to let me know. Feedback is : welcome, either privately or right here. Thanks in advance -- _and_ : apologies in advance because I know I just won't be able to accomodate : all the requests/advice, given the constraints on book size c. Alex, Probably not a practical sugestion, but have you considered ctypes? I know it's proved invaluable to our group at university - we like to make Python work with so many bits of weird hardware with vendor supplied libraries etc ... Perhaps a more resonable sugestion would be a short section on integration with native systems, e.g. an intro/overview to (non exhaustive list): psyco scipy.blitz/weave ctypes pyrex A detailed look at these is probably outside the scope of Nutshell, but they all represent intreresting areas. Perhaps the section could end with some words on PyPy. Cheers, cds -- http://mail.python.org/mailman/listinfo/python-list
Re: calling functions across threads
Steven Bethard wrote: Fernando Perez wrote: Steven Bethard wrote: Fernando Perez wrote: Steven Bethard wrote: I get the correct output, but if you run this yourself, you'll see that the numbers 1 through 10 aren't printed in sync with the writes (i.e. every half second); they're all printed at the end. Could someone explain to me why this happens, and how (if possible) I can get the numbers printed in sync with the appends to the list? This is just a shot in the dark, as I'm quite ignorant of threading details. But what happens if you try adding a sys.stdout.flush() call after the print statement in your custom update() method? It may just be a flushing problem what makes the output appear out of sync... Strangely enough, that causes PythonWin to hang... Why that would be true, I have no idea... Mmh. I wouldn't be surprised if under pythonwin, sys.stdout is not the true python sys.stdout. Check the following: sys.stdout is sys.__stdout__ The answer is probably false. In that case, they may have implemented some incomplete object whose flush method is broken, or something similar. I can't confirm, as I don't have windows access, so this is just a guess. Just to verify, yes, the answer is False: py import sys py sys.stdout is sys.__stdout__ False Is there a list to ask PythonWin specific questions somewhere, or should I just wait for a PythonWin expert around here? Steve There's a mailing list at python-win32@python.org - it's listed on www.python.org should you choose to subscribe, and the volume isn't generally high (maybe 5-10 messages per day). regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like 's?
On 29 Dec 2004 21:03:59 GMT, Grant Edwards [EMAIL PROTECTED] wrote: On 2004-12-29, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: Perl6 experiments with the use of guillemots as part of the syntax. As if Perl didn't look like bird-tracks already... http://www.seabird.org/education/animals/guillemot.html http://www.birdguides.com/html/vidlib/species/Uria_aalge.htm Well, (1,1,2,3,5) + (1,2,3,5,8); # results in (2,3,5,8,13) I was pretty sure that and were guillmots, but google sure preferred the sea bird when I asked it. They're guillemets (with an e); this is a [relatively] well-known Adobe SNAFU. (A quick google search or two failed to find an authoritative reference, but I know that such references are out there somewhere.) Regards, Dan -- Dan Sommers http://www.tombstonezero.net/dan/ Never play leapfrog with a unicorn. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like 's?
There just isn't enough neat-looking punctuation in the ASCII character set. Alex I can't thank you enough for your reply and for everyones' great info on this thread. The end of your email gave a rock solid reason why it is impossible to improve upon ()'s for tuples *There simply isn't enough good candidates in ASCII.* Moving to Unicode has pros and cons but your defense of parens assuming ASCII is perfect. Thanks again. Chris -- http://mail.python.org/mailman/listinfo/python-list
vga output
Title: vga output i'm writting an app to display images without X... i'm scared just to think about writting it in C... The hardware won't run X. and the CPU is very humble, around 20Mhz (and it must have fade outs). it run a minimalisc OpenBSD kernel. Anyone already did something similar and/or have any recomendations? Thanks, Gabriel -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like 's?
Brian I am so thankful for your reply and for Alex's and everyone else's on this thread. (See my reply to Alex.) This email may seem minor but it was bugging me for months. You just pointed out what I should have remembered on my own... *'s wouldn't have been a perfect choice because they would have had their own unique gotchas involving accidentally interpreting them as binary shift operators* I really appreciate it. Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
Alex Martelli wrote: I still believe Tkinter coverage is going to help more readers. Alex, I know this can be a can of worms. But honestly, I wonder what do you base that idea on. -Ruben -- http://mail.python.org/mailman/listinfo/python-list
PyQt installation problem
I got an evaluation version of Qt for Windows and installed PyQt. However, it gives me this error message: ImportError: DLL load failed: It doesn't seem to see the qt-mteval DLL, even though I made sure that the paths to lib and bin subfolders of Qt are there in the PATH. I installed Qt built with MSVC, and PyQt is also built using MSVC (PyQt-win-eval-msvc-3.13.exe). So why it doesn't see the DLL? Python version is 2.3.3. -- It's a man's life in a Python Programming Association. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuples use parentheses ()'s instead of something else like 's?
Dan Sommers wrote: On 29 Dec 2004 21:03:59 GMT, Grant Edwards [EMAIL PROTECTED] wrote: On 2004-12-29, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: Perl6 experiments with the use of guillemots as part of the syntax. As if Perl didn't look like bird-tracks already... http://www.seabird.org/education/animals/guillemot.html http://www.birdguides.com/html/vidlib/species/Uria_aalge.htm Well, (1,1,2,3,5) + (1,2,3,5,8); # results in (2,3,5,8,13) I was pretty sure that and were guillmots, but google sure preferred the sea bird when I asked it. They're guillemets (with an e); this is a [relatively] well-known Adobe SNAFU. (A quick google search or two failed to find an authoritative reference, but I know that such references are out there somewhere.) Regards, Dan Adobe recorded their error in the Red Book errata, but electronic admissions of the same error are apparently impossible to come by. regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
As a tester, my vote goes to extending the Testing subsection of the Testing, debugging and optimizing. I'd like to see more testing tools discussed there. Maybe py.test, PyFIT, and possibly others. Grig -- http://mail.python.org/mailman/listinfo/python-list
Re: learning about threads and processes
Aahz [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Alex Martelli [EMAIL PROTECTED] wrote: Hmmm - have you looked at Deitel, Deitel, Liperi, Wiedermann, Python how to program, chapters 18 (Process Management) and 19 (Multithreading), pages 613-687? They seem to do a rather workmanlike job -- of course, they can't do full justice to the subjects in 75 pages; and if you don't want to buy a vast, costly 1300-pages tome for the sake of those 75 pages, I can't really blame you, either. Except that it's a really, really piss-poor book. That's an opinion which I believe you've agreed with previously. Overall, yes, it's not a book I'd heartily recommend. But, is anything wrong, specifically, with chapters 18 and 19? They seem OK to me. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
RM wrote: Alex Martelli wrote: I still believe Tkinter coverage is going to help more readers. Alex, I know this can be a can of worms. But honestly, I wonder what do you base that idea on. -Ruben Tkinter is a part of the Python core, and so will be available to the majority of beginners. Tkinter is also likely to be supported (by Tcl) in Linux and other Unix-like environments, although with a slightly lower level of ubiquity. I suspect Alex is considering availability at least as strongly as the technical merits of the packages. And, when all is said and done, beginners shouldn't have to go download stuff before beginning to noodle round with GUIs. regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
Craig Ringer [EMAIL PROTECTED] wrote: On Wed, 2004-12-29 at 23:54, Thomas Heller wrote: I found the discussion of unicode, in any python book I have, insufficient. I couldn't agree more. I think explicit treatment of implicit conversion, the role of sysdefaultencoding, the u'' constructor and unicode() built in, etc would be helpful to many. Thanks! BTW, thanks first and foremost to Holger Krekel (who was a very activist tech reviewer and specifically contributed a recipe for this purpose), there's what I believe is a pretty good treatment of Unicode in the Cookbook's forthcoming 2nd edition -- still insufficient in some sense, no doubt (it IS just a few pages), but, I believe, pretty good. Nevertheless, I'll ensure I focus on this in the 2nd ed Nutshell, too. It wouldn't hurt to point C extension authors at things like the 'es' encoded string format for PyArg_ParseTuple to help them make their code better behaved with non-ascii text. Good sub-point, thanks. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
[EMAIL PROTECTED] wrote: As a Python beginner, I had a difficult time with the section on Slicing a sequence (p. 47). In particular, a better explanation and examples of negative indicies would be helpful. Good point, thanks. This is nitpicking in what I consider to be a very good book. I hope And thanks for this, too! Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
Fernando Perez [EMAIL PROTECTED] wrote: Alex Martelli wrote: the coverage of Twisted and adding just a few things (numarray -- perhaps premature to have it _instead_ of Numeric, though; dateutils, You might want to keep in touch with the scipy/numarray gang on this particular topic. An effort is currently under way to make scipy work with numarray, and matplotlib already works with numarray out of the box. These two facts will, I think, greatly accelerate the adoption of numarray and the transition away from Numeric. There are a few people (like me, unfortunately), who can simply not use numarray because of the small array instatiation overhead. But that subcommunity tends to know enough to be able to deal with the problems by itself. Since numarray is indeed the long-term array core for Python, I think the book would be better off by covering it. Numarray is actively developed, and vastly better documented than Numeric. Well, I _am_ going to cover or at least mention numarray -- my question was on whether I can _drop_ Numeric in favour of numarray. In good part _because_ numarray has good docs, it may be less crucial for me to cover it thoroughly, than I felt it was for Numeric. Three years ago, numarray was barely a blip on the radar, if that; three years from now, the same may be true of Numeric; but right now, I get some sense that we're in transition -- that numarray needs and deserves coverage or at least extended mention, BUT nevertheless it might be premature to drop the coverage of Numeric... A mention of the particular problems with numarray might be a good idea, so that readers are aware of Numeric and where it may still be preferable to numarray, but with the understanding that it's a (shrinking) niche. Hopefully one day that niche will shrink to zero, but that is going to take time and work. Right -- and if I can get the 2nd ed of the Nutshell out within 2005, it may be too early to say that Numeric has shrunk to the vanishing point... so I may still need to have both in... Finally, I think in this section a mention of the overall scipy project would be a good idea. Scipy is the central meeting point for most scientific computing projects in python, and therefore a natural reference for most users of numarray/numeric. Amongst other useful things at the scipy site, there's a community maintained wiki of links to python-based projects of scientific interest: http://www.scipy.org/wikis/topical_software/TopicalSoftware Most definitely a good idea, thanks. Indeed, the lack of mention of scipy _is_ a wart in the 1st ed -- as my excuse I can only explain that I was _so_ focused on being focused... I ended up excising even all mentions of my own baby, gmpy...!-) But yes, scipy _will_ most definitely get a mention this time around -- thanks for reminding me!-) Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
What you say is true. However, I didn't think the target audience of this book was newbies. Python newbies yes, but not programming newbies. For programming newbies I would recommend the Learning Python book instead. The availability argument, however, is a good point. -- http://mail.python.org/mailman/listinfo/python-list
Re: what would you like to see in a 2nd edition Nutshell?
Russell E. Owen [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Alex Martelli) wrote: I'm considering proposing to O'Reilly a 2nd edition of Python in a Nutshell, that I'd write in 2005, essentially to cover Python 2.3 and 2.4 (the current 1st edition only covers Python up to 2.2). ... Since you were kind enough to ask...what I'd really like is a better better index and better organization, so I can more quickly and easily locate info on a particular topic. Thanks for the advice! What I have now is the best organization I was able to conceive -- and I have no current ideas on how to enhance it. Any _suggestions_ will be truly welcome; somehow, I don't see make it better as a _suggestion_... if I _knew_ how to organize it better, I would, of course. Indexing is a completely separate issue, mostly done by O'Reilly outside of my control; can we please focus on _organization_, which _is_ almost entirely in my hands... Nutshell has some wonderful in-depth discussions of certain topics and I'm glad I own it, but I find it too hard to use for everyday questions (which was not at all what I expected for a nutshell book). I usually Indeed, this is definitely not what I was aiming for, and if it's a widespread issue which all reviews of the book I read managed to hide it's crucial for it to come out -- whence my thanks. But I need more help to understand what makes the book's organization so feeble for you, and whether the issue is widespread so that I need to revolutionize the book's organization... or whether such a revolution wouldn't hurt the many readers who appeared sort of OK with the current structure... Thanks in advance for any further input -- and that applies to others just as much as to you (meaning: o future potential readers, if you find the current organization of the book ok, please do speak up -- if only those who prefer changes are gonna speak, then changes are likely!-). Alex -- http://mail.python.org/mailman/listinfo/python-list
