Re: Python on the Web
On Aug 26, 4:17 am, alex23 wuwe...@gmail.com wrote: Frameworks created for the sake of creating a framework, as opposed to those written to meet a defined need, tend to be the worst examples of masturbatory coding. Indeed, but masturbation is perfectly healthy and acceptable, and we all do it every now and then. It is however, much like the framework in question, best kept private and not made public. Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: How best to test functions which use date.today
On Feb 28, 5:54 pm, Lie Ryan lie.1...@gmail.com wrote: Yuan HOng wrote: HI, In my project I have several date related methods which I want tested for correctness. The functions use date.today() in several places. Since this could change every time I run the test, I hope to find someway to fake a date.today. For illustration lets say I have a function: from datetime import date def today_is_2009(): return date.today().year == 2009 To test this I would like to write test function like: def test_today_is_2009(): set_today(date(2008, 12, 31)) assert today_is_2009() == False set_today(date(2009,1,1)) assert today_is_2009() == True Although you can't override today, you should be able to do something along the lines of: class MyDate(object): def __init__(self, today): self.today = today my_date = MyDate(date(2009, 11, 12)) date = my_date This assumes you aren't using anything else from date. If you are you'll either have to add that to MyDate or use a proper Mock Object. Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs versus Spaces in Source Code
On 5/15/06, Brian Quinlan [EMAIL PROTECTED] wrote: The problem with tabs is that people use tabs for alignment e.g. def foo(): -query = SELECT * - - - FROM sometable - - - WHERE condition Now I change my editor to use 8-space tabs and the code is all messed up. Of course, a very disciplined group of people could be trained to never use tabs except to align with the current block level but, in practice, that doesn't work. Therefore tabs are bad. def foo(): -query = SELECT * - ...FROM sometable - ...WHERE condition That would solve it. Tabs for indentation, spaces for spacing. Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: recursion and linked lists
On 01/04/06, John Salerno [EMAIL PROTECTED] wrote: I V wrote: Note that print gets called after _each_ time that printBackward returns. So, as the different calls to printBackward return, they print whatever 'head' was set to in that invocation. Now, logically enough, the last call to printBackward is the first to return, so the last value of 'head' is printed first, and so in in the reverse order of the list. Oh, that helps! Now I'm starting to understand when exactly it returns each time. The way I got my head round this was to think of namespaces (I'm not sure how true this is though). I think of the first head variable as being: printBackward.head When it calls printBackward from within the first printBackward, thye second variable is: printBackward.printBackward.head and so on. It helps to keep it clear that they are entirely different. Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Doc suggestions
On 4 Apr 2006 15:18:27 -0700, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote in message Here is a 3' view. I posted about a clear (admittedly very minor) doc problem 8 days ago. Since then there have been 30+ postings in this thread. Insults and bad feelings have flown. Two people setup wikis and uploaded the tutorial. I don't know how many people have visited or made changes. After all that I look at the current 2.5 docs, and what do I see? The same, trivial, problem is still there. I agree with you generally on the something needs to be done. I'm all for a system that allows people to make trivial changes themselves, and has a team (or Czar) overseeing it to keep things in order. I disagree with some of the details of your suggestion as I tend to be more in favour of a Wild West Wiki approach that gives everyone equal power, except the editors who have final say. However I'm broadly in agreement. Ironically, I think that if you and Fredric played nicely, you'd find that he also broadly agrees with the need for change (hence the creation of the wiki). I think (but am not at all sure) that getting the people in change of Python to change the way things are done is quite difficult. I think, just like with the standard library, that there tends to be a system of seeing what gets created in the wild, and then once something is fairly well proven, make it official. I'm not at all sure that this is a bad way of going about things. DIY certainly seems to be a large, but unspoken, part of the community. If you want your changes to take place, you'll need to set it up yourself, make it work, and if it did, it would very likely replace the current system. If it doesn't work, that would seem to suggest that it wasn't sufficiently better. I know it can be very frustrating making suggestions and comments on the list and people at best ignoring them, but that seems to be how things work around here. I think it's a zen thing. [snipped...a proposal that would hopefully improve the documentation and process.] No comments on this either. I wonder why? ...It is a lousy or unworkable idea. ...Fredrik doesn't like it. ...It did not come from an insider. ...The docs for introducing people to Python and getting them to an intermediate level are already ok. Any further improvement would erode the status of the existing experts and is thus undersireable. ...Same as above but would reduce the ability of experts to make money writing commercial books. Probably none of the above. It's just not exciting enough for people to go away and do it for you. If you really believe in the idea, do it, prove it and then people will accept it (and you'll probably be in charge of the docs). Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Doc suggestions (was: Why class exceptions are not deprecated?)
On 30 Mar 2006 16:30:24 -0800, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Fredrik Lundh wrote: [EMAIL PROTECTED] wrote write a tutorial as good as what is already there. But what I can do is report problems I find when using it, and make suggestions about how to avoid those problems. There's no shortage of ideas -- nor people who can write a tutorial that's better than the current one (which is far from optimal, mostly thanks to a zillion peephole edits over the years). There's a shortage of volunteer time, though. That's why the I'm just the idea guy, someone else will have to provide the hundreds of hours required to implement my idea arguments are so offensively meaningless. What are you saying? Ideas must come only from those with the time and skill to implement them? No one else need apply? Ideas can come from anyone and they do come from anyone all the time, and as such they are fairly worthless unless acted upon. If you want someone else to do the acting upon for you, for free (and probably for no thanks), then it has to be one hell of an amazing idea that no one else has ever had (which, trust me, you won't have, and neither, probably, will I). Everyone knows how to improve open source software, but what good is that to anyone? Making the improvements is worth hell of a lot and that's why the people who do develop a lot of kudos in the community (it's about the only payment they get for it, and they do deserve it). If you have an idea, then good for you, but make some small attempt to do something about it yourself. I'm not much of an expert in anything yet, but I had an idea, and then managed to put the documents in a wiki, which was at least trying to do something. Fredrik beat me to it and did a much better job, but even so I feel quite proud that I did something and tried to move things on, rather than just post to a mailing list and hope someone else does it. Whenever anyone criticizes anything about free software there are three automatic responses: 1. You are an idiot if you can't understand / have a problem with that. 2. Its free so you should be grateful and shutup. 3. You have the source, change it yourself, you lazy whiner. Whenever people are rude to you, it's quite useful to stop and think why. Quite often you'll find that it's something you're doing wrong. If it happens every single time you make a criticism, then it's definitely something you are doing wrong. You could save everyone time and bandwidth by just responding with #3!!! Sorry Fredrik, truth is truth. If there is a problem then people are right to point it out. If that is really a big problem for you then I suggest setting up a forum or mailing list on python.org where you can delete improper messages, and ban posters who have incorrect attitudes. Unfortunately just saying truth is truth doesn't make something true. If you really feel that people are right to point out problems whenever they see them without making any attempt to correct them, then at least attempt to prove your point with some sort of argument. Do you think I would be right to point out every time I saw a problem with your attitude or personality? Of course I wouldn't. If someone came to me with a gift, should I take it and start pointing out all it's flaws and demanding that they fix the flaws? Imagine that free software is a gift to you that has taken many thousands of hours to create. If you're going to ask the giver to do a better job of the gift that they've given you, you better ask in a very, very, very nice way and you should probably show that you've at least made some effort to correct the problem yourself, (and really you'd be better of just asking how to fix the problem yourself. People are quite responsive to that. They always want more helpers). Come up with an idea that *reduces* the overall work needed to write and maintain a good manual, and people might start listening to what you have to say. What makes you think there is such a way? Don't you think publishers have been looking for that way for years? Do you think it possible that a good manual might just require good writers, and good editors, and it would make sense to encourage those who might be interested, rather than posting put-downs of anyone who misreads or misinterprets the docs? If you think that publishers are the apex of discovering new ways to write docs then you don't have much experience of the real world. Any business process like that tends to be quite a good distance (around 5-10 years) behind the head of the pack. And if you think we have somehow reached perfection in the process of creating documents... Fredrik does encourage people who might be interested. Go back and read this thread again. Maybe he knows that you're not actually interested in contributing. Or come up with some money. If you can fund a technical writer for one year, there are lots of things that
Re: Doc suggestions (was: Why class exceptions are not deprecated?)
On 29/03/06, Fredrik Lundh [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote write a tutorial as good as what is already there. But what I can do is report problems I find when using it, and make suggestions about how to avoid those problems. There's no shortage of ideas -- nor people who can write a tutorial that's better than the current one (which is far from optimal, mostly thanks to a zillion peephole edits over the years). There's a shortage of volunteer time, though. That's why the I'm just the idea guy, someone else will have to provide the hundreds of hours required to implement my idea arguments are so offensively meaningless. I'm not entirely sure there is a shortage of people who want to volunteer, just that a lot don't know that they can volunteer, and those that do can't make a huge time commitment or don't have the confidence. I think there's quite a lot of people who would be happy to help out as and when they could (particularly with small edits like the one mentioned), if they were sure someone else was going to double check that they hadn't accidentally written garbage. This would be a perfect situation for a wiki. I think it would be a good experiment to have a wiki containing the documentation (separate from the main documentation and clearly marked experimental for the moment), and to see if it did self-organise as wikis often do. Beginners like rurpy could add comments when they don't understand a paragraph, more confident people could attempt to correct the paragraph, and every now and then an advanced person could scan through it and make sure it was truly accurate. It would greatly reduce the work need by the people currently responsible for documentation (they just have to read through and make sure things are correct) and if a page has been significantly improved by the community and double checked by an expert, it could be promoted to the official version of the documentation. If the whole thing descends into chaos, the wiki (pages) could just be deleted and we continue with the current system. As Python has such an excellent community, it would be a shame not to give them more responsibility in this area, and this system seems to be working quite well for many python projects (many just use the wiki in Trac). Ed (I'm actually tempted to just copy and paste each page from the tutorial into the current wiki but I'd hate for it all to be deleted after doing that). -- http://mail.python.org/mailman/listinfo/python-list
Re: Doc suggestions (was: Why class exceptions are not deprecated?)
On 29/03/06, Fredrik Lundh [EMAIL PROTECTED] wrote: btw, one alternative could be to use an infogame site for this purpose: http://infogami.com this gives you revision history, a permissions system (limiting editing to registered users might be a good idea), comments, an associated blog, voting, feeds, change logs, etc. alright, I got bored and uploaded a copy of the current Python tutorial to http://pytut.infogami.com Damn. You beat me to it by an hour. http://singletoned.infogami.com/_special/index I had a nightmare with character encodings (mainly because I'm terrible with them). I have a script written that does it all for me, but it keeps choking on characters. I just tried randomly converting things to Unicode at various points for over an hour until it worked. Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Doc suggestions (was: Why class exceptions are not deprecated?)
On 29/03/06, Ed Singleton [EMAIL PROTECTED] wrote: On 29/03/06, Fredrik Lundh [EMAIL PROTECTED] wrote: btw, one alternative could be to use an infogame site for this purpose: http://infogami.com this gives you revision history, a permissions system (limiting editing to registered users might be a good idea), comments, an associated blog, voting, feeds, change logs, etc. alright, I got bored and uploaded a copy of the current Python tutorial to http://pytut.infogami.com Damn. You beat me to it by an hour. http://singletoned.infogami.com/_special/index I had a nightmare with character encodings (mainly because I'm terrible with them). I have a script written that does it all for me, but it keeps choking on characters. I just tried randomly converting things to Unicode at various points for over an hour until it worked. Ed Also, your looks better than mine. Did you write a script to do the table of contents too? Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Doc suggestions (was: Why class exceptions are not deprecated?)
On 29/03/06, Fredrik Lundh [EMAIL PROTECTED] wrote: Ed Singleton wrote: alright, I got bored and uploaded a copy of the current Python tutorial to http://pytut.infogami.com Damn. You beat me to it by an hour. http://singletoned.infogami.com/_special/index oops. sorry for that. Not at all. I'm quite proud that it was only an hour. I had a nightmare with character encodings (mainly because I'm terrible with them). I have a script written that does it all for me, but it keeps choking on characters. I just tried randomly converting things to Unicode at various points for over an hour until it worked. sounds weird. iirc, there were only one page that contained non-ascii characters, and the latest html2text.py script had no problems dealing with that one. node4 and node5 caused problems for me. I'm still struggling a bit with character encodings so that probably caused most of my problems. Also, your looks better than mine. did you look at it before or after I added the new stylesheet? ;-) Before. Now it looks gorgeous. Did you write a script to do the table of contents too? nope; I did that all by hand. I plan to write some scripts to get contents *out* of infogami, though, but that'll have to wait for some other day. anyway, do you want to keep your version, or should we standardize on the pytut version ? and are there any willing community contributors out there? Standardise on yours obviously, though I might keep mine around to keep playing with the script. It's a bit clumsy at the moment, but I can see there's some potential there for having a general script to rip content out of sites and put it in a wiki (if only for the rest of the python docs, should this project succeed). I'd also be interested in seeing how you did it as it would be the first time I could directly compare what I did to how an expert does it. I'd suggest adding some sort of guidance page so that people know roughly what's expected. IE can they just add questions and comments into the text, hoping that someone more knowledgeable will sort it out (or delete it). Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: [CODE] - Python Newcomer Starting with Coding
On 21/03/06, Ilias Lazaridis [EMAIL PROTECTED] wrote: Where can I find practical coding examples for real life coding problems? Something like a categorized solution guide? This sounds quite a lot like PLEAC. It certainly contains a lot that you would find useful. http://pleac.sourceforge.net/pleac_python/index.html Also, try using the python-tutor list. It's a lot more helpful for questions like these. My current problem: * create a folder * seems to be: os.mkdir(path) Try using the Path module. It makes all that stuff much easier: http://www.jorendorff.com/articles/python/path/ Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: random playing soundfiles according to rating.
On 8 Feb 2006 19:49:09 -0800, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I am a little bit stuck I want to play a bunch of soundfiles randomly, but i want to give each soundfile a rating (say 0-100) and have the likelihood that the file be chosen be tied to its rating so that the higher the rating the more likely a file is to be chosen. Then i need some additional flags for repetition, and some other business. I am guessing a dictionary would be a great way to do this, with the key being the soundfile name and the values being my ratings and other flags associated data. It depends how accurate you want the likelihood to be and how important performance is. I was thinking about this in respect of queueing mp3s from my collection (10,000+) to be played based on a 1-5 star rating (five stars is five times more likely to be played than 1 star). If speed is no issue (for example you can queue an mp3 while the current one is playing), then Ben's solution is the classic one. Store the total of all your scores (or calculate it on the fly if you don't have too many files), pick a random number up to that total, and then iterate through all your scores, subtracting each score from the total, until the total reaches zero, and then play that file. However that approach gets slower and slower the more files you have (slower to calculate the total and slower to iterate through the files). If speed is more of an issue, you could give up on trying to use a perfect probability, and just pick 10 (or 50, or 100) files at random, and then play one of those based on the above approach. Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Rethinking the Python tutorial
On 09/02/06, Magnus Lycka [EMAIL PROTECTED] wrote: While the official Python Tutorial has served its purpose well, keeping it up to date is hardly anyones top priority, and there are others who passionately create really good Python tutorials on the web. I think 'A Byte of Python' by Swaroop C H is a good beginners tutorial, and 'Dive Into Python' by Mark Pilgrim is a good tutorial for more experienced programmers. My radical idea is that we mirror these at diveinto.python.org and byteof.python.org, and simply remove the old tutorial from the Python 2.5 (or 2.6?) docs. Give these two good texts an official status as the Python tutorials. Just as we want to adopt best of breed packages for the standard library, I think we should use best of breed documentation, and I think there are less backward compatibility issues with tutorials than with libraries. :) I think this change would give us better docs as well as a smaller maintenance burden. If a day comes when Mark Pilgrim or Swaroop C H don't want to maintain these texts, I strongly suspect that there are other tutorials we can replace them with if noone else steps in to keep them up to date. How about putting the current tutorial into the wiki and seeing if people start updating it? I'm not saying it would work, but it might have interesting effects... Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On 08/02/06, Magnus Lycka [EMAIL PROTECTED] wrote: Ed Singleton wrote: I'm a fairly average programmer (better than average compared to my immediate colleagues). I've read every tutorial I can get my hands on, but I have no _memory_ of ever coming across the del keyword, let alone that it is fundamental to Python, and I have no idea what collections school is. I doubtless have read of it at some point, but as no importance has ever been attached to it, I have probably not remembered it. Similarly, I remember slices simply because they are handy, not because I have ever heard of them being fundamental before. Ok, I can understand that, but I think that you really understand that the strength of a programming language such as Python is that it's like lego bricks. You have some basic pieces, and you can combine them to into something unique that does what you want. There are plenty of statements, operators, functions, types, modules and other things in Python already. I can well imagine that you had forgotten about del, and that you don't immediately think about slices when you wonder how to empty a list. It's like when I build lego with my son. I guess he has around 2000 pieces, and it's not always easy to spot what you need. It was difficult enough when I was a kid. Now there are so many different kinds of pieces, shaped to fulfil some niche usecase. One thing that I'm sure of is this: Making more kinds of odd-shaped pieces, especially prepared to solve the specific problem I'm facing right now, won't make it easier to understand or use Python in the long run. I agree utterly with this, particularly the general philosophy of having simple bricks that work in as many different places as possible. The point is that having to use del to clear a list appears to the inexperienced as being an odd shaped brick when they've already used the .clear() brick in other places. Having bricks that work in lots of places makes the language 'guessable'. I've never cleared a list before, but I've cleared dictionaries and I guess the same way would work here. The problem is you have to be very careful when talking about this, not to use the C-word, because that's the hobgoblin of little minds, whereas in almost every other field it is considered an important part of usability. I've used Python for almost 10 years now, and I still learn new things, and I sometimes come across things that I once new but had forgotten. It might work for a while to add a new convenience function as soon as someone finds that they don't immediately now how to solve a certain problem. It's my impression that that's pretty much the idea with PHP. It's not Python though. PHP is only successful in a fairly narrow (if important) niche, it has failed in getting used outside its niche, and I assume we'll see a decline in its use one the web pretty soon, just as it happened with Perl. (Whether RoR, something Python based or something entirely new will replace it is beyond my radar screen though.) -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On 08/02/06, Magnus Lycka [EMAIL PROTECTED] wrote: Ed Singleton wrote: Is it obvious to a newbie what the difference between mappings and not-mappings, and is it obvious exactly what is and isn't a mapping? Should it be necessary to know python before it becomes easy to use? QOTW! (You are joking, aren't you? :) It was a genuine question. Judging from one of your other responses, that you are still learning new things and remembering forgotten ones after 10 years, I assume the answer is no, it is not necessary. (I'm also assuming you find Python easy to use). The thing that first attracted me to Python was that I only had to read a page or two of the tutorial before I could get started on doing little things with Python and find it easy. I can undestand how people can turn a bit defensive when some people who are more skilled in programming than in diplomacy basically tells the confused that they are ignorant and should just learn the language. On the other hand, I think that Art Siegel said it very well: My ability to grok Python to any extent, from that starting point, was based on an understanding that it was my responsibility to come to Python, not it to me. (Actually, that's a much better QOTW! It gives me flashbacks from a book I once read, http://www.amazon.com/gp/product/0060958324 ) There are just a few statements in Python. Some of them should really have been functions (print and exec) but anyway, they are still few enough to learn. There are also a few ways to get inside composite objects, x.y, x[y], x[y:z]. These things are among the most fundamental in Python. If luminaries like Fredrik Lundh and Raymond Hettiger tells you that things should be done in a certain way, it's really just silly to argue further. I've programmed Python since 1996, but if these guys tell me I'm wrong, I won't bother to argue. If I don't understand their position, I'll try to study the subject further, and I might ask them to clarify, but I'll assume that they are right. That assumption has worked so far for me. I didn't know they were luminaries. I apologise. I've never heard of any of the people on the list before I came to Python and the only people I've learned to trust are Kent Johnson and Alan Gauld. I guess if I start to see those guys say things that turn out to be right I might start assuming they are right as well. Maybe there should be a list of luminaries on the website so we know who not to argue with? There are warts and quirks in Python, everybody will agree to that, but Python is *not* Perl. A basic motto has always been to avoid synonyms, to try to provide as few ways to do one thing, rather than to provide as many ways, as possible. This has proven very successful in making Python easy to learn and use. The opposite approach has made Perl into the favourite programimng language among people who think that if the program was difficult to write, it should be difficult to read as well! I think people concentrate on the total number of ways to do something, when the obviousness or consistency of one one of those ways is more important. For example one of the few things Microsoft does okay at, is in having a pretty consistent interface across their applications. There's a menu bar that (theoretically) has all the commands you can perform in a structured format. But you can also use reasonably consistent keyboard shortcuts to do something, or context menus for things that you do a lot. Having several different ways means that everyone can use the way they prefer. Beginners tend to use the menu bar a lot as they can always find what they want there, but can start using the keyboard shortcuts as they start to perform the action a lot and start to become more experienced. I know this isn't entirely applicable but hopefully you see the analogy. When you can't transfer one approach from one type to another, there is a reason for that. A few times it might be due to some obscure practical aspect of the implementation, but most of the time, it's completely intentional, and finding these aspects of Python, learning why they are the way they are, and embracing the language rather than trying to fight it, is actually very rewarding. No, it's rewarding for a certain type of person. It's not a rewarding activity for every type of person. I find it deeply frustrating when I have to constantly look things up to see what is the way of doing things for this type. I'd rather spend my time writing code then looking things up to see which way I have to do it now. Tuples aren't just immutable lists--they have different purposes beyond that. Ordereded and unordered collections are conceptually different. Neither call-by-referece nor call-by-value describes parameter passing in Python well, the clue lies in understanding how assignments and objects work, and you need to understand the difference between mutable and immutable objects etc
Re: Question about idioms for clearing a list
On 7 Feb 2006 00:27:05 -0800, Raymond Hettinger [EMAIL PROTECTED] wrote: There was a pithy Tim Peters quotation to the effect that he was unpersuaded by language proposals predicated on some hypothetical average programmer not being smart enough to understand something that the rest of us find to be basic. The problem is that the average programmer in question isn't hypothetical in this case. I'm a fairly average programmer (better than average compared to my immediate colleagues). I've read every tutorial I can get my hands on, but I have no _memory_ of ever coming across the del keyword, let alone that it is fundamental to Python, and I have no idea what collections school is. I doubtless have read of it at some point, but as no importance has ever been attached to it, I have probably not remembered it. Similarly, I remember slices simply because they are handy, not because I have ever heard of them being fundamental before. (I don't argue their fundamentalness one way or other, it's just that you seem to think that all people who have learned Python have some knowledge of this hugely important feature). The other problem with your use of the quote is that the smartness of the average programmer, or their ability to understand the feature, is not in question. It is their ability to know of the existence of the feature, or to find out about it. As a general rule of thumb, I would say that if a person is struggling with a language, it is primarily a problem with the language, and than problem with the documentation, and lastly a problem with the person. Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On 7 Feb 2006 02:02:42 -0800, Ben Sizer [EMAIL PROTECTED] wrote: Fred is exactly correct. Slicing is absolutely basic to Python. Accordingly, it gets covered right at the beginning of the tutorial (section 3.1). Yes, right after UTF encoding details, complex numbers, and various mentions of shell scripts. Now that is GPotD (Good Point of the Day) which is much better than QotW as it's actually useful. I don't want to criticise the hard work that went into making the tutorial but let's not pretend it's the epitome of documentation or even necessary the most obvious reference for users. Likewise, the del keyword is fundamental -- if you can't get, set, and del, then you need to go back to collections school. I have hardly used the del keyword in several years of coding in Python. Why should it magically spring to mind in this occasion? Similarly I hardly ever find myself using slices, never mind in a mutable context. del L[:] is not obvious, especially given the existence of clear() in dictionaries. I'm not necessarily requesting a clear() method, but I am requesting a little more understanding towards those who expected one. The list interface is full of redundant convenience methods, so one more would hardly be a surprise or an unreasonable thing for people to expect. Again we unfortunately have a bit of an attitude problem towards anyone posting here that doesn't know whatever the experts think is obvious. I agree wholeheartedly with this, particularly as there often seems to be strong (and confusing) resistance to making Python easier and more obvious. I can only assume that it is by people who have forgotten what it is like to be an average programmer. (Paul Graham constantly makes the same mistake when he goes on about how everyone should use lisp). Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On 07/02/06, Fredrik Lundh [EMAIL PROTECTED] wrote: Bryan Olson wrote: So is consistency; it ain't Perl, thank Guido. consistency is the hobgoblin of little minds. Python now has, what, three built-in mutable collections types: lists, dictionaries, and sets. Dicts and sets both have a clear() method and lists do not. dicts and sets are mappings, and lists are not. mappings don't support slicing. lists do. are you sure you know Python ? Is it obvious to a newbie what the difference between mappings and not-mappings, and is it obvious exactly what is and isn't a mapping? Should it be necessary to know python before it becomes easy to use? Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On 07/02/06, Raymond Hettinger [EMAIL PROTECTED] wrote: Again we unfortunately have a bit of an attitude problem towards anyone posting here that doesn't know whatever the experts think is obvious. I agree wholeheartedly with this, particularly as there often seems to be strong (and confusing) resistance to making Python easier and more obvious. That is B.S. We simply disagree on whether list.clear() is an improvement. Adding a non-essential method to an important API does not make the language t easier to learn or use. Yes it does. It makes it a lot easier to learn. Even list.del() would be a massive improvement. Also, it doesn't address the wider issue that learning about slices is important for understanding the language (it appears in many guises). Likewise, learning about the del-statement is somewhat essential for people setting out to mutate collections in-place. You're not helping someone if you steer them away from learning the basics. Maybe it's better to put the basics in a place that they will find them, rather than trying to steer them. Manipulating the language is hell of a lot easier than manipulating every user. Languages are only there for people to use therefore I'm going to go out on a limb and say that they should be designed for people to use. I can only assume that it is by people who have forgotten what it is like to be an average programmer. More B.S. My thoughts on the issue are informed by several years of answering average programmer questions on the python-help list. In that time, the question of how to clear a list has never come up. There are several areas of recurring confusion but this isn't one of them. You're mud-slinging over a non-issue. My thoughts on the issue are informed by many years of being an average programmer and knowing and working with lots of average programmers (and well below average programmers for that matter) I'm not mud-slinging, I'm just saying that people are very dismissive of making the language easier to use for newbies. Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On 7 Feb 2006 07:08:17 -0800, Raymond Hettinger [EMAIL PROTECTED] wrote: As a general rule of thumb, I would say that if a person is struggling with a language, it is primarily a problem with the language, and than problem with the documentation, and lastly a problem with the person. I would swap the first two. No language has yet been invented (including HTML and LOGO) that someone doesn't struggle with. In contrast, no documentation has ever been written that couldn't be improved. (I should clarify that by documentation, I mean external documentation rather than self-documentation features) Given the choice of having a language that is hard to use but has good documentation or one that is easy to use but has bad documentation, which would you go for? If you could write the perfect language, would it be so easy to use (including self-documentation) that no one ever needed to look things up in external documentation, or would it have such good documentation that you could always find what you needed in external documentation? Documentation is there to cover up the cracks in the none-obvious (or confusing) parts of the language. Python is starting to show that one day anything but the most perfunctory documentation may one day become unnecessary. Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about idioms for clearing a list
On 07/02/06, Fredrik Lundh [EMAIL PROTECTED] wrote: Ed Singleton wrote I'm not mud-slinging, I'm just saying that people are very dismissive of making the language easier to use for newbies. no, you're telling people who have long experience in explaining things to newbies that their experiences don't count, and that you are the only newbie that's important. No, I'm saying that people are very dismissive of making things easier to use for newbies (as you yourself were only a few posts ago) Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Help me in this please--is Python the answer?
On 11 Jan 2006 17:54:05 -0800, Ray [EMAIL PROTECTED] wrote: Hello, I've got the chance to determine the technology to use in creating a product similar to this: http://www.atomicisland.com/ Now the thing is that I need to sell this to the guy with the money. I've developed for years with C++ and Java, last 7 years J2EE, and I'm kinda sick of the bloated feeling that the whole J2EE/appserver business carries into the picture. Personally I have found that if you need to sell a technology on, saying it's written in Java is an advantage generally (because it's a standard). If it's written in Python you may get asked why it has been written in a scripting language if they've heard of it at all. Python is the language that I use at home, so I've been thinking of using this to implement the product mentioned above. I've personally experienced the pleasure of programming in it, and as such, I hope that this will translate to advantage over our competitors (a la Paul Graham's argument for Lisp). From my brief look at that url you gave, it looks like you are trying to enter a very crowded market place. You will have to perform a lot better than your competitors in order to succeed (they have a head start on you). There's no way on earth you can do that by using exactly the same tools as them, so you have to choose better tools. Almost by definition, the tools that the majority are using are NOT the best tools for the job. If I were you I'd definitely choose Python, if only because everyone else is not using it yet. That said, my experience with Python is limited to toy programs, that I write myself for my own use. As such, I have several concerns: 1. How scalable is Python? In J2EE, when the load gets really big, we can resort to clustering. Same goes about availability. Is there anything that will help here in Python? (Mind, my Python experience is usually with scripts and console). 2. If there is, what is the transition like from being lightweight to heavyweight? E.g.: in J2EE we can use Tomcat at first as a lightweight web container, and scale as necessary using a more powerful appserver. Is this possible in Python? If I were you I'd concentrate on creating a website that actually works. Your chances of creating a website that needs to scale to be 'heavyweight' are very slim. If you manage to get to that point then you can start worrying about how to cope with all the money that's rolling in ;) AFAIAA Python scales better than Java as any performance critical parts can be easily rewritten in C. To spend too much time worrying over it is premature optimisation though. 3. Have any of you done this before? As in you come from a heavy J2EE background, and then switch to doing something equally serious in Python? In your experience, in the end, did you find Python suitable at all for this domain or you think you should have stuck to J2EE? What are the pros and cons you discovered? I don't have much experience of Java tbh, but I've never heard of any pro's to using it, except for the fact that it's more acceptable to big business and it's easier to get mediocre programmers for it. (I'd love to develop in Python and get paid for it finally, but at the same time I do want to give the money guy the best value for his money...) The only thing you really need to be happy is to find something you enjoy doing and to do it. Money is definitely secondary to that. If you have a chance to be paid for working in Python, then go for it; even if you fail, you will have spent your days in a happy state. Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Which Python web framework is most like Ruby on Rails?
On 22/12/05, A.M. Kuchling [EMAIL PROTECTED] wrote: On 20 Dec 2005 15:05:15 -0800, Michael Tobis [EMAIL PROTECTED] wrote: Python people don't really think that way. As a community we really seem to inherit the open source dysfunction of trying harder to impress each other than to reach out to the rest of the world. The problem is Yes; I've long worried about this, but have no idea how to fix the problem. Python users largely talk to other Python users, not to the world at large. A good start would be for there to be a way for newbies to get heard more easily. Newbies were all quite recently nonPythonPeople, and as such have some very valuable insights into what it is like being a normal, nonPythonPerson. They normally get told they aren't pythonic yet, or that they should write a PEP, or some such. Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: Which Python web framework is most like Ruby on Rails?
On 22/12/05, A.M. Kuchling [EMAIL PROTECTED] wrote: On Thu, 22 Dec 2005 14:05:08 +, Ed Singleton [EMAIL PROTECTED] wrote: Yes; I've long worried about this, but have no idea how to fix the problem. Python users largely talk to other Python users, not to the world at large. A good start would be for there to be a way for newbies to get heard more easily. I don't see the connection between Python users talk too much to other Python users and newbies don't get heard. I wasn't particularly saying that there was a direct connection. You said you had been worrying about the problem of Python suffering from the open source dysfunction and had no idea how to fix it. I was suggesting one of the main ways of fixing it. In a little greater depth: Open source suffers from insularity because the community places a huge emphasis on reputation. Reputation is necessarily built-up over time and once people have reputation they tend to forget what it is like to not have it. (Additionally the type of person required to expend that much effort in building up reputation tends not to spend much time doing other, more normal things). Thus the people who are listened to the most in any OSS community are those who tend to know less about what it is like completely outside of the OSS world. These people tend to naturally gather to talk to each other, and they tend to stratify themselves, generally paying good attention to those above them and (in better communities like this one) those on the same level and just below. This leads to them insulating themselves even more from reaching out to the real world. Luckily there is a large group of people who are involved in the community but have recently been participating in the real world. They have a strong understanding of what needs to be done to reach out to the real world, because they themselves have just recently been reached out to. They are the newbs. Ed PS If you don't know how to reach out to the real world, then by definition you are not listening to newbs. PPS Some cool sayings about newbs: The newbs shall inherit the earth The future's bright; the future's newb We don't inherit the OSS community from it's leaders; we merely borrow it from the newbs -- http://mail.python.org/mailman/listinfo/python-list
Re: General question about Python design goals
On 29/11/05, Christoph Zwerschke [EMAIL PROTECTED] wrote: Fredrik Lundh wrote: on the other hand, it's also possible that there are perfectly usable ways to keep bikes and bike seats dry where Christoph works, but that he prefers not to use them because they're violating some design rule. Depends on how you understand perfectly usable. My collegue always carries his expensive racing bike to our office in the 3rd floor out of fear it may get wet or stolen. But I think this is not very convenient and I want to avoid discussions with our boss about skid marks on the carpet and things like that. Probably that collegue would not complain as well if he had to cast tuples to lists for counting items - you see, people are different ;-) If you're leaving skid marks on the floor, maybe you need better underwear? http://www.google.co.uk/search?q=skid+marks+slang Sorry to lower the tone. Ed -- http://mail.python.org/mailman/listinfo/python-list
Re: how to modify code while debugging it without having to stop and then restart debugger
I used Visual Basic a long time in the past and I know what you mean. The ability to step through code line by line was very useful in a language where you often didn't know what was happening. I particularly loved the ability to hover the mouse over any variable or expression and see the value at that point in the code. As a learning tool it would be excellent for Python, as would the ability to step through the code, hit an error, step back one line, change the line that caused the error and then continue stepping forward again. However I have to say that since using Python, I haven't needed these features as much (though I still would have liked to have them available). Ed On 08/11/05, python [EMAIL PROTECTED] wrote: hello and thanks for reading this, i have been a dos/windows user using some form of the basic language for 30 years now. i own and run a small programming company and there is one feature that keeps me in the windows/basic world. while i will agree that it has not evolved well, it does have one awesome feature that i have yet to see replicated in any linux product that i know about so far. i am a long time windows user and have had a great way to learn new api. to write some code and then run it. if there is an error, the debugger will load. then i can figure out what the eror is, just touch up the ocde and continue to run the code. i do not have to stop the code, modify the code, rerun the code. often an error will only happen after a complex set of conditions and not have to completely stop the app is a fantastic way to debug. there are several applications that can do this. in fact, the free version of the visual studio 2005, which is free, have this ability. so how can i use python to debug code and change that code without having to restart the code. thanks so much, dave -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Python's website does a great disservice to the language
I think I'm going to back you up a little bit here. You've gone about this in a bit of a half-assed way (and pissed off a fair few people in the process) but you are right that the site needs a redesign. It uses tables for layout with inline styles and font tags and doesn't really use CSS. It has invalid html, and doesn't even attempt xhtml. From an accessiblity point of view it has a poor choice of font and a poor choice of colours (blue links on a blue background). Design issues such as what logos to use and such aren't really my forte, but from a web developers point of view it's a badly made website. Ed On 01/11/05, CppNewB [EMAIL PROTECTED] wrote: I was trying to advocate using Python for an upcoming prototype, so my boss went out to take a look at the documentation and try and get a feel for what the language is all about. First comment; I hope the language is designed better than the site. The site is readable, but is amateurish. If I had an ounce of design skills in me, I would take a stab at it. Maybe we could round up a couple of designers to donate some time? Maybe we could build a basic CMS on top of Django or TurboGears (displaying Python's capability as a web development stack)? -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Rename files with numbers
The best free app I've found for this is MusicBrainz [www.musicbrainz.com].
This has a huge database of obsessively correct details of albums
which can be formatted in anyway you choose. It can automatically
recognise which song an MP3 is!
This is a similar script I wrote to renumber files in sequential
order. It assumes that everything before the first underscore can be
replaced.
from path import path
import re
def renumberfiles(filesdir, startnum=1):
d = path(filesdir)
print d
x = startnum
for f in d.files():
fname = f.name.split('_', 1)
fname = str(x).zfill(2) + _ + fname[-1]
fname = re.sub(r ,r_,fname)
fname = re.sub(r__,r_,fname)
x = x + 1
print f.name, ==,
f.rename(f.parent + \\ + fname)
print fname
As you can see, I use the path module rather than os.path. it's a
much more intuitive way of handling files.
http://www.jorendorff.com/articles/python/path/
Ed
On 01/11/05, Dave Benjamin [EMAIL PROTECTED] wrote:
On Mon, 31 Oct 2005, Micah Elliott wrote:
On Oct 31, Micah Elliott wrote:
Now I need to go beautify my collection. :-)
While a fun exercise, there are probably already dozens (or
thousands?) of utilities in existence that do this and much more.
Seconded. I initially considered writing a script to rename a huge pile of
MP3 files, but halfway through, I thought, there's *got* to be a better
way. I found this app: http://www.softpointer.com/tr.htm
Bought it the next day. Holy crap, what a gigantic timesaver. It looks up
albums based on track lengths, downloads titles from freedb and Amazon,
does ID3 tagging, renaming, moves files into separate directories... I
busted through about 20 gigs of MP3s in three days. I kid you not.
If this is just a fun toy Python project, don't let me discourage you, but
if you have more than a handful of albums to rename, trust me. This
problem has been solved.
Here's a list of apps, including TagRename, that can query freedb:
http://www.freedb.org/freedb_aware_apps.php
--
.:[ dave benjamin: ramen/[sp00] ]:.
\\ who will clean out my Inbox after I'm dead[?] - charles petzold
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
