Re: [Python-Dev] if-syntax for regular for-loops
Eric Smith wrote: I think it's a little too cute, and 'pass' is preferable. Agreed - it was just a little surreal to put the ... in as my usual pseudo-code stuff happens here marker, only to realise what I had written was still executable Py3k code. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] if-syntax for regular for-loops
Matthew Hawkins wrote: If there's another way of doing this I'd like to hear it. The pass statement is still the right way to denote an empty block (the compiler is already able to detect that and optimise the code appropriately). My tangential comment was based on the fact that this keyword could, in theory, be replaced with the ellipsis notation often used in pseudo-code to denote real code goes here. I don't think pursuing such a switch is actually a good idea - it was just odd to notice that the Py3k interpreter would quite happily execute the example code in my postscript when I had really only intended to write it as pseudo-code with sections missing. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] if-syntax for regular for-loops
Nick Coghlan wrote: it was just odd to notice that the Py3k interpreter would quite happily execute the example code in my postscript when I had really only intended to write it as pseudo-code with sections missing. Well, they do say that Python is executable pseudocode. :-) -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] if-syntax for regular for-loops
Greg Ewing wrote: Nick Coghlan wrote: it was just odd to notice that the Py3k interpreter would quite happily execute the example code in my postscript when I had really only intended to write it as pseudo-code with sections missing. Well, they do say that Python is executable pseudocode. :-) Indeed :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] if-syntax for regular for-loops
Steven D'Aprano wrote: On Sat, 4 Oct 2008 12:26:30 pm Nick Coghlan wrote: (Tangent: the above two try/except examples are perfectly legal Py3k code. Do we really need the pass statement anymore?) I can't imagine why you would think we don't need the pass statement. I often use it: * For subclassing exceptions: class MyTypeError(TypeError): pass * As a placeholder for code I haven't written yet. * As a no-op used in, e.g. the timeit module. And probably a few other places as well. Nick is literally (pardon the pun) saying that '...' could take the place of 'pass' in 3.0. His original examples are valid syntax, as written with the ellipses. For example: $ ./python Python 3.0rc1+ (py3k:66789, Oct 4 2008, 05:26:45) [GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2 Type help, copyright, credits or license for more information. try: ... ... ... except: ... ... ... else: ... ... ... finally: ... ... ... Ellipsis Ellipsis Ellipsis I think it's a little too cute, and 'pass' is preferable. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] if-syntax for regular for-loops
Hi. First post so here it goes. My name is Adde, and I'm a Swedish software developer. I've been programming for about 23 years now since starting with Basic on the C64. I've been through most well known and a couple of lesser known languages in search of the perfect one. At the moment I'm writing a custom ctypes interface to the Firebird database (need access to advanced features, portability to Windows and I definitely don't enjoy setting up GCC on Windows). I've programmed a lot of C/C++ in my days so I thought I'd at least join the list and see if anything piques my interest enough to dive in. With that out of the way, on to todays subject: I use list comprehensions and generator expressions a lot and lately I've found myself writing a lot of code like this: for i in items if i.some_field == some_value: i.do_something() Naturally it won't work but it seems like a pretty straight-forward extension to allow compressing simple loops to fit on one line. The alternative, in my eyes, suggests there's something more happening than a simple include-test which makes it harder to comprehend. for i in items: if i.some_field == some_value: i.do_something() One possibility of course is to use a generator-expression but that makes it look like there are two for loops and it feels like a waste setting up a generator just for filtering. for i in (i for i in items if some_field == some_value): i.do_something() Stupid idea? Am I missing some obviously better way of achieving the same result? Thanks, Adde ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] if-syntax for regular for-loops
Hi Andreas, On Fri, Oct 3, 2008 at 7:40 PM, Andreas Nilsson [EMAIL PROTECTED] wrote: Hi. First post so here it goes. My name is Adde, and I'm a Swedish software developer. I've been programming for about 23 years now since starting with Basic on the C64. I've been through most well known and a couple of lesser known languages in search of the perfect one. At the moment I'm writing a custom ctypes interface to the Firebird database (need access to advanced features, portability to Windows and I definitely don't enjoy setting up GCC on Windows). I've programmed a lot of C/C++ in my days so I thought I'd at least join the list and see if anything piques my interest enough to dive in. With that out of the way, on to todays subject: I use list comprehensions and generator expressions a lot and lately I've found myself writing a lot of code like this: for i in items if i.some_field == some_value: i.do_something() Naturally it won't work but it seems like a pretty straight-forward extension to allow compressing simple loops to fit on one line. The alternative, in my eyes, suggests there's something more happening than a simple include-test which makes it harder to comprehend. for i in items: if i.some_field == some_value: i.do_something() One possibility of course is to use a generator-expression but that makes it look like there are two for loops and it feels like a waste setting up a generator just for filtering. for i in (i for i in items if some_field == some_value): i.do_something() Stupid idea? Am I missing some obviously better way of achieving the same result? List comprehension. [i.do_something() for i in items if i.some_field == some_value] With the restriction that the statement you use must seem to return an expression.. For example [print(i) for i in range(9) if i % 2] Fails with SyntaxError, whereas def f(v): print (v) [f(i) for i in range(9) if i % 2] correctly prints 1 3 5 7 HTH, David -- Everything has reasons. Nothing has justification. Ĉio havas kialojn; Neniaĵo havas pravigeron. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] if-syntax for regular for-loops
On Fri, Oct 3, 2008 at 6:10 AM, Andreas Nilsson [EMAIL PROTECTED] wrote: With that out of the way, on to todays subject: I use list comprehensions and generator expressions a lot and lately I've found myself writing a lot of code like this: for i in items if i.some_field == some_value: i.do_something() Naturally it won't work but it seems like a pretty straight-forward extension to allow compressing simple loops to fit on one line. The alternative, in my eyes, suggests there's something more happening than a simple include-test which makes it harder to comprehend. for i in items: if i.some_field == some_value: i.do_something() One possibility of course is to use a generator-expression but that makes it look like there are two for loops and it feels like a waste setting up a generator just for filtering. for i in (i for i in items if some_field == some_value): i.do_something() Stupid idea? Am I missing some obviously better way of achieving the same result? It's been discussed already. Essentially, all that saves is a newline or two, which, as I think has been generally accepted, tends to hurt readability. Here's the full discussion: http://www.mail-archive.com/python-dev@python.org/msg29276.html Other than that, welcome! -- Cheers, Leif ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] if-syntax for regular for-loops
- Mensaje original De: Leif Walsh [EMAIL PROTECTED] Para: Andreas Nilsson [EMAIL PROTECTED] CC: python-dev@python.org Enviado: viernes, 3 de octubre, 2008 10:29:33 Asunto: Re: [Python-Dev] if-syntax for regular for-loops On Fri, Oct 3, 2008 at 6:10 AM, Andreas Nilsson wrote: With that out of the way, on to todays subject: I use list comprehensions and generator expressions a lot and lately I've found myself writing a lot of code like this: for i in items if i.some_field == some_value: i.do_something() Naturally it won't work but it seems like a pretty straight-forward extension to allow compressing simple loops to fit on one line. The alternative, in my eyes, suggests there's something more happening than a simple include-test which makes it harder to comprehend. for i in items: if i.some_field == some_value: i.do_something() One possibility of course is to use a generator-expression but that makes it look like there are two for loops and it feels like a waste setting up a generator just for filtering. for i in (i for i in items if some_field == some_value): i.do_something() Stupid idea? Am I missing some obviously better way of achieving the same result? It's been discussed already. Essentially, all that saves is a newline or two, which, as I think has been generally accepted, tends to hurt readability. The exact same argument could be used for list comprehensions themselves. They exist anyway, creating inconsistency in the language (being almost identical to for loops regarding syntax) Vitor Premios MTV 2008¡En exclusiva! Fotos, nominados, videos, y mucho más! Mira aquí http://mtvla.yahoo.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] if-syntax for regular for-loops
On Fri, Oct 3, 2008 at 12:33 PM, Andreas Nilsson [EMAIL PROTECTED] wrote: Thanks for the pointer! I don't buy the argument that newlines automagically improves readability though. You also get increased nesting suggesting something interesting is happening where it isn't and that hurts readability. And as Vitor said, all other constructions of the form 'for i in items' can have if-conditions attached to them, it's really not that far-fetched to assume that the loop behaves the same way. Consistency good, surprises bad. Yeah, I know what you mean, and I kind of liked the idea of adding the if statement to the for loop (for consistency, if nothing else), but it's been discussed before, and plenty of people have made the same argument. Probably not worth it. -- Cheers, Leif ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] if-syntax for regular for-loops
Vitor Bosshard wrote: On Fri, Oct 3, 2008 at 6:10 AM, Andreas Nilsson wrote: Essentially, all that saves is a newline or two, which, as I think has been generally accepted, tends to hurt readability. The exact same argument could be used for list comprehensions themselves. No, an LC saves more than newlines -- it saves the code to set up and append to a list. This is a substantial improvement when this code would otherwise swamp the essentials of what's being done. This doesn't apply to a plain for-loop that's not building a list. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] if-syntax for regular for-loops
Greg Ewing wrote: Vitor Bosshard wrote: The exact same argument could be used for list comprehensions themselves. No, an LC saves more than newlines -- it saves the code to set up and append to a list. This is a substantial improvement when this code would otherwise swamp the essentials of what's being done. This doesn't apply to a plain for-loop that's not building a list. Not only do LCs make it obvious to the reader that all this loop does is build a list, but the speed increases from doing the iteration in native code rather than pure Python are also non-trivial - every pass through the main eval loop that can be safely avoided leads to a fairly substantial time saving. Generally speaking, syntactic sugar (or new builtins) need to take a construct in idiomatic Python that is fairly obvious to an experienced Python user and make it obvious to even new users, or else take an idiom that is easy to get wrong when writing (or miss when reading) and make it trivial to use correctly. Providing significant performance improvements (usually in the form of reduced memory usage or increased speed) also counts heavily in favour of new constructs. I strongly suggest browsing through past PEPs (both accepted and rejected ones) before proposing syntax changes, but here are some examples of syntactic sugar proposals that were accepted. List/set/dict comprehensions (and the reduction builtins any(), all(), min(), max(), sum()) target = [op(x) for x in source] instead of: target = [] for x in source: target.append(op(x)) The transformation (op(x)) is far more prominent in the comprehension version, as is the fact that all the loop does is produce a new list. I include the various reduction builtins here, since they serve exactly the same purpose of taking an idiomatic looping construct and turning it into a single expression. Generator expressions = total = sum(x*x for x in source) instead of: def _g(seq): for x in source: yield x*x total = sum(_g(x)) or: total = sum([x*x for x in source]) Here, the GE version has obvious readability gains over the generator function version (as with comprehensions, it brings the operation being applied to each element front and centre instead of burying it in the middle of the code, as well as allowing reduction operations like sum() to retain their prominence), but doesn't actually improve readability significantly over the second LC-based version. The gain over the latter, of course, is that the GE based version needs a lot less *memory* than the LC version, and, as it consumes the source data incrementally, can work on source iterators of arbitrary (even infinite) length, and can also cope with source iterators with large time gaps between items (e.g. reading from a socket) as each item will be returned as it becomes available. With statements === with lock: # perform synchronised operations instead of: lock.aqcuire() try: # perform synchronised operations finally: lock.release() This change was a gain for both readability and writability - there were plenty of ways to get this kind of code wrong (e.g. leave out the try-finally altogether, acquire the resource inside the try block instead of before it, call the wrong method or spell the variable name wrong when attempting to release the resource in the finally block), and it wasn't easy to audit because the lock acquisition and release could be separated by an arbitrary number of lines of code. By combining all of that into a single line of code at the beginning of the block, the with statement eliminated a lot of those issues, making the code much easier to write correctly in the first place, and also easier to audit for correctness later (just make sure the code is using the correct context manager for the task at hand). Function decorators === @classmethod def f(cls): # Method body instead of: def f(cls): # Method body f = classmethod(f) Easier to write (function name only written once instead of three times), and easier to read (decorator names up top with the function signature instead of buried after the function body). Some folks still dislike the use of the @ symbol, but compared to the drawbacks of the old approach, the dedicated function decorator syntax is a huge improvement. Conditional expressions === x = A if C else B instead of: x = C and A or B The addition of conditional expressions arguably wasn't a particularly big win for readability, but it *was* a big win for correctness. The and/or based workaround for lack of a true conditional expression was not only hard to read if you weren't already familiar with the construct, but using it was also a potential buggy if A could ever be False while C was True (in such case, B would be returned from the expression instead of A). Except clause = except
