Re: Python less error-prone than Java
In article [EMAIL PROTECTED], Christoph Zwerschke [EMAIL PROTECTED] wrote: Simon Percivall wrote: First: It's perfectly simple in Java to create a binary sort that sorts all arrays that contain objects; so wrong there. My point was that the *same* Java source example, directly converted to Python would *automatically* accept all kinds of arrays. And the same code converted to SML would automatically work on all kinds of arrays and SML is statically typed. It's a language issue, not a typing issue. Ok, here the point was that Java has *explicit* static typing. SML is not a procedural language and uses *implicit* static typing. Therefore it shares some of the benefits of dynamically typed languages such as Python. However, an SML version of the program would probably still have the same bug as the Java version, right? No need to make any extra efforts. By the way, how would you do it in Java? With function overloading? I would not call that perfectly simple. Since Java doesn't allow function overloading that clearly can't be the way. J2SE 5.0 allows generic classes and functions that operate on generic containers. There are some gotchas, but it's not drastically more complex than the original int-only java code. Java doesn't allow function overloading? Brain fart. You said function and I read operator. Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: Python less error-prone than Java
In article [EMAIL PROTECTED], Christoph Zwerschke [EMAIL PROTECTED] wrote: Simon Percivall wrote: First: It's perfectly simple in Java to create a binary sort that sorts all arrays that contain objects; so wrong there. My point was that the *same* Java source example, directly converted to Python would *automatically* accept all kinds of arrays. And the same code converted to SML would automatically work on all kinds of arrays and SML is statically typed. It's a language issue, not a typing issue. No need to make any extra efforts. By the way, how would you do it in Java? With function overloading? I would not call that perfectly simple. Since Java doesn't allow function overloading that clearly can't be the way. J2SE 5.0 allows generic classes and functions that operate on generic containers. There are some gotchas, but it's not drastically more complex than the original int-only java code. Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: Python less error-prone than Java
In article [EMAIL PROTECTED], Neil Hodgson [EMAIL PROTECTED] wrote: Alan Morgan wrote: Since Java doesn't allow function overloading that clearly can't be the way. J2SE 5.0 allows generic classes and functions that operate on generic containers. There are some gotchas, but it's not drastically more complex than the original int-only java code. Doesn't Java restrict generics to only operate on reference types so you can't produce a generic binary search that operates on arrays where the item type may be int? Yup, you have to wrap int (and double and float and...). Blame type erasure. Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: Queue can result in nested monitor deadlock
In article [EMAIL PROTECTED], Jonathan Amsterdam [EMAIL PROTECTED] wrote: If you don't want to call it deadlock, fine, but the program execution I describe will make no progress to the end of time. Thread 2 can never put anything in the queue, because Thread 1 holds M, and Thread 1 will never release M because that can only happen if someone puts something on the queue. That's not a problem in the design of the queue class, it is a problem in how you are using it. Two possible solutions are: 1. Don't have the global lock on the object (or, at the very least, don't have that global lock taken when you read from the queue). 2. Don't use a syncronized queue. If the only access to the queue is through the object and the object is protected then you don't need a synchronized queue. Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: list.clear() missing?!?
In article [EMAIL PROTECTED], Raymond Hettinger [EMAIL PROTECTED] wrote: [Steven Bethard] I think these are all good reasons for adding a clear method, but being that it has been so hotly contended in the past, I don't think it will get added without a PEP. Anyone out there willing to take out the best examples from this thread and turn it into a PEP? Something this small doesn't need a PEP. I'll just send a note to Guido asking for a pronouncement. Here's a draft list of pros and cons (any changes or suggestions are welcome): Pros: - * s.clear() is more obvious in intent Serious question: Should it work more like s=[] or more like s[:]=[]. I'm assuming the latter, but the fact that there is a difference is an argument for not hiding this operation behind some syntactic sugar. Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: list.clear() missing?!?
In article [EMAIL PROTECTED], Steven D'Aprano [EMAIL PROTECTED] wrote: On Wed, 12 Apr 2006 15:36:47 -0700, Alan Morgan wrote: Serious question: Should it work more like s=[] or more like s[:]=[]. I'm assuming the latter, but the fact that there is a difference is an argument for not hiding this operation behind some syntactic sugar. Er, I don't see how it can possibly work like s = []. That merely reassigns a new empty list to the name s, it doesn't touch the existing list (which may or may not be garbage collected soon/immediately afterwards). Right. I was wondering what would happen in this case: s=[1,2,3] t=s s.clear() t # [] or [1,2,3]?? If you know your basic python it is obvious what would happen if you do s=[] or s[:]=[] instead of s.clear() and I guess it is equally obvious which one s.clear() must mimic. I'm still not used to dealing with mutable lists. Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: list.clear() missing?!?
In article [EMAIL PROTECTED], Peter Hansen [EMAIL PROTECTED] wrote: Alan Morgan wrote: Right. I was wondering what would happen in this case: s=[1,2,3] t=s s.clear() t # [] or [1,2,3]?? If you know your basic python it is obvious what would happen if you do s=[] or s[:]=[] instead of s.clear() and I guess it is equally obvious which one s.clear() must mimic. I'm still not used to dealing with mutable lists. If you know your basic python :-), you know that s[:] = [] is doing the only thing that s.clear() could possibly do, Ah, but if you know your basic python then you wouldn't be looking for s.clear() in the first place; you'd just use s[:]=[] (or s=[], whichever is appropriate). IOW, the people most in need of s.clear() are those least likely to be able to work out what it is actually doing. Personally, it seems more *reasonable* to me, a novice python user, for s.clear() to behave like s=[] (or, perhaps, for s=[] and s[:]=[] to mean the same thing). The fact that it can't might be an argument for not having it in the first place. Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: How can I reduce the number of queries to my PostgreSQL database?
In article [EMAIL PROTECTED], SR [EMAIL PROTECTED] wrote: As a starter project for learning Python/PostgreSQL, I am building a Books database that stores information on the books on my bookshelf. Say I have three tables. Table books contains rows for book_id, title, subtitle, ISBN. Table authors contains rows for author_id, author surname, author first names, biographical notes. Table bookauthors contains two rows: book_id, author_id. The bookauthors table links the books and authors tables. Scenario: I have a python script which creates web page listing all books in the database, and all authors for each book. My python script does essentially three things: 1. retrieve a list of all book_ids and book_titles. 2. for each book_id, query the bookauthors table and retrieve all author names for that book_id. 3. display it all out as an html table on a web page. The script works fine, if a little slow. I think that's because if I have 50 books in my database, my script performs 51 database queries (1 for all book names; then 1 for each book). A colleague of mine suggested that I could get away with two queries, 1 to read the book ids and titles, and 1 to read the bookauthors table to pull in *all* relations, and then do all the work in Python. I think I know where he's coming from, but I don't know where to begin. Any clues? Is there a specific name for this technique? Yup. The technique is called using a relational database. This is precisely the sort of thing SQL does well. Let's say you want to find out who wrote 'The Hitchhikers Guide to the Galaxy'. You could do the following (all sql untested and, let's face it, probably not understood by author): 1. Query for that book to get the book_id SELECT id FROM books WHERE title='The Hitchhikers Guide To The Galaxy' 2. Look up that author id in the bookauthor database SELECT author_id FROM bookauthors WHERE book_id=book id 3. Look up that author in the author database SELECT name FROM authors WHERE id=author id or do SELECT name FROM authors, books, bookauthors WHERE books.id=bookauthors.book_id AND authors.id=bookauthors.author_id AND title='The Hitchhikers Guide To The Galaxy' Slick, no? You want something like: SELECT title, name, book_id FROM authors, books, bookauthors WHERE books.id=bookauthors.book_id AND authors.id=bookauthors.author_id If you have more than one author for a book then the book will appear in the table multiple times. You'll have to combine those yourself (the book_id row can help here. I don't know if you can leverage more SQL for that job). You can optimize some of these SQL queries if you like. Optimizing JOINs, which is what these are) is a serious business, but for piddly databases of this size it really isn't necessary. Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: efficiency of range() and xrange() in for loops
In article [EMAIL PROTECTED], Georg Brandl [EMAIL PROTECTED] wrote: Alan Morgan wrote: range is giving you a real list, while xrange is giving you an xrange object. Have you tried to slice an xrange object? Or using .append on it? No, I hadn't. I presume these could all be defined. How would xrange(100).remove(1) work? One way is by first converting the xrange to a list. If we think of the xrange as an efficient and space lean way to store certain types of lists then it isn't unreasonable to return a regular list when the conditions no longer hold. Or extend the xrange object to allow multiple ranges and return the union of xrange(0,1) and xrange(2,100). No reason why you can't define the whole range of list operations over xrange and still leave it as a nice, lazy list (other languages do). It's possible that no one needs it enough to make it worthwhile (although having full fledged lazy structures can really helpful when you need them) but it could be done. Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: efficiency of range() and xrange() in for loops
In article [EMAIL PROTECTED], Giovanni Bajo [EMAIL PROTECTED] wrote: Steve R. Hastings wrote: in Python 2.X, range is defined to return a list. if you start returning something else, you'll break stuff. Perhaps I'm mistaken here, but I don't see how this optimization could possibly break anything. Because you assume that the only use-case of range() is within a for-loop. range() is a builtin function that can be used in any Python expression. For instance: RED, GREEN, BLUE, WHITE, BLACK = range(5) Hmmm, this worked fine when I used xrange as well. Am I missing something? Obviously there *are* differences, viz: a = range(5) b = range(5) a==b # True! c = xrange(5) d = xrange(5) c==d # False! and various other more arcane things, but do these actually happen in real life? Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: efficiency of range() and xrange() in for loops
In article [EMAIL PROTECTED], Georg Brandl [EMAIL PROTECTED] wrote: Alan Morgan wrote: In article [EMAIL PROTECTED], Giovanni Bajo [EMAIL PROTECTED] wrote: Steve R. Hastings wrote: in Python 2.X, range is defined to return a list. if you start returning something else, you'll break stuff. Perhaps I'm mistaken here, but I don't see how this optimization could possibly break anything. Because you assume that the only use-case of range() is within a for-loop. range() is a builtin function that can be used in any Python expression. For instance: RED, GREEN, BLUE, WHITE, BLACK = range(5) Hmmm, this worked fine when I used xrange as well. Am I missing something? Obviously there *are* differences, viz: Just _look_ at the objects: range(5) [0, 1, 2, 3, 4] xrange(5) xrange(5) Yes, I was well aware of this. I noted a difference in my original post. I was just pointing out that the example given didn't, in fact, behave differently for range() and xrange() even though range() and xrange() *are* different. range is giving you a real list, while xrange is giving you an xrange object. Have you tried to slice an xrange object? Or using .append on it? No, I hadn't. I presume these could all be defined. Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: efficiency of range() and xrange() in for loops
In article [EMAIL PROTECTED], Erik Max Francis [EMAIL PROTECTED] wrote: Alan Morgan wrote: In article [EMAIL PROTECTED], Giovanni Bajo [EMAIL PROTECTED] wrote: Because you assume that the only use-case of range() is within a for-loop. range() is a builtin function that can be used in any Python expression. For instance: RED, GREEN, BLUE, WHITE, BLACK = range(5) Hmmm, this worked fine when I used xrange as well. Am I missing something? Not in your use case. Tuple unpacking will iterate, and so it doesn't matter whether it's an actual list or an iterator: a, b, c = xrange(3) a 0 b 1 c 2 There are certainly contexts where a sequence and its iterator are not interchangeable. You missed an obvious one: range(3) == xrange(3) False I thought that one was sufficiently obvious as not to need mentioning. There was never any argument that range() and xrange() returned different things; the question (as I understood it) was if you could generally use the things they return in the same way and not *care* about the difference (the answer being Yes, except when you can't). Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: Too Many if Statements?
In article [EMAIL PROTECTED], Pierre Quentel [EMAIL PROTECTED] wrote: This is because Python has a hidden mechanism to detect programs generated by Perl scripts, and make them crash with no explanation In my case it turned out to be python having a hidden method to detect when you are using an ancient version of python. Retesting with a newer version didn't find any problems. Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: Too Many if Statements?
In article [EMAIL PROTECTED], slogging_away [EMAIL PROTECTED] wrote: Hi - I'm running Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32, and have a script that makes numerous checks on text files, (configuration files), so discrepancies can be reported. The script works fine but it appears that I may have hit a wall with 'if' statements. Due to the number of checks perfromed by the script on the text files, (over 500), there are quite a few 'if' statements in the script, (over 1150). It seems that it is at the point that when I add any additional 'if' statements the script will not run. No error is produced - it just returns to the python prompt much the same as when a successful 'Check Module' command is selected. If I delete some other 'if' statements the new ones work so it appears that it has hit a limit on the number of 'if' statements. This has stunted any further checks for the script to make on the text files. Hs anyone ever run into this sort of thing? I generated files with 1, 25000, and 5 simple if statements and ran them. 1 was okay, 25000 gave a bizarre internal error, and 5 segfaulted and died. My system has plenty of memory and it isn't obvious to me why python should be so bothered about this. I'm not sure why I can have 10x the number of if statements that cause you trouble. There might be some overall limitation on the number of statements in a file. Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: Too Many if Statements?
In article [EMAIL PROTECTED], Bryan Olson [EMAIL PROTECTED] wrote: Alan Morgan wrote: slogging_away wrote: Hi - I'm running Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32, and have a script that makes numerous checks on text files, (configuration files), so discrepancies can be reported. The script works fine but it appears that I may have hit a wall with 'if' statements. I generated files with 1, 25000, and 5 simple if statements and ran them. 1 was okay, 25000 gave a bizarre internal error, and 5 segfaulted and died. My system has plenty of memory and it isn't obvious to me why python should be so bothered about this. I'm not sure why I can have 10x the number of if statements that cause you trouble. There might be some overall limitation on the number of statements in a file. I made a script with 100,000 if's, (code below) and it appears to work on a couple systems, including Python 2.4.2 on Win32-XP. So at first cut, it doesn't seem to be just the if-count that triggers the bug. Mine was a simple #!/usr/local/bin/python zot=24999 if zot == 0: print It's 0 if zot == 1: print It's 1 if zot == 24999: print It's 24999 generated (I'm ashamed to admit) by a perl script. Is there any good reason why it is failing? I'd prefer a Too many silly walks in your program. Reduce! to a crash. I could experiment with putting the matching 'if' at the beginning rather than at the end, but I'm not sure what that would tell me. Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: How do I dynamically create functions without lambda?
In article [EMAIL PROTECTED], Alex Martelli [EMAIL PROTECTED] wrote: Alan Morgan [EMAIL PROTECTED] wrote: ... Excessive cleverness can lead to unmaintainable code. So can excessive stupidity. +1 QOTW. import blush Since there are a lot more stupid people than clever people out there I think the more likely scenario is having to maintain unmaintainable code written by a complete idiot whose programming knowledge comes solely from books whose titles end with In 7 Days. Disagree -- far more people THINK they're clever, than really ARE clever. No doubt about it, but I don't see how it contradicts my statement. According to a recent article in the Financial Times, over 40% of a typical financial firm's employees firmly believe they are among the 5% best employees of the firm -- and the situation, believe me, is no different in programming. I wonder if python, which has a low barrier to entry due to its simple syntax and general readability, might not have a worse time of this than other languages. Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: How do I dynamically create functions without lambda?
In article [EMAIL PROTECTED], Steven D'Aprano [EMAIL PROTECTED] wrote: On Sat, 28 Jan 2006 00:13:28 -0800, Kay Schluehr wrote: [snip lambda calculus stuff] In Python you can write: Y = lambda g: (lambda f: g(lambda arg: f(f)(arg))) (lambda f: g(lambda arg: f(f)(arg))) This serves the purpose. Try Y(F) and see. Is any of this stuff maintainable in the real world of IT, where most programmers don't have computer science degrees? You come along six months after the project was finished to maintain this code and discover that the whiz-kid lambda calculus guy never commented anything because that would detract from the elegance of his one liners; what happens next? Excessive cleverness can lead to unmaintainable code. So can excessive stupidity. Since there are a lot more stupid people than clever people out there I think the more likely scenario is having to maintain unmaintainable code written by a complete idiot whose programming knowledge comes solely from books whose titles end with In 7 Days. Oh, and I'd hope that code reviews, etc. would have kept lambda-boy from getting too far down this path of self invocation. Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
Re: lies about OOP
In article [EMAIL PROTECTED], projecktzero [EMAIL PROTECTED] wrote: I know this might not be the correct group to post this, but I thought I'd start here. A co-worker considers himself old school in that he hasn't seen the light of OOP.(It might be because he's in love with Perl...but that's another story.) He thinks that OOP has more overhead and is slower than programs written the procedural way. In the world of computers, the statement X is slower than Y is true for almost every value of X and Y under some circumstances. IMHO, loves perl doesn't mesh with either old school or cares about overhead, but that's just me. Alan -- Defendit numerus -- http://mail.python.org/mailman/listinfo/python-list
