[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
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (09/26/08 - 10/03/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2074 open (+39) / 13779 closed (+16) / 15853 total (+55) Open issues with patches: 678 Average duration of open issues: 712 days. Median duration of open issues: 1835 days. Open Issues Breakdown open 2058 (+38) pending16 ( +1) Issues Created Or Reopened (56) ___ pprint._safe_repr is not general enough in one instance 09/26/08 http://bugs.python.org/issue3976created erickt Check PyInt_AsSsize_t/PyLong_AsSsize_t error 09/26/08 CLOSED http://bugs.python.org/issue3977created haypo patch ZipFileExt.read() can be incredibly slow 09/26/08 http://bugs.python.org/issue3978created lightstruk patch Doctest failing when it should pass 09/26/08 CLOSED http://bugs.python.org/issue3979created pupeno win32file.GetCommState incorrect handling of DCB 09/26/08 CLOSED http://bugs.python.org/issue3980created jiaailun Python 3, IDLE does not start09/27/08 CLOSED http://bugs.python.org/issue3981created dah support .format for bytes09/27/08 http://bugs.python.org/issue3982created benjamin.peterson Typos in Documentation 09/28/08 CLOSED http://bugs.python.org/issue3983created Bk python interpreter import dependency with disutils/util 09/28/08 http://bugs.python.org/issue3984created tarek patch removed string module from distutils [patch] 09/28/08 http://bugs.python.org/issue3985created tarek patch removed string and type usage from distutils.cmd [patch] 09/28/08 http://bugs.python.org/issue3986created tarek patch removed types from distutils.core [patch]09/28/08 http://bugs.python.org/issue3987created tarek patch Byte warning mode and b'' != '' 09/28/08 http://bugs.python.org/issue3988created christian.heimes patch Tools\Scripts\2to3.py broken under 3.0 rc1 Windows 09/28/08 CLOSED http://bugs.python.org/issue3989created arnaud.faucher The Linux2 platform definition is incorrect for alpha, hppa, mip 09/28/08 http://bugs.python.org/issue3990created ths patch urllib.request.urlopen does not handle non-ASCII characters 09/28/08 http://bugs.python.org/issue3991created a.badger removed custom log from distutils09/28/08 http://bugs.python.org/issue3992created tarek patch Convert documentation to python 3. 09/29/08 CLOSED http://bugs.python.org/issue3993created LambertDW import fixer misses some symbols 09/29/08 http://bugs.python.org/issue3994created mhammond iso-xxx/cp1252 inconsistencies in Python 2.* n
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
[Python-Dev] for __future__ import planning
So now that we've released 2.6 and are working hard on shepherding 3.0 out the door, it's time to worry about the next set of releases. :) I propose that we dramatically shorten our release cycle for 2.7/3.1 to roughly a year and put a strong focus stabilizing all the new goodies we included in the last release(s). In the 3.x branch, we should continue to solidify the new code and features that were introduced. One 2.7's main objectives should be binding 3.x and 2.x ever closer. -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ 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] for __future__ import planning
Benjamin Peterson wrote: I propose that we dramatically shorten our release cycle for 2.7/3.1 to roughly a year and put a strong focus stabilizing all the new goodies we included in the last release(s). In the 3.x branch, we should continue to solidify the new code and features that were introduced. One 2.7's main objectives should be binding 3.x and 2.x ever closer. Hey! That was my idea! I told you the very same idea on IRC a week ago. Shame on you! :) I'm +1 on the proposal. Let's focus on stability and performance for the next release. But before we start planning the next release we need to find a way to sync the development. Soon we have to apply fixes to up to four (again FOUR) branches: 2.6, 2.7, 3.0 and 3.1. We don't have to merge as many code as we did during the py3k phase. But it's still lots of work and we need all the (technical) help we can get. Christian ___ 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] python-checkins seems broken
Hello, I consult very regularly (100x a day) the python-checkins and python-300-checkins mailing list archives: http://mail.python.org/pipermail/python-checkins/2008-October/date.html#end http://mail.python.org/pipermail/python-3000-checkins/2008-October/date.html#end But they did not receive the svn checkins since Friday morning (CEST timezone). They do display the buildbot failures however. I miss these messages, they are for me the best way to keep in sync with the developments. (I think I have read all the commit diffs for three years at least) They are specially important these days, where many people can work on the same files. Do other subscribed people receive these commit messages? Is there a problem with the mailer, or some SVN trigger? -- Amaury Forgeot d'Arc ___ 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
[Python-Dev] Suspect intermittent failure in buildbots
I've noticed an error that comes up from time to time in python 3.0 buildbots.
The error is always similar to this one:
Traceback (most recent call last):
File
"E:\cygwin\home\db3l\buildarea\3.0.bolen-windows\build\lib\test\test_io.py",
line 900, in testBasicIO
self.assertEquals(f.write("abc"), 3)
File "E:\cygwin\home\db3l\buildarea\3.0.bolen-windows\build\lib\io.py",
line 1486, in write
b = encoder.encode(s)
File
"E:\cygwin\home\db3l\buildarea\3.0.bolen-windows\build\lib\encodings\ascii.py",
line 22, in encode
return codecs.ascii_encode(input, self.errors)[0]
AttributeError: 'NoneType' object has no attribute 'ascii_encode'
The most recent is here:
http://www.python.org/dev/buildbot/3.0/AMD64%20W2k8%203.0/builds/843/step-test/0
but this already happened on various buildbots:
http://www.google.fr/search?q=%27NoneType%27+object+has+no+attribute+encode+site:mail.python.org/pipermail/python-checkins&filter=0
"x86 XP-4 3.0", "amd64 gentoo 3.0", "AMD64 W2k8 3.0", "x86 W2k8 3.0",
"g4 osx.4 3.0", "OS X x86 3.0"
"x86 XP-3 trunk"
yes, even on trunk!
Every time, a "codecs" global module variable has been reset to None,
either in a codec module (encoding/ascii.py, encoding/mac_roman.py) or
in test_io.py.
Every time, io.py is not far (which may be normal, it must have the
larger usage of encodings written in a .py)
I know that modules globals are reset to None on interpreter shutdown,
but it does not seem to be the case here: the unit test fail, and
fails again when run in verbose mode at the end.
I checked that the "codecs" name is a module global: the disassembler
shows a LOAD_GLOBAL opcode followed by LOAD_ATTR:
0 LOAD_GLOBAL 0 (codecs)
3 LOAD_ATTR1 (ascii_decode)
...
I fail to imagine a reason, apart from a creeping memory error (in
dictionary lookup; chilling idea).
Thoughts?
--
Amaury Forgeot d'Arc
___
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] for __future__ import planning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 3, 2008, at 5:26 PM, Benjamin Peterson wrote: So now that we've released 2.6 and are working hard on shepherding 3.0 out the door, it's time to worry about the next set of releases. :) I propose that we dramatically shorten our release cycle for 2.7/3.1 to roughly a year and put a strong focus stabilizing all the new goodies we included in the last release(s). In the 3.x branch, we should continue to solidify the new code and features that were introduced. One 2.7's main objectives should be binding 3.x and 2.x ever closer. There are several things that I would like to see us concentrate on after the 3.0 release. I agree that 3.1 should be primarily a stabilizing release. I suspect that we will find a lot of things that need tweaking only after 3.0 final has been out there for a while. I think 2.7 should continue along the path of convergence toward 3.x. The vision some of us talked about at Pycon was that at some point down the line, maybe there's no difference between "python2.9 -3" and "python3.3 -2". I would really like to see us adopt a distributed version control system. I want our maintenance branches to always be in a releasable state. I want to be confident enough about the tree to be able to cut a point release at any time. I want to release a new point release from the maint branches once a month. Christian rightly points out that with four active trees, we're going to a pretty big challenge on our hands. How do other large open source projects handle similar situations? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSOajHXEjvBPtnXfVAQJ5qgP+I6k+kHMG2zPTvMIstM2wRmhtAPd7kKz9 S6bXllUBzpxQGMYfqR3Ze5/SVUMEV2HvINPDfg816sGOoxs0fMeori398rU97bkH tOFHOEi/KLKMdgGdjGWWnV+iPEGF6stPMX/6nGQDhM5NMzj81hBgF+7U+UNbS7iM dT2wk3vSZHQ= =q4kW -END PGP SIGNATURE- ___ 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] Suspect intermittent failure in buildbots
Module globals are also reset when the module *object* is
garbage-collected (e.g. it's removed from sys.modules and not
referenced elsewhere), but the module *dict* is still referenced. This
can happen if all uses of the module is of the form "from
import " where the is a class or function, and
at least one of the users survives the garbage-collected module.
I suspect that something is resetting part of sys.modules content. It
is a known problem (in some parts) that encodings modules cannot be
reset that way. I suspect that there is code in the regrtest.py
framework that does this (resetting part of sys.modules) in order to
restore a clean environment in some cases. Or perhaps it's one of the
tests that does this.
On Fri, Oct 3, 2008 at 3:56 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> I've noticed an error that comes up from time to time in python 3.0 buildbots.
> The error is always similar to this one:
>
> Traceback (most recent call last):
> File
> "E:\cygwin\home\db3l\buildarea\3.0.bolen-windows\build\lib\test\test_io.py",
> line 900, in testBasicIO
>self.assertEquals(f.write("abc"), 3)
> File "E:\cygwin\home\db3l\buildarea\3.0.bolen-windows\build\lib\io.py",
> line 1486, in write
>b = encoder.encode(s)
> File
> "E:\cygwin\home\db3l\buildarea\3.0.bolen-windows\build\lib\encodings\ascii.py",
> line 22, in encode
>return codecs.ascii_encode(input, self.errors)[0]
> AttributeError: 'NoneType' object has no attribute 'ascii_encode'
>
> The most recent is here:
> http://www.python.org/dev/buildbot/3.0/AMD64%20W2k8%203.0/builds/843/step-test/0
>
> but this already happened on various buildbots:
> http://www.google.fr/search?q=%27NoneType%27+object+has+no+attribute+encode+site:mail.python.org/pipermail/python-checkins&filter=0
>
> "x86 XP-4 3.0", "amd64 gentoo 3.0", "AMD64 W2k8 3.0", "x86 W2k8 3.0",
> "g4 osx.4 3.0", "OS X x86 3.0"
> "x86 XP-3 trunk"
>
> yes, even on trunk!
> Every time, a "codecs" global module variable has been reset to None,
> either in a codec module (encoding/ascii.py, encoding/mac_roman.py) or
> in test_io.py.
> Every time, io.py is not far (which may be normal, it must have the
> larger usage of encodings written in a .py)
>
> I know that modules globals are reset to None on interpreter shutdown,
> but it does not seem to be the case here: the unit test fail, and
> fails again when run in verbose mode at the end.
>
> I checked that the "codecs" name is a module global: the disassembler
> shows a LOAD_GLOBAL opcode followed by LOAD_ATTR:
> 0 LOAD_GLOBAL 0 (codecs)
> 3 LOAD_ATTR1 (ascii_decode)
> ...
>
> I fail to imagine a reason, apart from a creeping memory error (in
> dictionary lookup; chilling idea).
> Thoughts?
>
> --
> Amaury Forgeot d'Arc
> ___
> 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/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] for __future__ import planning
On Fri, Oct 3, 2008 at 3:56 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Oct 3, 2008, at 5:26 PM, Benjamin Peterson wrote: > >> So now that we've released 2.6 and are working hard on shepherding 3.0 >> out the door, it's time to worry about the next set of releases. :) >> >> I propose that we dramatically shorten our release cycle for 2.7/3.1 >> to roughly a year and put a strong focus stabilizing all the new >> goodies we included in the last release(s). In the 3.x branch, we >> should continue to solidify the new code and features that were >> introduced. One 2.7's main objectives should be binding 3.x and 2.x >> ever closer. > > There are several things that I would like to see us concentrate on after > the 3.0 release. I agree that 3.1 should be primarily a stabilizing > release. I suspect that we will find a lot of things that need tweaking > only after 3.0 final has been out there for a while. > > I think 2.7 should continue along the path of convergence toward 3.x. The > vision some of us talked about at Pycon was that at some point down the > line, maybe there's no difference between "python2.9 -3" and "python3.3 -2". > +1 from me. I think 2.7/3.1 should be used as a chance to get our testing framework straightened out and have those releases be extremely rock-solid (especially 2.7 as it might be the last in the 2.x series). Oh, and getting import rewritten in pure Python for 3.1 of course. =) > I would really like to see us adopt a distributed version control system. > Along the lines of making 2.7/3.1 very stable releases, I would love to use the time to clean up our workflow. To me that means cleaning up the workflow on the issue tracker and getting on to a DVCS to make it as easy as possible for people to contribute patches and for us to do reviews. > I want our maintenance branches to always be in a releasable state. I want > to be confident enough about the tree to be able to cut a point release at > any time. I want to release a new point release from the maint branches > once a month. > Wow! I guess release.py is going to get really automated then. =) That or you are going to manage to con more of us to help out (and even cut the release ourselves). > Christian rightly points out that with four active trees, we're going to a > pretty big challenge on our hands. How do other large open source projects > handle similar situations? > Beats me. Are that many projects crazy enough to have that many active branches? -Brett ___ 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] for __future__ import planning
Brett Cannon wrote: Christian rightly points out that with four active trees, we're going to a pretty big challenge on our hands. How do other large open source projects handle similar situations? Beats me. Are that many projects crazy enough to have that many active branches? Is it really that bad? Once 3.0 is released, it's not like we're going to be patching 2.6 and 3.0 all that much. All the "real development" (by which I mean most of the checkins) will be on 2.7 and 3.1. The biggest challenge I see is the buildbots. 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
Re: [Python-Dev] [Python-checkins] python-checkins seems broken
On Sat, Oct 04, 2008 at 12:14:43AM +0200, Amaury Forgeot d'Arc wrote: > Do other subscribed people receive these commit messages? > Is there a problem with the mailer, or some SVN trigger? It looks like mail from dinsdale.python.org to mail.python.org isn't working due to a DNS issue: rcpt to: [EMAIL PROTECTED] 550 5.7.1 Client host rejected: cannot find your reverse hostname, [82.94.164.164] data I know there's a transition to new IP addresses going on for the python.org machines, but Thomas or Sean probably needs to do something with the DNS for this. --amk ___ 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] for __future__ import planning
Brett Cannon python.org> writes: > > Beats me. Are that many projects crazy enough to have that many active > branches? Any project using branch-driven development has many active branches. Our specificity is that we must maintain in sync two branches (trunk, py3k) which have widely diverged from each other. Thus, merges are often non-trivial. Regards Antoine. ___ 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
==
Re: [Python-Dev] if-syntax for regular for-loops
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. -- Steven ___ 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] Real segmentation fault handler
On Thu, Oct 2, 2008 at 10:54 AM, Thomas Heller <[EMAIL PROTECTED]> wrote: > Victor Stinner schrieb: >> Hi, >> >> I would like to be able to catch SIGSEGV in my Python code! So I started to >> hack Python trunk to support this feature. The idea is to use a signal >> handler which call longjmp(), and add setjmp() at Py_EvalFrameEx() enter. > > On windows, ctypes catches fatal errors (exception violations) in > foreign function calls, thanks to windows structured exception handling. > > On other platforms, there is the WAD module by David Beazley which > may do something similar: > > http://www.dabeaz.com/papers/Python2001/python.html > > I do not know whether the code itself is still available or not. It appears to be here: http://web.archive.org/web/20030113032725/systems.cs.uchicago.edu/wad/ It may need a bit of attention to get it to work today, I haven't tried. -gps ___ 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
