Re: [Python-Dev] Set the namespace free!
On Sat, Jul 24, 2010 at 3:31 AM, Gregory P. Smith wrote: > Yuck. Anyone who feels they need a variable named the same a reserved word > simply feels wrong and needs reeducation. [...] While I agree with you in principle, I have been finding it frustrating trying to calculate yield in my financial applications lately... ;) That being said, yield is pretty much the only (reserved) word I have had problems with finding (descriptive) alternative (variable) names for, so far. Anders ___ Python-Dev mailing list [email protected] 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 26/07/2010 04:42, Guido van Rossum wrote: On Sun, Jul 25, 2010 at 8:31 PM, Peter Portante wrote: FWIW: We use Python at Tabblo, straddled across Python 2.5.4 and 2.6.5. They work. And they work well. But we make light use of threads (mostly background I/O handling), and heavy use of multiple processes because we can't take advantage of our multi-core systems otherwise. Isn't this an indication that the GIL is, in fact, not (much of) a problem? I wish those trying to get rid of the GIL well. But it may not be the panacea some folks are hoping for. Multi-threaded programming remains hard (and removing the GIL might actually make it harder). Jython and IronPython don't have a GIL, and I think PyPy may not either. Does anyone have experience with GIL-free programming in one of those? At Resolver Systems we created a "calculation system" that does large calculations on background threads using IronPython. Doing them on a background thread allows the ui to remain responsive. Several calculations could run simultaneously using multiple cores. As the calculation operates on a large object graph (which the ui then needs access to in order to display it) using multiprocessing would have imposed a very big overhead due to serialization / deserialization (the program runs on windows). Using CPython would have made the program a lot slower due to the GIL. All the best, Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] 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 26/07/2010 04:42, Guido van Rossum wrote: On Sun, Jul 25, 2010 at 8:31 PM, Peter Portante wrote: FWIW: We use Python at Tabblo, straddled across Python 2.5.4 and 2.6.5. They work. And they work well. But we make light use of threads (mostly background I/O handling), and heavy use of multiple processes because we can't take advantage of our multi-core systems otherwise. Isn't this an indication that the GIL is, in fact, not (much of) a problem? I wish those trying to get rid of the GIL well. But it may not be the panacea some folks are hoping for. Multi-threaded programming remains hard (and removing the GIL might actually make it harder). Jython and IronPython don't have a GIL, and I think PyPy may not either. Does anyone have experience with GIL-free programming in one of those? Oh, and PyPy does have a GIL but the developers say it wouldn't be a huge amount of work to remove it. Presumably they would have to add locking in the right places - which would then impact performance. As PyPy doesn't use reference counting adding locking shouldn't impact performance as much as previous attempts with CPython have. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] 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
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. > I would like to highlight that other open source projects have used more liberal commit right policies, without the project breaking into pieces, to the contrary. For example, in KDE, you usually get commit rights on your second patch submisssion. The contributors have reported that it really helped to convert from "occasional contributors" to "active contributors" and were encouraged by the trust given by the project community. They felt a new sense of responsibility toward the project with the ability to contribute directly. There was never any malicious commits done to KDE using this liberal policy. The newcomers tend to be extremely careful. If you keep the newcomers under the umbrella of a mentor for a few months and with the additional security of post-commit reviews, I am sure that you are not taking any real risks on the codebase. cheers, Philippe ___ Python-Dev mailing list [email protected] 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 Mon, Jul 26, 2010 at 12:02 PM, Michael Foord wrote: > On 26/07/2010 04:42, Guido van Rossum wrote: >> >> On Sun, Jul 25, 2010 at 8:31 PM, Peter Portante >> wrote: >> >>> >>> FWIW: We use Python at Tabblo, straddled across Python 2.5.4 and 2.6.5. >>> They >>> work. And they work well. But we make light use of threads (mostly >>> background I/O handling), and heavy use of multiple processes because we >>> can't take advantage of our multi-core systems otherwise. >>> >> >> Isn't this an indication that the GIL is, in fact, not (much of) a >> problem? >> >> I wish those trying to get rid of the GIL well. But it may not be the >> panacea some folks are hoping for. Multi-threaded programming remains >> hard (and removing the GIL might actually make it harder). >> >> Jython and IronPython don't have a GIL, and I think PyPy may not >> either. Does anyone have experience with GIL-free programming in one >> of those? >> >> > > Oh, and PyPy does have a GIL but the developers say it wouldn't be a huge > amount of work to remove it. It wouldn't be as huge as on CPython, since we don't have reference counting, but it's still *a lot* of work and someone would have to step and take this task (since none core pypy dev is that interested in that). > > Presumably they would have to add locking in the right places - which would > then impact performance. As PyPy doesn't use reference counting adding > locking shouldn't impact performance as much as previous attempts with > CPython have. That's one thing but the other thing is that JIT can remove a lot of locks (like it does no JVM), but that's yet another batch of work to be done. Cheers, fijal ___ Python-Dev mailing list [email protected] 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 4:08 PM, Guido van Rossum wrote: [...] > - 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 Q&A (http://bit.ly/bdflqa) I think not enough people are > aware of what we are already doing in this area. Even people very involved in packaging are not fully aware of what's going on. I am not for instance. I think that we lack to communicate and synchronize on our efforts on the PyPI development. The last example I have in mind is that I have announced here that I was working on a patch for the checkbox problem, then Martin announced today on catalog-sig it was fixed by Georg and updated in production :) I think we need to improve this: it can be a very frustrating experience to contribute to PyPI. Possible improvements: - Have a PyPI component at bugs.python.org so all work on bugs/new features would be known and followed by at the same level than other packaging components we maintain, and that depend on PyPI (distutils, distutils2) -- e.g. drop the sourceforge tracker - Make it easier to contribute by moving the PyPI code base to hg.python.org. Unlike Python, this is a very simple move. > Frankly, I'm not sure > I do, either: I think I've heard of a GSOC student and of plans to > take over pypi.appspot.com (with the original developer's permission) > to become a full and up-to-date mirror. That would be great if the student could promote his work at Catalog-SIG. > Mirroring apparently also > requires some client changes. Mirrors can be used as long as you manually point a mirror when using them. We we are working on making the switch automatic. Regards, Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list [email protected] 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 Mon, Jul 26, 2010 at 4:02 AM, Tarek Ziadé wrote: > On Sat, Jul 24, 2010 at 4:08 PM, Guido van Rossum wrote: >> Mirroring apparently also >> requires some client changes. > > Mirrors can be used as long as you manually point a mirror when using > them. We we are working on making the > switch automatic. I think we've talked briefly about this before, but let me reiterate that getting this right from a security point of view is quite a bit harder than it at first appears, and IMHO it is worth getting right. Geremy Condra ___ Python-Dev mailing list [email protected] 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 Mon, Jul 26, 2010 at 1:20 PM, geremy condra wrote: > On Mon, Jul 26, 2010 at 4:02 AM, Tarek Ziadé wrote: >> On Sat, Jul 24, 2010 at 4:08 PM, Guido van Rossum wrote: > > > >>> Mirroring apparently also >>> requires some client changes. >> >> Mirrors can be used as long as you manually point a mirror when using >> them. We we are working on making the >> switch automatic. > > I think we've talked briefly about this before, but let me reiterate > that getting this right from a security point of view is quite a bit > harder than it at first appears, and IMHO it is worth getting right. FWIW, Martin has added a section about mirror authenticity in the PEP: http://www.python.org/dev/peps/pep-0381/#mirror-authenticity > > Geremy Condra > -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list [email protected] 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 Mon, Jul 26, 2010 at 4:52 AM, Tarek Ziadé wrote: > On Mon, Jul 26, 2010 at 1:20 PM, geremy condra wrote: >> On Mon, Jul 26, 2010 at 4:02 AM, Tarek Ziadé wrote: >>> On Sat, Jul 24, 2010 at 4:08 PM, Guido van Rossum wrote: >> >> >> Mirroring apparently also requires some client changes. >>> >>> Mirrors can be used as long as you manually point a mirror when using >>> them. We we are working on making the >>> switch automatic. >> >> I think we've talked briefly about this before, but let me reiterate >> that getting this right from a security point of view is quite a bit >> harder than it at first appears, and IMHO it is worth getting right. > > FWIW, Martin has added a section about mirror authenticity in the PEP: > > http://www.python.org/dev/peps/pep-0381/#mirror-authenticity This is more-or-less what was discussed earlier, and from what's described here I think the concerns I voiced stand. What's the right way to do disclosure on this sort of issue? Geremy Condra ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] View tracker patches with ViewVC?
On Mon, Jul 26, 2010 at 10:35 AM, "Martin v. Löwis" wrote: > Am 26.07.2010 02:24, schrieb Terry Reedy: >> To review a patch on the tracker, I have to read and try to make sense >> of the raw diff file. Sometimes that is easy, sometimes not. >> >> *After* a patch is applied, I can click the rev link and then the >> 'text changed' link and see a nice, colored, side-by-side web-pace view >> created by ViewVC. Is there any way a 'view' button could be added, >> along with the current edit and remove buttons, to produce the same web >> page and make it easier to review patches *before* commitment? > > You should be using Rietveld for that. And I believe there's already an item in the meta-tracker about improving the integration between bugs.python.org and Rietveld - it just doesn't exist yet. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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 Jul 24, 2010, at 07:08 AM, Guido van Rossum wrote: >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, though I'll observe that IME, actual commit privileges become much less of a special badge once a dvcs-based workflow is put in place. In the absence of that, I agree that we have enough checks and balances in place to allow more folks to commit changes. >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 This is a good idea, and certainly helps "scale Guido" better. We might also consider designating experts who can collaborate on PEP wrangling for certain topics. For example, if Martin would normally be the Cheeseshop PEP handler, but submits his own PEPs on the topic, the handful of experts can take up the slack when Martin recuses himself on his own PEPs. I'd hope that we could always find at least two people to wrangle any PEP, or we've got a bigger problem to deal with! Sounds like EuroPython was fun! -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] 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 Mon, Jul 26, 2010 at 2:10 PM, geremy condra wrote: > On Mon, Jul 26, 2010 at 4:52 AM, Tarek Ziadé wrote: >> On Mon, Jul 26, 2010 at 1:20 PM, geremy condra wrote: >>> On Mon, Jul 26, 2010 at 4:02 AM, Tarek Ziadé wrote: On Sat, Jul 24, 2010 at 4:08 PM, Guido van Rossum wrote: >>> >>> >>> > Mirroring apparently also > requires some client changes. Mirrors can be used as long as you manually point a mirror when using them. We we are working on making the switch automatic. >>> >>> I think we've talked briefly about this before, but let me reiterate >>> that getting this right from a security point of view is quite a bit >>> harder than it at first appears, and IMHO it is worth getting right. >> >> FWIW, Martin has added a section about mirror authenticity in the PEP: >> >> http://www.python.org/dev/peps/pep-0381/#mirror-authenticity > > This is more-or-less what was discussed earlier, and from what's > described here I think the concerns I voiced stand. What's the right > way to do disclosure on this sort of issue? I would recommend discussing it in Distutils-SIG and proposing a change to that PEP. Notice that this PEP is not accepted yet. I am not sure what would be the best moment to have it accepted. I guess once we have experimented enough on the client side. Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list [email protected] 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 Mon, Jul 26, 2010 at 7:21 AM, Tarek Ziadé wrote: > On Mon, Jul 26, 2010 at 2:10 PM, geremy condra wrote: >> On Mon, Jul 26, 2010 at 4:52 AM, Tarek Ziadé wrote: >>> On Mon, Jul 26, 2010 at 1:20 PM, geremy condra wrote: On Mon, Jul 26, 2010 at 4:02 AM, Tarek Ziadé wrote: > On Sat, Jul 24, 2010 at 4:08 PM, Guido van Rossum > wrote: >> Mirroring apparently also >> requires some client changes. > > Mirrors can be used as long as you manually point a mirror when using > them. We we are working on making the > switch automatic. I think we've talked briefly about this before, but let me reiterate that getting this right from a security point of view is quite a bit harder than it at first appears, and IMHO it is worth getting right. >>> >>> FWIW, Martin has added a section about mirror authenticity in the PEP: >>> >>> http://www.python.org/dev/peps/pep-0381/#mirror-authenticity >> >> This is more-or-less what was discussed earlier, and from what's >> described here I think the concerns I voiced stand. What's the right >> way to do disclosure on this sort of issue? > > I would recommend discussing it in Distutils-SIG and proposing a > change to that PEP. I've noticed that I don't have a lot of success in shifting this kind of debate, so I'm not sure it's a good idea to publicly discuss vulnerabilities in something that may wind up being implemented as-is, but it's up to you guys. Geremy Condra ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] marking os.system() as deprecated in the docs
Unless, it's as simple as replacing "os.system(x)" with "subprocess.system(x)", I'm against this removal of a handy shorthand. Ditto for popen. On Sun, Jul 25, 2010 at 11:42 PM, Chris Rebert wrote: > Hello, > > I'd like to propose formally marking os.system() as deprecated in the > docs for next release of Python (v3.2 ?). > > The docs for os.system() /already/ include the following paragraph, > which is basically tantamount to calling system() deprecated and very > much resembles the deprecation notes for the os.popen*() family. > """ > The subprocess module provides more powerful facilities for spawning > new processes and retrieving their results; using that module is > preferable to using this function. Use the subprocess module. Check > especially the Replacing Older Functions with the subprocess Module > section. > """ > > I'm merely suggesting slapping a formal ".. deprecated::" tag & box > around this paragraph to make system()'s status more obvious. I am > ***not*** suggesting the function be scheduled for removal or anything > like that. > > I figure since this would be a substantive change (the docs currently > don't outright say "deprecated"), it would need dev approval, hence > this message. I've already written the absolutely /trivial/ docs > patch. > > So, any objections? > > Cheers, > Chris > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] 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 26 Jul, 2010,at 12:00 PM, Michael Foord wrote:On 26/07/2010 04:42, Guido van Rossum wrote: > On Sun, Jul 25, 2010 at 8:31 PM, Peter Portante > wrote: > >> FWIW: We use Python at Tabblo, straddled across Python 2.5.4 and 2.6.5. They >> work. And they work well. But we make light use of threads (mostly >> background I/O handling), and heavy use of multiple processes because we >> can't take advantage of our multi-core systems otherwise. >> > Isn't this an indication that the GIL is, in fact, not (much of) a problem? > > I wish those trying to get rid of the GIL well. But it may not be the > panacea some folks are hoping for. Multi-threaded programming remains > hard (and removing the GIL might actually make it harder). > > Jython and IronPython don't have a GIL, and I think PyPy may not > either. Does anyone have experience with GIL-free programming in one > of those? > > At Resolver Systems we created a "calculation system" that does large calculations on background threads using IronPython. Doing them on a background thread allows the ui to remain responsive. Several calculations could run simultaneously using multiple cores. As the calculation operates on a large object graph (which the ui then needs access to in order to display it) using multiprocessing would have imposed a very big overhead due to serialization / deserialization (the program runs on windows). Using CPython would have made the program a lot slower due to the GIL. I have a simular usecase, although in my case it's more using large blobs instead of complicated datastructures. I'm not hurt by the GIL because most threads run C code most of the time, which enables us to use multiple CPU cores without getting hurt by the GIL.In my opinion the GIL is a weak point of CPython and it would be nice if it could be fixed. That is however easier said than done, a number of people have tried in the past and ran into implementation limitations like our refcounting garbage collector that make hard to remove the GIL without either rewriting lots of code, or running into a brick wall performance-wise.The HotPy presentation at EuroPython shows that it is possible to remove the GIL, although at the cost of replacing the garbage collector and most likely breaking existing C extensions (although the HotPy author seemed to have a possible workaround for that).Ronald___ Python-Dev mailing list [email protected] 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 Mon, Jul 26, 2010 at 3:00 AM, Michael Foord wrote: > At Resolver Systems we created a "calculation system" that does large > calculations on background threads using IronPython. Doing them on a > background thread allows the ui to remain responsive. Several calculations > could run simultaneously using multiple cores. > > As the calculation operates on a large object graph (which the ui then needs > access to in order to display it) using multiprocessing would have imposed a > very big overhead due to serialization / deserialization (the program runs > on windows). > > Using CPython would have made the program a lot slower due to the GIL. Sure. Note that using threads with the GIL, it is not a problem to keep the UI responsive even if background calculations are going on (at worst it requires some tweaking of sys.setcheckinterval() or its new-GIL equivalent). However with the GIL multiple calculations would be limited to a single core. According to CSP advicates, this approach will break down when you need more than 8-16 cores since cache coherence breaks down at 16 cores. Then you would have to figure out a message-passing approach (but the messages would have to be very fast). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] 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
geremy condra, 26.07.2010 16:29: I've noticed that I don't have a lot of success in shifting this kind of debate, so I'm not sure it's a good idea to publicly discuss vulnerabilities in something that may wind up being implemented as-is, but it's up to you guys. Hmm, security by obscurity? That's a good idea. Let's do that more often. Stefan ___ Python-Dev mailing list [email protected] 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 Mon, Jul 26, 2010 at 4:29 PM, geremy condra wrote: ... > I've noticed that I don't have a lot of success in shifting this kind > of debate, so I'm not sure it's a good idea to publicly discuss > vulnerabilities in something that may wind up being implemented as-is, > but it's up to you guys. I think its best to have this discussed there publicly. In any case, mirrors are run by trusted people, so the risks are not very high AFAIK I think this discussion didn't have a lot of participant because most of us (that includes me) are not expert all all, if not ignorant, in this topic. A complete patch to the PEP, including a detailed description, is the best thing to do I think, to move this forward. Regards Tarek ___ Python-Dev mailing list [email protected] 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 Mon, Jul 26, 2010 at 7:36 AM, Stefan Behnel wrote: > geremy condra, 26.07.2010 16:29: >> >> I've noticed that I don't have a lot of success in shifting this kind >> of debate, so I'm not sure it's a good idea to publicly discuss >> vulnerabilities in something that may wind up being implemented as-is, >> but it's up to you guys. > > Hmm, security by obscurity? That's a good idea. Let's do that more often. FWIW, security by obscurity has a bad rep in some circles, but it is an essential component of any serious security policy. It just should never be the *only* component. (In fact, any serious security policy should have multiple disparate components.) In this case, it looks like (a) the cat is already out of the bag, and (b) it's easy to figure out from the PEPs where the vulnerabilities lie, so I don't think we'll gain much by shushing it up. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] 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 Mon, Jul 26, 2010 at 7:36 AM, Stefan Behnel wrote: > geremy condra, 26.07.2010 16:29: >> >> I've noticed that I don't have a lot of success in shifting this kind >> of debate, so I'm not sure it's a good idea to publicly discuss >> vulnerabilities in something that may wind up being implemented as-is, >> but it's up to you guys. > > Hmm, security by obscurity? That's a good idea. Let's do that more often. Usually it's termed responsible disclosure, but I'm a lot more interested in fixing things than playing semantics. Geremy Condra ___ Python-Dev mailing list [email protected] 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 Tue, 27 Jul 2010 12:36:37 am Stefan Behnel wrote: > geremy condra, 26.07.2010 16:29: > > I've noticed that I don't have a lot of success in shifting this > > kind of debate, so I'm not sure it's a good idea to publicly > > discuss vulnerabilities in something that may wind up being > > implemented as-is, but it's up to you guys. > > Hmm, security by obscurity? That's a good idea. Let's do that more > often. Shhh! Don't tell anybody! *wink* But seriously, I don't think Geremy is suggesting security by obscurity. It seems to me that he's merely suggesting that we are discreet about discussing vulnerabilities unless we have a plan to fix them. Whether such discretion is useful is an open question. It may be that the cat is already out of the bag and it's too late to be discreet, so we might as well not bother. -- Steven D'Aprano ___ Python-Dev mailing list [email protected] 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
> According to CSP advicates, this approach will break down when you > need more than 8-16 cores since cache coherence breaks down at 16 > cores. Then you would have to figure out a message-passing approach > (but the messages would have to be very fast). It does break down, and probably always will be. Imho this gets worse with NUMA architectures becoming more prevalent. But even with 50 cores you may be happy to have something run away with 4-8 threads shared memory from time to time. Developing good message based schemes is important for the long run, but I think multithreaded parallelization will become more common, before we see a general switch to messages. Regards, Joerg Blank ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] marking os.system() as deprecated in the docs
On Mon, 26 Jul 2010 04:42:06 pm Chris Rebert wrote: > Hello, > > I'd like to propose formally marking os.system() as deprecated in the > docs for next release of Python (v3.2 ?). -0.5 on that. I often use os.system() for quick and dirty scripts that just call an external process without caring what the output is. But perhaps os.system() should become an alias for subprocess.system() in 3.2, then deprecated in 3.3 and removed (from os only) in 3.4? -- Steven D'Aprano ___ Python-Dev mailing list [email protected] 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/25/2010 12:01 PM, Alexander Belopolsky wrote: On Sun, Jul 25, 2010 at 12:32 PM, Ron Adam wrote: .. 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). Why not simply have "Quit Serving" next to the search button in the served pages? The server can even serve a friendly page explaining how it can be restarted before quitting. .. Another way to communicate to the server would be to add a link in the browser to open a server status page. For example my router has a configure page where I can check it's status and do other things. That might be something worth exploring at some later date. This would work as well, but for starters, I think "Search" and "Quit" buttons next to each other will be most familiar to the users of the current Tk-based control window. Nick, what do you think about the "Quit" link in the browser along with improving the server startup message on the console window? Ron ___ Python-Dev mailing list [email protected] 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 Mon, Jul 26, 2010 at 9:06 AM, Barry Warsaw wrote: > On Jul 24, 2010, at 07:08 AM, Guido van Rossum wrote: > >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, though I'll observe that IME, actual commit privileges become much less > of > a special badge once a dvcs-based workflow is put in place. In the absence > of > that, I agree that we have enough checks and balances in place to allow > more > folks to commit changes > Even with DVCS in place, commit privileges allow the person who cares about a change to move it forward, including the more mechanical aspects. E.g. if there are positive reviews of a person's changes in their fork, they can push those changes in. Or more generally, there's a lot of ways of getting approval, but limited commit privileges means all approval must ultimately be funneled through someone with commit. Also different parts of the codebase should have different levels of review and conservativism; e.g., adding clarifications to the docs requires a different level of review than changing stuff in the core. We could try to build that into the tools, but it's a lot easier to make the tools permissive and build these distinctions into social structures. -- Ian Bicking | http://blog.ianbicking.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] marking os.system() as deprecated in the docs
The current text is: The subprocess module provides more powerful facilities for spawning new processes and retrieving their results; using that module is preferable to using this function. See the Replacing Older Functions with the subprocess Module section in the subprocess documentation for some helpful recipes. We could soften "using that module is preferable" to say "may be", or just delete that whole clause completely. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] View tracker patches with ViewVC?
On Sun, Jul 25, 2010 at 8:24 PM, Terry Reedy wrote: > Is there any way a 'view' button could be added, along with the > current edit and remove buttons, to produce the same web page and make it > easier to review patches *before* commitment? One thing that patch submitters can do already is to make sure that their patches are recognized as text/plain by the tracker. This can be achieved using standard extensions such as .patch, .diff, or .txt and avoiding non-satndard ones such as .patch2. Note that if you accidentally uploaded a text file with a wrong extension, you can go to the edit page and change the file name and/or content type. I think the tracker may become a little more proactive in enforcing plain text attachments by rejecting unrecognized extensions or warning users about them. On a similar note, I wonder if tracker should simply reject binary attachments with a possible exception of well formed UTF-8 text. ___ Python-Dev mailing list [email protected] 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 24 Jul, 2010, at 23:29, Alexander Belopolsky wrote: > 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.) Could you please file a bug for this? I have no idea whether or not it is an easy to fix one, but without an issue in the tracker this is something that is unlikely to get fixed. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list [email protected] 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 Mon, Jul 26, 2010 at 11:39 AM, Ronald Oussoren wrote: .. > Could you please file a bug for this? I have no idea whether or not it is an > easy to fix one, > but without an issue in the tracker this is something that is unlikely to get > fixed. http://bugs.python.org/issue9384 ___ Python-Dev mailing list [email protected] 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/26/2010 2:40 AM, Peter Portante wrote: Yet, shouldn't we be able to write a simple embarrassingly parallel multithreaded algorithm in python (no C-extensions) and have its execution use all the cores on a system using CPython? Abstractly, yes, and I believe you can do that now with some implementations. The actual questions are along the lines of ... What would be the cost of making that happen with CPython? Who would be disadvanged making that happen with CPython? and for both of those, Is the tradeoff worth it? Another way to put it is Should CPython be optimized for 1, 2, 3, or 4 or more cores? The answer to this is obviously changing. I will soon replace a single core with a 4/6 core machine, so would be right in the middle on that, except that my current work is all single-threaded anyway. But that could change. Should all implementation be optimized the same way? Of course, with several developers focused on these issues, we could have a compile time switch and distribute multiple Windows binaries, but this does not seem like fun, volunteer-type stuff. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] marking os.system() as deprecated in the docs
Is it possible to use subprocess functionality in os.system()? Just exactly describe what it does instead of "This is implemented by calling the Standard C function system(), and has the same limitations." type sentences. -- anatoly t. On Mon, Jul 26, 2010 at 6:52 PM, A.M. Kuchling wrote: > The current text is: > > The subprocess module provides more powerful facilities for > spawning new processes and retrieving their results; using that > module is preferable to using this function. See the Replacing > Older Functions with the subprocess Module section in the > subprocess documentation for some helpful recipes. > > We could soften "using that module is preferable" to say "may be", or > just delete that whole clause completely. > > --amk > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/techtonik%40gmail.com > ___ Python-Dev mailing list [email protected] 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 Jul 26, 2010, at 10:50 AM, Ian Bicking wrote: >On Mon, Jul 26, 2010 at 9:06 AM, Barry Warsaw wrote: > >> On Jul 24, 2010, at 07:08 AM, Guido van Rossum wrote: >> >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, though I'll observe that IME, actual commit privileges become >> much less of >> a special badge once a dvcs-based workflow is put in place. In the >> absence of >> that, I agree that we have enough checks and balances in place to >> allow more >> folks to commit changes >> > >Even with DVCS in place, commit privileges allow the person who cares >about a change to move it forward, including the more mechanical >aspects. E.g. if there are positive reviews of a person's changes in >their fork, they can push those changes in. Or more generally, >there's a lot of ways of getting approval, but limited commit >privileges means all approval must ultimately be funneled through >someone with commit. Right, but with a dvcs workflow, it's really only the very last step that requires commit privileges. There is much less chance of having those fork branches get stale, much greater ability for those branches to be reviewed, tested, and commented on, etc. You can more easily do everything right up until the final merge to the master branch without commit privileges, so it's much less of a blocker to progress. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] OpenID login for Roundup bug trackers
+On Tue, Jul 20, 2010 at 3:25 PM, "Martin v. Löwis" wrote: >> Thanks for drawing my attention to that; if the people who made OpenID >> auth happen are observing this, then thank you all very much! > > You're welcome! > >> Any hope of feeding those changes back upstream so it's available to all >> Roundup users at some point? > > Hope dies last. > > It's main foundation is an openid library that I wrote > (http://pypi.python.org/pypi/openid2rp). As for the roundup integration, I > likely won't have much time to contribute it back. I could do the merge if the license were the same as Roundup or something similar like MIT or ISC. -- anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Readability of hex strings (Was: Use of coding cookie in 3.x stdlib)
I find "\xXX\xXX\xXX\xXX..." notation for binary data totally unreadable. Everybody who uses and analyses binary data is more familiar with plain hex dumps in the form of "XX XX XX XX...". I wonder if it is possible to introduce an effective binary string type that will be represented as h"XX XX XX" in language syntax? It will be much easier to analyze printed binary data and copy/paste such data as-is from hex editors/views. On Mon, Jul 19, 2010 at 9:45 AM, Guido van Rossum wrote: > Sounds like a good idea to try to remove redundant cookies *and* to > remove most occasional use of non-ASCII characters outside comments > (except for unittests specifically trying to test Unicode features). > Personally I would use \xXX escapes instead of spelling out the > characters in shlex.py, for example. > > Both with or without the coding cookies, many ways of displaying text > files garble characters outside the ASCII range, so it's better to > stick to ASCII as much as possible. > > --Guido > > On Mon, Jul 19, 2010 at 1:21 AM, Alexander Belopolsky > wrote: >> I was looking at the inspect module and noticed that it's source >> starts with "# -*- coding: iso-8859-1 -*-". I have checked and there >> are no non-ascii characters in the file. There are several other >> modules that still use the cookie: >> >> Lib/ast.py:# -*- coding: utf-8 -*- >> Lib/getopt.py:# -*- coding: utf-8 -*- >> Lib/inspect.py:# -*- coding: iso-8859-1 -*- >> Lib/pydoc.py:# -*- coding: latin-1 -*- >> Lib/shlex.py:# -*- coding: iso-8859-1 -*- >> Lib/encodings/punycode.py:# -*- coding: utf-8 -*- >> Lib/msilib/__init__.py:# -*- coding: utf-8 -*- >> Lib/sqlite3/__init__.py:#-*- coding: ISO-8859-1 -*- >> Lib/sqlite3/dbapi2.py:#-*- coding: ISO-8859-1 -*- >> Lib/test/bad_coding.py:# -*- coding: uft-8 -*- >> Lib/test/badsyntax_3131.py:# -*- coding: utf-8 -*- >> >> I understand that coding: utf-8 is strictly redundant in 3.x. There >> are cases such as Lib/shlex.py where using encoding other than utf-8 >> is justified. (See >> http://svn.python.org/view?view=rev&revision=82560). What are the >> guidelines for other cases? Should redundant cookies be removed? >> Since not all editors respect the -*- cookie, I think the answer >> should be "yes" particularly when the cookie is setting encoding other >> than utf-8. >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > > > -- > --Guido van Rossum (python.org/~guido) > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/techtonik%40gmail.com > ___ Python-Dev mailing list [email protected] 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
On Jul 24, 2010, at 09:54 AM, Ronald Oussoren wrote: >> 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. Cool. In that case, I won't add it. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] 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
On Jul 24, 2010, at 11:59 PM, [email protected] wrote: >Barry Warsaw writes: > >> On Jul 23, 2010, at 01:46 PM, [email protected] 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. Do you have concrete examples? Without that it's just speculation I can't do much to address. Is the problem big or small? Easy to work around or not? "Change is bad" isn't a constructive argument. ;) >> 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. That's fine, but it's not the way Debian/Ubuntu works today. PEP 3149 adoption will definitely remove significant complication for deploying multiple Python versions at the same time on those systems. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Readability of hex strings (Was: Use of coding cookie in 3.x stdlib)
[+Python-ideas -Python-Dev]
import binascii
def h(s):
return binascii.unhexlify("".join(s.split()))
h("DE AD BE EF CA FE BA BE")
-- Alexandre
On Mon, Jul 26, 2010 at 11:29 AM, anatoly techtonik wrote:
> I find "\xXX\xXX\xXX\xXX..." notation for binary data totally
> unreadable. Everybody who uses and analyses binary data is more
> familiar with plain hex dumps in the form of "XX XX XX XX...".
>
> I wonder if it is possible to introduce an effective binary string
> type that will be represented as h"XX XX XX" in language syntax? It
> will be much easier to analyze printed binary data and copy/paste such
> data as-is from hex editors/views.
>
> On Mon, Jul 19, 2010 at 9:45 AM, Guido van Rossum wrote:
>> Sounds like a good idea to try to remove redundant cookies *and* to
>> remove most occasional use of non-ASCII characters outside comments
>> (except for unittests specifically trying to test Unicode features).
>> Personally I would use \xXX escapes instead of spelling out the
>> characters in shlex.py, for example.
>>
>> Both with or without the coding cookies, many ways of displaying text
>> files garble characters outside the ASCII range, so it's better to
>> stick to ASCII as much as possible.
>>
>> --Guido
>>
>> On Mon, Jul 19, 2010 at 1:21 AM, Alexander Belopolsky
>> wrote:
>>> I was looking at the inspect module and noticed that it's source
>>> starts with "# -*- coding: iso-8859-1 -*-". I have checked and there
>>> are no non-ascii characters in the file. There are several other
>>> modules that still use the cookie:
>>>
>>> Lib/ast.py:# -*- coding: utf-8 -*-
>>> Lib/getopt.py:# -*- coding: utf-8 -*-
>>> Lib/inspect.py:# -*- coding: iso-8859-1 -*-
>>> Lib/pydoc.py:# -*- coding: latin-1 -*-
>>> Lib/shlex.py:# -*- coding: iso-8859-1 -*-
>>> Lib/encodings/punycode.py:# -*- coding: utf-8 -*-
>>> Lib/msilib/__init__.py:# -*- coding: utf-8 -*-
>>> Lib/sqlite3/__init__.py:#-*- coding: ISO-8859-1 -*-
>>> Lib/sqlite3/dbapi2.py:#-*- coding: ISO-8859-1 -*-
>>> Lib/test/bad_coding.py:# -*- coding: uft-8 -*-
>>> Lib/test/badsyntax_3131.py:# -*- coding: utf-8 -*-
>>>
>>> I understand that coding: utf-8 is strictly redundant in 3.x. There
>>> are cases such as Lib/shlex.py where using encoding other than utf-8
>>> is justified. (See
>>> http://svn.python.org/view?view=rev&revision=82560). What are the
>>> guidelines for other cases? Should redundant cookies be removed?
>>> Since not all editors respect the -*- cookie, I think the answer
>>> should be "yes" particularly when the cookie is setting encoding other
>>> than utf-8.
>>> ___
>>> Python-Dev mailing list
>>> [email protected]
>>> http://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
>>> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>>>
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>> ___
>> Python-Dev mailing list
>> [email protected]
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/techtonik%40gmail.com
>>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/alexandre%40peadrop.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Define a place for code review in Python workflow
http://bugs.python.org/issue9376 This issue discussed docs on the proper way to create diff on windows (as it is doesn't have the tool) for sending the patch. The current proper way is to use "svn diff" which will be replaced with "hg diff". I proposed using Rietveld like: > python -m easy_install review > python -m review But Brian said using Rietveld at all is not a good idea, and didn't want to answer what should be done for it to become good idea. Probably Brian is too busy, that's why I'd like to ask people here. What do you need or expect to happen to start using code review in Python workflow? == Intro == Small introduction for insiders not familiar with outsider's problem of maintaining patches in tracker. Please forgive the tone I write about things I dislike, but I am not devoting my life to earn a title of polite bastard (this one is obligatory disclaimer I find it still doesn't work for all people, so expect some irrelevant flame in follow-ups). Ok, for an outsider like me "svn diff" 'best practice' suxx greatly, because in non-ideal conditions (and it is about 90% of cases) patches are often needed to be edited, and reuploaded. There are usually too few insiders to review you patch, and they are usually too busy to edit a small typo, and they also deny that they need an online tool to see if patch applies clearly, so if your patch doesn't apply clearly you will be asked to check where the problem is. The "svn diff" upload story continues time after time. The problem of too few insiders is that there are too few of them, and in case your patch is somehow complicated it can enjoy some years of loneliness. During this time not only the code can change, but the codebase itself can move to some other place. Some of the few are devoting great time to review new contributions and everything could be fine, but.. there is still a big time lapse, big enough that your patches start to overlap.. Trying to get out of this maintenance nightmare you will start learning Mercurial, then Mercurial Queues, then you go some weeks practicing or.. you will just give up right away, because time is more valuable than money. If you're an insider, you can propose to review patches in ViewVC, but it is just plain wrong. Just because. Just because there are tools that do the job better. Even if they have awful usability interface. That can be improved though. By stealing templates from Gerrit. == How Rietveld helps to save time == Assuming that Python has "easy_install" packaging solution bundled by default (which it doesn't of course): > python -m easy_install review This is run once to install the Rietveld script that is used from command like like: > python -m review and allows you to: 1. Create issue for patch review on Rietveld site 2. Run "svn diff" 3. Upload the patch 4. Supply comment for the patch everything above in one step. To upload an updated patch, you just do: > python -m review -i X -m "log of fixes made in comparison with previous > patch" Everybody can go to Rietveld site to view either patch or the whole file code _with_ the patch. Everybody can add comments _directly_ near patch lines. Everybody receives notifications about new code review comments. As code comments are hard to keep offtopic, the signal to noise ration appears to be is quite high. The patch upload script is designed in a way that every project can tune it for their needs and place into the root of source code. "review" project at PyPI.is uploaded from source at http://bitbucket.org/techtonik/pypi-rietveld - it can be tuned to address needs specific for Python development. What do you need to start using code review for contributed Python patches? Why you wouldn't recommend this practice to outsiders? -- anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: Readability of hex strings (Was: Use of coding cookie in 3.x stdlib)
Don't you think it is a bad idea to require people to subscribe to post to python-ideas of redirected there? -- anatoly t. -- Forwarded message -- From: Date: Mon, Jul 26, 2010 at 11:24 PM Subject: Re: [Python-Dev] Readability of hex strings (Was: Use of coding cookie in 3.x stdlib) To: [email protected] You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at [email protected]. -- Forwarded message -- From: anatoly techtonik To: Alexandre Vassalotti Date: Mon, 26 Jul 2010 23:24:15 +0300 Subject: Re: [Python-Dev] Readability of hex strings (Was: Use of coding cookie in 3.x stdlib) On Mon, Jul 26, 2010 at 9:42 PM, Alexandre Vassalotti wrote: > [+Python-ideas -Python-Dev] > > import binascii > def h(s): > return binascii.unhexlify("".join(s.split())) > > h("DE AD BE EF CA FE BA BE") The idea is to make "print f.read(50)" usable. Your current solution is: -Beautiful is better than ugly. -Explicit is better than implicit. -Simple is better than complex. Complex is better than complicated. Flat is better than nested. -Sparse is better than dense. -Readability counts. Special cases aren't special enough to break the rules. -Although practicality beats purity. Errors should never pass silently. ... -- anatoly t. > -- Alexandre > > On Mon, Jul 26, 2010 at 11:29 AM, anatoly techtonik > wrote: >> I find "\xXX\xXX\xXX\xXX..." notation for binary data totally >> unreadable. Everybody who uses and analyses binary data is more >> familiar with plain hex dumps in the form of "XX XX XX XX...". >> >> I wonder if it is possible to introduce an effective binary string >> type that will be represented as h"XX XX XX" in language syntax? It >> will be much easier to analyze printed binary data and copy/paste such >> data as-is from hex editors/views. >> >> On Mon, Jul 19, 2010 at 9:45 AM, Guido van Rossum wrote: >>> Sounds like a good idea to try to remove redundant cookies *and* to >>> remove most occasional use of non-ASCII characters outside comments >>> (except for unittests specifically trying to test Unicode features). >>> Personally I would use \xXX escapes instead of spelling out the >>> characters in shlex.py, for example. >>> >>> Both with or without the coding cookies, many ways of displaying text >>> files garble characters outside the ASCII range, so it's better to >>> stick to ASCII as much as possible. >>> >>> --Guido >>> >>> On Mon, Jul 19, 2010 at 1:21 AM, Alexander Belopolsky >>> wrote: I was looking at the inspect module and noticed that it's source starts with "# -*- coding: iso-8859-1 -*-". I have checked and there are no non-ascii characters in the file. There are several other modules that still use the cookie: Lib/ast.py:# -*- coding: utf-8 -*- Lib/getopt.py:# -*- coding: utf-8 -*- Lib/inspect.py:# -*- coding: iso-8859-1 -*- Lib/pydoc.py:# -*- coding: latin-1 -*- Lib/shlex.py:# -*- coding: iso-8859-1 -*- Lib/encodings/punycode.py:# -*- coding: utf-8 -*- Lib/msilib/__init__.py:# -*- coding: utf-8 -*- Lib/sqlite3/__init__.py:#-*- coding: ISO-8859-1 -*- Lib/sqlite3/dbapi2.py:#-*- coding: ISO-8859-1 -*- Lib/test/bad_coding.py:# -*- coding: uft-8 -*- Lib/test/badsyntax_3131.py:# -*- coding: utf-8 -*- I understand that coding: utf-8 is strictly redundant in 3.x. There are cases such as Lib/shlex.py where using encoding other than utf-8 is justified. (See http://svn.python.org/view?view=rev&revision=82560). What are the guidelines for other cases? Should redundant cookies be removed? Since not all editors respect the -*- cookie, I think the answer should be "yes" particularly when the cookie is setting encoding other than utf-8. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org >>> >>> >>> >>> -- >>> --Guido van Rossum (python.org/~guido) >>> ___ >>> Python-Dev mailing list >>> [email protected] >>> http://mail.python.org/mailman/listinfo/python-dev >>> Unsubscribe: >>> http://mail.python.org/mailman/options/python-dev/techtonik%40gmail.com >>> >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/alexandre%40peadrop.com >> > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-ar
Re: [Python-Dev] Define a place for code review in Python workflow
On Mon, Jul 26, 2010 at 15:18, anatoly techtonik wrote: > http://bugs.python.org/issue9376 > This issue discussed docs on the proper way to create diff on windows > (as it is doesn't have the tool) for sending the patch. The current > proper way is to use "svn diff" which will be replaced with "hg diff". > > I proposed using Rietveld like: > > python -m easy_install review > > python -m review > > But Brian said using Rietveld at all is not a good idea, and didn't > want to answer what should be done for it to become good idea. > -- > anatoly t. This is not at all what I said. I do not think it is a good idea to make subtle changes to the dev FAQ to replace patch submission with Rietveld, like you had suggested. Comments on the issue tracker are not the place to debate/suggest/discuss changes in development workflow. My second sentence in that comment even says that I think Rietveld will be used in the future (hopefully sooner than later). ___ Python-Dev mailing list [email protected] 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
FWIW, a leading magazine (IEEE Spectrum) this week has an interesting opinion piece about multicore. http://spectrum.ieee.org/computing/software/the-trouble-with-multicore -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Define a place for code review in Python workflow
On Mon, 26 Jul 2010 23:18:05 +0300, anatoly techtonik wrote: > > python -m review > > and allows you to: > > 1. Create issue for patch review on Rietveld site > 2. Run "svn diff" > 3. Upload the patch > 4. Supply comment for the patch > > everything above in one step. To upload an updated patch, you just do: > > > python -m review -i X -m "log of fixes made in comparison with previous > > patch" > > Everybody can go to Rietveld site to view either patch or the whole > file code _with_ the patch. Everybody can add comments _directly_ near > patch lines. > Everybody receives notifications about new code review comments. We do use rietveld for reviews, though (so far) not usually for small patches. That could change. So: 1) write the tool 2) upload it to pypi 3) see to what extent it gets adopted. There's nothing in your proposal that is outside of your control, as far as I can tell. (Well, except for easy_install not being in the stdlib, but that's no barrier to adoption of the proposed tool.) -- R. David Murray www.bitdance.com ___ Python-Dev mailing list [email protected] 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
Am 26.07.2010 13:02, schrieb Tarek Ziadé: > On Sat, Jul 24, 2010 at 4:08 PM, Guido van Rossum wrote: > [...] >> - 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 Q&A (http://bit.ly/bdflqa) I think not enough people are >> aware of what we are already doing in this area. > > Even people very involved in packaging are not fully aware of what's > going on. I am not for instance. > I think that we lack to communicate and synchronize on our efforts on > the PyPI development. Basically, I think what you'd like to have is Martin saying "I'm going to work on this feature", in addition to "I implemented this feature now" afterwards. That shouldn't be too hard. On related news, PyPI now has a JSONRPC interface. I'll leave it to you to figure out how to use it, and that it wasn't Martin who added it in secret ;) > The last example I have in mind is that I have announced here that I > was working on a patch for > the checkbox problem, then Martin announced today on catalog-sig it > was fixed by Georg and > updated in production :) I'd like to add to this that Martin didn't know I was working on the patch (I wrote the patch on the day after I came home from EP), and having worked a bit in the PyPI codebase during the sprints, I just decided to fix this issue, which I had perceived to be quite urgent to some people. (Also, the patch really wasn't a huge thing.) > I think we need to improve this: it can be a very frustrating > experience to contribute to PyPI. I did not experience it this way. On the contrary, I tried to run PyPI locally for testing purposes, but didn't want to compile and run Postgres, so we figured how hard it was to use Sqlite instead. Martin put in quite an effort to make it possible to have a local instance run with an sqlite db, and I could sprint productively on PyPI. > Possible improvements: > > - Have a PyPI component at bugs.python.org so all work on bugs/new > features would be known and > followed by at the same level than other packaging components we > maintain, and that depend on PyPI > (distutils, distutils2) -- e.g. drop the sourceforge tracker I wouldn't do that -- PyPI is not distributed with Python. (I'm equally skeptical about Distutils2, but it will at least be part of Python at some point in the future.) I would support a move to a separate bugs.python.org/pypi tracker, however. Not having to deal with SourceForge is still a good thing. > - Make it easier to contribute by moving the PyPI code base to > hg.python.org. Unlike Python, this is > a very simple move. +1 to that. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] View tracker patches with ViewVC?
Am 26.07.2010 14:41, schrieb Nick Coghlan: > On Mon, Jul 26, 2010 at 10:35 AM, "Martin v. Löwis" > wrote: >> Am 26.07.2010 02:24, schrieb Terry Reedy: >>> To review a patch on the tracker, I have to read and try to make sense >>> of the raw diff file. Sometimes that is easy, sometimes not. >>> >>> *After* a patch is applied, I can click the rev link and then the >>> 'text changed' link and see a nice, colored, side-by-side web-pace view >>> created by ViewVC. Is there any way a 'view' button could be added, >>> along with the current edit and remove buttons, to produce the same web >>> page and make it easier to review patches *before* commitment? >> >> You should be using Rietveld for that. > > And I believe there's already an item in the meta-tracker about > improving the integration between bugs.python.org and Rietveld - it > just doesn't exist yet. Sounds like something Ezio could easily do -- adapt Rietveld's upload.py to a Roundup extension that submits attachments as patches, adds people on nosy to Rietveld CC, &c. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Readability of hex strings (Was: Use of coding cookie in 3.x stdlib)
Am 26.07.2010 20:42, schrieb Alexandre Vassalotti:
> [+Python-ideas -Python-Dev]
>
> import binascii
> def h(s):
> return binascii.unhexlify("".join(s.split()))
>
> h("DE AD BE EF CA FE BA BE")
In Py3k:
h = bytes.fromhex
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Readability of hex strings (Was: Use of coding cookie in 3.x stdlib)
Am 26.07.2010 22:28, schrieb anatoly techtonik: > Don't you think it is a bad idea to require people to subscribe to > post to python-ideas of redirected there? It doesn't matter *why* you post to a mailing list -- you just have to be subscribed to post. Whoever redirects you there is usually not in the position of automatically subscribing anyone, and most people wouldn't much like being subscribed automatically, don't you think? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] 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 writes: > > Do you have concrete examples? Without that it's just speculation I can't do > much to address. Is the problem big or small? Easy to work around or not? Some of the things that need to be adapted are e.g. Makefiles (basically anything that assumes modules have a certain name), all of the freezers (cxFreeze, py2exe, ...). The biggest problem probably will be that an import will load the wrong module or no module at all. I'm just speculating here... > "Change is bad" isn't a constructive argument. ;) Did I make that argument? > > That's fine, but it's not the way Debian/Ubuntu works today. PEP 3149 > adoption will definitely remove significant complication for deploying > multiple Python versions at the same time on those systems. You're just moving that complication into python. - Ralf ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Define a place for code review in Python workflow
Am 26.07.2010 22:18, schrieb anatoly techtonik: > Small introduction for insiders not familiar with outsider's problem > of maintaining patches in tracker. Please forgive the tone I write > about things I dislike, but I am not devoting my life to earn a title > of polite bastard (this one is obligatory disclaimer I find it still > doesn't work for all people, so expect some irrelevant flame in > follow-ups). Nice! I wish we'd all do this. We'd have so much more time to do actual work. > As code comments are hard to keep offtopic, the signal to noise ration > appears to be is quite high. > The patch upload script is designed in a way that every project can > tune it for their needs and place into the root of source code. > "review" project at PyPI.is uploaded from source at > http://bitbucket.org/techtonik/pypi-rietveld - it can be tuned to > address needs specific for Python development. > > > What do you need to start using code review for contributed Python patches? > Why you wouldn't recommend this practice to outsiders? I'd welcome any patch submitted to Rietveld for review. However, your proposed "review.py" module does not exist as far as I know, and unless someone writes it, it won't. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] 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 Mon, Jul 26, 2010 at 10:39 PM, Georg Brandl wrote: ... >> I think we need to improve this: it can be a very frustrating >> experience to contribute to PyPI. > > I did not experience it this way. On the contrary, I tried to run > PyPI locally for testing purposes, but didn't want to compile and > run Postgres, so we figured how hard it was to use Sqlite instead. > Martin put in quite an effort to make it possible to have a local > instance run with an sqlite db, and I could sprint productively on > PyPI. I wasn't talking about the technical gap. This is improving all the time (I've improved the quick wsgi launching script so we could use it without dependencies instance). I am talking about synchronization and communication e.g. the project management. For instance, You didn't know that I have started this patch, and Martin didn't know that you started on your side. :-) > >> Possible improvements: >> >> - Have a PyPI component at bugs.python.org so all work on bugs/new >> features would be known and >> followed by at the same level than other packaging components we >> maintain, and that depend on PyPI >> (distutils, distutils2) -- e.g. drop the sourceforge tracker > > I wouldn't do that -- PyPI is not distributed with Python. (I'm > equally skeptical about Distutils2, but it will at least be part > of Python at some point in the future.) > > I would support a move to a separate bugs.python.org/pypi tracker, > however. Not having to deal with SourceForge is still a good thing. My PoV is that PyPI is part of the Python ecosystem we provide. The other part is currently in Python (distutils) and can be impacted by changes. The checkbox for instance, is one atomic change across Python and PyPI, But another roundup issue would be a progress already. >> - Make it easier to contribute by moving the PyPI code base to >> hg.python.org. Unlike Python, this is >> a very simple move. > > +1 to that. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Set the namespace free!
Am 26.07.2010 10:59, schrieb Anders Sandvig: > On Sat, Jul 24, 2010 at 3:31 AM, Gregory P. Smith wrote: >> Yuck. Anyone who feels they need a variable named the same a reserved word >> simply feels wrong and needs reeducation. [...] > > While I agree with you in principle, I have been finding it > frustrating trying to calculate yield in my financial applications > lately... ;) In the spirit of optimistic programming, why not assume a large one and call it Yield? ;) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New regex module for 3.2?
Am 22.07.2010 12:53, schrieb Guido van Rossum: > On Fri, Jul 16, 2010 at 6:08 PM, Georg Brandl wrote: >> Nevertheless, the authoritative reference for our regex engine is its >> docs, i.e. http://docs.python.org/library/re.html -- and that states >> clearly that inline flags apply to the whole regex. >> >>> I think with a new regex implementation, not all of this "historical" >>> semantics must be copied, unless there are major real usecases, which >>> would be affected by this. >> >> As I already said, I *have* seen this in real code. As MRAB indicated, >> this was the only silent change in semantics as compared to the old >> regex engine. If we replace re by regex, which I think is the only >> way to get the new features in the stdlib, changing this one aspect is >> a) not backwards compatible and b) in a subtle way that forces everyone >> to review his/her regular expressions. That's definitely not >> acceptable. > > I wonder if the solution could be a new flag that you have to specify > if you want the flags to apply locally only. Let's say add 'L' to the > flags. Then for existing code (not using 'L') the flags should apply > globally, while someone wanting flags to apply to only part of a regex > can add 'L' to the flags syntax. > > Is that acceptable? I guess it would be; however it remains to be proven that this scoping is actually needed in addition to the (backwards compatible) grouped scoping. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] :program: markup in .rst documentation
Am 20.07.2010 19:32, schrieb Fred Drake: > Switching to "python -m" is generally good where it applies (as in this case). > > The original intent for :option: and :program: were in their use as > references rather than in sample command lines. > > Georg should be the final arbiter, but I'd be in favor of ``...`` for > command lines. Agreed. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] 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
Am 26.07.2010 23:03, schrieb Tarek Ziadé: > On Mon, Jul 26, 2010 at 10:39 PM, Georg Brandl wrote: > >>> I think we need to improve this: it can be a very frustrating >>> experience to contribute to PyPI. >> >> I did not experience it this way. On the contrary, I tried to run >> PyPI locally for testing purposes, but didn't want to compile and >> run Postgres, so we figured how hard it was to use Sqlite instead. >> Martin put in quite an effort to make it possible to have a local >> instance run with an sqlite db, and I could sprint productively on >> PyPI. > > I wasn't talking about the technical gap. This is improving all the time > (I've improved the quick wsgi launching script so we could use it > without dependencies instance). > > I am talking about synchronization and communication e.g. the project > management. > > For instance, You didn't know that I have started this patch, and > Martin didn't know > that you started on your side. :-) This isn't specific to PyPI though. I usually don't announce "I'm going to work on this issue" for a specific Python tracker item, except if I expect it to take more than a few hours. The patch in question is really pretty minor. >>> Possible improvements: >>> >>> - Have a PyPI component at bugs.python.org so all work on bugs/new >>> features would be known and >>> followed by at the same level than other packaging components we >>> maintain, and that depend on PyPI >>> (distutils, distutils2) -- e.g. drop the sourceforge tracker >> >> I wouldn't do that -- PyPI is not distributed with Python. (I'm >> equally skeptical about Distutils2, but it will at least be part >> of Python at some point in the future.) >> >> I would support a move to a separate bugs.python.org/pypi tracker, >> however. Not having to deal with SourceForge is still a good thing. > > My PoV is that PyPI is part of the Python ecosystem we provide. > The other part is currently in Python (distutils) and can be impacted > by changes. > The checkbox for instance, is one atomic change across Python and PyPI, Sure PyPI is part of the ecosystem. But so are quite a lot of other tools, and none of them are tracked in bugs.python.org. (This is also the case for the website.) I'd really like bugs.python.org to remain a tracker for what we ship as the CPython distribution, and nothing else. There's enough content in there already. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IDLE contributors and committers
Am 19.07.2010 04:22, schrieb Terry Reedy: > On 7/18/2010 7:42 PM, Georg Brandl wrote: > >> That phrasing implies that there is purpose behind letting issues rot. >> Believe me that this is not the case. > > This seems like a good place to mention that doc issues have become a > bright spot in the last few years, with a couple of days turnaround not > unusual for an issue ready for commit review. This is one reason I have > focused a bit on doc issues. It is rewarding. Because it's usually easier to review a doc patch -- you don't have to consider backwards compatibility implications :) > As I remember, a reason to switch from latex to sphinx/rst was so that > more people could/would work on doc issues. That seems to have worked. > And I do not think it bad is the docs catch up to the code by getting > extra attention. Yep, especially in Py3k where some changes were not really given enough docs love. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] View tracker patches with ViewVC?
> Sounds like something Ezio could easily do -- adapt Rietveld's upload.py > to a Roundup extension that submits attachments as patches, adds people > on nosy to Rietveld CC, &c. That may not be so easy - you'll have to authenticate to Rietveld from Roundup. The other way 'round actually works: if you put [email protected] into the reviewer list when uploading to Rietveld, Rietveld changes get automatically posted to the tracker. If you then also chose a sensible title (ie. one that includes [issueXXX]), Roundup will be able to associate it with the right issue. Regards, Martin ___ Python-Dev mailing list [email protected] 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 Mon, Jul 26, 2010 at 11:15 PM, Georg Brandl wrote: .. > Sure PyPI is part of the ecosystem. But so are quite a lot of other tools, > and none of them are tracked in bugs.python.org. (This is also the case > for the website.) I'd really like bugs.python.org to remain a tracker for > what we ship as the CPython distribution, and nothing else. There's enough > content in there already. PyPI is the only tool that gets called from Python AFAIK. ___ Python-Dev mailing list [email protected] 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
> Basically, I think what you'd like to have is Martin saying "I'm going to > work on this feature", in addition to "I implemented this feature now" > afterwards. That shouldn't be too hard. I'm not very good at blogging (more specifically, I never blog). People interested in following even the tinyest changes to PyPI should watch the commit list; it is unlikely that I will post each and every change to catalog-sig. People are then free to blog about the changes as they please (and I would appreciate any help I can get in announcing changes). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] marking os.system() as deprecated in the docs
> On Sun, Jul 25, 2010 at 11:42 PM, Chris Rebert wrote: >> Hello, >> >> I'd like to propose formally marking os.system() as deprecated in the >> docs for next release of Python (v3.2 ?). >> >> The docs for os.system() /already/ include the following paragraph, >> which is basically tantamount to calling system() deprecated and very >> much resembles the deprecation notes for the os.popen*() family. >> """ >> The subprocess module provides more powerful facilities for spawning >> new processes and retrieving their results; using that module is >> preferable to using this function. Use the subprocess module. Check >> especially the Replacing Older Functions with the subprocess Module >> section. >> """ Emphasizing the following paragraph from my original email: >> I'm merely suggesting slapping a formal ".. deprecated::" tag & box >> around this paragraph to make system()'s status more obvious. I am >> ***not*** suggesting the function be scheduled for removal or anything >> like that. >> >> I figure since this would be a substantive change (the docs currently >> don't outright say "deprecated"), it would need dev approval, hence >> this message. I've already written the absolutely /trivial/ docs >> patch. >> >> So, any objections? On Mon, Jul 26, 2010 at 7:29 AM, Guido van Rossum wrote: > Unless, it's as simple as replacing "os.system(x)" with > "subprocess.system(x)", I'm against this removal of a handy shorthand. [Addressing Steven's reply as well] In hindsight, I should have used a word other than "deprecate" (despite no longer matching the Sphinx directive) that's not overloaded with Python baggage about removal; I intended it here in its plain English meaning of merely "to express disapproval of" or "to play down". Allow me to reiterate: I am *NOT* suggesting os.system() be removed or prepared for removal. I'm only suggesting the docs be /slightly/ tweaked to make it /slightly/ more obvious that os.system() is dispreferred over the subprocess module. Removing os.system() would have backward compatibility and cross-language API problems; I agree it would be a bad idea; which is why I'm not proposing that. > Ditto for popen. Funny you should bring up os.popen(). Its docs are currently MIA in 3.x, for unclear reasons: http://bugs.python.org/issue9382 Cheers, Chris > -- > --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] 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 Mon, Jul 26, 2010 at 11:57 PM, "Martin v. Löwis" wrote: >> Basically, I think what you'd like to have is Martin saying "I'm going to >> work on this feature", in addition to "I implemented this feature now" >> afterwards. That shouldn't be too hard. > > I'm not very good at blogging (more specifically, I never blog). > > People interested in following even the tinyest changes to PyPI should > watch the commit list; it is unlikely that I will post each and every > change to catalog-sig. > > People are then free to blog about the changes as they please (and I > would appreciate any help I can get in announcing changes). I think what would be good is to have you discussing the "I'm going to work on this feature" at the ML before it's started. And not discovering it randomly at PyPI or the commit list, leading to a heated discussion or a poll. I would classify the changes in three kinds: - minor: a new feature, a UI bugfix etc - important: a new feature that changes a lot the end-user experience (like the rating system) - major: a change to the APIs (HTTP/XML-RPC) I think you should briefly present your plans for important or major changes in catalog-SIG prior to starting them, so we can discuss them. Regards Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Readability of hex strings (Was: Use of coding cookie in 3.x stdlib)
On Tue, 27 Jul 2010 04:29:31 am anatoly techtonik wrote: > I find "\xXX\xXX\xXX\xXX..." notation for binary data totally > unreadable. Everybody who uses and analyses binary data is more > familiar with plain hex dumps in the form of "XX XX XX XX...". > > I wonder if it is possible to introduce an effective binary string > type that will be represented as h"XX XX XX" in language syntax? It > will be much easier to analyze printed binary data and copy/paste > such data as-is from hex editors/views. With the moratorium on new language features, this would not even be considered until Python 3.3. If you are serious in pursuing this idea, it is off-topic for this list and should be taken to python-ideas, or even python-list for community feedback, first. Since it only takes a pair of small helper functions to convert hex dumps in the form " ..." to and from byte strings, I don't see the need for new syntax and would vote -1 on the idea. However, I'd vote +0 on a matching bytes.tohex() method to partner with the existing bytes.fromhex(). -- Steven D'Aprano ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Do any of the 4 multiprocessing methods work using shared memory?
Brief Summary: Can I share Python objects between multiple processes using shared memory (using the multiprocessing module)? In particular, do Queues or Pipes work using shared memory? Details: * I have several processes each on a separate CPU core (so they run in parallel). * I want to share certain Python objects between the processes using shared memory (I can handle the locking myself -- only one process can access a variable or object at a time, so there is no conflict anyways). * I strongly prefer that it be shared memory because I do not want to incur the costs of having to copy data back and forth between the processes. I am aware of the multiprocessing module. It offers: Queues Pipes Shared Memory Map Server Process So, let me ask a few questions about those 4 items: Queues & Pipes These handle Python objects and variables However, my question is do they use shared memory or do they require copying the data or some other method that is more costly than shared memory? Shared Memory Map Does not support Python objects or variables -- thus no good to me. Server Process Looks like it requires another process that incurs extra processing just to handle the data exchange -- which, if true, is bad for me. Does this use shared memory? or does it require copying data back and forth between processes? _ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: Readability of hex strings (Was: Use of coding cookie in 3.x stdlib)
anatoly techtonik writes: > Don't you think it is a bad idea to require people to subscribe to > post to python-ideas of redirected there? No, it's an excellent compromise in the current environment. On lists I manage (with a similar audience to python-dev), my MTA-level filters get 95% of the spam, the member test catches essentially all of the rest. On support lists, I moderate, mostly because drive-by posters usually post in HTML which is another 95% accurate signal of spam. On the dev lists, they get rejected on the principle that drive-by posts to a dev list *are* spam. If you want to post a quick RFE, that's what the tracker is for; people will see your brainstorm when they get around to looking at the tracker, but it just isn't urgent at all. This works well, yours is the first complaint about this kind of policy that I've seen in four or five years. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Set the namespace free!
Georg Brandl writes: > Am 26.07.2010 10:59, schrieb Anders Sandvig: > > On Sat, Jul 24, 2010 at 3:31 AM, Gregory P. Smith wrote: > >> Yuck. Anyone who feels they need a variable named the same a reserved > >> word > >> simply feels wrong and needs reeducation. [...] > > > > While I agree with you in principle, I have been finding it > > frustrating trying to calculate yield in my financial applications > > lately... ;) > > In the spirit of optimistic programming, why not assume a large one > and call it Yield? ;) That's certainly more workable than the obvious near-synonym, "return". ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] View tracker patches with ViewVC?
On 7/25/2010 8:35 PM, "Martin v. Löwis" wrote: Am 26.07.2010 02:24, schrieb Terry Reedy: To review a patch on the tracker, I have to read and try to make sense of the raw diff file. Sometimes that is easy, sometimes not. *After* a patch is applied, I can click the rev link and then the 'text changed' link and see a nice, colored, side-by-side web-pace view created by ViewVC. Is there any way a 'view' button could be added, along with the current edit and remove buttons, to produce the same web page and make it easier to review patches *before* commitment? You should be using Rietveld for that. There is no mention of Rietveld in the tracker docs that I could fine. Did I miss something? That fact that one needs to go to http://codereview.appspot.com/ rather than the rietveld page was not immediately obvious from 'use Rietveld'. > That may not be so easy - you'll have to authenticate to Rietveld from > Roundup. This is why I suggested ViewVC -- it already is at python.org and could potentially be directly accessed with a button. > The other way 'round actually works: if you put [email protected] > into the reviewer list when uploading to Rietveld, Rietveld changes > get automatically posted to the tracker. If you then also chose a > sensible title (ie. one that includes [issueXXX]), Roundup will be able > to associate it with the right issue. These are less obvious. Here is what I have gathered so far. Open patch in browser tab to get its url. Go to http://codereview.appspot.com/ Login in with Google account Go to Create issue form Copy and paste url into url field To get comments mailed back to tracker, put Issue in title and put [email protected] in reviewer list Should I open a tracker issue to add something to the tracker doc? -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] 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/26/2010 5:15 PM, Georg Brandl wrote: Sure PyPI is part of the ecosystem. But so are quite a lot of other tools, and none of them are tracked in bugs.python.org. (This is also the case for the website.) I'd really like bugs.python.org to remain a tracker for what we ship as the CPython distribution, and nothing else. There's enough content in there already. How about one other tracker, say bugs.python/org/tools (or projects, or ???) for everything else: pypi, distribute2 (until part of release), web site, sandbox projects? It would have to be taught how to turn rev + component into a link to the appropriate repository. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Do any of the 4 multiprocessing methods work using shared memory?
On 7/26/2010 8:20 PM, Kevin Ar18 wrote: Questions about the operation and use current python belong on python-list, mirrored on gmane.comp.python.general. This list pydev == g.c.p.devel is for the development of future versions. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] 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:44 PM, Nick Coghlan wrote: 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). I was able to implement this without too much trouble. I also changed it so -b and -p switches can be used together to override the automatic port selection. The default is port 0. I think idle uses automatic port selection now also. Does it have a way to select a specific port? Is the -p option needed with automatic port selection. I added a command prompt like the help> prompt. Here's what starting the server, opening a browser, and then stopping the server looks like. r...@gutsy:/media/hda2/home/ra/svn/py3k$ ./python -m pydoc -p 0 Server ready at: http://localhost:50279/ Server commands: [b]rowser, [q]uit server>b server>q Server stopped [83680 refs] r...@gutsy:/media/hda2/home/ra/svn/py3k$ I can add a [h]elp to get a longer help, but I'm not sure it's needed. I want to have a [r]eport command to list the server requests since the last report command was given. Sort of like a log. It may be useful to find problems with what the server is sending and what the browser is requesting. Should the server have a timeout in case the command window is not reachable? If so, how long? cheers, Ron ___ Python-Dev mailing list [email protected] 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
> I would classify the changes in three kinds: > > - minor: a new feature, a UI bugfix etc > - important: a new feature that changes a lot the end-user experience > (like the rating system) > - major: a change to the APIs (HTTP/XML-RPC) > > I think you should briefly present your plans for important or major > changes in catalog-SIG > prior to starting them, so we can discuss them. So would you consider the addition of JSON a major feature (as it introduces a new API)? I doubt Richard would have been willing to wait for the end of some discussion before implementing it. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New regex module for 3.2?
On Thu, Jul 22, 2010 at 3:26 PM, Nick Coghlan wrote: > On Fri, Jul 23, 2010 at 12:42 AM, Georg Brandl wrote: > > Sure -- I don't think this is a showstopper for regex. However if we > don't > > include regex in a future version, we might think about increasing > MAXCACHE > > a bit, and maybe not clear the cache when it reaches its max length, but > > rather remove another element. > > Yikes, I didn't know it did that. That certainly sounds like it should > be an RFE in its own right - some basic form of Least Recently Used > accounting should be beneficial (although the extra bookkeeping might > hurt scripts that aren't hitting the cache limit). > > A max cache size of 100 was too small. I just increased it to 500 in the py3k branch along with implementing a random replacement cache overflow policy. It now randomly drops 20% of the compiled regular expression cache instead of simply dropping the entire cache on overflow. With the regex_v8 benchmark, the better cache replacement policy sped it up ~7% while raising the cache size on top of that (likely meaning the cache was never overflowing) sped it up ~25%. Random replacement without dropping everything at least means apps thrashing the cache degrade much more gracefully. http://svn.python.org/view?view=rev&revision=83173 This change should be incorporated into MRAB's regex module in order to keep comparisons fair. -gps ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] View tracker patches with ViewVC?
> Should I open a tracker issue to add something to the tracker doc? I recommend that you use it for some time before changing anything. I also suggest that, instead of uploading the patch to Rietveld yourself, you can ask the submitter to do it. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] marking os.system() as deprecated in the docs
Guido van Rossum wrote: Unless, it's as simple as replacing "os.system(x)" with "subprocess.system(x)", I'm against this removal of a handy shorthand. Also, seeing as it's a well-known C library facility, and Python likes to provide thin wrappers around the C library wherever reasonable, its lack would seem a bit odd. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New regex module for 3.2?
Gregory P. Smith, 27.07.2010 07:40: A max cache size of 100 was too small. I just increased it to 500 in the py3k branch along with implementing a random replacement cache overflow policy. It now randomly drops 20% of the compiled regular expression cache instead of simply dropping the entire cache on overflow. With the regex_v8 benchmark, the better cache replacement policy sped it up ~7% while raising the cache size on top of that (likely meaning the cache was never overflowing) sped it up ~25%. Random replacement without dropping everything at least means apps thrashing the cache degrade much more gracefully. The same algorithm should be helpful in ElementTree's ElementPath module. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
