Re: [Python-Dev] versioned .so files for Python 3.2
On 23 Jul, 2010, at 23:19, Barry Warsaw wrote: On Jul 23, 2010, at 12:54 PM, Barry Warsaw wrote: On Jul 23, 2010, at 11:48 AM, Ronald Oussoren wrote: I'd be open to adding the platform name to the tag, but I'd probably define it as part of the implementation field, e.g. foo.cpython-linux2-32m.so. Or maybe start with the platform name, e.g. foo.linux2-cpython-32m. This isn't a strong preference though. I don't have a strong opionion, but placing the platform name at the start is probably better to be consistent with sysconfig.get_platform(). What about the architecture (i386, amd64)? With every increase in length I start to get more concerned. We could encode the platform and architecture, but that gets into cryptic territory. OTOH, would you really co-install i386 and amd64 shared libraries on the same machine? (hello NFS ;). Thinking about this some more, I'd rather *not* include the platform or architecture in the tag by default. They aren't really necessary to support the instigating use case and will probably be fairly uncommon. I'd be okay including a configure option to allow you to add whatever you want after the implementation, version, and flags. E.g. something like: ./configure --with-abi-tag-extension=linux2 would lead to foo.cpython-32m-linux2.so, so not the nicer names we'd prefer but probably good enough for your purposes. Would that work for you? That would certainly work. That said, I'm also fine with not adding the platform information or configure argument at all. My usecase is fairly exotic and I do have a feasible workaround. Ronald smime.p7s Description: S/MIME cryptographic 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] Include datetime.py in stdlib or not?
On Sat, Jul 24, 2010 at 3:44 AM, Benjamin Peterson benja...@python.org wrote: 2010/7/23 Alexander Belopolsky alexander.belopol...@gmail.com: Thanks, everyone who followed up here and on the tracker. I am readying the patch for check in, but as I look back through the messages, I don't really see anyone's answer to the question in the subject: * Include datetime.py in stdlib or not? I hope this means an implied yes, include. Since committing the patch will case a bit of file movement, I would like to pre-announce the commit in case my timing is not right. It's a bit hard to get a strong affirmative because it's not really anyone's decision. I would say, though, given that there haven't been any strong -1s, you can go ahead. Yep, that sounds right to me too. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] [isssue 2001] Pydoc enhancement patch questions
On Sat, Jul 24, 2010 at 10:05 AM, Ron Adam r...@ronadam.com wrote: I am not sure I like the fact that the browser is started automatically. Please bring this up on python-dev. This may be an opportunity to rethink pydoc command line switches. For example, -p and -g are currently exclusive, but it would make sense for -g to start server on the port specified by -p. So are any thoughts on starting the web browser automatically, and on how the -g and -p command line switches work? My suggestion: - leave the -g option alone (including the tk gui), but make sure other options still work when tk is unavailable - add a -b option to start the server and open the webbrowser automatically - allow -p to be combined with either -b or -g to specify where the server should run (or is running) For the -b option, if the server is already running (and hence the port is in use), catch the exception, print a message and start the webbrowser anyway. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Thoughts fresh after EuroPython
While the EuroPython sprints are still going on, I am back home, and after a somewhat restful night of sleep, I have some thoughts I'd like to share before I get distracted. Note, I am jumping wildly between topics. - Commit privileges: Maybe we've been too careful with only giving commit privileges to to experienced and trusted new developers. I spoke to Ezio Melotti and from his experience with getting commit privileges, it seems to be a case of the lion is much more afraid of you than you are afraid of the lion. I.e. having got privileges he was very concerned about doing something wrong, worried about the complexity of SVN, and so on. Since we've got lots of people watching the commit stream, I think that there really shouldn't need to be a worry at all about a new committer doing something malicious, and there shouldn't be much worry about honest beginners' mistakes either -- the main worry remains that new committers don't use their privileges enough. So, my recommendation (which surely is a turn-around of my *own* attitude in the past) is to give out more commit privileges sooner. - Concurrency and parallelism: Russel Winder and Sarah Mount pushed the idea of CSP (http://en.wikipedia.org/wiki/Communicating_sequential_processes) in several talks at the conference. They (at least Russell) emphasized the difference between concurrency (interleaved event streams) and parallelism (using many processors to speed things up). Their prediction is that as machines with many processing cores become more prevalent, the relevant architecture will change from cores sharing a single coherent memory (the model on which threads are based) to one where each core has a limited amount of private memory, and communication is done via message passing between the cores. This gives them (and me :-) hope that the GIL won't be a problem as long as we adopt a parallel processing model. Two competing models are the Actor model, which is based on asynchronous communication, and CSP, which is synchronous (when a writer writes to a channel, it blocks until a reader reads that value -- a rendezvous). At least Sarah suggested that both models are important. She also mentioned that a merger is under consideration between the two major CSP-for-Python packages, Py-CSP and Python-CSP. I also believe that the merger will be based on the stdlib multiprocessing package, but I'm not sure. I do expect that we may get some suggestions from that corner to make some minor changes to details of multiprocessing (and perhaps threading), and I think we should be open to those (I expect these will be good suggestions for small tweaks, not major overhauls). - After seeing Raymond's talk about monocle (search for it on PyPI) I am getting excited again about PEP 380 (yield from, return values from generators). Having read the PEP on the plane back home I didn't see anything wrong with it, so it could just be accepted in its current form. Implementation will still have to wait for Python 3.3 because of the moratorium. (Although I wouldn't mind making an exception to get it into 3.2.) - This made me think of how the PEP process should evolve so as to not require my personal approval for every PEP. I think the model for future PEPs should be the one we used for PEP 3148 (futures, which was just approved by Jesse): the discussion is led and moderated by one designated PEP handler (a different one for each PEP) and the PEP handler, after reviewing the discussion, decides when the PEP is approved. A PEP handler should be selected for each PEP as soon as possible; without a PEP handler, discussing a PEP is not all that useful. The PEP handler should be someone respected by the community with an interest in the subject of the PEP but at an arms' length (at least) from the PEP author. The PEP handler will have to moderate feedback, separating useful comments from (too much) bikeshedding, repetitious lines of questioning, and other forms of obstruction. The PEP handler should also set and try to maintain a schedule for the discussion. Note that a schedule should not be used to break a tie -- it should be used to stop bikeshedding and repeat discussions, while giving all interested parties a chance to comment. (I should say that this is probably similar to the role of an IETF working group director with respect to RFCs.) - Specifically, if Raymond is interested, I wouldn't mind seeing him as the PEP handler for PEP 380. For some of Martin von Löwis's PEPs (382, 384) I think a PEP handler is sorely lacking -- from the language summit it appeared as if nobody besides Martin understands these PEPs. - A lot of things seem to be happening to make PyPI better. Is this being summarized somewhere? Based on some questions I received during my keynote QA (http://bit.ly/bdflqa) I think not enough people are aware of what we are already doing in this area. Frankly, I'm not sure I do, either: I think I've heard of a GSOC student and of plans to take over
Re: [Python-Dev] [isssue 2001] Pydoc enhancement patch questions
On Sat, Jul 24, 2010 at 6:37 AM, Nick Coghlan ncogh...@gmail.com wrote: .. For the -b option, if the server is already running (and hence the port is in use), catch the exception, print a message and start the webbrowser anyway. I was going to make a similar suggestion, but then realized that there it may not be easy or desirable for pydoc to figure out whether the service running on the used port is in fact pydoc. Any query that pydoc would send may be disruptive depending on what program is listening on the port. It may also get easily confused by a pydoc service from a different version of python. It may be better to search for an unused port in the error case and pass it to the browser. ___ 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] Does trace modules have a unit test?
On Thu, Jul 22, 2010 at 6:33 PM, Nick Coghlan ncogh...@gmail.com wrote: On Fri, Jul 23, 2010 at 3:30 AM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: I see three solutions: 1. Minimal: do not rename test_trace in 2.7 and add trace module tests to the existing file. Whether to revert test_trace to test_line_tracing renaming in 3.2 can be decided after we have 2.7 tests written. 2. Rename test_trace in 2.7/3.1 and test_line_tracing in 3.2 to test_sys_settrace. 3. Rename test_trace in 2.7/3.1 to test_line_tracing. My preference in #2, but I can live with #1 (assuming Eli is the one who will write the tests:-). I'd say just fix it and go with #2 (just update the comment in test_sys as well!) I have looked further into setprofile tests for inspiration and discovered that it is covered in test_profilehooks. Note that sys.settrace and sys.setprofile are very similar. They take a function with the same signature and report events in the same format. The only difference is in the kind of events that get reported. I made an experiment replacing [sg]etprofile with [sg]ettrace in test-profilehooks and all tests worked reporting failures in comparing outputs. I would like to use this opportunity to merge settrace and setprofile tests. Here is the proposal: Step 1: Rename test_trace to test_sys_settrace and test_profilehooks to test_sys_setprofile. Step 2: Create tracetester helper file with abstract test cases made from the union of test_sys_settrace and test_sys_setprofile test cases and replace the concrete test cases in test_sys_set* with subclasses that define setmethod, getmethod and expected_output. An alternative proposal is to put all tests for both trace and profile into a single test_sys_tracing file. What do you think? (Another option is to leave test_profilehooks and use rename test_trace to test_tracehooks in the step 1 above.) ___ 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 profiler and other tools
On Fri, Jul 23, 2010 at 4:20 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: There must be a good reason why traditional software development tools such as debugger, profiler and coverage are mostly neglected in python. Most such tools are probably better developed outside the standard library. There are many reasons for that, but I would guess that it mostly has to do with very different development cycles for tools. Tool development usually goes in quick bursts (driven by urgent needs and perhaps improving tool developer skills) unrelated to the stdlib release cycle (and releasing the stdlib separately won't make much of a difference). Also tools often have rough edges, and the stdlib (except for the stuff added before 1995 or so :-) has a high perfectionism standard. -- --Guido van Rossum (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] [isssue 2001] Pydoc enhancement patch questions
On 07/24/2010 10:16 AM, Alexander Belopolsky wrote: On Sat, Jul 24, 2010 at 6:37 AM, Nick Coghlanncogh...@gmail.com wrote: .. For the -b option, if the server is already running (and hence the port is in use), catch the exception, print a message and start the webbrowser anyway. I was going to make a similar suggestion, but then realized that there it may not be easy or desirable for pydoc to figure out whether the service running on the used port is in fact pydoc. Any query that pydoc would send may be disruptive depending on what program is listening on the port. It may also get easily confused by a pydoc service from a different version of python. It may be better to search for an unused port in the error case and pass it to the browser. I'll try to look into improving how pydoc handles these types of errors. In the mean time if others have experience with browser apps and these kind of situations I'd like to hear about it. Does this have to be in this particular patch? I don't see any problem adding better error recovery later. This isn't something new, both the -p and -g modes have this issue. Ron ___ 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] [isssue 2001] Pydoc enhancement patch questions
On 07/24/2010 05:37 AM, Nick Coghlan wrote: On Sat, Jul 24, 2010 at 10:05 AM, Ron Adamr...@ronadam.com wrote: I am not sure I like the fact that the browser is started automatically. Please bring this up on python-dev. This may be an opportunity to rethink pydoc command line switches. For example, -p and -g are currently exclusive, but it would make sense for -g to start server on the port specified by -p. So are any thoughts on starting the web browser automatically, and on how the -g and -p command line switches work? My suggestion: - leave the -g option alone (including the tk gui), but make sure other options still work when tk is unavailable I was hoping it would be ok to drop the tk gui in pydoc. Keeping it requires rewriting the tk gui interface to use the new server because the server code and the gui code are not cleanly separate. I can do this if it's really wanted. (Nothing against tKinter, I use it for my own gui apps.) Or are you suggesting having pydoc work either with the tk gui behavior without any of the new features, or with the new features without the tk gui, depending on how it's started? I'd prefer not to do this because it would duplicate the server code and possibly other functions to produce some of the web page outputs. That would make pydoc.py both larger and harder to maintain. It may also make enhancing pydoc further more difficult as well. The current patch without the tk gui definitely makes things easier to maintain IMHO. Are there any compelling reasons for keeping the tk gui? BTW, the synopsis search feature is currently broken in python 3.2. See issue: http://bugs.python.org/issue9319 Once that is fixed, you can then play around with the search features with and without this patch and see how they compare. - add a -b option to start the server and open the webbrowser automatically - allow -p to be combined with either -b or -g to specify where the server should run (or is running) I also agree the -p option should work with the -b and/or -g. Using -b instead of reusing -g for browser only, makes sense to me. Depending on weather or not the tk gui is kept, the -g option can either open the tk gui or give a message to use the -b option instead. Ron ___ 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] Thoughts fresh after EuroPython
On 7/24/2010 10:08 AM, Guido van Rossum wrote: - Commit privileges: Maybe we've been too careful with only giving commit privileges to to experienced and trusted new developers. I spoke to Ezio Melotti and from his experience with getting commit privileges, it seems to be a case of the lion is much more afraid of you than you are afraid of the lion. I.e. having got privileges he was very concerned about doing something wrong, worried about the complexity of SVN, and so on. Since we've got lots of people watching the commit stream, I think that there really shouldn't need to be a worry at all about a new committer doing something malicious, and there shouldn't be much worry about honest beginners' mistakes either -- the main worry remains that new committers don't use their privileges enough. My initial inclination is to start with 1 or 2 line patches that I am 99.99% certain are correct. But it has occurred to me that it might be better for Python if I were willing to take a greater than 1/1 chance of making a mistake. But how much greater? What error rate do *you* consider acceptable? - Concurrency and parallelism: Russel Winder and Sarah Mount pushed the idea of CSP (http://en.wikipedia.org/wiki/Communicating_sequential_processes) in several talks at the conference. They (at least Russell) emphasized the difference between concurrency (interleaved event streams) This speeds perceived and maybe actual responsiveness to user input. and parallelism (using many processors to speed things up). This reduces total time. Their prediction is that as machines with many processing cores become more prevalent, the relevant architecture will change from cores sharing a single coherent memory (the model on which threads are based) to one where each core has a limited amount of private memory, and communication is done via message passing between the cores. I believe this is a prediction that current prototypes, if not current products, will be both technically and commercially successful. My impression is enough better than 50/50 to be worth taking into account. It does not seem like much of a leap from private caches that write through to common memory to private memory that is not written through, especially on 64 bit machines with memory space to spare. - After seeing Raymond's talk about monocle (search for it on PyPI) I am getting excited again about PEP 380 (yield from, return values from generators). Having read the PEP on the plane back home I didn't see anything wrong with it, so it could just be accepted in its current form. Implementation will still have to wait for Python 3.3 because of the moratorium. (Although I wouldn't mind making an exception to get it into 3.2.) While initially -0, I now think the moratorium was a good idea. It seems to be successful at letting and even encouraging people to target 3.2 by working with 3.1. A big exception like this would probably annoy lots of people who had *their* 'equally good' ideas put off and might annoy alternative implementors counting on core 3.2 being as it. So the only exception I would make would one that had a really good technical reason, like making Python work better on multi-core processors - This made me think of how the PEP process should evolve so as to not require my personal approval for every PEP. I think the model for future PEPs should be the one we used for PEP 3148 (futures, which was just approved by Jesse): +1 -- Terry Jan Reedy ___ 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] [isssue 2001] Pydoc enhancement patch questions
On Sat, Jul 24, 2010 at 3:34 PM, Ron Adam r...@ronadam.com wrote: On 07/24/2010 05:37 AM, Nick Coghlan wrote: .. - leave the -g option alone (including the tk gui), but make sure other options still work when tk is unavailable I was hoping it would be ok to drop the tk gui in pydoc. Keeping it requires rewriting the tk gui interface to use the new server because the server code and the gui code are not cleanly separate. I can do this if it's really wanted. (Nothing against tKinter, I use it for my own gui apps.) FWIW, I am +1 on dropping tkinter interface. Tkinter window looks foreign next to browser and server-side GUI that opens a new client window with each search topic does not strike me as most usable design. Furthermore, I just tried to use it on my OSX laptop and it crashed after I searched for pydoc and clicked on the first entry. (Another issue is that search window pops under the terminal window.) I think Tkinter interface to pydoc may make sense in IDLE, but not in the main pydoc GUI. If the equivalent functionality is available in the browser (preferably in the style familiar to docs.python.org users, I don't see why we need to keep old GUI and hide new behind a new option. ___ 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] versioned .so files for Python 3.2
Barry Warsaw ba...@python.org writes: On Jul 23, 2010, at 01:46 PM, sch...@gmail.com wrote: Doesn't anybody else think this is lost work for very little gain? My /usr/lib/python2.6/site-packages directory consumes 200MB on disk. I couldn't care less if my /usr/lib/python2.5/site-packages consumed the same amount of disk space... Right, you probably don't care now that your extension modules live in foo.so so it probably won't make much difference if they were named foo-blahblah.so, as long as they import. :) Most of the time it won't make much difference, right. But I can assure you, that it will bite some people and there is some code to be adapted. If you use Debian or Ubuntu though, it'll be a win for you by allow us to make Python support much more robust. I'd much prefer to have cleanly separated environments by having separate directories for my python modules. Sharing the source code and complicating things will not lead to increased robustness. - Ralf ___ 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] [isssue 2001] Pydoc enhancement patch questions
On 07/24/2010 04:29 PM, Alexander Belopolsky wrote: On Sat, Jul 24, 2010 at 3:34 PM, Ron Adamr...@ronadam.com wrote: On 07/24/2010 05:37 AM, Nick Coghlan wrote: .. - leave the -g option alone (including the tk gui), but make sure other options still work when tk is unavailable I was hoping it would be ok to drop the tk gui in pydoc. Keeping it requires rewriting the tk gui interface to use the new server because the server code and the gui code are not cleanly separate. I can do this if it's really wanted. (Nothing against tKinter, I use it for my own gui apps.) FWIW, I am +1 on dropping tkinter interface. Tkinter window looks foreign next to browser and server-side GUI that opens a new client window with each search topic does not strike me as most usable design. Furthermore, I just tried to use it on my OSX laptop and it crashed after I searched for pydoc and clicked on the first entry. (Another issue is that search window pops under the terminal window.) I think Tkinter interface to pydoc may make sense in IDLE, but not in the main pydoc GUI. If the equivalent functionality is available in the browser (preferably in the style familiar to docs.python.org users, I don't see why we need to keep old GUI and hide new behind a new option. The information returned by the new find field in the browser navigation bar is the same as that returned to the tk gui window. Each item is a link followed by the synopsis. The style is similar to the other pydoc pages with the navigation bar at the top that makes it easy to do other searches or return to an index page. There should be a link on each pydoc module page to the online docs. I have to look at how pydoc decides to include that or not. The patched version does not include it. I don't think I did anything to remove that, but will check and add it back if I did. Both python 2.6 and 3.1 versions of pydoc currently adds a Module Docs link to module pages to the 2.7 online docs. (A bug?, I'm using Ubuntu) Having the search results in the browser instead of the tk gui allows you to print the results and you can also right click on the links and choose open in a new tab or window. (Firefox Browser) Ron ___ 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] Thoughts fresh after EuroPython
On Sat, Jul 24, 2010 at 2:05 PM, Terry Reedy tjre...@udel.edu wrote: On 7/24/2010 10:08 AM, Guido van Rossum wrote: - Commit privileges: Maybe we've been too careful with only giving commit privileges to to experienced and trusted new developers. I spoke to Ezio Melotti and from his experience with getting commit privileges, it seems to be a case of the lion is much more afraid of you than you are afraid of the lion. I.e. having got privileges he was very concerned about doing something wrong, worried about the complexity of SVN, and so on. Since we've got lots of people watching the commit stream, I think that there really shouldn't need to be a worry at all about a new committer doing something malicious, and there shouldn't be much worry about honest beginners' mistakes either -- the main worry remains that new committers don't use their privileges enough. My initial inclination is to start with 1 or 2 line patches that I am 99.99% certain are correct. But it has occurred to me that it might be better for Python if I were willing to take a greater than 1/1 chance of making a mistake. But how much greater? What error rate do *you* consider acceptable? Mistakes get made all the time, mostly by experienced committers. When caught quickly they are easy to roll back (that's arguably much of the point of source control :-). New committers can also start with things like docs where there are fewer risks, and more little things that can easily get fixed but aren't for lack of attention. This will help them figure out the source control tools and workflow, which will build up their (and our) confidence, making future success even more likely. -- --Guido van Rossum (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] http://bugs.python.org/issue231540
On 23/07/2010 23:26, Mark Lawrence wrote: Is there any money to pay for the forthcoming 10th birthday party for this issue? Is the OP still alive? Kindest regards. Mark Lawrence. Hi all, I admit that when I sent this off last night, I felt rather better after for having let off a bit of steam. Whatever, but in future, could you all please be so kind as to take this with a supertanker's worth of salt, I don't really mean it. To repeat myself for those who are not aware, I have long term physical and mental health problems. Thinking about it, by definition there must be others using Python who are in the same league as myself. I do sympathise. I have to admit that this morning I was rather afraid of reading my email, I thought I was going to get a right slagging, and deservedly so. I have been absolutely staggered by the responses that I've received, some of them offline, but I don't think that matters at all. They're all along the lines of:- great job Mark, keep your chin up, keep plugging Thanks, I'd forgotten that one, I'll get it fixed And so on, and so forth. Nobody has been at all really negative. I think that this is a tremendous way of saying what a wonderful community Python is, long may it be that way. So at least when I rant, everyone to my knowledge sees it as a positive rant, if you can understand that. Perhaps those who frequent c.l.py will understand the negative rants, which fortunately come from a very small minority of people. How can I sum up what I think about Python, that's fairly easy. www.python.org is bookmarked as Home Sweet Home, can I say any more? Thank you all for your kindness, and please note that I've again been plugging away today and rather enjoying myself. Kindest regards. Mark Lawrence. p.s. I don't know much about baseball, but did have a rather wonderful chat at my nephew's wedding last September in Conneticut. Uncle George (who's claim to fame is allegedly providing the optics for a little bit of kit called the Hubble Space Telescope) spent 20 minutes with myself discussing baseball compared to cricket. He was baffled by the fact that 11 players can have so many fielding positions in cricket, but we got there in the end. More importantly, the aerodynamics of the two balls were of particular interest. How sad can you get? ___ 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] Thoughts fresh after EuroPython
On 7/24/2010 3:08 PM, Guido van Rossum wrote: While the EuroPython sprints are still going on, I am back home, and after a somewhat restful night of sleep, I have some thoughts I'd like to share before I get distracted. Note, I am jumping wildly between topics. - Commit privileges: Maybe we've been too careful with only giving commit privileges to to experienced and trusted new developers. I spoke to Ezio Melotti and from his experience with getting commit privileges, it seems to be a case of the lion is much more afraid of you than you are afraid of the lion. I.e. having got privileges he was very concerned about doing something wrong, worried about the complexity of SVN, and so on. Since we've got lots of people watching the commit stream, I think that there really shouldn't need to be a worry at all about a new committer doing something malicious, and there shouldn't be much worry about honest beginners' mistakes either -- the main worry remains that new committers don't use their privileges enough. So, my recommendation (which surely is a turn-around of my *own* attitude in the past) is to give out more commit privileges sooner. +1. I think this would have a very positive effect on the way that the Python development community id perceived from the outside. In reality it's probably mostly an acceptance of the fact that new protocols are appropriate with a rather larger development community. - Concurrency and parallelism: Russel Winder and Sarah Mount pushed the idea of CSP (http://en.wikipedia.org/wiki/Communicating_sequential_processes) in several talks at the conference. They (at least Russell) emphasized the difference between concurrency (interleaved event streams) and parallelism (using many processors to speed things up). Their prediction is that as machines with many processing cores become more prevalent, the relevant architecture will change from cores sharing a single coherent memory (the model on which threads are based) to one where each core has a limited amount of private memory, and communication is done via message passing between the cores. This gives them (and me :-) hope that the GIL won't be a problem as long as we adopt a parallel processing model. Two competing models are the Actor model, which is based on asynchronous communication, and CSP, which is synchronous (when a writer writes to a channel, it blocks until a reader reads that value -- a rendezvous). At least Sarah suggested that both models are important. She also mentioned that a merger is under consideration between the two major CSP-for-Python packages, Py-CSP and Python-CSP. I also believe that the merger will be based on the stdlib multiprocessing package, but I'm not sure. I do expect that we may get some suggestions from that corner to make some minor changes to details of multiprocessing (and perhaps threading), and I think we should be open to those (I expect these will be good suggestions for small tweaks, not major overhauls). - After seeing Raymond's talk about monocle (search for it on PyPI) I am getting excited again about PEP 380 (yield from, return values from generators). Having read the PEP on the plane back home I didn't see anything wrong with it, so it could just be accepted in its current form. Implementation will still have to wait for Python 3.3 because of the moratorium. (Although I wouldn't mind making an exception to get it into 3.2.) I can understand the temptation, but hope you can manage to resist it. The downside of allowing such exceptions is that people won't take these pronouncements seriously if they see that a sufficiently desirable goal is a reason for ignoring them. Everyone should be subject to the same rules. - This made me think of how the PEP process should evolve so as to not require my personal approval for every PEP. I think the model for future PEPs should be the one we used for PEP 3148 (futures, which was just approved by Jesse): the discussion is led and moderated by one designated PEP handler (a different one for each PEP) and the PEP handler, after reviewing the discussion, decides when the PEP is approved. A PEP handler should be selected for each PEP as soon as possible; without a PEP handler, discussing a PEP is not all that useful. The PEP handler should be someone respected by the community with an interest in the subject of the PEP but at an arms' length (at least) from the PEP author. The PEP handler will have to moderate feedback, separating useful comments from (too much) bikeshedding, repetitious lines of questioning, and other forms of obstruction. The PEP handler should also set and try to maintain a schedule for the discussion. Note that a schedule should not be used to break a tie -- it should be used to stop bikeshedding and repeat discussions, while giving all interested parties a chance to comment. (I should say that this is probably similar to the role of an IETF working group
Re: [Python-Dev] http://bugs.python.org/issue231540
Mark Lawrence breamore...@yahoo.co.uk writes: I admit that when I sent this off last night, I felt rather better after for having let off a bit of steam. […] Nobody has been at all really negative. I think that this is a tremendous way of saying what a wonderful community Python is, long may it be that way. So at least when I rant, everyone to my knowledge sees it as a positive rant, if you can understand that. […] I'm glad that this was a positive experience in the end for you, but I do wish it could have been done without the rant actually appearing here. In my experience, there will likely be many people who were affected negatively by the message containing that rant and simply didn't say so, but they will enjoy this community less as a result. What I find very helpful in these cases is to put all my vitriol into the rant, bask in it, and then *delete it unsent*. That way, I'm not spreading the bad emotion any further than my desk, and it truly is cathartic so I can sleep soundly. A win all around. How can I sum up what I think about Python, that's fairly easy. www.python.org is bookmarked as Home Sweet Home, can I say any more? Thank you all for your kindness, and please note that I've again been plugging away today and rather enjoying myself. Thanks again for your achievements in improving Python, and best wishes in dealing with whatever life deals you. -- \ “Here is a test to see if your mission on earth is finished. If | `\ you are alive, it isn't.” —Francis Bacon | _o__) | Ben Finney ___ 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] PEP 380 - return value question and prototype implementation (was Thoughts fresh after EuroPython)
At 07:08 AM 7/24/2010 -0700, Guido van Rossum wrote: - After seeing Raymond's talk about monocle (search for it on PyPI) I am getting excited again about PEP 380 (yield from, return values from generators). Having read the PEP on the plane back home I didn't see anything wrong with it, so it could just be accepted in its current form. I would like to reiterate (no pun intended) the suggestion of a special syntactic form for the return, such as yield return x, or return with x or something similar, to distinguish it from a normal generator return. I think that when people are getting used to the idea of generators, it's important for them to get the idea that the function's return value isn't really a value, it's an iterator object. Allowing a return value, but then having that value silently disappear, seems like it would delay that learning, so, a special form might help to make it clear that the generator in question is intended for use with a corresponding yield from, and help avoid confusion on this. (I could of course be wrong, and would defer to anyone who sees a better way to explain/teach around this issue. In any event, I'm +1 on the PEP otherwise.) By the way, the PEP's optimized implementation could probably be done just by making generator functions containing yield-from statements return an object of a different type than the standard geniter. Here's a Python implementation sketch, using a helper class and a decorator -- translation to a C version is likely straightforward, as it'll basically be this plus a light sprinkling of syntactic sugar. So, in the pure-Python prototype (without syntax sugaring), usage would look like this: @From.container def some_generator(...): ... yield From(other_generator(...)) # equivalent to 'yield from' ... def other_generator(...): ... raise StopIteration(value) # equivalent to 'return value' We mark some_generator() with @From.container to indicate that it uses 'yield from' internally (which would happen automatically in the C/syntax sugar version). We don't mark other_generator(), though, because it doesn't contain a 'yield from'. Now, the implementation code (a slightly altered/watered-down version of a trampoline I've used before in 2.x, hopefully altered correctly for Python 3.x syntax/semantics): class From: @classmethod def container(cls, func): def decorated(*args, **kw): return cls(func(*args, **kw)) # wrap generator in a From() instance return decorated def __new__(cls, geniter): if isinstance(geniter, cls): # It's already a 'From' instance, just return it return geniter self = object.__new__(cls, geniter) self.stack = [geniter] return self def __iter__(self): return self def __next__(self): return self._step() def send(self, value): return self._step(value) def throw(self, *exc_info): return self._step(None, exc_info) def _step(self, value=None, exc_info=()): if not self.stack: raise RuntimeError(Can't resume completed generator) try: while self.stack: try: it = self.stack[-1] if exc_info: try: rv = it.throw(*exc_info) finally: exc_info = () elif value is not None: rv = it.send(value) else: rv = it.next() except: value = None exc_info = sys.exc_info() if exc_info[0] is StopIteration: # pass return value up the stack value, = exc_info[1].args or (None,) exc_info = () # but not the error self.stack.pop() else: if isinstance(rv, From): stack.extend(rv.stack) # Call subgenerator value, exc_info, rv = None, (), None else: return rv # it's a value to yield/return else: # Stack's empty, so exit w/current return value or error if exc_info: raise exc_info[1] else: return value finally: exc_info = () # don't let this create garbage def close(self): if self.stack: try: # There's probably a cleaner way to do this in Py 3, I just # don't know what it is off the top of my head... raise GeneratorExit except GeneratorExit as e: try: self.throw(*sys.exc_info()) except
Re: [Python-Dev] Does trace modules have a unit test?
On Sun, Jul 25, 2010 at 2:20 AM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: I would like to use this opportunity to merge settrace and setprofile tests. Here is the proposal: Step 1: Rename test_trace to test_sys_settrace and test_profilehooks to test_sys_setprofile. Step 2: Create tracetester helper file with abstract test cases made from the union of test_sys_settrace and test_sys_setprofile test cases and replace the concrete test cases in test_sys_set* with subclasses that define setmethod, getmethod and expected_output. An alternative proposal is to put all tests for both trace and profile into a single test_sys_tracing file. What do you think? (Another option is to leave test_profilehooks and use rename test_trace to test_tracehooks in the step 1 above.) A tracetester helper module + the two test module renames sounds like a fine idea to me (your proposed new names should be clearer than the existing *hooks naming, given the existence of profile and trace modules). You may want to do a grep for references to the existing test files in comments in the rest of the test suite though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] PEP 380 - return value question and prototype implementation (was Thoughts fresh after EuroPython)
On Sat, Jul 24, 2010 at 6:51 PM, P.J. Eby p...@telecommunity.com wrote: At 07:08 AM 7/24/2010 -0700, Guido van Rossum wrote: - After seeing Raymond's talk about monocle (search for it on PyPI) I am getting excited again about PEP 380 (yield from, return values from generators). Having read the PEP on the plane back home I didn't see anything wrong with it, so it could just be accepted in its current form. I would like to reiterate (no pun intended) the suggestion of a special syntactic form for the return, such as yield return x, or return with x or something similar, to distinguish it from a normal generator return. I think that when people are getting used to the idea of generators, it's important for them to get the idea that the function's return value isn't really a value, it's an iterator object. Allowing a return value, but then having that value silently disappear, seems like it would delay that learning, so, a special form might help to make it clear that the generator in question is intended for use with a corresponding yield from, and help avoid confusion on this. (I could of course be wrong, and would defer to anyone who sees a better way to explain/teach around this issue. In any event, I'm +1 on the PEP otherwise.) Hm... I somehow really like the idea that the return statement always translates into raising StopIteration -- it seems so right when writing the trampoline code. I wonder if we could enforce this at runtime, by raising (e.g.) TypeError if a StopIteration is caught with a value other than None in a place where the value will be ignored. Such a check feels somewhat similar to the check that .send() with a value other than None is not used on a generator in its initial state. Also I think that confusing yield X and return X, while possible, is relatively easy to debug, because things go so horribly wrong the first time. FWIW, the thing that was harder to debug when I tried to write some code involving generators and a trampoline recently, was thinking of a function as a generator without actually putting a yield in it (because a particular version of a coroutine pattern didn't need to block at all). Monocle uses a decorator to flag all coroutines which fixes this up in the right way, which I think is clever, but I'm torn about the need to flag every coroutine with a decorator -- Monocle makes the decorator really short (@_o) because, as Raymond (not Monocle's author but its advocate at EuroPython) said, you'll be using this hundreds of times. Which I find disturbing in itself. By the way, the PEP's optimized implementation could probably be done just by making generator functions containing yield-from statements return an object of a different type than the standard geniter. [...] Not a bad idea. -- --Guido van Rossum (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] Python profiler and other tools
On Sun, Jul 25, 2010 at 3:30 AM, Guido van Rossum gu...@python.org wrote: On Fri, Jul 23, 2010 at 4:20 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: There must be a good reason why traditional software development tools such as debugger, profiler and coverage are mostly neglected in python. Most such tools are probably better developed outside the standard library. There are many reasons for that, but I would guess that it mostly has to do with very different development cycles for tools. Tool development usually goes in quick bursts (driven by urgent needs and perhaps improving tool developer skills) unrelated to the stdlib release cycle (and releasing the stdlib separately won't make much of a difference). Also tools often have rough edges, and the stdlib (except for the stuff added before 1995 or so :-) has a high perfectionism standard. Part of me agrees with you regarding the generally different tool lifecycle, but another part says we need these tools in the standard library or we risk inadvertently breaking the hooks they would still rely on, even as third party projects. I suspect a major factor here relates to the degree of unit test coverage for these components - for areas that aren't of direct interest to me, I'll still deal with it if something I do breaks that code's unit tests, but if the tests don't start failing I'll never even think to check for an incompatibility. (e.g. I seem to recall line tracing for with statements and/or generator expressions being broken for a while before we fixed it) PEP 306 (the one about changing the grammar) and PEP 339 (which includes a short section on changing the bytecode definition) may also be missing some steps to make sure that any syntax and opcode changes are correctly covered by the disassembly, debugging, profiling and tracing tests. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] [isssue 2001] Pydoc enhancement patch questions
On Sun, Jul 25, 2010 at 5:34 AM, Ron Adam r...@ronadam.com wrote: On 07/24/2010 05:37 AM, Nick Coghlan wrote: On Sat, Jul 24, 2010 at 10:05 AM, Ron Adamr...@ronadam.com wrote: I am not sure I like the fact that the browser is started automatically. Please bring this up on python-dev. This may be an opportunity to rethink pydoc command line switches. For example, -p and -g are currently exclusive, but it would make sense for -g to start server on the port specified by -p. So are any thoughts on starting the web browser automatically, and on how the -g and -p command line switches work? My suggestion: - leave the -g option alone (including the tk gui), but make sure other options still work when tk is unavailable I was hoping it would be ok to drop the tk gui in pydoc. Keeping it requires rewriting the tk gui interface to use the new server because the server code and the gui code are not cleanly separate. I can do this if it's really wanted. (Nothing against tKinter, I use it for my own gui apps.) I'd be completely fine with dropping the Search For box from the GUI interface, but the persistent window listing the served port and providing Open Browser and Quit Serving buttons still seems quite useful even without the search box (When running python -m pydoc -p 8080 , it took me a moment to figure out how to kill the server I had started). You could even tidy it up a bit and include things like the Python version in the GUI window. Specifying both -b and -g should open both the (limited) GUI and the web browser. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] [isssue 2001] Pydoc enhancement patch questions
On Sun, Jul 25, 2010 at 1:16 AM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Sat, Jul 24, 2010 at 6:37 AM, Nick Coghlan ncogh...@gmail.com wrote: .. For the -b option, if the server is already running (and hence the port is in use), catch the exception, print a message and start the webbrowser anyway. I was going to make a similar suggestion, but then realized that there it may not be easy or desirable for pydoc to figure out whether the service running on the used port is in fact pydoc. Any query that pydoc would send may be disruptive depending on what program is listening on the port. It may also get easily confused by a pydoc service from a different version of python. It may be better to search for an unused port in the error case and pass it to the browser. I don't think there's any need to check if it is an actual pydoc server running on the port - if it isn't pydoc, the user will be able to tell that by what shows up in the webbrowser window. To request automatic assignment of a local port number, -p 0 could be made to work correctly (i.e. print out the actual port the OS assigned rather than the 0 that was passed in on the command line as it does currently). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] PEP 380 - return value question and prototype implementation (was Thoughts fresh after EuroPython)
At 08:21 PM 7/24/2010 -0700, Guido van Rossum wrote: FWIW, the thing that was harder to debug when I tried to write some code involving generators and a trampoline recently, was thinking of a function as a generator without actually putting a yield in it (because a particular version of a coroutine pattern didn't need to block at all). Monocle uses a decorator to flag all coroutines which fixes this up in the right way, which I think is clever, but I'm torn about the need to flag every coroutine with a decorator -- Monocle makes the decorator really short (@_o) because, as Raymond (not Monocle's author but its advocate at EuroPython) said, you'll be using this hundreds of times. Which I find disturbing in itself. I haven't used Monocle, but in all the libraries I've written myself for this sort of thing (Trellis and peak.events), a decorator is only required for a generator that is a root task; everything else is just a normal generator. For example, in Trellis you use @Task.factory to mark a function as spawning an independent task each time it's called, but subgenerator functions called within the task don't need to be marked, and in fact the yield from is just a yield - the trampoline expects all yields of generators to be subgenerator calls. (PEP 380 can't do this of course, since it also doubles as a sort of 'yield *' - i.e., you may care about the yielded values) Note, though, that even in the sketch I just gave, you don't *really* need to decorate every function, just the ones that need to be called from *non*-decorated functions... i.e. root coroutines. Even then, you could *still* skip the decorator and replace: an_iter = decorated_root_function() with: an_iter = From(undecorated_root_function()) and not need to decorate *anything*. ___ 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] http://bugs.python.org/issue231540
On Sun, Jul 25, 2010 at 10:45 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: What I find very helpful in these cases is to put all my vitriol into the rant, bask in it, and then *delete it unsent*. That way, I'm not spreading the bad emotion any further than my desk, and it truly is cathartic so I can sleep soundly. A win all around. I can vouch for the effectiveness of this trick. I can also point to cases where I didn't use it and dealing with the consequences proved to be a lot more hassle than whatever had been irritating me in the first place :) How can I sum up what I think about Python, that's fairly easy. www.python.org is bookmarked as Home Sweet Home, can I say any more? Thank you all for your kindness, and please note that I've again been plugging away today and rather enjoying myself. Thanks again for your achievements in improving Python, and best wishes in dealing with whatever life deals you. Indeed. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Thoughts fresh after EuroPython
On Sun, 25 Jul 2010 10:04:57 am Steve Holden wrote: - After seeing Raymond's talk about monocle (search for it on PyPI) I am getting excited again about PEP 380 (yield from, return values from generators). Having read the PEP on the plane back home I didn't see anything wrong with it, so it could just be accepted in its current form. Implementation will still have to wait for Python 3.3 because of the moratorium. (Although I wouldn't mind making an exception to get it into 3.2.) I can understand the temptation, but hope you can manage to resist it. The downside of allowing such exceptions is that people won't take these pronouncements seriously if they see that a sufficiently desirable goal is a reason for ignoring them. Everyone should be subject to the same rules. I have no opinion on PEP 380 specifically, but surely a *sufficiently* desirable goal *should* be a reason for breaking the rules? Obedience to some abstract rule just because it is the rule is not a virtue. The moratorium is there to advance Python as a whole, and if (a big if) it becomes a hindrance instead, then Guido should make an exception. I promise that I won't cease taking his pronouncements seriously if he does :) -- Steven D'Aprano ___ 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] Thoughts fresh after EuroPython
On Sat, Jul 24, 2010 at 9:16 PM, Steven D'Aprano st...@pearwood.info wrote: On Sun, 25 Jul 2010 10:04:57 am Steve Holden wrote: - After seeing Raymond's talk about monocle (search for it on PyPI) I am getting excited again about PEP 380 (yield from, return values from generators). Having read the PEP on the plane back home I didn't see anything wrong with it, so it could just be accepted in its current form. Implementation will still have to wait for Python 3.3 because of the moratorium. (Although I wouldn't mind making an exception to get it into 3.2.) I can understand the temptation, but hope you can manage to resist it. The downside of allowing such exceptions is that people won't take these pronouncements seriously if they see that a sufficiently desirable goal is a reason for ignoring them. Everyone should be subject to the same rules. I have no opinion on PEP 380 specifically, but surely a *sufficiently* desirable goal *should* be a reason for breaking the rules? Obedience to some abstract rule just because it is the rule is not a virtue. The moratorium is there to advance Python as a whole, and if (a big if) it becomes a hindrance instead, then Guido should make an exception. I promise that I won't cease taking his pronouncements seriously if he does :) I wasn't for the moratorium in the first place, so take this with a grain of salt, but ISTM that if you feel this doesn't impact the moratorium's goals then there's nothing logically inconsistent about allowing it through. Of course, if you feel like it does and you decide to let it through anyway, I think it would be worth explaining really well why exactly that happened. Geremy Condra ___ 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-Dev Digest, Vol 84, Issue 112
Date: Sat, 24 Jul 2010 23:59:14 +0200 From:sch...@gmail.com To: Barry Warsawba...@python.org Cc: Ronald Oussorenronaldousso...@mac.com,python-dev@python.org Subject: Re: [Python-Dev] versioned .so files for Python 3.2 Message-ID:87aapgbky5@brainbot.com Content-Type: text/plain; charset=us-ascii Barry Warsawba...@python.org writes: On Jul 23, 2010, at 01:46 PM,sch...@gmail.com wrote: Doesn't anybody else think this is lost work for very little gain? My /usr/lib/python2.6/site-packages directory consumes 200MB on disk. I couldn't care less if my /usr/lib/python2.5/site-packages consumed the same amount of disk space... Right, you probably don't care now that your extension modules live in foo.so so it probably won't make much difference if they were named foo-blahblah.so, as long as they import.:) Most of the time it won't make much difference, right. But I can assure you, that it will bite some people and there is some code to be adapted. If you use Debian or Ubuntu though, it'll be a win for you by allow us to make Python support much more robust. I'd much prefer to have cleanly separated environments by having separate directories for my python modules. Sharing the source code and complicating things will not lead to increased robustness. - Ralf Debian's policy on Python packaging calls for maximum separation between versions. See http://www.debian.org/doc/packaging-manuals/python-policy/; This keeps the system updaters from becoming confused, and reduces the risk that an update to one version of Python will break another version. John Nagle ___ 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
