Re: generate list of partially accumulated values
On Sep 16, 11:56 am, cesco [EMAIL PROTECTED] wrote: Hi, I have the following list: l = [1, 2, 3, 4] and I'd like to obtain a list like the following: l_partial_sum = [1, 3, 6, 10] (that is [1, 1+2, 1+2+3, 1+2+3+4]) Is there a simple way to accomplish this? I came up with the following solution but it seems a bit too elaborated for the task: l_partial_sum = [reduce(lambda x,y:x+y, sub_l) for sub_l in [l[:i+1] for i in range(len(l))]] Any help will be appreciated. Thanks Francesco l = [1, 2, 3, 4] [sum(l[:x+1]) for x in xrange(len(l))] [1, 3, 6, 10] - Björn Kempén -- http://mail.python.org/mailman/listinfo/python-list
Re: generate list of partially accumulated values
Uh... that turned out weird. Anyways, here goes again l = [1, 2, 3, 4] [sum(l[:x+1]) for x in xrange(len(l))] -- http://mail.python.org/mailman/listinfo/python-list
Python statements not forcing whitespace is messy?
Am I the only one that thinks that python statements should force whitespace before and after them? Right now this is not enforced and for an example these statements are valid printhello fooifbarelsefoobar for(x,y)in[(1,2),(3,4)]:print(x,y) [(y)for(x,y)in[(foo,2),(bar,4)]iffooin(x)] ...and so on. I know that writing code like this really shouldn't be done but wouldn't it be a good idea to enforce the use of whitespace around statements? (I wrote a short blog post about this here http://blog.buffis.com/?p=55 but thought I would post here as well to see what other developers think) - Björn Kempén -- http://mail.python.org/mailman/listinfo/python-list
Re: Python statements not forcing whitespace is messy?
On Sep 15, 10:11 pm, J. Cliff Dyer [EMAIL PROTECTED] wrote: buffi wrote: Am I the only one that thinks that python statements should force whitespace before and after them? Right now this is not enforced and for an example these statements are valid printhello fooifbarelsefoobar for(x,y)in[(1,2),(3,4)]:print(x,y) [(y)for(x,y)in[(foo,2),(bar,4)]iffooin(x)] ...and so on. On the other hand, this is just as bad: [ ( y ) for ( x , y ) in [ ( foo , 2 ) , ( bar , 4 ) ] if foo in ( x ) ] And I'd hate to have to remember all of the rules for what can go together and what can't, especially when it comes time to debug. No. I don't think it should be forced, but maybe put it in PEP8 or PEP3008. Also, the only thing I find thoroughly disagreeable in all of that mess, is the run-ins involving characters. The rest are at least clear at a glance what belongs where. Also, would you require the following? my_function (swallow='European') Because that is just an awful use of whitespace. Cheers, Cliff I believe that having whitespace around the builtin statements, and having whitespace around everything is pretty different. There would be no downside whatsoever to enforcing this, except for backwards incompatibility (which is a rather huge downside but well... py3k is gonna break everything anyways). There obviously shouldnt be any limit to the maximum amount of whitespace used around statements (due to formatting and so on), but allowing stuff like printhello is just horrible. - Björn Kempén -- http://mail.python.org/mailman/listinfo/python-list
Re: how could change backcolor of console?
On Sep 15, 3:55 pm, [EMAIL PROTECTED] wrote: Hi,everyone: I am a c programmer,and want using Python instead of C I can change backcolor using C,like this: textbackground(color); How can I do in Python? Best regards 点 击 此 处！免 费 试 玩 07 年 最 受 期 待 的 游 戏 大 作 ！ textbackground() is not part of the C programming language but rather a part of an rather old module for msdos. http://en.wikipedia.org/wiki/Conio.h If you want terminal colors in python you can use the curses module but I doubt that it will work in windows. http://docs.python.org/lib/module-curses.html -- http://mail.python.org/mailman/listinfo/python-list
Re: problems using pythom tempfile module
On Sep 15, 11:11 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello everyone, I'm trying to test the tempfile module with the following script, which basically creates a temporary file, fills the file with some test data and prints it. import tempfile t = tempfile.TemporaryFile() t.write(lalalala) t.flush() print t.read() Unfortunately, the print statement gives me an empty string. Can somebody tell me what I'm doing wrong ? regards Samir Do a t.seek(0) before you do the read to rewind the file and then it should work. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python statements not forcing whitespace is messy?
On Sep 15, 11:49 pm, Steve Holden [EMAIL PROTECTED] wrote: buffi wrote: On Sep 15, 10:11 pm, J. Cliff Dyer [EMAIL PROTECTED] wrote: buffi wrote: Am I the only one that thinks that python statements should force whitespace before and after them? Right now this is not enforced and for an example these statements are valid printhello fooifbarelsefoobar for(x,y)in[(1,2),(3,4)]:print(x,y) [(y)for(x,y)in[(foo,2),(bar,4)]iffooin(x)] ...and so on. On the other hand, this is just as bad: [ ( y ) for ( x , y ) in [ ( foo , 2 ) , ( bar , 4 ) ] if foo in ( x ) ] And I'd hate to have to remember all of the rules for what can go together and what can't, especially when it comes time to debug. No. I don't think it should be forced, but maybe put it in PEP8 or PEP3008. Also, the only thing I find thoroughly disagreeable in all of that mess, is the run-ins involving characters. The rest are at least clear at a glance what belongs where. Also, would you require the following? my_function (swallow='European') Because that is just an awful use of whitespace. Cheers, Cliff I believe that having whitespace around the builtin statements, and having whitespace around everything is pretty different. There would be no downside whatsoever to enforcing this, except for backwards incompatibility (which is a rather huge downside but well... py3k is gonna break everything anyways). There obviously shouldnt be any limit to the maximum amount of whitespace used around statements (due to formatting and so on), but allowing stuff like printhello is just horrible. If you don't like it then don't write it. I've been reading this group on and off for about ten years and I believe your email is the first to point out that this is possible. Clearly it isn't something that happens a lot, and I don't know why you have a bug up your ass about it, as the Americans say. The Python philosophy is to be permissive, and to expect individual users to write readable Python. Since they obviously do (one message in ten years providing a counter-example) I think you are wasting your time and energy on this. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Sorry, the dog ate my .sigline I actually found out about this myself while grading student labs. I myself didn't even know that you could write statements like this until then, but since some students does it that means that there should be other people out there as well that does it. And I can't say that I agree about The Python philosophy being permissive, and to expect individual users to write readable Python. Python enforces proper indentation which I think is a great idea since I'm used to reading horribly indented code by others. I would love to see this extended to enforce proper whitespacing for statements. There should be one-and preferably only one-obvious way to do it. is a phrase that is usually considered pythonic, and I think that it should also apply a bit when it comes to coding conventions. - Björn Kempén -- http://mail.python.org/mailman/listinfo/python-list
Re: Needless copying in iterations?
On Sep 15, 11:58 pm, James Stroud [EMAIL PROTECTED] wrote: Hello all, I was staring at a segment of code that looked like this today: for something in stuff[x:y]: whatever(something) and was wondering if the compiler really made a copy of the slice from stuff as the code seems to suggest, or does it find some way to produce an iterator without the need to make a copy (if stuff is a built-in sequence type)? Or would it be more efficient to do the more clumsy (in my opinion): for i in xrange(x, y): whatever(stuff[i]) James itertools.islice does what you want import itertools for something in itertools.islice(stuff, x, y): whatever(something) -- http://mail.python.org/mailman/listinfo/python-list
Re: Needless copying in iterations?
On Sep 16, 12:20 am, James Stroud [EMAIL PROTECTED] wrote: buffi wrote: On Sep 15, 11:58 pm, James Stroud [EMAIL PROTECTED] wrote: Hello all, I was staring at a segment of code that looked like this today: for something in stuff[x:y]: whatever(something) and was wondering if the compiler really made a copy of the slice from stuff as the code seems to suggest, or does it find some way to produce an iterator without the need to make a copy (if stuff is a built-in sequence type)? Or would it be more efficient to do the more clumsy (in my opinion): for i in xrange(x, y): whatever(stuff[i]) James itertools.islice does what you want import itertools for something in itertools.islice(stuff, x, y): whatever(something) Thanks buffi! So I guess the interpreter does no optimization in the latter? James No, as far as I know it makes a new list out of the slice when you do it like for something in stuff[x:y] - Björn Kempén -- http://mail.python.org/mailman/listinfo/python-list
Re: Needless copying in iterations?
On Sep 16, 12:25 am, Calvin Spealman [EMAIL PROTECTED] wrote: This is a case where its up to the type involved. For example, xrange() slices the way you want but range() does not. Coul you explain this? As far as I know you can't slice a xrange - Björn Kempén -- http://mail.python.org/mailman/listinfo/python-list
Re: problems using pythom tempfile module
Pretend that you have a number that is always pointing somewhere in your temporary file. It starts a 0. If you then write lalalala (8 characters) it will point after these at position 8, so that you can write more stuff after your previous text later by calling write. The read method reads all the data from the current position of the pointer to the end of the file. If you simply call it after writing, you wont get anything since you are already at the end of the file. Therefore you rewind the pointer back to the start by calling seek which takes the position in the file to go to... your_file.seek(0) returns you to the start of the file to read all of its data - Björn Kempén -- http://mail.python.org/mailman/listinfo/python-list
Re: Scaling pictures
Kajsa Anka wrote: I would like some advice, I'm going to build a small app that will, among other things, scale images so that they can be published on a web site. I've never done any image processing in python before so I would like to ask what is the best way of doing this, I will not do anything else than scaling the images. I found the Python Imaging Library but before I dive into that I would like to know if there is a better way of doing this. I prefer using imagemagick whenever I have to do anything related to images. http://www.imagemagick.org/script/index.php Resizing an image would be something like this import os filename = picture.png outputfile = picture_resized.png new_size = 100x100 os.system(convert %s -resize %s %s % (filename, new_size, outputfile)) -- http://mail.python.org/mailman/listinfo/python-list
Re: Persistent variables in python
There is a problem that this trick only works for functions and not for methods as it assumes that there is a global name through which you can access the function. I didn't really see any issue with this since methods can store the persistant data from the method inside the class containing it :) /buffi -- http://mail.python.org/mailman/listinfo/python-list
Re: can't instantiate following inner class
Pyenos wrote: class One: Two() #can't instantiate class Two: Three() #can't instantiate class Three:pass Python parses code from top to bottom. Since it first tries to read the class One and finds the class Two inside it, it throws an error since it is not defined yet. Reverse the order and it will work (like this:) class Three:pass class Two: Three() class One: Two() Of course this makes no sense whatsoever as the poster above me wrote. The reason that you can use classes in the order the second poster wrote is because of init not being called until you make an instance of that class, and by then all classes are loaded. /buffi (buffis.com) -- http://mail.python.org/mailman/listinfo/python-list
Persistent variables in python
Found out a quite fun way to store persistent variables in functions in python. def doStuff(): try: #Will throw exception if not set doStuff.timesUsed ## #Insert stuff to do each time the function is called here ## doStuff.timesUsed+=1 print Function call! except AttributeError: doStuff.timesUsed = 0 # set up the variable ## #Put other stuff to call the first #time the function is called here ## print First call! doStuff() #recursive call. Will not throw exception now Some output testing this: doStuff() First call! Function call! doStuff() Function call! doStuff() Function call! doStuff() Function call! doStuff.timesUsed 4 Is this concidered bad coding practice since I guess persistent variables in functions are not meant to be? /buffi (www.buffis.com) -- http://mail.python.org/mailman/listinfo/python-list
Re: Persistent variables in python
I don't think so, since Python proudly says that functions are first-class objects. CherryPy does a similar thing to mark a method as exposed. But perhaps I'd write the code this way to avoid an unneeded and risky recursive call: def doStuff(some, arguments, may, *be, **required): try: doStuff.timesUsed += 1 except AttributeError: doStuff.timesUsed = 1 # ... special case for first call ... # ...common code... True, the recursivity is not needed there I guess :) It just feels so ugly to use try/except to enable the variable but I've found it useful at least once. /buffi (buffis.com) -- http://mail.python.org/mailman/listinfo/python-list
