From ethan at stoneleaf.us Tue Feb 1 00:10:06 2011 From: ethan at stoneleaf.us (Ethan Furman) Date: Mon, 31 Jan 2011 15:10:06 -0800 Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows In-Reply-To: References: <4D431724.4010002@voidspace.org.uk> <7DA37C12-D3DA-49B3-996A-017CF304BC5C@gmail.com> Message-ID: <4D47414E.5080602@stoneleaf.us> Brian Curtin wrote: > On Mon, Jan 31, 2011 at 15:43, anatoly techtonik > wrote: >> That's the easy part. It doesn't cover any of the real issues with doing >> this. > > Please be more specific. It will also help if you integrate this part > while it's still hot. > -- > anatoly t. > > > There are numerous comments in the various PATH-related issues on the > issue tracker, and many of them are duplicated in this very thread. Imagine that -- discussion and coordination on b.p.o.! ;) ~Ethan~ From ncoghlan at gmail.com Tue Feb 1 00:38:00 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Tue, 1 Feb 2011 09:38:00 +1000 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) In-Reply-To: References: <20cf30434772fe60a6049b2a7f9a@google.com> <4D4724FC.1040705@stoneleaf.us> Message-ID: On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik wrote: > To me polluting tracker with the > issues that are neither bugs nor feature requests only makes bug > triaging process and search more cumbersome. Anatoly, your constant efforts to try to force python-dev to adapt to *your* way of doing things, instead of being willing to work with the documented processes are *seriously* annoying. Which is a shame, since it obscures the fact that your underlying suggestions are often quite reasonable. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From martin at v.loewis.de Tue Feb 1 01:05:08 2011 From: martin at v.loewis.de (martin at v.loewis.de) Date: Tue, 01 Feb 2011 00:05:08 +0000 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) Message-ID: <0022152d655912c0d4049b2d4917@google.com> What's the rationale of this change? It certainly doesn't remove the dependency from win32com.client (i.e. the code continues to depend on win32com). http://codereview.appspot.com/4080047/ From martin at v.loewis.de Tue Feb 1 01:10:34 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Tue, 01 Feb 2011 01:10:34 +0100 Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows In-Reply-To: References: <4D431724.4010002@voidspace.org.uk> <7DA37C12-D3DA-49B3-996A-017CF304BC5C@gmail.com> Message-ID: <4D474F7A.2090800@v.loewis.de> Am 31.01.2011 22:13, schrieb anatoly techtonik: > Ok. Here is the patch. I used Orca to reverse installer tables of > Mercurial MSI and inserted similar entry for Python. This doesn't do uninstallation correctly. Regards, Martin From martin at v.loewis.de Tue Feb 1 01:24:47 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 01 Feb 2011 01:24:47 +0100 Subject: [Python-Dev] Mercurial style patch submission (Was: MSI: Remove dependency from win32com.client module (issue4080047)) In-Reply-To: References: Message-ID: <4D4752CF.3090902@v.loewis.de> >> If you don't want to receive a stupid answer, why don't you read the >> link and say what you don't like in this approach in a constructive >> manner? > > As I understand it, there used to be patches at python.org. I'm not sure > why this was discontinued, so perhaps someone more senior should chime > in. :) As a mailing list, it was unmaintainable, since there was no tracking of what patches still need consideration. So a web-based bug tracker got into use (although I forgot the name of the tracker software that was used before SourceForge). Regards, Martin From dirkjan at ochtman.nl Tue Feb 1 08:11:14 2011 From: dirkjan at ochtman.nl (Dirkjan Ochtman) Date: Tue, 1 Feb 2011 08:11:14 +0100 Subject: [Python-Dev] Mercurial style patch submission (Was: MSI: Remove dependency from win32com.client module (issue4080047)) In-Reply-To: References: Message-ID: On Mon, Jan 31, 2011 at 22:50, anatoly techtonik wrote: > If you don't want to receive a stupid answer, why don't you read the > link and say what you don't like in this approach in a constructive > manner? Mercurial is a much smaller project, so it has different needs. It would be nice if you could respect the process the developers on any project have laid out for their project and assume they know what works best for them. Cheers, Dirkjan From techtonik at gmail.com Tue Feb 1 08:22:58 2011 From: techtonik at gmail.com (techtonik at gmail.com) Date: Tue, 01 Feb 2011 07:22:58 +0000 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) Message-ID: <20cf305497e3db5c18049b336617@google.com> It removes the dependency from msi.py making it easier to do the rest in subsequent patches. http://codereview.appspot.com/4080047/ From techtonik at gmail.com Tue Feb 1 08:35:12 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Tue, 1 Feb 2011 09:35:12 +0200 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) In-Reply-To: References: <20cf30434772fe60a6049b2a7f9a@google.com> <4D4724FC.1040705@stoneleaf.us> Message-ID: On Tue, Feb 1, 2011 at 12:59 AM, Benjamin Peterson wrote: >>>> >>>> I see no reason for b.p.o bureaucracy. >>> >>> It provides a place for discussion, and makes it easier to coordinate >>> multiple efforts. >> >> Code review system provides a better space for discussion if we are >> speaking about simple code cleanup. To me polluting tracker with the >> issues that are neither bugs nor feature requests only makes bug >> triaging process and search more cumbersome. > > If it's not a bug or a feature request, why does it need to change? Because code cleanup patches pave road for more complex pieces of work. Clean code makes patches easier to review. It saves developer's time and as a result useful patches are integrated into codebase more quickly. -- anatoly t. From g.brandl at gmx.net Tue Feb 1 08:45:44 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Tue, 01 Feb 2011 08:45:44 +0100 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) In-Reply-To: References: <20cf30434772fe60a6049b2a7f9a@google.com> <4D4724FC.1040705@stoneleaf.us> Message-ID: Am 31.01.2011 22:58, schrieb anatoly techtonik: > On Mon, Jan 31, 2011 at 11:09 PM, Ethan Furman wrote: >> techtonik at gmail.com wrote: >>> >>> I see no reason for b.p.o bureaucracy. >> >> It provides a place for discussion, and makes it easier to coordinate >> multiple efforts. > > Code review system provides a better space for discussion if we are > speaking about simple code cleanup. To me polluting tracker with the > issues that are neither bugs nor feature requests only makes bug > triaging process and search more cumbersome. Note that while the domain may be "bugs.python.org" (because that is a traditional name used by many projects), it really is an *issue tracker*, and for us, all patches are issues that should be tracked there. A mailing list works only if you have a small group of core developers who can independently organize the incoming mails using local tools, such as the read/unread marking of the email client. For a larger group this doesn't work (how do you assign a patch to someone using a mailing list?). It sure is more convenient to do patch review, but that's why we are working on Rietveld integration in the tracker. Georg From g.brandl at gmx.net Tue Feb 1 08:49:00 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Tue, 01 Feb 2011 08:49:00 +0100 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) In-Reply-To: References: <20cf30434772fe60a6049b2a7f9a@google.com> Message-ID: Am 31.01.2011 23:05, schrieb anatoly techtonik: > On Mon, Jan 31, 2011 at 10:58 PM, Georg Brandl wrote: >> Am 31.01.2011 21:45, schrieb techtonik at gmail.com: >>> There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch >>> to clean up the code a bit while I am trying to understand how to add >>> Python to the PATH. >>> >>> I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is >>> more beneficial to development as it doesn't require switching from >>> console to browser for submitting changes. This way tiny changes can be >>> integrated/updated more rapidly. >> >> The tracker is not bureaucracy, it's how our development process works. > > Don't you want to improve this process? Code review system is a much > better place to review patches than mailing list or bug tracker. > Especially patches that are not related to actual bugs. If there are patches only on the code review system, others only on the issue tracker, and still others on both, people will get confused quickly. There needs to be a single canonical place to collect issues, and that needs to be the issue tracker (since bug reports cannot go anywhere else). I'm enthusiastic about anything that *improves* this process, but you're proposing to *change* it. >> I know that Mercurial uses a different process, with patches always going >> to the mailing list and being reviewed there, but that would be way too >> much volume for python-dev considering our number of patches. > > Seems reasonable. Do you have any stats how many patches are sent > weekly and how many of them are actually integrated? No, but you can have a look at the weekly "Summary of Python tracker issues" emails that are sent to this list by a script. Georg From ncoghlan at gmail.com Tue Feb 1 11:15:09 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Tue, 1 Feb 2011 20:15:09 +1000 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) In-Reply-To: References: <20cf30434772fe60a6049b2a7f9a@google.com> <4D4724FC.1040705@stoneleaf.us> Message-ID: On Tue, Feb 1, 2011 at 5:35 PM, anatoly techtonik wrote: > Because code cleanup patches pave road for more complex pieces of > work. Clean code makes patches easier to review. It saves developer's > time and as a result useful patches are integrated into codebase more > quickly. While I've occasionally wished for the ability to enter "clarification" as the issue type (especially for docs patches), simply leaving the issue type blank when none of the available categories fits has worked well enough as an alternative. If it helps, try to think of it as "this code isn't clear as it could be, which is a readability bug" Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From lukasz at langa.pl Tue Feb 1 11:22:57 2011 From: lukasz at langa.pl (=?UTF-8?B?xYF1a2FzeiBMYW5nYQ==?=) Date: Tue, 01 Feb 2011 11:22:57 +0100 Subject: [Python-Dev] Mercurial style patch submission (Was: MSI: Remove dependency from win32com.client module (issue4080047)) In-Reply-To: <4D4752CF.3090902@v.loewis.de> References: <4D4752CF.3090902@v.loewis.de> Message-ID: <4D47DF01.1070100@langa.pl> W dniu 2011-02-01 01:24, "Martin v. L?wis" pisze: > As a mailing list, it was unmaintainable, since there was no tracking > of what patches still need consideration. So a web-based bug tracker > got into use (although I forgot the name of the tracker software that > was used before SourceForge). JitterBug! Best regards, ?ukasz From brian.curtin at gmail.com Tue Feb 1 15:35:41 2011 From: brian.curtin at gmail.com (Brian Curtin) Date: Tue, 1 Feb 2011 08:35:41 -0600 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) In-Reply-To: References: <20cf30434772fe60a6049b2a7f9a@google.com> <4D4724FC.1040705@stoneleaf.us> Message-ID: On Tue, Feb 1, 2011 at 01:35, anatoly techtonik wrote: > On Tue, Feb 1, 2011 at 12:59 AM, Benjamin Peterson > wrote: > >>>> > >>>> I see no reason for b.p.o bureaucracy. > >>> > >>> It provides a place for discussion, and makes it easier to coordinate > >>> multiple efforts. > >> > >> Code review system provides a better space for discussion if we are > >> speaking about simple code cleanup. To me polluting tracker with the > >> issues that are neither bugs nor feature requests only makes bug > >> triaging process and search more cumbersome. > > > > If it's not a bug or a feature request, why does it need to change? > > Because code cleanup patches pave road for more complex pieces of > work. Clean code makes patches easier to review. It saves developer's > time and as a result useful patches are integrated into codebase more > quickly. > -- > anatoly t. Code cleanup patches, if you mean minor refactoring, are generally not where developer time is best spent. We could all come in and make 50 check-ins each of refactoring but the net benefit is even, if not negative. Yes, clean code is easier to work with, easier to review, etc., but keep in mind we're working with multiple branches that also need to be kept in sync. Refactoring some function in py3k should probably be replicated in release31-maint, and possibly release27-maint, otherwise patching between the branches becomes more time intensive. Adding time intensive work with no net gain is probably the last thing we want to do. -------------- next part -------------- An HTML attachment was scrubbed... URL: From techtonik at gmail.com Tue Feb 1 16:51:57 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Tue, 1 Feb 2011 17:51:57 +0200 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) In-Reply-To: References: <20cf30434772fe60a6049b2a7f9a@google.com> <4D4724FC.1040705@stoneleaf.us> Message-ID: On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan wrote: > On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik wrote: >> To me polluting tracker with the >> issues that are neither bugs nor feature requests only makes bug >> triaging process and search more cumbersome. > > Anatoly, your constant efforts to try to force python-dev to adapt to > *your* way of doing things, instead of being willing to work with the > documented processes are *seriously* annoying. Which is a shame, since > it obscures the fact that your underlying suggestions are often quite > reasonable. I'll abandon my efforts when you prove me that current "documented process" is a top-notch way for all interested parties to do a quality contributions to make Python better. So that the process is open, straightforward, transparent and doesn't waste people's time more than necessary to communicate a change, make it visible for all interested parties, get feedback, polish and finally integrate. There are many ways for improvement, but if people won't try alternative approaches, they won't see them. I am not sure if I can manage to get to PyCon, so I didn't do any talk preparation, but if by chance I get there and there will be an Open Space, we can definitely find a lot of ways to improve Python development process for general public. As well as discuss ways to get around stdlib graveyard and dealing with really complicated problems that won't budge over the years - like out of the box UTC support. The most valuable contributions are coming from professionals, and these people often don't have enough time to follow "documented process". In the era of information abundance you often have only 140 symbols to communicate the idea, and instead of blaming people of annoying behavior, it might be more useful to make process intuitive and easy to follow. If that's not possible, there should always be an exact link to a reasonable explanation about why you need the process to be so complicated. So far only Georg explained what patches sent to mailing list will not be reviewed, because there is too much volume. But bugtracker is not a patch tracker. It doesn't allow to monitor incoming patches by module, its search is very poor. Of course mailing lists are even worse in this regard, but there is nothing Python community can't deal with. The problem is to keep non-core people outside motivated, and the biggest problem with current "documented process" is that nobody even thinks about it. -- anatoly t. From amauryfa at gmail.com Tue Feb 1 17:07:26 2011 From: amauryfa at gmail.com (Amaury Forgeot d'Arc) Date: Tue, 1 Feb 2011 17:07:26 +0100 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) In-Reply-To: References: <20cf30434772fe60a6049b2a7f9a@google.com> <4D4724FC.1040705@stoneleaf.us> Message-ID: 2011/2/1 anatoly techtonik : > we can definitely > find a lot of ways to improve Python development process for general > public Definitely. And the future migration to Mercurial will certainly help as well. But this thread started with a patch review, not with a proposal to change the development process! For the moment, we use svn and the issue tracker. If every patch comes with its own workflow, no coordination is possible. -- Amaury Forgeot d'Arc From brian.curtin at gmail.com Tue Feb 1 17:20:40 2011 From: brian.curtin at gmail.com (Brian Curtin) Date: Tue, 1 Feb 2011 10:20:40 -0600 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) In-Reply-To: References: <20cf30434772fe60a6049b2a7f9a@google.com> <4D4724FC.1040705@stoneleaf.us> Message-ID: On Tue, Feb 1, 2011 at 09:51, anatoly techtonik wrote: > On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan wrote: > > On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik > wrote: > >> To me polluting tracker with the > >> issues that are neither bugs nor feature requests only makes bug > >> triaging process and search more cumbersome. > > > > Anatoly, your constant efforts to try to force python-dev to adapt to > > *your* way of doing things, instead of being willing to work with the > > documented processes are *seriously* annoying. Which is a shame, since > > it obscures the fact that your underlying suggestions are often quite > > reasonable. > > I'll abandon my efforts when you prove me that current "documented > process" is a top-notch way for all interested parties to do a quality > contributions to make Python better. So that the process is open, > straightforward, transparent and doesn't waste people's time more than > necessary to communicate a change, make it visible for all interested > parties, get feedback, polish and finally integrate. The burden of proof should not be on us to prove to you why we do things the way we do them. I'm not even sure you are familiar with the process that you want to change so badly. You do realize that no one else, from the people in Misc/developers.txt to the one-time patch submitters, has a monthly process gripe, correct? It's certainly working for a few of us. There are many ways for improvement, but if people won't try > alternative approaches, they won't see them. This is true of just about anything in the world, but I don't think it's a bad thing. We decided on something, it works, and we use it. I umpire college baseball in my free time and people like to propose tweaks to our on-field mechanics all the time because they think certain alternatives work better. To even get me to think about that stuff is a tall task because not only is my time on the job limited, my actual ability to practice these alternatives is more limited. I'll stick to what's in our book -- it works. > I am not sure if I can > manage to get to PyCon, so I didn't do any talk preparation, but if by > chance I get there and there will be an Open Space, we can definitely > find a lot of ways to improve Python development process for general > public. I could list a few ways to improve it as well. Do we need any of them to survive? No. > The most valuable contributions are coming from professionals, and > these people often don't have enough time to follow "documented > process". Sorry, but sometimes that's the cost of doing business. Just because the court system has a lengthy process for suing people doesn't mean you can skip to the end if you just want to get your money. You have to tell your story first. > In the era of information abundance you often have only 140 > symbols to communicate the idea, and instead of blaming people of > annoying behavior, it might be more useful to make process intuitive > and easy to follow. Thankfully Twitter is not our bug tracker. > If that's not possible, there should always be an > exact link to a reasonable explanation about why you need the process > to be so complicated. > There's a few things the process is, and complicated it is not. In most cases it is as simple as: report a bug, provide a failing test case, provide a complete patch, review the patch, commit the patch. To an outsider, they don't have to worry about the bug tracker fields, who's doing the commit, what branches it goes into, etc. Just write the code and it'll speak for itself. So far only Georg explained what patches sent to mailing list will not > be reviewed, because there is too much volume. But bugtracker is not a > patch tracker. Yes it is, or at least that is one of the functions it is currently serving. It doesn't allow to monitor incoming patches by module, > its search is very poor. Patches are certainly welcome if you want to make it happen. I think it would be a nice addition. -------------- next part -------------- An HTML attachment was scrubbed... URL: From techtonik at gmail.com Tue Feb 1 17:25:24 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Tue, 1 Feb 2011 18:25:24 +0200 Subject: [Python-Dev] Rietveld integration status (Was: MSI: Remove dependency from win32com.client module (issue4080047)) Message-ID: On Tue, Feb 1, 2011 at 9:45 AM, Georg Brandl wrote: > > A mailing list works only if you have a small group of core developers > who can independently organize the incoming mails using local tools, > such as the read/unread marking of the email client. ?For a larger > group this doesn't work (how do you assign a patch to someone using > a mailing list?). If you can filter patches by module (and it can be done automatically), then you won't need to assign patches. People can subscribe to interested parts and participate independently. > It sure is more convenient to do patch review, but > that's why we are working on Rietveld integration in the tracker. Where is the code? What is the status? Where is the roadmap, i.e. how can people help? Why can't you use hosted Rietveld instance if there are troubles to setup server properly? -- anatoly t. From hsoft at hardcoded.net Tue Feb 1 17:30:23 2011 From: hsoft at hardcoded.net (Virgil Dupras) Date: Tue, 1 Feb 2011 17:30:23 +0100 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) In-Reply-To: References: <20cf30434772fe60a6049b2a7f9a@google.com> <4D4724FC.1040705@stoneleaf.us> Message-ID: <06806A67-A999-4026-B3B8-6F2D50847BAD@hardcoded.net> On 2011-02-01, at 4:51 PM, anatoly techtonik wrote: > > I'll abandon my efforts when you prove me that current "documented > process" is a top-notch way for all interested parties to do a quality > contributions to make Python better. So that the process is open, > straightforward, transparent and doesn't waste people's time more than > necessary to communicate a change, make it visible for all interested > parties, get feedback, polish and finally integrate. > > There are many ways for improvement, but if people won't try > alternative approaches, they won't see them. I am not sure if I can > manage to get to PyCon, so I didn't do any talk preparation, but if by > chance I get there and there will be an Open Space, we can definitely > find a lot of ways to improve Python development process for general > public. As well as discuss ways to get around stdlib graveyard and > dealing with really complicated problems that won't budge over the > years - like out of the box UTC support. > > The most valuable contributions are coming from professionals, and > these people often don't have enough time to follow "documented > process". In the era of information abundance you often have only 140 > symbols to communicate the idea, and instead of blaming people of > annoying behavior, it might be more useful to make process intuitive > and easy to follow. If that's not possible, there should always be an > exact link to a reasonable explanation about why you need the process > to be so complicated. > > So far only Georg explained what patches sent to mailing list will not > be reviewed, because there is too much volume. But bugtracker is not a > patch tracker. It doesn't allow to monitor incoming patches by module, > its search is very poor. Of course mailing lists are even worse in > this regard, but there is nothing Python community can't deal with. > The problem is to keep non-core people outside motivated, and the > biggest problem with current "documented process" is that nobody even > thinks about it. It's nice to see that you want to improve the tracker. I'm happy to point you to the appropriate place for such proposals: http://psf.upfronthosting.co.za/roundup/meta/ The mailing list about the tracker is: http://mail.python.org/mailman/listinfo/tracker-discuss As for the "mailing list/patch" proposal, I think you should drop it. It's been made abundantly clear, by people much more knowledgable about the dev process of Python than you, why it can't work. Also, not being keen on "following the documented process" is a good indication, IMHO, of unprofessionalism. -- Virgil Dupras From stephen at xemacs.org Tue Feb 1 18:02:19 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 02 Feb 2011 02:02:19 +0900 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) In-Reply-To: References: <20cf30434772fe60a6049b2a7f9a@google.com> <4D4724FC.1040705@stoneleaf.us> Message-ID: <87r5br3cys.fsf@uwakimon.sk.tsukuba.ac.jp> anatoly techtonik writes: > I'll abandon my efforts when you prove me that current "documented > process" is a top-notch way for all interested parties to do a quality > contributions to make Python better. I think the product of the process speaks very well for the process. > The most valuable contributions are coming from professionals, and > these people often don't have enough time to follow "documented > process". I think you have that exactly backward. It is precisely the seasoned professionals who value process most. Professionals are good at managing their own time and can handle process if they can make it routine; but they get annoyed and go away if you break their routine. It's non-professional newcomers who are most attracted by minimal process. > the biggest problem with current "documented process" is that > nobody even thinks about it. Look harder. People thinking about the "Python process" are all over this list, not to mention featured PEP authors. (It's this kind of gratuitous exaggeration that Nick speaks of.) In general, you remind me of the "let's import Japanese practices" management consultancies of the '80s. They failed dismally, because none of the famous Japanese process innovations are standalone. They depend on each other and on a common culture, both lacking in the U.S. and Europe. That doesn't mean that quality circles, JIT, and the like haven't been successfully applied outside of Japan, but they work differently and organizations had to adapt both the Japanese practices and their existing processes to get any advantage from the innovations. I think the analogy to software process, including in open, open source projects like Python, is quite strong. If you want to change the process, I believe that the most effective way is kaizen, ie, gradually improving by sanding down some rough spots, not by whacking off whole subprocesses that you believe are wasteful. Truly wasteful subprocesses generally don't survive in this environment. You should look harder to figure out what they're good for, and then gradually wean the project from them by providing alternative ways to accomplish those goals that are less wasteful, but compatible with other aspects of the existing process. From rdmurray at bitdance.com Tue Feb 1 18:28:50 2011 From: rdmurray at bitdance.com (R. David Murray) Date: Tue, 01 Feb 2011 12:28:50 -0500 Subject: [Python-Dev] Rietveld integration status (Was: MSI: Remove dependency from win32com.client module (issue4080047)) In-Reply-To: References: Message-ID: <20110201172850.43AD1234B7B@kimball.webabinitio.net> On Tue, 01 Feb 2011 18:25:24 +0200, anatoly techtonik wrote: > On Tue, Feb 1, 2011 at 9:45 AM, Georg Brandl wrote: > > It sure is more convenient to do patch review, but > > that's why we are working on Rietveld integration in the tracker. > > Where is the code? What is the status? Where is the roadmap, i.e. how > can people help? Why can't you use hosted Rietveld instance if there > are troubles to setup server properly? See http://wiki.python.org/moin/TrackerDevelopment for how to set up a test instance to hack on. The rietveld stuff is in http://svn.python.org/view/tracker/instances/python-dev/rietveld/. The problem with the rietveld setup is that the script that looks for patches and sets up review tickets has a problem where it consumes ever larger amounts of memory and doesn't finish its run. So the "roadmap" is to debug and fix that script. Martin hasn't had time to do it, and I haven't had time to learn enough about rietveld to try. Getting set up to test tracker patches is distinctly non-trivial, which is probably why very few people work on it. -- R. David Murray www.bitdance.com From scott+python-dev at scottdial.com Tue Feb 1 20:04:05 2011 From: scott+python-dev at scottdial.com (Scott Dial) Date: Tue, 01 Feb 2011 14:04:05 -0500 Subject: [Python-Dev] Issue #11051: system calls per import In-Reply-To: References: <1296377778.24415.4.camel@marge> <4D452E71.6070401@python.org> <1296405345.24507.9.camel@marge> <4D45D6E1.6030906@canterbury.ac.nz> <4D4665B9.9000108@v.loewis.de> <20110131134300.2babc577@pitrou.net> Message-ID: <4D485925.7090603@scottdial.com> On 1/31/2011 1:38 PM, Brett Cannon wrote: > I should mention that I have considered implementing a caching finder > and loader for filesystems in importlib for people to optionally > install to use for themselves. The real trick, though, is should it > only cache hits, misses, or both? Regardless, though, it would be a > very simple mixin or subclass to implement if there is demand for this > sort of thing. I have in the past implemented a PEP302 finder/loader zipfile-based cache. On campus, I use a version of python installed to my home directory that is on an NFS share. I found such a cache often gave slower startup times for applications like bzr and hg. My cache merely stores things it finds things in sys.path and loads from the zipfile names that it knows and storing those that it doesn't. I make no attempt to invalidate the cache contents once stored. So, I am already talking about a best-case scenario for caching. I'm not sure how you could invalidate the cache without paying the cost of all the normal syscalls that we are trying to avoid. My finder/loader is not bug-free, but I'd be glad to make it available to someone if they want to play around with it. -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From martin at v.loewis.de Tue Feb 1 20:50:23 2011 From: martin at v.loewis.de (martin at v.loewis.de) Date: Tue, 01 Feb 2011 19:50:23 +0000 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) Message-ID: <001636e1e9e9e06748049b3dd7cc@google.com> On 2011/02/01 07:22:57, techtonik wrote: > It removes the dependency from msi.py making it easier to do the rest in > subsequent patches. What rest specifically? Why are the msilib changes needed for that? http://codereview.appspot.com/4080047/ From g.brandl at gmx.net Tue Feb 1 22:39:59 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Tue, 01 Feb 2011 22:39:59 +0100 Subject: [Python-Dev] Rietveld integration status (Was: MSI: Remove dependency from win32com.client module (issue4080047)) In-Reply-To: References: Message-ID: Am 01.02.2011 17:25, schrieb anatoly techtonik: > On Tue, Feb 1, 2011 at 9:45 AM, Georg Brandl wrote: >> >> A mailing list works only if you have a small group of core developers >> who can independently organize the incoming mails using local tools, >> such as the read/unread marking of the email client. For a larger >> group this doesn't work (how do you assign a patch to someone using >> a mailing list?). > > If you can filter patches by module (and it can be done > automatically), then you won't need to assign patches. People can > subscribe to interested parts and participate independently. That's not true. Assignment isn't meant to make searching issues easier, it's meant for the developers to help them collect and work on their tasks. Georg From g.brandl at gmx.net Tue Feb 1 22:46:28 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Tue, 01 Feb 2011 22:46:28 +0100 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) In-Reply-To: References: <20cf30434772fe60a6049b2a7f9a@google.com> <4D4724FC.1040705@stoneleaf.us> Message-ID: Am 01.02.2011 16:51, schrieb anatoly techtonik: > On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan wrote: >> On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik wrote: >>> To me polluting tracker with the >>> issues that are neither bugs nor feature requests only makes bug >>> triaging process and search more cumbersome. >> >> Anatoly, your constant efforts to try to force python-dev to adapt to >> *your* way of doing things, instead of being willing to work with the >> documented processes are *seriously* annoying. Which is a shame, since >> it obscures the fact that your underlying suggestions are often quite >> reasonable. > > I'll abandon my efforts when you prove me that current "documented > process" is a top-notch way for all interested parties to do a quality > contributions to make Python better. And who or what decides what this "top-notch way" is? > So that the process is open, straightforward, transparent Ah. Well, that's definitely very a concise spec. > and doesn't waste people's time more than > necessary to communicate a change, make it visible for all interested > parties, get feedback, polish and finally integrate. [...] > The most valuable contributions are coming from professionals, and > these people often don't have enough time to follow "documented > process". In the era of information abundance you often have only 140 > symbols to communicate the idea, That's a great idea for a change: report bugs by twitter. We need to set up a twitter search for #PythonBug, and then you simply enter #PythonBug the process is slow and it is converted to an issue on b.p.o. Very open, very transparent, and of course very straightforward. Let's not care about how to reach the submitter when clarification is needed, or what to do about patches. If it doesn't fit into 140 characters, it doesn't exist! > and instead of blaming people of > annoying behavior, it might be more useful to make process intuitive > and easy to follow. If that's not possible, there should always be an > exact link to a reasonable explanation about why you need the process > to be so complicated. The new devguide (docs.python.org/devguide) should provide exactly that, and in a central location. > So far only Georg explained what patches sent to mailing list will not > be reviewed, because there is too much volume. But bugtracker is not a > patch tracker. As I explained, it is an *issue tracker*. And since in 99% of cases there is an actual issue underlying a patch, it is more than justified to use it to track issues that have patches. > It doesn't allow to monitor incoming patches by module, > its search is very poor. Of course mailing lists are even worse in > this regard, but there is nothing Python community can't deal with. Exactly, so let us continue the ongoing work in improving the tracker. > The problem is to keep non-core people outside motivated, and the > biggest problem with current "documented process" is that nobody even > thinks about it. I think others already wrote enough about that. Georg From techtonik at gmail.com Wed Feb 2 06:18:50 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Wed, 2 Feb 2011 07:18:50 +0200 Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows In-Reply-To: References: <4D431724.4010002@voidspace.org.uk> <7DA37C12-D3DA-49B3-996A-017CF304BC5C@gmail.com> Message-ID: On Mon, Jan 31, 2011 at 11:49 PM, Brian Curtin wrote: > On Mon, Jan 31, 2011 at 15:43, anatoly techtonik > wrote: >> >> On Mon, Jan 31, 2011 at 11:24 PM, Brian Curtin >> wrote: >> > On Mon, Jan 31, 2011 at 15:13, anatoly techtonik >> > wrote: >> >> >> >> Ok. Here is the patch. I used Orca to reverse installer tables of >> >> Mercurial MSI and inserted similar entry for Python. >> >> >> >> Also available for review at: http://codereview.appspot.com/4023055 >> > >> > That's the easy part. It doesn't cover any of the real issues with doing >> > this. >> >> Please be more specific. It will also help if you integrate this part >> while it's still hot. > > There are numerous comments in the various PATH-related issues on the issue > tracker, and many of them are duplicated in this very thread. The master issue at http://bugs.python.org/issue3561 specifically proposes further discussion proposals on python-dev. From techtonik at gmail.com Wed Feb 2 06:41:16 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Wed, 2 Feb 2011 07:41:16 +0200 Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows In-Reply-To: <4D474F7A.2090800@v.loewis.de> References: <4D431724.4010002@voidspace.org.uk> <7DA37C12-D3DA-49B3-996A-017CF304BC5C@gmail.com> <4D474F7A.2090800@v.loewis.de> Message-ID: On Tue, Feb 1, 2011 at 2:10 AM, "Martin v. L?wis" wrote: > Am 31.01.2011 22:13, schrieb anatoly techtonik: >> Ok. Here is the patch. I used Orca to reverse installer tables of >> Mercurial MSI and inserted similar entry for Python. > > This doesn't do uninstallation correctly. I do not know where did you get this info, but I assure you that it does, and I've stressed this in the first post of this thread. You may repeat the experiment yourself. Here is the patched installer: https://docs.google.com/leaf?id=0Bwu0AJeJuth_MWJjMTgzNmQtYWIzOS00ODhlLTk3YjAtYWJiYTdmYWQwNzU5&sort=name&layout=list&num=50 From rrr at ronadam.com Wed Feb 2 07:27:43 2011 From: rrr at ronadam.com (Ron Adam) Date: Wed, 02 Feb 2011 00:27:43 -0600 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) In-Reply-To: References: <20cf30434772fe60a6049b2a7f9a@google.com> <4D4724FC.1040705@stoneleaf.us> Message-ID: On 02/01/2011 09:51 AM, anatoly techtonik wrote: > So far only Georg explained what patches sent to mailing list will not > be reviewed, because there is too much volume. But bugtracker is not a > patch tracker. It doesn't allow to monitor incoming patches by module, > its search is very poor. Of course mailing lists are even worse in > this regard, but there is nothing Python community can't deal with. > The problem is to keep non-core people outside motivated, and the > biggest problem with current "documented process" is that nobody even > thinks about it. I've seen quite a bit of changes over the years. Yes, it's happens over years because the release schedule is fairly long. They try not to interrupt the current schedule too much, so bigger changes to the development process are usually made after a major release is done, rather than during the middle. Lately (the last two years) things have been quite a bit busier with the addition of python3.x. Once we get to where we are (mostly) only concentrating on one major version again, then it will be easer to make process changes. (Less things to mess up if it goes wrong.) I think after this next release is completed you will see more efforts turning to improving the process. Some of the vary things you have been trying to pointed out I think. As far as patches getting attention, it's getting better there too. Every time you make a comment or update an issue with a patch change, it gets reported to the bugs list. Many of the core developers watch that and will add them self to the nosey list on that issue if it has something to do with the parts of python they know. If you have a patch that you feel is complete and is ready to go into the next release or a bug fix for the current one, post a comment on the issue asking for a review. Chances are you will get a reply in a few days. I've found searching for other patches related to my patches helps. I can search the tracker or the bug list for the module or problem I'm working on. It's really not that hard to find related issues. Then I can post a comment on those issues when I can be of help, and also post on that issue a link to the related issue I'm working on. Python is a large project with a *huge* user base. So changes are considered very carefully. Probably the hardest part is making changes in a way that is very unlikely to break someone's program. Mess up someone's pay role process some place (even by the smallest change) and people will get very unhappy really quick. It's also not good to crash space shuttles or google. ;-) Cheers, Ron From techtonik at gmail.com Wed Feb 2 08:14:18 2011 From: techtonik at gmail.com (techtonik at gmail.com) Date: Wed, 02 Feb 2011 07:14:18 +0000 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) Message-ID: <20cf3043474cb32a67049b47657c@google.com> On 2011/02/01 19:50:23, Martin v. L?wis wrote: > On 2011/02/01 07:22:57, techtonik wrote: > > It removes the dependency from msi.py making it easier to do the rest in > > subsequent patches. > What rest specifically? Why are the msilib changes needed for that? The rest is to use ctypes, so that no external packages will be required to build Python installer. http://codereview.appspot.com/4080047/ From martin at v.loewis.de Wed Feb 2 08:18:33 2011 From: martin at v.loewis.de (martin at v.loewis.de) Date: Wed, 02 Feb 2011 07:18:33 +0000 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) Message-ID: <90e6ba6e8f34f0e1ae049b477417@google.com> On 2011/02/02 07:14:17, techtonik wrote: > On 2011/02/01 19:50:23, Martin v. L?wis wrote: > > On 2011/02/01 07:22:57, techtonik wrote: > > > It removes the dependency from msi.py making it easier to do the rest in > > > subsequent patches. > > > > What rest specifically? Why are the msilib changes needed for that? > The rest is to use ctypes, so that no external packages will be required to > build Python installer. Ah. That shouldn't be done. If anything is to be done, the builtin msilib can be considered, instead. Given the choice of using either ctypes or an external package, I prefer the external package. http://codereview.appspot.com/4080047/ From techtonik at gmail.com Wed Feb 2 08:32:03 2011 From: techtonik at gmail.com (techtonik at gmail.com) Date: Wed, 02 Feb 2011 07:32:03 +0000 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) Message-ID: <20cf3056445d2d4dd5049b47a512@google.com> On 2011/02/02 07:18:33, Martin v. L?wis wrote: > Ah. That shouldn't be done. If anything is to be done, the builtin msilib can be > considered, instead. Given the choice of using either ctypes or an external > package, I prefer the external package. It is a surprise to find builtin msilib. Why isn't it used? Is an incremental transition to builtin possible? http://codereview.appspot.com/4080047/ From georg.brandl at gmail.com Wed Feb 2 08:36:47 2011 From: georg.brandl at gmail.com (georg.brandl at gmail.com) Date: Wed, 02 Feb 2011 07:36:47 +0000 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) Message-ID: <90e6ba6e8a0e225e1d049b47b6ea@google.com> On 2011/02/02 07:32:02, techtonik wrote: [...] Can you PLEASE take this off python-dev and move to an issue at bugs.python.org? At least remove python-dev from the CC, or we'll have to temporarily block messages from codereview. http://codereview.appspot.com/4080047/ From techtonik at gmail.com Wed Feb 2 09:33:05 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Wed, 2 Feb 2011 10:33:05 +0200 Subject: [Python-Dev] devguide: Generate patches without code checkout (Was: devguide: Write a guide to committing a patch.) Message-ID: On Tue, Jan 18, 2011 at 2:35 PM, Antoine Pitrou wrote: > On Tue, 18 Jan 2011 07:14:51 +0100 > Ezio Melotti wrote: >> > + >> > +Committing Patches >> > +================== > [...] >> > + >> > + ? ?svnmerge.py merge -r 42 >> > + >> > +This will try to apply the patch to the current patch and generate a >> > commit > > Do we want to spend so much time explaining how to use SVN for core > developers while we're supposed to switch to Mercurial Real Soon Now? > (current core devs already know how to use it, and we don't get many > new ones every month) How about patches sent by users who track and fix bugs directly in codebase of their Python installation? Making and testing a patch from Python checkout requires compiling Python, which is not possible for Windows users. We should add less hardcore instructions how to use bundled diff.py for creating simple patches like docstring, comment fixes or generating new testcases. This will greatly reduce the barrier for starting with development. -- anatoly t. From martin at v.loewis.de Wed Feb 2 09:36:37 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 02 Feb 2011 09:36:37 +0100 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) In-Reply-To: <20cf3056445d2d4dd5049b47a512@google.com> References: <20cf3056445d2d4dd5049b47a512@google.com> Message-ID: <4D491795.2020008@v.loewis.de> > It is a surprise to find builtin msilib. Why isn't it used? Originally, because Python needs to be packaged with an older release (in particular one that isn't itself maintained anymore). Today, the problem is that the msilib package doesn't support merge modules (and if such support was added, we would have to wait until the version containing it isn't maintained anymore). I don't consider the dependency on win32com a serious issue at all; it's just a mild annoyance (much less than reliance on ctypes would be, or hard-coding of symbolic constants). Regards, Martin From ncoghlan at gmail.com Wed Feb 2 11:27:24 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 2 Feb 2011 20:27:24 +1000 Subject: [Python-Dev] devguide: Generate patches without code checkout (Was: devguide: Write a guide to committing a patch.) In-Reply-To: References: Message-ID: On Wed, Feb 2, 2011 at 6:33 PM, anatoly techtonik wrote: > Making and testing a patch from Python checkout requires compiling > Python, which is not possible for Windows users. That latter comment hasn't been true since Microsoft started releasing the Visual Studio Express editions. > We should add less > hardcore instructions how to use bundled diff.py for creating simple > patches like docstring, comment fixes or generating new testcases. > This will greatly reduce the barrier for starting with development. Given the length of Python's release cycles, diffs against released versions are far too likely to be out of date. We want diffs against the head of the relevant branch. People that can't check out and build their own version of Python are quite welcome to simply report issues without trying to fix them themselves. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From techtonik at gmail.com Wed Feb 2 12:03:05 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Wed, 2 Feb 2011 13:03:05 +0200 Subject: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047) In-Reply-To: <4D491795.2020008@v.loewis.de> References: <20cf3056445d2d4dd5049b47a512@google.com> <4D491795.2020008@v.loewis.de> Message-ID: On Wed, Feb 2, 2011 at 10:36 AM, "Martin v. L?wis" wrote: > >> It is a surprise to find builtin msilib. Why isn't it used? > > Originally, because Python needs to be packaged with an older > release (in particular one that isn't itself maintained anymore). That doesn't answer the question why Python could not be packaged with a newer release of 'msilib' at that time? > Today, the problem is that the msilib package doesn't support > merge modules (and if such support was added, we would have to > wait until the version containing it isn't maintained anymore). I don't understand the phrase in (). What for do we need to wait after adding support for merge modules to builtin msilib? I imagine we've added support for merge modules to msilib, and then waiting until new msilib version with merge support isn't maintained anymore. And only then we can use it to create installer. Sounds like a nonsense. Anyways, is it possible to reuse builtin msilib to the max and add required 'merge modules' functionality inside msi.py or extension module? > I don't consider the dependency on win32com a serious issue at > all; it's just a mild annoyance (much less than reliance on ctypes > would be, or hard-coding of symbolic constants). There is nothing wrong with hardcoded symbolic constants - Microsoft specifically provides values for them in their MSDN materials to be used with scripting languages which doesn't have include files. They just need to be validated one time, and won't change in future. Why don't you like ctypes solution? I find it strange that Python build process avoids using its own modules. -- anatoly t. From sandro.tosi at gmail.com Wed Feb 2 12:04:44 2011 From: sandro.tosi at gmail.com (Sandro Tosi) Date: Wed, 2 Feb 2011 12:04:44 +0100 Subject: [Python-Dev] [Python-checkins] devguide: Add a document discussing the development cycle typically followed for In-Reply-To: References: Message-ID: On Wed, Jan 26, 2011 at 23:20, brett.cannon wrote: > +The in-development branch is where new functionality and semantic changes new functionalities (dunno if it's plural in english or not)? > +occur. Currently this branch is known as the "py3k" branch. The next minor > +release of Python will come from this branch (major releases are once a decade > +and so have no specific rules on how they are started). All changes land in this > +branch and then trickle down to other branches. > + > +Once a Final_ release is made from the in-development branch, a branch is made > +to represent the minor version of Python and it goes into maintenance mode. > +Typically a minor version of Python is under development for about 18 months. > + > + > +Maintenance > +----------- > +The branch currently being maintained for bug fixes. > + > +The branch under maintenance is the last minor version of Python to be released > +as Final_. This means that the latest release of Python was 3.1.2, then the if the latest release ? > +branch representing Python 3.1 is in maintenance mode. > + > +The only changes allowed to occur in a maintenance branch without debate are bug > +fixes. > +Semantic changes **must** be carefully considered as code out in the world will > +have already been developed that will rely on the released semantics. Changes > +related to semantics should be discussed on python-dev before being made. > + > +A branch stays in maintenance mode as long as a new minor release has not been > +made. For example, this means that Python 2.6 stayed in maintenance mode until > +Python 2.7.0 was released, at which point 2.7 went into maintenance mode and > +2.6 went into Security_ mode. As new minor releases occur on a (roughly) 18 > +month schedule, a branch stays in mainteance mode for the same amount of time. s/mainteance/maintenance/ > + > +A micro release of a maintenance branch is made about every six months. > +Typically when a new minor release is made one more release of the new-old > +version of Python is made. > + > + > +Security > +-------- > +A branch less than five years old but no longer in maintenance mode. > + > +The only changes made to a branch that is being maintained for security > +purposes are somewhat obviously those related to security, e.g., privilege > +escalation. Crashers and other behaviorial issues are **not** considered a s/Crashers/Crashes/ s/behaviorial/behavioral/ > +security risk and thus not backported to a branch being maintained for > +security. Any releases made for a branch under security maintenance is s/releases/release/ ? s/for/from/ > +source-only and done only when actual security patches have been applied to the > +branch. > + > + > +Stages > +'''''' > + > +Based on what stage the in-development version of Python is in, the > +responsibilities of a core developer change in regards to commits to the VCS. > + > + > +Pre-alpha > +--------- > +This is the stage a branch is in from the last final release until the first > +alpha (a1). There are no special restrictions placed on commits beyond those > +imposed by the type of branch being worked on (e.g., in-development vs. > +maintenance). > + > + > +Alpha > +----- > +Alphas typically serve as a reminder to core developers that they need to start > +getting in changes that change semantics or add something to Python as such > +things should not be added during a Beta_. Otherwise no new restrictions are in > +place while in alpha. > + > + > +Beta > +---- > +A branch in beta means that no new additions to Python are accepted. Bugfixes > +and the like are still fine. Being in beta can be viewed much like being in RC_ > +but without the extra overhead of needing commit reviews. > + > + > +.. _RC: > + > +Release Candidate (RC) > +---------------------- > +A branch preparing for an RC release can only have bugfixes applied that have > +been reviewed by other core developers. That reviewer should make a post to the > +issue related to the change and be mentioned in the commit message. > + > +You **cannot** skip the peer review during an RC, no matter how small! Even if > +it is a simple copy-and-paste change, **everything** requires peer review from > +a core developer. > + > + > +Final > +----- > +When a final release is being cut, only the release manager (RM) can make > +changes to the branch. > diff --git a/index.rst b/index.rst > --- a/index.rst > +++ b/index.rst > @@ -20,6 +20,7 @@ > ? ?coredev > ? ?developers > ? ?committing > + ? devcycle > > ? ?stdlibchanges > ? ?langchanges > @@ -64,6 +65,7 @@ > ?* :ref:`coredev` > ? ? * :ref:`developers` > ? ? * :ref:`committing` > + ? ?* :ref:`devcycle` > > > ?Proposing changes to Python itself > > -- > Repository URL: http://hg.python.org/devguide > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://mail.python.org/mailman/listinfo/python-checkins > > -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi From fuzzyman at voidspace.org.uk Wed Feb 2 12:22:24 2011 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 02 Feb 2011 11:22:24 +0000 Subject: [Python-Dev] [Python-checkins] devguide: Add a document discussing the development cycle typically followed for In-Reply-To: References: Message-ID: <4D493E70.9050606@voidspace.org.uk> On 02/02/2011 11:04, Sandro Tosi wrote: > On Wed, Jan 26, 2011 at 23:20, brett.cannon wrote: >> +The in-development branch is where new functionality and semantic changes > new functionalities (dunno if it's plural in english or not)? It's an odd one. Functionality can be implicitly plural (include several individual features that comprise new functionality) but can also be pluralised; several functionalities where each new functionality comprises plural features. I would say that Brett's wording reads correctly here. Michael >> +occur. Currently this branch is known as the "py3k" branch. The next minor >> +release of Python will come from this branch (major releases are once a decade >> +and so have no specific rules on how they are started). All changes land in this >> +branch and then trickle down to other branches. >> + >> +Once a Final_ release is made from the in-development branch, a branch is made >> +to represent the minor version of Python and it goes into maintenance mode. >> +Typically a minor version of Python is under development for about 18 months. >> + >> + >> +Maintenance >> +----------- >> +The branch currently being maintained for bug fixes. >> + >> +The branch under maintenance is the last minor version of Python to be released >> +as Final_. This means that the latest release of Python was 3.1.2, then the > if the latest release ? > >> +branch representing Python 3.1 is in maintenance mode. >> + >> +The only changes allowed to occur in a maintenance branch without debate are bug >> +fixes. >> +Semantic changes **must** be carefully considered as code out in the world will >> +have already been developed that will rely on the released semantics. Changes >> +related to semantics should be discussed on python-dev before being made. >> + >> +A branch stays in maintenance mode as long as a new minor release has not been >> +made. For example, this means that Python 2.6 stayed in maintenance mode until >> +Python 2.7.0 was released, at which point 2.7 went into maintenance mode and >> +2.6 went into Security_ mode. As new minor releases occur on a (roughly) 18 >> +month schedule, a branch stays in mainteance mode for the same amount of time. > s/mainteance/maintenance/ > >> + >> +A micro release of a maintenance branch is made about every six months. >> +Typically when a new minor release is made one more release of the new-old >> +version of Python is made. >> + >> + >> +Security >> +-------- >> +A branch less than five years old but no longer in maintenance mode. >> + >> +The only changes made to a branch that is being maintained for security >> +purposes are somewhat obviously those related to security, e.g., privilege >> +escalation. Crashers and other behaviorial issues are **not** considered a > s/Crashers/Crashes/ > s/behaviorial/behavioral/ > >> +security risk and thus not backported to a branch being maintained for >> +security. Any releases made for a branch under security maintenance is > s/releases/release/ ? > s/for/from/ > >> +source-only and done only when actual security patches have been applied to the >> +branch. >> + >> + >> +Stages >> +'''''' >> + >> +Based on what stage the in-development version of Python is in, the >> +responsibilities of a core developer change in regards to commits to the VCS. >> + >> + >> +Pre-alpha >> +--------- >> +This is the stage a branch is in from the last final release until the first >> +alpha (a1). There are no special restrictions placed on commits beyond those >> +imposed by the type of branch being worked on (e.g., in-development vs. >> +maintenance). >> + >> + >> +Alpha >> +----- >> +Alphas typically serve as a reminder to core developers that they need to start >> +getting in changes that change semantics or add something to Python as such >> +things should not be added during a Beta_. Otherwise no new restrictions are in >> +place while in alpha. >> + >> + >> +Beta >> +---- >> +A branch in beta means that no new additions to Python are accepted. Bugfixes >> +and the like are still fine. Being in beta can be viewed much like being in RC_ >> +but without the extra overhead of needing commit reviews. >> + >> + >> +.. _RC: >> + >> +Release Candidate (RC) >> +---------------------- >> +A branch preparing for an RC release can only have bugfixes applied that have >> +been reviewed by other core developers. That reviewer should make a post to the >> +issue related to the change and be mentioned in the commit message. >> + >> +You **cannot** skip the peer review during an RC, no matter how small! Even if >> +it is a simple copy-and-paste change, **everything** requires peer review from >> +a core developer. >> + >> + >> +Final >> +----- >> +When a final release is being cut, only the release manager (RM) can make >> +changes to the branch. >> diff --git a/index.rst b/index.rst >> --- a/index.rst >> +++ b/index.rst >> @@ -20,6 +20,7 @@ >> coredev >> developers >> committing >> + devcycle >> >> stdlibchanges >> langchanges >> @@ -64,6 +65,7 @@ >> * :ref:`coredev` >> * :ref:`developers` >> * :ref:`committing` >> + * :ref:`devcycle` >> >> >> Proposing changes to Python itself >> >> -- >> Repository URL: http://hg.python.org/devguide >> _______________________________________________ >> Python-checkins mailing list >> Python-checkins at python.org >> http://mail.python.org/mailman/listinfo/python-checkins >> >> > > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From techtonik at gmail.com Wed Feb 2 13:50:22 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Wed, 2 Feb 2011 14:50:22 +0200 Subject: [Python-Dev] devguide: Generate patches without code checkout (Was: devguide: Write a guide to committing a patch.) In-Reply-To: References: Message-ID: On Wed, Feb 2, 2011 at 12:27 PM, Nick Coghlan wrote: > On Wed, Feb 2, 2011 at 6:33 PM, anatoly techtonik wrote: >> Making and testing a patch from Python checkout requires compiling >> Python, which is not possible for Windows users. > > That latter comment hasn't been true since Microsoft started releasing > the Visual Studio Express editions. "not possible" here means that practically only a very small percent of Python users will go through the hurdles of getting code checkout, downloading and installing Visual Studio, compiling project, switching their code to use compiled version and finally submitting a patch. BTW, what is the size of Mercurial clone right now? >> We should add less >> hardcore instructions how to use bundled diff.py for creating simple >> patches like docstring, comment fixes or generating new testcases. >> This will greatly reduce the barrier for starting with development. > > Given the length of Python's release cycles, diffs against released > versions are far too likely to be out of date. We want diffs against > the head of the relevant branch. I only see that you want the contribution entry barrier to stay at the height of core developer. > People that can't check out and build their own version of Python are > quite welcome to simply report issues without trying to fix them > themselves. But if they really want for an issue to be fixed, they will need to think about preparing a patch. The first time they ask about plans to fix the issue, they will be asked to send a patch anyway. This person will look into devguide how to send a patch. There will be instructions to download Visual Studio, clone repository, compile, etc. I doubt this person will have time to do this, but next time the person will think twice before reporting. From hodgestar+pythondev at gmail.com Wed Feb 2 13:59:02 2011 From: hodgestar+pythondev at gmail.com (Simon Cross) Date: Wed, 2 Feb 2011 14:59:02 +0200 Subject: [Python-Dev] devguide: Generate patches without code checkout (Was: devguide: Write a guide to committing a patch.) In-Reply-To: References: Message-ID: On Wed, Feb 2, 2011 at 10:33 AM, anatoly techtonik wrote: > How about patches sent by users who track and fix bugs directly in > codebase of their Python installation? While I don't personally endorse the above approach, if you're going to develop inside your installed site-packages folder it seems like a good idea to at least version control that code by running "hg init" or similar in the site-packages folder. Then you can create diffs against older versions using "hg diff". If one is going to do something crazy one might as well go the whole hog I guess. :) Schiavo Simon From solipsis at pitrou.net Wed Feb 2 14:51:56 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 2 Feb 2011 14:51:56 +0100 Subject: [Python-Dev] [Python-checkins] devguide: Add a document discussing the development cycle typically followed for References: Message-ID: <20110202145156.6f62d39b@pitrou.net> On Wed, 2 Feb 2011 12:04:44 +0100 Sandro Tosi wrote: > > +Security > > +-------- > > +A branch less than five years old but no longer in maintenance mode. > > + > > +The only changes made to a branch that is being maintained for security > > +purposes are somewhat obviously those related to security, e.g., privilege > > +escalation. Crashers and other behaviorial issues are **not** considered a > > s/Crashers/Crashes/ > s/behaviorial/behavioral/ > > > +security risk By the way, crashers *are* a security risk. See http://code.python.org/hg/branches/release2.6-maint/ Regards Antoine. From erez27 at gmail.com Wed Feb 2 14:52:17 2011 From: erez27 at gmail.com (Erez Sh) Date: Wed, 2 Feb 2011 15:52:17 +0200 Subject: [Python-Dev] xmlrpclib and communication verbosity Message-ID: In an attempt to record the xml exchange in an xmlrpclib.ServerProxy connection, I set its verbose flag to 1. This is the whole premise, and the rest of this message contains a bug report, and general complaints about the API. ServerProxy, or to be a bit more specific, the Transport class (which does all the actual printing), provides very little control over where the output goes. By very little, I mean it only outputs to stdout, which is limiting in a server environment where many a prints occur. That, however, turned out to be the least of my worries: xmlrpclib depends on httplib.HTTP to print the outgoing data, but prints its own incoming data, and they tend to collide, in what I permit myself to call a "race condition", though it's mostly just simple lack of management of a shared resource (stdout). The resulting output is mostly well-formed, with the occasional nonsense produced by an interjection of one string to the middle of the other. Also, there's the nasty business of Transport.request accepting a 'verbose' param, and then setting it as an instance attribute and using *that*, for no apparent reason except to cause yet another potential race condition. I suggest that httplib.HTTP's verbosity will be controlled by a separate flag, if controlled at all. The outgoing communication can easily be printed by transport, allowing for better control of synchrony. Also, ServerProxy should accept an optional output file (=a class with write,writelines methods), which will be the target of all prints. Would Python be interested in such a patch? Best Regards, Erez -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.curtin at gmail.com Wed Feb 2 16:52:55 2011 From: brian.curtin at gmail.com (Brian Curtin) Date: Wed, 2 Feb 2011 09:52:55 -0600 Subject: [Python-Dev] curtin-win2008-amd64 build slave down for a while Message-ID: I'm having some power issues due to a major snow storm so my build slave is turned off. Don't worry, everyone's favorite OS will be back to work within the next few days. -------------- next part -------------- An HTML attachment was scrubbed... URL: From osirius at gmail.com Wed Feb 2 16:55:03 2011 From: osirius at gmail.com (Sam Bull) Date: Wed, 2 Feb 2011 10:55:03 -0500 Subject: [Python-Dev] alternate fix for urllib2 bug #8797 Message-ID: <4E27C7B0-0301-4027-B342-EEF7E7A07F52@gmail.com> Hello all, This is my first stab at contributing to this list. I'm writing to lobby for bug #8797's fix to be removed and for my fix to put in in its place. I'm probably doing this wrong, so please bear with me. I will embrace whatever scathing criticism I get. The ticket covers all the details (http://bugs.python.org/issue8797#) but I'll try to summarize here: In 2.6.5, urllib2 had a small regression that caused HTTP 401 errors to trigger an infinite recursion when the request handler had HTTP Auth credentials that the server was rejecting. Previously, urllib2 avoided this loop by checking the previous request's headers to see if it had already tried the credentials it was about to try. If it had, it would re-raise the exception instead of trying again. The current fix adds a "max retries" concept to urllib2's handling of HTTP 401 errors so that the code will only retry a certain number of times. To me, the original logic of only trying once for each set of credentials was sound, and it looks like the only reason this stopped working was that in 2.6.5 the auth header wasn't being stored in the same place as the code was expecting to find it. I think it makes sense to revisit this issue and swap out the existing fix for my fix because it's tidier and doesn't introduce this new "max retries" functionality. Please let me know what you think. Thanks, Sam Bull -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.belopolsky at gmail.com Wed Feb 2 17:13:14 2011 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 2 Feb 2011 11:13:14 -0500 Subject: [Python-Dev] alternate fix for urllib2 bug #8797 In-Reply-To: <4E27C7B0-0301-4027-B342-EEF7E7A07F52@gmail.com> References: <4E27C7B0-0301-4027-B342-EEF7E7A07F52@gmail.com> Message-ID: On Wed, Feb 2, 2011 at 10:55 AM, Sam Bull wrote: >.. I'm writing to lobby for bug #8797's fix to be removed and for my fix to put in in its place. Please open a separate issue for your patch. Patches attached to closed issues will be lost. From hodgestar+pythondev at gmail.com Wed Feb 2 17:25:45 2011 From: hodgestar+pythondev at gmail.com (Simon Cross) Date: Wed, 2 Feb 2011 18:25:45 +0200 Subject: [Python-Dev] alternate fix for urllib2 bug #8797 In-Reply-To: <4E27C7B0-0301-4027-B342-EEF7E7A07F52@gmail.com> References: <4E27C7B0-0301-4027-B342-EEF7E7A07F52@gmail.com> Message-ID: Hi Sam On Wed, Feb 2, 2011 at 5:55 PM, Sam Bull wrote: > This is my first stab at contributing to this list. I'm writing to lobby for > bug #8797's fix to be removed and for my fix to put in in its place. For what it's worth, I was already about to include your patch as a workaround for the bug in 2.6. See Bitten issue http://bitten.edgewall.org/ticket/658. I also consider Sam's patch to be a cleaner patch than the one that ended up being applied in Python. See my comments in the Bitten mailing list thread: https://groups.google.com/forum/#!topic/bitten/niJENqEGuus. Schiavo Simon From hoyt6 at llnl.gov Wed Feb 2 20:01:06 2011 From: hoyt6 at llnl.gov (Hoyt, David) Date: Wed, 2 Feb 2011 11:01:06 -0800 Subject: [Python-Dev] Python merge module Message-ID: Is there or will there be support for python merge modules so we can include python in our installer? Also, the discussions I saw about windows installers not removing the path on uninstall is completely false as regards the installers that wix creates, at least. I've modified the path many times and explicitly tested that it was removed on uninstall. I can't speak for the msilib package and what it does - perhaps it's doing the wrong thing? But has there been thought towards migrating away from msilib and using platform standard tools such as wix (used by ms office, visual studio, etc.)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.brandl at gmx.net Wed Feb 2 20:29:15 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Wed, 02 Feb 2011 20:29:15 +0100 Subject: [Python-Dev] devguide: Generate patches without code checkout (Was: devguide: Write a guide to committing a patch.) In-Reply-To: References: Message-ID: Am 02.02.2011 13:50, schrieb anatoly techtonik: >>> We should add less >>> hardcore instructions how to use bundled diff.py for creating simple >>> patches like docstring, comment fixes or generating new testcases. >>> This will greatly reduce the barrier for starting with development. >> >> Given the length of Python's release cycles, diffs against released >> versions are far too likely to be out of date. We want diffs against >> the head of the relevant branch. > > I only see that you want the contribution entry barrier to stay at the > height of core developer. Because only core developers are allowed to have a checkout of trunk? Georg From merwok at netwok.org Wed Feb 2 20:48:03 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Wed, 02 Feb 2011 20:48:03 +0100 Subject: [Python-Dev] Moving stuff out of Misc and over to the devguide In-Reply-To: References: <20110117215440.122bef7b@pitrou.net> <4D36E118.40008@netwok.org> <7e9e0831fbf09c304e9f358b406f43b8.squirrel@mail.trueblade.com> Message-ID: <4D49B4F3.9000503@netwok.org> Le 19/01/2011 18:04, Georg Brandl a ?crit : > Am 19.01.2011 16:25, schrieb Eric Smith: >>> Bonus question: if we remove maintainers.rst from py3k, what do we do in >>> 3.1 and 2.7? I?d favor removing them over keeping outdated versions. >> >> Is there not some advantage to knowing who was the maintainer (or expert) >> of a given module at the time of a release? > > I don't see much advantage. And if you need the version of maintainers.rst > in another repo, it's not hard to find the revision that corresponds to the > release date. Ping. Do we remove maintainers.rst or do we add a note advising people to look at the up-to-date version on docs.python.org/devguide? (And yes, by ?we? I mean I?m volunteering to do either. :) Regards From brian.curtin at gmail.com Wed Feb 2 21:17:22 2011 From: brian.curtin at gmail.com (Brian Curtin) Date: Wed, 2 Feb 2011 14:17:22 -0600 Subject: [Python-Dev] devguide: Generate patches without code checkout (Was: devguide: Write a guide to committing a patch.) In-Reply-To: References: Message-ID: On Wed, Feb 2, 2011 at 06:50, anatoly techtonik wrote: > On Wed, Feb 2, 2011 at 12:27 PM, Nick Coghlan wrote: > > On Wed, Feb 2, 2011 at 6:33 PM, anatoly techtonik > wrote: > >> Making and testing a patch from Python checkout requires compiling > >> Python, which is not possible for Windows users. > > > > That latter comment hasn't been true since Microsoft started releasing > > the Visual Studio Express editions. > > "not possible" here means that practically only a very small percent > of Python users will go through the hurdles of getting code checkout, > downloading and installing Visual Studio, compiling project, switching > their code to use compiled version and finally submitting a patch. > In reality this doesn't seem to be the case. In all of the Windows-related Python issues I've looked at in a year and a half, only a small handful of the patches or analysis have been based on installed versions or from users who don't have the capability or interest in setting up the environment. Of course we welcome those users, but my experience shows them to be the minority. Installing Visual Studio is probably one of the more rare steps in the process, as many Windows-using software developers tend to use it for other things. > People that can't check out and build their own version of Python are > > quite welcome to simply report issues without trying to fix them > > themselves. > > But if they really want for an issue to be fixed, they will need to > think about preparing a patch. This is not true at all. It's perfectly acceptable to report an issue and do nothing further. It certainly helps the process to contribute more, but we're happy to just get valid bug reports. Someone even made it easy enough to email report at bugs.python.org so you don't even have to create an account. > The first time they ask about plans to > fix the issue, they will be asked to send a patch anyway. We don't want bugs to linger, but there's only so many developers and so little time. If you want to know when something will be fixed, a lot of people will say something like "I won't be able to get to this next week, unless you have a patch of your own". I don't see anything wrong with that. In fact, it's pretty common in open source. This person > will look into devguide how to send a patch. There will be > instructions to download Visual Studio, clone repository, compile, > etc. I doubt this person will have time to do this, but next time the > person will think twice before reporting. I've found quite the opposite to be true. The dev guide I wrote for PSF Sprints, most of which was absorbed into the recently created http://docs.python.org/devguide/, got many people happily setup to contribute and I expect the new one to do the same. In fact, I've heard comments from a number of people that the setup was much easier than they thought, especially compared to other projects. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phd at phdru.name Wed Feb 2 21:34:13 2011 From: phd at phdru.name (Oleg Broytman) Date: Wed, 2 Feb 2011 23:34:13 +0300 Subject: [Python-Dev] xmlrpclib and communication verbosity In-Reply-To: References: Message-ID: <20110202203413.GE16949@iskra.aviel.ru> On Wed, Feb 02, 2011 at 03:52:17PM +0200, Erez Sh wrote: > Also, ServerProxy should accept an optional output file (=a class with > write,writelines methods), which will be the target of all prints. Why not logging? Oleg. -- Oleg Broytman http://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From martin at v.loewis.de Wed Feb 2 22:07:31 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 02 Feb 2011 22:07:31 +0100 Subject: [Python-Dev] Python merge module In-Reply-To: References: Message-ID: <4D49C793.40507@v.loewis.de> Am 02.02.2011 20:01, schrieb Hoyt, David: > Is there or will there be support for python merge modules so we can > include python in our installer? I haven't planned any. Contributions are welcome. > But has there been thought towards migrating away from msilib and using > platform standard tools such as wix (used by ms office, visual studio, > etc.)? Are you sure visual studio uses wix? I wouldn't call it a "platform standard tool". The Installer COM object is the platform standard mechanism, and that's what msilib uses. I really see no need to move away from that - it can create arbitrary MSI files. Regards, Martin From hoyt6 at llnl.gov Wed Feb 2 22:27:07 2011 From: hoyt6 at llnl.gov (Hoyt, David) Date: Wed, 2 Feb 2011 13:27:07 -0800 Subject: [Python-Dev] Python merge module In-Reply-To: <4D49C793.40507@v.loewis.de> References: <4D49C793.40507@v.loewis.de> Message-ID: >> Is there or will there be support for python merge modules so we can >> include python in our installer? > >I haven't planned any. Contributions are welcome. > >> But has there been thought towards migrating away from msilib and using >> platform standard tools such as wix (used by ms office, visual studio, >> etc.)? > >Are you sure visual studio uses wix? The visual studio regularly contributes to the wix toolset. They and the .net framework team contributed a lot of the wix bootstrapper (burn) foundational code. > I wouldn't call it a "platform standard tool". It's becoming that as more and more projects are adopting it. It was considered to be shipped w/ VS 2010 but didn't make it due to management/time issues. > The Installer COM object is the platform standard mechanism, and that's what msilib uses. Why maintain a lib when there's (better), free alternatives out there that are maintained by Microsoft itself? (okay, a group at Microsoft that works on their free time, but has significant contributions by many teams at Microsoft -- thus they have a vested interested in its success). > I really see no need to move away from that - it can create arbitrary MSI files. Can it create merge modules? Transform files (e.g. localization)? Bootstrappers? There's a lot more to ms installers than the msi itself. Wouldn't it be easier to maintain an XML file than an entire lib dedicated to something that someone else has already solved? From merwok at netwok.org Wed Feb 2 23:01:24 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Wed, 02 Feb 2011 23:01:24 +0100 Subject: [Python-Dev] [Python-checkins] r88323 - in python/branches/release31-maint: Lib/configparser.py Misc/NEWS In-Reply-To: <20110202213549.1CE8BEEA55@mail.python.org> References: <20110202213549.1CE8BEEA55@mail.python.org> Message-ID: <4D49D434.4070400@netwok.org> Hello, > --- python/branches/release31-maint/Lib/configparser.py (original) > +++ python/branches/release31-maint/Lib/configparser.py Wed Feb 2 22:35:48 2011 > @@ -88,7 +88,7 @@ > """ > > try: > - from collections import OrderedDict as _default_dict > + from collections import Mapping, OrderedDict as _default_dict > except ImportError: > # fallback for setup.py which hasn't yet built _collections > _default_dict = dict Buildbots can?t compile after that change, because Mapping is not found. I suggest aliasing Mapping to dict in the except block (untested). Regards From murman at gmail.com Wed Feb 2 23:16:33 2011 From: murman at gmail.com (Michael Urman) Date: Wed, 2 Feb 2011 16:16:33 -0600 Subject: [Python-Dev] Python merge module In-Reply-To: References: <4D49C793.40507@v.loewis.de> Message-ID: On Wed, Feb 2, 2011 at 15:27, Hoyt, David wrote: >> The Installer COM object is the platform standard mechanism, and that's what msilib uses. > > Why maintain a lib when there's (better), free alternatives out there that are maintained by Microsoft itself? (okay, a group at Microsoft that works on their free time, but has significant contributions by many teams at Microsoft -- thus they have a vested interested in its success). > >> I really see no need to move away from that - it can create arbitrary MSI files. > > Can it create merge modules? Transform files (e.g. localization)? Bootstrappers? There's a lot more to ms installers than the msi itself. Wouldn't it be easier to maintain an XML file than an entire lib dedicated to something that someone else has already solved? If Python was starting at ground zero, and the choices were to create a library or to use WiX, the answer might have been different. However with a mature enough library to suit all the needs that anyone has been willing to author, it's certainly more work to create the WiX install and maintain it than it is to merely maintain the existing scripts. As far as the possibility of distributing Python as a merge module? I'd recommend against it. Shared location merge modules are a maintenance nightmare, and private location merge modules may not offer the benefit you need. Better to just install the main Python msi as part of a suite with your installer, whether you build that installer in WiX and burn, or not. Michael From ncoghlan at gmail.com Thu Feb 3 00:00:11 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 3 Feb 2011 09:00:11 +1000 Subject: [Python-Dev] alternate fix for urllib2 bug #8797 In-Reply-To: References: <4E27C7B0-0301-4027-B342-EEF7E7A07F52@gmail.com> Message-ID: On Thu, Feb 3, 2011 at 2:13 AM, Alexander Belopolsky wrote: > On Wed, Feb 2, 2011 at 10:55 AM, Sam Bull wrote: >>.. ?I'm writing to lobby for bug #8797's fix to be removed and for my fix to put in in its place. > > Please open a separate issue for your patch. ?Patches attached to > closed issues will be lost. Antoine reopened it, so that shouldn't be an issue. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From martin at v.loewis.de Thu Feb 3 00:01:36 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Thu, 03 Feb 2011 00:01:36 +0100 Subject: [Python-Dev] Python merge module In-Reply-To: References: <4D49C793.40507@v.loewis.de> Message-ID: <4D49E250.2070207@v.loewis.de> >> The Installer COM object is the platform standard mechanism, and >> that's what msilib uses. > > Why maintain a lib when there's (better), free alternatives out there > that are maintained by Microsoft itself? Using msilib is easier than using Wix. It's also more flexible. All you have to know is how the MSI schema works. >> I really see no need to move away from that - it can create >> arbitrary MSI files. > > Can it create merge modules? Transform files (e.g. localization)? It could easily be extended to do so, in a straight-forward manner. > Bootstrappers? Not sure what this is - if it is what I think it is, there is no need to (actually, there is no need to create the other two types of files, either, as it stands). > There's a lot more to ms installers than the msi > itself. Wouldn't it be easier to maintain an XML file than an entire > lib dedicated to something that someone else has already solved? Definitely not. Python is easier than XML. If you think otherwise, feel free to provide a proof in the form of a Wix installation generator for Python. Regards, Martin From brett at python.org Thu Feb 3 00:05:36 2011 From: brett at python.org (Brett Cannon) Date: Wed, 2 Feb 2011 15:05:36 -0800 Subject: [Python-Dev] Moving stuff out of Misc and over to the devguide In-Reply-To: <4D49B4F3.9000503@netwok.org> References: <20110117215440.122bef7b@pitrou.net> <4D36E118.40008@netwok.org> <7e9e0831fbf09c304e9f358b406f43b8.squirrel@mail.trueblade.com> <4D49B4F3.9000503@netwok.org> Message-ID: On Wed, Feb 2, 2011 at 11:48, ?ric Araujo wrote: > Le 19/01/2011 18:04, Georg Brandl a ?crit : >> Am 19.01.2011 16:25, schrieb Eric Smith: >>>> Bonus question: if we remove maintainers.rst from py3k, what do we do in >>>> 3.1 and 2.7? ?I?d favor removing them over keeping outdated versions. >>> >>> Is there not some advantage to knowing who was the maintainer (or expert) >>> of a given module at the time of a release? >> >> I don't see much advantage. ?And if you need the version of maintainers.rst >> in another repo, it's not hard to find the revision that corresponds to the >> release date. > > Ping. ?Do we remove maintainers.rst or do we add a note advising people > to look at the up-to-date version on docs.python.org/devguide? > > (And yes, by ?we? I mean I?m volunteering to do either. :) You're a little late, Eric; I already moved it. =) From ncoghlan at gmail.com Thu Feb 3 00:07:31 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 3 Feb 2011 09:07:31 +1000 Subject: [Python-Dev] [Python-checkins] r88324 - in python/branches/release31-maint: Doc/library/trace.rst Lib/distutils/tests/__init__.py Lib/distutils/tests/test_archive_util.py Lib/distutils/tests/test_bdist.py Lib/distutils/tests/test_bdist_dumb.py Lib/distutils/t Message-ID: On Thu, Feb 3, 2011 at 7:38 AM, eric.araujo wrote: > Author: eric.araujo > Date: Wed Feb ?2 22:38:37 2011 > New Revision: 88324 > > Log: > Merged revisions 86236,86240,86332,86340,87271,87273,87447 via svnmerge from > svn+ssh://pythondev at svn.python.org/python/branches/py3k > > The missing NEWS entries correspond to changes that were made before 3.1.3, but > I think it?s not usual to edit entries of released versions, so I put them at > the top. The only reason it isn't usual is because the change normally goes in at roughly the same time as the NEWS update, so it is very rare to have a change in a release without the corresponding NEWS entry. If NEWS entries get missed for the release, better to add them in the right place afterwards (it's easy enough to tell which entries were originally missing by comparing the NEWS file from source control with the one from the release). Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From janssen at parc.com Thu Feb 3 00:28:23 2011 From: janssen at parc.com (Bill Janssen) Date: Wed, 2 Feb 2011 15:28:23 PST Subject: [Python-Dev] Python merge module In-Reply-To: <4D49C793.40507@v.loewis.de> References: <4D49C793.40507@v.loewis.de> Message-ID: <16245.1296689303@parc.com> Martin v. L?wis wrote: > The Installer COM object is the platform standard > mechanism, and that's what msilib uses. I really see no need to move > away from that - it can create arbitrary MSI files. I've used it to package UpLib for Windows -- see http://uplib.parc.com/hg/uplib/file/e29e36f751f7/win32/build-msi-installer.py. I've generalized some of Martin's code to create a Packager class which supports non-Python pre and post install scripts. I found it much easier to use than WiX, which I also tried. Bill From merwok at netwok.org Thu Feb 3 00:34:16 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Thu, 03 Feb 2011 00:34:16 +0100 Subject: [Python-Dev] [Python-checkins] r88324 - in python/branches/release31-maint: Doc/library/trace.rst Lib/distutils/tests/__init__.py Lib/distutils/tests/test_archive_util.py Lib/distutils/tests/test_bdist.py Lib/distutils/tests/test_bdist_dumb.py Lib/distutils/t In-Reply-To: References: Message-ID: <4D49E9F8.8010900@netwok.org> Thanks Nick, I moved the entries. Cheers From brett at python.org Thu Feb 3 01:37:43 2011 From: brett at python.org (Brett Cannon) Date: Wed, 2 Feb 2011 16:37:43 -0800 Subject: [Python-Dev] [Python-checkins] devguide: Add a document discussing the development cycle typically followed for In-Reply-To: References: Message-ID: all fixed On Wed, Feb 2, 2011 at 03:04, Sandro Tosi wrote: > On Wed, Jan 26, 2011 at 23:20, brett.cannon wrote: >> +The in-development branch is where new functionality and semantic changes > > new functionalities (dunno if it's plural in english or not)? > >> +occur. Currently this branch is known as the "py3k" branch. The next minor >> +release of Python will come from this branch (major releases are once a decade >> +and so have no specific rules on how they are started). All changes land in this >> +branch and then trickle down to other branches. >> + >> +Once a Final_ release is made from the in-development branch, a branch is made >> +to represent the minor version of Python and it goes into maintenance mode. >> +Typically a minor version of Python is under development for about 18 months. >> + >> + >> +Maintenance >> +----------- >> +The branch currently being maintained for bug fixes. >> + >> +The branch under maintenance is the last minor version of Python to be released >> +as Final_. This means that the latest release of Python was 3.1.2, then the > > if the latest release ? > >> +branch representing Python 3.1 is in maintenance mode. >> + >> +The only changes allowed to occur in a maintenance branch without debate are bug >> +fixes. >> +Semantic changes **must** be carefully considered as code out in the world will >> +have already been developed that will rely on the released semantics. Changes >> +related to semantics should be discussed on python-dev before being made. >> + >> +A branch stays in maintenance mode as long as a new minor release has not been >> +made. For example, this means that Python 2.6 stayed in maintenance mode until >> +Python 2.7.0 was released, at which point 2.7 went into maintenance mode and >> +2.6 went into Security_ mode. As new minor releases occur on a (roughly) 18 >> +month schedule, a branch stays in mainteance mode for the same amount of time. > > s/mainteance/maintenance/ > >> + >> +A micro release of a maintenance branch is made about every six months. >> +Typically when a new minor release is made one more release of the new-old >> +version of Python is made. >> + >> + >> +Security >> +-------- >> +A branch less than five years old but no longer in maintenance mode. >> + >> +The only changes made to a branch that is being maintained for security >> +purposes are somewhat obviously those related to security, e.g., privilege >> +escalation. Crashers and other behaviorial issues are **not** considered a > > s/Crashers/Crashes/ > s/behaviorial/behavioral/ > >> +security risk and thus not backported to a branch being maintained for >> +security. Any releases made for a branch under security maintenance is > > s/releases/release/ ? > s/for/from/ > >> +source-only and done only when actual security patches have been applied to the >> +branch. >> + >> + >> +Stages >> +'''''' >> + >> +Based on what stage the in-development version of Python is in, the >> +responsibilities of a core developer change in regards to commits to the VCS. >> + >> + >> +Pre-alpha >> +--------- >> +This is the stage a branch is in from the last final release until the first >> +alpha (a1). There are no special restrictions placed on commits beyond those >> +imposed by the type of branch being worked on (e.g., in-development vs. >> +maintenance). >> + >> + >> +Alpha >> +----- >> +Alphas typically serve as a reminder to core developers that they need to start >> +getting in changes that change semantics or add something to Python as such >> +things should not be added during a Beta_. Otherwise no new restrictions are in >> +place while in alpha. >> + >> + >> +Beta >> +---- >> +A branch in beta means that no new additions to Python are accepted. Bugfixes >> +and the like are still fine. Being in beta can be viewed much like being in RC_ >> +but without the extra overhead of needing commit reviews. >> + >> + >> +.. _RC: >> + >> +Release Candidate (RC) >> +---------------------- >> +A branch preparing for an RC release can only have bugfixes applied that have >> +been reviewed by other core developers. That reviewer should make a post to the >> +issue related to the change and be mentioned in the commit message. >> + >> +You **cannot** skip the peer review during an RC, no matter how small! Even if >> +it is a simple copy-and-paste change, **everything** requires peer review from >> +a core developer. >> + >> + >> +Final >> +----- >> +When a final release is being cut, only the release manager (RM) can make >> +changes to the branch. >> diff --git a/index.rst b/index.rst >> --- a/index.rst >> +++ b/index.rst >> @@ -20,6 +20,7 @@ >> ? ?coredev >> ? ?developers >> ? ?committing >> + ? devcycle >> >> ? ?stdlibchanges >> ? ?langchanges >> @@ -64,6 +65,7 @@ >> ?* :ref:`coredev` >> ? ? * :ref:`developers` >> ? ? * :ref:`committing` >> + ? ?* :ref:`devcycle` >> >> >> ?Proposing changes to Python itself >> >> -- >> Repository URL: http://hg.python.org/devguide >> _______________________________________________ >> Python-checkins mailing list >> Python-checkins at python.org >> http://mail.python.org/mailman/listinfo/python-checkins >> >> > > > > -- > Sandro Tosi (aka morph, morpheus, matrixhasu) > My website: http://matrixhasu.altervista.org/ > Me at Debian: http://wiki.debian.org/SandroTosi > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org > From hoyt6 at llnl.gov Thu Feb 3 02:30:43 2011 From: hoyt6 at llnl.gov (Hoyt, David) Date: Wed, 2 Feb 2011 17:30:43 -0800 Subject: [Python-Dev] Python merge module In-Reply-To: <4D49E250.2070207@v.loewis.de> References: <4D49C793.40507@v.loewis.de> <4D49E250.2070207@v.loewis.de> Message-ID: > Using msilib is easier than using Wix. It's also more flexible. IMO, no. It's simply not. > All you have to know is how the MSI schema works. Same with WiX. > It could easily be extended to do so, in a straight-forward manner. Other packaging apps already have it - no work needed. > (actually, there is no need to create the other two types of files, either, as it stands). Sure there is. Transform files + bootstrappers give you localizable installs in one flat file. > Definitely not. Python is easier than XML. I disagree. > If you think otherwise, feel free to provide a proof in the form of a Wix installation generator for Python. If you think otherwise, why don't you provide proof and get the WiX guys to switch to Python and use your msilib package? The point is that your argument is nonsensical. I'm really not trying to start a flame war here (my original post only asked if there was "thought towards migrating away from msilib"). There's legitimate need/desire for a merge module to make it easier to package a specific Python version. I can (and am) including it in the bootstrapper, but it would make things much cleaner to simply have a merge module available. If the answer's "no and we don't ever intend to", then that's perfectly fine. (c: I really don't care to argue the merits or virtues of WiX vs. msilib and I apologize if I came across as doing that -- I simply was interested to know if there's any serious thought in the matter and it turns out that people are perfectly happy w/ msilib. From hoyt6 at llnl.gov Thu Feb 3 02:40:49 2011 From: hoyt6 at llnl.gov (Hoyt, David) Date: Wed, 2 Feb 2011 17:40:49 -0800 Subject: [Python-Dev] Python merge module In-Reply-To: References: <4D49C793.40507@v.loewis.de> Message-ID: > If Python was starting at ground zero, and the choices were to create > a library or to use WiX, the answer might have been different. > However with a mature enough library to suit all the needs that anyone > has been willing to author, it's certainly more work to create the WiX > install and maintain it than it is to merely maintain the existing > scripts. Sounds reasonable. > As far as the possibility of distributing Python as a merge module? > I'd recommend against it. Shared location merge modules are a > maintenance nightmare, and private location merge modules may not > offer the benefit you need. Better to just install the main Python msi > as part of a suite with your installer, whether you build that > installer in WiX and burn, or not. I'm not familiar w/ shared location merge modules vs. private location merge modules. Are you referring to the possibility of having multiple python apps trying to use their own python versions? How relocatable is python? The maintenance nightmare isn't on your end (in my case), it would be on me to provide patches/upgrades. I do agree that patches w/ merge modules are a pain/nightmare. But what about providing both a merge module and msi so developers have a choice? I work on open source projects myself, and we always provide both a merge module and a normal msi installer. It's very little extra work (in WiX at least) to create both. But I can tell from this discussion that it would require changes in msilib and since I don't have the time to work on it, it would most likely not happen. Perhaps I could generate enough fervor in the community for a merge module, though, to drive msilib development. :p At any rate, where could I find the script used to generate the msi package? Perhaps I can translate it into WiX if I thought it'd be used (but why bother if no one's interested?). From hoyt6 at llnl.gov Thu Feb 3 02:43:50 2011 From: hoyt6 at llnl.gov (Hoyt, David) Date: Wed, 2 Feb 2011 17:43:50 -0800 Subject: [Python-Dev] Python merge module In-Reply-To: <16245.1296689303@parc.com> References: <4D49C793.40507@v.loewis.de> <16245.1296689303@parc.com> Message-ID: > I found it much easier to use than WiX, which I also tried. I also used to use the Visual Studio installer projects until I needed something a lot more robust (e.g., customized UI + localizable strings). msilib does the job people need it to do and that's fine. I'm really not trying to argue the merits of WiX vs. msilib. Was just wondering if it had been considered... From rdmurray at bitdance.com Thu Feb 3 03:43:09 2011 From: rdmurray at bitdance.com (R. David Murray) Date: Wed, 02 Feb 2011 21:43:09 -0500 Subject: [Python-Dev] Python merge module In-Reply-To: References: <4D49C793.40507@v.loewis.de> <4D49E250.2070207@v.loewis.de> Message-ID: <20110203024309.CE186242900@kimball.webabinitio.net> On Wed, 02 Feb 2011 17:30:43 -0800, "Hoyt, David" wrote: > > Definitely not. Python is easier than XML. > > I disagree. Just as an FYI, I believe that most people in the Python community find XML much more of a pain than Python. Many of us (especially those of us who are not web developers) avoid XML whenever possible, and when we do have to deal with it we tend to abstract it behind easier to work with Python code. The obvious exception to that would be web templating languages, but I personally prefer to avoid those, as well :) -- R. David Murray www.bitdance.com From martin at v.loewis.de Thu Feb 3 07:10:26 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Thu, 03 Feb 2011 07:10:26 +0100 Subject: [Python-Dev] Python merge module In-Reply-To: References: <4D49C793.40507@v.loewis.de> <4D49E250.2070207@v.loewis.de> Message-ID: <4D4A46D2.8090304@v.loewis.de> > I'm really not trying to start a flame war here (my original post > only asked if there was "thought towards migrating away from > msilib"). There's legitimate need/desire for a merge module to make > it easier to package a specific Python version. Please recognize that this question is entirely independent of the question whether Wix is used or not. I'm personally +0 on providing a merge module (although others are apparently opposed to that idea). As for msilib vs. Wix: yes, I did put thought into this (actually originally also when writing msilib, which slightly predates Wix in time). However, I don't see any need to switch, and I actually do believe that Wix couldn't provide a feature-by-feature full replacement of the current packaging code (but I might be wrong). Regards, Martin From martin at v.loewis.de Thu Feb 3 07:30:40 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Thu, 03 Feb 2011 07:30:40 +0100 Subject: [Python-Dev] Python merge module In-Reply-To: References: <4D49C793.40507@v.loewis.de> Message-ID: <4D4A4B90.8030700@v.loewis.de> >> As far as the possibility of distributing Python as a merge >> module? I'd recommend against it. Shared location merge modules are >> a maintenance nightmare, and private location merge modules may >> not offer the benefit you need. Better to just install the main >> Python msi as part of a suite with your installer, whether you >> build that installer in WiX and burn, or not. > > I'm not familiar w/ shared location merge modules vs. private > location merge modules. Are you referring to the possibility of > having multiple python apps trying to use their own python versions? > How relocatable is python? Fairly relocatable. If there is was a merge module, I'd really prefer it to be shared. The challenge here is site-packages: different users of the merge module would need different copies of site-packages (or else installing additional packages might break existing software). Another challenge with shared location merge modules is upgrades: the Python installer currently doesn't use stable component IDs; I think this would cause problems for users of the merge module. Providing stable component IDs is a challenge since it's difficult to version the files on disk. Not sure why Michael thinks that a private location merge module would provide no benefits to the user of the merge module. > The maintenance nightmare isn't on your > end (in my case), it would be on me to provide patches/upgrades. I do > agree that patches w/ merge modules are a pain/nightmare. But what > about providing both a merge module and msi so developers have a > choice? I certainly wouldn't stop providing an MSI. The next question would be whether the MSI then also installs into the shared location, or whether it would have a private copy of Python. > I work on open source projects myself, and we always provide > both a merge module and a normal msi installer. It's very little > extra work (in WiX at least) to create both. But what's the quality of these? Ideally, I'd like to create a single merge module which, at the option of the user of the merge module, produces either a shared or a private installation. Is that still only little extra work in Wix? > At any rate, where could I find the script used to generate the msi > package? Perhaps I can translate it into WiX if I thought it'd be > used (but why bother if no one's interested?). It's in Tools/msi/msi.py. Regards, Martin From erez27 at gmail.com Thu Feb 3 10:32:17 2011 From: erez27 at gmail.com (Erez Sh) Date: Thu, 3 Feb 2011 11:32:17 +0200 Subject: [Python-Dev] xmlrpclib and communication verbosity Message-ID: Oleg wrote: > Why not logging? > It seems to me that most of python's library modules don't use the logging module, and I didn't want to make style judgments. I actually prefer logging. -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.stinner at haypocalc.com Thu Feb 3 14:05:06 2011 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Thu, 03 Feb 2011 14:05:06 +0100 Subject: [Python-Dev] News of the faulthandler project Message-ID: <1296738306.19440.20.camel@marge> Hi, Since the end of last december, I'm still working on my fault handler project: https://github.com/haypo/faulthandler You can use it to get more information after a crash or if you program hangs somewhere. It helps if you don't have access to other debugging tool (eg. install gdb7+python-gdb.py on Windows is not trivial today) or if you cannot interact with your program (eg. on a buildbot). The last version works on Python 2.5, 2.6, 2.7, 3.1 and 3.2, on Windows, Linux and FreeBSD. It can display the Python backtrace on a fatal fault (SIGSEGV, SIGFPE, SIGILL, SIGBUS), after a delay in seconds, when an user signal is received (eg. SIGUSR1) or explicitly (call directly the dumpbacktrace() function). By default, it is disabled: you have to call faulthandler.enable() to install the signal handlers. You can choose in which file the backtrace is written (sys.stderr by default) and if it displays the backtrace of the current thread or of all threads. If you use the delay: you can choose to repeat the operation (dump the backtrace each delay seconds). The project is now a module, so it is no more enabled by default. It is more configurable, and has more features. It has a better API (so it was a good idea to not include it in Python 3.2). I plan to integrate this project into Python 3.3. I hope that it can help to debug some buildbots issues, but also any segfault in your programs. Note: faulthandler.register() (dump the backtrace when an user signal is raised) is only available in the development version. -- The project is not perfect yet: - I have to write something to be able to enable the faulthandler before starting your program (write a program for that?) - faulthandler.dumpbacktrace_later() uses alarm() which interrupts the current system call when SIGALARM is raised: it may be a problem (it's maybe not a problem if you try to debug a program hang) - I don't know if something should be done on a fork() - SIGABRT is not handled - The module is unloaded using Py_AtExit(): it cannot release references because the unload function is called too late -- There are similar projects, tipper and crier, using a signal handler implemented in Python or a signal handler implemented in Python. These projects give more information (eg. local variables) and more control on how the informations are written, but I think that there are less reliable: it doesn't work if Python hangs (eg. deadlock) and signal handlers implemented in Python are asynchronous. And there are unable to catch fatal faults (eg. SIGSEGV). http://pypi.python.org/pypi/tipper/ https://gist.github.com/737056 Victor From ncoghlan at gmail.com Thu Feb 3 15:14:30 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 4 Feb 2011 00:14:30 +1000 Subject: [Python-Dev] News of the faulthandler project In-Reply-To: <1296738306.19440.20.camel@marge> References: <1296738306.19440.20.camel@marge> Message-ID: On Thu, Feb 3, 2011 at 11:05 PM, Victor Stinner wrote: > ?- I have to write something to be able to enable the faulthandler > before starting your program (write a program for that?) I don't know enough about signal handling to help with your other remaining concerns, but an appropriate "-X" command line option seem like a reasonable way to activate it before main starts running (-X is currently documented as reserved for use by other implementations, but it's really more a "implementation dependent options" marker) (+1 on the general idea, though) Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From murman at gmail.com Thu Feb 3 16:38:28 2011 From: murman at gmail.com (Michael Urman) Date: Thu, 3 Feb 2011 09:38:28 -0600 Subject: [Python-Dev] Python merge module In-Reply-To: <4D4A4B90.8030700@v.loewis.de> References: <4D49C793.40507@v.loewis.de> <4D4A4B90.8030700@v.loewis.de> Message-ID: On Thu, Feb 3, 2011 at 00:30, "Martin v. L?wis" wrote: > Another challenge with shared location merge modules is upgrades: > the Python installer currently doesn't use stable component IDs; > I think this would cause problems for users of the merge module. > Providing stable component IDs is a challenge since it's difficult > to version the files on disk. > > Not sure why Michael thinks that a private location merge module > would provide no benefits to the user of the merge module. I hadn't thought it through fully, but the preceding paragraph really gets to the core of the problem. The maintenance nightmare is security updates for private location installations by third parties. The only MSI-friendly way to update that code is through releasing an updated merge module and having the consuming application also release an update that uses it. Since Python's components use fresh GUIDs each time, this would require a "major" upgrade; "minor" upgrades would cause Windows Installer to throw fits. Technically this is a problem with the component generation in Python, and for that in particular, a move to WiX could be very helpful. They have stable component code generation which keys off of location, name, platform, etc., but only works for single-file components. For contrast, I don't see a shared-location merge module as offering benefits beyond a silently redistributable msi package. The shared location is better about following component code rules (re-use in private areas is an allowed gray area), and there are people out there who consider the reference counting through merge modules to be superior. I find the resulting complexity in the consuming package's installation to be more of a down-side. >> I work on open source projects myself, and we always provide >> both a merge module and a normal msi installer. It's very little >> extra work (in WiX at least) to create both. > > But what's the quality of these? Ideally, I'd like to create a single > merge module which, at the option of the user of the merge module, > produces either a shared or a private installation. Is that still > only little extra work in Wix? I've never tried to make a configurable merge module in WiX, but I think that's the only option if you want a single merge module to allow both. It should be a one-time authoring overhead with [1]. Using them is pretty straightforward within the Merge elements [2]. [1] http://wix.sourceforge.net/manual-wix3/wix_xsd_configuration.htm [2] http://wix.sourceforge.net/manual-wix2/wix_xsd_configurationdata.htm Michael From smiwa.egon at googlemail.com Thu Feb 3 16:43:20 2011 From: smiwa.egon at googlemail.com (Egon Smiwa) Date: Thu, 03 Feb 2011 16:43:20 +0100 Subject: [Python-Dev] Py_tp_getset in ABI? Message-ID: <4D4ACD18.50603@googlemail.com> Hi all, I'm trying to convert my embedding code to your new ABI, but I cannot find the ABI slot for tp_getset in typeslots.h (while tp_methods are supported). Is the support of tp_getset not yet determined? (Because I cannot find this in the PEP 384) Thank you! From reid.kleckner at gmail.com Thu Feb 3 18:22:28 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Thu, 3 Feb 2011 12:22:28 -0500 Subject: [Python-Dev] News of the faulthandler project In-Reply-To: <1296738306.19440.20.camel@marge> References: <1296738306.19440.20.camel@marge> Message-ID: On Thu, Feb 3, 2011 at 8:05 AM, Victor Stinner wrote: > ?- SIGABRT is not handled Why not? That seems useful for debugging assertion failures, although most C code in Python raises exceptions rather than asserting. I'm guessing it's because it aborts the process after printing the backtrace. You could just clear the signal handler before aborting. Reid From flub at devork.be Thu Feb 3 18:58:31 2011 From: flub at devork.be (Floris Bruynooghe) Date: Thu, 3 Feb 2011 17:58:31 +0000 Subject: [Python-Dev] Python merge module In-Reply-To: References: <4D49C793.40507@v.loewis.de> <4D4A4B90.8030700@v.loewis.de> Message-ID: On 3 February 2011 15:38, Michael Urman wrote: > Technically this is a problem with the component generation in Python, > and for that in particular, a move to WiX could be very helpful. They > have stable component code generation which keys off of location, > name, platform, etc., but only works for single-file components. At work we keep the required stable UUIDs in an ConfigParser-format file checked in to the VCS for that purpose. FWIW our build system uses WiX (v2) currently and if I where to redo it, I'd change to msilib and not WiX v3. But never change working systems. Python.org supplied merge modules would be nice though, if the upgrade/security issue can be resolved. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From victor.stinner at haypocalc.com Thu Feb 3 21:52:40 2011 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Thu, 03 Feb 2011 21:52:40 +0100 Subject: [Python-Dev] News of the faulthandler project In-Reply-To: References: <1296738306.19440.20.camel@marge> Message-ID: <1296766360.27124.15.camel@marge> Le jeudi 03 f?vrier 2011 ? 12:22 -0500, Reid Kleckner a ?crit : > On Thu, Feb 3, 2011 at 8:05 AM, Victor Stinner > wrote: > > - SIGABRT is not handled > > Why not? Just because I forgot to handle it. But I don't know if it is a good thing to display the Python backtrace on abort() or not. Python uses abort() on Py_FatalError(). Victor From hoyt6 at llnl.gov Thu Feb 3 22:03:13 2011 From: hoyt6 at llnl.gov (Hoyt, David) Date: Thu, 3 Feb 2011 13:03:13 -0800 Subject: [Python-Dev] Python merge module In-Reply-To: References: <4D49C793.40507@v.loewis.de> <4D4A4B90.8030700@v.loewis.de> Message-ID: > I hadn't thought it through fully, but the preceding paragraph really > gets to the core of the problem. The maintenance nightmare is security > updates for private location installations by third parties. The only > MSI-friendly way to update that code is through releasing an updated > merge module and having the consuming application also release an > update that uses it. Since Python's components use fresh GUIDs each > time, this would require a "major" upgrade; "minor" upgrades would > cause Windows Installer to throw fits. That's exactly right and why I said earlier that patches w/ merge modules are a pain/nightmare. But I also said that the security patching w/ a merge module would then depend on the party who has integrated the merge module into their product -- not on you guys. I don't think most (or any) parties are trying to do incremental minor updates w/ python right now anyway. With us, we just want a single, well-tested and known python implementation installed w/ our product -- we basically don't trust the user to get the right version and install it correctly. You obviously can't hold their hand every step of the way, at some point you have to let go -- but this is one thing that we could possibly control. > Technically this is a problem with the component generation in Python, > and for that in particular, a move to WiX could be very helpful. They > have stable component code generation which keys off of location, > name, platform, etc., but only works for single-file components. The general recommendation regarding msi packages is that you always, always do single-file components (one of the major reasons being for patching purposes). If you use WiX' heat application to autogenerate WiX files from directories, you'll see that it always produces single-file components. > For contrast, I don't see a shared-location merge module as offering > benefits beyond a silently redistributable msi package. The shared > location is better about following component code rules (re-use in > private areas is an allowed gray area), and there are people out there > who consider the reference counting through merge modules to be > superior. I find the resulting complexity in the consuming package's > installation to be more of a down-side. I think a merge module (shared or private) generally reduces complexity unless you already have a bootstrapper for other packages. Including one in WiX is very simple (if you're already familiar w/ msi's): If you use something like the VS installer projects, you just have to use the GUI to add a reference to it and you're done. A shared merge module might pose a problem if you want to have multiple python versions installed. At the least, you'd need to change the component guid w/ each major release (e.g. 2.x -> 3.x, but not 2.7 -> 2.8 -> 2.9, etc.). I'd recommend w/ sticking to a private one that doesn't modify the PATH (should you choose to create one) and then you're free to keep or change the component guids. Can python operate inside a sandboxed C:\Program Files\\ directory? > I've never tried to make a configurable merge module in WiX, but I > think that's the only option if you want a single merge module to > allow both. It should be a one-time authoring overhead with [1]. Using > them is pretty straightforward within the Merge elements [2]. > > [1] http://wix.sourceforge.net/manual-wix3/wix_xsd_configuration.htm > [2] http://wix.sourceforge.net/manual-wix2/wix_xsd_configurationdata.htm I wouldn't try to make it configurable (nor does it really need to be) beyond what it already should do -- that is, just be able to set the base target directory, which is already done for you. And as I just suggested, I wouldn't go for both -- declare the merge module to be private and that's that. From hoyt6 at llnl.gov Thu Feb 3 22:15:28 2011 From: hoyt6 at llnl.gov (Hoyt, David) Date: Thu, 3 Feb 2011 13:15:28 -0800 Subject: [Python-Dev] Python merge module In-Reply-To: References: <4D49C793.40507@v.loewis.de> <4D4A4B90.8030700@v.loewis.de> Message-ID: > At work we keep the required stable UUIDs in an ConfigParser-format > file checked in to the VCS for that purpose. > > FWIW our build system uses WiX (v2) currently and if I where to redo > it, I'd change to msilib and not WiX v3. But never change working > systems. No need to do that if you're using heat -- I haven't used WiX v2 so I can't speak to its relative merits, but v3.5 (which was just officially released) is pretty good and much more feature complete (according to rob mensching's blog). I'd recommend re-evaluating it. I'm not a Microsoft fanboy, btw. But I am getting my group (or trying to, at least) to migrate away from older, stale installer projects (e.g. Visual Studio will be dropping support for any further installer project improvements in the future) and into WiX because that's where the momentum is and it also keeps up-to-date w/ the latest msi changes. That and I was tired of the install looking like an intern did it (no offense to interns -- I was one once. (c: ). A good, polished product should (IMO) also have a good, polished installer. Especially since that's one of the customer's first views/impressions of your product. > Python.org supplied merge modules would be nice though, if the > upgrade/security issue can be resolved. Good to know I'm not entirely alone. (c: From martin at v.loewis.de Thu Feb 3 22:18:37 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Thu, 03 Feb 2011 22:18:37 +0100 Subject: [Python-Dev] Python merge module In-Reply-To: References: <4D49C793.40507@v.loewis.de> <4D4A4B90.8030700@v.loewis.de> Message-ID: <4D4B1BAD.8050308@v.loewis.de> > Technically this is a problem with the component generation in Python, > and for that in particular, a move to WiX could be very helpful. They > have stable component code generation which keys off of location, > name, platform, etc., but only works for single-file components. That would be no reason to move to Wix. Integrating the same algorithm in msilib is trivial. Regards, Martin From martin at v.loewis.de Thu Feb 3 22:22:32 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Thu, 03 Feb 2011 22:22:32 +0100 Subject: [Python-Dev] Python merge module In-Reply-To: References: <4D49C793.40507@v.loewis.de> <4D4A4B90.8030700@v.loewis.de> Message-ID: <4D4B1C98.90208@v.loewis.de> Am 03.02.2011 18:58, schrieb Floris Bruynooghe: > On 3 February 2011 15:38, Michael Urman wrote: >> Technically this is a problem with the component generation in Python, >> and for that in particular, a move to WiX could be very helpful. They >> have stable component code generation which keys off of location, >> name, platform, etc., but only works for single-file components. > > At work we keep the required stable UUIDs in an ConfigParser-format > file checked in to the VCS for that purpose. That's also the path I'd take. But I'm unsure how versioning would work, in particular if I have per-directory components, and files get added (which typically shouldn't, but might happen in bugfix releases). Regards, Martin From solipsis at pitrou.net Thu Feb 3 22:25:46 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 3 Feb 2011 22:25:46 +0100 Subject: [Python-Dev] News of the faulthandler project References: <1296738306.19440.20.camel@marge> <1296766360.27124.15.camel@marge> Message-ID: <20110203222546.61e24fda@pitrou.net> On Thu, 03 Feb 2011 21:52:40 +0100 Victor Stinner wrote: > Le jeudi 03 f?vrier 2011 ? 12:22 -0500, Reid Kleckner a ?crit : > > On Thu, Feb 3, 2011 at 8:05 AM, Victor Stinner > > wrote: > > > - SIGABRT is not handled > > > > Why not? > > Just because I forgot to handle it. But I don't know if it is a good > thing to display the Python backtrace on abort() or not. Python uses > abort() on Py_FatalError(). I think that precisely makes it a good idea. It's much better to know where a fatal error was triggered from if you want to have a chance of at least working around it. Regards Antoine. From martin at v.loewis.de Thu Feb 3 22:33:14 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Thu, 03 Feb 2011 22:33:14 +0100 Subject: [Python-Dev] Python merge module In-Reply-To: References: <4D49C793.40507@v.loewis.de> <4D4A4B90.8030700@v.loewis.de> Message-ID: <4D4B1F1A.6030405@v.loewis.de> > The general recommendation regarding msi packages is that you always, > always do single-file components (one of the major reasons being for > patching purposes). Can you please cite a source for that recommendation? Preferably some MSDN documentation. Regards, Martin From martin at v.loewis.de Thu Feb 3 22:46:52 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Thu, 03 Feb 2011 22:46:52 +0100 Subject: [Python-Dev] Py_tp_getset in ABI? In-Reply-To: <4D4ACD18.50603@googlemail.com> References: <4D4ACD18.50603@googlemail.com> Message-ID: <4D4B224C.9070100@v.loewis.de> Am 03.02.2011 16:43, schrieb Egon Smiwa: > Hi all, > I'm trying to convert my embedding code to your new ABI, > but I cannot find the ABI slot for tp_getset in typeslots.h > (while tp_methods are supported). Is the support of tp_getset > not yet determined? Not sure what I thought - it seems that tp_getset and tp_members is plain missing. This is puzzling because I clearly meant to include PyMemberDef and PyGetSetDef (and they are included). Unless somebody reminds me why they would have to be excluded, I would like to add them still. Adding them after 3.2 would be forward-compatible (?), i.e. all modules build for 3.2 would continue to work in 3.2.1. However, modules using them would work in 3.2.1, but fail in 3.2.0 (with a RuntimeError exception) So I think I would preferably add these before 3.2 is released. Regards, Martin From hoyt6 at llnl.gov Thu Feb 3 22:48:09 2011 From: hoyt6 at llnl.gov (Hoyt, David) Date: Thu, 3 Feb 2011 13:48:09 -0800 Subject: [Python-Dev] Python merge module In-Reply-To: <4D4B1F1A.6030405@v.loewis.de> References: <4D49C793.40507@v.loewis.de> <4D4A4B90.8030700@v.loewis.de> <4D4B1F1A.6030405@v.loewis.de> Message-ID: > Can you please cite a source for that recommendation? Preferably > some MSDN documentation. http://msdn.microsoft.com/en-us/library/aa368269(v=vs.85).aspx http://wix.sourceforge.net/manual-wix3/add_a_file.htm Specifically, starting in bold, where it says "In general, you should restrict yourself to a single file per component. The Windows Installer is designed to support thousands of components in a single installer, so unless you have a very good reason, keep to one file per component. Every component must have its own unique GUID. Failure to follow these two basic rules can lead to many problems down the road when it comes to servicing." A little before that, it states: "The component element describes a set of resources (usually files, registry entries, and shortcuts) that need to be installed as a single unit. This is separate from whether the set of items consist of a logical feature the user can select to install ... While it may not seem like a big deal when you are first authoring your installer, components play a critical role when you decide to build patches at a later date." I didn't say it's a must, but experience lends you to following the recommendation. From g.brandl at gmx.net Thu Feb 3 22:56:36 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Thu, 03 Feb 2011 22:56:36 +0100 Subject: [Python-Dev] Py_tp_getset in ABI? In-Reply-To: <4D4B224C.9070100@v.loewis.de> References: <4D4ACD18.50603@googlemail.com> <4D4B224C.9070100@v.loewis.de> Message-ID: Am 03.02.2011 22:46, schrieb "Martin v. L?wis": > Am 03.02.2011 16:43, schrieb Egon Smiwa: >> Hi all, >> I'm trying to convert my embedding code to your new ABI, >> but I cannot find the ABI slot for tp_getset in typeslots.h >> (while tp_methods are supported). Is the support of tp_getset >> not yet determined? > > Not sure what I thought - it seems that tp_getset and tp_members > is plain missing. This is puzzling because I clearly meant to include > PyMemberDef and PyGetSetDef (and they are included). > > Unless somebody reminds me why they would have to be excluded, I > would like to add them still. > > Adding them after 3.2 would be forward-compatible (?), i.e. > all modules build for 3.2 would continue to work in 3.2.1. > However, modules using them would work in 3.2.1, but fail in > 3.2.0 (with a RuntimeError exception) > > So I think I would preferably add these before 3.2 is released. I'm okay with you making this fix (and the one for #11067) before 3.2.0 is released. Georg From ncoghlan at gmail.com Fri Feb 4 00:05:03 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 4 Feb 2011 09:05:03 +1000 Subject: [Python-Dev] [Python-checkins] r88331 - in python/branches/py3k/Doc/howto: index.rst pyporting.rst In-Reply-To: <20110203220155.419E3EEA35@mail.python.org> References: <20110203220155.419E3EEA35@mail.python.org> Message-ID: On Fri, Feb 4, 2011 at 8:01 AM, brett.cannon wrote: > +Capturing the Currently Raised Exception > +---------------------------------------- > +One change between Python 2 and 3 that will require changing how you code is > +accessing the currently raised exception. ?In Python 2 the syntax to access the > +current exception is:: > + > + ? ?try: > + ? ? ? ?raise Exception() > + ? ?except Exception, exc: > + ? ? ? ?# Current exception is 'exc' > + ? ? ? ?pass > + > +This syntax changed in Python 3 to:: > + > + ? ?try: > + ? ? ? ?raise Exception() > + ? ?except Exception as exc: > + ? ? ? ?# Current exception is 'exc' > + ? ? ? ?pass Note that you can write it the Python 3 way in 2.6+ as well (this was new syntax, so there weren't any backwards compatibility issues with adding it). You only need to do the sys.exc_info dance if you need to support 2.5 or earlier. Other notes: - explicit relative imports work in 2.6+ without needing a future import - absolute imports are the default in 2.7 Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From ncoghlan at gmail.com Fri Feb 4 00:10:07 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 4 Feb 2011 09:10:07 +1000 Subject: [Python-Dev] [Python-checkins] r88331 - in python/branches/py3k/Doc/howto: index.rst pyporting.rst In-Reply-To: <20110203220155.419E3EEA35@mail.python.org> References: <20110203220155.419E3EEA35@mail.python.org> Message-ID: On Fri, Feb 4, 2011 at 8:01 AM, brett.cannon wrote: > +Stop Using :mod:`doctest` > +''''''''''''''''''''''''' > +While 2to3 tries to port doctests properly, it's a rather tough thing to do. It > +is probably best to simply convert your critical doctests to :mod:`unittest`. This advice strikes me as being *way* too strong. Perhaps something like: Consider limiting use of :mod:`doctest` =============================== While 2to3 tries to port doctests properly, it's a rather tough thing to do. If your test suite is heavily doctest dependent, then you may end up spending a lot of time manually fixing doctests. The two major avenues for dealing with this are to either port doctest based tests over to the unittest module (making them significantly easier for 2to3 to handle) or else to follow the guidelines below for writing 2/3 compatible source code in all doctests (making it so they should run unmodified on both Python versions). Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From steve at pearwood.info Fri Feb 4 00:32:20 2011 From: steve at pearwood.info (Steven D'Aprano) Date: Fri, 04 Feb 2011 10:32:20 +1100 Subject: [Python-Dev] [Python-checkins] r88331 - in python/branches/py3k/Doc/howto: index.rst pyporting.rst In-Reply-To: References: <20110203220155.419E3EEA35@mail.python.org> Message-ID: <4D4B3B04.3070209@pearwood.info> Nick Coghlan wrote: > On Fri, Feb 4, 2011 at 8:01 AM, brett.cannon wrote: >> +Capturing the Currently Raised Exception >> +---------------------------------------- >> +One change between Python 2 and 3 that will require changing how you code is >> +accessing the currently raised exception. In Python 2 the syntax to access the >> +current exception is:: I think that the semantic change is *much* more important that the syntax change. In 2.6: >>> try: ... len(None) ... except TypeError as e: ... pass ... >>> e TypeError("object of type 'NoneType' has no len()",) In 3.1: >>> try: ... len(None) ... except TypeError as e: ... pass ... >>> e Traceback (most recent call last): File "", line 1, in NameError: name 'e' is not defined -- Steven From brett at python.org Fri Feb 4 00:56:58 2011 From: brett at python.org (Brett Cannon) Date: Thu, 3 Feb 2011 15:56:58 -0800 Subject: [Python-Dev] [Python-checkins] r88331 - in python/branches/py3k/Doc/howto: index.rst pyporting.rst In-Reply-To: References: <20110203220155.419E3EEA35@mail.python.org> Message-ID: On Thu, Feb 3, 2011 at 15:10, Nick Coghlan wrote: > On Fri, Feb 4, 2011 at 8:01 AM, brett.cannon wrote: >> +Stop Using :mod:`doctest` >> +''''''''''''''''''''''''' >> +While 2to3 tries to port doctests properly, it's a rather tough thing to do. It >> +is probably best to simply convert your critical doctests to :mod:`unittest`. > > This advice strikes me as being *way* too strong. Perhaps something like: I will change it to make sure that it states that you may want to port your doctests if all you have is one massive set, but I do not think it is "*way* too strong". Massive doctest inputs are bad enough as it is to edit when you don't have a shift in syntax (e.g., I have a patch waiting for 3.3 which causes entire test suites to skip because they are a massive doctest and it is not reasonable nor easy to make something conditional based on whether a trace function is set). Trying to port them to new syntax is just that much harder (and a complaint I came across online while researching the HOWTO). -Brett > > Consider limiting use of :mod:`doctest` > =============================== > > While 2to3 tries to port doctests properly, it's a rather tough thing > to do. If your test suite is heavily doctest dependent, then you may > end up spending a lot of time manually fixing doctests. The two major > avenues for dealing with this are to either port doctest based tests > over to the unittest module (making them significantly easier for 2to3 > to handle) or else to follow the guidelines below for writing 2/3 > compatible source code in all doctests (making it so they should run > unmodified on both Python versions). > > > Cheers, > Nick. > > -- > Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://mail.python.org/mailman/listinfo/python-checkins > From rian at dropbox.com Fri Feb 4 06:10:33 2011 From: rian at dropbox.com (Rian Hunter) Date: Thu, 3 Feb 2011 21:10:33 -0800 Subject: [Python-Dev] Issue #11051: system calls per import In-Reply-To: <20110131134300.2babc577@pitrou.net> References: <1296377778.24415.4.camel@marge> <4D452E71.6070401@python.org> <1296405345.24507.9.camel@marge> <4D45D6E1.6030906@canterbury.ac.nz> <4D4665B9.9000108@v.loewis.de> <20110131134300.2babc577@pitrou.net> Message-ID: <4945B802-AEF8-4528-BE53-293FBEF83A5C@dropbox.com> Hello Speaking from experience from my observations on millions of machines the stat() call is *very slow* when compared to readdir(), FindNextFile(), getdirentriesattr(), etc. When we switched from a file system indexer that stat()ed every file to one that read directories we noticed an average speedup of about 10x. You can probably attribute this to the fact that in file system indexing the raw system call volume is much lower (not having to stat() each file, just read the directories) but also due to the fact that there is much less HD seeking (stat() has to jump around the HD, usually all directory entries fit in one block). If you only need to test for the existence of multiple files and don't need the extra information that stat() gives you, it might make sense to avoid the context switch/IO overhead. Rian On Jan 31, 2011, at 4:43 AM, Antoine Pitrou wrote: > On Mon, 31 Jan 2011 00:08:25 -0800 > Guido van Rossum wrote: >> >> (Basically I am biased to believe that stat() is a pretty slow system >> call -- this may just be old NFS lore though.) > > I don't know about NFS, but starting a Python interpreter located on a > Samba share from a Windows VM is quite slow too. > I think Martin is right for the common case: on a local filesystem on a > modern Unix, stat() is certainly very fast. Remote or > distributed filesystems seem to be more of a problem. > > Regards > > Antoine. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/rian%40dropbox.com From jcea at jcea.es Fri Feb 4 16:30:01 2011 From: jcea at jcea.es (Jesus Cea) Date: Fri, 04 Feb 2011 16:30:01 +0100 Subject: [Python-Dev] Support for async read/write In-Reply-To: <1287529122.3488.9.camel@localhost.localdomain> References: <4CBDCC52.8080209@jcea.es> <20101019235627.3812bd24@pitrou.net> <4CBE202E.8060409@v.loewis.de> <1287529122.3488.9.camel@localhost.localdomain> Message-ID: <4D4C1B79.20507@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20/10/10 00:58, Antoine Pitrou wrote: > It would be nice to know about the use case Jesus has in mind. I am thinking about the cases where a request come, you do some disk read in behalf of it and you reply. If the read is "slow" (if not cached, you have to deal with a physical harddisk), you stop the main-loop for a while, unless you use threads. If, instead, I can schedule a read and keep processing other requests (possibly queueing new reads), be notified when the read is done and complete the reply, I think this is more simple and performing (and far less memory hungry) that using threads. I just opened a issue, assigned to me. I plan to do the implementation myself, at least for Solaris and possibly (recent) Linux: . Some people say AIO OS implementations are flaky. Well, you must deal with it, like you deal with other flaky OS corners, like exhausting memory or whatever. I would suppose that if Python exposes AIO and in some OS support is underpar, the exposing would incentivate a better support for OS. Like happened to threads and linux years ago. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTUwbeZlgi5GaxT1NAQK4uwP+J3PwGY1dvBi+OyBo9M9UWsma0khgzdUS 6ewHhCrCK+U5HK0e/g9cLbesBSsYvVfNjPe+fb9cQuwMBK0lpF3kOzfsEf82RIxR NlsqOba31CE1tW9uS4wja0TddFDob3IImqgwSB7NptBOZTNVjDvB6k0V7KHqvPWX 9g01GqaQ9uQ= =hx6M -----END PGP SIGNATURE----- From status at bugs.python.org Fri Feb 4 18:07:06 2011 From: status at bugs.python.org (Python tracker) Date: Fri, 4 Feb 2011 18:07:06 +0100 (CET) Subject: [Python-Dev] Summary of Python tracker Issues Message-ID: <20110204170706.2E7D61CDDC@psf.upfronthosting.co.za> ACTIVITY SUMMARY (2011-01-28 - 2011-02-04) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2585 (+18) closed 20314 (+52) total 22899 (+70) Open issues with patches: 1102 Issues opened (49) ================== #10918: **kwargs unnecessarily restricted in concurrent.futures 'submi http://bugs.python.org/issue10918 reopened by bquinlan #11023: pep 227 missing text http://bugs.python.org/issue11023 reopened by r.david.murray #11048: "import ctypes" causes segfault on read-only filesystem http://bugs.python.org/issue11048 opened by Arach #11049: add tests for test.support http://bugs.python.org/issue11049 opened by brett.cannon #11050: email.utils.getaddresses behavior contradicts RFC2822 http://bugs.python.org/issue11050 opened by Ivan.Egorov #11051: system calls per import http://bugs.python.org/issue11051 opened by pitrou #11055: OS X IDLE 3.2 Save As menu accelerator opens two Save windows http://bugs.python.org/issue11055 opened by ned.deily #11056: 2to3 fails for inner __metaclass__ class definition http://bugs.python.org/issue11056 opened by nw #11062: mailbox fails to round-trip a file to a Babyl mailbox http://bugs.python.org/issue11062 opened by r.david.murray #11063: uuid.py module import has heavy side effects http://bugs.python.org/issue11063 opened by Keith.Dart #11067: Py_LIMITED_API breaks most PySomething_Check() functions http://bugs.python.org/issue11067 opened by petere #11071: What's New review comments http://bugs.python.org/issue11071 opened by ncoghlan #11072: Add MLSD command support to ftplib http://bugs.python.org/issue11072 opened by giampaolo.rodola #11074: fix tokenize so it can be reloaded http://bugs.python.org/issue11074 opened by brett.cannon #11076: Iterable argparse Namespace http://bugs.python.org/issue11076 opened by vdupras #11077: Tkinter is not thread safe http://bugs.python.org/issue11077 opened by PythonInTheGrass #11078: Have test___all__ check for duplicates http://bugs.python.org/issue11078 opened by r.david.murray #11079: Make OS X entry in Applications like that in Windows http://bugs.python.org/issue11079 opened by rhettinger #11085: expose _abcoll as collections.abc http://bugs.python.org/issue11085 opened by rhettinger #11086: add lib2to3/__main__.py http://bugs.python.org/issue11086 opened by brett.cannon #11087: Speeding up the interpreter with a few lines of code http://bugs.python.org/issue11087 opened by jneb #11088: IDLE on OS X with Cocoa Tk 8.5 can hang waiting on input / raw http://bugs.python.org/issue11088 opened by ned.deily #11089: ConfigParser 50x slower in 2.7 http://bugs.python.org/issue11089 opened by vlachoudis #11090: Doc errors for unittest in Python 3.1 http://bugs.python.org/issue11090 opened by michael.foord #11092: Setup.cfg isn't packaged when running sdist http://bugs.python.org/issue11092 opened by Julien.Miotte #11093: test_future - rename not-unittest files to make regrtest.NOTTE http://bugs.python.org/issue11093 opened by sandro.tosi #11096: Multiple turtle tracers http://bugs.python.org/issue11096 opened by amcnerney13 #11097: MSI: Remove win32com dependency from installer generator http://bugs.python.org/issue11097 opened by techtonik #11100: test_fdopen: close failed in file object destructor http://bugs.python.org/issue11100 opened by ekrauss #11101: plistlib has no graceful way of handing None values http://bugs.python.org/issue11101 opened by bobveznat #11102: configure doesn't find "major()" on HP-UX v11.31 http://bugs.python.org/issue11102 opened by Oren_Held #11103: Python 3.2 installer doesn't register file extensions on Windo http://bugs.python.org/issue11103 opened by darren #11104: distutils sdist ignores MANIFEST http://bugs.python.org/issue11104 opened by jdennis #11105: Compiling evil ast crashes interpreter http://bugs.python.org/issue11105 opened by benjamin.peterson #11107: Cache constant "slice" instances http://bugs.python.org/issue11107 opened by scoder #11109: socketserver.ForkingMixIn leaves zombies http://bugs.python.org/issue11109 opened by jwark #11110: Py_DECREF->Py_XDECREF in Module/_sqlite/module.c http://bugs.python.org/issue11110 opened by brett.cannon #11112: UDPTimeoutTest derives from SocketTCPTest http://bugs.python.org/issue11112 opened by rmtew #11113: html.entities mapping dicts need updating? http://bugs.python.org/issue11113 opened by Brian.Jones #11114: TextIOWrapper.tell extremely slow http://bugs.python.org/issue11114 opened by Laurens #11116: mailbox and email errors http://bugs.python.org/issue11116 opened by sdaoden #11117: Implementing Async IO http://bugs.python.org/issue11117 opened by jcea #1103350: send/recv SEGMENT_SIZE should be used more in socketmodule http://bugs.python.org/issue1103350 reopened by r.david.murray #11060: distutils2 sdist does not complain about version that is not P http://bugs.python.org/issue11060 opened by gotcha #11061: Verify command option before parsing config file http://bugs.python.org/issue11061 opened by sdouche #11066: cgi.py proposals : sys.stdout encoding + rewriting of parsing http://bugs.python.org/issue11066 opened by quentel #11082: ValueError: Content-Length should be specified http://bugs.python.org/issue11082 opened by William.Wu #11084: Serialization of decimal.Decimal to XML-RPC http://bugs.python.org/issue11084 opened by gdr #1252236: Simplying Tkinter's event loop http://bugs.python.org/issue1252236 reopened by belopolsky Most recent 15 issues with no replies (15) ========================================== #11109: socketserver.ForkingMixIn leaves zombies http://bugs.python.org/issue11109 #11101: plistlib has no graceful way of handing None values http://bugs.python.org/issue11101 #11100: test_fdopen: close failed in file object destructor http://bugs.python.org/issue11100 #11097: MSI: Remove win32com dependency from installer generator http://bugs.python.org/issue11097 #11093: test_future - rename not-unittest files to make regrtest.NOTTE http://bugs.python.org/issue11093 #11088: IDLE on OS X with Cocoa Tk 8.5 can hang waiting on input / raw http://bugs.python.org/issue11088 #11074: fix tokenize so it can be reloaded http://bugs.python.org/issue11074 #11072: Add MLSD command support to ftplib http://bugs.python.org/issue11072 #11066: cgi.py proposals : sys.stdout encoding + rewriting of parsing http://bugs.python.org/issue11066 #11063: uuid.py module import has heavy side effects http://bugs.python.org/issue11063 #11062: mailbox fails to round-trip a file to a Babyl mailbox http://bugs.python.org/issue11062 #11060: distutils2 sdist does not complain about version that is not P http://bugs.python.org/issue11060 #11056: 2to3 fails for inner __metaclass__ class definition http://bugs.python.org/issue11056 #11055: OS X IDLE 3.2 Save As menu accelerator opens two Save windows http://bugs.python.org/issue11055 #11050: email.utils.getaddresses behavior contradicts RFC2822 http://bugs.python.org/issue11050 Most recent 15 issues waiting for review (15) ============================================= #11116: mailbox and email errors http://bugs.python.org/issue11116 #11110: Py_DECREF->Py_XDECREF in Module/_sqlite/module.c http://bugs.python.org/issue11110 #11109: socketserver.ForkingMixIn leaves zombies http://bugs.python.org/issue11109 #11104: distutils sdist ignores MANIFEST http://bugs.python.org/issue11104 #11102: configure doesn't find "major()" on HP-UX v11.31 http://bugs.python.org/issue11102 #11101: plistlib has no graceful way of handing None values http://bugs.python.org/issue11101 #11093: test_future - rename not-unittest files to make regrtest.NOTTE http://bugs.python.org/issue11093 #11090: Doc errors for unittest in Python 3.1 http://bugs.python.org/issue11090 #11089: ConfigParser 50x slower in 2.7 http://bugs.python.org/issue11089 #11086: add lib2to3/__main__.py http://bugs.python.org/issue11086 #11082: ValueError: Content-Length should be specified http://bugs.python.org/issue11082 #11079: Make OS X entry in Applications like that in Windows http://bugs.python.org/issue11079 #11078: Have test___all__ check for duplicates http://bugs.python.org/issue11078 #11076: Iterable argparse Namespace http://bugs.python.org/issue11076 #11074: fix tokenize so it can be reloaded http://bugs.python.org/issue11074 Top 10 most discussed issues (10) ================================= #11071: What's New review comments http://bugs.python.org/issue11071 20 msgs #10845: test_multiprocessing failure under Windows http://bugs.python.org/issue10845 12 msgs #7111: abort when stderr is closed http://bugs.python.org/issue7111 11 msgs #10227: Improve performance of MemoryView slicing http://bugs.python.org/issue10227 11 msgs #11114: TextIOWrapper.tell extremely slow http://bugs.python.org/issue11114 9 msgs #11082: ValueError: Content-Length should be specified http://bugs.python.org/issue11082 9 msgs #8914: Run clang's static analyzer http://bugs.python.org/issue8914 8 msgs #11037: State of PEP 382 or How does distutils2 handle namespaces? http://bugs.python.org/issue11037 8 msgs #11024: imaplib: Time2Internaldate() returns localized strings http://bugs.python.org/issue11024 8 msgs #2193: Cookie Colon Name Bug http://bugs.python.org/issue2193 7 msgs Issues closed (53) ================== #6045: Add more dict methods to dbm interfaces http://bugs.python.org/issue6045 closed by eric.araujo #6465: email.feedparser regular expression bug (NLCRE_crack) http://bugs.python.org/issue6465 closed by sandro.tosi #7074: Turtle module crashes python http://bugs.python.org/issue7074 closed by belopolsky #8275: callback function on win64 results in bad behavior. mem corrup http://bugs.python.org/issue8275 closed by pitrou #9124: Mailbox module should use binary I/O, not text I/O http://bugs.python.org/issue9124 closed by r.david.murray #9127: subprocess.Popen.communicate() and SIGCHLD handlers http://bugs.python.org/issue9127 closed by ned.deily #9418: Move _formatter_* methods from string type into _string module http://bugs.python.org/issue9418 closed by eric.smith #9763: Crashes upon run after syntax error encountered in OSX 10.5.8 http://bugs.python.org/issue9763 closed by ned.deily #9884: The 4th parameter of method always None or 0 on x64 Windows. http://bugs.python.org/issue9884 closed by owenl #10480: cgi.py should document the need for binary stdin/stdout http://bugs.python.org/issue10480 closed by v+python #10573: Consistency in unittest assert methods: order of actual, expec http://bugs.python.org/issue10573 closed by michael.foord #10847: Distutils drops -fno-strict-aliasing when CFLAGS are set http://bugs.python.org/issue10847 closed by eric.araujo #10939: imaplib: Internaldate2tuple raises KeyError parsing month and http://bugs.python.org/issue10939 closed by belopolsky #10940: IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with 64-bit inst http://bugs.python.org/issue10940 closed by ned.deily #10961: Pydoc touchups in new browser for 3.2 http://bugs.python.org/issue10961 closed by georg.brandl #10989: ssl.SSLContext(True).load_verify_locations(None, True) segfaul http://bugs.python.org/issue10989 closed by haypo #11025: Distutils2 install command without setup.py or setup.cfg creat http://bugs.python.org/issue11025 closed by eric.araujo #11032: _string: formatter_field_name_split() and formatter_parser() d http://bugs.python.org/issue11032 closed by eric.smith #11035: Segmentation fault http://bugs.python.org/issue11035 closed by brett.cannon #11038: Some commands should stop if Name and Version are missing http://bugs.python.org/issue11038 closed by eric.araujo #11040: After registering a project to PyPI, classifiers fields aren't http://bugs.python.org/issue11040 closed by eric.araujo #11042: [PyPI CSS] Adding project urls onto a project page using regis http://bugs.python.org/issue11042 closed by eric.araujo #11043: On GNU/Linux (Ubuntu) distutils2.mkcfg shouldn't create an exe http://bugs.python.org/issue11043 closed by eric.araujo #11044: The description-file isn't handled by distutils2 http://bugs.python.org/issue11044 closed by Julien.Miotte #11052: Fix OS X IDLE menu accelerators for Save As and Save Copy http://bugs.python.org/issue11052 closed by ned.deily #11053: OS X IDLE 3 with Tk 8.4 appears to hang with syntax error http://bugs.python.org/issue11053 closed by ned.deily #11054: OS X installer build script for 3.2 can no longer build with s http://bugs.python.org/issue11054 closed by ned.deily #11057: Missing import of DistutilsOptionError http://bugs.python.org/issue11057 closed by eric.araujo #11064: abc documentation version conflict http://bugs.python.org/issue11064 closed by dustin.farris #11065: Fatal "can't locate locale" errors when zip file with director http://bugs.python.org/issue11065 closed by ned.deily #11068: Python 2.7.1 Idle traceback on OS X (10.6.6) http://bugs.python.org/issue11068 closed by r.david.murray #11069: IDLE crashes when Stack Viewer opened http://bugs.python.org/issue11069 closed by georg.brandl #11070: test_capi crashes and fails http://bugs.python.org/issue11070 closed by brian.curtin #11073: threading.Thread documentation can be improved http://bugs.python.org/issue11073 closed by pitrou #11075: Using Turtle with IDLE on Mac OS X http://bugs.python.org/issue11075 closed by amcnerney13 #11080: Win32Serial.read coding error for non-blocking read http://bugs.python.org/issue11080 closed by brian.curtin #11081: from struct import * misses pack_into http://bugs.python.org/issue11081 closed by belopolsky #11083: threading.Thread - start() rises RuntimeException? http://bugs.python.org/issue11083 closed by brian.curtin #11091: Bug with reimport in pkg_resources http://bugs.python.org/issue11091 closed by brett.cannon #11094: Runtime error http://bugs.python.org/issue11094 closed by amaury.forgeotdarc #11095: subprocess popen broken for bytes and backslash http://bugs.python.org/issue11095 closed by eric.smith #11098: syntax error at end of line in interactive python -u http://bugs.python.org/issue11098 closed by r.david.murray #11099: Bytes pickled with 3.1 not unpickled with 2.7 correctly http://bugs.python.org/issue11099 closed by r.david.murray #11106: python 2.6.6 and python 2.7.1 cannot be built successfully bec http://bugs.python.org/issue11106 closed by skrah #11108: Intermittent AttributeError when using time.strptime in thread http://bugs.python.org/issue11108 closed by amaury.forgeotdarc #11111: See "Gmail" on your Google homepage http://bugs.python.org/issue11111 closed by belopolsky #11115: csv readers and writers should be context managers http://bugs.python.org/issue11115 closed by r.david.murray #1613479: pydoc info for a package doesn't list all package contents http://bugs.python.org/issue1613479 closed by eric.araujo #10947: imaplib: Internaldate2tuple and ParseFlags require (and latter http://bugs.python.org/issue10947 closed by lavajoe #11036: Allow multiple files in the description-file metadata http://bugs.python.org/issue11036 closed by eric.araujo #11058: dist directory not created when running sdist command http://bugs.python.org/issue11058 closed by kelseyhightower #11059: Mercurial fails on code.python.org repo http://bugs.python.org/issue11059 closed by sdaoden #1647654: No obvious and correct way to get the time zone offset http://bugs.python.org/issue1647654 closed by belopolsky From chris at simplistix.co.uk Fri Feb 4 18:43:21 2011 From: chris at simplistix.co.uk (Chris Withers) Date: Fri, 04 Feb 2011 17:43:21 +0000 Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows In-Reply-To: <4D431724.4010002@voidspace.org.uk> References: <4D431724.4010002@voidspace.org.uk> Message-ID: <4D4C3AB9.3020300@simplistix.co.uk> On 28/01/2011 19:21, Michael Foord wrote: > I've helped quite a few "python newbies" on Windows who are also > surprised / frustrated on learning that "python" on the command line > doesn't work after installing python. Yes, I've always found it a surprising disappointment that I have to manually munge the PATH and the installer doesn't *even* offer to do it for me. But, since I don't know how to help fix the installer, I've just generally stfu'd on this issue... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From p.f.moore at gmail.com Sat Feb 5 19:39:21 2011 From: p.f.moore at gmail.com (Paul Moore) Date: Sat, 5 Feb 2011 18:39:21 +0000 Subject: [Python-Dev] Test - Are there problems with the list? Message-ID: I've not seen any python-dev mails for a day or so. Is there a problem with the list? Paul. From solipsis at pitrou.net Sat Feb 5 20:02:02 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 5 Feb 2011 20:02:02 +0100 Subject: [Python-Dev] Test - Are there problems with the list? References: Message-ID: <20110205200202.20164431@pitrou.net> On Sat, 5 Feb 2011 18:39:21 +0000 Paul Moore wrote: > I've not seen any python-dev mails for a day or so. Is there a problem > with the list? I think it's just that nobody posted. Regards Antoine. From techtonik at gmail.com Sun Feb 6 11:14:52 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Sun, 6 Feb 2011 12:14:52 +0200 Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows In-Reply-To: <4D4C3AB9.3020300@simplistix.co.uk> References: <4D431724.4010002@voidspace.org.uk> <4D4C3AB9.3020300@simplistix.co.uk> Message-ID: On Fri, Feb 4, 2011 at 7:43 PM, Chris Withers wrote: >> >> I've helped quite a few "python newbies" on Windows who are also >> surprised / frustrated on learning that "python" on the command line >> doesn't work after installing python. > > Yes, I've always found it a surprising disappointment that I have to > manually munge the PATH and the installer doesn't *even* offer to do it for > me. > > But, since I don't know how to help fix the installer, I've just generally > stfu'd on this issue... This is how to fix an installer. http://codereview.appspot.com/4023055/diff/1/Tools/msi/msi.py Right now I am waiting for Martin's decision (and probably not only me). He is responsible for MSI stuff and the only one, who can integrate the patch. I don't want to put too much pressure on him, but it would be more comfortable for all of us to know what is he up to. I'd like to see this in 3.2 release, of course. -- anatoly t. From ncoghlan at gmail.com Sun Feb 6 14:59:33 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 6 Feb 2011 23:59:33 +1000 Subject: [Python-Dev] [Python-checkins] devguide: Describe the Rdiff extension for remote diffs In-Reply-To: References: Message-ID: On Sun, Feb 6, 2011 at 4:26 PM, nick.coghlan wrote: > +How do I compare my working copy to a remote repository? > +------------------------------------------------------------------------------- To save anyone else pointing this out, I'm now aware that "hg incoming" and "hg outgoing" are the actual commands I want. Still, that kind of mistake is why I want to keep the dev FAQ around - to help people that don't know enough to avoid the misleading answers a web search will sometimes give back. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From merwok at netwok.org Sun Feb 6 15:06:05 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sun, 06 Feb 2011 15:06:05 +0100 Subject: [Python-Dev] [Python-checkins] devguide: Describe the Rdiff extension for remote diffs In-Reply-To: References: Message-ID: <4D4EAACD.3010903@netwok.org> >> +How do I compare my working copy to a remote repository? > > To save anyone else pointing this out, I'm now aware that "hg > incoming" and "hg outgoing" are the actual commands I want. incoming and outgoing compare your repository to a remote repository, not your working copy. Regards From ncoghlan at gmail.com Sun Feb 6 15:42:17 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 7 Feb 2011 00:42:17 +1000 Subject: [Python-Dev] [Python-checkins] devguide: Describe the Rdiff extension for remote diffs In-Reply-To: <4D4EAACD.3010903@netwok.org> References: <4D4EAACD.3010903@netwok.org> Message-ID: On Mon, Feb 7, 2011 at 12:06 AM, ?ric Araujo wrote: >>> +How do I compare my working copy to a remote repository? >> >> To save anyone else pointing this out, I'm now aware that "hg >> incoming" and "hg outgoing" are the actual commands I want. > > incoming and outgoing compare your repository to a remote repository, > not your working copy. Yeah, I know, but for the use case I actually had in mind with that new FAQ entry ("When I type this next push command, what is it going to do?"), it's the committed changes that are important. I had my terminology wrong, so Google led me astray. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From brian.curtin at gmail.com Sun Feb 6 16:20:41 2011 From: brian.curtin at gmail.com (Brian Curtin) Date: Sun, 6 Feb 2011 09:20:41 -0600 Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows In-Reply-To: References: <4D431724.4010002@voidspace.org.uk> <4D4C3AB9.3020300@simplistix.co.uk> Message-ID: On Sun, Feb 6, 2011 at 04:14, anatoly techtonik wrote: > On Fri, Feb 4, 2011 at 7:43 PM, Chris Withers > wrote: > >> > >> I've helped quite a few "python newbies" on Windows who are also > >> surprised / frustrated on learning that "python" on the command line > >> doesn't work after installing python. > > > > Yes, I've always found it a surprising disappointment that I have to > > manually munge the PATH and the installer doesn't *even* offer to do it > for > > me. > > > > But, since I don't know how to help fix the installer, I've just > generally > > stfu'd on this issue... > > This is how to fix an installer. > http://codereview.appspot.com/4023055/diff/1/Tools/msi/msi.py > > Right now I am waiting for Martin's decision (and probably not only > me). He is responsible for MSI stuff and the only one, who can > integrate the patch. I don't want to put too much pressure on him, but > it would be more comfortable for all of us to know what is he up to. > I'd like to see this in 3.2 release, of course. We're one week from the 3.2 final release, so adding a feature such as this is definitely out of the question. Sorry to speak for Martin, but I'm certain he would agree. There are still outstanding considerations in the various issues on the tracker, so it would be best to address them before requesting integration. Example: What should happen when there is another Python installation on the path? -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at simplistix.co.uk Sun Feb 6 16:22:44 2011 From: chris at simplistix.co.uk (Chris Withers) Date: Sun, 06 Feb 2011 15:22:44 +0000 Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows In-Reply-To: References: <4D431724.4010002@voidspace.org.uk> <4D4C3AB9.3020300@simplistix.co.uk> Message-ID: <4D4EBCC4.1090003@simplistix.co.uk> On 06/02/2011 15:20, Brian Curtin wrote: > There are still outstanding considerations in the various issues on the > tracker, so it would be best to address them before requesting > integration. Example: What should happen when there is another Python > installation on the path? Same as happens with most Windows apps: last one installed wins. Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From brian.curtin at gmail.com Sun Feb 6 16:25:08 2011 From: brian.curtin at gmail.com (Brian Curtin) Date: Sun, 6 Feb 2011 09:25:08 -0600 Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows In-Reply-To: <4D4EBCC4.1090003@simplistix.co.uk> References: <4D431724.4010002@voidspace.org.uk> <4D4C3AB9.3020300@simplistix.co.uk> <4D4EBCC4.1090003@simplistix.co.uk> Message-ID: On Sun, Feb 6, 2011 at 09:22, Chris Withers wrote: > On 06/02/2011 15:20, Brian Curtin wrote: > >> There are still outstanding considerations in the various issues on the >> tracker, so it would be best to address them before requesting >> integration. Example: What should happen when there is another Python >> installation on the path? >> > > Same as happens with most Windows apps: last one installed wins. > > > Chris > So put the new path before the old path, or replace it? The current patch appends to the end. Anyways, this is the type of discussion for the existing issues on the tracker. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at simplistix.co.uk Sun Feb 6 16:27:03 2011 From: chris at simplistix.co.uk (Chris Withers) Date: Sun, 06 Feb 2011 15:27:03 +0000 Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows In-Reply-To: References: <4D431724.4010002@voidspace.org.uk> <4D4C3AB9.3020300@simplistix.co.uk> <4D4EBCC4.1090003@simplistix.co.uk> Message-ID: <4D4EBDC7.9000301@simplistix.co.uk> On 06/02/2011 15:25, Brian Curtin wrote: > So put the new path before the old path, or replace it? The current > patch appends to the end. I believe the last path wins in Windows land, so that would be fine. Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk From ncoghlan at gmail.com Sun Feb 6 16:35:13 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 7 Feb 2011 01:35:13 +1000 Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows In-Reply-To: <4D4EBDC7.9000301@simplistix.co.uk> References: <4D431724.4010002@voidspace.org.uk> <4D4C3AB9.3020300@simplistix.co.uk> <4D4EBCC4.1090003@simplistix.co.uk> <4D4EBDC7.9000301@simplistix.co.uk> Message-ID: On Mon, Feb 7, 2011 at 1:27 AM, Chris Withers wrote: > On 06/02/2011 15:25, Brian Curtin wrote: >> >> So put the new path before the old path, or replace it? The current >> patch appends to the end. > > I believe the last path wins in Windows land, so that would be fine. Not that I've ever experienced. Most installers just make sure to insert entries at the beginning so "last installed" wins. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From solipsis at pitrou.net Sun Feb 6 17:15:42 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 6 Feb 2011 17:15:42 +0100 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. References: Message-ID: <20110206171542.3859df07@pitrou.net> On Sun, 06 Feb 2011 02:10:15 +0100 brett.cannon wrote: > > To create your patch, you should generate a unified diff from your checkout's > top-level directory:: > > - svn diff > patch.diff > + hg outgoing --path > patch.diff Should be --patch. The problem is that it will show one several patch per changeset, which is normally not what you want (it's a pity "hg out" doesn't have an option to collapse them all). > If your work needs some new files to be added to the source tree, remember > -to ``svn add`` them before generating the patch:: > +to ``hg add`` them before generating the patch:: > > - svn add Lib/newfile.py > - svn diff > patch.diff > + hg add Lib/newfile.py > + hg outgoing --patch > patch.diff You should commit before using "outgoing", otherwise the added file is not in the repo (and therefore not in the patch). The problem with hg (and other DVCSes) is that allows for *several* local workflows, and therefore it's harder to advocate one of them in such tutorial docs. I wonder what Georg and Dirkjan suggest. We could perhaps present SVN-like "work in the working copy" workflow (without local commits), and let seasoned hg users choose other workflows they like more (they don't need our help anyway). > To undo a patch, you can revert **all** changes made in your checkout:: > > - svn revert -R . > + hg revert --all > + Or "hg revert -a", which is nicer to type. From p.f.moore at gmail.com Sun Feb 6 17:17:23 2011 From: p.f.moore at gmail.com (Paul Moore) Date: Sun, 6 Feb 2011 16:17:23 +0000 Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows In-Reply-To: References: <4D431724.4010002@voidspace.org.uk> <4D4C3AB9.3020300@simplistix.co.uk> <4D4EBCC4.1090003@simplistix.co.uk> <4D4EBDC7.9000301@simplistix.co.uk> Message-ID: On 6 February 2011 15:35, Nick Coghlan wrote: > On Mon, Feb 7, 2011 at 1:27 AM, Chris Withers wrote: >> On 06/02/2011 15:25, Brian Curtin wrote: >>> >>> So put the new path before the old path, or replace it? The current >>> patch appends to the end. >> >> I believe the last path wins in Windows land, so that would be fine. > > Not that I've ever experienced. Most installers just make sure to > insert entries at the beginning so "last installed" wins. ... and "at the beginning" can be a pain due to unintended overriding of existing user commands (not likely in the case of Python, where there's only python, pythonw, w9xpopen and various bdist_wininst "RemoveXXX" commands, but still possible). "Before any existing Python directories, otherwise at the end" is the closest to what I suspect most users want (certainly it matches my preferences, and anything else would have me manually editing PATH anyway, so is of no use to me in practice). Paul. From stephen at xemacs.org Sun Feb 6 18:07:26 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 07 Feb 2011 02:07:26 +0900 Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows In-Reply-To: References: <4D431724.4010002@voidspace.org.uk> <4D4C3AB9.3020300@simplistix.co.uk> <4D4EBCC4.1090003@simplistix.co.uk> <4D4EBDC7.9000301@simplistix.co.uk> Message-ID: <8762sx148h.fsf@uwakimon.sk.tsukuba.ac.jp> Paul Moore writes: > "Before any existing Python directories, otherwise at the end" is the > closest to what I suspect most users want (certainly it matches my > preferences, and anything else would have me manually editing PATH > anyway, so is of no use to me in practice). Unfortunately, what is "no use to person X in practice" is a function of X. I suspect that's why this hasn't been done. Specifically, it seems to me that there are use cases for each of 1. Append (eg, if both python3 and python2 provide "python.exe", for experimental use of python3). 2. Prepend (actually, not a use case; just common, and therefore "intuitive", practice). 3. "Moore's rule" (put latest and greatest ahead of other versions but not interfere with previously installed apps). Maybe it should be user-configurable. From merwok at netwok.org Sun Feb 6 19:10:37 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sun, 06 Feb 2011 19:10:37 +0100 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. In-Reply-To: <20110206171542.3859df07@pitrou.net> References: <20110206171542.3859df07@pitrou.net> Message-ID: <4D4EE41D.30003@netwok.org> Le 06/02/2011 17:15, Antoine Pitrou a ?crit : > On Sun, 06 Feb 2011 02:10:15 +0100 > brett.cannon wrote: >> To create your patch, you should generate a unified diff from your checkout's >> top-level directory:: >> >> - svn diff > patch.diff >> + hg outgoing --path > patch.diff > > Should be --patch. > The problem is that it will show one several patch per changeset, which > is normally not what you want (it's a pity "hg out" doesn't have an > option to collapse them all). I suggest you request that feature upstream. In the meantime, one can use hg diff -r $upstream-tip:tip to diff two anonymous branches. Using a named branch or local tags helps identifying $upstream-tip. Regards From p.f.moore at gmail.com Sun Feb 6 19:13:30 2011 From: p.f.moore at gmail.com (Paul Moore) Date: Sun, 6 Feb 2011 18:13:30 +0000 Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows In-Reply-To: <8762sx148h.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4D431724.4010002@voidspace.org.uk> <4D4C3AB9.3020300@simplistix.co.uk> <4D4EBCC4.1090003@simplistix.co.uk> <4D4EBDC7.9000301@simplistix.co.uk> <8762sx148h.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On 6 February 2011 17:07, Stephen J. Turnbull wrote: > Paul Moore writes: > > ?> "Before any existing Python directories, otherwise at the end" is the > ?> closest to what I suspect most users want (certainly it matches my > ?> preferences, and anything else would have me manually editing PATH > ?> anyway, so is of no use to me in practice). > > Unfortunately, what is "no use to person X in practice" is a function > of X. ?I suspect that's why this hasn't been done. Absolutely :-) And it's also why I'm reluctant to support it - even though I agree that not having "python" just work is a PITA. > Specifically, it seems to me that there are use cases for each of > > 1. ?Append (eg, if both python3 and python2 provide "python.exe", for > ? ?experimental use of python3). > 2. ?Prepend (actually, not a use case; just common, and therefore > ? ?"intuitive", practice). > 3. ?"Moore's rule" (put latest and greatest ahead of other versions > ? ?but not interfere with previously installed apps). Fame at last :-) I've seen both (1) and (2) in common use. Both have disadvantages, particularly if you try to support multiple versions being installed at once (something which is nearly unheard of in Windows, and hence why no commonly used solution really does a good job of it). I've never seen (3), and in all honesty I don't expect it to be practical - too many special cases to consider. It was more of a straw man example of what "do it right" might really mean... > Maybe it should be user-configurable. -1. Too much complexity. What I *have* seen is Oracle's "Home Selector", which is a program installed with Oracle's software which keeps track of which versions of Oracle you have installed, and gives you a GUI to move them up & down in priority, or disable versions. It then updates PATH appropriately. Ultimately, all it is in Python's terms, is a GUI means of editing PATH, so I'm not sure it's of any real use to us. (For Oracle, I think it fiddles with some other registry values, so it does have some value there...) One point - no matter what we do, we only need to consider 3.3 and later. People using 3.2 or earlier still have to manually fix up PATH how they want. So if we do add python to PATH in 3.3, we don't actually have a "what if people want to install multiple versions" issue until 3.4 comes out. I'm assuming we don't try to support multiple maintenance releases (3.3.1 and 3.3.2) being installed at once... Paul. From martin at v.loewis.de Sun Feb 6 19:26:49 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 06 Feb 2011 19:26:49 +0100 Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows In-Reply-To: References: <4D431724.4010002@voidspace.org.uk> <4D4C3AB9.3020300@simplistix.co.uk> Message-ID: <4D4EE7E9.5030008@v.loewis.de> > I'd like to see this in 3.2 release, of course. As Brian already asserted: that's not feasible. I still haven't managed to test your installer, and may not be able to for the next few weeks. It's also against the policy for release candidates to add such a change at this point. I believe the change, if implemented, needs to be optional (which I believe your change is not). Regards, Martin From solipsis at pitrou.net Sun Feb 6 19:39:05 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 6 Feb 2011 19:39:05 +0100 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. References: <20110206171542.3859df07@pitrou.net> <4D4EE41D.30003@netwok.org> Message-ID: <20110206193905.442ab7ce@pitrou.net> On Sun, 06 Feb 2011 19:10:37 +0100 ?ric Araujo wrote: > Le 06/02/2011 17:15, Antoine Pitrou a ?crit : > > On Sun, 06 Feb 2011 02:10:15 +0100 > > brett.cannon wrote: > >> To create your patch, you should generate a unified diff from your checkout's > >> top-level directory:: > >> > >> - svn diff > patch.diff > >> + hg outgoing --path > patch.diff > > > > Should be --patch. > > The problem is that it will show one several patch per changeset, which > > is normally not what you want (it's a pity "hg out" doesn't have an > > option to collapse them all). > > I suggest you request that feature upstream. > > In the meantime, one can use hg diff -r $upstream-tip:tip to diff two > anonymous branches. Using a named branch or local tags helps > identifying $upstream-tip. Yes. But that's where we start advocating a particular local workflow over another (why named branches rather than mercurial queues or bookmarks, for example?). That's why I think that part of the devguide should stick to a trivial SVN-like use, letting people learn about more powerful options in other resources. Regards Antoine. From brett at python.org Sun Feb 6 21:13:08 2011 From: brett at python.org (Brett Cannon) Date: Sun, 6 Feb 2011 12:13:08 -0800 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. In-Reply-To: <20110206171542.3859df07@pitrou.net> References: <20110206171542.3859df07@pitrou.net> Message-ID: On Sun, Feb 6, 2011 at 08:15, Antoine Pitrou wrote: > On Sun, 06 Feb 2011 02:10:15 +0100 > brett.cannon wrote: >> >> ?To create your patch, you should generate a unified diff from your checkout's >> ?top-level directory:: >> >> - ? ?svn diff > patch.diff >> + ? ?hg outgoing --path > patch.diff > > Should be --patch. > The problem is that it will show one several patch per changeset, which > is normally not what you want (it's a pity "hg out" doesn't have an > option to collapse them all). Yeah, that is a perk of mq. > >> ?If your work needs some new files to be added to the source tree, remember >> -to ``svn add`` them before generating the patch:: >> +to ``hg add`` them before generating the patch:: >> >> - ? svn add Lib/newfile.py >> - ? svn diff > patch.diff >> + ? hg add Lib/newfile.py >> + ? hg outgoing --patch > patch.diff > > You should commit before using "outgoing", otherwise the added file is > not in the repo (and therefore not in the patch). > > The problem with hg (and other DVCSes) is that allows for *several* > local workflows, and therefore it's harder to advocate one of them in > such tutorial docs. I wonder what Georg and Dirkjan suggest. Well, I wouldn't say harder. We just choose one we like the most and advocate that while stating upfront this is just one of many different ways someone can choose to work. > > We could perhaps present SVN-like "work in the working copy" workflow > (without local commits), and let seasoned hg users choose other > workflows they like more (they don't need our help anyway). I would rather give people some simple workflow that has some benefit over svn. Basically whatever is the easiest to comprehend and work with should be what we start people with. > >> ?To undo a patch, you can revert **all** changes made in your checkout:: >> >> - ? ?svn revert -R . >> + ? ?hg revert --all >> + > > Or "hg revert -a", which is nicer to type. I prefer being explicit over implicit in the tutorial. From brendan at kublai.com Sun Feb 6 21:36:17 2011 From: brendan at kublai.com (Brendan Cully) Date: Sun, 6 Feb 2011 12:36:17 -0800 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. In-Reply-To: References: <20110206171542.3859df07@pitrou.net> Message-ID: <20110206203616.GA6168@zanzibar.quuxuum.com> On Sunday, 06 February 2011 at 12:13, Brett Cannon wrote: > On Sun, Feb 6, 2011 at 08:15, Antoine Pitrou wrote: > > On Sun, 06 Feb 2011 02:10:15 +0100 > > brett.cannon wrote: > >> > >> ?To create your patch, you should generate a unified diff from your checkout's > >> ?top-level directory:: > >> > >> - ? ?svn diff > patch.diff > >> + ? ?hg outgoing --path > patch.diff > > > > Should be --patch. > > The problem is that it will show one several patch per changeset, which > > is normally not what you want (it's a pity "hg out" doesn't have an > > option to collapse them all). > > Yeah, that is a perk of mq. > > > > >> ?If your work needs some new files to be added to the source tree, remember > >> -to ``svn add`` them before generating the patch:: > >> +to ``hg add`` them before generating the patch:: > >> > >> - ? svn add Lib/newfile.py > >> - ? svn diff > patch.diff > >> + ? hg add Lib/newfile.py > >> + ? hg outgoing --patch > patch.diff > > > > You should commit before using "outgoing", otherwise the added file is > > not in the repo (and therefore not in the patch). > > > > The problem with hg (and other DVCSes) is that allows for *several* > > local workflows, and therefore it's harder to advocate one of them in > > such tutorial docs. I wonder what Georg and Dirkjan suggest. I just happened to see this message and don't really know the context -- you may not want to use any extensions here. But my 'rdiff' extension does let you create diffs between your working directory and upstream, and collapses your changesets into a single diff. http://mercurial.selenic.com/wiki/RdiffExtension From brett at python.org Sun Feb 6 21:53:43 2011 From: brett at python.org (Brett Cannon) Date: Sun, 6 Feb 2011 12:53:43 -0800 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. In-Reply-To: <20110206203616.GA6168@zanzibar.quuxuum.com> References: <20110206171542.3859df07@pitrou.net> <20110206203616.GA6168@zanzibar.quuxuum.com> Message-ID: On Sun, Feb 6, 2011 at 12:36, Brendan Cully wrote: > On Sunday, 06 February 2011 at 12:13, Brett Cannon wrote: >> On Sun, Feb 6, 2011 at 08:15, Antoine Pitrou wrote: >> > On Sun, 06 Feb 2011 02:10:15 +0100 >> > brett.cannon wrote: >> >> >> >> ?To create your patch, you should generate a unified diff from your checkout's >> >> ?top-level directory:: >> >> >> >> - ? ?svn diff > patch.diff >> >> + ? ?hg outgoing --path > patch.diff >> > >> > Should be --patch. >> > The problem is that it will show one several patch per changeset, which >> > is normally not what you want (it's a pity "hg out" doesn't have an >> > option to collapse them all). >> >> Yeah, that is a perk of mq. >> >> > >> >> ?If your work needs some new files to be added to the source tree, remember >> >> -to ``svn add`` them before generating the patch:: >> >> +to ``hg add`` them before generating the patch:: >> >> >> >> - ? svn add Lib/newfile.py >> >> - ? svn diff > patch.diff >> >> + ? hg add Lib/newfile.py >> >> + ? hg outgoing --patch > patch.diff >> > >> > You should commit before using "outgoing", otherwise the added file is >> > not in the repo (and therefore not in the patch). >> > >> > The problem with hg (and other DVCSes) is that allows for *several* >> > local workflows, and therefore it's harder to advocate one of them in >> > such tutorial docs. I wonder what Georg and Dirkjan suggest. > > I just happened to see this message and don't really know the > context -- you may not want to use any extensions here. But my 'rdiff' > extension does let you create diffs between your working directory and > upstream, and collapses your changesets into a single diff. I would rather not have new hg users have to install an extension just to get a simple workflow going. From ncoghlan at gmail.com Mon Feb 7 00:21:02 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 7 Feb 2011 09:21:02 +1000 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. In-Reply-To: References: <20110206171542.3859df07@pitrou.net> <20110206203616.GA6168@zanzibar.quuxuum.com> Message-ID: On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon wrote: > I would rather not have new hg users have to install an extension just > to get a simple workflow going. I may still keep my Rdiff-based FAQ entry around as an example of how to get a collapsed diff regardless of personal workflow, though. Installing Rdiff was actually pretty easy, and I get the impression that becoming comfortable with adding the extensions that suit your personal workflow is a key part in getting Mercurial to really work for you. We won't do people any favours if we try to pretend that isn't the case. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From ncoghlan at gmail.com Mon Feb 7 00:28:22 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 7 Feb 2011 09:28:22 +1000 Subject: [Python-Dev] [Python-checkins] r88359 - python/branches/py3k/Doc/whatsnew/3.2.rst In-Reply-To: <20110206200857.A3046EE98D@mail.python.org> References: <20110206200857.A3046EE98D@mail.python.org> Message-ID: On Mon, Feb 7, 2011 at 6:08 AM, raymond.hettinger wrote: > +In addition, the :func:`~dis.dis` function now accepts string arguments > +so that the common idiom ``dis(compile(s, '', 'eval'))`` can be shortened > +to ``dis(compile(s))``:: That should be ``dis(s)``. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From g.brandl at gmx.net Mon Feb 7 13:25:26 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Mon, 07 Feb 2011 13:25:26 +0100 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. In-Reply-To: References: <20110206171542.3859df07@pitrou.net> <20110206203616.GA6168@zanzibar.quuxuum.com> Message-ID: Am 07.02.2011 00:21, schrieb Nick Coghlan: > On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon wrote: >> I would rather not have new hg users have to install an extension just >> to get a simple workflow going. > > I may still keep my Rdiff-based FAQ entry around as an example of how > to get a collapsed diff regardless of personal workflow, though. > > Installing Rdiff was actually pretty easy, and I get the impression > that becoming comfortable with adding the extensions that suit your > personal workflow is a key part in getting Mercurial to really work > for you. We won't do people any favours if we try to pretend that > isn't the case. This is quite true. (And after a while, the same goes for creating your own extensions, BTW.) Georg From g.brandl at gmx.net Mon Feb 7 13:26:28 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Mon, 07 Feb 2011 13:26:28 +0100 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. In-Reply-To: References: <20110206171542.3859df07@pitrou.net> Message-ID: Am 06.02.2011 21:13, schrieb Brett Cannon: >>> To undo a patch, you can revert **all** changes made in your checkout:: >>> >>> - svn revert -R . >>> + hg revert --all >>> + >> >> Or "hg revert -a", which is nicer to type. > > I prefer being explicit over implicit in the tutorial. BTW, the exact equivalent of "svn revert -R ." is "hg revert ."; the two differ if you're not in the working dir root. However, considering the preceding text, the SVN command was faulty in the first place. Georg From fuzzyman at voidspace.org.uk Mon Feb 7 14:27:31 2011 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 07 Feb 2011 13:27:31 +0000 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. In-Reply-To: References: <20110206171542.3859df07@pitrou.net> <20110206203616.GA6168@zanzibar.quuxuum.com> Message-ID: <4D4FF343.5030703@voidspace.org.uk> On 07/02/2011 12:25, Georg Brandl wrote: > Am 07.02.2011 00:21, schrieb Nick Coghlan: >> On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon wrote: >>> I would rather not have new hg users have to install an extension just >>> to get a simple workflow going. >> I may still keep my Rdiff-based FAQ entry around as an example of how >> to get a collapsed diff regardless of personal workflow, though. >> >> Installing Rdiff was actually pretty easy, and I get the impression >> that becoming comfortable with adding the extensions that suit your >> personal workflow is a key part in getting Mercurial to really work >> for you. We won't do people any favours if we try to pretend that >> isn't the case. > This is quite true. (And after a while, the same goes for creating your > own extensions, BTW.) > And from the description it sounds like rdiff will be very useful for our usecase. Michael > Georg > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From solipsis at pitrou.net Mon Feb 7 15:24:59 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 7 Feb 2011 15:24:59 +0100 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. References: <20110206171542.3859df07@pitrou.net> Message-ID: <20110207152459.02cb2bcb@pitrou.net> On Mon, 07 Feb 2011 13:26:28 +0100 Georg Brandl wrote: > Am 06.02.2011 21:13, schrieb Brett Cannon: > > >>> To undo a patch, you can revert **all** changes made in your checkout:: > >>> > >>> - svn revert -R . > >>> + hg revert --all > >>> + > >> > >> Or "hg revert -a", which is nicer to type. > > > > I prefer being explicit over implicit in the tutorial. > > BTW, the exact equivalent of "svn revert -R ." is "hg revert ."; the two > differ if you're not in the working dir root. Using hg commands from somewhere else that the dir root is too confusing. Sometimes they display WC-relative paths, sometimes they display current dir-relative paths. I would not recommend it. Regards Antoine. From solipsis at pitrou.net Mon Feb 7 15:28:00 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 7 Feb 2011 15:28:00 +0100 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. References: <20110206171542.3859df07@pitrou.net> <20110206203616.GA6168@zanzibar.quuxuum.com> <4D4FF343.5030703@voidspace.org.uk> Message-ID: <20110207152800.67e05fd9@pitrou.net> On Mon, 07 Feb 2011 13:27:31 +0000 Michael Foord wrote: > On 07/02/2011 12:25, Georg Brandl wrote: > > Am 07.02.2011 00:21, schrieb Nick Coghlan: > >> On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon wrote: > >>> I would rather not have new hg users have to install an extension just > >>> to get a simple workflow going. > >> I may still keep my Rdiff-based FAQ entry around as an example of how > >> to get a collapsed diff regardless of personal workflow, though. > >> > >> Installing Rdiff was actually pretty easy, and I get the impression > >> that becoming comfortable with adding the extensions that suit your > >> personal workflow is a key part in getting Mercurial to really work > >> for you. We won't do people any favours if we try to pretend that > >> isn't the case. > > This is quite true. (And after a while, the same goes for creating your > > own extensions, BTW.) > > > > And from the description it sounds like rdiff will be very useful for > our usecase. I'm not sure it is really. When you commit multiple changesets locally you really want to use something like named branches or mq to track them. Advocating rdiff is advocating something SVN-like, it's not very helpful IMO. Regards Antoine. From fuzzyman at voidspace.org.uk Mon Feb 7 15:34:35 2011 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 07 Feb 2011 14:34:35 +0000 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. In-Reply-To: <20110207152800.67e05fd9@pitrou.net> References: <20110206171542.3859df07@pitrou.net> <20110206203616.GA6168@zanzibar.quuxuum.com> <4D4FF343.5030703@voidspace.org.uk> <20110207152800.67e05fd9@pitrou.net> Message-ID: <4D5002FB.2050504@voidspace.org.uk> On 07/02/2011 14:28, Antoine Pitrou wrote: > On Mon, 07 Feb 2011 13:27:31 +0000 > Michael Foord wrote: >> On 07/02/2011 12:25, Georg Brandl wrote: >>> Am 07.02.2011 00:21, schrieb Nick Coghlan: >>>> On Mon, Feb 7, 2011 at 6:53 AM, Brett Cannon wrote: >>>>> I would rather not have new hg users have to install an extension just >>>>> to get a simple workflow going. >>>> I may still keep my Rdiff-based FAQ entry around as an example of how >>>> to get a collapsed diff regardless of personal workflow, though. >>>> >>>> Installing Rdiff was actually pretty easy, and I get the impression >>>> that becoming comfortable with adding the extensions that suit your >>>> personal workflow is a key part in getting Mercurial to really work >>>> for you. We won't do people any favours if we try to pretend that >>>> isn't the case. >>> This is quite true. (And after a while, the same goes for creating your >>> own extensions, BTW.) >>> >> And from the description it sounds like rdiff will be very useful for >> our usecase. > I'm not sure it is really. When you commit multiple changesets > locally you really want to use something like named branches or mq to > track them. Advocating rdiff is advocating something SVN-like, it's not > very helpful IMO. > Although often you want to merge in a single commit and erase the commit history of the branch you worked in (as discussed previously). So are you advocating rebasing before merge as the alternative? Michael > Regards > > Antoine. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From solipsis at pitrou.net Mon Feb 7 15:46:45 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 7 Feb 2011 15:46:45 +0100 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. In-Reply-To: <4D5002FB.2050504@voidspace.org.uk> References: <20110206171542.3859df07@pitrou.net> <20110206203616.GA6168@zanzibar.quuxuum.com> <4D4FF343.5030703@voidspace.org.uk> <20110207152800.67e05fd9@pitrou.net> <4D5002FB.2050504@voidspace.org.uk> Message-ID: <20110207154645.790d02a6@pitrou.net> On Mon, 07 Feb 2011 14:34:35 +0000 Michael Foord wrote: > >>> > >> And from the description it sounds like rdiff will be very useful for > >> our usecase. > > I'm not sure it is really. When you commit multiple changesets > > locally you really want to use something like named branches or mq to > > track them. Advocating rdiff is advocating something SVN-like, it's not > > very helpful IMO. > > > > Although often you want to merge in a single commit and erase the commit > history of the branch you worked in (as discussed previously). Yes, but apparently rdiff compares the *working copy* rather than the local repository. Also, AFAIU rdiff will compare against the tip of the remote, which is probably not what you based your work on. And if you have to specify revisions by hand, it kind of defeats the point (you want hg to track changes by itself, which is why you want to use one of named branches / bookmarks / mq / etc.). > So are > you advocating rebasing before merge as the alternative? I'm not advocating anything in particular really. I think creating a named branch "foo" (or a bookmark? I've never used them but it sounds like they might do the trick) and then using "hg di -r py3k" to get the diff against upstream is very reasonable. That's without any hg extension activated. Throwaway clones are good too, since they avoid the issues with "rebasing" or "erasing commit history". But if we suggest people use some extension, I'd rather see us advocate mq (or shelve or any equivalent) rather than something low-level such as rdiff. Regards Antoine. From dirkjan at ochtman.nl Mon Feb 7 15:54:31 2011 From: dirkjan at ochtman.nl (Dirkjan Ochtman) Date: Mon, 7 Feb 2011 15:54:31 +0100 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. In-Reply-To: <20110207154645.790d02a6@pitrou.net> References: <20110206171542.3859df07@pitrou.net> <20110206203616.GA6168@zanzibar.quuxuum.com> <4D4FF343.5030703@voidspace.org.uk> <20110207152800.67e05fd9@pitrou.net> <4D5002FB.2050504@voidspace.org.uk> <20110207154645.790d02a6@pitrou.net> Message-ID: On Mon, Feb 7, 2011 at 15:46, Antoine Pitrou wrote: > I'm not advocating anything in particular really. I think creating a > named branch "foo" (or a bookmark? I've never used them but it sounds > like they might do the trick) and then using "hg di -r py3k" to get the > diff against upstream is very reasonable. That's without any hg > extension activated. Yeah, I don't think we need rdiff. IIRC it isn't really maintained, either, just the basics to keep it working with new versions of hg. Cheers, Dirkjan From brendan at kublai.com Mon Feb 7 15:58:47 2011 From: brendan at kublai.com (Brendan Cully) Date: Mon, 7 Feb 2011 06:58:47 -0800 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. In-Reply-To: <20110207154645.790d02a6@pitrou.net> References: <20110206171542.3859df07@pitrou.net> <20110206203616.GA6168@zanzibar.quuxuum.com> <4D4FF343.5030703@voidspace.org.uk> <20110207152800.67e05fd9@pitrou.net> <4D5002FB.2050504@voidspace.org.uk> <20110207154645.790d02a6@pitrou.net> Message-ID: <20110207145846.GA18266@zanzibar.quuxuum.com> On Monday, 07 February 2011 at 15:46, Antoine Pitrou wrote: > On Mon, 07 Feb 2011 14:34:35 +0000 > Michael Foord wrote: > > >>> > > >> And from the description it sounds like rdiff will be very useful for > > >> our usecase. > > > I'm not sure it is really. When you commit multiple changesets > > > locally you really want to use something like named branches or mq to > > > track them. Advocating rdiff is advocating something SVN-like, it's not > > > very helpful IMO. > > > > > > > Although often you want to merge in a single commit and erase the commit > > history of the branch you worked in (as discussed previously). > > Yes, but apparently rdiff compares the *working copy* rather than the > local repository. Also, AFAIU rdiff will compare against the tip of the Rdiff is meant to make diff work against remote repositories the way it already does on local ones. So it *can* produce a diff between the working directory and a remote revision, just as regular diff can do for a local revision. But it can also produce diffs between any local revision and any remote revision. > remote, which is probably not what you based your work on. And if you If you're talking about named branches, I think I agree (rdiff predates a lot of the work done in hg to support named branches). I assume you think the right target is the most recent remote revision on the named branch you're working against? (rdiff does accept symbolic names for remote revisions, including branch names) > have to specify revisions by hand, it kind of defeats the point (you > want hg to track changes by itself, which is why you want to use one > of named branches / bookmarks / mq / etc.). rdiff is somewhat orthogonal to bookmarks/mq/etc. It's really just a convenient wrapper for outgoing. From ethan at stoneleaf.us Mon Feb 7 21:16:35 2011 From: ethan at stoneleaf.us (Ethan Furman) Date: Mon, 07 Feb 2011 12:16:35 -0800 Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows In-Reply-To: <4D4EBDC7.9000301@simplistix.co.uk> References: <4D431724.4010002@voidspace.org.uk> <4D4C3AB9.3020300@simplistix.co.uk> <4D4EBCC4.1090003@simplistix.co.uk> <4D4EBDC7.9000301@simplistix.co.uk> Message-ID: <4D505323.5020909@stoneleaf.us> Chris Withers wrote: > On 06/02/2011 15:25, Brian Curtin wrote: >> So put the new path before the old path, or replace it? The current >> patch appends to the end. > > I believe the last path wins in Windows land, so that would be fine. Actually, first one wins, as Windows starts at the beginning and stops looking once it finds a match. ~Ethan~ From wesleymesquita at gmail.com Mon Feb 7 23:38:28 2011 From: wesleymesquita at gmail.com (Wesley Mesquita) Date: Mon, 7 Feb 2011 20:38:28 -0200 Subject: [Python-Dev] Python Unit Tests Message-ID: Hi all, I starting to explore python 3k core development environment. So, sorry in advance for any mistakes, but I really don't know what is the best list to post this, since it not a "use of python" issue, and probably is not a dev issue, it is more like a "dev env" question. I have ran the test suit, and got the messages below. ~/python_dev/python$ make testall ./python -Wd -E -bb ./Lib/test/regrtest.py -uall -l == CPython 3.2rc2+ (py3k:88376, Feb 7 2011, 18:31:28) [GCC 4.4.5] == Linux-2.6.35-24-generic-x86_64-with-debian-squeeze-sid little-endian == /home/wesley/python_dev/python/build/test_python_3387 Testing with flags: sys.flags(debug=0, division_warning=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, verbose=0, bytes_warning=2, quiet=0) [...] [198/349] test_ossaudiodev test_ossaudiodev skipped -- [Errno 2] No such file or directory: '/dev/dsp' [...] [200/349] test_parser Expecting 's_push: parser stack overflow' in next line s_push: parser stack overflow [...] [321/349] test_urllib2net /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed self._sock = None /home/wesley/python_dev/python/Lib/urllib/request.py:2134: ResourceWarning: unclosed sys.exc_info()[2]) /home/wesley/python_dev/python/Lib/urllib/request.py:2134: ResourceWarning: unclosed sys.exc_info()[2]) /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed self._sock = None /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed self._sock = None /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed self._sock = None /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed self._sock = None [323/349] test_urllibnet /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed self._sock = None 24 tests skipped: test_bz2 test_curses test_dbm_gnu test_dbm_ndbm test_gdb test_kqueue test_ossaudiodev test_readline test_smtpnet test_socketserver test_sqlite test_ssl test_startfile test_tcl test_timeout test_tk test_ttk_guionly test_ttk_textonly test_urllib2net test_urllibnet test_winreg test_winsound test_xmlrpc_net test_zipfile64 9 skips unexpected on linux2: test_bz2 test_dbm_gnu test_dbm_ndbm test_readline test_ssl test_tcl test_tk test_ttk_guionly test_ttk_textonly sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='a' encoding='UTF-8'> But running each of them individually: :~/python_dev/python$ ./python Lib/test/regrtest.py test_ossaudiodev [1/1] test_ossaudiodev test_ossaudiodev skipped -- Use of the `audio' resource not enabled 1 test skipped: test_ossaudiodev Those skips are all expected on linux2. ./python Lib/test/regrtest.py test_parser [1/1] test_parser Expecting 's_push: parser stack overflow' in next line s_push: parser stack overflow 1 test OK. ./python Lib/test/regrtest.py test_urllib2net[1/1] test_urllib2net test_urllib2net skipped -- Use of the `network' resource not enabled 1 test skipped: test_urllib2net Those skips are all expected on linux2. Is there any reason for the different results? Regards, Wesley -- Wesley Mesquita Computer Engineer http://www.wesleymesquita.com Mobile: +55 11 95249272 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdmurray at bitdance.com Tue Feb 8 02:00:49 2011 From: rdmurray at bitdance.com (R. David Murray) Date: Mon, 07 Feb 2011 20:00:49 -0500 Subject: [Python-Dev] Python Unit Tests In-Reply-To: References: Message-ID: <20110208010049.52B58225404@kimball.webabinitio.net> On Mon, 07 Feb 2011 20:38:28 -0200, Wesley Mesquita wrote: > [198/349] test_ossaudiodev > test_ossaudiodev skipped -- [Errno 2] No such file or directory: '/dev/dsp' This is normal since you don't have a /dev/dsp. That's what the skip message means. > [200/349] test_parser > Expecting 's_push: parser stack overflow' in next line > s_push: parser stack overflow "Expecting" means the next message is expected. Someone should probably check to see if this test can (in Python3) be rewritten so that message isn't generated, but for now it is Expected and completely normal. > [321/349] test_urllib2net > /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed > > self._sock = None There are some ResourceWarnings we haven't cured yet (the ResourceWarning is a fairly new innovation). I'm not sure why they don't show up when you run the tests individually. > 9 skips unexpected on linux2: > test_bz2 test_dbm_gnu test_dbm_ndbm test_readline test_ssl > test_tcl test_tk test_ttk_guionly test_ttk_textonly These would be because you don't have the correct system/development libraries installed for bz2, gnudbm, ndbm, readline, openssl, tcl, and tk when you compiled your Python. So, these skips are actually expected if you don't have those libraries, but if you want a complete development/test environment you should install the necessary packages and recompile. I imagine at least some of this is already covered in the dev guide (I haven't made time to review it yet). If any of it is unclear to you, please provide feedback so we can improve the guide (which is new). -- R. David Murray www.bitdance.com From mal at egenix.com Tue Feb 8 09:32:50 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 08 Feb 2011 09:32:50 +0100 Subject: [Python-Dev] Python Unit Tests In-Reply-To: References: Message-ID: <4D50FFB2.8070209@egenix.com> Wesley Mesquita wrote: > Hi all, > > I starting to explore python 3k core development environment. So, sorry in > advance for any mistakes, but I really don't know what is the best list to > post this, since it not a "use of python" issue, and probably is not a dev > issue, it is more like a "dev env" question. > > I have ran the test suit, and got the messages below. > > ~/python_dev/python$ make testall > > ./python -Wd -E -bb ./Lib/test/regrtest.py -uall -l > == CPython 3.2rc2+ (py3k:88376, Feb 7 2011, 18:31:28) [GCC 4.4.5] > == Linux-2.6.35-24-generic-x86_64-with-debian-squeeze-sid little-endian > == /home/wesley/python_dev/python/build/test_python_3387 > Testing with flags: sys.flags(debug=0, division_warning=0, inspect=0, > interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, > ignore_environment=1, verbose=0, bytes_warning=2, quiet=0) > > [...] > > [198/349] test_ossaudiodev > test_ossaudiodev skipped -- [Errno 2] No such file or directory: '/dev/dsp' > > [...] > > [200/349] test_parser > Expecting 's_push: parser stack overflow' in next line > s_push: parser stack overflow > > [...] > > [321/349] test_urllib2net > /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed > > self._sock = None > /home/wesley/python_dev/python/Lib/urllib/request.py:2134: ResourceWarning: > unclosed > sys.exc_info()[2]) > /home/wesley/python_dev/python/Lib/urllib/request.py:2134: ResourceWarning: > unclosed > sys.exc_info()[2]) > /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed > > self._sock = None > /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed > > self._sock = None > /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed > > self._sock = None > /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed > > self._sock = None > [323/349] test_urllibnet > /home/wesley/python_dev/python/Lib/socket.py:333: ResourceWarning: unclosed > > self._sock = None > > > 24 tests skipped: > test_bz2 test_curses test_dbm_gnu test_dbm_ndbm test_gdb > test_kqueue test_ossaudiodev test_readline test_smtpnet > test_socketserver test_sqlite test_ssl test_startfile test_tcl > test_timeout test_tk test_ttk_guionly test_ttk_textonly > test_urllib2net test_urllibnet test_winreg test_winsound > test_xmlrpc_net test_zipfile64 > 9 skips unexpected on linux2: > test_bz2 test_dbm_gnu test_dbm_ndbm test_readline test_ssl > test_tcl test_tk test_ttk_guionly test_ttk_textonly > sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' > mode='a' encoding='UTF-8'> > > > But running each of them individually: > > :~/python_dev/python$ ./python Lib/test/regrtest.py test_ossaudiodev > [1/1] test_ossaudiodev > test_ossaudiodev skipped -- Use of the `audio' resource not enabled > 1 test skipped: > test_ossaudiodev > Those skips are all expected on linux2. > > ./python Lib/test/regrtest.py test_parser > [1/1] test_parser > Expecting 's_push: parser stack overflow' in next line > s_push: parser stack overflow > 1 test OK. > > ./python Lib/test/regrtest.py test_urllib2net[1/1] test_urllib2net > test_urllib2net skipped -- Use of the `network' resource not enabled > 1 test skipped: > test_urllib2net > Those skips are all expected on linux2. > > Is there any reason for the different results? Yes: you are not using the same options on the stand-alone tests as you are on the suite run. Most importantly, you are not enabling all resources (-uall). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 08 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From solipsis at pitrou.net Tue Feb 8 14:26:59 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Tue, 8 Feb 2011 14:26:59 +0100 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. In-Reply-To: References: <20110206171542.3859df07@pitrou.net> Message-ID: <20110208142659.07f8b515@pitrou.net> On Sun, 6 Feb 2011 12:13:08 -0800 Brett Cannon wrote: > > > > We could perhaps present SVN-like "work in the working copy" workflow > > (without local commits), and let seasoned hg users choose other > > workflows they like more (they don't need our help anyway). > > I would rather give people some simple workflow that has some benefit > over svn. Basically whatever is the easiest to comprehend and work > with should be what we start people with. Ok, I've updated the devguide to present a simple named branch-based approach. I'm not sure it is our job to *explain* hg features, so I've just given a couple of minimal instructions to get people on track. Regards Antoine. From ncoghlan at gmail.com Tue Feb 8 15:17:51 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 9 Feb 2011 00:17:51 +1000 Subject: [Python-Dev] Python Unit Tests In-Reply-To: <20110208010049.52B58225404@kimball.webabinitio.net> References: <20110208010049.52B58225404@kimball.webabinitio.net> Message-ID: On Tue, Feb 8, 2011 at 11:00 AM, R. David Murray wrote: > There are some ResourceWarnings we haven't cured yet (the ResourceWarning is > a fairly new innovation). ?I'm not sure why they don't show up when > you run the tests individually. Almost certainly the missing "-uall" meant the relevant tests didn't actually run the second time around. >> 9 skips unexpected on linux2: >> ? ? test_bz2 test_dbm_gnu test_dbm_ndbm test_readline test_ssl >> ? ? test_tcl test_tk test_ttk_guionly test_ttk_textonly > > These would be because you don't have the correct system/development > libraries installed for bz2, gnudbm, ndbm, readline, openssl, > tcl, and tk when you compiled your Python. ?So, these skips are > actually expected if you don't have those libraries, but if you want > a complete development/test environment you should install the > necessary packages and recompile. I put together a list a while back of the minimal set of dev packages needed to do a full Python build on Kubuntu: http://www.boredomandlaziness.org/2010/01/kubuntu-dev-packages-to-build-python.html The apt-get build dependencies command added as a comment to that post should work on any apt-based Linux variant (although, at least on Kubuntu, it brings down quite a lot of stuff you don't actually need in order to build Python). Presumably there's something similar available for other packaging systems (if not, the minimal package list may still provide a useful starting point) I don't believe anything that platform specific is in the dev guide, though (it wasn't in the old README files, that's why I made my own list for later reference). Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From guido at python.org Tue Feb 8 19:15:54 2011 From: guido at python.org (Guido van Rossum) Date: Tue, 8 Feb 2011 10:15:54 -0800 Subject: [Python-Dev] http://www.pythonlabs.com/logos.html is gone In-Reply-To: References: Message-ID: As a late follow-up to this thread, I still get a bunch of hits a day on this URL (and also on www.pythonlabs.com/talks.html -- I have no idea what popular page *that* is still linked from). I don't suppose we can *ever* delete that link from the LICENSE file? On Sun, Oct 11, 2009 at 1:46 PM, Georg Brandl wrote: > Guido van Rossum schrieb: >> On Sun, Oct 11, 2009 at 12:55 PM, Georg Brandl wrote: >>> Which I noticed since it's cited in the BeOpen license we still refer >>> to in LICENSE. ?Since pythonlabs.com itself is still up, it probably >>> isn't much work to make the logos.html URI work again, but I don't know >>> who maintains that page. >> >> I own the domain. I don't know what was on logos.html and >> http://web.archive.org won't show it to me because of a robots.txt >> file. I think it's fine to let it be a 404. > > Okay. ?Though I am fairly sure that Tim *would* remember ;) > > 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 > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) From brett at python.org Tue Feb 8 19:33:05 2011 From: brett at python.org (Brett Cannon) Date: Tue, 8 Feb 2011 10:33:05 -0800 Subject: [Python-Dev] devguide: Basic instructions on how to generate a patch with hg for non-committers. In-Reply-To: <20110208142659.07f8b515@pitrou.net> References: <20110206171542.3859df07@pitrou.net> <20110208142659.07f8b515@pitrou.net> Message-ID: On Tue, Feb 8, 2011 at 05:26, Antoine Pitrou wrote: > On Sun, 6 Feb 2011 12:13:08 -0800 > Brett Cannon wrote: >> > >> > We could perhaps present SVN-like "work in the working copy" workflow >> > (without local commits), and let seasoned hg users choose other >> > workflows they like more (they don't need our help anyway). >> >> I would rather give people some simple workflow that has some benefit >> over svn. Basically whatever is the easiest to comprehend and work >> with should be what we start people with. > > Ok, I've updated the devguide to present a simple named branch-based > approach. I'm not sure it is our job to *explain* hg features, so I've > just given a couple of minimal instructions to get people on track. Yep, what you wrote is what I was thinking. Enough so people can get up and going and at least a taste of what hg can do for them w/o devolving into an hg tutorial. -Brett > > Regards > > Antoine. > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org > From brett at python.org Wed Feb 9 01:53:43 2011 From: brett at python.org (Brett Cannon) Date: Tue, 8 Feb 2011 16:53:43 -0800 Subject: [Python-Dev] [Python-checkins] devguide: Try to explain the two most common approaches to hg workflow: feature In-Reply-To: <4D51C335.10306@udel.edu> References: <4D51C335.10306@udel.edu> Message-ID: fixed On Tue, Feb 8, 2011 at 14:27, Terry Reedy wrote: > >> +While non-committers can use named branches without issue, as a core >> developer >> +you should limit their use to only those branches to be used to >> collaborate > > either /their/your/ > or /as a core developer you/core developers/ > I prefer latter as parallel to 'non-committers'. > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://mail.python.org/mailman/listinfo/python-checkins > From marks at dcs.gla.ac.uk Wed Feb 9 10:09:08 2011 From: marks at dcs.gla.ac.uk (Mark Shannon) Date: Wed, 09 Feb 2011 09:09:08 +0000 Subject: [Python-Dev] API bloat Message-ID: <4D5259B4.8030205@dcs.gla.ac.uk> At sometime between versions 3.1 and the current version, 3.1.3, the API grew considerably. See http://docs.python.org/release/3.1/c-api/exceptions.html#exception-handling and http://docs.python.org/py3k/c-api/exceptions.html#exception-handling The Unicode Exception Objects section is new and seemingly redundant: http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects Should this be in the public API? Is there any kind of review system (like PEPs) for modifying the C API? Are bug-fix updates really the place to modify the API? Could the API be reverted to the 3.1 version plus any *necessary* changes in time for the 3.2 release? Remember the C API is a promise to support these functions for years to come and a burden on other implementations, including future CPythons. So could the CPython internal APIs be kept out of the public API? Please. Cheers, Mark. From g.brandl at gmx.net Wed Feb 9 10:44:49 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Wed, 09 Feb 2011 10:44:49 +0100 Subject: [Python-Dev] API bloat In-Reply-To: <4D5259B4.8030205@dcs.gla.ac.uk> References: <4D5259B4.8030205@dcs.gla.ac.uk> Message-ID: Am 09.02.2011 10:09, schrieb Mark Shannon: > At sometime between versions 3.1 and the current version, 3.1.3, > the API grew considerably. > See > http://docs.python.org/release/3.1/c-api/exceptions.html#exception-handling > and > http://docs.python.org/py3k/c-api/exceptions.html#exception-handling > > The Unicode Exception Objects section is new and seemingly redundant: Why redundant? > http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects > Should this be in the public API? While this question is valid, it *should* have been asked 8 years ago, when the functions were actually added. They are new in the docs because they weren't documented before. Otherwise they would have a "New in version 3.2" tag. > Is there any kind of review system (like PEPs) for modifying the C API? No, but python-dev is involved by either a thread here or an issue that is then OK'd by several developers. > Are bug-fix updates really the place to modify the API? No, but that's not relevant here. > Could the API be reverted to the 3.1 version plus any *necessary* > changes in time for the 3.2 release? Any changes in API are definitely forbidden before 3.2. Georg From marks at dcs.gla.ac.uk Wed Feb 9 11:37:11 2011 From: marks at dcs.gla.ac.uk (Mark Shannon) Date: Wed, 09 Feb 2011 10:37:11 +0000 Subject: [Python-Dev] API bloat In-Reply-To: References: <4D5259B4.8030205@dcs.gla.ac.uk> Message-ID: <4D526E57.9030206@dcs.gla.ac.uk> Georg Brandl wrote: > Am 09.02.2011 10:09, schrieb Mark Shannon: >> At sometime between versions 3.1 and the current version, 3.1.3, >> the API grew considerably. >> See >> http://docs.python.org/release/3.1/c-api/exceptions.html#exception-handling >> and >> http://docs.python.org/py3k/c-api/exceptions.html#exception-handling >> >> The Unicode Exception Objects section is new and seemingly redundant: > > Why redundant? Because they are all attribute getter and setters. For example: PyUnicodeDecodeError_GetStart(exc, x) <=> PyObject_GetAttr(exc, "start", x) This sort of redundancy seems sensible for list, tuple and such. It just seems like bloat for classes like UnicodeDecodeError. > >> http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects >> Should this be in the public API? > > While this question is valid, it *should* have been asked 8 years ago, when > the functions were actually added. The functions may have been add to CPython 8 years ago, but they were added to the API when they appeared in the docs, between 3.1 and 3.1.3. How is the API defined, if not by the documentation? The header files do not specify what is API and what is implementation specific. > > They are new in the docs because they weren't documented before. Otherwise > they would have a "New in version 3.2" tag. > >> Is there any kind of review system (like PEPs) for modifying the C API? > > No, but python-dev is involved by either a thread here or an issue that > is then OK'd by several developers. > >> Are bug-fix updates really the place to modify the API? > > No, but that's not relevant here. > >> Could the API be reverted to the 3.1 version plus any *necessary* >> changes in time for the 3.2 release? > > Any changes in API are definitely forbidden before 3.2. If that is the case then the API, as defined by http://docs.python.org/py3k/c-api/index.html should be same for 3.2 as for 3.1, plus a few functions, that are explicitly marked as "New in version 3.2". Unfortunately, that is not currently the case. > > Georg > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/marks%40dcs.gla.ac.uk > From georg at python.org Wed Feb 9 11:49:34 2011 From: georg at python.org (Georg Brandl) Date: Wed, 09 Feb 2011 11:49:34 +0100 Subject: [Python-Dev] API bloat In-Reply-To: <4D5266B0.6030701@dcs.gla.ac.uk> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5266B0.6030701@dcs.gla.ac.uk> Message-ID: <4D52713E.5040405@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (Not sure if your message went to python-dev too.) Am 09.02.2011 11:04, schrieb Mark Shannon: > Georg Brandl wrote: >> Am 09.02.2011 10:09, schrieb Mark Shannon: >>> At sometime between versions 3.1 and the current version, 3.1.3, >>> the API grew considerably. >>> See >>> http://docs.python.org/release/3.1/c-api/exceptions.html#exception-handling >>> and >>> http://docs.python.org/py3k/c-api/exceptions.html#exception-handling >>> >>> The Unicode Exception Objects section is new and seemingly redundant: >> >> Why redundant? > > Because they are all attribute getter and setters. For example: > > PyUnicodeDecodeError_GetStart(exc, x) <=> > PyObject_GetAttr(exc, "start", x) > > This sort of redundancy seems sensible for list, tuple and such. > It just seems like bloat for classes like UnicodeDecodeError. Have you looked at the implementation? They do some more, e.g. make sure the returned value is within the boundaries of the offending string. (Yes, that probably should be in the docs too.) >>> http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects >>> Should this be in the public API? >> >> While this question is valid, it *should* have been asked 8 years ago, when >> the functions were actually added. > > The functions may have been add to CPython 8 years ago, but they were > added to the API when they appeared in the docs, between 3.1 and 3.1.3. > > How is the API defined, if not by the documentation? > The header files do not specify what is API and what is implementation > specific. The API is defined by all functions (and macros, and types) defined by the headers starting with a "Py" prefix. Implementation specific functions have a "_Py" prefix. - From 3.2, we also have a "Limited API" (see PEP 384) that defines a set of API that will not change, and is guaranteed to have a consistent ABI between Python minor versions. >>> Could the API be reverted to the 3.1 version plus any *necessary* >>> changes in time for the 3.2 release? >> >> Any changes in API are definitely forbidden before 3.2. > > If that is the case then the API, as defined by > http://docs.python.org/py3k/c-api/index.html > should be same for 3.2 as for 3.1, plus a few functions, > that are explicitly marked as "New in version 3.2". > > Unfortunately, that is not currently the case. In any case, these are doc bugs. In the past, many additions to the C API were made without proper documentation changes, and we are still working to clean this up. So, yes: modulo doc bugs, any function that newly appears in the 3.2 docs either has a "New in version 3.2" tag, or has been present in 3.1 already. Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1ScT4ACgkQN9GcIYhpnLDEjwCggMLnpWoeL7Vpg3SiZlfJvJ0H 2isAn0hhBmbUelr4Of+kAqPopWc5s5ro =xYhv -----END PGP SIGNATURE----- From solipsis at pitrou.net Wed Feb 9 11:56:00 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 9 Feb 2011 11:56:00 +0100 Subject: [Python-Dev] API bloat References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> Message-ID: <20110209115600.39719cd3@pitrou.net> On Wed, 09 Feb 2011 10:37:11 +0000 Mark Shannon wrote: > > > > Why redundant? > > Because they are all attribute getter and setters. For example: > > PyUnicodeDecodeError_GetStart(exc, x) <=> > PyObject_GetAttr(exc, "start", x) > > This sort of redundancy seems sensible for list, tuple and such. > It just seems like bloat for classes like UnicodeDecodeError. It's not exactly the same thing, still. PyObject_GetAttr() will do a full blown attribute access, while I guess (I didn't check) PyUnicodeDecodeError_GetStart() accesses the C struct member directly. Also, the latter gives you a Py_ssize_t object, which relieves you from having to do a conversion explicitly. I do agree that it doesn't seem widely used, according to Google Code Search :) > >> http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects > >> Should this be in the public API? > > > > While this question is valid, it *should* have been asked 8 years ago, when > > the functions were actually added. > > The functions may have been add to CPython 8 years ago, but they were > added to the API when they appeared in the docs, between 3.1 and 3.1.3. > > How is the API defined, if not by the documentation? > The header files do not specify what is API and what is implementation > specific. True. But if they were added to the documentation, it's certainly because they were *intended* to be part of the API from the start. (after all, core CPython code can just access the C struct fields directly rather than go through a function call) Take it as acknowledging that it has *always* been part of the intended API. These days, we try to follow a stricter naming convention: when we want an API to remain explicitly private, we often prefix it with an underscore. But that has not been the case in the past, I admit. > > Any changes in API are definitely forbidden before 3.2. > > If that is the case then the API, as defined by > http://docs.python.org/py3k/c-api/index.html > should be same for 3.2 as for 3.1, plus a few functions, > that are explicitly marked as "New in version 3.2". > > Unfortunately, that is not currently the case. How so? Can you give an example? Regards Antoine. From mal at egenix.com Wed Feb 9 12:00:44 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 09 Feb 2011 12:00:44 +0100 Subject: [Python-Dev] API bloat In-Reply-To: <4D5259B4.8030205@dcs.gla.ac.uk> References: <4D5259B4.8030205@dcs.gla.ac.uk> Message-ID: <4D5273DC.3020409@egenix.com> Mark Shannon wrote: > The Unicode Exception Objects section is new and seemingly redundant: > http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects > Should this be in the public API? Those function have been in the public API since we introduced Unicode callbak error handlers. It was an oversight that these were not documented in the Python documentation. They have been documented part of the unicodeobject.h ever since they were introduced. Note that these APIs are needed by codecs supporting the callback error handlers, and since performance matters a lot for codecs, the C APIs were introduced. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 09 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From marks at dcs.gla.ac.uk Wed Feb 9 13:11:43 2011 From: marks at dcs.gla.ac.uk (Mark Shannon) Date: Wed, 09 Feb 2011 12:11:43 +0000 Subject: [Python-Dev] API bloat In-Reply-To: <4D5273DC.3020409@egenix.com> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com> Message-ID: <4D52847F.10006@dcs.gla.ac.uk> M.-A. Lemburg wrote: > Mark Shannon wrote: >> The Unicode Exception Objects section is new and seemingly redundant: >> http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects >> Should this be in the public API? > > Those function have been in the public API since we introduced > Unicode callbak error handlers. > > It was an oversight that these were not documented in the Python > documentation. They have been documented part of the unicodeobject.h > ever since they were introduced. > > Note that these APIs are needed by codecs supporting the > callback error handlers, and since performance matters a lot > for codecs, the C APIs were introduced. > OK, so UnicodeError_xxx is important for codecs, but surely this sort of argument could be made for lots of things. Don't forget that for each function added to the API, all other implementations have to support it forever. Unfortunately, UnicodeError_xxx are not the only new functions. Various others have been added: int Py_EnterRecursiveCall(char *where) void Py_LeaveRecursiveCall() int Py_ReprEnter(PyObject *object) void Py_ReprLeave(PyObject *object) HotPyModule_GetFilenameObject HotPy_CompileStringExFlags and a few others. Individual functions are not the problem, I'm sure all of these can be justified, its lack of process and review that bothers me. Mark. From ncoghlan at gmail.com Wed Feb 9 13:43:12 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 9 Feb 2011 22:43:12 +1000 Subject: [Python-Dev] API bloat In-Reply-To: <4D52847F.10006@dcs.gla.ac.uk> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com> <4D52847F.10006@dcs.gla.ac.uk> Message-ID: On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon wrote: > OK, so UnicodeError_xxx is important for codecs, but surely this sort of > argument could be made for lots of things. > Don't forget that for each function added to the API, > all other implementations have to support it forever. Other implementations that want to support CPython extensions should focus their efforts on the limited API defined in PEP 384. That will not only be a lot easier, it will also be less of a moving target. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From exarkun at twistedmatrix.com Wed Feb 9 14:03:39 2011 From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com) Date: Wed, 09 Feb 2011 13:03:39 -0000 Subject: [Python-Dev] API bloat In-Reply-To: References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com> <4D52847F.10006@dcs.gla.ac.uk> Message-ID: <20110209130339.1699.1037684053.divmod.xquotient.1402@localhost.localdomain> On 12:43 pm, ncoghlan at gmail.com wrote: >On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon >wrote: >>OK, so UnicodeError_xxx is important for codecs, but surely this sort >>of >>argument could be made for lots of things. >>Don't forget that for each function added to the API, >>all other implementations have to support it forever. > >Other implementations that want to support CPython extensions should >focus their efforts on the limited API defined in PEP 384. That will >not only be a lot easier, it will also be less of a moving target. And will produce what kind of results? How many extension libraries work with this subset? Jean-Paul From benjamin at python.org Wed Feb 9 14:58:55 2011 From: benjamin at python.org (Benjamin Peterson) Date: Wed, 9 Feb 2011 07:58:55 -0600 Subject: [Python-Dev] API bloat In-Reply-To: <20110209130339.1699.1037684053.divmod.xquotient.1402@localhost.localdomain> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com> <4D52847F.10006@dcs.gla.ac.uk> <20110209130339.1699.1037684053.divmod.xquotient.1402@localhost.localdomain> Message-ID: 2011/2/9 : > On 12:43 pm, ncoghlan at gmail.com wrote: >> >> On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon wrote: >>> >>> OK, so UnicodeError_xxx is important for codecs, but surely this sort of >>> argument could be made for lots of things. >>> Don't forget that for each function added to the API, >>> all other implementations have to support it forever. >> >> Other implementations that want to support CPython extensions should >> focus their efforts on the limited API defined in PEP 384. That will >> not only be a lot easier, it will also be less of a moving target. > > And will produce what kind of results? ?How many extension libraries work > with this subset? Probably none because it hasn't been released. That's the goal. -- Regards, Benjamin From ncoghlan at gmail.com Wed Feb 9 14:59:48 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 9 Feb 2011 23:59:48 +1000 Subject: [Python-Dev] API bloat In-Reply-To: <20110209130339.1699.1037684053.divmod.xquotient.1402@localhost.localdomain> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com> <4D52847F.10006@dcs.gla.ac.uk> <20110209130339.1699.1037684053.divmod.xquotient.1402@localhost.localdomain> Message-ID: On Wed, Feb 9, 2011 at 11:03 PM, wrote: > On 12:43 pm, ncoghlan at gmail.com wrote: >> >> On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon wrote: >>> >>> OK, so UnicodeError_xxx is important for codecs, but surely this sort of >>> argument could be made for lots of things. >>> Don't forget that for each function added to the API, >>> all other implementations have to support it forever. >> >> Other implementations that want to support CPython extensions should >> focus their efforts on the limited API defined in PEP 384. That will >> not only be a lot easier, it will also be less of a moving target. > > And will produce what kind of results? ?How many extension libraries work > with this subset? Right now? Very few, given the changes to the way types need to be created. But prioritising it will speed convergence over time as more extension modules cut over to it for the stable ABI benefits. And, since the C API has never been anywhere near as tightly controlled as the language definition, alternative implementations are going to garner more sympathy if they restrict their concerns to the growth of the stable ABI rather than worrying about an implementation detail of CPython. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From benjamin at python.org Wed Feb 9 15:00:49 2011 From: benjamin at python.org (Benjamin Peterson) Date: Wed, 9 Feb 2011 08:00:49 -0600 Subject: [Python-Dev] API bloat In-Reply-To: <4D52847F.10006@dcs.gla.ac.uk> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com> <4D52847F.10006@dcs.gla.ac.uk> Message-ID: 2011/2/9 Mark Shannon : > OK, so UnicodeError_xxx is important for codecs, but surely this sort of > argument could be made for lots of things. > Don't forget that for each function added to the API, > all other implementations have to support it forever. The C-API is about the biggest implementation detail of CPython, so no, they don't have to. > > Unfortunately, UnicodeError_xxx are not the only new functions. > > Various others have been added: > > int Py_EnterRecursiveCall(char *where) > void Py_LeaveRecursiveCall() > int Py_ReprEnter(PyObject *object) > void Py_ReprLeave(PyObject *object) > > HotPyModule_GetFilenameObject > HotPy_CompileStringExFlags > > and a few others. > > Individual functions are not the problem, > I'm sure all of these can be justified, > its lack of process and review that bothers me. If they can be justified, what is the process lacking? -- Regards, Benjamin From fuzzyman at voidspace.org.uk Wed Feb 9 15:11:51 2011 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 09 Feb 2011 14:11:51 +0000 Subject: [Python-Dev] API bloat In-Reply-To: References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com> <4D52847F.10006@dcs.gla.ac.uk> Message-ID: <4D52A0A7.2000507@voidspace.org.uk> On 09/02/2011 14:00, Benjamin Peterson wrote: > 2011/2/9 Mark Shannon: >> OK, so UnicodeError_xxx is important for codecs, but surely this sort of >> argument could be made for lots of things. >> Don't forget that for each function added to the API, >> all other implementations have to support it forever. > The C-API is about the biggest implementation detail of CPython, so > no, they don't have to. > Alternative implementations that want C extensions to work (like Ironclad for IronPython and cpyext for pypy) do implement the parts of the C API that are most widely used though. Of course they don't *have to*, but c extension compatibility is one of the biggest problems for users of alternative implementations. Hopefully the stable ABI will improve this situation for the future, but realistically its going to be a few years before it has an appreciable effect. Michael >> Unfortunately, UnicodeError_xxx are not the only new functions. >> >> Various others have been added: >> >> int Py_EnterRecursiveCall(char *where) >> void Py_LeaveRecursiveCall() >> int Py_ReprEnter(PyObject *object) >> void Py_ReprLeave(PyObject *object) >> >> HotPyModule_GetFilenameObject >> HotPy_CompileStringExFlags >> >> and a few others. >> >> Individual functions are not the problem, >> I'm sure all of these can be justified, >> its lack of process and review that bothers me. > > If they can be justified, what is the process lacking? > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From fuzzyman at voidspace.org.uk Wed Feb 9 15:13:08 2011 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 09 Feb 2011 14:13:08 +0000 Subject: [Python-Dev] API bloat In-Reply-To: References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com> <4D52847F.10006@dcs.gla.ac.uk> <20110209130339.1699.1037684053.divmod.xquotient.1402@localhost.localdomain> Message-ID: <4D52A0F4.3010801@voidspace.org.uk> On 09/02/2011 13:59, Nick Coghlan wrote: > [snip...] > And, since the C API has never been anywhere near as tightly > controlled as the language definition, alternative implementations are > going to garner more sympathy if they restrict their concerns to the > growth of the stable ABI rather than worrying about an implementation > detail of CPython. Actually the opposite. Users tend to be very unsympathetic when extensions they depend on don't work with alternative implementations (I speak from experience). Michael > Cheers, > Nick. > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From exarkun at twistedmatrix.com Wed Feb 9 15:13:11 2011 From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com) Date: Wed, 09 Feb 2011 14:13:11 -0000 Subject: [Python-Dev] API bloat In-Reply-To: References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com> <4D52847F.10006@dcs.gla.ac.uk> <20110209130339.1699.1037684053.divmod.xquotient.1402@localhost.localdomain> Message-ID: <20110209141311.1699.1389612648.divmod.xquotient.1404@localhost.localdomain> On 01:59 pm, ncoghlan at gmail.com wrote: >On Wed, Feb 9, 2011 at 11:03 PM, wrote: >>On 12:43 pm, ncoghlan at gmail.com wrote: >>> >>>On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon >>>wrote: >>>> >>>>OK, so UnicodeError_xxx is important for codecs, but surely this >>>>sort of >>>>argument could be made for lots of things. >>>>Don't forget that for each function added to the API, >>>>all other implementations have to support it forever. >>> >>>Other implementations that want to support CPython extensions should >>>focus their efforts on the limited API defined in PEP 384. That will >>>not only be a lot easier, it will also be less of a moving target. >> >>And will produce what kind of results? ?How many extension libraries >>work >>with this subset? > >Right now? Very few, given the changes to the way types need to be >created. But prioritising it will speed convergence over time as more >extension modules cut over to it for the stable ABI benefits. > >And, since the C API has never been anywhere near as tightly >controlled as the language definition, alternative implementations are >going to garner more sympathy if they restrict their concerns to the >growth of the stable ABI rather than worrying about an implementation >detail of CPython. Sympathy, perhaps. But that doesn't mean people will drop everything and rewrite their extension modules. Jean-Paul From solipsis at pitrou.net Wed Feb 9 15:41:33 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 9 Feb 2011 15:41:33 +0100 Subject: [Python-Dev] API bloat References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com> <4D52847F.10006@dcs.gla.ac.uk> Message-ID: <20110209154133.3dc754e5@pitrou.net> On Wed, 09 Feb 2011 12:11:43 +0000 Mark Shannon wrote: > Various others have been added: > > int Py_EnterRecursiveCall(char *where) > void Py_LeaveRecursiveCall() > int Py_ReprEnter(PyObject *object) > void Py_ReprLeave(PyObject *object) Again, they haven't been "added". They have been there for a long time; it's just that they weren't documented before (either because it was overlooked or out of laziness, I don't know). And these 4 functions are definitely useful for extension modules. > HotPyModule_GetFilenameObject > HotPy_CompileStringExFlags Judging by the "HotPy" prefix, these aren't CPython functions ;) > I'm sure all of these can be justified, > its lack of process and review that bothers me. Process and review of new APIs usually go through the issue tracker. We also have a ton of new stdlib APIs in 3.2: http://docs.python.org/dev/whatsnew/3.2.html If each of these new APIs went through a python-dev discussion, this mailing-list would become a huge mess. Regards Antoine. From solipsis at pitrou.net Wed Feb 9 15:45:31 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 9 Feb 2011 15:45:31 +0100 Subject: [Python-Dev] API bloat References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D5273DC.3020409@egenix.com> <4D52847F.10006@dcs.gla.ac.uk> <20110209130339.1699.1037684053.divmod.xquotient.1402@localhost.localdomain> <20110209141311.1699.1389612648.divmod.xquotient.1404@localhost.localdomain> Message-ID: <20110209154531.25117bd3@pitrou.net> On Wed, 09 Feb 2011 14:13:11 -0000 exarkun at twistedmatrix.com wrote: > >And, since the C API has never been anywhere near as tightly > >controlled as the language definition, alternative implementations are > >going to garner more sympathy if they restrict their concerns to the > >growth of the stable ABI rather than worrying about an implementation > >detail of CPython. > > Sympathy, perhaps. But that doesn't mean people will drop everything > and rewrite their extension modules. Using the stable ABI should have maintenance advantages, since you don't have to compile a separate package for each Python version. How far distutils goes to support version-independent binary distributions I don't know, though. But at least the stable ABI is a step in that direction. And of course you don't need to "rewrite your extension modules". Apparently type definitions have to be adapted, and you have to make sure you aren't using functions that are not in the limited API, but otherwise things should work fine. Regards Antoine. From skip at pobox.com Wed Feb 9 18:32:38 2011 From: skip at pobox.com (skip at pobox.com) Date: Wed, 9 Feb 2011 11:32:38 -0600 Subject: [Python-Dev] python 3.2 (fwd) Message-ID: <19794.53174.766166.195523@montanaro.dyndns.org> Passing this along from webmaster. S -------------- next part -------------- An embedded message was scrubbed... From: "Mayur Patel" Subject: python 3.2 Date: Wed, 9 Feb 2011 10:55:34 -0500 Size: 8564 URL: From tjreedy at udel.edu Wed Feb 9 20:21:35 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 09 Feb 2011 14:21:35 -0500 Subject: [Python-Dev] python 3.2 (fwd) In-Reply-To: <19794.53174.766166.195523@montanaro.dyndns.org> References: <19794.53174.766166.195523@montanaro.dyndns.org> Message-ID: <4D52E93F.3020108@udel.edu> On 2/9/2011 12:32 PM, skip at pobox.com wrote: > Passing this along from webmaster. It is hard to reply to an attachment rather than inline forwarded message. However, with rc1 >>> import sqlite3 >>> sqlite3.version '2.6.0' >>> sqlite3.sqlite_version '3.7.4' I added 'pysqlite' to the "What's new" entry. -- Terry Jan Reedy From martin at v.loewis.de Wed Feb 9 20:55:19 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 09 Feb 2011 20:55:19 +0100 Subject: [Python-Dev] API bloat In-Reply-To: <4D526E57.9030206@dcs.gla.ac.uk> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> Message-ID: <4D52F127.4050906@v.loewis.de> > The functions may have been add to CPython 8 years ago, but they were > added to the API when they appeared in the docs, between 3.1 and 3.1.3. > > How is the API defined, if not by the documentation? Just to stress and support Georg's explanation: the API is *not* defined through the documentation, but instead primarily through the header files. All functions declared as PyAPI_FUNC and not starting with _Py are public API. There used to be a lot of undocumented API (up to 1.4, there was no API documentation at all, only the extension module tutorial); these days, more and more API gets documented. HTH, Martin From solipsis at pitrou.net Wed Feb 9 21:29:19 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 9 Feb 2011 21:29:19 +0100 Subject: [Python-Dev] devguide: More clarifications: use the term 'working copy' and mention 'hg update'. References: Message-ID: <20110209212919.1a8f3fe1@pitrou.net> On Wed, 09 Feb 2011 21:17:51 +0100 brett.cannon wrote: > > > -One should always work from a checkout of the CPython source code. While it may > +One should always work from a working copy of the CPython source code. > +While it may > be tempting to work from the downloaded copy you already have installed on your The difference between "downloaded copy" and "working copy" isn't very clear. The important difference here is between "official stable version" and "latest development sources". > -To get a read-only checkout of CPython's source, you need to checkout the source > -code. To get a read-only checkout of > +To get a read-only checkout of CPython's source, you need a working copy the > +source code. To get a read-only checkout of Why talk about "checkout" at all? It's an SVN/CVS/RCS term, if I'm not mistaken (even though it may occasionally be used with hg, it's a synonym of "working copy" there). Regards Antoine. From brett at python.org Wed Feb 9 23:49:40 2011 From: brett at python.org (Brett Cannon) Date: Wed, 9 Feb 2011 14:49:40 -0800 Subject: [Python-Dev] devguide: More clarifications: use the term 'working copy' and mention 'hg update'. In-Reply-To: <20110209212919.1a8f3fe1@pitrou.net> References: <20110209212919.1a8f3fe1@pitrou.net> Message-ID: On Wed, Feb 9, 2011 at 12:29, Antoine Pitrou wrote: > On Wed, 09 Feb 2011 21:17:51 +0100 > brett.cannon wrote: >> >> >> -One should always work from a checkout of the CPython source code. While it may >> +One should always work from a working copy of the CPython source code. >> +While it may >> ?be tempting to work from the downloaded copy you already have installed on your > > The difference between "downloaded copy" and "working copy" isn't very > clear. The important difference here is between "official stable > version" and "latest development sources". I'll clarify. > >> -To get a read-only checkout of CPython's source, you need to checkout the source >> -code. To get a read-only checkout of >> +To get a read-only checkout of CPython's source, you need a working copy the >> +source code. To get a read-only checkout of > > Why talk about "checkout" at all? It's an SVN/CVS/RCS term, if I'm not > mistaken (even though it may occasionally be used with hg, it's a > synonym of "working copy" there). Since it's a synonym I didn't worry about it. I honestly just thought it flowed better. -Brett > > Regards > > Antoine. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org > From solipsis at pitrou.net Wed Feb 9 23:51:49 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 09 Feb 2011 23:51:49 +0100 Subject: [Python-Dev] devguide: More clarifications: use the term 'working copy' and mention 'hg update'. In-Reply-To: References: <20110209212919.1a8f3fe1@pitrou.net> Message-ID: <1297291909.3731.15.camel@localhost.localdomain> > > > >> -To get a read-only checkout of CPython's source, you need to checkout the source > >> -code. To get a read-only checkout of > >> +To get a read-only checkout of CPython's source, you need a working copy the > >> +source code. To get a read-only checkout of > > > > Why talk about "checkout" at all? It's an SVN/CVS/RCS term, if I'm not > > mistaken (even though it may occasionally be used with hg, it's a > > synonym of "working copy" there). > > Since it's a synonym I didn't worry about it. I honestly just thought > it flowed better. What I meant is that "To get a read-only checkout, you need a working copy" is kind of tautologic then. Regards Antoine. From merwok at netwok.org Wed Feb 9 23:57:48 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Wed, 09 Feb 2011 23:57:48 +0100 Subject: [Python-Dev] devguide: More clarifications: use the term 'working copy' and mention 'hg update'. In-Reply-To: References: <20110209212919.1a8f3fe1@pitrou.net> Message-ID: <4D531BEC.1030609@netwok.org> Le 09/02/2011 23:49, Brett Cannon a ?crit : > On Wed, Feb 9, 2011 at 12:29, Antoine Pitrou wrote: >>> -To get a read-only checkout of CPython's source, you need to checkout the source >>> -code. To get a read-only checkout of >>> +To get a read-only checkout of CPython's source, you need a working copy the >>> +source code. To get a read-only checkout of ?you need a working copy the source code? ? ?you need to clone the source code repository? (see below for more) >> Why talk about "checkout" at all? It's an SVN/CVS/RCS term, if I'm not >> mistaken (even though it may occasionally be used with hg, it's a >> synonym of "working copy" there). > Since it's a synonym I didn't worry about it. I honestly just thought > it flowed better. Agreed. The problem is that the terms do not map 1:1 from Subversion. When Subversion docs talk about getting a checkout, Mercurial tells to make a clone (which includes the working copy); in other cases, a strict distinction between repository and working copy is needed. I see no problems in using checkout when it flows better than working copy (especially as a verb). Sincerely hoping I don?t make things more confusing, Regards From g.brandl at gmx.net Thu Feb 10 08:10:02 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Thu, 10 Feb 2011 08:10:02 +0100 Subject: [Python-Dev] devguide: Fix a silly statement. In-Reply-To: References: Message-ID: Am 09.02.2011 23:58, schrieb brett.cannon: > brett.cannon pushed 7101df1bd817 to devguide: > > http://hg.python.org/devguide/rev/7101df1bd817 > changeset: 291:7101df1bd817 > branch: hg_transition > tag: tip > user: Brett Cannon > date: Wed Feb 09 14:58:17 2011 -0800 > summary: > Fix a silly statement. > > files: > setup.rst > > diff --git a/setup.rst b/setup.rst > --- a/setup.rst > +++ b/setup.rst > @@ -34,8 +34,7 @@ > :abbr:`VCS`. It also means you will have better tool > support through the VCS as it will provide a diff tool, etc. > > -To get a read-only checkout of CPython's source, you need a working copy the > -source code. To get a read-only checkout of > +To get a read-only checkout of > the :ref:`in-development ` branch of Python, run:: > > hg clone http://hg.python.org/cpython This statement is still somewhat silly, as a) you get a clone, not a checkout and b) it is not read only in any way: you can commit just fine. The only difference will be the entry in .hg/hgrc pointing the default repo to something you can't push to. Skimming through, the whole section "Checking out the code" is still way too SVN-point of viewy (e.g. you always get all branches anyway). Georg From tjreedy at udel.edu Thu Feb 10 08:13:00 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 10 Feb 2011 02:13:00 -0500 Subject: [Python-Dev] devguide: More clarifications: use the term 'working copy' and mention 'hg update'. In-Reply-To: <20110209212919.1a8f3fe1@pitrou.net> References: <20110209212919.1a8f3fe1@pitrou.net> Message-ID: On 2/9/2011 3:29 PM, Antoine Pitrou wrote: > Why talk about "checkout" at all? It's an SVN/CVS/RCS term, if I'm not > mistaken (even though it may occasionally be used with hg, it's a > synonym of "working copy" there). I believe it harkens back to early source code control systems where one person literally 'checked out' a file and got a write lock on it, similar to checking out a particular volume from the library )except that others could still read, unlike with the library). yes. good riddance (already done). -- Terry Jan Reedy From marks at dcs.gla.ac.uk Thu Feb 10 11:16:04 2011 From: marks at dcs.gla.ac.uk (Mark Shannon) Date: Thu, 10 Feb 2011 10:16:04 +0000 Subject: [Python-Dev] API bloat In-Reply-To: <4D52F127.4050906@v.loewis.de> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> Message-ID: <4D53BAE4.9070000@dcs.gla.ac.uk> Thanks to everyone for all their comments so far. Martin v. L?wis wrote: >> The functions may have been add to CPython 8 years ago, but they were >> added to the API when they appeared in the docs, between 3.1 and 3.1.3. >> >> How is the API defined, if not by the documentation? > > Just to stress and support Georg's explanation: the API is *not* defined > through the documentation, but instead primarily through the header > files. All functions declared as PyAPI_FUNC and not starting with _Py > are public API. There used to be a lot of undocumented API (up to 1.4, > there was no API documentation at all, only the extension module > tutorial); these days, more and more API gets documented. Doing a search for the regex: "PyAPI_FUNC\([^)]*\) *Py" in .h files, which should match API functions (functions starting _Py are excluded) gives the following result: Version matches 3.0 717 3.1.3 728 3.2b2 743 It would appear the API bloat is real, not just an artefact of updated docs. The "what's new for 3.2" API section: http://docs.python.org/dev/py3k/whatsnew/3.2.html#build-and-c-api-changes lists 6 new functions, yet according to my search, 15 have been added between 3.1.3 and 3.2b2. Of course 743 functions is about 700 too many, but that's a discussion for Python-ideas and PEP 384. Mark. > > HTH, > Martin > From ncoghlan at gmail.com Thu Feb 10 13:22:49 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 10 Feb 2011 22:22:49 +1000 Subject: [Python-Dev] API bloat In-Reply-To: <4D53BAE4.9070000@dcs.gla.ac.uk> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> Message-ID: On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon wrote: > Doing a search for the regex: ?"PyAPI_FUNC\([^)]*\) *Py" in .h files, > which should match API functions (functions starting _Py are excluded) gives > the following result: > > Version ?matches > 3.0 ? ? ? 717 > 3.1.3 ? ? 728 > 3.2b2 ? ? 743 > > It would appear the API ?bloat is real, > not just an artefact of updated docs. Since it doesn't account for #ifdef, a naive count like that isn't a valid basis for comparison. I would hazard a guess that a substantial amount of the additional numbers there are going to be from new alternative definitions of Py_hash_t and some of the Py_UNICODE macros. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From stefan_ml at behnel.de Thu Feb 10 13:51:16 2011 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 10 Feb 2011 13:51:16 +0100 Subject: [Python-Dev] API bloat In-Reply-To: <4D53BAE4.9070000@dcs.gla.ac.uk> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> Message-ID: Mark Shannon, 10.02.2011 11:16: > Of course 743 functions is about 700 too many, Sorry, but that's so wrong, it's just being mean. What do you expect from a platform that has grown for more than 20 years? And which has been the only (real) Python implementation for most of that time. I'm sure it'll be easy to find, say, 200 functions that are not really required (PySequence_Fast?), but many of those make the life easier for C programmers and/or have helped with portability in the past. Most of those "C helper functions" long predate the dedicated extension writer tools that bring relieve from calling them. Mind you, even the Cython project is only some 4 years old, and even there you will still want to call a C-API function or two from time to time. Seriously, CPython's C-API has always been a *reason* for it to be popular. Many important tools wouldn't even exist without it, and sure wouldn't be in their current state if the C-API had not evolved together with them. Just think of NumPy, which is one (if not *the* one) of the main attractors for other Python implementations to get their view of the C-API implemented. Stefan From ncoghlan at gmail.com Thu Feb 10 14:00:08 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 10 Feb 2011 23:00:08 +1000 Subject: [Python-Dev] [Python-checkins] r88385 - python/branches/py3k/Doc/whatsnew/3.2.rst In-Reply-To: <20110210092026.60330EEAD7@mail.python.org> References: <20110210092026.60330EEAD7@mail.python.org> Message-ID: On Thu, Feb 10, 2011 at 7:20 PM, raymond.hettinger wrote: > +The :func:`logging.basicConfig` set-up function gained a *style* argument to > +support three different types of string formatting. ?It defaults to "%" for > +traditional %-formatting, can be set to "{" for the new :meth:`str.format` style, or > +can be set to "$" for the shell-style formatting provided by > +:class:`string.Template`. ?The following three configurations are equivalent:: > + > + ? ?>>> from logging import basicConfig > + ? ?>>> basicConfig(style='%', format="%(name)s -> %(levelname)s: %(message)s") > + ? ?>>> basicConfig(style='{', format="{name} -> {levelname} {message}") > + ? ?>>> basicConfig(style='$', format="$name -> $levelname: $message") It may be worth noting here that: 1. the "style" parameter also exists for logging.Formatter objects 2. it only applies to the output formatting for output, individual logging calls are still constrained to using %-formatting by backwards compatibility issues (Especially point 2 - I briefly forgot that distinction myself, and I helped review this feature when Vinay added it) Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From marks at dcs.gla.ac.uk Thu Feb 10 14:37:36 2011 From: marks at dcs.gla.ac.uk (Mark Shannon) Date: Thu, 10 Feb 2011 13:37:36 +0000 Subject: [Python-Dev] API bloat In-Reply-To: References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> Message-ID: <4D53EA20.80403@dcs.gla.ac.uk> Nick Coghlan wrote: > On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon wrote: >> Doing a search for the regex: "PyAPI_FUNC\([^)]*\) *Py" in .h files, >> which should match API functions (functions starting _Py are excluded) gives >> the following result: >> >> Version matches >> 3.0 717 >> 3.1.3 728 >> 3.2b2 743 >> >> It would appear the API bloat is real, >> not just an artefact of updated docs. > > Since it doesn't account for #ifdef, a naive count like that isn't a > valid basis for comparison. > OK. How about this: egrep -ho '#.*PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h finds no matches. egrep -ho 'PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h | sort -u This finds all matches and removes duplicates, so anything defined multiple time in branches of #ifdef blocks, will only be counted once. Version matches 3.0 714 3.1.3 725 3.2b2 739 So given, the revised numbers; The "what's new for 3.2" API section: http://docs.python.org/dev/py3k/whatsnew/3.2.html#build-and-c-api-changes lists 6 new functions, yet 14 have been added between 3.1.3 and 3.2b2. > I would hazard a guess that a substantial amount of the additional > numbers there are going to be from new alternative definitions of > Py_hash_t and some of the Py_UNICODE macros. Unless there is a PyAPI_FUNC involved, these won't match the regex. > > Cheers, > Nick. > From mal at egenix.com Thu Feb 10 14:51:59 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 10 Feb 2011 14:51:59 +0100 Subject: [Python-Dev] API bloat In-Reply-To: <4D53EA20.80403@dcs.gla.ac.uk> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> Message-ID: <4D53ED7F.1050300@egenix.com> Mark Shannon wrote: > Nick Coghlan wrote: >> On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon >> wrote: >>> Doing a search for the regex: "PyAPI_FUNC\([^)]*\) *Py" in .h files, >>> which should match API functions (functions starting _Py are >>> excluded) gives >>> the following result: >>> >>> Version matches >>> 3.0 717 >>> 3.1.3 728 >>> 3.2b2 743 >>> >>> It would appear the API bloat is real, >>> not just an artefact of updated docs. >> >> Since it doesn't account for #ifdef, a naive count like that isn't a >> valid basis for comparison. >> > OK. How about this: > > egrep -ho '#.*PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h > finds no matches. > > egrep -ho 'PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h | sort -u > > This finds all matches and removes duplicates, so anything defined > multiple time in branches of #ifdef blocks, will only be counted once. > > Version matches > 3.0 714 > 3.1.3 725 > 3.2b2 739 Given these numbers, I don't think the subject line really captures the problem accurately enough ... a 2% increase in number of API function per release can hardly be called API bloat :-) > So given, the revised numbers; > > The "what's new for 3.2" API section: > http://docs.python.org/dev/py3k/whatsnew/3.2.html#build-and-c-api-changes > lists 6 new functions, yet 14 have been added between 3.1.3 and 3.2b2. Could you identify the ones that are not yet documented ? That would be useful. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 10 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From ncoghlan at gmail.com Thu Feb 10 15:09:11 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 11 Feb 2011 00:09:11 +1000 Subject: [Python-Dev] API bloat In-Reply-To: <4D53ED7F.1050300@egenix.com> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com> Message-ID: On Thu, Feb 10, 2011 at 11:51 PM, M.-A. Lemburg wrote: >> The "what's new for 3.2" API section: >> http://docs.python.org/dev/py3k/whatsnew/3.2.html#build-and-c-api-changes >> lists 6 new functions, yet 14 have been added between 3.1.3 and 3.2b2. > > Could you identify the ones that are not yet documented ? >From Misc/NEWS: PyUnicode_TransformDecimalToASCII PyErr_SyntaxLocationEx PyArg_ValidateKeywordArguments PyFrame_GetLineNumber PyCode_NewEmpty I would guess that a lot of the other ones that aren't explicitly documented in NEWS or What's New are the assorted utilities Victor added in order to properly support non-ASCII entries in sys.path, as well as all the additional APIs to handle both bytes and unicode interfaces to the external environment. In scanning NEWS, I also noticed that there were quite a few ancient APIs that were finally killed off in 3.2, so the number of new functions is likely to actually exceed the 14 picked up by Mark's measurements. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From marks at dcs.gla.ac.uk Thu Feb 10 15:26:26 2011 From: marks at dcs.gla.ac.uk (Mark Shannon) Date: Thu, 10 Feb 2011 14:26:26 +0000 Subject: [Python-Dev] API bloat In-Reply-To: <4D53ED7F.1050300@egenix.com> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com> Message-ID: <4D53F592.2080401@dcs.gla.ac.uk> M.-A. Lemburg wrote: > Mark Shannon wrote: >> Nick Coghlan wrote: >>> On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon >>> wrote: >>>> Doing a search for the regex: "PyAPI_FUNC\([^)]*\) *Py" in .h files, >>>> which should match API functions (functions starting _Py are >>>> excluded) gives >>>> the following result: >>>> >>>> Version matches >>>> 3.0 717 >>>> 3.1.3 728 >>>> 3.2b2 743 >>>> >>>> It would appear the API bloat is real, >>>> not just an artefact of updated docs. >>> Since it doesn't account for #ifdef, a naive count like that isn't a >>> valid basis for comparison. >>> >> OK. How about this: >> >> egrep -ho '#.*PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h >> finds no matches. >> >> egrep -ho 'PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h | sort -u >> >> This finds all matches and removes duplicates, so anything defined >> multiple time in branches of #ifdef blocks, will only be counted once. >> >> Version matches >> 3.0 714 >> 3.1.3 725 >> 3.2b2 739 > > Given these numbers, I don't think the subject line really > captures the problem accurately enough ... a 2% increase > in number of API function per release can hardly be called > API bloat :-) > >> So given, the revised numbers; >> >> The "what's new for 3.2" API section: >> http://docs.python.org/dev/py3k/whatsnew/3.2.html#build-and-c-api-changes >> lists 6 new functions, yet 14 have been added between 3.1.3 and 3.2b2. > > Could you identify the ones that are not yet documented ? > > That would be useful. Here's the details: The following API functions were removed from 3.1.3: PyAST_Compile PyCObject_AsVoidPtr PyCObject_FromVoidPtr PyCObject_FromVoidPtrAndDesc PyCObject_GetDesc PyCObject_Import PyCObject_SetVoidPtr PyCode_CheckLineNumber Py_CompileStringFlags PyEval_CallObject PyOS_ascii_atof PyOS_ascii_formatd PyOS_ascii_strtod PyThread_exit_prog PyThread__PyThread_exit_prog PyThread__PyThread_exit_thread PyUnicode_SetDefaultEncoding And the following were added to 3.2, of which only 2 are documented: PyArg_ValidateKeywordArguments PyAST_CompileEx Py_CompileString Py_CompileStringExFlags PyErr_NewExceptionWithDoc (documented) PyErr_SyntaxLocationEx PyErr_WarnFormat PyFrame_GetLineNumber PyImport_ExecCodeModuleWithPathnames PyImport_GetMagicTag PyLong_AsLongLongAndOverflow (documented) PyModule_GetFilenameObject Py_SetPath PyStructSequence_GetItem PyStructSequence_NewType PyStructSequence_SetItem PySys_AddWarnOptionUnicode PySys_AddXOption PySys_FormatStderr PySys_FormatStdout PySys_GetXOptions PyThread_acquire_lock_timed PyType_FromSpec PyUnicode_AsUnicodeCopy PyUnicode_AsWideCharString PyUnicode_EncodeFSDefault PyUnicode_FSDecoder Py_UNICODE_strcat Py_UNICODE_strncmp Py_UNICODE_strrchr PyUnicode_TransformDecimalToASCII For added confusion PySys_SetArgvEx is documented as new in 3.2, but exists in 3.1.3 That should keep someone busy ;) Note that this only include functions. The API also includes a number of macros such as Py_False and Py_RETURN_FALSE, types , and data like PyBool_Type. I've not tried to analyse any of these. Mark. > > Thanks, From mal at egenix.com Thu Feb 10 16:19:56 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 10 Feb 2011 16:19:56 +0100 Subject: [Python-Dev] API bloat In-Reply-To: <4D53F592.2080401@dcs.gla.ac.uk> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk> Message-ID: <4D54021C.9000304@egenix.com> Mark Shannon wrote: > M.-A. Lemburg wrote: >> Mark Shannon wrote: >>> Nick Coghlan wrote: >>>> On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon >>>> wrote: >>>>> Doing a search for the regex: "PyAPI_FUNC\([^)]*\) *Py" in .h files, >>>>> which should match API functions (functions starting _Py are >>>>> excluded) gives >>>>> the following result: >>>>> >>>>> Version matches >>>>> 3.0 717 >>>>> 3.1.3 728 >>>>> 3.2b2 743 >>>>> >>>>> It would appear the API bloat is real, >>>>> not just an artefact of updated docs. >>>> Since it doesn't account for #ifdef, a naive count like that isn't a >>>> valid basis for comparison. >>>> >>> OK. How about this: >>> >>> egrep -ho '#.*PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h >>> finds no matches. >>> >>> egrep -ho 'PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h | sort -u >>> >>> This finds all matches and removes duplicates, so anything defined >>> multiple time in branches of #ifdef blocks, will only be counted once. >>> >>> Version matches >>> 3.0 714 >>> 3.1.3 725 >>> 3.2b2 739 >> >> Given these numbers, I don't think the subject line really >> captures the problem accurately enough ... a 2% increase >> in number of API function per release can hardly be called >> API bloat :-) >> >>> So given, the revised numbers; >>> >>> The "what's new for 3.2" API section: >>> http://docs.python.org/dev/py3k/whatsnew/3.2.html#build-and-c-api-changes >>> >>> lists 6 new functions, yet 14 have been added between 3.1.3 and 3.2b2. >> >> Could you identify the ones that are not yet documented ? >> >> That would be useful. > > Here's the details: > > The following API functions were removed from 3.1.3: > > PyAST_Compile > PyCObject_AsVoidPtr > PyCObject_FromVoidPtr > PyCObject_FromVoidPtrAndDesc > PyCObject_GetDesc > PyCObject_Import > PyCObject_SetVoidPtr > PyCode_CheckLineNumber > Py_CompileStringFlags > PyEval_CallObject > PyOS_ascii_atof > PyOS_ascii_formatd > PyOS_ascii_strtod > PyThread_exit_prog > PyThread__PyThread_exit_prog > PyThread__PyThread_exit_thread > PyUnicode_SetDefaultEncoding > > And the following were added to 3.2, > of which only 2 are documented: > > PyArg_ValidateKeywordArguments > PyAST_CompileEx > Py_CompileString > Py_CompileStringExFlags > PyErr_NewExceptionWithDoc (documented) > PyErr_SyntaxLocationEx > PyErr_WarnFormat > PyFrame_GetLineNumber > PyImport_ExecCodeModuleWithPathnames > PyImport_GetMagicTag > PyLong_AsLongLongAndOverflow (documented) > PyModule_GetFilenameObject > Py_SetPath > PyStructSequence_GetItem > PyStructSequence_NewType > PyStructSequence_SetItem > PySys_AddWarnOptionUnicode > PySys_AddXOption > PySys_FormatStderr > PySys_FormatStdout > PySys_GetXOptions > PyThread_acquire_lock_timed > PyType_FromSpec > PyUnicode_AsUnicodeCopy > PyUnicode_AsWideCharString > PyUnicode_EncodeFSDefault > PyUnicode_FSDecoder > Py_UNICODE_strcat > Py_UNICODE_strncmp > Py_UNICODE_strrchr > PyUnicode_TransformDecimalToASCII > > For added confusion PySys_SetArgvEx is documented as > new in 3.2, but exists in 3.1.3 > > That should keep someone busy ;) > > Note that this only include functions. > The API also includes a number of macros such as > Py_False and Py_RETURN_FALSE, types , > and data like PyBool_Type. > > I've not tried to analyse any of these. Thanks. I opened http://bugs.python.org/issue11173 for this. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 10 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From victor.stinner at haypocalc.com Thu Feb 10 16:49:51 2011 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Thu, 10 Feb 2011 16:49:51 +0100 Subject: [Python-Dev] API bloat In-Reply-To: <4D54021C.9000304@egenix.com> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com> Message-ID: <1297352991.5203.3.camel@marge> Le jeudi 10 f?vrier 2011 ? 16:19 +0100, M.-A. Lemburg a ?crit : > > And the following were added to 3.2, > > of which only 2 are documented: > > > > PyArg_ValidateKeywordArguments > > PyAST_CompileEx > > Py_CompileString > > Py_CompileStringExFlags > > PyErr_NewExceptionWithDoc (documented) > > PyErr_SyntaxLocationEx > > PyErr_WarnFormat > > PyFrame_GetLineNumber > > PyImport_ExecCodeModuleWithPathnames > > PyImport_GetMagicTag > > PyLong_AsLongLongAndOverflow (documented) > > PyModule_GetFilenameObject > > Py_SetPath > > PyStructSequence_GetItem > > PyStructSequence_NewType > > PyStructSequence_SetItem > > PySys_AddWarnOptionUnicode > > PySys_AddXOption > > PySys_FormatStderr > > PySys_FormatStdout > > PySys_GetXOptions > > PyThread_acquire_lock_timed > > PyType_FromSpec > > PyUnicode_AsUnicodeCopy > > PyUnicode_AsWideCharString > > PyUnicode_EncodeFSDefault > > PyUnicode_FSDecoder > > Py_UNICODE_strcat > > Py_UNICODE_strncmp > > Py_UNICODE_strrchr > > PyUnicode_TransformDecimalToASCII PyErr_WarnFormat, PyImport_ExecCodeModuleWithPathnames, PyModule_GetFilenameObject, PySys_AddWarnOptionUnicode, PySys_FormatStderr, PySys_FormatStdout, PyUnicode_AsUnicodeCopy, PyUnicode_AsWideCharString, PyUnicode_EncodeFSDefault and PyUnicode_FSDecoder are documented (I wrote most of these functions). I added references in the issue #11173. So there are a little bit less than 29/31 of new undocumented functions. But yes, most Py_UNICODE_* functions are not documented: see issue #10435 (which has a patch). victor From marks at dcs.gla.ac.uk Thu Feb 10 17:21:28 2011 From: marks at dcs.gla.ac.uk (Mark Shannon) Date: Thu, 10 Feb 2011 16:21:28 +0000 Subject: [Python-Dev] API bloat In-Reply-To: <4D54021C.9000304@egenix.com> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com> Message-ID: <4D541088.8090301@dcs.gla.ac.uk> >> And the following were added to 3.2, >> of which only 2 are documented: >> >> PyArg_ValidateKeywordArguments >> PyAST_CompileEx >> Py_CompileString >> Py_CompileStringExFlags >> PyErr_NewExceptionWithDoc (documented) >> PyErr_SyntaxLocationEx >> PyErr_WarnFormat >> PyFrame_GetLineNumber >> PyImport_ExecCodeModuleWithPathnames >> PyImport_GetMagicTag >> PyLong_AsLongLongAndOverflow (documented) >> PyModule_GetFilenameObject >> Py_SetPath >> PyStructSequence_GetItem >> PyStructSequence_NewType >> PyStructSequence_SetItem >> PySys_AddWarnOptionUnicode >> PySys_AddXOption >> PySys_FormatStderr >> PySys_FormatStdout >> PySys_GetXOptions >> PyThread_acquire_lock_timed >> PyType_FromSpec >> PyUnicode_AsUnicodeCopy >> PyUnicode_AsWideCharString >> PyUnicode_EncodeFSDefault >> PyUnicode_FSDecoder >> Py_UNICODE_strcat >> Py_UNICODE_strncmp >> Py_UNICODE_strrchr >> PyUnicode_TransformDecimalToASCII >> >> For added confusion PySys_SetArgvEx is documented as >> new in 3.2, but exists in 3.1.3 >> >> That should keep someone busy ;) >> >> Note that this only include functions. >> The API also includes a number of macros such as >> Py_False and Py_RETURN_FALSE, types , >> and data like PyBool_Type. >> >> I've not tried to analyse any of these. > > Thanks. > > I opened http://bugs.python.org/issue11173 for this. > Please, don't just document all these. Don't add them to the API, unless they are really needed. For example, PySys_FormatStdout and PySys_FormatStderr get exactly zero hits between them on google code search. PySys_FormatStdout doesn't even get used in the 3.2 source. I'm not picking on PySys_FormatStderr, or its author here, I'm just using it as an example, it seems fairly typical. According to http://bugs.python.org/issue9599 "I only need PySys_FormatStderr(), but I added also PySys_FormatStdout() just to be consistent with PySys_Write*() and because it only costs a few line of code." This seems a little cavalier to me. That little PyAPI_FUNC() macro carries a lot of obligation in terms of documentation, future support, and the cost to other implementations. Cheers, Mark. From marks at dcs.gla.ac.uk Thu Feb 10 17:30:31 2011 From: marks at dcs.gla.ac.uk (Mark Shannon) Date: Thu, 10 Feb 2011 16:30:31 +0000 Subject: [Python-Dev] API bloat In-Reply-To: <1297352991.5203.3.camel@marge> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com> <1297352991.5203.3.camel@marge> Message-ID: <4D5412A7.1030309@dcs.gla.ac.uk> Victor Stinner wrote: > Le jeudi 10 f?vrier 2011 ? 16:19 +0100, M.-A. Lemburg a ?crit : >>> And the following were added to 3.2, >>> of which only 2 are documented: >>> >>> PyArg_ValidateKeywordArguments >>> PyAST_CompileEx >>> Py_CompileString >>> Py_CompileStringExFlags >>> PyErr_NewExceptionWithDoc (documented) >>> PyErr_SyntaxLocationEx >>> PyErr_WarnFormat >>> PyFrame_GetLineNumber >>> PyImport_ExecCodeModuleWithPathnames >>> PyImport_GetMagicTag >>> PyLong_AsLongLongAndOverflow (documented) >>> PyModule_GetFilenameObject >>> Py_SetPath >>> PyStructSequence_GetItem >>> PyStructSequence_NewType >>> PyStructSequence_SetItem >>> PySys_AddWarnOptionUnicode >>> PySys_AddXOption >>> PySys_FormatStderr >>> PySys_FormatStdout >>> PySys_GetXOptions >>> PyThread_acquire_lock_timed >>> PyType_FromSpec >>> PyUnicode_AsUnicodeCopy >>> PyUnicode_AsWideCharString >>> PyUnicode_EncodeFSDefault >>> PyUnicode_FSDecoder >>> Py_UNICODE_strcat >>> Py_UNICODE_strncmp >>> Py_UNICODE_strrchr >>> PyUnicode_TransformDecimalToASCII > > PyErr_WarnFormat, PyImport_ExecCodeModuleWithPathnames, > PyModule_GetFilenameObject, PySys_AddWarnOptionUnicode, > PySys_FormatStderr, PySys_FormatStdout, PyUnicode_AsUnicodeCopy, > PyUnicode_AsWideCharString, PyUnicode_EncodeFSDefault and > PyUnicode_FSDecoder are documented (I wrote most of these functions). I > added references in the issue #11173. I meant documented in the "What's new in 3.2" section. Gathering all these in one place might make the extent of the changes clearer for all. > > So there are a little bit less than 29/31 of new undocumented functions. > > But yes, most Py_UNICODE_* functions are not documented: see issue > #10435 (which has a patch). > > victor > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/marks%40dcs.gla.ac.uk From solipsis at pitrou.net Thu Feb 10 17:36:47 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 10 Feb 2011 17:36:47 +0100 Subject: [Python-Dev] API bloat References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com> <4D541088.8090301@dcs.gla.ac.uk> Message-ID: <20110210173647.31b0a4ac@pitrou.net> > > Please, don't just document all these. > Don't add them to the API, unless they are really needed. We only add functions when they are actually needed (by us, usually). > I'm not picking on PySys_FormatStderr, or its author here, > I'm just using it as an example, it seems fairly typical. You've found an exception. Antoine. From marks at dcs.gla.ac.uk Thu Feb 10 18:25:54 2011 From: marks at dcs.gla.ac.uk (Mark Shannon) Date: Thu, 10 Feb 2011 17:25:54 +0000 Subject: [Python-Dev] API bloat In-Reply-To: <20110210173647.31b0a4ac@pitrou.net> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com> <4D541088.8090301@dcs.gla.ac.uk> <20110210173647.31b0a4ac@pitrou.net> Message-ID: <4D541FA2.4090801@dcs.gla.ac.uk> Antoine Pitrou wrote: >> Please, don't just document all these. >> Don't add them to the API, unless they are really needed. > > We only add functions when they are actually needed (by us, usually). If only you (I presume you mean the CPython devs) need them, why put them in the API. That underscore prefix saves a lot of trouble in the long run ;) > >> I'm not picking on PySys_FormatStderr, or its author here, >> I'm just using it as an example, it seems fairly typical. > > You've found an exception. What about this one then, PyFrame_GetLineNumber was added because people were using PyCode_Addr2Line to get the current line number. The API will contain then both PyFrame_GetLineNumber *and* PyCode_Addr2Line. The API then has even more redundancy. PyObject_GetAttrString(frame, "f_lineno") should do the job. Mark. > > Antoine. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/marks%40dcs.gla.ac.uk > From g.brandl at gmx.net Thu Feb 10 19:07:38 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Thu, 10 Feb 2011 19:07:38 +0100 Subject: [Python-Dev] API bloat In-Reply-To: <4D53F592.2080401@dcs.gla.ac.uk> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk> Message-ID: Am 10.02.2011 15:26, schrieb Mark Shannon: > M.-A. Lemburg wrote: >> Mark Shannon wrote: >>> Nick Coghlan wrote: >>>> On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon >>>> wrote: >>>>> Doing a search for the regex: "PyAPI_FUNC\([^)]*\) *Py" in .h files, >>>>> which should match API functions (functions starting _Py are >>>>> excluded) gives >>>>> the following result: >>>>> >>>>> Version matches >>>>> 3.0 717 >>>>> 3.1.3 728 >>>>> 3.2b2 743 >>>>> >>>>> It would appear the API bloat is real, >>>>> not just an artefact of updated docs. >>>> Since it doesn't account for #ifdef, a naive count like that isn't a >>>> valid basis for comparison. >>>> >>> OK. How about this: >>> >>> egrep -ho '#.*PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h >>> finds no matches. >>> >>> egrep -ho 'PyAPI_FUNC\([^)]*\)( |\n)*Py\w+' Include/*.h | sort -u >>> >>> This finds all matches and removes duplicates, so anything defined >>> multiple time in branches of #ifdef blocks, will only be counted once. >>> >>> Version matches >>> 3.0 714 >>> 3.1.3 725 >>> 3.2b2 739 >> >> Given these numbers, I don't think the subject line really >> captures the problem accurately enough ... a 2% increase >> in number of API function per release can hardly be called >> API bloat :-) >> >>> So given, the revised numbers; >>> >>> The "what's new for 3.2" API section: >>> http://docs.python.org/dev/py3k/whatsnew/3.2.html#build-and-c-api-changes >>> lists 6 new functions, yet 14 have been added between 3.1.3 and 3.2b2. >> >> Could you identify the ones that are not yet documented ? >> >> That would be useful. > > Here's the details: > > The following API functions were removed from 3.1.3: > > PyAST_Compile This is not correct, for example: this function is still present as a #define (and there is also a stub implementation so that extensions compiled against earlier versions can import the symbol). Georg From brett at python.org Thu Feb 10 19:27:32 2011 From: brett at python.org (Brett Cannon) Date: Thu, 10 Feb 2011 10:27:32 -0800 Subject: [Python-Dev] devguide: Fix a silly statement. In-Reply-To: References: Message-ID: On Wed, Feb 9, 2011 at 23:10, Georg Brandl wrote: > Am 09.02.2011 23:58, schrieb brett.cannon: >> brett.cannon pushed 7101df1bd817 to devguide: >> >> http://hg.python.org/devguide/rev/7101df1bd817 >> changeset: ? 291:7101df1bd817 >> branch: ? ? ?hg_transition >> tag: ? ? ? ? tip >> user: ? ? ? ?Brett Cannon >> date: ? ? ? ?Wed Feb 09 14:58:17 2011 -0800 >> summary: >> ? Fix a silly statement. >> >> files: >> ? setup.rst >> >> diff --git a/setup.rst b/setup.rst >> --- a/setup.rst >> +++ b/setup.rst >> @@ -34,8 +34,7 @@ >> ?:abbr:`VCS`. It also means you will have better tool >> ?support through the VCS as it will provide a diff tool, etc. >> >> -To get a read-only checkout of CPython's source, you need a working copy the >> -source code. To get a read-only checkout of >> +To get a read-only checkout of >> ?the :ref:`in-development ` branch of Python, run:: >> >> ? ? ?hg clone http://hg.python.org/cpython > > This statement is still somewhat silly, as a) you get a clone, not a checkout > and b) it is not read only in any way: you can commit just fine. ?The only > difference will be the entry in .hg/hgrc pointing the default repo to something > you can't push to. > > Skimming through, the whole section "Checking out the code" is still way too > SVN-point of viewy (e.g. you always get all branches anyway). I'll take another pass, but do realize this needs to be something that can easily be understood by someone who has never used hg before, so I can't get too technically accurate while ignoring a possible base ignorance of hg and DVCSs as a whole. From g.brandl at gmx.net Thu Feb 10 21:08:30 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Thu, 10 Feb 2011 21:08:30 +0100 Subject: [Python-Dev] devguide: Fix a silly statement. In-Reply-To: References: Message-ID: Am 10.02.2011 19:27, schrieb Brett Cannon: > On Wed, Feb 9, 2011 at 23:10, Georg Brandl wrote: >> Am 09.02.2011 23:58, schrieb brett.cannon: >>> brett.cannon pushed 7101df1bd817 to devguide: >>> >>> http://hg.python.org/devguide/rev/7101df1bd817 >>> changeset: 291:7101df1bd817 >>> branch: hg_transition >>> tag: tip >>> user: Brett Cannon >>> date: Wed Feb 09 14:58:17 2011 -0800 >>> summary: >>> Fix a silly statement. >>> >>> files: >>> setup.rst >>> >>> diff --git a/setup.rst b/setup.rst >>> --- a/setup.rst >>> +++ b/setup.rst >>> @@ -34,8 +34,7 @@ >>> :abbr:`VCS`. It also means you will have better tool >>> support through the VCS as it will provide a diff tool, etc. >>> >>> -To get a read-only checkout of CPython's source, you need a working copy the >>> -source code. To get a read-only checkout of >>> +To get a read-only checkout of >>> the :ref:`in-development ` branch of Python, run:: >>> >>> hg clone http://hg.python.org/cpython >> >> This statement is still somewhat silly, as a) you get a clone, not a checkout >> and b) it is not read only in any way: you can commit just fine. The only >> difference will be the entry in .hg/hgrc pointing the default repo to something >> you can't push to. >> >> Skimming through, the whole section "Checking out the code" is still way too >> SVN-point of viewy (e.g. you always get all branches anyway). > > I'll take another pass, but do realize this needs to be something that > can easily be understood by someone who has never used hg before, so I > can't get too technically accurate while ignoring a possible base > ignorance of hg and DVCSs as a whole. Well, it's no good to keep using CVCS terms and mislead users. That the "checkout" is not a checkout but a full repository is about the most important fact about a hg (or any DVCS) clone. Georg From sandro.tosi at gmail.com Thu Feb 10 21:01:35 2011 From: sandro.tosi at gmail.com (Sandro Tosi) Date: Thu, 10 Feb 2011 21:01:35 +0100 Subject: [Python-Dev] [Python-checkins] devguide: Move to using mq for basic usage. In-Reply-To: References: Message-ID: Hi, On Wed, Feb 9, 2011 at 23:19, brett.cannon wrote: > +project's preference. ?We present here a very simple solution based on mq_ > +(Mercurial Queue) non-core developers. for non-core devs (ok, this is not the last patch applied to the file, but it's still there after the next changes). > +This will update the patch to contain all of the changes you have made up to > +this point. If you have any you have added or removed, use ``hg add`` or ``hg > +remove``, respectively, before running ``hg qrefresh``. If you have any > ?This will check and/or fix various common things people forget to do for > -patches, such as adding any new files needing for the patch to work. > +patches, such as adding any new files needing for the patch to work (do not (do note Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi From steveth45 at gmail.com Thu Feb 10 21:30:02 2011 From: steveth45 at gmail.com (Steve Goss) Date: Thu, 10 Feb 2011 12:30:02 -0800 Subject: [Python-Dev] Proposal / Questions about OrderedDict literals and/or faster C implementation Message-ID: I have a proposal for a literal syntax for OrderedDicts which is just replacing the braces with square brackets: ['a': 1,'b': 2] == OrderedDict([('a', 1),('b', 2)]) OrderedDict literals would follow: [x : x for x in foo()] == OrderedDict([(x,x) for x in foo()]) The rationale for the syntax is that it follows the set / list / dict precedent of curly braces for unordered collections, square brackets for ordered collections, and otherwise aping the normal dict syntax. OrderedDict is arguable one of the best recent additions to the Python standard library. Looking at the py3k codebase, it seems like adding OrderedDicts as a native C implementation at the same time as introducing a literal syntax with all the additions to the grammar and ast makes sense. A native implementation would make the memory usage closer to normal dicts (plus two pointers per element) but be potentially faster for many operations than even regular dictionaries and certainly much, much faster than the current Python-only implementation of OrderedDict. I've started working on this in my free time, but I'm not a seasoned CPython hacker. Any feedback or pointers would be helpful. Originally, I was planning on creating a patch first before suggesting this to the mailing list, but given the scope of the feature and the number of concerns I figure I might as well test the waters first. Even if the idea of a literal syntax is dismissed, I think a C implementation of OrderedDict would be a great addition and I'd love to help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From merwok at netwok.org Thu Feb 10 21:47:33 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Thu, 10 Feb 2011 21:47:33 +0100 Subject: [Python-Dev] Proposal / Questions about OrderedDict literals and/or faster C implementation In-Reply-To: References: Message-ID: <4D544EE5.1060504@netwok.org> Hello, Thanks for wanting to contribute and welcome to python-dev :) Ideas are usually discussed first on python-ideas to assess usefulness, get the pulse of the community, beat the API into shape and such things before coming up to python-dev. (A number of core devs are on both lists.) You may want to search the mail archive for all the previous threads about adding a C version and literal notation for ordered dicts. Regards From victor.stinner at haypocalc.com Thu Feb 10 22:57:39 2011 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Thu, 10 Feb 2011 22:57:39 +0100 Subject: [Python-Dev] API bloat In-Reply-To: <4D541FA2.4090801@dcs.gla.ac.uk> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com> <4D541088.8090301@dcs.gla.ac.uk> <20110210173647.31b0a4ac@pitrou.net> <4D541FA2.4090801@dcs.gla.ac.uk> Message-ID: <1297375059.9928.0.camel@marge> Le jeudi 10 f?vrier 2011 ? 17:25 +0000, Mark Shannon a ?crit : > What about this one then, > > PyFrame_GetLineNumber was added because people were using > PyCode_Addr2Line to get the current line number. > > The API will contain then both > PyFrame_GetLineNumber *and* PyCode_Addr2Line. > The API then has even more redundancy. > > PyObject_GetAttrString(frame, "f_lineno") should do the job. Not exactly: int PyFrame_GetLineNumber(PyFrameObject *f) { if (f->f_trace) return f->f_lineno; else return PyCode_Addr2Line(f->f_code, f->f_lasti); } Victor From ncoghlan at gmail.com Fri Feb 11 00:21:22 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 11 Feb 2011 09:21:22 +1000 Subject: [Python-Dev] API bloat In-Reply-To: <4D541FA2.4090801@dcs.gla.ac.uk> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com> <4D541088.8090301@dcs.gla.ac.uk> <20110210173647.31b0a4ac@pitrou.net> <4D541FA2.4090801@dcs.gla.ac.uk> Message-ID: On Fri, Feb 11, 2011 at 3:25 AM, Mark Shannon wrote: > Antoine Pitrou wrote: >>> >>> Please, don't just document all these. >>> Don't add them to the API, unless they are really needed. >> >> We only add functions when they are actually needed (by us, usually). > > If only you (I presume you mean the CPython devs) need them, > why put them in the API. > That underscore prefix saves a lot of trouble in the long run ;) Keep in mind that you're asking us to change our audience here. When we modify the C API, we have precisely *three* audiences in mind: 1. CPython developers 2. authors of CPython extensions 3. developers embedding a CPython interpreter (or interpreters) into their application So if we find something that makes life easier for us in group 1, our natural inclination is to make it available to the people in groups 2 and 3 as well, rather than selfishly reserving it for ourselves. We will also take aesthetics and obvious symmetries into account when providing convenience functions (as in the case of PySys_FormatStdout). It's only when we consider something to be an ugly hack, or have some other reason to think we may want to change it in the future, that we opt to make it a private implementation detail. The audience consisting of "authors of other implementations trying to mimic the CPython C API" has never even been on the radar. That's quite a significant philosophical shift, so coming in and asking us to apply it retroactively to a release in its RC phase comes across as being *very* presumptuous. Now that the issue has been brought up, it can certainly be taken into consideration for 3.3. The idea of defining a Py_PORTABLE_API that is even more restrictive than PEP 384 (e.g. eliminating lots of old cruft that is a legacy of CPython's long history of development when it was the *only* viable Python implementation) may also be worth exploring. But no, at this late stage nothing significant is going to be done in the context of 3.2, except perhaps describing the C API changes in more detail in the What's New document (whether or not that happens is up to Raymond - the C API is of very little interest to most Python users, who will either use pre-existing C extensions, or else use something like ctypes, Cython, Pyrex, Boost or SWIG to deal with the details of the C/Python boundary). Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From ncoghlan at gmail.com Fri Feb 11 00:25:19 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 11 Feb 2011 09:25:19 +1000 Subject: [Python-Dev] [Python-checkins] r88387 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <20110210184236.F1834EEB4E@mail.python.org> References: <20110210184236.F1834EEB4E@mail.python.org> Message-ID: On Fri, Feb 11, 2011 at 4:42 AM, giampaolo.rodola wrote: > Author: giampaolo.rodola > Date: Thu Feb 10 19:42:36 2011 > New Revision: 88387 > > Log: > get rid of asyncore.dispatcher's debug attribute, which is no longer used (assuming it ever was). Reviewer? NEWS entry? RM approval? Tracker issue? Removing a public attribute seems like an odd change to be making at this stage of a release. What if there is third party code that uses that attribute to enable additional debugging info in asyncore? Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From catch-all at masklinn.net Fri Feb 11 10:06:57 2011 From: catch-all at masklinn.net (Xavier Morel) Date: Fri, 11 Feb 2011 10:06:57 +0100 Subject: [Python-Dev] Proposal / Questions about OrderedDict literals and/or faster C implementation In-Reply-To: <4D544EE5.1060504@netwok.org> References: <4D544EE5.1060504@netwok.org> Message-ID: On 2011-02-10, at 21:47 , ?ric Araujo wrote: > Ideas are usually discussed first on python-ideas to assess usefulness, > get the pulse of the community, beat the API into shape and such things > before coming up to python-dev. (A number of core devs are on both lists.) > > You may want to search the mail archive for all the previous threads > about adding a C version and literal notation for ordered dicts. Indeed, there's been a discussion on this very subject not three weeks ago: http://mail.python.org/pipermail/python-ideas/2011-January/009037.html I'm guessing this request is going to get more common for some time, as people are getting aware Ruby switched its Hash implementation to an ordered dict in 1.9 (well they didn't exactly switch anything around, they added back and next pointers to their dict cells) From marks at dcs.gla.ac.uk Fri Feb 11 10:29:50 2011 From: marks at dcs.gla.ac.uk (Mark Shannon) Date: Fri, 11 Feb 2011 09:29:50 +0000 Subject: [Python-Dev] API bloat In-Reply-To: References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com> <4D541088.8090301@dcs.gla.ac.uk> <20110210173647.31b0a4ac@pitrou.net> <4D541FA2.4090801@dcs.gla.ac.uk> Message-ID: <4D55018E.3030608@dcs.gla.ac.uk> Nick Coghlan wrote: > On Fri, Feb 11, 2011 at 3:25 AM, Mark Shannon wrote: >> Antoine Pitrou wrote: >>>> Please, don't just document all these. >>>> Don't add them to the API, unless they are really needed. >>> We only add functions when they are actually needed (by us, usually). >> If only you (I presume you mean the CPython devs) need them, >> why put them in the API. >> That underscore prefix saves a lot of trouble in the long run ;) > > Keep in mind that you're asking us to change our audience here. When > we modify the C API, we have precisely *three* audiences in mind: > > 1. CPython developers > 2. authors of CPython extensions > 3. developers embedding a CPython interpreter (or interpreters) into > their application This makes me wonder who `owns' the API. Is the CPython developers, the Python community as a whole, the PSF? (Another one for Python-ideas) > > So if we find something that makes life easier for us in group 1, our > natural inclination is to make it available to the people in groups 2 > and 3 as well, rather than selfishly reserving it for ourselves. We > will also take aesthetics and obvious symmetries into account when > providing convenience functions (as in the case of > PySys_FormatStdout). It's only when we consider something to be an > ugly hack, or have some other reason to think we may want to change it > in the future, that we opt to make it a private implementation detail. > > The audience consisting of "authors of other implementations trying to > mimic the CPython C API" has never even been on the radar. That's > quite a significant philosophical shift, so coming in and asking us to > apply it retroactively to a release in its RC phase comes across as > being *very* presumptuous. Sorry to leave it the RC stage, I just didn't pick up the changes until now. Don't forget that `other implementations' include future versions of CPython. > > Now that the issue has been brought up, it can certainly be taken into > consideration for 3.3. The idea of defining a Py_PORTABLE_API that is > even more restrictive than PEP 384 (e.g. eliminating lots of old cruft > that is a legacy of CPython's long history of development when it was > the *only* viable Python implementation) may also be worth exploring. Absolutely. I intend to do just that. > But no, at this late stage nothing significant is going to be done in > the context of 3.2, except perhaps describing the C API changes in > more detail in the What's New document (whether or not that happens is > up to Raymond - the C API is of very little interest to most Python > users, who will either use pre-existing C extensions, or else use > something like ctypes, Cython, Pyrex, Boost or SWIG to deal with the > details of the C/Python boundary). I do realise that its rather late in the release process, so I'll leave it that. Thanks, Mark. > > Cheers, > Nick. > From ncoghlan at gmail.com Fri Feb 11 14:25:10 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 11 Feb 2011 23:25:10 +1000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <20110211130418.5D6F4EE9CE@mail.python.org> References: <20110211130418.5D6F4EE9CE@mail.python.org> Message-ID: On Fri, Feb 11, 2011 at 11:04 PM, giampaolo.rodola wrote: > Author: giampaolo.rodola > Date: Fri Feb 11 14:04:18 2011 > New Revision: 88395 > > Log: > asyncore: introduce a new 'closed' attribute to make sure that dispatcher gets closed only once. > In different occasions close() might be called more than once, causing problems with already disconnected sockets/dispatchers. Giampaolo, This checkin and the previous one are not appropriate for the release candidate phase of the 3.2 release. At the very least, they need to identify the second core dev that reviewed them, as well as a reference to the tracker issue where the RM approved them for inclusion. Regards, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From g.rodola at gmail.com Fri Feb 11 14:52:21 2011 From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=) Date: Fri, 11 Feb 2011 14:52:21 +0100 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: References: <20110211130418.5D6F4EE9CE@mail.python.org> Message-ID: I'm sorry, I'm going to revert those checkins. They are very minor changes which I'm sure don't break anything, but I understand your complain. --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ 2011/2/11 Nick Coghlan : > On Fri, Feb 11, 2011 at 11:04 PM, giampaolo.rodola > wrote: >> Author: giampaolo.rodola >> Date: Fri Feb 11 14:04:18 2011 >> New Revision: 88395 >> >> Log: >> asyncore: introduce a new 'closed' attribute to make sure that dispatcher gets closed only once. >> In different occasions close() might be called more than once, causing problems with already disconnected sockets/dispatchers. > > Giampaolo, > > This checkin and the previous one are not appropriate for the release > candidate phase of the 3.2 release. At the very least, they need to > identify the second core dev that reviewed them, as well as a > reference to the tracker issue where the RM approved them for > inclusion. > > Regards, > Nick. > > -- > Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia > From victor.stinner at haypocalc.com Fri Feb 11 15:28:01 2011 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Fri, 11 Feb 2011 15:28:01 +0100 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: References: <20110211130418.5D6F4EE9CE@mail.python.org> Message-ID: <1297434481.3175.6.camel@marge> Le vendredi 11 f?vrier 2011 ? 14:52 +0100, Giampaolo Rodol? a ?crit : > >> New Revision: 88395 > >> > >> Log: > >> asyncore: introduce a new 'closed' attribute to make sure that dispatcher gets closed only once. > >> In different occasions close() might be called more than once, causing problems with already disconnected sockets/dispatchers. > > (...) > I'm sorry, I'm going to revert those checkins. > They are very minor changes which I'm sure don't break anything, but I > understand your complain. dispatcher.closing is a public attribute: some programs my rely on it. I checked mine: it uses "connected", but not closing :-) I think that it will be fine for Python 3.3, but not for 3.2 (too late). And you should document your change, because it is the public API. Victor From guido at python.org Fri Feb 11 17:06:23 2011 From: guido at python.org (Guido van Rossum) Date: Fri, 11 Feb 2011 08:06:23 -0800 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <1297434481.3175.6.camel@marge> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> Message-ID: On Fri, Feb 11, 2011 at 6:28 AM, Victor Stinner wrote: > Le vendredi 11 f?vrier 2011 ? 14:52 +0100, Giampaolo Rodol? a ?crit : >> >> New Revision: 88395 >> >> >> >> Log: >> >> asyncore: introduce a new 'closed' attribute to make sure that dispatcher gets closed only once. >> >> In different occasions close() might be called more than once, causing problems with already disconnected sockets/dispatchers. >> > (...) >> I'm sorry, I'm going to revert those checkins. >> They are very minor changes which I'm sure don't break anything, but I >> understand your complain. > > dispatcher.closing is a public attribute: some programs my rely on it. I > checked mine: it uses "connected", but not closing :-) > > I think that it will be fine for Python 3.3, but not for 3.2 (too late). > And you should document your change, because it is the public API. And finally remember that asyncore is the most monkey-patched module in the world. :-) -- --Guido van Rossum (python.org/~guido) From status at bugs.python.org Fri Feb 11 18:07:06 2011 From: status at bugs.python.org (Python tracker) Date: Fri, 11 Feb 2011 18:07:06 +0100 (CET) Subject: [Python-Dev] Summary of Python tracker Issues Message-ID: <20110211170706.3CE971CC5D@psf.upfronthosting.co.za> ACTIVITY SUMMARY (2011-02-04 - 2011-02-11) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2627 (+42) closed 20348 (+34) total 22975 (+76) Open issues with patches: 1119 Issues opened (56) ================== #6378: Patch to make 'idle.bat' run idle.pyw using appropriate Python http://bugs.python.org/issue6378 reopened by srid #7074: Turtle module crashes python http://bugs.python.org/issue7074 reopened by terry.reedy #9920: test_cmath on atan fails on AIX http://bugs.python.org/issue9920 reopened by mark.dickinson #11120: threading.Thread.daemon Documentation Incomplete http://bugs.python.org/issue11120 opened by cardinalbiggles #11122: bdist_rpm fails http://bugs.python.org/issue11122 opened by purpleidea #11123: problem with packaged dependency extracter script, pdeps http://bugs.python.org/issue11123 opened by $$Coffeepot$$ #11126: Wave.py does not always write proper length in header http://bugs.python.org/issue11126 opened by jtidman #11127: sockets should not be pickleable http://bugs.python.org/issue11127 opened by pitrou #11128: decimal.py: to_integral() corner cases http://bugs.python.org/issue11128 opened by skrah #11131: decimal.py: plus/minus with ROUND_FLOOR http://bugs.python.org/issue11131 opened by skrah #11133: inspect.getattr_static code execution http://bugs.python.org/issue11133 opened by durban #11134: Add missing type slots http://bugs.python.org/issue11134 opened by loewis #11135: Redundant doc field in TypeSpec http://bugs.python.org/issue11135 opened by loewis #11140: threading.Lock().release() raises _thread.error, not RuntimeEr http://bugs.python.org/issue11140 opened by aaugustin #11142: xmlrpclib.ServerProxy with verbosity produces bad output http://bugs.python.org/issue11142 opened by Erez.Sh #11144: int(float) may return a long for no reason http://bugs.python.org/issue11144 opened by arigo #11145: '%o' % user-defined instance http://bugs.python.org/issue11145 opened by arigo #11147: _Py_ANNOTATE_MEMORY_ORDER has unused argument, effects code wh http://bugs.python.org/issue11147 opened by ideasman42 #11148: Crash and error message from Python VM http://bugs.python.org/issue11148 opened by pcdinh #11149: [PATCH] Configure should enable -fwrapv for clang http://bugs.python.org/issue11149 opened by cartman #11151: Arguments to various types not specified in types module http://bugs.python.org/issue11151 opened by noufal #11152: pb in zipfile module http://bugs.python.org/issue11152 opened by Emmanuel LAB #11153: urllib2 basic auth parser handle unquoted realm in WWW-Authent http://bugs.python.org/issue11153 opened by mmb #11155: multiprocessing.Queue's put() signature differs from docs http://bugs.python.org/issue11155 opened by Erik.Cederstrand #11158: Python VM deadlock http://bugs.python.org/issue11158 opened by pcdinh #11159: Sax parser crashes if given unicode file name http://bugs.python.org/issue11159 opened by ricli85 #11160: ZipFile.comment expects bytes http://bugs.python.org/issue11160 opened by xuanji #11161: futures.ProcessPoolExecutor hangs http://bugs.python.org/issue11161 opened by pclinch #11163: iter() documentation code doesn't work http://bugs.python.org/issue11163 opened by mgrazebrook #11164: xml shouldn't use _xmlplus http://bugs.python.org/issue11164 opened by Arfrever #11165: Document PyEval_Call* functions http://bugs.python.org/issue11165 opened by ncoghlan #11166: No exit when daemon thread is running. http://bugs.python.org/issue11166 opened by dmahn #11168: UnicodeEncodeError on recusion limit if the script filename is http://bugs.python.org/issue11168 opened by haypo #11169: compileall doesn't support the PEP 383 (undecodable paths/file http://bugs.python.org/issue11169 opened by haypo #11171: Python 2.7.1 does not start when "./configure" is used with " http://bugs.python.org/issue11171 opened by hoel #11172: Avoid '.' as runpath on AIX http://bugs.python.org/issue11172 opened by haubi #11173: Undocumented public APIs in Python 3.2 http://bugs.python.org/issue11173 opened by lemburg #11174: add argparse formatting option to display type names for metav http://bugs.python.org/issue11174 opened by bethard #11175: allow argparse FileType to accept encoding and errors argument http://bugs.python.org/issue11175 opened by bethard #11176: give more meaningful argument names in argparse documentation http://bugs.python.org/issue11176 opened by bethard #11177: Set asyncore create_socket default argument http://bugs.python.org/issue11177 opened by giampaolo.rodola #11178: Running tests inside a package by module name fails http://bugs.python.org/issue11178 opened by michael.foord #11179: ccbench doesn't work on 3.1/2.7 http://bugs.python.org/issue11179 opened by pitrou #11181: TLS end connection not detected properly in retrbinary http://bugs.python.org/issue11181 opened by adiroiban #11182: pydoc.Scanner class not used by anything http://bugs.python.org/issue11182 opened by ron_adam #11183: Finer-grained exceptions for the ssl module http://bugs.python.org/issue11183 opened by pitrou #11184: Broken large file support on AIX http://bugs.python.org/issue11184 opened by sable #11185: test_wait4 error on AIX http://bugs.python.org/issue11185 opened by sable #11186: pydoc: HTMLDoc.index() doesn't support PEP 383 http://bugs.python.org/issue11186 opened by haypo #11187: PyUnicode_AsEncodedString: the bootstrap hack is no more neede http://bugs.python.org/issue11187 opened by haypo #11188: test_time error on AIX http://bugs.python.org/issue11188 opened by sable #11190: test_locale error on AIX http://bugs.python.org/issue11190 opened by sable #11191: test_search_cpp error on AIX (with xlc) http://bugs.python.org/issue11191 opened by sable #11192: test_socket error on AIX http://bugs.python.org/issue11192 opened by sable #11193: test_subprocess error on AIX http://bugs.python.org/issue11193 opened by sable #940286: pydoc.Helper.help() ignores input/output init parameters http://bugs.python.org/issue940286 reopened by eric.araujo Most recent 15 issues with no replies (15) ========================================== #11192: test_socket error on AIX http://bugs.python.org/issue11192 #11191: test_search_cpp error on AIX (with xlc) http://bugs.python.org/issue11191 #11188: test_time error on AIX http://bugs.python.org/issue11188 #11187: PyUnicode_AsEncodedString: the bootstrap hack is no more neede http://bugs.python.org/issue11187 #11185: test_wait4 error on AIX http://bugs.python.org/issue11185 #11183: Finer-grained exceptions for the ssl module http://bugs.python.org/issue11183 #11182: pydoc.Scanner class not used by anything http://bugs.python.org/issue11182 #11179: ccbench doesn't work on 3.1/2.7 http://bugs.python.org/issue11179 #11178: Running tests inside a package by module name fails http://bugs.python.org/issue11178 #11174: add argparse formatting option to display type names for metav http://bugs.python.org/issue11174 #11172: Avoid '.' as runpath on AIX http://bugs.python.org/issue11172 #11171: Python 2.7.1 does not start when "./configure" is used with " http://bugs.python.org/issue11171 #11169: compileall doesn't support the PEP 383 (undecodable paths/file http://bugs.python.org/issue11169 #11168: UnicodeEncodeError on recusion limit if the script filename is http://bugs.python.org/issue11168 #11166: No exit when daemon thread is running. http://bugs.python.org/issue11166 Most recent 15 issues waiting for review (15) ============================================= #11187: PyUnicode_AsEncodedString: the bootstrap hack is no more neede http://bugs.python.org/issue11187 #11184: Broken large file support on AIX http://bugs.python.org/issue11184 #11177: Set asyncore create_socket default argument http://bugs.python.org/issue11177 #11172: Avoid '.' as runpath on AIX http://bugs.python.org/issue11172 #11171: Python 2.7.1 does not start when "./configure" is used with " http://bugs.python.org/issue11171 #11169: compileall doesn't support the PEP 383 (undecodable paths/file http://bugs.python.org/issue11169 #11168: UnicodeEncodeError on recusion limit if the script filename is http://bugs.python.org/issue11168 #11155: multiprocessing.Queue's put() signature differs from docs http://bugs.python.org/issue11155 #11153: urllib2 basic auth parser handle unquoted realm in WWW-Authent http://bugs.python.org/issue11153 #11149: [PATCH] Configure should enable -fwrapv for clang http://bugs.python.org/issue11149 #11144: int(float) may return a long for no reason http://bugs.python.org/issue11144 #11135: Redundant doc field in TypeSpec http://bugs.python.org/issue11135 #11134: Add missing type slots http://bugs.python.org/issue11134 #11131: decimal.py: plus/minus with ROUND_FLOOR http://bugs.python.org/issue11131 #11123: problem with packaged dependency extracter script, pdeps http://bugs.python.org/issue11123 Top 10 most discussed issues (10) ================================= #9334: argparse does not accept options taking arguments beginning wi http://bugs.python.org/issue9334 16 msgs #11116: mailbox and email errors http://bugs.python.org/issue11116 15 msgs #11063: uuid.py module import has heavy side effects http://bugs.python.org/issue11063 14 msgs #10966: eliminate use of ImportError implicitly representing SkipTest http://bugs.python.org/issue10966 13 msgs #11184: Broken large file support on AIX http://bugs.python.org/issue11184 11 msgs #4681: mmap offset should be off_t instead of ssize_t, and size calcu http://bugs.python.org/issue4681 10 msgs #11077: Tkinter is not thread safe http://bugs.python.org/issue11077 10 msgs #10882: Add os.sendfile() http://bugs.python.org/issue10882 9 msgs #11071: What's New review comments http://bugs.python.org/issue11071 9 msgs #11122: bdist_rpm fails http://bugs.python.org/issue11122 9 msgs Issues closed (38) ================== #2228: Imaplib speedup patch http://bugs.python.org/issue2228 closed by pitrou #7284: optparse - display version in usage by default http://bugs.python.org/issue7284 closed by sandro.tosi #7678: subprocess.Popen pipeline example code in the documentation is http://bugs.python.org/issue7678 closed by gregory.p.smith #8691: Doc: left alignment is not the default for numbers http://bugs.python.org/issue8691 closed by georg.brandl #10298: zipfile: incorrect comment size will prevent extracting http://bugs.python.org/issue10298 closed by rep #10891: Tweak sorting howto to eliminate redundancy http://bugs.python.org/issue10891 closed by rhettinger #10971: python Lib/test/regrtest.py -R 3:3: test_zipimport_support fai http://bugs.python.org/issue10971 closed by ncoghlan #11003: os.system should be deprecated in favour of subprocess module http://bugs.python.org/issue11003 closed by rhettinger #11067: Py_LIMITED_API breaks most PySomething_Check() functions http://bugs.python.org/issue11067 closed by loewis #11079: Make OS X entry in Applications like that in Windows http://bugs.python.org/issue11079 closed by ned.deily #11110: Py_DECREF->Py_XDECREF in Module/_sqlite/module.c http://bugs.python.org/issue11110 closed by brett.cannon #11118: Fix python3 None export http://bugs.python.org/issue11118 closed by loewis #11119: Passing a socket to a process (multiprocessing module) http://bugs.python.org/issue11119 closed by pitrou #11121: libpython3.so support with --enable-shared http://bugs.python.org/issue11121 closed by loewis #11124: test_posix failure on the Leopard buildbot http://bugs.python.org/issue11124 closed by ned.deily #11125: csv documentation should not use open() without close() http://bugs.python.org/issue11125 closed by eric.araujo #11129: logging: allow multiple entries in qualname config http://bugs.python.org/issue11129 closed by vinay.sajip #11130: SocketServer: server_address is... a socket http://bugs.python.org/issue11130 closed by orsenthil #11132: compileall.compile_dir loses 'optimize' parameter in recursion http://bugs.python.org/issue11132 closed by georg.brandl #11136: imaplib IMAP4_SSL shutdown gets socket error in py 3.2 http://bugs.python.org/issue11136 closed by pitrou #11137: clarify use of imaplib IMAP4(_SSL) shutdown http://bugs.python.org/issue11137 closed by pitrou #11138: Docs: incollect example: "fill" and "align" http://bugs.python.org/issue11138 closed by georg.brandl #11139: subprocess: Arguments to .bat scripts get interpreted by shell http://bugs.python.org/issue11139 closed by SilentGhost #11141: 2.x range() in 3.x shelve documentation http://bugs.python.org/issue11141 closed by pitrou #11143: Issue with the issue tracker http://bugs.python.org/issue11143 closed by r.david.murray #11146: Add a feature similar to C++ "using some_namespace" http://bugs.python.org/issue11146 closed by r.david.murray #11150: SVN credentials can't be provided to easy_install http://bugs.python.org/issue11150 closed by r.david.murray #11154: Alternate name for __pycache__ http://bugs.python.org/issue11154 closed by rhettinger #11156: email.encoders.encode_base64 create a single long line http://bugs.python.org/issue11156 closed by r.david.murray #11157: Use socket.accept4 syscall under linux http://bugs.python.org/issue11157 closed by pitrou #11162: Add tuple/list sep to string split method http://bugs.python.org/issue11162 closed by rhettinger #11167: Overflow in unicode_hash http://bugs.python.org/issue11167 closed by skrah #11170: (MacOS X) Crash on non-english language keyboard input in Text http://bugs.python.org/issue11170 closed by r.david.murray #11180: More efficient nlargest()/nsmallest() http://bugs.python.org/issue11180 closed by rhettinger #11189: test_resource error on AIX http://bugs.python.org/issue11189 closed by sable #1615376: subprocess doesn\'t handle SIGPIPE http://bugs.python.org/issue1615376 closed by gregory.p.smith #11061: Verify command option before parsing config file http://bugs.python.org/issue11061 closed by eric.araujo #1704474: optparse tests fail under Jython http://bugs.python.org/issue1704474 closed by sandro.tosi From tjreedy at udel.edu Fri Feb 11 19:16:12 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 11 Feb 2011 13:16:12 -0500 Subject: [Python-Dev] API bloat In-Reply-To: <4D55018E.3030608@dcs.gla.ac.uk> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com> <4D541088.8090301@dcs.gla.ac.uk> <20110210173647.31b0a4ac@pitrou.net> <4D541FA2.4090801@dcs.gla.ac.uk> <4D55018E.3030608@dcs.gla.ac.uk> Message-ID: On 2/11/2011 4:29 AM, Mark Shannon wrote: > Nick Coghlan wrote: >> Now that the issue has been brought up, it can certainly be taken into >> consideration for 3.3. The idea of defining a Py_PORTABLE_API that is >> even more restrictive than PEP 384 (e.g. eliminating lots of old cruft >> that is a legacy of CPython's long history of development when it was >> the *only* viable Python implementation) may also be worth exploring. > > Absolutely. I intend to do just that. I think we should try to have deprecations and removals in the codebase by the first alpha release for maximal testing. GP's asyncore changes inspired this thought, but I would apply it generally. -- Terry Jan Reedy From stutzbach at google.com Fri Feb 11 19:11:54 2011 From: stutzbach at google.com (Daniel Stutzbach) Date: Fri, 11 Feb 2011 10:11:54 -0800 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> Message-ID: On Fri, Feb 11, 2011 at 8:06 AM, Guido van Rossum wrote: > > And finally remember that asyncore is the most monkey-patched module > in the world. :-) I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys. -- Daniel Stutzbach -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Fri Feb 11 19:28:25 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 11 Feb 2011 19:28:25 +0100 Subject: [Python-Dev] API bloat References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com> <4D541088.8090301@dcs.gla.ac.uk> <20110210173647.31b0a4ac@pitrou.net> <4D541FA2.4090801@dcs.gla.ac.uk> <4D55018E.3030608@dcs.gla.ac.uk> Message-ID: <20110211192825.79159318@pitrou.net> On Fri, 11 Feb 2011 13:16:12 -0500 Terry Reedy wrote: > On 2/11/2011 4:29 AM, Mark Shannon wrote: > > Nick Coghlan wrote: > > >> Now that the issue has been brought up, it can certainly be taken into > >> consideration for 3.3. The idea of defining a Py_PORTABLE_API that is > >> even more restrictive than PEP 384 (e.g. eliminating lots of old cruft > >> that is a legacy of CPython's long history of development when it was > >> the *only* viable Python implementation) may also be worth exploring. > > > > Absolutely. I intend to do just that. > > I think we should try to have deprecations and removals in the codebase > by the first alpha release for maximal testing. Why would we deprecate or remove anything? Are some functions useless? Reducing the number of API functions is not a goal in itself. Regards Antoine. From benjamin at python.org Fri Feb 11 19:35:59 2011 From: benjamin at python.org (Benjamin Peterson) Date: Fri, 11 Feb 2011 12:35:59 -0600 Subject: [Python-Dev] API bloat In-Reply-To: <20110211192825.79159318@pitrou.net> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com> <4D541088.8090301@dcs.gla.ac.uk> <20110210173647.31b0a4ac@pitrou.net> <4D541FA2.4090801@dcs.gla.ac.uk> <4D55018E.3030608@dcs.gla.ac.uk> <20110211192825.79159318@pitrou.net> Message-ID: 2011/2/11 Antoine Pitrou : > On Fri, 11 Feb 2011 13:16:12 -0500 > Terry Reedy wrote: >> On 2/11/2011 4:29 AM, Mark Shannon wrote: >> > Nick Coghlan wrote: >> >> >> Now that the issue has been brought up, it can certainly be taken into >> >> consideration for 3.3. The idea of defining a Py_PORTABLE_API that is >> >> even more restrictive than PEP 384 (e.g. eliminating lots of old cruft >> >> that is a legacy of CPython's long history of development when it was >> >> the *only* viable Python implementation) may also be worth exploring. >> > >> > Absolutely. I intend to do just that. >> >> I think we should try to have deprecations and removals in the codebase >> by the first alpha release for maximal testing. > > Why would we deprecate or remove anything? Are some functions useless? > Reducing the number of API functions is not a goal in itself. I think he's referring to deprecations and removals in general. -- Regards, Benjamin From solipsis at pitrou.net Fri Feb 11 19:36:52 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 11 Feb 2011 19:36:52 +0100 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> Message-ID: <20110211193652.0395d199@pitrou.net> On Fri, 11 Feb 2011 10:11:54 -0800 Daniel Stutzbach wrote: > On Fri, Feb 11, 2011 at 8:06 AM, Guido van Rossum wrote: > > > > And finally remember that asyncore is the most monkey-patched module > > in the world. :-) > > > I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys. Would that be a Mapping or a Sequence? From benjamin at python.org Fri Feb 11 19:44:19 2011 From: benjamin at python.org (Benjamin Peterson) Date: Fri, 11 Feb 2011 12:44:19 -0600 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <20110211193652.0395d199@pitrou.net> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <20110211193652.0395d199@pitrou.net> Message-ID: 2011/2/11 Antoine Pitrou : > On Fri, 11 Feb 2011 10:11:54 -0800 > Daniel Stutzbach wrote: >> On Fri, Feb 11, 2011 at 8:06 AM, Guido van Rossum wrote: >> > >> > And finally remember that asyncore is the most monkey-patched module >> > in the world. :-) >> >> >> I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys. > > Would that be a Mapping or a Sequence? Actually, probably Laughable. -- Regards, Benjamin From g.rodola at gmail.com Fri Feb 11 20:56:40 2011 From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=) Date: Fri, 11 Feb 2011 20:56:40 +0100 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> Message-ID: Yeah, the original API design (which is very inflexible) and the lack of maintenance for many years is at the base of asyncore problems. I still think it worths some love as a stdlib module, though. For 3.3 I have in mind to revamp asyncore/asynchat a bit by introducing SSL support and finally add a scheduler (issue 1641). --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ 2011/2/11 Daniel Stutzbach : > On Fri, Feb 11, 2011 at 8:06 AM, Guido van Rossum wrote: >> >> And finally remember that asyncore is the most monkey-patched module >> in the world. :-) > > I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys. > -- > Daniel Stutzbach > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com > > From martin at v.loewis.de Fri Feb 11 21:20:04 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Fri, 11 Feb 2011 21:20:04 +0100 Subject: [Python-Dev] API bloat In-Reply-To: <4D55018E.3030608@dcs.gla.ac.uk> References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com> <4D541088.8090301@dcs.gla.ac.uk> <20110210173647.31b0a4ac@pitrou.net> <4D541FA2.4090801@dcs.gla.ac.uk> <4D55018E.3030608@dcs.gla.ac.uk> Message-ID: <4D5599F4.2040500@v.loewis.de> >> 1. CPython developers >> 2. authors of CPython extensions >> 3. developers embedding a CPython interpreter (or interpreters) into >> their application > > This makes me wonder who `owns' the API. > Is the CPython developers, the Python community as a whole, the PSF? > (Another one for Python-ideas) Clearly the CPython contributors own the API. There are both policies for additions and policies for removal, and so far, these policies haven't been challenged. The "addition" policy is that anything can be added as long as it's reasonable that future versions support it, and that there is a plausible use case for an embedder or extender actually making use of the API. The "removal" policy is that things can be removed after "proper" deprecation. The precise requirements of deprecation depend on how widely the API is being used. More explicitly: while it is policy to consider alternative implementations when changing the language or the standard library, it is not policy to consider alternative implementations when changing the C API. Regards, Martin From tjreedy at udel.edu Fri Feb 11 21:34:10 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Fri, 11 Feb 2011 15:34:10 -0500 Subject: [Python-Dev] API bloat In-Reply-To: References: <4D5259B4.8030205@dcs.gla.ac.uk> <4D526E57.9030206@dcs.gla.ac.uk> <4D52F127.4050906@v.loewis.de> <4D53BAE4.9070000@dcs.gla.ac.uk> <4D53EA20.80403@dcs.gla.ac.uk> <4D53ED7F.1050300@egenix.com> <4D53F592.2080401@dcs.gla.ac.uk> <4D54021C.9000304@egenix.com> <4D541088.8090301@dcs.gla.ac.uk> <20110210173647.31b0a4ac@pitrou.net> <4D541FA2.4090801@dcs.gla.ac.uk> <4D55018E.3030608@dcs.gla.ac.uk> <20110211192825.79159318@pitrou.net> Message-ID: On 2/11/2011 1:35 PM, Benjamin Peterson wrote: > 2011/2/11 Antoine Pitrou: >> On Fri, 11 Feb 2011 13:16:12 -0500 >> Terry Reedy wrote: >>> On 2/11/2011 4:29 AM, Mark Shannon wrote: >>>> Nick Coghlan wrote: >>> >>>>> Now that the issue has been brought up, it can certainly be taken into >>>>> consideration for 3.3. The idea of defining a Py_PORTABLE_API that is >>>>> even more restrictive than PEP 384 (e.g. eliminating lots of old cruft >>>>> that is a legacy of CPython's long history of development when it was >>>>> the *only* viable Python implementation) may also be worth exploring. >>>> >>>> Absolutely. I intend to do just that. >>> >>> I think we should try to have deprecations and removals in the codebase >>> by the first alpha release for maximal testing. My next sentence [snipped] was "GP's asyncore changes inspired this thought, but I would apply it generally." >> Why would we deprecate or remove anything? Are some functions useless? Shannon thinks so. I am specifically suggesting that he make any removal suggestion well before the alpha release. > I think he's referring to deprecations and removals in general. Yes, as I said. I am also thinking about 3.2 deprecations that will become 3.3 removals. That includes one that I am responsible for. -- Terry Jan Reedy From stutzbach at google.com Fri Feb 11 23:09:23 2011 From: stutzbach at google.com (Daniel Stutzbach) Date: Fri, 11 Feb 2011 14:09:23 -0800 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <20110211193652.0395d199@pitrou.net> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <20110211193652.0395d199@pitrou.net> Message-ID: On Fri, Feb 11, 2011 at 10:36 AM, Antoine Pitrou wrote: > Daniel Stutzbach wrote: > > I propose that in Python 3.3 we rename asyncore to barrel_of_monkeys. > > Would that be a Mapping or a Sequence? Before or after monkey-patching? :-) -- Daniel Stutzbach -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Sat Feb 12 01:16:28 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 12 Feb 2011 10:16:28 +1000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> Message-ID: On Sat, Feb 12, 2011 at 5:56 AM, Giampaolo Rodol? wrote: > Yeah, the original API design (which is very inflexible) and the lack > of maintenance for many years is at the base of asyncore problems. > I still think it worths some love as a stdlib module, though. Oh, definitely. It's popularity is half the problem :) Flawed API + lack of popularity = just fix it Flawed API + popularity = years of fun* *For a given definition of fun, that may or may not align with any real person's idea of fun ;) Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From turnbull at sk.tsukuba.ac.jp Sat Feb 12 07:26:11 2011 From: turnbull at sk.tsukuba.ac.jp (Stephen J. Turnbull) Date: Sat, 12 Feb 2011 15:26:11 +0900 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <20110211193652.0395d199@pitrou.net> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <20110211193652.0395d199@pitrou.net> Message-ID: <87hbc9kbuk.fsf@uwakimon.sk.tsukuba.ac.jp> Antoine Pitrou writes: > Would that be a Mapping or a Sequence? Sure it would be nowhere near as predictable as a Mapping or Sequence, so Isuppose it would be a Container ... although the probability of OverflowException is near 1. From swamiyeswanth at gmail.com Sat Feb 12 13:44:51 2011 From: swamiyeswanth at gmail.com (yeswanth swami) Date: Sat, 12 Feb 2011 18:14:51 +0530 Subject: [Python-Dev] Gsoc 2011 ideas Message-ID: Hi everyone, I am planning to apply for Gsoc 2011 for the PSF . I would like to know if any of you have any ideas which can be implemented this summer. I guess the gsoc 2011 ideas page has not been put up as yet. So I thought maybe any of you can suggest some ideas . Thanks Yeswanth -------------- next part -------------- An HTML attachment was scrubbed... URL: From arcriley at gmail.com Sat Feb 12 15:52:16 2011 From: arcriley at gmail.com (Arc Riley) Date: Sat, 12 Feb 2011 09:52:16 -0500 Subject: [Python-Dev] Gsoc 2011 ideas In-Reply-To: References: Message-ID: Hey Yeswanth Students who get involved with the projects they plan to work with early have a definite edge over students who don't, so certainly get involved now. While I would highly encourage you to get involved with python-dev (core projects are top in line), you may also want to consider 3rd party libraries for Python 3 or to help a Python 2 library port to 3. Python-dev has a list of bugs. Pick one and start, submit patches, join IRC (#python-dev on irc.freenode.net) and see if you can find someone who can help you get started. On Sat, Feb 12, 2011 at 7:44 AM, yeswanth swami wrote: > Hi everyone, > I am planning to apply for Gsoc 2011 for the PSF . I would like to know if > any of you have any ideas which can be implemented this summer. I guess the > gsoc 2011 ideas page has not been put up as yet. So I thought maybe any of > you can suggest some ideas . > > Thanks > Yeswanth > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/arcriley%40gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From merwok at netwok.org Sat Feb 12 22:42:41 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sat, 12 Feb 2011 22:42:41 +0100 Subject: [Python-Dev] [Python-checkins] devguide: Comment out the "make patchcheck" advice, since it doesn't work for a In-Reply-To: References: Message-ID: <4D56FED1.60907@netwok.org> > antoine.pitrou pushed f22bac464e11 to devguide: > summary: > Comment out the "make patchcheck" advice, since it doesn't work for a > non-SVN workflow. patchcheck should work after http://svn.python.org/view?view=rev&revision=85767 (from http://bugs.python.org/issue8999). What specific part of ?it? doesn?t work? Regards From solipsis at pitrou.net Sat Feb 12 22:50:56 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 12 Feb 2011 22:50:56 +0100 Subject: [Python-Dev] [Python-checkins] devguide: Comment out the "make patchcheck" advice, since it doesn't work for a References: <4D56FED1.60907@netwok.org> Message-ID: <20110212225056.11f08dd4@pitrou.net> On Sat, 12 Feb 2011 22:42:41 +0100 ?ric Araujo wrote: > > antoine.pitrou pushed f22bac464e11 to devguide: > > summary: > > Comment out the "make patchcheck" advice, since it doesn't work for a > > non-SVN workflow. > > patchcheck should work after > http://svn.python.org/view?view=rev&revision=85767 (from > http://bugs.python.org/issue8999). What specific part of ?it? doesn?t work? What precisely I explained in http://bugs.python.org/issue8999#msg108477 Antoine. From greg.ewing at canterbury.ac.nz Sat Feb 12 23:19:06 2011 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sun, 13 Feb 2011 11:19:06 +1300 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> Message-ID: <4D57075A.1050108@canterbury.ac.nz> Nick Coghlan wrote: > Flawed API + popularity = years of fun* So maybe it's time to design a new module with a better API and deprecate the old one? -- Greg From solipsis at pitrou.net Sat Feb 12 23:28:46 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 12 Feb 2011 23:28:46 +0100 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> Message-ID: <20110212232846.35b55400@pitrou.net> On Sun, 13 Feb 2011 11:19:06 +1300 Greg Ewing wrote: > Nick Coghlan wrote: > > > Flawed API + popularity = years of fun* > > So maybe it's time to design a new module with a better API > and deprecate the old one? That's called Twisted. From greg.ewing at canterbury.ac.nz Sat Feb 12 23:46:36 2011 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sun, 13 Feb 2011 11:46:36 +1300 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <20110212232846.35b55400@pitrou.net> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> Message-ID: <4D570DCC.5030903@canterbury.ac.nz> Antoine Pitrou wrote: > On Sun, 13 Feb 2011 11:19:06 +1300 > Greg Ewing wrote: >>So maybe it's time to design a new module with a better API >>and deprecate the old one? > > That's called Twisted. I was thinking of something lighter-weight than that. -- Greg From exarkun at twistedmatrix.com Sun Feb 13 00:10:46 2011 From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com) Date: Sat, 12 Feb 2011 23:10:46 -0000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <4D570DCC.5030903@canterbury.ac.nz> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> Message-ID: <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> On 10:46 pm, greg.ewing at canterbury.ac.nz wrote: >Antoine Pitrou wrote: >>On Sun, 13 Feb 2011 11:19:06 +1300 >>Greg Ewing wrote: > >>>So maybe it's time to design a new module with a better API >>>and deprecate the old one? >> >>That's called Twisted. > >I was thinking of something lighter-weight than that. Twisted Core Jean-Paul From p.f.moore at gmail.com Sun Feb 13 01:13:00 2011 From: p.f.moore at gmail.com (Paul Moore) Date: Sun, 13 Feb 2011 00:13:00 +0000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> Message-ID: On 12 February 2011 23:10, wrote: > On 10:46 pm, greg.ewing at canterbury.ac.nz wrote: >> >> Antoine Pitrou wrote: >>> >>> On Sun, 13 Feb 2011 11:19:06 +1300 >>> Greg Ewing wrote: >> >>>> So maybe it's time to design a new module with a better API >>>> and deprecate the old one? >>> >>> That's called Twisted. >> >> I was thinking of something lighter-weight than that. > > Twisted Core Is anyone willing to package up Twisted Core for stdlib inclusion, then? Paul. From exarkun at twistedmatrix.com Sun Feb 13 01:22:58 2011 From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com) Date: Sun, 13 Feb 2011 00:22:58 -0000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> Message-ID: <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> On 12:13 am, p.f.moore at gmail.com wrote: >On 12 February 2011 23:10, wrote: >>On 10:46 pm, greg.ewing at canterbury.ac.nz wrote: >>> >>>Antoine Pitrou wrote: >>>> >>>>On Sun, 13 Feb 2011 11:19:06 +1300 >>>>Greg Ewing wrote: >>> >>>>>So maybe it's time to design a new module with a better API >>>>>and deprecate the old one? >>>> >>>>That's called Twisted. >>> >>>I was thinking of something lighter-weight than that. >> >>Twisted Core > >Is anyone willing to package up Twisted Core for stdlib inclusion, >then? >Paul. Do people want to seriously consider deprecating asyncore and adding a replacement for it to the stdlib? (Hey, PyCon is coming up. How convenient. :) Jean-Paul From stutzbach at google.com Sun Feb 13 01:34:56 2011 From: stutzbach at google.com (Daniel Stutzbach) Date: Sat, 12 Feb 2011 16:34:56 -0800 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> Message-ID: On Sat, Feb 12, 2011 at 4:22 PM, wrote: > Do people want to seriously consider deprecating asyncore and adding a > replacement for it to the stdlib? > > (Hey, PyCon is coming up. How convenient. :) > The desire is there, but it's a hard problem. There was a similar discussion before PyCon 2009, but not much came of it: http://mail.python.org/pipermail/python-dev/2009-March/086678.html -- Daniel Stutzbach -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcolish at gmail.com Sun Feb 13 02:53:16 2011 From: dcolish at gmail.com (Dan Colish) Date: Sat, 12 Feb 2011 17:53:16 -0800 Subject: [Python-Dev] PSF Sponsored Sprint in Portland, OR Message-ID: Hello Developers! I'm one of the organizers of the Portland PSF Sprint. We've been working hard on our proposal to come up with a strong program for a full day of sprinting in Portland. The day will mostly focus on porting libraries to Python 3, hacking on PyPY 2.7 compatibility and testing. It'll be a great time so if you're in the area stop on by! The current project list includes:- Fabric - Django - Flatland - PyPy - Alfajor Want to suggest your own? Use the signup sheet here. Breakfast is being sponsored by Idealist.org, lunch is being sponsored by Emma and beverages will be made available by Urban Airship. More information: http://goo.gl/XTMWv. Signup sheet: http://goo.gl/a5Gqk. -- Dan From exarkun at twistedmatrix.com Sun Feb 13 05:20:59 2011 From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com) Date: Sun, 13 Feb 2011 04:20:59 -0000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> Message-ID: <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> On 12:34 am, stutzbach at google.com wrote: >On Sat, Feb 12, 2011 at 4:22 PM, wrote: >>Do people want to seriously consider deprecating asyncore and adding a >>replacement for it to the stdlib? > >>(Hey, PyCon is coming up. How convenient. :) > >The desire is there, but it's a hard problem. There was a similar >discussion before PyCon 2009, but not much came of it: > >http://mail.python.org/pipermail/python-dev/2009-March/086678.html I started working on a PEP last year, but I didn't get very far partly because I doubted the desire. What part do you think is a hard problem? Convincing people to switch to a new API? *Defining* the new API doesn't seem very hard to me. Jean-Paul From eliben at gmail.com Sun Feb 13 05:52:33 2011 From: eliben at gmail.com (Eli Bendersky) Date: Sun, 13 Feb 2011 06:52:33 +0200 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> Message-ID: > I started working on a PEP last year, but I didn't get very far partly > because I doubted the desire. > > What part do you think is a hard problem? ?Convincing people to switch to a > new API? ?*Defining* the new API doesn't seem very hard to me. > I must say that the only time I needed the functionality asyncore provides in some Python code, 5 minutes of browsing and reading pointed me to Twisted anyway. I think that having the "ultimately recommended" library for such programming in stdlib is a good idea, or at least some core of it. We have a tradition of new modules replacing old ones with the same functionality gradually (command line argument parsing, for example) and if someone is motivated enough to prepare a comprehensive PEP and then working on pulling it through, I think it may work. Eli From ncoghlan at gmail.com Sun Feb 13 10:18:52 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 13 Feb 2011 19:18:52 +1000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> Message-ID: On Sun, Feb 13, 2011 at 2:20 PM, wrote: >> The desire is there, but it's a hard problem. ?There was a similar >> discussion before PyCon 2009, but not much came of it: >> >> http://mail.python.org/pipermail/python-dev/2009-March/086678.html > > I started working on a PEP last year, but I didn't get very far partly > because I doubted the desire. > > What part do you think is a hard problem? ?Convincing people to switch to a > new API? ?*Defining* the new API doesn't seem very hard to me. If there is an essential subset of the API that the Twisted devs think would be a suitable replacement for asyncore, while providing a more straightforward migration path into Twisted itself, then it certainly makes sense to include it. The other possible sticking point I can see is that I don't know how Twisted's licensing works - is there anyone with the legal authority to appropriately license the code to the PSF for inclusion in the standard library? Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From solipsis at pitrou.net Sun Feb 13 15:23:38 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 13 Feb 2011 15:23:38 +0100 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> Message-ID: <20110213152338.46eb689b@pitrou.net> On Sun, 13 Feb 2011 19:18:52 +1000 Nick Coghlan wrote: > > If there is an essential subset of the API that the Twisted devs think > would be a suitable replacement for asyncore, while providing a more > straightforward migration path into Twisted itself, then it certainly > makes sense to include it. That subset would be the reactor (actually, the various reactor implementations) and its close dependencies. However, that might already amount to a sizeable chunk of code :-) (for good reason, of course: even Twisted Core does much, much more than asyncore). > The other possible sticking point I can see is that I don't know how > Twisted's licensing works - is there anyone with the legal authority > to appropriately license the code to the PSF for inclusion in the > standard library? Twisted's license is MIT-like so I don't think there would be any so-called "licensing" problem. :-) Regards Antoine. From fuzzyman at voidspace.org.uk Sun Feb 13 15:32:16 2011 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 13 Feb 2011 14:32:16 +0000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <20110213152338.46eb689b@pitrou.net> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> <20110213152338.46eb689b@pitrou.net> Message-ID: <4D57EB70.8080600@voidspace.org.uk> On 13/02/2011 14:23, Antoine Pitrou wrote: > On Sun, 13 Feb 2011 19:18:52 +1000 > Nick Coghlan wrote: >> If there is an essential subset of the API that the Twisted devs think >> would be a suitable replacement for asyncore, while providing a more >> straightforward migration path into Twisted itself, then it certainly >> makes sense to include it. > That subset would be the reactor (actually, the various reactor > implementations) and its close dependencies. However, that might > already amount to a sizeable chunk of code :-) (for good reason, of > course: even Twisted Core does much, much more than asyncore). > It would then be subject to python-dev development policy rather than twisted dev policy (which is even stricter!). Would the twisted devs *really* want that? We could use the same processes we have for "externally maintained" libraries, but they have without fail caused us problems. This is usually due to maintainers leaving or going dark, which *probably* wouldn't be the case with twisted, nonetheless we've been burned enough times to be cautious about adding new "externally maintained" packages to the standard library. Not to mention that the twisted tests have quite a few "non standard library" dependencies, so integrating it would be non-trivial. That's after it has been ported to Python 3. The other issue is that just because we provide an alternative doesn't mean that everyone automatically stops using asyncore and migrates. That means the maintenance burden of asyncore doesn't necessarily go away, we just add a new maintenance burden (albeit one with lots of advantages - certainly in principle it would be *great* to have twisted-core in the standard library). >> The other possible sticking point I can see is that I don't know how >> Twisted's licensing works - is there anyone with the legal authority >> to appropriately license the code to the PSF for inclusion in the >> standard library? > Twisted's license is MIT-like so I don't think there would be any > so-called "licensing" problem. :-) > That's not sufficient (IIUC). The code *authors* (copyright owners) have to agree, and probably have to sign contributor agreements. :-) Twisted have gone through an IP management process already I believe, so it is certainly possible. Michael > Regards > > Antoine. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From solipsis at pitrou.net Sun Feb 13 15:51:01 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 13 Feb 2011 15:51:01 +0100 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <4D57EB70.8080600@voidspace.org.uk> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> <20110213152338.46eb689b@pitrou.net> <4D57EB70.8080600@voidspace.org.uk> Message-ID: <1297608661.3802.25.camel@localhost.localdomain> > It would then be subject to python-dev development policy rather than > twisted dev policy (which is even stricter!). Would the twisted devs > *really* want that? We could use the same processes we have for > "externally maintained" libraries, but they have without fail caused us > problems. Oh, I agree with you. -1 on any new externally maintained library. > The other issue is that just because we provide an alternative doesn't > mean that everyone automatically stops using asyncore and migrates. Of course. asyncore's problem is not that its a maintenance burden, it's that it's really subpar compared to everything else out there. That said, Giampaolo has committed to taking it forward, so perhaps the 3.3 version of asyncore will be much (?) better. > >> The other possible sticking point I can see is that I don't know how > >> Twisted's licensing works - is there anyone with the legal authority > >> to appropriately license the code to the PSF for inclusion in the > >> standard library? > > Twisted's license is MIT-like so I don't think there would be any > > so-called "licensing" problem. :-) > > > That's not sufficient (IIUC). The code *authors* (copyright owners) have > to agree, and probably have to sign contributor agreements. :-) Well, of course. Or at least that's the theory. In practice, the algebra of open source licenses is quite well-known and non-copyleft code usually can be combined freely without any worries. (and do you think the zlib authors signed a contributor agreement for inclusion in Python distributions? :-)) > Twisted > have gone through an IP management process already I believe, so it is > certainly possible. "IP management process"? What is that horrible jargon supposed to mean? :) I don't think the Twisted people are into legalese, and I've never signed an agreement when contributing (admittedly little) code to Twisted. They did relicense Twisted once (from LGPL to MIT-like), but that probably means they asked every past contributor. Regards Antoine. From alexis at notmyidea.org Sun Feb 13 15:47:01 2011 From: alexis at notmyidea.org (=?ISO-8859-1?Q?Alexis_M=E9taireau?=) Date: Sun, 13 Feb 2011 14:47:01 +0000 Subject: [Python-Dev] Rights on the tracker Message-ID: <4D57EEE5.9040904@notmyidea.org> Hi python-devs, I'm currently working on distutils2, and I'm trying to stop having different informations in different places. This means using the bugs.python.org bugtracker, instead of some weird TODO-lists in the bitbucket wiki. Two requests then: * Is it possible to give me the rights to edit the reports for the distutils2 component ? * Is it possible to automatically be in the noisy list for distutils2' bug reports ? Tarek co-opts this. My roundup username is "alexis". Thanks, Alex From tjreedy at udel.edu Sun Feb 13 16:40:59 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Sun, 13 Feb 2011 10:40:59 -0500 Subject: [Python-Dev] Rights on the tracker In-Reply-To: <4D57EEE5.9040904@notmyidea.org> References: <4D57EEE5.9040904@notmyidea.org> Message-ID: On 2/13/2011 9:47 AM, Alexis M?taireau wrote: > Tarek co-opts this. Do you meant that Tarek supports or approves of this? (Co-opt means something rather different in English.) -- Terry Jan Reedy From alexis at notmyidea.org Sun Feb 13 16:48:40 2011 From: alexis at notmyidea.org (=?ISO-8859-1?Q?Alexis_M=E9taireau?=) Date: Sun, 13 Feb 2011 15:48:40 +0000 Subject: [Python-Dev] Rights on the tracker In-Reply-To: References: <4D57EEE5.9040904@notmyidea.org> Message-ID: <4D57FD58.1060108@notmyidea.org> Le 13/02/2011 15:40, Terry Reedy a ?crit : > Do you meant that Tarek supports or approves of this? > (Co-opt means something rather different in English.) Sorry, I mean that Tarek approves that :-) From merwok at netwok.org Sun Feb 13 17:12:15 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sun, 13 Feb 2011 17:12:15 +0100 Subject: [Python-Dev] Rights on the tracker In-Reply-To: <4D57EEE5.9040904@notmyidea.org> References: <4D57EEE5.9040904@notmyidea.org> Message-ID: <4D5802DF.1050705@netwok.org> Hi, I?ve wanted to move our TODO wiki page to the bug tracker for months, thanks for doing it! Auto-nosy is useful to catch new bugs; for existing bugs, instead of adding yourself manually to each one and trigger not-so-useful email, a tracker admin could add you automatically. I?ve asked on http://psf.upfronthosting.co.za/roundup/meta/issue362 Regards From alexis at notmyidea.org Sun Feb 13 18:14:52 2011 From: alexis at notmyidea.org (=?UTF-8?B?QWxleGlzIE3DqXRhaXJlYXU=?=) Date: Sun, 13 Feb 2011 17:14:52 +0000 Subject: [Python-Dev] Rights on the tracker In-Reply-To: <4D5802DF.1050705@netwok.org> References: <4D57EEE5.9040904@notmyidea.org> <4D5802DF.1050705@netwok.org> Message-ID: <4D58118C.3040709@notmyidea.org> Le 13/02/2011 16:12, ?ric Araujo a ?crit : > Hi, > > I?ve wanted to move our TODO wiki page to the bug tracker for months, > thanks for doing it! Auto-nosy is useful to catch new bugs; for > existing bugs, instead of adding yourself manually to each one and > trigger not-so-useful email, a tracker admin could add you > automatically. I?ve asked on > http://psf.upfronthosting.co.za/roundup/meta/issue362 Great, thanks for that :) From greg.ewing at canterbury.ac.nz Sun Feb 13 21:06:53 2011 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Mon, 14 Feb 2011 09:06:53 +1300 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> Message-ID: <4D5839DD.5070906@canterbury.ac.nz> exarkun at twistedmatrix.com wrote: > On 10:46 pm, greg.ewing at canterbury.ac.nz wrote: >>> On Sun, 13 Feb 2011 11:19:06 +1300 >>> Greg Ewing wrote: >> >> I was thinking of something lighter-weight than that. > > Twisted Core I just had a look at the docs for Twisted Core, and it lists 10 sub-modules. The only one that really looks "core" to me is twisted.internet. Drilling into that reveals another 39 public sub-sub-modules and 10 private ones. Sorry, but you'll have to chop it back quite a bit more than that before it's focused enough to be a stlib module, I think. -- Greg From exarkun at twistedmatrix.com Sun Feb 13 23:11:47 2011 From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com) Date: Sun, 13 Feb 2011 22:11:47 -0000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <4D5839DD.5070906@canterbury.ac.nz> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <4D5839DD.5070906@canterbury.ac.nz> Message-ID: <20110213221147.1914.1118758870.divmod.xquotient.59@localhost.localdomain> On 08:06 pm, greg.ewing at canterbury.ac.nz wrote: >exarkun at twistedmatrix.com wrote: >>On 10:46 pm, greg.ewing at canterbury.ac.nz wrote: >>>>On Sun, 13 Feb 2011 11:19:06 +1300 >>>>Greg Ewing wrote: >>> >>>I was thinking of something lighter-weight than that. >> >>Twisted Core > >I just had a look at the docs for Twisted Core, and it lists >10 sub-modules. The only one that really looks "core" to me >is twisted.internet. Drilling into that reveals another >39 public sub-sub-modules and 10 private ones. > >Sorry, but you'll have to chop it back quite a bit more than >that before it's focused enough to be a stlib module, I think. Excluding stuff is not hard, seriously. It's not hard to see that wxPython integration doesn't belong in the stdlib. There are more useful aspects of the task to discuss. Jean-Paul From ncoghlan at gmail.com Sun Feb 13 23:23:46 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 14 Feb 2011 08:23:46 +1000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <20110213221147.1914.1118758870.divmod.xquotient.59@localhost.localdomain> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <4D5839DD.5070906@canterbury.ac.nz> <20110213221147.1914.1118758870.divmod.xquotient.59@localhost.localdomain> Message-ID: On Mon, Feb 14, 2011 at 8:11 AM, wrote: > > Excluding stuff is not hard, seriously. ?It's not hard to see that wxPython > integration doesn't belong in the stdlib. ?There are more useful aspects of > the task to discuss. I think part of the problem is that those of us that aren't Twisted users aren't familiar enough with it to know which of the elements in twisted.internet would be important to include in a stdlib "reactor" package (or whatever it ended up being called). So we see the size of twisted.internet and start to get nervous. Our fears may be unfounded in practice, but we don't know that up front. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From prologic at shortcircuit.net.au Sun Feb 13 23:24:24 2011 From: prologic at shortcircuit.net.au (James Mills) Date: Mon, 14 Feb 2011 08:24:24 +1000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <20110213221147.1914.1118758870.divmod.xquotient.59@localhost.localdomain> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <4D5839DD.5070906@canterbury.ac.nz> <20110213221147.1914.1118758870.divmod.xquotient.59@localhost.localdomain> Message-ID: On Mon, Feb 14, 2011 at 8:11 AM, wrote: > On 08:06 pm, greg.ewing at canterbury.ac.nz wrote: >> >> exarkun at twistedmatrix.com wrote: >>> >>> On 10:46 pm, greg.ewing at canterbury.ac.nz wrote: >>>>> >>>>> On Sun, 13 Feb 2011 11:19:06 +1300 >>>>> Greg Ewing wrote: >>>> >>>> I was thinking of something lighter-weight than that. >>> >>> Twisted Core >> >> I just had a look at the docs for Twisted Core, and it lists >> 10 sub-modules. The only one that really looks "core" to me >> is twisted.internet. Drilling into that reveals another >> 39 public sub-sub-modules and 10 private ones. >> >> Sorry, but you'll have to chop it back quite a bit more than >> that before it's focused enough to be a stlib module, I think. > > Excluding stuff is not hard, seriously. ?It's not hard to see that wxPython > integration doesn't belong in the stdlib. ?There are more useful aspects of > the task to discuss. I don't mean to but in here and I may have no business doing so... But what about circuits.core ? cheers James -- -- James Mills -- -- "Problems are solved by method" From fuzzyman at voidspace.org.uk Sun Feb 13 23:36:59 2011 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 13 Feb 2011 22:36:59 +0000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <4D5839DD.5070906@canterbury.ac.nz> <20110213221147.1914.1118758870.divmod.xquotient.59@localhost.localdomain> Message-ID: <4D585D0B.6010208@voidspace.org.uk> On 13/02/2011 22:24, James Mills wrote: > On Mon, Feb 14, 2011 at 8:11 AM, wrote: >> On 08:06 pm, greg.ewing at canterbury.ac.nz wrote: >>> exarkun at twistedmatrix.com wrote: >>>> On 10:46 pm, greg.ewing at canterbury.ac.nz wrote: >>>>>> On Sun, 13 Feb 2011 11:19:06 +1300 >>>>>> Greg Ewing wrote: >>>>> I was thinking of something lighter-weight than that. >>>> Twisted Core >>> I just had a look at the docs for Twisted Core, and it lists >>> 10 sub-modules. The only one that really looks "core" to me >>> is twisted.internet. Drilling into that reveals another >>> 39 public sub-sub-modules and 10 private ones. >>> >>> Sorry, but you'll have to chop it back quite a bit more than >>> that before it's focused enough to be a stlib module, I think. >> Excluding stuff is not hard, seriously. It's not hard to see that wxPython >> integration doesn't belong in the stdlib. There are more useful aspects of >> the task to discuss. > I don't mean to but in here and I may have no business > doing so... But what about circuits.core ? > Well, what about it? The virtue of twisted is that even if we haven't all used it, we've all heard of it. That speaks volumes about its penetration into the python world. Note that the requirements for inclusion in the standard library (and at this point the conversation should really move to python-ideas) are *ideally*: * well established and widely used * well written and tested (including working on the major platforms that python runs on) * solves a common problem * the "owners" are submitting the code for conclusion and we have someone (preferably more than one) commited to maintaining the code in the core for the forseeable future * can be integrated with python-as-it-is-at-the-moment without bringing in new dependencies that *shouldn't* go into python core Twisted certainly meets the first three of those requirements, the last two are uncertain and still being discussed. We *don't* go around fishing for projects to include which is why we haven't suggested alternatives. There has been ongoing musing about including parts of twisted for many years however, and the core contributor to this discussion (Jean-Paul Calderone) is one of the lead developers of twisted. I think if we *were* going to include an alternative async event loop into the Python standard library there would have to be very good reasons for it *not* to be twisted, just because of the prominence of twisted within the python ecosystem. All the best, Michael Foord > cheers > James > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From prologic at shortcircuit.net.au Sun Feb 13 23:43:48 2011 From: prologic at shortcircuit.net.au (James Mills) Date: Mon, 14 Feb 2011 08:43:48 +1000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <4D585D0B.6010208@voidspace.org.uk> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <4D5839DD.5070906@canterbury.ac.nz> <20110213221147.1914.1118758870.divmod.xquotient.59@localhost.localdomain> <4D585D0B.6010208@voidspace.org.uk> Message-ID: On Mon, Feb 14, 2011 at 8:36 AM, Michael Foord wrote: > Well, what about it? The virtue of twisted is that even if we haven't all > used it, we've all heard of it. That speaks volumes about its penetration > into the python world. Just a mere suggestion. The fact that this discussion exists means that Twisted may end up being in the std. lib in the end because no-one can come up with a better? solution that meets "all" requirements. In any case, there are other alternatives. I realize we're not discussing them but it's nice to know what is and can be included in the std. lib, etc. I'll just follow and keep quiet now :) cheers James -- -- James Mills -- -- "Problems are solved by method" From solipsis at pitrou.net Mon Feb 14 00:16:05 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 14 Feb 2011 00:16:05 +0100 Subject: [Python-Dev] Rights on the tracker References: <4D57EEE5.9040904@notmyidea.org> Message-ID: <20110214001605.42150d08@pitrou.net> On Sun, 13 Feb 2011 14:47:01 +0000 Alexis M?taireau wrote: > > * Is it possible to give me the rights to edit the reports for the > distutils2 component ? Done. Actually, you have general developer rights, since there doesn't seem to be a way (in the GUI) to restrict those to a specific component. > * Is it possible to automatically be in the noisy list for distutils2' > bug reports ? Someone else with the right knowledge and power will have to do that. Regards Antoine. From alexis at notmyidea.org Mon Feb 14 00:50:08 2011 From: alexis at notmyidea.org (=?ISO-8859-1?Q?Alexis_M=E9taireau?=) Date: Sun, 13 Feb 2011 23:50:08 +0000 Subject: [Python-Dev] Rights on the tracker In-Reply-To: <20110214001605.42150d08@pitrou.net> References: <4D57EEE5.9040904@notmyidea.org> <20110214001605.42150d08@pitrou.net> Message-ID: <4D586E30.2060306@notmyidea.org> Le 13/02/2011 23:16, Antoine Pitrou a ?crit : > On Sun, 13 Feb 2011 14:47:01 +0000 > Alexis M?taireau wrote: >> >> * Is it possible to give me the rights to edit the reports for the >> distutils2 component ? > > Done. Actually, you have general developer rights, since there doesn't > seem to be a way (in the GUI) to restrict those to a specific component. Thanks ! > Someone else with the right knowledge and power will have to do that. Okay, there is an issue on the tracker's tracker, as ?ric told. Cheers, Alex From tjreedy at udel.edu Mon Feb 14 01:55:06 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Sun, 13 Feb 2011 19:55:06 -0500 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <4D5839DD.5070906@canterbury.ac.nz> <20110213221147.1914.1118758870.divmod.xquotient.59@localhost.localdomain> Message-ID: On 2/13/2011 5:23 PM, Nick Coghlan wrote: > On Mon, Feb 14, 2011 at 8:11 AM, wrote: >> >> Excluding stuff is not hard, seriously. It's not hard to see that wxPython >> integration doesn't belong in the stdlib. There are more useful aspects of >> the task to discuss. > > I think part of the problem is that those of us that aren't Twisted > users aren't familiar enough with it to know which of the elements in > twisted.internet would be important to include in a stdlib "reactor" > package (or whatever it ended up being called). To me, this is what a PEP would be for -- to present a concrete proposal listing inclusions that could be evaluated. The someone familiar with asyncore could compare feature lists to decide if the new module would have everything needed without too much other stuff. -- Terry Jan Reedy From georg at python.org Mon Feb 14 07:40:00 2011 From: georg at python.org (Georg Brandl) Date: Mon, 14 Feb 2011 07:40:00 +0100 Subject: [Python-Dev] [RELEASED] Python 3.2 rc 3 Message-ID: <4D58CE40.1010408@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team, I'm happy to announce the third release candidate of Python 3.2. Python 3.2 is a continuation of the efforts to improve and stabilize the Python 3.x line. Since the final release of Python 2.7, the 2.x line will only receive bugfixes, and new features are developed for 3.x only. Since PEP 3003, the Moratorium on Language Changes, is in effect, there are no changes in Python's syntax and built-in types in Python 3.2. Development efforts concentrated on the standard library and support for porting code to Python 3. Highlights are: * numerous improvements to the unittest module * PEP 3147, support for .pyc repository directories * PEP 3149, support for version tagged dynamic libraries * PEP 3148, a new futures library for concurrent programming * PEP 384, a stable ABI for extension modules * PEP 391, dictionary-based logging configuration * an overhauled GIL implementation that reduces contention * an extended email package that handles bytes messages * a much improved ssl module with support for SSL contexts and certificate hostname matching * a sysconfig module to access configuration information * additions to the shutil module, among them archive file support * many enhancements to configparser, among them mapping protocol support * improvements to pdb, the Python debugger * countless fixes regarding bytes/string issues; among them full support for a bytes environment (filenames, environment variables) * many consistency and behavior fixes for numeric operations For a more extensive list of changes in 3.2, see http://docs.python.org/3.2/whatsnew/3.2.html To download Python 3.2 visit: http://www.python.org/download/releases/3.2/ Please consider trying Python 3.2 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.2's contributors) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk1YzkAACgkQN9GcIYhpnLAggwCfQ92djMinrmNkGI4Ma3VRqrcX EWIAn16kTEJtvEH/7DJApp7YdhnmIRBd =NJ1B -----END PGP SIGNATURE----- From victor.stinner at haypocalc.com Mon Feb 14 11:05:52 2011 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Mon, 14 Feb 2011 11:05:52 +0100 Subject: [Python-Dev] [RELEASED] Python 3.2 rc 3 In-Reply-To: <4D58CE40.1010408@python.org> References: <4D58CE40.1010408@python.org> Message-ID: <1297677952.15296.60.camel@marge> Le lundi 14 f?vrier 2011 ? 07:40 +0100, Georg Brandl a ?crit : > On behalf of the Python development team, I'm happy to announce > the third release candidate of Python 3.2. Oh, the RC3 changelog is still very long. And sorry, because I contributed to this long list of changes! I hope that the list will be shorter for the final version. I don't have any pending patch :-) Victor From list at qtrac.plus.com Mon Feb 14 12:58:42 2011 From: list at qtrac.plus.com (Mark Summerfield) Date: Mon, 14 Feb 2011 11:58:42 +0000 Subject: [Python-Dev] [python-committers] [RELEASED] Python 3.2 rc 3 In-Reply-To: <4D58CE40.1010408@python.org> References: <4D58CE40.1010408@python.org> Message-ID: <20110214115842.3c98a68e@dino> On Mon, 14 Feb 2011 07:40:00 +0100 Georg Brandl wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On behalf of the Python development team, I'm happy to announce > the third release candidate of Python 3.2. > > Python 3.2 is a continuation of the efforts to improve and stabilize > the Python 3.x line. Since the final release of Python 2.7, the 2.x > line will only receive bugfixes, and new features are developed for > 3.x only. [snip] It looks good:-) V. small suggestion: how about putting the "New, Improved, and Deprecated Modules" in What's New in alphabetical order? -- Mark Summerfield, Qtrac Ltd, www.qtrac.eu C++, Python, Qt, PyQt - training and consultancy Programming in Python 3" - ISBN 0321680561 http://www.qtrac.eu/py3book.html From g.rodola at gmail.com Mon Feb 14 13:18:55 2011 From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=) Date: Mon, 14 Feb 2011 13:18:55 +0100 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <1297608661.3802.25.camel@localhost.localdomain> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> <20110213152338.46eb689b@pitrou.net> <4D57EB70.8080600@voidspace.org.uk> <1297608661.3802.25.camel@localhost.localdomain> Message-ID: 2011/2/13 Antoine Pitrou : > >> It would then be subject to python-dev development policy rather than >> twisted dev policy (which is even stricter!). Would the twisted devs >> *really* want that? We could use the same processes we have for >> "externally maintained" libraries, but they have without fail caused us >> problems. > > Oh, I agree with you. -1 on any new externally maintained library. > >> The other issue is that just because we provide an alternative doesn't >> mean that everyone automatically stops using asyncore and migrates. > > Of course. asyncore's problem is not that its a maintenance burden, it's > that it's really subpar compared to everything else out there. > That said, Giampaolo has committed to taking it forward, so perhaps the > 3.3 version of asyncore will be much (?) better. I must say that asyncore can surely be improved but not so that it can reach the flexibility offered by Twisted. Or at least, not without changing some aspects of the current API and break backward compatibility. I'll try to summarize what I think is wrong with asyncore so that maybe someone can chime in and propose ideas. Guido was right when he stated that providing a future-proof and maximally flexible design of such an API is not easy, and this is exactly the problem with asyncore. It provides a subclass-based API which doesn't work well in all those cases where I want to mix different functionallities as in: - I want a base TCP dispatcher - ...with buffered output capabilities a-la asynchat - ...which is able to limit the speed for incoming data - ...and that can also switch to SSL Although I don't use it, it seems that Twisted managed to do this by splitting the concepts of "transport" and "protocol" / "application" and by using zope.interface. At the current state, asyncore is not able to do this flexibly. It should at least separate transport and protocol, but again, I can't imagine how exactly and it would surely have a cost in terms of backward compatibility. Another problem is that asyncore is pretty low-level, and this is why the outcome is a code which looks monkey patched. Where Twisted provides a dataReceived() method, asyncore provides handle_read(): the user is supposed to override handle_read() and manually call recv() which might either fail (e.g. "retry later" or "disconnected") or succeed. The same applies for all other aspects of a TCP connection: handle_accept() -> accept(), handle_connect() -> connect() and handle_write -> send(). They all might fail and all need to be handled with care individually (see for example: http://bugs.python.org/issue6706 ). This aspect might be mitigated by providing a serie of higher lever classes (e.g. TCPServer, UDPServer, TCPConnection, UDPConnection, SSLTCPConnection) providing an API similar to: http://twistedmatrix.com/documents/8.2.0/api/twisted.internet.interfaces.IProtocol.html ...but the need of a separation between transport and protocol layers is still needed. Last but not least, the asyncore "reactor" (asyncore.loop()) is not tied with the dispatcher. >From the dispatcher we have no reference to the reactor, hence we cannot register/unregister file descriptors, forcing the main loop to iterate over all dispatcher instances and making impossible to benefit of epoll() and kqueue(), which are crucial for scalable servers handling thousands simultaneous requests: http://bugs.python.org/issue6692 As for what we can *currently* do without going into too much trouble I can mention: http://bugs.python.org/issue10084 http://bugs.python.org/issue1641 As for Twisted core, I think it would be a nice addition for the stdlib, but for me it should also fit one crucial requirement: it should be *simple* and reflect the simplicity and "taste" of all other stdlib modules, and to fulfill such a requirement I think Twisted probably needs to be "adapted" a bit. The main reason why I decided to use asyncore is that, despite it's huge gaps and lack of base functionnalities, I can read its source code, understand what's going on and extend it via monkey patching. It might seem a poor approach but it worked for me and couldn't do the same when I tried to use Twisted. Regards, --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ From rdmurray at bitdance.com Mon Feb 14 14:48:38 2011 From: rdmurray at bitdance.com (R. David Murray) Date: Mon, 14 Feb 2011 08:48:38 -0500 Subject: [Python-Dev] Rights on the tracker In-Reply-To: <20110214001605.42150d08@pitrou.net> References: <4D57EEE5.9040904@notmyidea.org> <20110214001605.42150d08@pitrou.net> Message-ID: <20110214134838.5DBBD236C65@kimball.webabinitio.net> On Mon, 14 Feb 2011 00:16:05 +0100, Antoine Pitrou wrote: > On Sun, 13 Feb 2011 14:47:01 +0000 Alexis M??taireau wrote: > > * Is it possible to automatically be in the noisy list for distutils2' > > bug reports ? > > Someone else with the right knowledge and power will have to do that. Done. I hope. This is the first one we (currently) have where more than one person is being auto-nosied, so I hope I got the syntax right. Someone should test it. This is separate from the meta-tracker issue ??ric mentioned, it applies only to issues where the distutils2 component is newly added. (Antoine: FYI, the place this is edited is http://bugs.python.org/component, and I don't know anything more than what is explained on that scree :). -- R. David Murray www.bitdance.com From janssen at parc.com Mon Feb 14 21:08:25 2011 From: janssen at parc.com (Bill Janssen) Date: Mon, 14 Feb 2011 12:08:25 PST Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: Message-ID: <85871.1297714105@parc.com> Giampaolo Rodol? wrote: > Although I don't use it, it seems that Twisted managed to do this by > splitting the concepts of "transport" and "protocol" / "application" > and by using zope.interface. You might want to look at the ILU core, too, just for ideas. Somewhat to my surprise, the link http://www2.parc.com/istl/projects/ILU/ still works. The protocol/transport distinction is at . The key requirements for an async loop, IMO, are the normal file descriptor state change notifications, support for timer events, and support for time-bounded work tasks (that get run when nothing is happening). The Tornado IOLoop does all three of these; also worth taking a look at: . Bill From greg.ewing at canterbury.ac.nz Mon Feb 14 23:15:59 2011 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Tue, 15 Feb 2011 11:15:59 +1300 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: References: <20110211130418.5D6F4EE9CE@mail.python.org> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> <20110213152338.46eb689b@pitrou.net> <4D57EB70.8080600@voidspace.org.uk> <1297608661.3802.25.camel@localhost.localdomain> Message-ID: <4D59A99F.90106@canterbury.ac.nz> Giampaolo Rodol? wrote: > for me it should also fit one crucial requirement: it > should be *simple* and reflect the simplicity and "taste" of all other > stdlib modules, and to fulfill such a requirement I think Twisted > probably needs to be "adapted" a bit. My thoughts exactly -- from a bird's eye view, Twisted appears to be very far from simple. While there may be some good ideas to adopt from it, I suspect that finding them will require just as much careful thought as designing an API from scratch. -- Greg From martin at v.loewis.de Mon Feb 14 23:21:15 2011 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 14 Feb 2011 23:21:15 +0100 Subject: [Python-Dev] Rights on the tracker In-Reply-To: <20110214134838.5DBBD236C65@kimball.webabinitio.net> References: <4D57EEE5.9040904@notmyidea.org> <20110214001605.42150d08@pitrou.net> <20110214134838.5DBBD236C65@kimball.webabinitio.net> Message-ID: <4D59AADB.1070109@v.loewis.de> > Done. I hope. This is the first one we (currently) have where more > than one person is being auto-nosied, so I hope I got the syntax right. It should be fine: roundup_tracker=> select * from component_add_as_nosy where nodeid = 25; linkid | nodeid --------+-------- 7641 | 25 12434 | 25 (2 Zeilen) It might still be useful to test it, since actually evaluating the property might also go wrong, but that should be fine as well: for component in components: users = db.component.get(component, 'add_as_nosy') nosy |= set(users) Regards, Martin From exarkun at twistedmatrix.com Tue Feb 15 01:45:21 2011 From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com) Date: Tue, 15 Feb 2011 00:45:21 -0000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <4D59A99F.90106@canterbury.ac.nz> References: <20110211130418.5D6F4EE9CE@mail.python.org> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> <20110213152338.46eb689b@pitrou.net> <4D57EB70.8080600@voidspace.org.uk> <1297608661.3802.25.camel@localhost.localdomain> <4D59A99F.90106@canterbury.ac.nz> Message-ID: <20110215004521.1914.1113086733.divmod.xquotient.82@localhost.localdomain> On 14 Feb, 10:15 pm, greg.ewing at canterbury.ac.nz wrote: >Giampaolo Rodol? wrote: >>for me it should also fit one crucial requirement: it >>should be *simple* and reflect the simplicity and "taste" of all other >>stdlib modules, and to fulfill such a requirement I think Twisted >>probably needs to be "adapted" a bit. > >My thoughts exactly -- from a bird's eye view, Twisted appears >to be very far from simple. While there may be some good ideas >to adopt from it, I suspect that finding them will require just >as much careful thought as designing an API from scratch. Can you try to be more constructive? Generalizations like this don't help the process at all. They don't explain why Twisted's APIs shouldn't be adopted in the stdlib and they don't explain what APIs _should_ be adopted. It's basically just stop energy. I'm not picking on Giampaolo because despite the small portion of his message you quoted, his full email actually contained quite a bit of useful technical information. It wasn't just an unsupported snipe. As far as the difficulties of "finding" the good ideas in Twisted goes, there are several people familiar with Twisted already contributing to this thread. Between us all, I'm sure we can dig out the insidiously buried secrets. As I mentioned before, I've also started a PEP myself to lay bare the mysteries. I may try working on it some more, since there seems to be some interest. Jean-Paul From eric at trueblade.com Tue Feb 15 01:52:59 2011 From: eric at trueblade.com (Eric Smith) Date: Mon, 14 Feb 2011 19:52:59 -0500 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <4D59A99F.90106@canterbury.ac.nz> References: <20110211130418.5D6F4EE9CE@mail.python.org> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> <20110213152338.46eb689b@pitrou.net> <4D57EB70.8080600@voidspace.org.uk> <1297608661.3802.25.camel@localhost.localdomain> <4D59A99F.90106@canterbury.ac.nz> Message-ID: <4D59CE6B.7010400@trueblade.com> On 2/14/2011 5:15 PM, Greg Ewing wrote: > Giampaolo Rodol? wrote: > >> for me it should also fit one crucial requirement: it >> should be *simple* and reflect the simplicity and "taste" of all other >> stdlib modules, and to fulfill such a requirement I think Twisted >> probably needs to be "adapted" a bit. > > My thoughts exactly -- from a bird's eye view, Twisted appears > to be very far from simple. While there may be some good ideas > to adopt from it, I suspect that finding them will require just > as much careful thought as designing an API from scratch. I find this hard to believe, given the brainpower behind Twisted and the willingness of the Twisted devs to help with this. Starting from scratch seems like a very bad idea. From stutzbach at google.com Tue Feb 15 02:09:22 2011 From: stutzbach at google.com (Daniel Stutzbach) Date: Mon, 14 Feb 2011 17:09:22 -0800 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> Message-ID: On Sat, Feb 12, 2011 at 8:20 PM, wrote: > What part do you think is a hard problem? Convincing people to switch to a > new API? > I think the hard parts is coming up with an API that's simple enough to learn quickly but powerful enough for to cover most use-cases and cleanly extendable to cover use-cases we haven't thought of. If we go with something based on or inspired by Twisted, that solves some problems, but creates others. Will users be able to later migrate to using Twisted proper? Will the standard library module and Twisted go out of sync? What happens if a user tries to use both the standard library module and Twisted? Please understand that I'm not saying these are insurmountable problems. I'm just suggesting things that might be good to address in a PEP. > *Defining* the new API doesn't seem very hard to me. > If you have the skills and experience so that designing a async API is not as hard for you, please run with it. :-) Personally, I would love to see asyncore deprecated in favor of something better. -- Daniel Stutzbach -------------- next part -------------- An HTML attachment was scrubbed... URL: From prologic at shortcircuit.net.au Tue Feb 15 02:15:52 2011 From: prologic at shortcircuit.net.au (James Mills) Date: Tue, 15 Feb 2011 11:15:52 +1000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <20110215004521.1914.1113086733.divmod.xquotient.82@localhost.localdomain> References: <20110211130418.5D6F4EE9CE@mail.python.org> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> <20110213152338.46eb689b@pitrou.net> <4D57EB70.8080600@voidspace.org.uk> <1297608661.3802.25.camel@localhost.localdomain> <4D59A99F.90106@canterbury.ac.nz> <20110215004521.1914.1113086733.divmod.xquotient.82@localhost.localdomain> Message-ID: On Tue, Feb 15, 2011 at 10:45 AM, wrote: > As far as the difficulties of "finding" the good ideas in Twisted goes, > there are several people familiar with Twisted already contributing to this > thread. ?Between us all, I'm sure we can dig out the insidiously buried > secrets. ?As I mentioned before, I've also started a PEP myself to lay bare > the mysteries. ?I may try working on it some more, since there seems to be > some interest. So far in this discussion (I'm not really contributing very much) I agree with several things: a) We should have a PEP outlining the proposed new "async" lib. b) It should be general purpose enough to use without Twisted (for example) I like the idea of having an "async" core in the std. lib that takes care of cross-platform polling of I/O descriptors, notifications and timers. cheers James -- -- James Mills -- -- "Problems are solved by method" From prologic at shortcircuit.net.au Tue Feb 15 02:18:00 2011 From: prologic at shortcircuit.net.au (James Mills) Date: Tue, 15 Feb 2011 11:18:00 +1000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: References: <20110211130418.5D6F4EE9CE@mail.python.org> <1297434481.3175.6.camel@marge> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> Message-ID: On Tue, Feb 15, 2011 at 11:09 AM, Daniel Stutzbach wrote: > If we go with something based on or inspired by Twisted, that solves some > problems, but creates others. ?Will users be able to later migrate to using > Twisted proper? ?Will the standard library module and Twisted go out of > sync? ?What happens if a user tries to use both the standard library module > and Twisted? Or any other async / application framework. --JamesMills From p.f.moore at gmail.com Tue Feb 15 08:54:40 2011 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 15 Feb 2011 07:54:40 +0000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: <20110215004521.1914.1113086733.divmod.xquotient.82@localhost.localdomain> References: <20110211130418.5D6F4EE9CE@mail.python.org> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> <20110213152338.46eb689b@pitrou.net> <4D57EB70.8080600@voidspace.org.uk> <1297608661.3802.25.camel@localhost.localdomain> <4D59A99F.90106@canterbury.ac.nz> <20110215004521.1914.1113086733.divmod.xquotient.82@localhost.localdomain> Message-ID: On 15 February 2011 00:45, wrote: > As far as the difficulties of "finding" the good ideas in Twisted goes, > there are several people familiar with Twisted already contributing to this > thread. ?Between us all, I'm sure we can dig out the insidiously buried > secrets. ?As I mentioned before, I've also started a PEP myself to lay bare > the mysteries. ?I may try working on it some more, since there seems to be > some interest. FWIW, I am +1 on seeing a PEP for a twisted-based async framework. Probably targeted at 3.3, that should be plenty of time. I'd like it to be upward compatible with Twisted proper. If I'm expanding the scope of my code anywhere, it will be to full twisted, and I'd rather not have to rewrite what's already there. I've no reason to criticise any of the other async frameworks out there, but it seems clear to me that Twisted is well established as the "best of breed" in this area. The PEP should address what will happen with the dependency on zope.interface. Getting interfaces into the stdlib has *also* been discussed often in the past, and has never happened. It might even be contentious enough to warrant a second sub-PEP covering just that area. While I'm sure there's still plenty of technical issues we can cover in this thread, I think that a PEP would focus discussion a lot more clearly. Paul. From martin at v.loewis.de Tue Feb 15 09:30:08 2011 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 15 Feb 2011 09:30:08 +0100 Subject: [Python-Dev] svn outage on Friday Message-ID: <4D5A3990.4040902@v.loewis.de> I'm going to perform a Debian upgrade of svn.python.org on Friday, between 9:00 UTC and 11:00 UTC. I'll be disabling write access during that time. The outage shouldn't be longer than an hour. Regards, Martin From victor.stinner at haypocalc.com Tue Feb 15 10:25:06 2011 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Tue, 15 Feb 2011 10:25:06 +0100 Subject: [Python-Dev] svn outage on Friday In-Reply-To: <4D5A3990.4040902@v.loewis.de> References: <4D5A3990.4040902@v.loewis.de> Message-ID: <1297761906.31674.0.camel@marge> Le mardi 15 f?vrier 2011 ? 09:30 +0100, "Martin v. L?wis" a ?crit : > I'm going to perform a Debian upgrade of svn.python.org on Friday, > between 9:00 UTC and 11:00 UTC. I'll be disabling write access during > that time. The outage shouldn't be longer than an hour. It's time to move to Mercurial! :-) Victor From phd at phdru.name Tue Feb 15 10:32:12 2011 From: phd at phdru.name (Oleg Broytman) Date: Tue, 15 Feb 2011 12:32:12 +0300 Subject: [Python-Dev] svn outage on Friday In-Reply-To: <1297761906.31674.0.camel@marge> References: <4D5A3990.4040902@v.loewis.de> <1297761906.31674.0.camel@marge> Message-ID: <20110215093210.GA25546@iskra.aviel.ru> On Tue, Feb 15, 2011 at 10:25:06AM +0100, Victor Stinner wrote: > Le mardi 15 f??vrier 2011 ?? 09:30 +0100, "Martin v. L??wis" a ??crit : > > I'm going to perform a Debian upgrade of svn.python.org on Friday, > > between 9:00 UTC and 11:00 UTC. I'll be disabling write access during > > that time. The outage shouldn't be longer than an hour. > > It's time to move to Mercurial! :-) Never do two upgrades at once! Especially on Fridays! Oleg. -- Oleg Broytman http://phdru.name/ phd at phdru.name Programmers don't die, they just GOSUB without RETURN. From ncoghlan at gmail.com Tue Feb 15 13:52:18 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Tue, 15 Feb 2011 22:52:18 +1000 Subject: [Python-Dev] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py In-Reply-To: References: <20110211130418.5D6F4EE9CE@mail.python.org> <4D57075A.1050108@canterbury.ac.nz> <20110212232846.35b55400@pitrou.net> <4D570DCC.5030903@canterbury.ac.nz> <20110212231046.1914.794875934.divmod.xquotient.50@localhost.localdomain> <20110213002258.1914.2047194157.divmod.xquotient.53@localhost.localdomain> <20110213042059.1914.1174135786.divmod.xquotient.57@localhost.localdomain> <20110213152338.46eb689b@pitrou.net> <4D57EB70.8080600@voidspace.org.uk> <1297608661.3802.25.camel@localhost.localdomain> <4D59A99F.90106@canterbury.ac.nz> <20110215004521.1914.1113086733.divmod.xquotient.82@localhost.localdomain> Message-ID: On Tue, Feb 15, 2011 at 5:54 PM, Paul Moore wrote: > The PEP should address what will happen with the dependency on > zope.interface. Getting interfaces into the stdlib has *also* been > discussed often in the past, and has never happened. It might even be > contentious enough to warrant a second sub-PEP covering just that > area. The equivalent functionality was subsumed by the inclusion of ABC support (which is what a "standalone" core event loop should probably use instead of zope interfaces). Definitely a PEP worth pursuing. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From benjamin at python.org Tue Feb 15 15:03:16 2011 From: benjamin at python.org (Benjamin Peterson) Date: Tue, 15 Feb 2011 08:03:16 -0600 Subject: [Python-Dev] svn outage on Friday In-Reply-To: <1297761906.31674.0.camel@marge> References: <4D5A3990.4040902@v.loewis.de> <1297761906.31674.0.camel@marge> Message-ID: 2011/2/15 Victor Stinner : > Le mardi 15 f?vrier 2011 ? 09:30 +0100, "Martin v. L?wis" a ?crit : >> I'm going to perform a Debian upgrade of svn.python.org on Friday, >> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during >> that time. The outage shouldn't be longer than an hour. > > It's time to move to Mercurial! :-) And doubtless there will be times when Mercurial must be upgraded, too... -- Regards, Benjamin From john.arbash.meinel at gmail.com Tue Feb 15 17:32:25 2011 From: john.arbash.meinel at gmail.com (John Arbash Meinel) Date: Tue, 15 Feb 2011 10:32:25 -0600 Subject: [Python-Dev] svn outage on Friday In-Reply-To: References: <4D5A3990.4040902@v.loewis.de> <1297761906.31674.0.camel@marge> Message-ID: <4D5AAA99.8010600@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/15/2011 8:03 AM, Benjamin Peterson wrote: > 2011/2/15 Victor Stinner : >> Le mardi 15 f?vrier 2011 ? 09:30 +0100, "Martin v. L?wis" a ?crit : >>> I'm going to perform a Debian upgrade of svn.python.org on Friday, >>> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during >>> that time. The outage shouldn't be longer than an hour. >> >> It's time to move to Mercurial! :-) > > And doubtless there will be times when Mercurial must be upgraded, too... > True, but on those days you just keep committing locally... John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1aqpkACgkQJdeBCYSNAAMW3gCgt/Ea75R/HfKM4KlmGmCmfjtL BBYAoI89GYsxrsa4/Eefifg3i6+Euv+T =Kz3A -----END PGP SIGNATURE----- From techtonik at gmail.com Wed Feb 16 11:51:21 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Wed, 16 Feb 2011 12:51:21 +0200 Subject: [Python-Dev] python 3.2 (fwd) In-Reply-To: <4D52E93F.3020108@udel.edu> References: <19794.53174.766166.195523@montanaro.dyndns.org> <4D52E93F.3020108@udel.edu> Message-ID: On Wed, Feb 9, 2011 at 9:21 PM, Terry Reedy wrote: > On 2/9/2011 12:32 PM, skip at pobox.com wrote: >> >> Passing this along from webmaster. > > It is hard to reply to an attachment rather than inline forwarded message. > ?However, with rc1 > >>>> import sqlite3 >>>> sqlite3.version > '2.6.0' >>>> sqlite3.sqlite_version > '3.7.4' That's not intuitive. It is better to point sqlite3.version to the actual version of sqlite3 used. -- anatoly t. From techtonik at gmail.com Wed Feb 16 11:53:34 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Wed, 16 Feb 2011 12:53:34 +0200 Subject: [Python-Dev] devguide: Fix a silly statement. In-Reply-To: References: Message-ID: On Thu, Feb 10, 2011 at 10:08 PM, Georg Brandl wrote: > Am 10.02.2011 19:27, schrieb Brett Cannon: >> On Wed, Feb 9, 2011 at 23:10, Georg Brandl wrote: >>> Am 09.02.2011 23:58, schrieb brett.cannon: >>>> brett.cannon pushed 7101df1bd817 to devguide: >>>> >>>> http://hg.python.org/devguide/rev/7101df1bd817 >>>> changeset: ? 291:7101df1bd817 >>>> branch: ? ? ?hg_transition >>>> tag: ? ? ? ? tip >>>> user: ? ? ? ?Brett Cannon >>>> date: ? ? ? ?Wed Feb 09 14:58:17 2011 -0800 >>>> summary: >>>> ? Fix a silly statement. >>>> >>>> files: >>>> ? setup.rst >>>> >>>> diff --git a/setup.rst b/setup.rst >>>> --- a/setup.rst >>>> +++ b/setup.rst >>>> @@ -34,8 +34,7 @@ >>>> ?:abbr:`VCS`. It also means you will have better tool >>>> ?support through the VCS as it will provide a diff tool, etc. >>>> >>>> -To get a read-only checkout of CPython's source, you need a working copy the >>>> -source code. To get a read-only checkout of >>>> +To get a read-only checkout of >>>> ?the :ref:`in-development ` branch of Python, run:: >>>> >>>> ? ? ?hg clone http://hg.python.org/cpython >>> >>> This statement is still somewhat silly, as a) you get a clone, not a checkout >>> and b) it is not read only in any way: you can commit just fine. ?The only >>> difference will be the entry in .hg/hgrc pointing the default repo to something >>> you can't push to. >>> >>> Skimming through, the whole section "Checking out the code" is still way too >>> SVN-point of viewy (e.g. you always get all branches anyway). >> >> I'll take another pass, but do realize this needs to be something that >> can easily be understood by someone who has never used hg before, so I >> can't get too technically accurate while ignoring a possible base >> ignorance of hg and DVCSs as a whole. > > Well, it's no good to keep using CVCS terms and mislead users. ?That the > "checkout" is not a checkout but a full repository is about the most important > fact about a hg (or any DVCS) clone. +1 -- anatoly t. From merwok at netwok.org Wed Feb 16 12:05:11 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Wed, 16 Feb 2011 12:05:11 +0100 Subject: [Python-Dev] devguide: Fix a silly statement. In-Reply-To: References: Message-ID: <4D5BAF67.4000406@netwok.org> > Well, it's no good to keep using CVCS terms and mislead users. That the > "checkout" is not a checkout but a full repository is about the most important > fact about a hg (or any DVCS) clone. Well, to really use the Mercurial terms, what you have when you get stuff from a remote server to your disk is a clone, which contains a full repository and may contain a working copy (also called checkout). IOW, ?check out? is used with Mercurial, as a synonym for ?update?, an operation from the (local) repo to the working directory; the CVCS-inspired mistake is to use that to refer to an operation from a remote server to the local disk (?clone?, ?pull?). HTH Regards From merwok at netwok.org Wed Feb 16 12:01:21 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Wed, 16 Feb 2011 12:01:21 +0100 Subject: [Python-Dev] python 3.2 (fwd) In-Reply-To: References: <19794.53174.766166.195523@montanaro.dyndns.org> <4D52E93F.3020108@udel.edu> Message-ID: <4D5BAE81.5050709@netwok.org> >>>>> import sqlite3 >>>>> sqlite3.version >> '2.6.0' >>>>> sqlite3.sqlite_version >> '3.7.4' > > That's not intuitive. It is better to point sqlite3.version to the > actual version of sqlite3 used. We can?t break compatibility for such a small thing. However, it should be documented in http://docs.python.org/dev/library/sqlite3#module-functions-and-constants Could you report the bug? Thanks in advance. Regards From tjreedy at udel.edu Wed Feb 16 18:34:00 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 16 Feb 2011 12:34:00 -0500 Subject: [Python-Dev] 3.2.0 Message-ID: I would like the next release called 3.2.0 rather than just 3.2. 'x.y' is known to be ambiguous and confusing. In most actual usages, I believe, it refers to the latest x.y.z release. On the site, the 'x.y' docs are almost always the latest version of the docs (actually x.y.z+additional fixes). In discussions on python-list, for instance, advice to use 'x.y' means to download and use the latest x.y.z release, not the initial x.y(.0) release. Similarly on the tracker, 'what happens with x.y' means the same. So the alternate use of 'x.y' to mean x.y(.0) is both confusing and correctable, at least for the future. -- Terry Jan Reedy From brett at python.org Wed Feb 16 19:52:16 2011 From: brett at python.org (Brett Cannon) Date: Wed, 16 Feb 2011 10:52:16 -0800 Subject: [Python-Dev] 3.2.0 In-Reply-To: References: Message-ID: On Wed, Feb 16, 2011 at 09:34, Terry Reedy wrote: > I would like the next release called 3.2.0 rather than just 3.2. > > 'x.y' is known to be ambiguous and confusing. > > In most actual usages, I believe, it refers to the latest x.y.z release. On > the site, the 'x.y' docs are almost always the latest version of the docs > (actually x.y.z+additional fixes). In discussions on python-list, for > instance, advice to use 'x.y' means to download and use the latest x.y.z > release, not the initial x.y(.0) release. Similarly on the tracker, 'what > happens with x.y' means the same. > > So the alternate use of 'x.y' to mean x.y(.0) is both confusing and > correctable, at least for the future. With all of the writing I have been doing recently, I agree that disambiguating 3.2.0 from 3.2 is a good thing. From barry at python.org Wed Feb 16 20:05:52 2011 From: barry at python.org (Barry Warsaw) Date: Wed, 16 Feb 2011 14:05:52 -0500 Subject: [Python-Dev] 3.2.0 In-Reply-To: References: Message-ID: <20110216140552.3eb0ddda@python.org> On Feb 16, 2011, at 12:34 PM, Terry Reedy wrote: >I would like the next release called 3.2.0 rather than just 3.2. +1 (I'd have said +0 for the humor of it :). -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From ncoghlan at gmail.com Wed Feb 16 23:39:55 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 17 Feb 2011 08:39:55 +1000 Subject: [Python-Dev] 3.2.0 In-Reply-To: <20110216140552.3eb0ddda@python.org> References: <20110216140552.3eb0ddda@python.org> Message-ID: On Thu, Feb 17, 2011 at 5:05 AM, Barry Warsaw wrote: > On Feb 16, 2011, at 12:34 PM, Terry Reedy wrote: > >>I would like the next release called 3.2.0 rather than just 3.2. > > +1 > > (I'd have said +0 for the humor of it :). +0 I actually *am* only +0, since I like the idea in principle, but it is Georg, Ronald and Martin that would need to do the work, and I'm not sure it's a great idea to be messing with it a couple of days out from the release. So it may be better to do this for 3.3.0, rather than 3.2.0. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From victor.stinner at haypocalc.com Wed Feb 16 23:43:04 2011 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Wed, 16 Feb 2011 23:43:04 +0100 Subject: [Python-Dev] 3.2.0 In-Reply-To: <20110216140552.3eb0ddda@python.org> References: <20110216140552.3eb0ddda@python.org> Message-ID: <1297896184.5710.7.camel@marge> Le mercredi 16 f?vrier 2011 ? 14:05 -0500, Barry Warsaw a ?crit : > On Feb 16, 2011, at 12:34 PM, Terry Reedy wrote: > > >I would like the next release called 3.2.0 rather than just 3.2. > > +1 > > (I'd have said +0 for the humor of it :). Should we write +1.0, +1.000000003 or just +1? Mark can maybe help us on this question. Victor From anikom15 at gmail.com Thu Feb 17 00:33:58 2011 From: anikom15 at gmail.com (Westley =?ISO-8859-1?Q?Mart=EDnez?=) Date: Wed, 16 Feb 2011 15:33:58 -0800 Subject: [Python-Dev] 3.2.0 In-Reply-To: References: Message-ID: <1297899238.5832.2.camel@localhost.localdomain> On Wed, 2011-02-16 at 12:34 -0500, Terry Reedy wrote: > I would like the next release called 3.2.0 rather than just 3.2. - -1 From raymond.hettinger at gmail.com Thu Feb 17 03:08:17 2011 From: raymond.hettinger at gmail.com (Raymond Hettinger) Date: Wed, 16 Feb 2011 18:08:17 -0800 Subject: [Python-Dev] 3.2.0 In-Reply-To: References: <20110216140552.3eb0ddda@python.org> Message-ID: On Feb 16, 2011, at 2:39 PM, Nick Coghlan wrote: > On Thu, Feb 17, 2011 at 5:05 AM, Barry Warsaw wrote: >> On Feb 16, 2011, at 12:34 PM, Terry Reedy wrote: >> >>> I would like the next release called 3.2.0 rather than just 3.2. >> >> +1 >> >> (I'd have said +0 for the humor of it :). > > +0 > > I actually *am* only +0, since I like the idea in principle, but it is > Georg, Ronald and Martin that would need to do the work, and I'm not > sure it's a great idea to be messing with it a couple of days out from > the release. So it may be better to do this for 3.3.0, rather than > 3.2.0. The basic idea is reasonable, but it's a little late in the game to make any changes. This is ready to ship and we're doing our best to make no changes at all to RC3. The web page and announcement can say 3.2.0 but I'm opposed to changing anything in the release at this point. We have some real bugfixes that we're delaying until 3.2.1, so why would we make an exception for a non-essential changes such as this. Raymond From tjreedy at udel.edu Thu Feb 17 04:45:03 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 16 Feb 2011 22:45:03 -0500 Subject: [Python-Dev] 3.2.0 In-Reply-To: References: <20110216140552.3eb0ddda@python.org> Message-ID: On 2/16/2011 5:39 PM, Nick Coghlan wrote: > On Thu, Feb 17, 2011 at 5:05 AM, Barry Warsaw wrote: >> On Feb 16, 2011, at 12:34 PM, Terry Reedy wrote: >> >>> I would like the next release called 3.2.0 rather than just 3.2. >> >> +1 >> >> (I'd have said +0 for the humor of it :). > > +0 > > I actually *am* only +0, since I like the idea in principle, but it is > Georg, Ronald and Martin that would need to do the work, and I'm not > sure it's a great idea to be messing with it a couple of days out from > the release. So it may be better to do this for 3.3.0, rather than > 3.2.0. My immediate suggestion is predicated on the assumption that it would be easy and safe to change '3.2rc2' in the various places it appears to '3.2.0' instead of '3.2'. If that is not true, then my suggestion is that after 3.2 is released, that trunk be regarded as 3.3.0a0 rather than 3.3a0 as soon as it make any difference anywhere. -- Terry Jan Reedy From g.brandl at gmx.net Thu Feb 17 07:07:52 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Thu, 17 Feb 2011 07:07:52 +0100 Subject: [Python-Dev] 3.2.0 In-Reply-To: References: <20110216140552.3eb0ddda@python.org> Message-ID: Am 17.02.2011 03:08, schrieb Raymond Hettinger: > > On Feb 16, 2011, at 2:39 PM, Nick Coghlan wrote: > >> On Thu, Feb 17, 2011 at 5:05 AM, Barry Warsaw wrote: >>> On Feb 16, 2011, at 12:34 PM, Terry Reedy wrote: >>> >>>> I would like the next release called 3.2.0 rather than just 3.2. >>> >>> +1 >>> >>> (I'd have said +0 for the humor of it :). >> >> +0 >> >> I actually *am* only +0, since I like the idea in principle, but it is >> Georg, Ronald and Martin that would need to do the work, and I'm not >> sure it's a great idea to be messing with it a couple of days out from >> the release. So it may be better to do this for 3.3.0, rather than >> 3.2.0. > > The basic idea is reasonable, but it's a little late in the game to make > any changes. This is ready to ship and we're doing our best > to make no changes at all to RC3. > > The web page and announcement can say 3.2.0 but I'm opposed to > changing anything in the release at this point. We have some > real bugfixes that we're delaying until 3.2.1, so why would we > make an exception for a non-essential changes such as this. Quite right. I will see where I can put "3.2.0" on the website, but I will not fiddle with the release tools (much of this is automated) at this stage in the process. Georg From orsenthil at gmail.com Thu Feb 17 07:36:11 2011 From: orsenthil at gmail.com (Senthil Kumaran) Date: Thu, 17 Feb 2011 14:36:11 +0800 Subject: [Python-Dev] 3.2.0 In-Reply-To: References: Message-ID: On Thu, Feb 17, 2011 at 1:34 AM, Terry Reedy wrote: > 'x.y' is known to be ambiguous and confusing. Not really. x.y seems to be saying it is a milestone (major release) and we all have got used to that convention. > In most actual usages, I believe, it refers to the latest x.y.z release. On While I agree with all these points, I feel calling the release itself as x.y.0 may be distracting the convention which is being followed so far. So, it is -1 from me. In the mailing list we can say that use the 'latest' of python 2.x version or 'latest' of python 3.x version and on the web-pages, pointers can be properly set to the correct version. -- Senthil From solipsis at pitrou.net Thu Feb 17 12:20:58 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Thu, 17 Feb 2011 12:20:58 +0100 Subject: [Python-Dev] 3.2.0 References: Message-ID: <20110217122058.4b83530c@pitrou.net> On Wed, 16 Feb 2011 10:52:16 -0800 Brett Cannon wrote: > On Wed, Feb 16, 2011 at 09:34, Terry Reedy wrote: > > I would like the next release called 3.2.0 rather than just 3.2. > > > > 'x.y' is known to be ambiguous and confusing. > > > > In most actual usages, I believe, it refers to the latest x.y.z release. On > > the site, the 'x.y' docs are almost always the latest version of the docs > > (actually x.y.z+additional fixes). In discussions on python-list, for > > instance, advice to use 'x.y' means to download and use the latest x.y.z > > release, not the initial x.y(.0) release. Similarly on the tracker, 'what > > happens with x.y' means the same. > > > > So the alternate use of 'x.y' to mean x.y(.0) is both confusing and > > correctable, at least for the future. > > With all of the writing I have been doing recently, I agree that > disambiguating 3.2.0 from 3.2 is a good thing. Agreed. Although better to defer it to 3.3.0 at this point. Regards Antoine. From regebro at gmail.com Thu Feb 17 14:14:41 2011 From: regebro at gmail.com (Lennart Regebro) Date: Thu, 17 Feb 2011 14:14:41 +0100 Subject: [Python-Dev] 3.2.0 In-Reply-To: <20110217122058.4b83530c@pitrou.net> References: <20110217122058.4b83530c@pitrou.net> Message-ID: On Thu, Feb 17, 2011 at 12:20, Antoine Pitrou wrote: > Agreed. Although better to defer it to 3.3.0 at this point. +1.0.0 for that. Yes, it's confusing, but it's going to be even more confusing if it's called 3.2 sometimes and 3.2.0 sometimes. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python3porting.com/ +33 661 58 14 64 From tjreedy at udel.edu Thu Feb 17 18:19:58 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 17 Feb 2011 12:19:58 -0500 Subject: [Python-Dev] 3.2.0 In-Reply-To: References: Message-ID: On 2/17/2011 1:36 AM, Senthil Kumaran wrote: > On Thu, Feb 17, 2011 at 1:34 AM, Terry Reedy wrote: > >> 'x.y' is known to be ambiguous and confusing. > > Not really. Actually, to me, the confusion is slightly worse, and the reason to change slightly stronger, than I initially explained. Python x.y is a version of the *language*. CPython x.y.z is an occasional marked release of an *implementation*. For instance, Python 3.2 is a version of the language and stdlib. It has been pretty well defined since new features were prohibited. The 3.2 docs are the specification of Python 3.2 (with a few CPython-specific notes). The 3.2 docs will be continuously upgraded as deficiencies are noted and fixed. As I understand it, all patches are expected to leave the docs in an improved and buildable state, so that updates can be built and uploaded to the site frequently (daily?). CPython 3.2.0 will be the first 'production' release of the CPython implementation of Python 3.2. It will be one in a series of approximation of an ideal bug-free 'CPython 3.2'. Some have already been released, more will come. Like the docs, the concrete CPython 3.2 codebase will also be continuously upgraded. For various reasons, it will probably not always be buildable on all platforms and not always be production ready. For practical reasons, marked releases will be spaced some months apart. So, for me, Python 3.2 is a now theoritically fixed version of the language. The Python 3.2 docs document that version, but will be upgraded as mistaked, ambiguities, and omissions are found. The CPython 3.2 codebase is an evolving approximation of an ideal bug-free CPython 3.2 (that will never be reached). And CPython 3.2.0 is an early snapshot release of that evolving codebase. -- Terry Jan Reedy From ncoghlan at gmail.com Thu Feb 17 22:56:00 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 18 Feb 2011 07:56:00 +1000 Subject: [Python-Dev] 3.2.0 In-Reply-To: References: Message-ID: On Fri, Feb 18, 2011 at 3:19 AM, Terry Reedy wrote: > Actually, to me, the confusion is slightly worse, and the reason to change > slightly stronger, than I initially explained. Python x.y is a version of > the *language*. CPython x.y.z is an occasional marked release of an > *implementation*. > > For instance, Python 3.2 is a version of the language and stdlib. It has > been pretty well defined since new features were prohibited. > > The 3.2 docs are the specification of Python 3.2 (with a few > CPython-specific notes). The 3.2 docs will be continuously upgraded as > deficiencies are noted and fixed. As I understand it, all patches are > expected to leave the docs in an improved and buildable state, so that > updates can be built and uploaded to the site frequently (daily?). > > CPython 3.2.0 will be the first 'production' release of the CPython > implementation of Python 3.2. It will be one in a series of approximation of > an ideal bug-free 'CPython 3.2'. Some have already been released, more will > come. Like the docs, the concrete CPython 3.2 codebase will also be > continuously upgraded. For various reasons, it will probably not always be > buildable on all platforms and not always be production ready. For practical > reasons, marked releases will be spaced some months apart. > > So, for me, Python 3.2 is a now theoritically fixed version of the language. > The Python 3.2 docs document that version, but will be upgraded as mistaked, > ambiguities, and omissions are found. The CPython 3.2 codebase is an > evolving approximation of an ideal bug-free CPython 3.2 (that will never be > reached). And CPython 3.2.0 is an early snapshot release of that evolving > codebase. I actually agree with this viewpoint, and think it would definitely be a good way to go for 3.3.0. For the 3.2 series, I think living with the ambiguity for another 6 months or so (however long it is until 3.2.1 is released) is the better choice. There are enough parts of the release process that involve the version number that we *really* shouldn't be messing with it during the RC phase. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From ncoghlan at gmail.com Thu Feb 17 23:01:55 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 18 Feb 2011 08:01:55 +1000 Subject: [Python-Dev] 3.2.0 In-Reply-To: References: Message-ID: On Fri, Feb 18, 2011 at 7:56 AM, Nick Coghlan wrote: > For the 3.2 series, I think living with the ambiguity for another 6 > months or so (however long it is until 3.2.1 is released) is the > better choice. There are enough parts of the release process that > involve the version number that we *really* shouldn't be messing with > it during the RC phase. And the number 1 reason I consider messing with the numbering to be a bad idea: >>> "3.2" >= "3.2.0" False >>> (3, 2) >= (3, 2, 0) False If we miss anything, it could easily lead to errors like the two above. I'll grant that it *shouldn't* be any different to what happens when the release version gets bumped to 3.2.1 in the first maintenance release, but I really don't trust "should" all that much in a release management context :) Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From santoso.wijaya at gmail.com Thu Feb 17 23:19:13 2011 From: santoso.wijaya at gmail.com (Santoso Wijaya) Date: Thu, 17 Feb 2011 14:19:13 -0800 Subject: [Python-Dev] svn outage on Friday In-Reply-To: <1297761906.31674.0.camel@marge> References: <4D5A3990.4040902@v.loewis.de> <1297761906.31674.0.camel@marge> Message-ID: Speaking of, what is the current status and timeline on the move to Mercurial? ~/santa On Tue, Feb 15, 2011 at 1:25 AM, Victor Stinner < victor.stinner at haypocalc.com> wrote: > Le mardi 15 f?vrier 2011 ? 09:30 +0100, "Martin v. L?wis" a ?crit : > > I'm going to perform a Debian upgrade of svn.python.org on Friday, > > between 9:00 UTC and 11:00 UTC. I'll be disabling write access during > > that time. The outage shouldn't be longer than an hour. > > It's time to move to Mercurial! :-) > > Victor > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/santoso.wijaya%40gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Thu Feb 17 23:35:30 2011 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 17 Feb 2011 22:35:30 +0000 Subject: [Python-Dev] 3.2.0 In-Reply-To: References: Message-ID: <4D5DA2B2.2030900@voidspace.org.uk> On 17/02/2011 22:01, Nick Coghlan wrote: > On Fri, Feb 18, 2011 at 7:56 AM, Nick Coghlan wrote: >> For the 3.2 series, I think living with the ambiguity for another 6 >> months or so (however long it is until 3.2.1 is released) is the >> better choice. There are enough parts of the release process that >> involve the version number that we *really* shouldn't be messing with >> it during the RC phase. > And the number 1 reason I consider messing with the numbering to be a bad idea: > >>>> "3.2">= "3.2.0" > False >>>> (3, 2)>= (3, 2, 0) > False > > If we miss anything, it could easily lead to errors like the two > above. How are those errors? Surely what matters is that the following *is* True: >>> (3, 2, 0) >= (3, 2) True >>> "3.2.0" >= "3.2" True I'm +1 for the change, but happy for it to happen for 3.3.0 given how close we are to 3.2 release. Michael Foord > I'll grant that it *shouldn't* be any different to what happens > when the release version gets bumped to 3.2.1 in the first maintenance > release, but I really don't trust "should" all that much in a release > management context :) > > Cheers, > Nick. > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From martin at v.loewis.de Fri Feb 18 00:17:32 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Fri, 18 Feb 2011 00:17:32 +0100 Subject: [Python-Dev] svn outage on Friday In-Reply-To: References: <4D5A3990.4040902@v.loewis.de> <1297761906.31674.0.camel@marge> Message-ID: <4D5DAC8C.3030304@v.loewis.de> Am 17.02.2011 23:19, schrieb Santoso Wijaya: > Speaking of, what is the current status and timeline on the move to > Mercurial? I think it's fair to say that the project currently rests, lacking a project lead. The most recent timeline is that conversion should be completed by PyCon, and, failing that, should start at PyCon. Regards, Martin From dirkjan at ochtman.nl Fri Feb 18 08:09:12 2011 From: dirkjan at ochtman.nl (Dirkjan Ochtman) Date: Fri, 18 Feb 2011 08:09:12 +0100 Subject: [Python-Dev] svn outage on Friday In-Reply-To: <4D5DAC8C.3030304@v.loewis.de> References: <4D5A3990.4040902@v.loewis.de> <1297761906.31674.0.camel@marge> <4D5DAC8C.3030304@v.loewis.de> Message-ID: On Fri, Feb 18, 2011 at 00:17, "Martin v. L?wis" wrote: > I think it's fair to say that the project currently rests, lacking > a project lead. The most recent timeline is that conversion should > be completed by PyCon, and, failing that, should start at PyCon. It's not exactly resting; I've been pushing around the cvs2svn-converted tags to get them to behave sensibly, and I've been having good discussions with Antoine and Georg about several things we need to hash out in IRC. Sorry I haven't been doing more progress reports here. But yes, it would be nice if we could actually switch by PyCon, but at the very least there should be a fresh test repo and consensus on most of the workflow issues by PyCon (for those interested who live in Europe, I'm going to be at a hg sprint in Karlsruhe during the PyCon weekend). Cheers, Dirkjan From dirkjan at ochtman.nl Fri Feb 18 14:41:00 2011 From: dirkjan at ochtman.nl (Dirkjan Ochtman) Date: Fri, 18 Feb 2011 14:41:00 +0100 Subject: [Python-Dev] svn outage on Friday In-Reply-To: <4D5A3990.4040902@v.loewis.de> References: <4D5A3990.4040902@v.loewis.de> Message-ID: On Tue, Feb 15, 2011 at 09:30, "Martin v. L?wis" wrote: > I'm going to perform a Debian upgrade of svn.python.org on Friday, > between 9:00 UTC and 11:00 UTC. I'll be disabling write access during > that time. The outage shouldn't be longer than an hour. It seems hg is no longer installed on dinsdale, does that have anything to do with this? Cheers, Dirkjan From techtonik at gmail.com Fri Feb 18 14:41:33 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Fri, 18 Feb 2011 15:41:33 +0200 Subject: [Python-Dev] Actual Mercurial Roadmap for February (Was: svn outage on Friday) Message-ID: On Fri, Feb 18, 2011 at 9:09 AM, Dirkjan Ochtman wrote: > On Fri, Feb 18, 2011 at 00:17, "Martin v. L?wis" wrote: >> I think it's fair to say that the project currently rests, lacking >> a project lead. The most recent timeline is that conversion should >> be completed by PyCon, and, failing that, should start at PyCon. > > It's not exactly resting; I've been pushing around the > cvs2svn-converted tags to get them to behave sensibly, and I've been > having good discussions with Antoine and Georg about several things we > need to hash out in IRC. Sorry I haven't been doing more progress > reports here. Do you have a public list of stuff to be done (i.e. Roadmap)? BTW, what is the size of Mercurial clone for Python repository? -- anatoly t. From techtonik at gmail.com Fri Feb 18 14:44:41 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Fri, 18 Feb 2011 15:44:41 +0200 Subject: [Python-Dev] devguide: Fix a silly statement. In-Reply-To: <4D5BAF67.4000406@netwok.org> References: <4D5BAF67.4000406@netwok.org> Message-ID: On Wed, Feb 16, 2011 at 1:05 PM, ?ric Araujo wrote: >> Well, it's no good to keep using CVCS terms and mislead users. ?That the >> "checkout" is not a checkout but a full repository is about the most important >> fact about a hg (or any DVCS) clone. > > Well, to really use the Mercurial terms, what you have when you get > stuff from a remote server to your disk is a clone, which contains a > full repository and may contain a working copy (also called checkout). And that's the proper way to describe this. > IOW, ?check out? is used with Mercurial, as a synonym for ?update?, an > operation from the (local) repo to the working directory; the > CVCS-inspired mistake is to use that to refer to an operation from a > remote server to the local disk (?clone?, ?pull?). ?HTH Exactly. -- anatoly t. From dirkjan at ochtman.nl Fri Feb 18 15:00:06 2011 From: dirkjan at ochtman.nl (Dirkjan Ochtman) Date: Fri, 18 Feb 2011 15:00:06 +0100 Subject: [Python-Dev] Actual Mercurial Roadmap for February (Was: svn outage on Friday) In-Reply-To: References: Message-ID: On Fri, Feb 18, 2011 at 14:41, anatoly techtonik wrote: > Do you have a public list of stuff to be done (i.e. Roadmap)? > BTW, what is the size of Mercurial clone for Python repository? There is a TODO file in the pymigr repo (though I think that is currently inaccessible). I don't have a recent optimized clone to check the size of, yet. Cheers, Dirkjan From ncoghlan at gmail.com Fri Feb 18 15:47:42 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 19 Feb 2011 00:47:42 +1000 Subject: [Python-Dev] 3.2.0 In-Reply-To: <4D5DA2B2.2030900@voidspace.org.uk> References: <4D5DA2B2.2030900@voidspace.org.uk> Message-ID: On Fri, Feb 18, 2011 at 8:35 AM, Michael Foord wrote: >> And the number 1 reason I consider messing with the numbering to be a bad >> idea: >> >>>>> "3.2">= "3.2.0" >> >> False >>>>> >>>>> (3, 2)>= (3, 2, 0) >> >> False >> >> If we miss anything, it could easily lead to errors like the two >> above. > > How are those errors? ?Surely what matters is that the following *is* True: > >>>> (3, 2, 0) >= (3, 2) > True >>>> "3.2.0" >= "3.2" > True They aren't errors per se, but they're different from the answer you get with a "3.2" or "(3, 2)" on both sides of the equation (as behavioural changes go, such a change is probably a good thing, since it makes naive version checks less likely to break when 3.2.1 hits, but it's a concrete behavioural change in the release that isn't really an option until we start working on 3.3). Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From status at bugs.python.org Fri Feb 18 18:06:52 2011 From: status at bugs.python.org (Python tracker) Date: Fri, 18 Feb 2011 18:06:52 +0100 (CET) Subject: [Python-Dev] Summary of Python tracker Issues Message-ID: <20110218170652.8D9D41D9FD@psf.upfronthosting.co.za> ACTIVITY SUMMARY (2011-02-11 - 2011-02-18) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2655 (+28) closed 20370 (+22) total 23025 (+50) Open issues with patches: 1130 Issues opened (41) ================== #7284: optparse - display version in usage by default http://bugs.python.org/issue7284 reopened by techtonik #11195: next fixer fooled by trailing cheracters http://bugs.python.org/issue11195 opened by piro #11197: information leakage with SimpleHTTPServer http://bugs.python.org/issue11197 opened by brett.cannon #11199: urllib hangs when closing connection http://bugs.python.org/issue11199 opened by rg3 #11200: Addition of abiflags breaks distutils http://bugs.python.org/issue11200 opened by a.badger #11201: Python installation error 2203 http://bugs.python.org/issue11201 opened by corenova #11203: gzip doc is behind http://bugs.python.org/issue11203 opened by teamnoir #11204: re module: strange behaviour of space inside {m, n} http://bugs.python.org/issue11204 opened by sjmachin #11205: Evaluation order of dictionary display is different from refer http://bugs.python.org/issue11205 opened by takayuki #11206: test_readline unconditionally calls clear_history() http://bugs.python.org/issue11206 opened by georg.brandl #11207: Pythong seg fault with PIL/numpy http://bugs.python.org/issue11207 opened by David.Knapp #11210: PyErr_SetFromWindowsErrWithFilenameObject() doesn't exist: rem http://bugs.python.org/issue11210 opened by haypo #11212: Python memory limit on AIX http://bugs.python.org/issue11212 opened by sable #11214: test_asyncore fails on AIX http://bugs.python.org/issue11214 opened by sable #11215: test_fileio error on AIX http://bugs.python.org/issue11215 opened by sable #11216: email.message.Message set_charset does not encode properly? http://bugs.python.org/issue11216 opened by Shay.Rojansky #11217: python-32 not linked in /usr/local/bin in framework builds http://bugs.python.org/issue11217 opened by tloredo #11218: pattern=None when following documentation for load_tests and u http://bugs.python.org/issue11218 opened by gagern #11219: Produce a warning when the license is specified in both the Li http://bugs.python.org/issue11219 opened by kelseyhightower #11222: Python3.2rc3 fails to build on Mac OS X with a non-framework b http://bugs.python.org/issue11222 opened by jszakmeister #11223: interruption of locks by signals not guaranteed when the semap http://bugs.python.org/issue11223 opened by sable #11224: 3.2: tarfile.getmembers causes 100% cpu usage on Windows http://bugs.python.org/issue11224 opened by srid #11225: getcwd fix for NetBSD to handle ERANGE errno http://bugs.python.org/issue11225 opened by njoly #11226: subprocesses experience mysterious delay in receiving stdin EO http://bugs.python.org/issue11226 opened by yaaang #11227: [DOC] asyncore - use 'Host' header in HTTP example http://bugs.python.org/issue11227 opened by sandro.tosi #11229: Make the Mac installer more like the Windows installer http://bugs.python.org/issue11229 opened by rhettinger #11230: "Full unicode import system" not in 3.2 http://bugs.python.org/issue11230 opened by jh45 #11231: bytes() constructor is not correctly documented http://bugs.python.org/issue11231 opened by haypo #11232: asyncore - don't throw a traceback when a client disconnects i http://bugs.python.org/issue11232 opened by sandro.tosi #11233: clarifying Availability: Unix http://bugs.python.org/issue11233 opened by sandro.tosi #11234: Possible error in What's new Python3.2(rc3) documentation (sys http://bugs.python.org/issue11234 opened by chaica_ #11235: Source files with date modifed in 2106 cause OverflowError http://bugs.python.org/issue11235 opened by Guy.Kisel #11236: getpass.getpass does not respond to ctrl-c or ctrl-z http://bugs.python.org/issue11236 opened by valhallasw #11238: sets - refer to sets/frozenset in stdtypes http://bugs.python.org/issue11238 opened by sandro.tosi #11239: regexp-howto - add missing } to metachars http://bugs.python.org/issue11239 opened by sandro.tosi #11240: Running unit tests in a command line tool leads to infinite lo http://bugs.python.org/issue11240 opened by mattchaput #11241: ctypes: subclassing an already subclassed ArrayType generates http://bugs.python.org/issue11241 opened by Steve.Thompson #11242: urllib.request.url_open() doesn't support SSLContext http://bugs.python.org/issue11242 opened by haypo #11243: email/message.py str conversion http://bugs.python.org/issue11243 opened by sdaoden #941346: AIX shared library fix http://bugs.python.org/issue941346 reopened by georg.brandl #1704474: optparse tests fail under Jython http://bugs.python.org/issue1704474 reopened by r.david.murray Most recent 15 issues with no replies (15) ========================================== #11242: urllib.request.url_open() doesn't support SSLContext http://bugs.python.org/issue11242 #11241: ctypes: subclassing an already subclassed ArrayType generates http://bugs.python.org/issue11241 #11239: regexp-howto - add missing } to metachars http://bugs.python.org/issue11239 #11238: sets - refer to sets/frozenset in stdtypes http://bugs.python.org/issue11238 #11229: Make the Mac installer more like the Windows installer http://bugs.python.org/issue11229 #11226: subprocesses experience mysterious delay in receiving stdin EO http://bugs.python.org/issue11226 #11225: getcwd fix for NetBSD to handle ERANGE errno http://bugs.python.org/issue11225 #11224: 3.2: tarfile.getmembers causes 100% cpu usage on Windows http://bugs.python.org/issue11224 #11218: pattern=None when following documentation for load_tests and u http://bugs.python.org/issue11218 #11210: PyErr_SetFromWindowsErrWithFilenameObject() doesn't exist: rem http://bugs.python.org/issue11210 #11206: test_readline unconditionally calls clear_history() http://bugs.python.org/issue11206 #11204: re module: strange behaviour of space inside {m, n} http://bugs.python.org/issue11204 #11203: gzip doc is behind http://bugs.python.org/issue11203 #11199: urllib hangs when closing connection http://bugs.python.org/issue11199 #11195: next fixer fooled by trailing cheracters http://bugs.python.org/issue11195 Most recent 15 issues waiting for review (15) ============================================= #11243: email/message.py str conversion http://bugs.python.org/issue11243 #11239: regexp-howto - add missing } to metachars http://bugs.python.org/issue11239 #11238: sets - refer to sets/frozenset in stdtypes http://bugs.python.org/issue11238 #11232: asyncore - don't throw a traceback when a client disconnects i http://bugs.python.org/issue11232 #11227: [DOC] asyncore - use 'Host' header in HTTP example http://bugs.python.org/issue11227 #11225: getcwd fix for NetBSD to handle ERANGE errno http://bugs.python.org/issue11225 #11223: interruption of locks by signals not guaranteed when the semap http://bugs.python.org/issue11223 #11222: Python3.2rc3 fails to build on Mac OS X with a non-framework b http://bugs.python.org/issue11222 #11212: Python memory limit on AIX http://bugs.python.org/issue11212 #11210: PyErr_SetFromWindowsErrWithFilenameObject() doesn't exist: rem http://bugs.python.org/issue11210 #11205: Evaluation order of dictionary display is different from refer http://bugs.python.org/issue11205 #11188: test_time error on AIX http://bugs.python.org/issue11188 #11187: PyUnicode_AsEncodedString: the bootstrap hack is no more neede http://bugs.python.org/issue11187 #11184: Broken large file support on AIX http://bugs.python.org/issue11184 #11177: Set asyncore create_socket default argument http://bugs.python.org/issue11177 Top 10 most discussed issues (10) ================================= #10181: Problems with Py_buffer management in memoryobject.c (and else http://bugs.python.org/issue10181 25 msgs #11222: Python3.2rc3 fails to build on Mac OS X with a non-framework b http://bugs.python.org/issue11222 20 msgs #11223: interruption of locks by signals not guaranteed when the semap http://bugs.python.org/issue11223 16 msgs #11205: Evaluation order of dictionary display is different from refer http://bugs.python.org/issue11205 14 msgs #11212: Python memory limit on AIX http://bugs.python.org/issue11212 14 msgs #941346: AIX shared library fix http://bugs.python.org/issue941346 13 msgs #11188: test_time error on AIX http://bugs.python.org/issue11188 12 msgs #11219: Produce a warning when the license is specified in both the Li http://bugs.python.org/issue11219 9 msgs #3244: multipart/form-data encoding http://bugs.python.org/issue3244 7 msgs #5537: LWPCookieJar cannot handle cookies with expirations of 2038 or http://bugs.python.org/issue5537 7 msgs Issues closed (24) ================== #4379: Py_SAFE_DOWNCAST in FILE_TIME_to_time_t_nsec failing http://bugs.python.org/issue4379 closed by haypo #5736: Add the iterator protocol to dbm modules http://bugs.python.org/issue5736 closed by eric.araujo #7305: urllib2.urlopen() segfault using SSL on Solaris http://bugs.python.org/issue7305 closed by orsenthil #10720: test_threadsignals hang on FreeBSD 6.4 http://bugs.python.org/issue10720 closed by pitrou #11116: mailbox and email errors http://bugs.python.org/issue11116 closed by r.david.murray #11134: Add missing type slots http://bugs.python.org/issue11134 closed by loewis #11135: Redundant doc field in TypeSpec http://bugs.python.org/issue11135 closed by loewis #11171: Python 2.7.1 does not start when "./configure" is used with " http://bugs.python.org/issue11171 closed by barry #11181: TLS end connection not detected properly in retrbinary http://bugs.python.org/issue11181 closed by adiroiban #11194: "lock.__exit__ == lock.release" should be False http://bugs.python.org/issue11194 closed by r.david.murray #11196: add possibility for returning value the way Matlab does it http://bugs.python.org/issue11196 closed by brian.curtin #11198: re sub subn backreferrence too few replacements http://bugs.python.org/issue11198 closed by r.david.murray #11202: Win32: shutil.move does not inherit permissions http://bugs.python.org/issue11202 closed by brian.curtin #11208: example misprint in documentation whatsnew/3.2 http://bugs.python.org/issue11208 closed by rhettinger #11209: Example for itertools.count is misleading http://bugs.python.org/issue11209 closed by rhettinger #11211: gzip.open() fails for gzipped file http://bugs.python.org/issue11211 closed by haypo #11213: distutils2 test issue http://bugs.python.org/issue11213 closed by pitrou #11220: https sslv3 error 14077417: illegal parameter http://bugs.python.org/issue11220 closed by pitrou #11221: all() returns wrong result when the parameters are non-encapsu http://bugs.python.org/issue11221 closed by georg.brandl #11237: odbc module crashes Python interpretter http://bugs.python.org/issue11237 closed by brett.cannon #1726687: Bug found in datetime for Epoch time = -1 http://bugs.python.org/issue1726687 closed by belopolsky #1649329: Extract file-finding and language-handling code from gettext.f http://bugs.python.org/issue1649329 closed by eric.araujo #11228: raw unicode strings interpret \u and \U (but not \n, \xHH, ... http://bugs.python.org/issue11228 closed by haypo #730467: Not detecting AIX_GENUINE_CPLUSPLUS http://bugs.python.org/issue730467 closed by georg.brandl From martin at v.loewis.de Sat Feb 19 00:02:55 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Sat, 19 Feb 2011 00:02:55 +0100 Subject: [Python-Dev] svn outage on Friday In-Reply-To: References: <4D5A3990.4040902@v.loewis.de> Message-ID: <4D5EFA9F.5030900@v.loewis.de> Am 18.02.2011 14:41, schrieb Dirkjan Ochtman: > On Tue, Feb 15, 2011 at 09:30, "Martin v. L?wis" wrote: >> I'm going to perform a Debian upgrade of svn.python.org on Friday, >> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during >> that time. The outage shouldn't be longer than an hour. > > It seems hg is no longer installed on dinsdale, does that have > anything to do with this? Yes, it must have gotten uninstalled during the upgrade. I have now reinstalled it. Please let me know if there is anything else missing. Regards, Martin From stefan_ml at behnel.de Sat Feb 19 13:37:26 2011 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 19 Feb 2011 13:37:26 +0100 Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__ during installation Message-ID: Hi, sorry for asking here instead of filing a bug, but given that 3.2 final is pretty close, I wanted to make sure this gets considered. A Cython user noticed that the installation (setup.py install or bdist) puts several .pyc files into the installed source directory, instead of moving them into __pycache__. The latter is still used, and most of the .pyc files end up there, but not all of them. Some even end up in both directories, once with a ".cpython-32.pyc" suffix in __pycache__ and simply as ".pyc" next to the sources. A specialty of the Cython installation is that a tiny part of Cython gets imported at the beginning, then setup() is called. Next, 2to3 is run over the sources, and during the extension building phase, the initially imported part is removed from sys.modules and Cython is imported completely from the converted sources and runs to compile parts of itself. Finally, the installation continues and copies/byte-compiles the 2to3 converted .py files. What I think is happening here, is that the normal import mechanism byte compiles the 2to3 converted sources into the __pycache__ directory (when invoked at extension building time), but then distutils' byte compilation seems to decide that it's better to keep the .pyc files where the sources are. And thus a mix of both ends up in the installation. Wouldn't it be better to let distutils *always* byte-compile the .py files into the appropriate __pycache__ directory, just like the import mechanism does? Or is there something else broken here? Stefan From martin at v.loewis.de Sat Feb 19 13:55:56 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 19 Feb 2011 13:55:56 +0100 Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__ during installation In-Reply-To: References: Message-ID: <4D5FBDDC.1080607@v.loewis.de> > sorry for asking here instead of filing a bug, but given that 3.2 final > is pretty close, I wanted to make sure this gets considered. If you want it decided before the 3.2 release, it must be a release-critical bug report in the tracker. Posting it here does not make sure it gets considered. Regards, Martin From ncoghlan at gmail.com Sat Feb 19 14:07:17 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 19 Feb 2011 23:07:17 +1000 Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__ during installation In-Reply-To: References: Message-ID: On Sat, Feb 19, 2011 at 10:37 PM, Stefan Behnel wrote: > What I think is happening here, is that the normal import mechanism byte > compiles the 2to3 converted sources into the __pycache__ directory (when > invoked at extension building time), but then distutils' byte compilation > seems to decide that it's better to keep the .pyc files where the sources > are. And thus a mix of both ends up in the installation. > > Wouldn't it be better to let distutils *always* byte-compile the .py files > into the appropriate __pycache__ directory, just like the import mechanism > does? Or is there something else broken here? A quick look [1] suggests that distutils.util.bytes_compile is indeed second-guessing py_compile.compile and forcing use of the legacy .pyc location rather than accepting the default location. (Why? I have no idea, it's distutils...) While this is definitely untidy, it doesn't strike me as a release blocker. More of a "fix it in 3.2.1", since the status quo will *work*, it just means the precompiled file will be ignored on first execution with newer Python versions. Cheers, Nick. [1] http://svn.python.org/view/python/branches/py3k/Lib/distutils/util.py?view=markup -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From solipsis at pitrou.net Sat Feb 19 14:14:19 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 19 Feb 2011 14:14:19 +0100 Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__ during installation References: Message-ID: <20110219141419.246af6aa@pitrou.net> On Sat, 19 Feb 2011 23:07:17 +1000 Nick Coghlan wrote: > > While this is definitely untidy, it doesn't strike me as a release > blocker. More of a "fix it in 3.2.1", since the status quo will > *work*, it just means the precompiled file will be ignored on first > execution with newer Python versions. Are you sure? If the package gets installed in a root-writable-only directory, later execution cannot create the right pyc files. This certainly looks like a critical issue (hopefully not release blocker). From solipsis at pitrou.net Sat Feb 19 14:23:52 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 19 Feb 2011 14:23:52 +0100 Subject: [Python-Dev] svn outage on Friday References: <4D5A3990.4040902@v.loewis.de> <1297761906.31674.0.camel@marge> <4D5DAC8C.3030304@v.loewis.de> Message-ID: <20110219142352.76388f2b@pitrou.net> On Fri, 18 Feb 2011 08:09:12 +0100 Dirkjan Ochtman wrote: > On Fri, Feb 18, 2011 at 00:17, "Martin v. L?wis" wrote: > > I think it's fair to say that the project currently rests, lacking > > a project lead. The most recent timeline is that conversion should > > be completed by PyCon, and, failing that, should start at PyCon. > > It's not exactly resting; I've been pushing around the > cvs2svn-converted tags to get them to behave sensibly, and I've been > having good discussions with Antoine and Georg about several things we > need to hash out in IRC. Sorry I haven't been doing more progress > reports here. > > But yes, it would be nice if we could actually switch by PyCon, but at > the very least there should be a fresh test repo and consensus on most > of the workflow issues by PyCon (for those interested who live in > Europe, I'm going to be at a hg sprint in Karlsruhe during the PyCon > weekend). Would be nice if at least a simple repo (e.g. peps) got fully migrated as soon as possible. Thanks Antoine. From martin at v.loewis.de Sat Feb 19 14:27:56 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 19 Feb 2011 14:27:56 +0100 Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__ during installation In-Reply-To: <20110219141419.246af6aa@pitrou.net> References: <20110219141419.246af6aa@pitrou.net> Message-ID: <4D5FC55C.9060100@v.loewis.de> Am 19.02.2011 14:14, schrieb Antoine Pitrou: > On Sat, 19 Feb 2011 23:07:17 +1000 > Nick Coghlan wrote: >> >> While this is definitely untidy, it doesn't strike me as a release >> blocker. More of a "fix it in 3.2.1", since the status quo will >> *work*, it just means the precompiled file will be ignored on first >> execution with newer Python versions. > > Are you sure? If the package gets installed in a root-writable-only > directory, later execution cannot create the right pyc files. It will certainly work. It won't create pyc files, but it will still work - right? Regards, Martin From ncoghlan at gmail.com Sat Feb 19 14:29:36 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 19 Feb 2011 23:29:36 +1000 Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__ during installation In-Reply-To: <20110219141419.246af6aa@pitrou.net> References: <20110219141419.246af6aa@pitrou.net> Message-ID: On Sat, Feb 19, 2011 at 11:14 PM, Antoine Pitrou wrote: > On Sat, 19 Feb 2011 23:07:17 +1000 > Nick Coghlan wrote: >> >> While this is definitely untidy, it doesn't strike me as a release >> blocker. More of a "fix it in 3.2.1", since the status quo will >> *work*, it just means the precompiled file will be ignored on first >> execution with newer Python versions. > > Are you sure? If the package gets installed in a root-writable-only > directory, later execution cannot create the right pyc files. Worst case, it will run from the source file. It may even use the legacy .pyc file in the case where it can't write to __pycache__ (I don't remember how that particular subtlety of PEP 3147 played out). Certainly not ideal from a performance point of view, but also not difficult to workaround once discovered. > This certainly looks like a critical issue (hopefully not release > blocker). As a performance problem that only arises in some situations when using distutils to do bulk compilation, and with running "compileall" as root available as a relatively straightforward workaround, I personally think it can wait until 3.2.1. So I'd agree with the critical-but-not-a-release-blocker assessment, but it's ultimately Georg's call. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From solipsis at pitrou.net Sat Feb 19 14:29:42 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 19 Feb 2011 14:29:42 +0100 Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__ during installation In-Reply-To: <4D5FC55C.9060100@v.loewis.de> References: <20110219141419.246af6aa@pitrou.net> <4D5FC55C.9060100@v.loewis.de> Message-ID: <1298122182.3793.1.camel@localhost.localdomain> Le samedi 19 f?vrier 2011 ? 14:27 +0100, "Martin v. L?wis" a ?crit : > Am 19.02.2011 14:14, schrieb Antoine Pitrou: > > On Sat, 19 Feb 2011 23:07:17 +1000 > > Nick Coghlan wrote: > >> > >> While this is definitely untidy, it doesn't strike me as a release > >> blocker. More of a "fix it in 3.2.1", since the status quo will > >> *work*, it just means the precompiled file will be ignored on first > >> execution with newer Python versions. > > > > Are you sure? If the package gets installed in a root-writable-only > > directory, later execution cannot create the right pyc files. > > It will certainly work. It won't create pyc files, but it will still > work - right? Right, but that's a big performance regression if it doesn't use cached bytecode file. Regards Antoine. From songofacandy at gmail.com Sat Feb 19 17:19:51 2011 From: songofacandy at gmail.com (INADA Naoki) Date: Sun, 20 Feb 2011 01:19:51 +0900 Subject: [Python-Dev] What's L2R status? Message-ID: Ref: http://bugs.python.org/issue448679 Has this bug fixed already? This bug seems not be fixed for Python 2.6 and Python 3.2rc3. Python 3.2rc3 (r32rc3:88413, Feb 15 2011, 18:31:14) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> C=0 >>> def x(): ... global C ... C += 1 ... return C ... >>> {x(): x(), x(): x()} {2: 1, 4: 3} -- INADA Naoki? From songofacandy at gmail.com Sat Feb 19 17:35:53 2011 From: songofacandy at gmail.com (INADA Naoki) Date: Sun, 20 Feb 2011 01:35:53 +0900 Subject: [Python-Dev] What's L2R status? In-Reply-To: References: Message-ID: Sorry. There is a issue already. http://bugs.python.org/issue11205 On Sun, Feb 20, 2011 at 1:19 AM, INADA Naoki wrote: > Ref: http://bugs.python.org/issue448679 > > Has this bug fixed already? > This bug seems not be fixed for Python 2.6 and Python 3.2rc3. > > Python 3.2rc3 (r32rc3:88413, Feb 15 2011, 18:31:14) > [GCC 4.4.5] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> C=0 >>>> def x(): > ... ? ? global C > ... ? ? C += 1 > ... ? ? return C > ... >>>> {x(): x(), x(): x()} > {2: 1, 4: 3} > > > -- > INADA Naoki? > -- INADA Naoki? From skip at pobox.com Sat Feb 19 19:08:38 2011 From: skip at pobox.com (skip at pobox.com) Date: Sat, 19 Feb 2011 12:08:38 -0600 Subject: [Python-Dev] What's L2R status? In-Reply-To: References: Message-ID: <19808.1830.651449.644661@montanaro.dyndns.org> INADA> Sorry. There is a issue already. INADA> http://bugs.python.org/issue11205 >From Raymond's last comment on the above ticket: > How much to change and how far to backport may make for a good python-dev > discussion. I think the simple patch I posted for 2.7 is probably all that should be done for the 2.x series. Briefly, change the visit order to evaluate the key before the value, then use ROT_TWO to reorder the top of the stack for STORE_MAP. > I don't have any feelings about it one way or the other, but it would > great to see Py3.2.1 get fixed properly. I don't know if bumping the bytecode version is okay after 3.2 is released, or if that's something which could only happen with 3.3. Whatever is deemed proper by the release managers, the better change would be to bump the version number, remove the ROT_TWO from my basic patch and change the order of arguments expected by STORE_MAP. Skip From g.brandl at gmx.net Sat Feb 19 21:53:31 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Sat, 19 Feb 2011 21:53:31 +0100 Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__ during installation In-Reply-To: References: <20110219141419.246af6aa@pitrou.net> Message-ID: Am 19.02.2011 14:29, schrieb Nick Coghlan: > On Sat, Feb 19, 2011 at 11:14 PM, Antoine Pitrou wrote: >> On Sat, 19 Feb 2011 23:07:17 +1000 >> Nick Coghlan wrote: >>> >>> While this is definitely untidy, it doesn't strike me as a release >>> blocker. More of a "fix it in 3.2.1", since the status quo will >>> *work*, it just means the precompiled file will be ignored on first >>> execution with newer Python versions. >> >> Are you sure? If the package gets installed in a root-writable-only >> directory, later execution cannot create the right pyc files. > > Worst case, it will run from the source file. It may even use the > legacy .pyc file in the case where it can't write to __pycache__ (I > don't remember how that particular subtlety of PEP 3147 played out). > Certainly not ideal from a performance point of view, but also not > difficult to workaround once discovered. > >> This certainly looks like a critical issue (hopefully not release >> blocker). > > As a performance problem that only arises in some situations when > using distutils to do bulk compilation, and with running "compileall" > as root available as a relatively straightforward workaround, I > personally think it can wait until 3.2.1. > > So I'd agree with the critical-but-not-a-release-blocker assessment, > but it's ultimately Georg's call. Given that we are only hours from the final, I'm quite unwilling to call this a blocker, seeing that running from the .py file works well (and I'm not really of Antoine's opinion that that is such a big performance hit). BTW, I haven't seen an issue yet. Georg From ncoghlan at gmail.com Sun Feb 20 01:41:56 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 20 Feb 2011 10:41:56 +1000 Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__ during installation In-Reply-To: References: <20110219141419.246af6aa@pitrou.net> Message-ID: On Sun, Feb 20, 2011 at 6:53 AM, Georg Brandl wrote: > Given that we are only hours from the final, I'm quite unwilling to > call this a blocker, seeing that running from the .py file works well > (and I'm not really of Antoine's opinion that that is such a big > performance hit). How significant the performance hit is depends on at least a few different factors: 1. How many files are affected 2. How many files are implicitly imported when the application starts 3. How big/complicated those files 4. How long the actual "do work" part of the application takes I expect something like "hg diff" on a small working copy would be severely impacted if the application files for hg itself weren't cached properly. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From hoytak at stat.washington.edu Sun Feb 20 06:43:14 2011 From: hoytak at stat.washington.edu (Hoyt Koepke) Date: Sat, 19 Feb 2011 21:43:14 -0800 Subject: [Python-Dev] Bug in linking to gomp with python; causes crash in matplotlib. Message-ID: Hello, I've encountered a strange bug that appears to be either in gcc's gomp implementation or in how python loads extension modules linked against gomp. Here's the error: Using gcc (multiple versions) on linux, I compile an empty c extension module and pass -lgomp as a linker arg. If I import it, running a simple script in matplotlib causes a segfault. Not passing -lgomp or not loading the empty module makes the code works fine. More specifically, if I compile: #include "Python.h" static struct PyMethodDef methods[] = { {0, 0, 0, 0} }; PyMODINIT_FUNC initempty(void) { Py_InitModule4("empty", methods, 0, 0, PYTHON_API_VERSION); } using ``ext_modules = [Extension("empty", ["empty.c"], extra_link_args = ["-lgomp"])]``, then import empty import matplotlib.pylab as plt plt.figure() plt.plot([0,1], [0,1], '-b') plt.show() causes the program to segfault (removing ``import empty`` makes it fine). Looking at a traceback: #0 0x00f78bc7 in __cxa_allocate_exception () from /usr/lib/libstdc++.so.6 #1 0x008f51f2 in py_to_agg_transformation_matrix (obj=0x8223f58, errors=false) at src/agg_py_transforms.cpp:20 #2 0x008fdd73 in _path_module::update_path_extents (this=0x8e45f90, args=...) at src/path.cpp:378 #3 0x009048bd in Py::ExtensionModule<_path_module>::invoke_method_varargs (this=, method_def=0x8e9ae30, args=...) at ./CXX/Python2/ExtensionModule.hxx:184 #4 0x008f0d96 in method_varargs_call_handler (_self_and_name_tuple=0x8e6eeac, _args=0x94e683c) at CXX/Python2/cxx_extensions.cxx:1714 #5 0x080dc0d0 in PyEval_EvalFrameEx () #6 0x080dddf2 in PyEval_EvalCodeEx () While occurring in some of matplotlib's extension code (and I haven't found another library that crashes it), the fact that the deciding factor is whether I link against gomp indicates the it's probably upstream somewhere. I encountered this error a year ago and asked about it on the matplotlib mailing list, but found a quick workaround then, and with deadline pressure I forgot about it. However, it's come up again, and then I was asked to bump it to python-dev, which is why I'm posting it here. I can reproduce it on the following systems. In all cases, matplotlib is compiled from source on the development branch (r8969) and uses QT4Agg as the backend, as is numpy, scipy, etc. If needed, I can track down more versions. gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.4, 64bit, Python 2.6.6, ubuntu 10.10 gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3, 64bit, Python 2.6.5, ubuntu 10.04 gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1, 32bit, Python 2.6.4, ubuntu 9.10 gcc 4.5.2 (source build), Python 2.6.5, ubuntu 10.04. On this build, the given source example does not produce the result, and I haven't been able to tweak it so it does. However, linking to a much larger extension library that uses many different parts of openmp causes exactly the same crash. If I recompile that library without openmp support, then everything works fine; with openmp support it corrupts something and matplotlib crashes in exactly the same way. gcc 4.3.2, Python 2.6.2, ubuntu 9.04 (I don't have access to this system any more, since it got upgraded, but it had the same problem a year ago). I'd be happy to provide any more information if needed. I attached example code that reproduces it. Let me know if I should file a bug report (and where to file it -- which is why I haven't yet). Thanks, --Hoyt ++++++++++++++++++++++++++++++++++++++++++++++++ + Hoyt Koepke + University of Washington Department of Statistics + http://www.stat.washington.edu/~hoytak/ + hoytak at gmail.com ++++++++++++++++++++++++++++++++++++++++++ -------------- next part -------------- A non-text attachment was scrubbed... Name: python-gomp-bug.tar.gz Type: application/x-gzip Size: 672 bytes Desc: not available URL: From ncoghlan at gmail.com Sun Feb 20 07:28:03 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 20 Feb 2011 16:28:03 +1000 Subject: [Python-Dev] Bug in linking to gomp with python; causes crash in matplotlib. In-Reply-To: References: Message-ID: On Sun, Feb 20, 2011 at 3:43 PM, Hoyt Koepke wrote: > I'd be happy to provide any more information if needed. ?I attached > example code that reproduces it. ?Let me know if I should file a bug > report (and where to file it -- which is why I haven't yet). An associated bug report would be appreciated (mailing list discussions are useful for raising awareness, but are more likely to be forgotten over time than bug reports): http://bugs.python.org Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From techtonik at gmail.com Sun Feb 20 07:39:12 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Sun, 20 Feb 2011 08:39:12 +0200 Subject: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows In-Reply-To: <4D505323.5020909@stoneleaf.us> References: <4D431724.4010002@voidspace.org.uk> <4D4C3AB9.3020300@simplistix.co.uk> <4D4EBCC4.1090003@simplistix.co.uk> <4D4EBDC7.9000301@simplistix.co.uk> <4D505323.5020909@stoneleaf.us> Message-ID: I've got a feeling that policy is evil and can not be applied cleanly when change falls out of scope of Python core .c sources and .py files from standard library. Right now the proposal is to add Python to %PATH% to make Python more user friendly for newbies. I can't see what can become worse than it is now. People are discussing advanced scenarios with multiple Python installations, but I propose first to make Python a normal command line user-friendly system application for Windows, and then discuss more advanced usage scenarios to make it developer-friendly in subsequent versions. Time is passing by and nothing happens. -- anatoly t. From techtonik at gmail.com Sun Feb 20 07:43:06 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Sun, 20 Feb 2011 08:43:06 +0200 Subject: [Python-Dev] w9xpopen.exe is still in 3.2 Message-ID: Python definitely needs a development Roadmap to avoid things like w9xpopen.exe slipping off radar from release to release. We don't support Windows 9x since Python 2.6. What this file does in 3.x distributions? http://bugs.python.org/issue2405 -- anatoly t. From martin at v.loewis.de Sun Feb 20 10:10:08 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 20 Feb 2011 10:10:08 +0100 Subject: [Python-Dev] w9xpopen.exe is still in 3.2 In-Reply-To: References: Message-ID: <4D60DA70.1010509@v.loewis.de> Am 20.02.2011 07:43, schrieb anatoly techtonik: > Python definitely needs a development Roadmap to avoid things like > w9xpopen.exe slipping off radar from release to release. We don't > support Windows 9x since Python 2.6. What this file does in 3.x > distributions? > > http://bugs.python.org/issue2405 Read the report carefully. It can't be removed to support installations that have changed COMSPEC. Regards, Martin From stefan_ml at behnel.de Sun Feb 20 10:55:42 2011 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sun, 20 Feb 2011 10:55:42 +0100 Subject: [Python-Dev] "Some" .pyc files not ending up in __pycache__ during installation In-Reply-To: References: <20110219141419.246af6aa@pitrou.net> Message-ID: Georg Brandl, 19.02.2011 21:53: > BTW, I haven't seen an issue yet. http://bugs.python.org/issue11254 Stefan From techtonik at gmail.com Sun Feb 20 22:22:55 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Sun, 20 Feb 2011 23:22:55 +0200 Subject: [Python-Dev] w9xpopen.exe is still in 3.2 In-Reply-To: <4D60DA70.1010509@v.loewis.de> References: <4D60DA70.1010509@v.loewis.de> Message-ID: On Sun, Feb 20, 2011 at 11:10 AM, "Martin v. L?wis" wrote: > Am 20.02.2011 07:43, schrieb anatoly techtonik: >> Python definitely needs a development Roadmap to avoid things like >> w9xpopen.exe slipping off radar from release to release. We don't >> support Windows 9x since Python 2.6. What this file does in 3.x >> distributions? >> >> http://bugs.python.org/issue2405 > > Read the report carefully. It can't be removed to support installations > that have changed COMSPEC. What is the percentage of these installations? Is it possible to support them using by 3rd-party package/distribution? -- anatoly t. From georg at python.org Sun Feb 20 23:22:47 2011 From: georg at python.org (Georg Brandl) Date: Sun, 20 Feb 2011 23:22:47 +0100 Subject: [Python-Dev] [RELEASED] Python 3.2 Message-ID: <4D619437.7050507@python.org> On behalf of the Python development team, I'm delighted to announce Python 3.2 final release. Python 3.2 is a continuation of the efforts to improve and stabilize the Python 3.x line. Since the final release of Python 2.7, the 2.x line will only receive bugfixes, and new features are developed for 3.x only. Since PEP 3003, the Moratorium on Language Changes, is in effect, there are no changes in Python's syntax and built-in types in Python 3.2. Development efforts concentrated on the standard library and support for porting code to Python 3. Highlights are: * numerous improvements to the unittest module * PEP 3147, support for .pyc repository directories * PEP 3149, support for version tagged dynamic libraries * PEP 3148, a new futures library for concurrent programming * PEP 384, a stable ABI for extension modules * PEP 391, dictionary-based logging configuration * an overhauled GIL implementation that reduces contention * an extended email package that handles bytes messages * a much improved ssl module with support for SSL contexts and certificate hostname matching * a sysconfig module to access configuration information * additions to the shutil module, among them archive file support * many enhancements to configparser, among them mapping protocol support * improvements to pdb, the Python debugger * countless fixes regarding bytes/string issues; among them full support for a bytes environment (filenames, environment variables) * many consistency and behavior fixes for numeric operations For a more extensive list of changes in 3.2, see http://docs.python.org/3.2/whatsnew/3.2.html To download Python 3.2 visit: http://www.python.org/download/releases/3.2/ Please consider trying Python 3.2 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.2's contributors) From techtonik at gmail.com Sun Feb 20 23:24:41 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Mon, 21 Feb 2011 00:24:41 +0200 Subject: [Python-Dev] Gsoc 2011 ideas In-Reply-To: References: Message-ID: I've compiled a list of issues with python.org services that are not strictly related to core development, but still may be beneficial for Python community as a GSoC project at http://code.google.com/p/pydotorg/issues/list Feel free to add your own proposals/ideas. -- anatoly t. On Sat, Feb 12, 2011 at 2:44 PM, yeswanth swami wrote: > Hi everyone, > I am planning to apply for Gsoc 2011 for the PSF . I would like to know if > any of you have any ideas which can be implemented this summer. I guess the > gsoc 2011 ideas page has not been put up as yet. So I thought maybe any of > you can suggest some ideas . > Thanks > Yeswanth > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/techtonik%40gmail.com > > From brian.curtin at gmail.com Mon Feb 21 00:11:54 2011 From: brian.curtin at gmail.com (Brian Curtin) Date: Sun, 20 Feb 2011 17:11:54 -0600 Subject: [Python-Dev] w9xpopen.exe is still in 3.2 In-Reply-To: References: <4D60DA70.1010509@v.loewis.de> Message-ID: On Sun, Feb 20, 2011 at 15:22, anatoly techtonik wrote: > On Sun, Feb 20, 2011 at 11:10 AM, "Martin v. L?wis" > wrote: > > Am 20.02.2011 07:43, schrieb anatoly techtonik: > >> Python definitely needs a development Roadmap to avoid things like > >> w9xpopen.exe slipping off radar from release to release. We don't > >> support Windows 9x since Python 2.6. What this file does in 3.x > >> distributions? > >> > >> http://bugs.python.org/issue2405 > > > > Read the report carefully. It can't be removed to support installations > > that have changed COMSPEC. > > What is the percentage of these installations? > Is it possible to support them using by 3rd-party package/distribution? I'm not sure the percentage matters. Someone somewhere may need it now or in the future, and keeping it requires zero effort. Removing it and creating an external distribution requires extra work from someone on python-dev and also on the user's part, which is a losing situation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.stinner at haypocalc.com Mon Feb 21 00:39:12 2011 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Mon, 21 Feb 2011 00:39:12 +0100 Subject: [Python-Dev] [RELEASED] Python 3.2 In-Reply-To: <4D619437.7050507@python.org> References: <4D619437.7050507@python.org> Message-ID: <1298245152.5269.24.camel@marge> Le dimanche 20 f?vrier 2011 ? 23:22 +0100, Georg Brandl a ?crit : > On behalf of the Python development team, I'm delighted to announce > Python 3.2 final release. > > Python 3.2 is a continuation of the efforts to improve and stabilize the > Python 3.x line. Congratulation to all Python developers for this wonderful release! And a special kudo to our release manager, Georg. I hope that Python 3 is now stable enough to support migration of major projects like Django, Twisted or Zope. Other important projets like Distribute, Jinja2, PyQt, PyGObject, pygame, NumPy+SciPy and Sphinx are already compatible with Python 3. Victor From foom at fuhm.net Mon Feb 21 02:42:07 2011 From: foom at fuhm.net (James Y Knight) Date: Sun, 20 Feb 2011 20:42:07 -0500 Subject: [Python-Dev] w9xpopen.exe is still in 3.2 In-Reply-To: <4D60DA70.1010509@v.loewis.de> References: <4D60DA70.1010509@v.loewis.de> Message-ID: <24DB6936-C0FB-40B9-B9D1-373B0E4C853F@fuhm.net> On Feb 20, 2011, at 4:10 AM, Martin v. L?wis wrote: > Am 20.02.2011 07:43, schrieb anatoly techtonik: >> Python definitely needs a development Roadmap to avoid things like >> w9xpopen.exe slipping off radar from release to release. We don't >> support Windows 9x since Python 2.6. What this file does in 3.x >> distributions? >> >> http://bugs.python.org/issue2405 > > Read the report carefully. It can't be removed to support installations > that have changed COMSPEC. Does a modern windows installation actually even *work* if you change COMSPEC to command.com instead of cmd.exe? And why would anyone ever do that? Hey, I have a good idea: python can just ignore COMSPEC and always run cmd.exe. Then you can delete w9xpopen, hooray. James From martin at v.loewis.de Mon Feb 21 07:35:28 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 21 Feb 2011 07:35:28 +0100 Subject: [Python-Dev] w9xpopen.exe is still in 3.2 In-Reply-To: <24DB6936-C0FB-40B9-B9D1-373B0E4C853F@fuhm.net> References: <4D60DA70.1010509@v.loewis.de> <24DB6936-C0FB-40B9-B9D1-373B0E4C853F@fuhm.net> Message-ID: <4D6207B0.3060804@v.loewis.de> > Does a modern windows installation actually even *work* if you change > COMSPEC to command.com instead of cmd.exe? And why would anyone ever > do that? Hey, I have a good idea: python can just ignore COMSPEC and > always run cmd.exe. Then you can delete w9xpopen, hooray. We have a process for that: in version 3.x, we deprecate the feature, and in version 3.x+1, we drop support for it. Since deprecation missed Python 3.2, we can only deprecate in 3.3, and drop in 3.4. As for "always run cmd.exe": we can't, as it's not us who runs cmd.exe, but the CRT (in the popen library function). Regards, Martin From ziade.tarek at gmail.com Mon Feb 21 08:41:51 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Mon, 21 Feb 2011 08:41:51 +0100 Subject: [Python-Dev] Distutils2 next steps Message-ID: Hello Now that Python 3.2 is out, I am planning to do the following with Distutils2: 1 - release a new alpha before Pycon for community feedback 2 - add distutils2 back in the trunk, along with the changes in pkgutil and sysconfig 3 - continue the ongoing work in Distutils2 to prepare the first Python 3.3 release If you want me to give more details here on what is going to be done precisely in the various stdlib parts, let me know. I plan to do 2. as a sprint task, and will be looking for help from other core devs, for reviews, advices etc. So if anyone is interested and present at Pycon, please add your name at http://us.pycon.org/2011/sprints/projects under the "Disttuils2" project. Thanks ! Cheers Tarek -- Tarek Ziad? | http://ziade.org From g.brandl at gmx.net Mon Feb 21 08:48:54 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Mon, 21 Feb 2011 08:48:54 +0100 Subject: [Python-Dev] Distutils2 next steps In-Reply-To: References: Message-ID: On 21.02.2011 08:41, Tarek Ziad? wrote: > Hello > > Now that Python 3.2 is out, I am planning to do the following with Distutils2: > > 1 - release a new alpha before Pycon for community feedback > 2 - add distutils2 back in the trunk, along with the changes in > pkgutil and sysconfig > 3 - continue the ongoing work in Distutils2 to prepare the first > Python 3.3 release > > If you want me to give more details here on what is going to be done > precisely in the various stdlib parts, let me know. I think I'm also speaking for the prospective release manager of 3.3 by saying yes, please, details would be nice, but not necessarily *right* now. :) Georg From ziade.tarek at gmail.com Mon Feb 21 09:02:51 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Mon, 21 Feb 2011 09:02:51 +0100 Subject: [Python-Dev] Distutils2 next steps In-Reply-To: References: Message-ID: On Mon, Feb 21, 2011 at 8:48 AM, Georg Brandl wrote: > On 21.02.2011 08:41, Tarek Ziad? wrote: >> Hello >> >> Now that Python 3.2 is out, I am planning to do the following with Distutils2: >> >> 1 - release a new alpha before Pycon for community feedback >> 2 - add distutils2 back in the trunk, along with the changes in >> pkgutil and sysconfig >> 3 - continue the ongoing work in Distutils2 to prepare the first >> Python 3.3 release >> >> If you want me to give more details here on what is going to be done >> precisely in the various stdlib parts, let me know. > > I think I'm also speaking for the prospective release manager of 3.3 > by saying yes, please, details would be nice, but not necessarily > *right* now. :) It's easy enough to give right now: - pkgutil will gain all the API that are implementing PEP 376 -- a py2 version of this module that has them can be seen at http://hg.python.org/distutils2/file/tip/distutils2/_backport/pkgutil.py for the moment - sysconfig will need to have two things: - create via the Makefile a "_sysconfig" module, so the API stop to read data dynamically in pyconfig.h and Makefile at runtime - [to be validated-discussed] an easier way to configure the installation paths. the current plan is to use a sysconfig.cfg file that may be changed. This file will be global to Python, but also possibly local to a user or a project -- http://hg.python.org/distutils2/file/tip/distutils2/_backport/sysconfig.cfg - distutils2 will be converted to Py3 using 2to3, then included in Lib/ -- the code base is ready for this, besides a few spots. - distutils2 will continue to be released as a standalone project from 2.4 to 3.2. Probably by using 3to2, but I have not tried the tool yet. Cheers Tarek > > Georg > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com > -- Tarek Ziad? | http://ziade.org From ncoghlan at gmail.com Mon Feb 21 13:52:19 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 21 Feb 2011 22:52:19 +1000 Subject: [Python-Dev] Are these PEP complete?: 389, 391, 3108, 3135 Message-ID: As the subject line asks, is there anything preventing the following PEPs from being marked Final? SA 389 argparse - New Command Line Parsing Module Bethard SA 391 Dictionary-Based Configuration For Logging Sajip SA 3108 Standard Library Reorganization Cannon SA 3121 Extension Module Initialization and Finalization von L?wis SA 3135 New Super Spealman, Delaney, Ryan (I deliberately left 3118 off the list, since there are some discrepancies between the PEP and the implementation that need to be clarified for 3.3 and the 3 distutils related PEPs won't be done until Tarek merges distutils2 back into the main line of development) It would be good to clear the decks before new PEPs start to be accepted for inclusion in 3.3. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From guido at python.org Mon Feb 21 18:20:48 2011 From: guido at python.org (Guido van Rossum) Date: Mon, 21 Feb 2011 09:20:48 -0800 Subject: [Python-Dev] Are these PEP complete?: 389, 391, 3108, 3135 In-Reply-To: References: Message-ID: On Mon, Feb 21, 2011 at 4:52 AM, Nick Coghlan wrote: > As the subject line asks, is there anything preventing the following > PEPs from being marked Final? > > ?SA ?389 ?argparse - New Command Line Parsing Module ? ? ? ? ? ? ?Bethard > ?SA ?391 ?Dictionary-Based Configuration For Logging ? ? ? ? ? ? ?Sajip > ?SA 3108 ?Standard Library Reorganization ? ? ? ? ? ? ? ? ? ? ? ? Cannon > ?SA 3121 ?Extension Module Initialization and Finalization ? ? ? ?von L?wis > ?SA 3135 ?New Super > Spealman, Delaney, Ryan Somebody (not me, not necessarily the same person for each PEP) needs to check each of these PEPs for how well they match the implemented reality and report back here. (Unless you already did this and are basically giving them a certificate of correctness with your post?) > (I deliberately left 3118 off the list, since there are some > discrepancies between the PEP and the implementation that need to be > clarified for 3.3 and the 3 distutils related PEPs won't be done until > Tarek merges distutils2 back into the main line of development) > > It would be good to clear the decks before new PEPs start to be > accepted for inclusion in 3.3. Why? -- --Guido van Rossum (python.org/~guido) From hoytak at stat.washington.edu Mon Feb 21 18:55:46 2011 From: hoytak at stat.washington.edu (Hoyt Koepke) Date: Mon, 21 Feb 2011 09:55:46 -0800 Subject: [Python-Dev] Bug in linking to gomp with python; causes crash in matplotlib. In-Reply-To: References: Message-ID: > An associated bug report would be appreciated (mailing list > discussions are useful for raising awareness, but are more likely to > be forgotten over time than bug reports): http://bugs.python.org Just did that; thanks! -- Hoyt ++++++++++++++++++++++++++++++++++++++++++++++++ + Hoyt Koepke + University of Washington Department of Statistics + http://www.stat.washington.edu/~hoytak/ + hoytak at gmail.com ++++++++++++++++++++++++++++++++++++++++++ From brett at python.org Mon Feb 21 19:22:39 2011 From: brett at python.org (Brett Cannon) Date: Mon, 21 Feb 2011 10:22:39 -0800 Subject: [Python-Dev] Distutils2 next steps In-Reply-To: References: Message-ID: On Mon, Feb 21, 2011 at 00:02, Tarek Ziad? wrote: > On Mon, Feb 21, 2011 at 8:48 AM, Georg Brandl wrote: >> On 21.02.2011 08:41, Tarek Ziad? wrote: >>> Hello >>> >>> Now that Python 3.2 is out, I am planning to do the following with Distutils2: >>> >>> 1 - release a new alpha before Pycon for community feedback >>> 2 - add distutils2 back in the trunk, along with the changes in >>> pkgutil and sysconfig >>> 3 - continue the ongoing work in Distutils2 to prepare the first >>> Python 3.3 release >>> >>> If you want me to give more details here on what is going to be done >>> precisely in the various stdlib parts, let me know. >> >> I think I'm also speaking for the prospective release manager of 3.3 >> by saying yes, please, details would be nice, but not necessarily >> *right* now. :) > > It's easy enough to give right now: > > - pkgutil will gain all the API that are implementing PEP 376 -- a py2 > version of this module that has them can be seen at > http://hg.python.org/distutils2/file/tip/distutils2/_backport/pkgutil.py > ?for the moment > > - sysconfig will need to have two things: > > ?- create via the Makefile a "_sysconfig" module, so the API stop to > read data dynamically in pyconfig.h and Makefile at runtime > ?- [to be validated-discussed] an easier way to configure the > installation paths. the current plan is to use a sysconfig.cfg file > that may be changed. This file will be global to Python, but also > possibly local to a user or a project -- > http://hg.python.org/distutils2/file/tip/distutils2/_backport/sysconfig.cfg > > - distutils2 will be converted to Py3 using 2to3, then included in > Lib/ -- the code base is ready for this, besides a few spots. > > - distutils2 will continue to be released as a standalone project from > 2.4 to 3.2. Probably by using 3to2, but I have not tried the tool yet. So does this mean that primary development will move to py3k and then you will simply push changes downstream to the distutils2 project for separate releases? Or are you going to go the reverse route? -Brett > > > Cheers > Tarek > >> >> Georg >> >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com >> > > > > -- > Tarek Ziad? | http://ziade.org > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org > From brett at python.org Mon Feb 21 19:25:58 2011 From: brett at python.org (Brett Cannon) Date: Mon, 21 Feb 2011 10:25:58 -0800 Subject: [Python-Dev] Are these PEP complete?: 389, 391, 3108, 3135 In-Reply-To: References: Message-ID: On Mon, Feb 21, 2011 at 04:52, Nick Coghlan wrote: > As the subject line asks, is there anything preventing the following > PEPs from being marked Final? > > ?SA ?389 ?argparse - New Command Line Parsing Module ? ? ? ? ? ? ?Bethard > ?SA ?391 ?Dictionary-Based Configuration For Logging ? ? ? ? ? ? ?Sajip > ?SA 3108 ?Standard Library Reorganization ? ? ? ? ? ? ? ? ? ? ? ? Cannon PEP 3108 (http://bugs.python.org/issue2775) will be considered done once cProfile and profile are merged. -Brett > ?SA 3121 ?Extension Module Initialization and Finalization ? ? ? ?von L?wis > ?SA 3135 ?New Super > Spealman, Delaney, Ryan > > (I deliberately left 3118 off the list, since there are some > discrepancies between the PEP and the implementation that need to be > clarified for 3.3 and the 3 distutils related PEPs won't be done until > Tarek merges distutils2 back into the main line of development) > > It would be good to clear the decks before new PEPs start to be > accepted for inclusion in 3.3. > > Cheers, > Nick. > > -- > Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org > From ziade.tarek at gmail.com Mon Feb 21 19:30:46 2011 From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=) Date: Mon, 21 Feb 2011 19:30:46 +0100 Subject: [Python-Dev] Distutils2 next steps In-Reply-To: References: Message-ID: On Mon, Feb 21, 2011 at 7:22 PM, Brett Cannon wrote: ... >> - distutils2 will continue to be released as a standalone project from >> 2.4 to 3.2. Probably by using 3to2, but I have not tried the tool yet. > > So does this mean that primary development will move to py3k and then > you will simply push changes downstream to the distutils2 project for > separate releases? Or are you going to go the reverse route? I will backport from py3k to the standalone version, yes. I think it will be better because the changes will be exposed to more people in the Python trunk, and maybe get more feedback before pushing downstream Cheers Tarek > > -Brett > >> >> >> Cheers >> Tarek >> >>> >>> Georg >>> >>> >>> _______________________________________________ >>> Python-Dev mailing list >>> Python-Dev at python.org >>> http://mail.python.org/mailman/listinfo/python-dev >>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com >>> >> >> >> >> -- >> Tarek Ziad? | http://ziade.org >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org >> > -- Tarek Ziad? | http://ziade.org From ncoghlan at gmail.com Mon Feb 21 23:01:28 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Tue, 22 Feb 2011 08:01:28 +1000 Subject: [Python-Dev] Are these PEP complete?: 389, 391, 3108, 3135 In-Reply-To: References: Message-ID: On Tue, Feb 22, 2011 at 3:20 AM, Guido van Rossum wrote: > On Mon, Feb 21, 2011 at 4:52 AM, Nick Coghlan wrote: >> As the subject line asks, is there anything preventing the following >> PEPs from being marked Final? >> >> ?SA ?389 ?argparse - New Command Line Parsing Module ? ? ? ? ? ? ?Bethard >> ?SA ?391 ?Dictionary-Based Configuration For Logging ? ? ? ? ? ? ?Sajip >> ?SA 3108 ?Standard Library Reorganization ? ? ? ? ? ? ? ? ? ? ? ? Cannon >> ?SA 3121 ?Extension Module Initialization and Finalization ? ? ? ?von L?wis >> ?SA 3135 ?New Super >> Spealman, Delaney, Ryan > > Somebody (not me, not necessarily the same person for each PEP) needs > to check each of these PEPs for how well they match the implemented > reality and report back here. (Unless you already did this and are > basically giving them a certificate of correctness with your post?) I did have a look and those listed are the ones that seemed to be finished. Before moving them to Final, I figured I would ask for additional opinions in case I had missed something and they still had some elements that needed to be implemented for 3.3. As it turns out, I had missed the incomplete profile/cProfile merge for PEP 3108. >> It would be good to clear the decks before new PEPs start to be >> accepted for inclusion in 3.3. > > Why? It's mainly just a continuation of the PEP 0 cleanup I started a while back, trying to make it clearer which major items are still on the to-do list for 3.3 and which were completed for 3.2. I have an associated PEP 1 update I'd like to propose as well (giving the API/metadata standardisation PEPs a dedicated "Consensus" state to better separate them from Accepted language and standard library feature PEPs), but I need to actually write it first. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From daave at daave.com Tue Feb 22 00:34:45 2011 From: daave at daave.com (David Claridge) Date: Tue, 22 Feb 2011 10:34:45 +1100 Subject: [Python-Dev] Const-correctness in C-API Object Protocol Message-ID: Hi, I was wondering if there is some reason why C API functions like PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments rather than const char*s? If there is some reason these methods will modify their string arguments, it would be nice if it was documented, because at the moment it's unclear whether it is safe to cast a string literal to char* in these cases. For instance it seems reasonable that I should be able to call PySys_GetObject("path") without having to deal with a 'deprecated conversion from string constant to ?char*?' error. Thanks, -- David Claridge http://daave.com [1] http://docs.python.org/c-api/object.html [2] http://docs.python.org/c-api/sys.html From victor.stinner at haypocalc.com Tue Feb 22 01:02:58 2011 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Tue, 22 Feb 2011 01:02:58 +0100 Subject: [Python-Dev] [Python-checkins] r88484 - in python/branches/py3k: Lib/test/subprocessdata/fd_status.py Lib/test/test_subprocess.py Misc/NEWS In-Reply-To: <20110221215548.98F23EE98F@mail.python.org> References: <20110221215548.98F23EE98F@mail.python.org> Message-ID: <4D62FD32.6040009@haypocalc.com> Le 21/02/2011 22:55, antoine.pitrou a ?crit : > Author: antoine.pitrou > Date: Mon Feb 21 22:55:48 2011 > New Revision: 88484 > > Log: > Issue #10826: Prevent sporadic failure in test_subprocess on Solaris due > to open door files. > > if __name__ == "__main__": > - print(','.join(str(fd) for fd in range(0, _MAXFD) if isopen(fd))) > + fds = [] > + for fd in range(0, _MAXFD): > + try: > + st = os.fstat(fd) > + except OSError as e: > + if e.errno == errno.EBADF: > + continue > + raise > + # Ignore Solaris door files > + if st.st_mode& 0xF000 != 0xd000: > + fds.append(fd) > Are 0xF000 and 0xD000 constants specific to Solaris? If yes, you may only skip these files on Solaris, not on other OSes. Victor From wst at pancaprima.com Tue Feb 22 02:29:51 2011 From: wst at pancaprima.com (wst at pancaprima.com) Date: Tue, 22 Feb 2011 08:29:51 +0700 Subject: [Python-Dev] Mail System Error - Returned Mail Message-ID: The original message was received at Tue, 22 Feb 2011 08:29:51 +0700 from pancaprima.com [196.86.11.104] ----- The following addresses had permanent fatal errors ----- From wenheping at gmail.com Tue Feb 22 04:02:34 2011 From: wenheping at gmail.com (wen heping) Date: Tue, 22 Feb 2011 11:02:34 +0800 Subject: [Python-Dev] Is Demo directory removed from python3.2 ? Message-ID: Hi, I found 2 changes in python-3.2 compared to previous python version: i) Demo directory removed ii) lib/libpython3.2.so.1 changed to lib/libpython3.2mu.so.1 Would someone tell me why ? Thanks at advance. wen From brian.curtin at gmail.com Tue Feb 22 04:34:58 2011 From: brian.curtin at gmail.com (Brian Curtin) Date: Mon, 21 Feb 2011 21:34:58 -0600 Subject: [Python-Dev] Is Demo directory removed from python3.2 ? In-Reply-To: References: Message-ID: On Mon, Feb 21, 2011 at 21:02, wen heping wrote: > Hi, > > I found 2 changes in python-3.2 compared to previous python version: > i) Demo directory removed >From the "What's new in 3.2" document: The unmaintained Demo directory has been removed. Some demos were integrated into the documentation, some were moved to the Tools/demo directory, and others were removed altogether. See http://bugs.python.org/issue7962 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jackdied at gmail.com Tue Feb 22 04:40:19 2011 From: jackdied at gmail.com (Jack Diederich) Date: Mon, 21 Feb 2011 22:40:19 -0500 Subject: [Python-Dev] Is Demo directory removed from python3.2 ? In-Reply-To: References: Message-ID: On Mon, Feb 21, 2011 at 10:02 PM, wen heping wrote: > Hi, > > ? I found 2 changes in python-3.2 compared to previous python version: > ? i) Demo directory removed > ? ii) lib/libpython3.2.so.1 ?changed to lib/libpython3.2mu.so.1 > > ? Would someone tell me why ? The demo directory was largely out of date (some of it by a decade). Most of what was in it plain didn't work or was an outdated example of how you should do things. The good stuff was moved into the documentation or the standard library. -Jack From ncoghlan at gmail.com Tue Feb 22 06:06:07 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Tue, 22 Feb 2011 15:06:07 +1000 Subject: [Python-Dev] Is Demo directory removed from python3.2 ? In-Reply-To: References: Message-ID: On Tue, Feb 22, 2011 at 1:02 PM, wen heping wrote: > Hi, > > ? I found 2 changes in python-3.2 compared to previous python version: > ? i) Demo directory removed > ? ii) lib/libpython3.2.so.1 ?changed to lib/libpython3.2mu.so.1 Others have answered your first question, but the latter is part of PEP 3149: http://docs.python.org/py3k/whatsnew/3.2.html#pep-3149-abi-version-tagged-so-files In addition to allowing multiple builds of extension modules to exist in parallel, PEP 3149 allows multiple builds of Python itself (with different build options) to coexist. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From jcea at jcea.es Tue Feb 22 13:14:18 2011 From: jcea at jcea.es (Jesus Cea) Date: Tue, 22 Feb 2011 13:14:18 +0100 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 Message-ID: <4D63A89A.20609@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have 10MB pickled structure generated in Python 2.7. I only use basic types (no clases) like sets, dictionaries, lists, strings, etc. The pickle stores a lot of strings. Some of them should be "bytes", while other should be "unicode". My idea is to import ALL the strings as bytes in Python 3.2 and navigate the data structure to convert the appropiate values to unicode, in a one-time operation (I version the structure, so I can know if this conversion is already done, simply storing a new version value). But I get this error: """ Python 3.2 (r32:88445, Feb 21 2011, 13:34:07) [GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> f=open("file.pickle", mode="rb").read() >>> len(f) 9847316 >>> b=pickle.loads(f,encoding="latin1") Traceback (most recent call last): File "", line 1, in ValueError: operation forbidden on released memoryview object """ I use the encoding "latin1" for transparent byte/unicode conversion (do not touch the values!). This seems to be a bug in Python 3.2. Any suggestion?. PS: The bytestream is protocol 2. PPS: If there is consensus that this is a real bug, I would create an issue in the tracker and try to get a minimal testcase. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTWOomplgi5GaxT1NAQLTYAP/U+eqhQ5nIJyBAqSgYwPmkH4DOlMj4JnH Jgt6okvOV0hRIXlZ7kbWI2l9OuQyUM4gAeTNDSjFaKs9Hswy26Ro6xhtjidivXDS TKw6ocRx92/eHvgsOdEZjrE0D8l0dOqodZddbXELp2DjpYs9aozzAsjTHqNZDE1L fujeTOhtUKw= =/bcO -----END PGP SIGNATURE----- From fuzzyman at voidspace.org.uk Tue Feb 22 13:20:57 2011 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 22 Feb 2011 12:20:57 +0000 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <4D63A89A.20609@jcea.es> References: <4D63A89A.20609@jcea.es> Message-ID: <4D63AA29.9020004@voidspace.org.uk> On 22/02/2011 12:14, Jesus Cea wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I have 10MB pickled structure generated in Python 2.7. I only use basic > types (no clases) like sets, dictionaries, lists, strings, etc. > > The pickle stores a lot of strings. Some of them should be "bytes", > while other should be "unicode". My idea is to import ALL the strings as > bytes in Python 3.2 and navigate the data structure to convert the > appropiate values to unicode, in a one-time operation (I version the > structure, so I can know if this conversion is already done, simply > storing a new version value). > > But I get this error: > > """ > Python 3.2 (r32:88445, Feb 21 2011, 13:34:07) > [GCC 4.4.3] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> f=open("file.pickle", mode="rb").read() >>>> len(f) > 9847316 >>>> b=pickle.loads(f,encoding="latin1") > Traceback (most recent call last): > File "", line 1, in > ValueError: operation forbidden on released memoryview object > """ > That seems like an odd error, but the decision was made that Python 2 byte-strings would be unpickled on Python 3 as Unicode strings. See the discussion here: http://bugs.python.org/issue6784 This is basically because many people "do the wrong thing" and use Python 2 byte strings for restoring text. What it means though is that people who "do the right thing" and store binary data in Python 2 byte strings can't use Python 2 pickles from Python 3. It also means that only ascii data can be unpickled. A custom pickler / unpickler is suggested as the solution in this issue. All the best, Michael Foord > I use the encoding "latin1" for transparent byte/unicode conversion (do > not touch the values!). > > This seems to be a bug in Python 3.2. Any suggestion?. > > PS: The bytestream is protocol 2. > > PPS: If there is consensus that this is a real bug, I would create an > issue in the tracker and try to get a minimal testcase. > > - -- > Jesus Cea Avion _/_/ _/_/_/ _/_/_/ > jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ > jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/ > . _/_/ _/_/ _/_/ _/_/ _/_/ > "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ > "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQCVAwUBTWOomplgi5GaxT1NAQLTYAP/U+eqhQ5nIJyBAqSgYwPmkH4DOlMj4JnH > Jgt6okvOV0hRIXlZ7kbWI2l9OuQyUM4gAeTNDSjFaKs9Hswy26Ro6xhtjidivXDS > TKw6ocRx92/eHvgsOdEZjrE0D8l0dOqodZddbXELp2DjpYs9aozzAsjTHqNZDE1L > fujeTOhtUKw= > =/bcO > -----END PGP SIGNATURE----- > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From solipsis at pitrou.net Tue Feb 22 13:25:01 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Tue, 22 Feb 2011 13:25:01 +0100 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 References: <4D63A89A.20609@jcea.es> Message-ID: <20110222132501.64a8b1e0@pitrou.net> On Tue, 22 Feb 2011 13:14:18 +0100 Jesus Cea wrote: > > This seems to be a bug in Python 3.2. Any suggestion?. Report an issue and investigate :) Antoine. From jcea at jcea.es Tue Feb 22 14:35:19 2011 From: jcea at jcea.es (Jesus Cea) Date: Tue, 22 Feb 2011 14:35:19 +0100 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <4D63AA29.9020004@voidspace.org.uk> References: <4D63A89A.20609@jcea.es> <4D63AA29.9020004@voidspace.org.uk> Message-ID: <4D63BB97.8050608@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22/02/11 13:20, Michael Foord wrote: >> Traceback (most recent call last): >> File "", line 1, in >> ValueError: operation forbidden on released memoryview object > > That seems like an odd error, but the decision was made that Python 2 > byte-strings would be unpickled on Python 3 as Unicode strings. This problem seems NOT related to unicode. In fact, when saying 'encoding="latin1"', my "binary" strings should be converted to unicode without any kind of issue (my plan was, then, to scan the datastructure and convert them to native bytes). The fact is that I get a strange error: "ValueError: operation forbidden on released memoryview object". Seems like a bug to me. Google shows no hits. I want to discard any obvious overlooked point. PS: Just checked... Python 3.1.3 imports the pickle just fine. So busy migrating my projects to 3.2 (it was my compromise two years ago :), I don't have time to debug this :). - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTWO7l5lgi5GaxT1NAQJVLQP/fZMxsybbHfkbwDEJ/DVaBSj8VZ2dkO38 oXsH9ojspbxRTv9BCNakKt8SyDMtzJIB6kaZ10qScxftDAGs22xlkpOJyGxBYgNZ Ut5U425YuUTCyFQyYfREWNs2AqUQOWymnXgIlThDS93n1Y+W2S1ovcT9WJaHyebe ZVDabLUZYlw= =IBN8 -----END PGP SIGNATURE----- From eliben at gmail.com Tue Feb 22 15:32:45 2011 From: eliben at gmail.com (Eli Bendersky) Date: Tue, 22 Feb 2011 16:32:45 +0200 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <4D63BB97.8050608@jcea.es> References: <4D63A89A.20609@jcea.es> <4D63AA29.9020004@voidspace.org.uk> <4D63BB97.8050608@jcea.es> Message-ID: > PS: Just checked... Python 3.1.3 imports the pickle just fine. So busy > migrating my projects to 3.2 (it was my compromise two years ago :), I > don't have time to debug this :). > I hope you do have a time to open an issue, though :-) Eli From jcea at jcea.es Tue Feb 22 16:10:07 2011 From: jcea at jcea.es (Jesus Cea) Date: Tue, 22 Feb 2011 16:10:07 +0100 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: References: <4D63A89A.20609@jcea.es> <4D63AA29.9020004@voidspace.org.uk> <4D63BB97.8050608@jcea.es> Message-ID: <4D63D1CF.7000902@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22/02/11 15:32, Eli Bendersky wrote: >> PS: Just checked... Python 3.1.3 imports the pickle just fine. So busy >> migrating my projects to 3.2 (it was my compromise two years ago :), I >> don't have time to debug this :). >> > > I hope you do have a time to open an issue, though :-) > Eli Bugs bug me a lot :). I spend a couple of hours trying to reduce my pickle to something I could post (the original pickle has tons of propietary information): http://bugs.python.org/issue11286 I got a reproductible pickle testcase in only 41 bytes. Seems to be a SERIOUS regression in 3.2. I can't progress further. Pickle internals are out of my expertise. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTWPRz5lgi5GaxT1NAQKwdgQAjV5zKB3LhuVMU+JDbPeZjo/oFu1Yz++Z 1xFPuXTtaeMGMYuQH16j5rghqp90Q4u0M/VGaXI99uxcyTR9fpGGVEBE2L0qnVTg 1sbRyCaaVrPDVju3tTonw5QEe7eXnsec9INuK7KCIXUqEZK7klbqoWFFflU5g/Ui hcxe8Zt6lQE= =nWu0 -----END PGP SIGNATURE----- From techtonik at gmail.com Tue Feb 22 16:41:47 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Tue, 22 Feb 2011 17:41:47 +0200 Subject: [Python-Dev] Actual Mercurial Roadmap for February (Was: svn outage on Friday) In-Reply-To: References: Message-ID: On Fri, Feb 18, 2011 at 4:00 PM, Dirkjan Ochtman wrote: > On Fri, Feb 18, 2011 at 14:41, anatoly techtonik wrote: >> Do you have a public list of stuff to be done (i.e. Roadmap)? >> BTW, what is the size of Mercurial clone for Python repository? > > There is a TODO file in the pymigr repo (though I think that is > currently inaccessible). Can you provide a link? I don't know where to search. Should we open a src.python.org domain? > I don't have a recent optimized clone to check the size of, yet. What is the size of non-optimized clone then? I know that a clone of such relatively small project as MoinMoin is about 250Mb. ISTM that Python repository may take more than 1GB, and that's not acceptable IMHO. BTW, what do you mean by optimization - I hope not stripping the history? [1] http://moinmo.in/MoinMoin2.0/InfrastructurePlans -- anatoly t. From john at arbash-meinel.com Tue Feb 22 17:56:10 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 22 Feb 2011 10:56:10 -0600 Subject: [Python-Dev] Actual Mercurial Roadmap for February (Was: svn outage on Friday) In-Reply-To: References: Message-ID: <4D63EAAA.8010106@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/22/2011 9:41 AM, anatoly techtonik wrote: > On Fri, Feb 18, 2011 at 4:00 PM, Dirkjan Ochtman wrote: >> On Fri, Feb 18, 2011 at 14:41, anatoly techtonik wrote: >>> Do you have a public list of stuff to be done (i.e. Roadmap)? >>> BTW, what is the size of Mercurial clone for Python repository? >> >> There is a TODO file in the pymigr repo (though I think that is >> currently inaccessible). > > Can you provide a link? I don't know where to search. Should we open a > src.python.org domain? > >> I don't have a recent optimized clone to check the size of, yet. > > What is the size of non-optimized clone then? I know that a clone of > such relatively small project as MoinMoin is about 250Mb. ISTM that > Python repository may take more than 1GB, and that's not acceptable > IMHO. BTW, what do you mean by optimization - I hope not stripping the > history? Mercurial repositories are sensitive to the order that data is inserted into them. So re-ordering the topological insert can dramatically improve compression. The quick overview is that in a given file's history, each diff is computed to the previous text in that file. So if you have a history like: foo | \ foo baz bar foo | / baz foo bar This can be stored as either: foo +bar -bar +baz +bar This matters more if you have a long divergent history for a while: A |\ B C | | D E | | F G : : X Y |/ Z In this case, you could end up with contents that look like: A +B +D +F +X -BDFX+C +E +G +Y +ABDFXZ Or you could have the history 'interleaved': A +B -B+C -C+BD -BD+CE -BDF+CEG -... There are tools that take a history file, and rewrite it to be more compact. I don't know much more than that myself. But especially with something like an svn conversion which probably works on each revision at a time, where people are committing to different branches concurrently, I would imagine the conversion could easily end up in the pessimistic case. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1j6qoACgkQJdeBCYSNAAPzPgCdEOJsHf4Xf4lZH+jHX42FQb8J sQoAn3JuCmDcsyv0JZpXtbVJoGewA+7t =M8DI -----END PGP SIGNATURE----- From ethan at stoneleaf.us Tue Feb 22 19:43:28 2011 From: ethan at stoneleaf.us (Ethan Furman) Date: Tue, 22 Feb 2011 10:43:28 -0800 Subject: [Python-Dev] %-formatting depracation Message-ID: <4D6403D0.4030107@stoneleaf.us> Greetings! According to these release notes in Python 3.0, %-formatting will be going away. http://docs.python.org/release/3.0.1/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting However, I was unable to find any further evidence of actual deprecation in 3.1 or 3.2... does anybody know the status of this? ~Ethan~ From brett at python.org Tue Feb 22 19:55:26 2011 From: brett at python.org (Brett Cannon) Date: Tue, 22 Feb 2011 10:55:26 -0800 Subject: [Python-Dev] Const-correctness in C-API Object Protocol In-Reply-To: References: Message-ID: On Mon, Feb 21, 2011 at 15:34, David Claridge wrote: > Hi, > > I was wondering if there is some reason why C API functions like > PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments > rather than const char*s? If there is some reason these methods will > modify their string arguments, it would be nice if it was documented, > because at the moment it's unclear whether it is safe to cast a string > literal to char* in these cases. For instance it seems reasonable that > I should be able to call PySys_GetObject("path") without having to > deal with a 'deprecated conversion from string constant to ?char*?' > error. > Probably because (a) the person who first wrote them used char* instead of const char*, and (b) it gives us API flexibility by not promising to not alter the char array at some point in the future. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Tue Feb 22 19:51:57 2011 From: brett at python.org (Brett Cannon) Date: Tue, 22 Feb 2011 10:51:57 -0800 Subject: [Python-Dev] %-formatting depracation In-Reply-To: <4D6403D0.4030107@stoneleaf.us> References: <4D6403D0.4030107@stoneleaf.us> Message-ID: On Tue, Feb 22, 2011 at 10:43, Ethan Furman wrote: > Greetings! > > According to these release notes in Python 3.0, %-formatting will be going > away. > > > http://docs.python.org/release/3.0.1/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting > > > However, I was unable to find any further evidence of actual deprecation in > 3.1 or 3.2... does anybody know the status of this? > There isn't one. =) The very long term view is for %-formatting to go away, but that's as far as the thinking has gone. There are currently no plans to introduce any deprecation warning, and I highly doubt we will even remove the feature in Python 3, giving you probably at least another decade of use at our current major version release schedule. =) -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Tue Feb 22 20:06:41 2011 From: guido at python.org (Guido van Rossum) Date: Tue, 22 Feb 2011 11:06:41 -0800 Subject: [Python-Dev] Const-correctness in C-API Object Protocol In-Reply-To: References: Message-ID: On Tue, Feb 22, 2011 at 10:55 AM, Brett Cannon wrote: > > > On Mon, Feb 21, 2011 at 15:34, David Claridge wrote: >> >> Hi, >> >> I was wondering if there is some reason why C API functions like >> PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments >> rather than const char*s? If there is some reason these methods will >> modify their string arguments, it would be nice if it was documented, >> because at the moment it's unclear whether it is safe to cast a string >> literal to char* in these cases. For instance it seems reasonable that >> I should be able to call PySys_GetObject("path") without having to >> deal with a 'deprecated conversion from string constant to ?char*?' >> error. > > Probably because (a) the person who first wrote them used char* instead of > const char*, and (b) it gives us API flexibility by not promising to not > alter the char array at some point in the future. I'm sorry, but (b) does not make sense. These APIs typically get passed string literals and modifying the argument would be a bad idea. FWIW, in Python 3.2, PySys_GetObject() is actually using const char *. I don't see a problem with changing PyObject_CallMethod() and its variations as well. Though I do not get that warning -- which compiler and version issues it? Is it a C or a C++ compiler? (If it is a C++ compiler I'm tempted to reject the complaint -- CPython is not written in C++ even though at various points we try to keep the headers usable with C++ as well as with C.) -- --Guido van Rossum (python.org/~guido) From eric at trueblade.com Tue Feb 22 20:04:46 2011 From: eric at trueblade.com (Eric Smith) Date: Tue, 22 Feb 2011 14:04:46 -0500 Subject: [Python-Dev] %-formatting depracation In-Reply-To: <4D6403D0.4030107@stoneleaf.us> References: <4D6403D0.4030107@stoneleaf.us> Message-ID: <4D6408CE.5050406@trueblade.com> On 02/22/2011 01:43 PM, Ethan Furman wrote: > Greetings! > > According to these release notes in Python 3.0, %-formatting will be > going away. > > http://docs.python.org/release/3.0.1/whatsnew/3.0.html#pep-3101-a-new-approach-to-string-formatting > > > > However, I was unable to find any further evidence of actual deprecation > in 3.1 or 3.2... does anybody know the status of this? The last thread on this I have a reference to was in September 2009. I think was basically the outcome: http://mail.python.org/pipermail/python-dev/2009-September/092399.html So there will be no deprecation, just a gradual shift to PEP 3101 formatting. Eric. From eric at trueblade.com Tue Feb 22 20:09:56 2011 From: eric at trueblade.com (Eric Smith) Date: Tue, 22 Feb 2011 14:09:56 -0500 Subject: [Python-Dev] Const-correctness in C-API Object Protocol In-Reply-To: References: Message-ID: <4D640A04.7080209@trueblade.com> On 02/22/2011 01:55 PM, Brett Cannon wrote: > > > On Mon, Feb 21, 2011 at 15:34, David Claridge > wrote: > > Hi, > > I was wondering if there is some reason why C API functions like > PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments > rather than const char*s? If there is some reason these methods will > modify their string arguments, it would be nice if it was documented, > because at the moment it's unclear whether it is safe to cast a string > literal to char* in these cases. For instance it seems reasonable that > I should be able to call PySys_GetObject("path") without having to > deal with a 'deprecated conversion from string constant to ?char*?' > error. > > > Probably because (a) the person who first wrote them used char* instead > of const char*, and (b) it gives us API flexibility by not promising to > not alter the char array at some point in the future. Also changing it now would be a giant hassle, leading to so-called "const poisoning" where many, many APIs need to be changed before everything would again work. From solipsis at pitrou.net Tue Feb 22 20:25:44 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Tue, 22 Feb 2011 20:25:44 +0100 Subject: [Python-Dev] Const-correctness in C-API Object Protocol References: Message-ID: <20110222202544.4009b85e@pitrou.net> On Tue, 22 Feb 2011 11:06:41 -0800 Guido van Rossum wrote: > > > > Probably because (a) the person who first wrote them used char* instead of > > const char*, and (b) it gives us API flexibility by not promising to not > > alter the char array at some point in the future. > > I'm sorry, but (b) does not make sense. These APIs typically get > passed string literals and modifying the argument would be a bad idea. +1. If we started mutating strings passed to such APIs, it would certainly break a lot of third-party code. > FWIW, in Python 3.2, PySys_GetObject() is actually using const char *. > I don't see a problem with changing PyObject_CallMethod() and its > variations as well. > > Though I do not get that warning -- which compiler and version issues > it? Is it a C or a C++ compiler? Well, which warning are you talking about? I don't think changing a "char *" to a "const char *" specification would be harmful, since it makes the API more tolerant: with the latter, you can pass it both const and non-const strings. Regards Antoine. From reid.kleckner at gmail.com Tue Feb 22 21:21:35 2011 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Tue, 22 Feb 2011 15:21:35 -0500 Subject: [Python-Dev] Const-correctness in C-API Object Protocol In-Reply-To: <4D640A04.7080209@trueblade.com> References: <4D640A04.7080209@trueblade.com> Message-ID: On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith wrote: > Also changing it now would be a giant hassle, leading to so-called "const > poisoning" where many, many APIs need to be changed before everything would > again work. The poisoning will not break any users of the API, though, since they can pass const and non-const pointers. Internally Python would have to go through and add const keywords as appropriate when passing strings around. IMO it's worth it to not cause this warning for users. Reid From stefan_ml at behnel.de Tue Feb 22 21:48:51 2011 From: stefan_ml at behnel.de (Stefan Behnel) Date: Tue, 22 Feb 2011 21:48:51 +0100 Subject: [Python-Dev] Const-correctness in C-API Object Protocol In-Reply-To: References: <4D640A04.7080209@trueblade.com> Message-ID: Reid Kleckner, 22.02.2011 21:21: > On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith wrote: >> Also changing it now would be a giant hassle, leading to so-called "const >> poisoning" where many, many APIs need to be changed before everything would >> again work. > > The poisoning will not break any users of the API, though, since they > can pass const and non-const pointers. Internally Python would have > to go through and add const keywords as appropriate when passing > strings around. IMO it's worth it to not cause this warning for > users. The problem is that Python's C-API functions are used both internally and externally, so changes like this can easily impact other public API functions because the function being changed uses them. I think that's what "const poisoning" refers to here. Stefan From solipsis at pitrou.net Tue Feb 22 21:55:46 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Tue, 22 Feb 2011 21:55:46 +0100 Subject: [Python-Dev] Const-correctness in C-API Object Protocol References: <4D640A04.7080209@trueblade.com> Message-ID: <20110222215546.21bfdad1@pitrou.net> On Tue, 22 Feb 2011 21:48:51 +0100 Stefan Behnel wrote: > Reid Kleckner, 22.02.2011 21:21: > > On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith wrote: > >> Also changing it now would be a giant hassle, leading to so-called "const > >> poisoning" where many, many APIs need to be changed before everything would > >> again work. > > > > The poisoning will not break any users of the API, though, since they > > can pass const and non-const pointers. Internally Python would have > > to go through and add const keywords as appropriate when passing > > strings around. IMO it's worth it to not cause this warning for > > users. > > The problem is that Python's C-API functions are used both internally and > externally, so changes like this can easily impact other public API > functions because the function being changed uses them. How so? From python-dev at masklinn.net Tue Feb 22 22:17:43 2011 From: python-dev at masklinn.net (Xavier Morel) Date: Tue, 22 Feb 2011 22:17:43 +0100 Subject: [Python-Dev] Const-correctness in C-API Object Protocol In-Reply-To: <20110222215546.21bfdad1@pitrou.net> References: <4D640A04.7080209@trueblade.com> <20110222215546.21bfdad1@pitrou.net> Message-ID: On 2011-02-22, at 21:55 , Antoine Pitrou wrote: > On Tue, 22 Feb 2011 21:48:51 +0100 > Stefan Behnel wrote: >> Reid Kleckner, 22.02.2011 21:21: >>> On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith wrote: >>>> Also changing it now would be a giant hassle, leading to so-called "const >>>> poisoning" where many, many APIs need to be changed before everything would >>>> again work. >>> >>> The poisoning will not break any users of the API, though, since they >>> can pass const and non-const pointers. Internally Python would have >>> to go through and add const keywords as appropriate when passing >>> strings around. IMO it's worth it to not cause this warning for >>> users. >> The problem is that Python's C-API functions are used both internally and >> externally, so changes like this can easily impact other public API >> functions because the function being changed uses them. > How so? If the parameters are passed from the newly const'ed function to an other public-API function, that one will have to be const'ed as well (or the const will have to be cast away which generally isn't considered good style and may lead to UBs), which may cascade into yet an other public-API function, the end result being that numerous functions would have to be const'ed: > Adding const qualification may propagate through a program; as you > add const qualifiers, still more become necessary. This phenomenon is > sometimes called "const-poisoning." Const-poisoning can frequently > lead to violations of recommendation EXP05-C. Do not cast away a const > qualification. While const qualification is a good idea, the costs may > outweigh the value in the remediation of existing code. https://www.securecoding.cert.org/confluence/display/seccode/STR05-C.+Use+pointers+to+const+when+referring+to+string+literals From guido at python.org Tue Feb 22 22:22:51 2011 From: guido at python.org (Guido van Rossum) Date: Tue, 22 Feb 2011 13:22:51 -0800 Subject: [Python-Dev] Const-correctness in C-API Object Protocol In-Reply-To: References: <4D640A04.7080209@trueblade.com> <20110222215546.21bfdad1@pitrou.net> Message-ID: On Tue, Feb 22, 2011 at 1:17 PM, Xavier Morel wrote: > On 2011-02-22, at 21:55 , Antoine Pitrou wrote: >> On Tue, 22 Feb 2011 21:48:51 +0100 >> Stefan Behnel wrote: >>> Reid Kleckner, 22.02.2011 21:21: >>>> On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith wrote: >>>>> Also changing it now would be a giant hassle, leading to so-called "const >>>>> poisoning" where many, many APIs need to be changed before everything would >>>>> again work. >>>> >>>> The poisoning will not break any users of the API, though, since they >>>> can pass const and non-const pointers. ?Internally Python would have >>>> to go through and add const keywords as appropriate when passing >>>> strings around. ?IMO it's worth it to not cause this warning for >>>> users. >>> The problem is that Python's C-API functions are used both internally and >>> externally, so changes like this can easily impact other public API >>> functions because the function being changed uses them. >> How so? > > If the parameters are passed from the newly const'ed function to an > other public-API function, that one will have to be const'ed as well > (or the const will have to be cast away which generally isn't > considered good style and may lead to UBs), which may cascade into yet > an other public-API function, the end result being that numerous > functions would have to be const'ed: I tried this in my codebase. I found no need for further const propagation in this particular case. >> Adding const qualification may propagate through a program; as you >> add const qualifiers, still more become necessary. This phenomenon is >> sometimes called "const-poisoning." Const-poisoning can frequently >> lead to violations of recommendation EXP05-C. Do not cast away a const >> qualification. While const qualification is a good idea, the costs may >> outweigh the value in the remediation of existing code. > > https://www.securecoding.cert.org/confluence/display/seccode/STR05-C.+Use+pointers+to+const+when+referring+to+string+literals > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) From ncoghlan at gmail.com Tue Feb 22 22:52:23 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 23 Feb 2011 07:52:23 +1000 Subject: [Python-Dev] %-formatting depracation In-Reply-To: References: <4D6403D0.4030107@stoneleaf.us> Message-ID: On Wed, Feb 23, 2011 at 4:51 AM, Brett Cannon wrote: > The very long term view is for %-formatting to go away, but that's as far as > the thinking has gone. There are currently no plans to introduce any > deprecation warning, and I highly doubt we will even remove the feature in > Python 3, giving you probably at least another decade of use at our current > major version release schedule. =) This. Without a systematic way to detect and convert %-style to {}-style formatting, enforcing the switch in the 3.x series just isn't practical. Heck, we still haven't figured out how to convert a lot of higher level APIs to the new scheme in a backwards compatible way (that's why modules like logging still default to %-style, with {}-style only available via options and wrapper objects). Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From martin at v.loewis.de Tue Feb 22 22:57:16 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Tue, 22 Feb 2011 22:57:16 +0100 Subject: [Python-Dev] Const-correctness in C-API Object Protocol In-Reply-To: <4D640A04.7080209@trueblade.com> References: <4D640A04.7080209@trueblade.com> Message-ID: <4D64313C.1020309@v.loewis.de> > Also changing it now would be a giant hassle, leading to so-called > "const poisoning" where many, many APIs need to be changed before > everything would again work. We have been adding const to many places over the years. I think the specific case was just missed (i.e. nobody cared about adding const there). Regards, Martin From solipsis at pitrou.net Tue Feb 22 23:03:00 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Tue, 22 Feb 2011 23:03:00 +0100 Subject: [Python-Dev] %-formatting depracation References: <4D6403D0.4030107@stoneleaf.us> Message-ID: <20110222230300.46e426f2@pitrou.net> On Wed, 23 Feb 2011 07:52:23 +1000 Nick Coghlan wrote: > On Wed, Feb 23, 2011 at 4:51 AM, Brett Cannon wrote: > > The very long term view is for %-formatting to go away, but that's as far as > > the thinking has gone. There are currently no plans to introduce any > > deprecation warning, and I highly doubt we will even remove the feature in > > Python 3, giving you probably at least another decade of use at our current > > major version release schedule. =) > > This. Without a systematic way to detect and convert %-style to > {}-style formatting, enforcing the switch in the 3.x series just isn't > practical. Heck, we still haven't figured out how to convert a lot of > higher level APIs to the new scheme in a backwards compatible way > (that's why modules like logging still default to %-style, with > {}-style only available via options and wrapper objects). I think there are many people still finding %-style more practical for simple uses, so this might be a case of "practicality beats purity" over "there should be one obvious way to do it". Regards Antoine. From martin at v.loewis.de Tue Feb 22 23:06:36 2011 From: martin at v.loewis.de (=?windows-1252?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Tue, 22 Feb 2011 23:06:36 +0100 Subject: [Python-Dev] Const-correctness in C-API Object Protocol In-Reply-To: <20110222202544.4009b85e@pitrou.net> References: <20110222202544.4009b85e@pitrou.net> Message-ID: <4D64336C.5080206@v.loewis.de> >> Though I do not get that warning -- which compiler and version issues >> it? Is it a C or a C++ compiler? > > Well, which warning are you talking about? I think Guido assumed that the OP was getting actual complaints from some actual compiler - else he wouldn't have asked the question. However, he didn't actually say he got compile issues. If you compile #include int main() { const char* s = "stdin"; PyObject_CallMethod(0, s, s); } with a g++, you get a.cc: In function ?int main()?: a.cc:6: error: invalid conversion from ?const char*? to ?char*? a.cc:6: error: initializing argument 2 of ?PyObject* PyObject_CallMethod(PyObject*, char*, char*, ...)? a.cc:6: error: invalid conversion from ?const char*? to ?char*? a.cc:6: error: initializing argument 3 of ?PyObject* PyObject_CallMethod(PyObject*, char*, char*, ...)? If you compile #include int main() { PyObject_CallMethod(0, "stdin", "stdin"); } you get a.cc: In function ?int main()?: a.cc:5: warning: deprecated conversion from string constant to ?char*? a.cc:5: warning: deprecated conversion from string constant to ?char*? Since most people likely use string literals, and since g++ only started warning about the deprecated conversion only recently, most people probably haven't run into the issue. Regards, Martin From martin at v.loewis.de Tue Feb 22 23:11:09 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Tue, 22 Feb 2011 23:11:09 +0100 Subject: [Python-Dev] %-formatting depracation In-Reply-To: References: <4D6403D0.4030107@stoneleaf.us> Message-ID: <4D64347D.6070501@v.loewis.de> > The very long term view is for %-formatting to go away Add to that that this view isn't universally shared among contributors. Many of us would rather see % formatting stay indefinitely. I regularly use it for new code. Regards, Martin From ncoghlan at gmail.com Tue Feb 22 23:13:44 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 23 Feb 2011 08:13:44 +1000 Subject: [Python-Dev] %-formatting depracation In-Reply-To: <20110222230300.46e426f2@pitrou.net> References: <4D6403D0.4030107@stoneleaf.us> <20110222230300.46e426f2@pitrou.net> Message-ID: On Wed, Feb 23, 2011 at 8:03 AM, Antoine Pitrou wrote: > I think there are many people still finding %-style more practical for > simple uses, A lot of the sting went out of that objection when field autonumbering was added to new-style formatting ("'%s' % (obj,)" vs "'{}'.format(obj)" as the minimal case that correctly handles tuples). The addition of format_map() reduces it even further. > so this might be a case of "practicality beats purity" > over "there should be one obvious way to do it". I agree with that part though, just for historical reasons rather than seeing much in the way in the way of inherent advantages with %-style formatting. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From steve at holdenweb.com Wed Feb 23 00:01:06 2011 From: steve at holdenweb.com (Steve Holden) Date: Tue, 22 Feb 2011 15:01:06 -0800 Subject: [Python-Dev] Fwd: deep question re dict as formatting input References: Message-ID: One of the students on an introductory Python 3 class asks a very good question about string formatting. This could be because the course materials are misleading, so I would like to understand. It would appear from tests that "{0[X]}".format(...) first tries to convert the string "X" to in integer. If it succeeds then __getitem__() is called with the integer as an argument, otherwise it is called with the string itself as an argument. Is this correct? The documentation at http://docs.python.org/library/string.html#formatspec is silent on whether strings were ever intended to be used as subscripts. Does this seem sensible? Was it considered during design? Should I alter the materials so that only integer subscripts are used? regards Steve Begin forwarded message: > From: kirby urner > Date: February 22, 2011 2:31:08 PM PST > To: Steve Holden > Subject: deep question re dict as formatting input > >>>> d > {'Steve': 'Holden', 'Tim': 'Peters', 'Guido': 'van Rossum', '1': > 'string', 1: 'integer'} >>>> "{0[Guido]} is cool".format(d) > 'van Rossum is cool' >>>> "{0[1]} is cool".format(d) > 'integer is cool' >>>> "{0['1']} is cool".format(d) > Traceback (most recent call last): > File "", line 1, in > "{0['1']} is cool".format(d) > KeyError: "'1'" > > > Student question: > > Good morning! > > Question on .format(), interactive session follows: > > --> d = {"Steve": "Holden", > ... "Guido": "van Rossum", > ... "Tim": "Peters", > ... "1": "string", > ... 1: "integer"} > > --> d > {'Steve': 'Holden', 'Tim': 'Peters', '1': 'string', 1: 'integer', > 'Guido': 'van Rossum'} > > --> d[1] > 'integer' > > --> d['1'] > 'string' > > --> "{dct[1]}".format(dct=d) > 'integer' > > --> "{dct[Guido]}".format(dct=d) > 'van Rossum' > > --> "{dct['1']}".format(dct=d) > Traceback (most recent call last): > File "", line 1, in > KeyError: "'1'" > > Question: If {dct[Guido]} treats Guido as str, why doesn't {dct[1]} > treate 1 as str? Feels like an automatic conversion from str to int. > Furthermore, how does one access the key '1' in a format statement? > > ~Ethan~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.belopolsky at gmail.com Wed Feb 23 00:08:01 2011 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Tue, 22 Feb 2011 18:08:01 -0500 Subject: [Python-Dev] Const-correctness in C-API Object Protocol In-Reply-To: References: Message-ID: On Mon, Feb 21, 2011 at 6:34 PM, David Claridge wrote: .. > I was wondering if there is some reason why C API functions like > PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments > rather than const char*s? The later is addressed by issue 1699259 . It looks like const was added in 3.2, but deemed not important enough to backport to 2.7. The issue is still open, so interested parties can argue for backport there. The former (PyObject_CallMethod) is similarly subject of an open issue in a commit review stage: . From daave at daave.com Wed Feb 23 00:14:10 2011 From: daave at daave.com (David Claridge) Date: Wed, 23 Feb 2011 10:14:10 +1100 Subject: [Python-Dev] Const-correctness in C-API Object Protocol In-Reply-To: <4D64336C.5080206@v.loewis.de> References: <20110222202544.4009b85e@pitrou.net> <4D64336C.5080206@v.loewis.de> Message-ID: > If you compile > > #include > > int main() > { > ? ?PyObject_CallMethod(0, "stdin", "stdin"); > } > > you get > > a.cc: In function ?int main()?: > a.cc:5: warning: deprecated conversion from string constant to ?char*? > a.cc:5: warning: deprecated conversion from string constant to ?char*? > > Since most people likely use string literals, and since g++ only started > warning about the deprecated conversion only recently, most people > probably haven't run into the issue. > > Regards, > Martin This is precisely the warning I've been getting, I've been embedding Python 2.6 in an application built using g++ 4.4. > The later is addressed by issue 1699259 > . ?It looks like const was added > in 3.2, but deemed not important enough to backport to 2.7. ?The issue > is still open, so interested parties can argue for backport there. > > The former (PyObject_CallMethod) is similarly subject of an open issue > in a commit review stage: . Thanks, I'll add my 2c worth on those issues. Even if it is eventually decided not to backport those patches to 2.7, it would be nice if the documentation could be updated to indicate that strings passed to those functions won't be modified, so that API users like myself can feel a little safer when passing literals in, without having to trawl through the interpreter source to see if the arguments are modified. Thanks, -- David Claridge http://daave.com From alexander.belopolsky at gmail.com Wed Feb 23 00:15:08 2011 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Tue, 22 Feb 2011 18:15:08 -0500 Subject: [Python-Dev] Fwd: deep question re dict as formatting input In-Reply-To: References: Message-ID: On Tue, Feb 22, 2011 at 6:01 PM, Steve Holden wrote: > ... It would appear from tests > that "{0[X]}".format(...) first tries to convert the string "X" to in > integer. If it succeeds then __getitem__() is called with the integer as an > argument, otherwise it is called with the string itself as an argument. Is > this correct? This is addressed in the PEP 3101: """ The rules for parsing an item key are very simple. If it starts with a digit, then it is treated as a number, otherwise it is used as a string. """ http://www.python.org/dev/peps/pep-3101/ If current implementation does something more involved, I would say it is a bug. From solipsis at pitrou.net Wed Feb 23 00:18:59 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 23 Feb 2011 00:18:59 +0100 Subject: [Python-Dev] Const-correctness in C-API Object Protocol References: Message-ID: <20110223001859.5113aad5@pitrou.net> On Tue, 22 Feb 2011 18:08:01 -0500 Alexander Belopolsky wrote: > On Mon, Feb 21, 2011 at 6:34 PM, David Claridge wrote: > .. > > I was wondering if there is some reason why C API functions like > > PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments > > rather than const char*s? > > The later is addressed by issue 1699259 > . It looks like const was added > in 3.2, but deemed not important enough to backport to 2.7. The issue > is still open, so interested parties can argue for backport there. I don't think it's a good idea to backport visible API changes. (someone successfully compiling on 2.7.N could then have users complaining that compilation fails on 2.7.N-1). Moreover, it doesn't really fix a bug. Regards Antoine. From eric at trueblade.com Wed Feb 23 00:08:50 2011 From: eric at trueblade.com (Eric Smith) Date: Tue, 22 Feb 2011 18:08:50 -0500 Subject: [Python-Dev] Fwd: deep question re dict as formatting input In-Reply-To: References: Message-ID: <4D644202.7010505@trueblade.com> Quoting PEP 3101: An example of the 'getitem' syntax: "My name is {0[name]}".format(dict(name='Fred')) It should be noted that the use of 'getitem' within a format string is much more limited than its conventional usage. In the above example, the string 'name' really is the literal string 'name', not a variable named 'name'. The rules for parsing an item key are very simple. If it starts with a digit, then it is treated as a number, otherwise it is used as a string. On 2/22/2011 6:01 PM, Steve Holden wrote: > One of the students on an introductory Python 3 class asks a very good > question about string formatting. This could be because the course > materials are misleading, so I would like to understand. It would appear > from tests that "{0[X]}".format(...) first tries to convert the string > "X" to in integer. If it succeeds then __getitem__() is called with the > integer as an argument, otherwise it is called with the string itself as > an argument. Is this correct? > > The documentation at > http://docs.python.org/library/string.html#formatspec is silent on > whether strings were ever intended to be used as subscripts. Does this > seem sensible? Was it considered during design? Should I alter the > materials so that only integer subscripts are used? > > regards > Steve > > > Begin forwarded message: > >> *From: *kirby urner > >> *Date: *February 22, 2011 2:31:08 PM PST >> *To: *Steve Holden > >> *Subject: **deep question re dict as formatting input* >> >>>>> d >> {'Steve': 'Holden', 'Tim': 'Peters', 'Guido': 'van Rossum', '1': >> 'string', 1: 'integer'} >>>>> "{0[Guido]} is cool".format(d) >> 'van Rossum is cool' >>>>> "{0[1]} is cool".format(d) >> 'integer is cool' >>>>> "{0['1']} is cool".format(d) >> Traceback (most recent call last): >> File "", line 1, in >> "{0['1']} is cool".format(d) >> KeyError: "'1'" >> >> >> Student question: >> >> Good morning! >> >> Question on .format(), interactive session follows: >> >> --> d = {"Steve": "Holden", >> ... "Guido": "van Rossum", >> ... "Tim": "Peters", >> ... "1": "string", >> ... 1: "integer"} >> >> --> d >> {'Steve': 'Holden', 'Tim': 'Peters', '1': 'string', 1: 'integer', >> 'Guido': 'van Rossum'} >> >> --> d[1] >> 'integer' >> >> --> d['1'] >> 'string' >> >> --> "{dct[1]}".format(dct=d) >> 'integer' >> >> --> "{dct[Guido]}".format(dct=d) >> 'van Rossum' >> >> --> "{dct['1']}".format(dct=d) >> Traceback (most recent call last): >> File "", line 1, in >> KeyError: "'1'" >> >> Question: If {dct[Guido]} treats Guido as str, why doesn't {dct[1]} >> treate 1 as str? Feels like an automatic conversion from str to int. >> Furthermore, how does one access the key '1' in a format statement? >> >> ~Ethan~ > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com From steve at holdenweb.com Wed Feb 23 00:28:10 2011 From: steve at holdenweb.com (Steve Holden) Date: Tue, 22 Feb 2011 15:28:10 -0800 Subject: [Python-Dev] Fwd: deep question re dict as formatting input In-Reply-To: <4D644202.7010505@trueblade.com> References: <4D644202.7010505@trueblade.com> Message-ID: On Feb 22, 2011, at 3:08 PM, Eric Smith wrote: > Quoting PEP 3101: > > An example of the 'getitem' syntax: > > "My name is {0[name]}".format(dict(name='Fred')) > > It should be noted that the use of 'getitem' within a format string > is much more limited than its conventional usage. In the above example, > the string 'name' really is the literal string 'name', not a variable > named 'name'. The rules for parsing an item key are very simple. > If it starts with a digit, then it is treated as a number, otherwise > it is used as a string. > That's not strictly true: >>> d = {"Steve":"Holden", "Guido":"van Rossum", 21.2:"float"} >>> d[21.1] Traceback (most recent call last): File "", line 1, in KeyError: 21.1 >>> d[21.2] 'float' >>> "{0[21.2]}".format(d) Traceback (most recent call last): File "", line 1, in KeyError: '21.2' >>> But I take your point, and should have thought to read the PEP. Thanks! Kirby: Please apologize to Ethan. I can't remember being aware of the PEP 3101 specification quoted by Eric above. We will probably need to modify the course materials to take this wrinkle into account (at least by demonstrating that we are aware of it). regards Steve > > On 2/22/2011 6:01 PM, Steve Holden wrote: >> One of the students on an introductory Python 3 class asks a very good >> question about string formatting. This could be because the course >> materials are misleading, so I would like to understand. It would appear >> from tests that "{0[X]}".format(...) first tries to convert the string >> "X" to in integer. If it succeeds then __getitem__() is called with the >> integer as an argument, otherwise it is called with the string itself as >> an argument. Is this correct? >> >> The documentation at >> http://docs.python.org/library/string.html#formatspec is silent on >> whether strings were ever intended to be used as subscripts. Does this >> seem sensible? Was it considered during design? Should I alter the >> materials so that only integer subscripts are used? >> >> regards >> Steve >> >> >> Begin forwarded message: >> >>> *From: *kirby urner > >>> *Date: *February 22, 2011 2:31:08 PM PST >>> *To: *Steve Holden > >>> *Subject: **deep question re dict as formatting input* >>> >>>>>> d >>> {'Steve': 'Holden', 'Tim': 'Peters', 'Guido': 'van Rossum', '1': >>> 'string', 1: 'integer'} >>>>>> "{0[Guido]} is cool".format(d) >>> 'van Rossum is cool' >>>>>> "{0[1]} is cool".format(d) >>> 'integer is cool' >>>>>> "{0['1']} is cool".format(d) >>> Traceback (most recent call last): >>> File "", line 1, in >>> "{0['1']} is cool".format(d) >>> KeyError: "'1'" >>> >>> >>> Student question: >>> >>> Good morning! >>> >>> Question on .format(), interactive session follows: >>> >>> --> d = {"Steve": "Holden", >>> ... "Guido": "van Rossum", >>> ... "Tim": "Peters", >>> ... "1": "string", >>> ... 1: "integer"} >>> >>> --> d >>> {'Steve': 'Holden', 'Tim': 'Peters', '1': 'string', 1: 'integer', >>> 'Guido': 'van Rossum'} >>> >>> --> d[1] >>> 'integer' >>> >>> --> d['1'] >>> 'string' >>> >>> --> "{dct[1]}".format(dct=d) >>> 'integer' >>> >>> --> "{dct[Guido]}".format(dct=d) >>> 'van Rossum' >>> >>> --> "{dct['1']}".format(dct=d) >>> Traceback (most recent call last): >>> File "", line 1, in >>> KeyError: "'1'" >>> >>> Question: If {dct[Guido]} treats Guido as str, why doesn't {dct[1]} >>> treate 1 as str? Feels like an automatic conversion from str to int. >>> Furthermore, how does one access the key '1' in a format statement? >>> >>> ~Ethan~ >> >> >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: http://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com > From alexander.belopolsky at gmail.com Wed Feb 23 00:30:01 2011 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Tue, 22 Feb 2011 18:30:01 -0500 Subject: [Python-Dev] Const-correctness in C-API Object Protocol In-Reply-To: <20110223001859.5113aad5@pitrou.net> References: <20110223001859.5113aad5@pitrou.net> Message-ID: On Tue, Feb 22, 2011 at 6:18 PM, Antoine Pitrou wrote: .. > I don't think it's a good idea to backport visible API changes. > (someone successfully compiling on 2.7.N could then have users > complaining that compilation fails on 2.7.N-1). > Moreover, it doesn't really fix a bug. That was the argument that I voiced http://bugs.python.org/issue1699259#msg119032, but I cannot really think of the code that would be broken by changing the type of an API function *argument* from char * to const char *. Given that 2.7 is an odd-ball with extended maintenance period, I am not sure "it doesn't really fix a bug" argument is dispositive. I am still -0 on backport, however. From orsenthil at gmail.com Wed Feb 23 00:32:45 2011 From: orsenthil at gmail.com (Senthil Kumaran) Date: Wed, 23 Feb 2011 07:32:45 +0800 Subject: [Python-Dev] Fwd: deep question re dict as formatting input In-Reply-To: References: Message-ID: > On Tue, Feb 22, 2011 at 6:01 PM, Steve Holden wrote: >> ... It would appear from tests >> that "{0[X]}".format(...) first tries to convert the string "X" to in >> integer. If it succeeds then __getitem__() is called with the integer as an >> argument, otherwise it is called with the string itself as an argument. Is >> this correct? > > This is addressed in the PEP 3101: > """ > ? ?The rules for parsing an item key are very simple. > ? ?If it starts with a digit, then it is treated as a number, otherwise > ? ?it is used as a string. > """ http://www.python.org/dev/peps/pep-3101/ To the other question : > Furthermore, how does one access the key '1' in a format statement? > ~Ethan~ I think, parsing rule already helps to understand the problem with the key like '1'. The PEP also explicitly states that: """ Because keys are not quote-delimited, it is not possible to specify arbitrary dictionary keys (e.g., the strings "10" or ":-]") from within a format string. """ -- Senthil From anikom15 at gmail.com Wed Feb 23 00:36:00 2011 From: anikom15 at gmail.com (Westley =?ISO-8859-1?Q?Mart=EDnez?=) Date: Tue, 22 Feb 2011 15:36:00 -0800 Subject: [Python-Dev] %-formatting depracation In-Reply-To: <20110222230300.46e426f2@pitrou.net> References: <4D6403D0.4030107@stoneleaf.us> <20110222230300.46e426f2@pitrou.net> Message-ID: <1298417760.12731.1.camel@localhost.localdomain> On Tue, 2011-02-22 at 23:03 +0100, Antoine Pitrou wrote: > On Wed, 23 Feb 2011 07:52:23 +1000 > Nick Coghlan wrote: > > > On Wed, Feb 23, 2011 at 4:51 AM, Brett Cannon wrote: > > > The very long term view is for %-formatting to go away, but that's as far as > > > the thinking has gone. There are currently no plans to introduce any > > > deprecation warning, and I highly doubt we will even remove the feature in > > > Python 3, giving you probably at least another decade of use at our current > > > major version release schedule. =) > > > > This. Without a systematic way to detect and convert %-style to > > {}-style formatting, enforcing the switch in the 3.x series just isn't > > practical. Heck, we still haven't figured out how to convert a lot of > > higher level APIs to the new scheme in a backwards compatible way > > (that's why modules like logging still default to %-style, with > > {}-style only available via options and wrapper objects). > > I think there are many people still finding %-style more practical for > simple uses, so this might be a case of "practicality beats purity" > over "there should be one obvious way to do it". > > Regards > > Antoine. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/anikom15%40gmail.com I tried to use the format method, but I found the syntax was getting on my nerves and have since gone back to %-formatting. So I don't think it's going away anytime soon. From solipsis at pitrou.net Wed Feb 23 00:36:33 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 23 Feb 2011 00:36:33 +0100 Subject: [Python-Dev] Const-correctness in C-API Object Protocol In-Reply-To: References: <20110223001859.5113aad5@pitrou.net> Message-ID: <1298417793.3757.40.camel@localhost.localdomain> Le mardi 22 f?vrier 2011 ? 18:30 -0500, Alexander Belopolsky a ?crit : > On Tue, Feb 22, 2011 at 6:18 PM, Antoine Pitrou wrote: > .. > > I don't think it's a good idea to backport visible API changes. > > (someone successfully compiling on 2.7.N could then have users > > complaining that compilation fails on 2.7.N-1). > > Moreover, it doesn't really fix a bug. > > That was the argument that I voiced > http://bugs.python.org/issue1699259#msg119032, but I cannot really > think of the code that would be broken by changing the type of an API > function *argument* from char * to const char *. To quote the message above: someone successfully compiling on 2.7.N could then have users complaining that compilation fails on 2.7.N-1. (note: *N-1*) From martin at v.loewis.de Wed Feb 23 00:43:29 2011 From: martin at v.loewis.de (=?windows-1252?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 23 Feb 2011 00:43:29 +0100 Subject: [Python-Dev] Const-correctness in C-API Object Protocol In-Reply-To: References: <20110222202544.4009b85e@pitrou.net> <4D64336C.5080206@v.loewis.de> Message-ID: <4D644A21.3020105@v.loewis.de> > Even if it is eventually decided not to backport those patches to 2.7, > it would be nice if the documentation could be updated to indicate > that strings passed to those functions won't be modified, so that API > users like myself can feel a little safer when passing literals in, > without having to trawl through the interpreter source to see if the > arguments are modified. Can you provide the proper patches? In writing them, you can assume that Python never modifies parameters, except when it is already documented that it does. Regards, Martin From alexander.belopolsky at gmail.com Wed Feb 23 00:49:55 2011 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Tue, 22 Feb 2011 18:49:55 -0500 Subject: [Python-Dev] Const-correctness in C-API Object Protocol In-Reply-To: <1298417793.3757.40.camel@localhost.localdomain> References: <20110223001859.5113aad5@pitrou.net> <1298417793.3757.40.camel@localhost.localdomain> Message-ID: On Tue, Feb 22, 2011 at 6:36 PM, Antoine Pitrou wrote: .. > To quote the message above: someone successfully compiling on 2.7.N > could then have users complaining that compilation fails on 2.7.N-1. > (note: *N-1*) I missed that. Yes, this is a valid concern. I change my vote from -0 to -1. :-) From martin at v.loewis.de Wed Feb 23 00:50:41 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 23 Feb 2011 00:50:41 +0100 Subject: [Python-Dev] Const-correctness in C-API Object Protocol In-Reply-To: <20110223001859.5113aad5@pitrou.net> References: <20110223001859.5113aad5@pitrou.net> Message-ID: <4D644BD1.1020806@v.loewis.de> > I don't think it's a good idea to backport visible API changes. > (someone successfully compiling on 2.7.N could then have users > complaining that compilation fails on 2.7.N-1). +1. If it was a bug fix (which it isn't), having this kind of breakage would be fine, of course (i.e. code relying on the bug fix will reasonably break when used with buggy versions). Regards, Martin From tjreedy at udel.edu Wed Feb 23 01:55:18 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 22 Feb 2011 19:55:18 -0500 Subject: [Python-Dev] Fwd: deep question re dict as formatting input In-Reply-To: References: Message-ID: On 2/22/2011 6:32 PM, Senthil Kumaran wrote: >> On Tue, Feb 22, 2011 at 6:01 PM, Steve Holden wrote: >>> ... It would appear from tests >>> that "{0[X]}".format(...) first tries to convert the string "X" to in >>> integer. If it succeeds then __getitem__() is called with the integer as an >>> argument, otherwise it is called with the string itself as an argument. Is >>> this correct? >> >> This is addressed in the PEP 3101: >> """ >> The rules for parsing an item key are very simple. >> If it starts with a digit, then it is treated as a number, otherwise >> it is used as a string. >> """ http://www.python.org/dev/peps/pep-3101/ > > To the other question : > >> Furthermore, how does one access the key '1' in a format statement? >> ~Ethan~ > > I think, parsing rule already helps to understand the problem with the > key like '1'. > The PEP also explicitly states that: > > """ > Because keys are not quote-delimited, it is not possible to > specify arbitrary dictionary keys (e.g., the strings "10" or > ":-]") from within a format string. > """ Is this all specific in the lib docs? If not, it should be. -- Terry Jan Reedy From eric at trueblade.com Wed Feb 23 01:32:56 2011 From: eric at trueblade.com (Eric Smith) Date: Tue, 22 Feb 2011 19:32:56 -0500 Subject: [Python-Dev] Fwd: deep question re dict as formatting input In-Reply-To: References: <4D644202.7010505@trueblade.com> Message-ID: <4D6455B8.309@trueblade.com> On 2/22/2011 6:28 PM, Steve Holden wrote: > > On Feb 22, 2011, at 3:08 PM, Eric Smith wrote: > >> Quoting PEP 3101: >> >> An example of the 'getitem' syntax: >> >> "My name is {0[name]}".format(dict(name='Fred')) >> >> It should be noted that the use of 'getitem' within a format string >> is much more limited than its conventional usage. In the above example, >> the string 'name' really is the literal string 'name', not a variable >> named 'name'. The rules for parsing an item key are very simple. >> If it starts with a digit, then it is treated as a number, otherwise >> it is used as a string. >> > That's not strictly true: > >>>> d = {"Steve":"Holden", "Guido":"van Rossum", 21.2:"float"} >>>> d[21.1] > Traceback (most recent call last): > File "", line 1, in > KeyError: 21.1 >>>> d[21.2] > 'float' >>>> "{0[21.2]}".format(d) > Traceback (most recent call last): > File "", line 1, in > KeyError: '21.2' >>>> You are correct, I didn't exactly implement the PEP on this point, probably as a shortcut. I think there's an issue somewhere that discusses this, but I can't find it. The CPython implementation is really using "If every character is a digit, then it is treated as an integer, otherwise it is used as a string". See find_name_split in Objects/stringlib/string_format.h, in particular the call to get_integer() and the interpretation of the result. Eric. From victor.stinner at haypocalc.com Wed Feb 23 02:25:34 2011 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Wed, 23 Feb 2011 02:25:34 +0100 Subject: [Python-Dev] [Python-checkins] r88505 - python/branches/py3k/Lib/ftplib.py In-Reply-To: <20110222192433.60A86EEA06@mail.python.org> References: <20110222192433.60A86EEA06@mail.python.org> Message-ID: <1298424334.4903.5.camel@marge> You should maybe backport this fix to Python 3.2. Le mardi 22 f?vrier 2011 ? 20:24 +0100, giampaolo.rodola a ?crit : > Author: giampaolo.rodola > Date: Tue Feb 22 20:24:33 2011 > New Revision: 88505 > > Log: > In FTP.close() method, make sure to also close the socket object, not only the file. > > Modified: > python/branches/py3k/Lib/ftplib.py > > Modified: python/branches/py3k/Lib/ftplib.py > ============================================================================== > --- python/branches/py3k/Lib/ftplib.py (original) > +++ python/branches/py3k/Lib/ftplib.py Tue Feb 22 20:24:33 2011 > @@ -589,11 +589,11 @@ > > def close(self): > '''Close the connection without assuming anything about it.''' > - if self.file: > + if self.file is not None: > self.file.close() > + if self.sock is not None: > self.sock.close() > - self.file = self.sock = None > - > + self.file = self.sock = None > From ncoghlan at gmail.com Wed Feb 23 02:43:54 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 23 Feb 2011 11:43:54 +1000 Subject: [Python-Dev] svn outage on Friday In-Reply-To: <4D5A3990.4040902@v.loewis.de> References: <4D5A3990.4040902@v.loewis.de> Message-ID: On Tue, Feb 15, 2011 at 6:30 PM, "Martin v. L?wis" wrote: > I'm going to perform a Debian upgrade of svn.python.org on Friday, > between 9:00 UTC and 11:00 UTC. I'll be disabling write access during > that time. The outage shouldn't be longer than an hour. This may have caused some issues with the SVN viewer - I'm currently getting "code" with no syntax highlighting and all leading whitespace stripped when attempting to look at file contents. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From raymond.hettinger at gmail.com Wed Feb 23 02:51:56 2011 From: raymond.hettinger at gmail.com (Raymond Hettinger) Date: Tue, 22 Feb 2011 17:51:56 -0800 Subject: [Python-Dev] svn outage on Friday In-Reply-To: References: <4D5A3990.4040902@v.loewis.de> Message-ID: On Feb 22, 2011, at 5:43 PM, Nick Coghlan wrote: > On Tue, Feb 15, 2011 at 6:30 PM, "Martin v. L?wis" wrote: >> I'm going to perform a Debian upgrade of svn.python.org on Friday, >> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during >> that time. The outage shouldn't be longer than an hour. > > This may have caused some issues with the SVN viewer - I'm currently > getting "code" with no syntax highlighting and all leading whitespace > stripped when attempting to look at file contents. I saw the same thing yesterday when viewing with the Chrome browser but it looked fine on Firefox. Later, after restarting the browsers the problem disappeared. I wonder if there was some sort of caching issue. Raymond -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin at python.org Wed Feb 23 03:23:54 2011 From: benjamin at python.org (Benjamin Peterson) Date: Tue, 22 Feb 2011 20:23:54 -0600 Subject: [Python-Dev] [Python-checkins] r88503 - in python/branches/py3k: Lib/lib2to3/__main__.py Tools/scripts/2to3 In-Reply-To: <20110222191243.810C3F634@mail.python.org> References: <20110222191243.810C3F634@mail.python.org> Message-ID: 2011/2/22 brett.cannon : > Author: brett.cannon > Date: Tue Feb 22 20:12:43 2011 > New Revision: 88503 > > Log: > Add lib2to3.__main__ to make it easier for debugging purposes to run 2to3. Please revert this and do it in the sandbox. > > Added: > ? python/branches/py3k/Lib/lib2to3/__main__.py > Modified: > ? python/branches/py3k/Tools/scripts/2to3 > > Added: python/branches/py3k/Lib/lib2to3/__main__.py > ============================================================================== > --- (empty file) > +++ python/branches/py3k/Lib/lib2to3/__main__.py ? ? ? ?Tue Feb 22 20:12:43 2011 > @@ -0,0 +1,4 @@ > +import sys > +from .main import main > + > +sys.exit(main("lib2to3.fixes")) > > Modified: python/branches/py3k/Tools/scripts/2to3 > ============================================================================== > --- python/branches/py3k/Tools/scripts/2to3 ? ? (original) > +++ python/branches/py3k/Tools/scripts/2to3 ? ? Tue Feb 22 20:12:43 2011 > @@ -1,5 +1,4 @@ > ?#!/usr/bin/env python > -import sys > -from lib2to3.main import main > +import runpy > > -sys.exit(main("lib2to3.fixes")) > +runpy.run_module('lib2to3', run_name='__main__', alter_sys=True) > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://mail.python.org/mailman/listinfo/python-checkins > -- Regards, Benjamin From stephen at xemacs.org Wed Feb 23 03:31:39 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 23 Feb 2011 11:31:39 +0900 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <4D63A89A.20609@jcea.es> References: <4D63A89A.20609@jcea.es> Message-ID: <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> Jesus Cea writes: > PPS: If there is consensus that this is a real bug, I would create an > issue in the tracker and try to get a minimal testcase. All bugs are issues, but not all issues are bugs. Please don't wait for consensus or even a second opinion to file the issue. It's reasonable for a new Python user to ask whether something is a bug or not, but if somebody with your experience and contribution level to Python doesn't understand something, at the very least we have to suspect a doc bug. So please file the issue to ensure that something will be done to address the issue, and even if it turns out to be some misunderstanding that only you are ever likely to make, at least the issue will remain as documentation if somebody else has the same misunderstanding. OTOH, the testcase might require a lot of effort on your part. Of course it's reasonable for you to check whether it's a simple misunderstanding before exerting that effort. From alexander.belopolsky at gmail.com Wed Feb 23 04:06:51 2011 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Tue, 22 Feb 2011 22:06:51 -0500 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On Tue, Feb 22, 2011 at 9:31 PM, Stephen J. Turnbull wrote: > Jesus Cea writes: > > ?> PPS: If there is consensus that this is a real bug, I would create an > ?> issue in the tracker and try to get a minimal testcase. > > All bugs are issues, but not all issues are bugs. > > Please don't wait for consensus or even a second opinion to file the > issue. > AFAICT, it was not mentioned in this thread, but the issue has been created on the tracker: http://bugs.python.org/issue11286 From jcea at jcea.es Wed Feb 23 05:34:43 2011 From: jcea at jcea.es (Jesus Cea) Date: Wed, 23 Feb 2011 05:34:43 +0100 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <4D648E63.2050106@jcea.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/02/11 03:31, Stephen J. Turnbull wrote: > Please don't wait for consensus or even a second opinion to file the > issue. > > It's reasonable for a new Python user to ask whether something is a > bug or not, but if somebody with your experience and contribution > level to Python doesn't understand something, at the very least we > have to suspect a doc bug. Every time I read a message from Antoine Pitrou, Brett Cannon, Nick Coghlan, Martin L?wis, Eric Smith, Steve Holden, Benjamin Peterson, Victor Stinner, Greog Brandl, Raymond Hettinger, Guido and so many others python-devs (not an exhaustive list, if you are not there, you probably should, sorry :), I feel I am faking my knowledge of Python :-). I am a pretender :). BTW, this project is my first real python 3 code (I promised to myself to move after 3.2 release, a year ago), for a real/big project, and I was thinking that maybe I was overlooking something obvious for any seasoned "real" python programmer. I overcame my fear of being seen as a fool last millenia, so I am not afraid of asking. Sometimes I even ask too much. > OTOH, the testcase might require a lot of effort on your part. Of > course it's reasonable for you to check whether it's a simple > misunderstanding before exerting that effort. In fact, I invested *hours* trying to reduce my multimegabyte problematic pickle to 41 bytes, but at this time I was already convinced that I had hit an ugly and serious bug. Issue filed. It already has a patch. That was fast!. Now I can sit back waiting for 3.2.1 before touching my project again :). Mixed feelings about the waiting. I hope it is short. Life sucks sometimes :). Thanks $DEITY there are quite a few better python-devs than me :). - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTWSOY5lgi5GaxT1NAQIqQAP/Wf/e2iN3FRb7istoGCpqCgjDv7UyCOWF RzOYMJWh0xhNL5ydZZ2YwtcQNEWrQS538zrr8piOqvV3ielOBCgSWArqChWaQTHU ZC3gdaw8N5VMr0AXGBMXwcflkLaQ7BrBtiQBizFL9KLYGDI9JG8+O1YjpjamUeQv iXEyGdqWUp4= =XwYt -----END PGP SIGNATURE----- From g.rodola at gmail.com Wed Feb 23 05:41:40 2011 From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=) Date: Wed, 23 Feb 2011 05:41:40 +0100 Subject: [Python-Dev] [Python-checkins] r88505 - python/branches/py3k/Lib/ftplib.py In-Reply-To: <1298424334.4903.5.camel@marge> References: <20110222192433.60A86EEA06@mail.python.org> <1298424334.4903.5.camel@marge> Message-ID: I'll do. 2011/2/23 Victor Stinner : > You should maybe backport this fix to Python 3.2. > > Le mardi 22 f?vrier 2011 ? 20:24 +0100, giampaolo.rodola a ?crit : >> Author: giampaolo.rodola >> Date: Tue Feb 22 20:24:33 2011 >> New Revision: 88505 >> >> Log: >> In FTP.close() method, make sure to also close the socket object, not only the file. >> >> Modified: >> ? ?python/branches/py3k/Lib/ftplib.py >> >> Modified: python/branches/py3k/Lib/ftplib.py >> ============================================================================== >> --- python/branches/py3k/Lib/ftplib.py ? ? ? ?(original) >> +++ python/branches/py3k/Lib/ftplib.py ? ? ? ?Tue Feb 22 20:24:33 2011 >> @@ -589,11 +589,11 @@ >> >> ? ? ?def close(self): >> ? ? ? ? ?'''Close the connection without assuming anything about it.''' >> - ? ? ? ?if self.file: >> + ? ? ? ?if self.file is not None: >> ? ? ? ? ? ? ?self.file.close() >> + ? ? ? ?if self.sock is not None: >> ? ? ? ? ? ? ?self.sock.close() >> - ? ? ? ? ? ?self.file = self.sock = None >> - >> + ? ? ? ?self.file = self.sock = None >> > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com > From stephen at xemacs.org Wed Feb 23 06:51:48 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Wed, 23 Feb 2011 14:51:48 +0900 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <4D648E63.2050106@jcea.es> References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> Message-ID: <87bp23nvrf.fsf@uwakimon.sk.tsukuba.ac.jp> Jesus Cea writes: > Every time I read a message from [long, incomplete list] and > so many others python-devs (not an exhaustive list, if you are not > there, you probably should, sorry :), I feel I am faking my > knowledge of Python :-). I am a pretender :). Sure. I suspect even some of those *on* the list feel that way sometimes. That's what's so great about the list, the people who contribute! From martin at v.loewis.de Wed Feb 23 07:22:19 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Wed, 23 Feb 2011 07:22:19 +0100 Subject: [Python-Dev] svn outage on Friday In-Reply-To: References: <4D5A3990.4040902@v.loewis.de> Message-ID: <4D64A79B.8040607@v.loewis.de> Am 23.02.2011 02:43, schrieb Nick Coghlan: > On Tue, Feb 15, 2011 at 6:30 PM, "Martin v. L?wis" wrote: >> I'm going to perform a Debian upgrade of svn.python.org on Friday, >> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during >> that time. The outage shouldn't be longer than an hour. > > This may have caused some issues with the SVN viewer - I'm currently > getting "code" with no syntax highlighting and all leading whitespace > stripped when attempting to look at file contents. The ViewVC configuration has significantly changed, so I originally tried to adjust the old configuration. I went now the other path of configuring starting with the new configuration template. I may have broken things in the process; if so, please let me know. Post the specific URL that gives troubles. Regards, Martin From g.brandl at gmx.net Wed Feb 23 08:32:02 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Wed, 23 Feb 2011 08:32:02 +0100 Subject: [Python-Dev] r88501 - python/branches/py3k/Lib/smtplib.py In-Reply-To: <20110222155620.B82D2EE9B5@mail.python.org> References: <20110222155620.B82D2EE9B5@mail.python.org> Message-ID: You're sure this will not cause tedious conflicts with backports? Georg On 22.02.2011 16:56, giampaolo.rodola wrote: > Author: giampaolo.rodola > Date: Tue Feb 22 16:56:20 2011 > New Revision: 88501 > > Log: > smtlib.py PEP8 normalization via pep8.py script. > > Modified: > python/branches/py3k/Lib/smtplib.py > > Modified: python/branches/py3k/Lib/smtplib.py > ============================================================================== > --- python/branches/py3k/Lib/smtplib.py (original) > +++ python/branches/py3k/Lib/smtplib.py Tue Feb 22 16:56:20 2011 > @@ -52,15 +52,15 @@ From g.brandl at gmx.net Wed Feb 23 08:35:04 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Wed, 23 Feb 2011 08:35:04 +0100 Subject: [Python-Dev] r88516 - in python/branches/py3k/Python: dynload_aix.c dynload_dl.c dynload_hpux.c dynload_next.c dynload_os2.c dynload_shlib.c dynload_win.c importdl.c In-Reply-To: <20110222231620.1668BEE9A5@mail.python.org> References: <20110222231620.1668BEE9A5@mail.python.org> Message-ID: This commit introduced tabs, at least in dynload_dl.c. Georg On 23.02.2011 00:16, victor.stinner wrote: > Author: victor.stinner > Date: Wed Feb 23 00:16:19 2011 > New Revision: 88516 > > Log: > Issue #3080: Remove unused argument of _PyImport_GetDynLoadFunc() > > The first argument, fqname, was not used. > > Modified: > python/branches/py3k/Python/dynload_aix.c > python/branches/py3k/Python/dynload_dl.c > python/branches/py3k/Python/dynload_hpux.c > python/branches/py3k/Python/dynload_next.c > python/branches/py3k/Python/dynload_os2.c > python/branches/py3k/Python/dynload_shlib.c > python/branches/py3k/Python/dynload_win.c > python/branches/py3k/Python/importdl.c > > Modified: python/branches/py3k/Python/dynload_aix.c > ============================================================================== > --- python/branches/py3k/Python/dynload_aix.c (original) > +++ python/branches/py3k/Python/dynload_aix.c Wed Feb 23 00:16:19 2011 > @@ -154,7 +154,7 @@ > } > > > -dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname, > +dl_funcptr _PyImport_GetDynLoadFunc(const char *shortname, > const char *pathname, FILE *fp) > { > dl_funcptr p; > > Modified: python/branches/py3k/Python/dynload_dl.c > ============================================================================== > --- python/branches/py3k/Python/dynload_dl.c (original) > +++ python/branches/py3k/Python/dynload_dl.c Wed Feb 23 00:16:19 2011 > @@ -16,7 +16,7 @@ > }; > > > -dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname, > +dl_funcptr _PyImport_GetDynLoadFunc(const char *shortname, > const char *pathname, FILE *fp) > { > char funcname[258]; > > Modified: python/branches/py3k/Python/dynload_hpux.c > ============================================================================== > --- python/branches/py3k/Python/dynload_hpux.c (original) > +++ python/branches/py3k/Python/dynload_hpux.c Wed Feb 23 00:16:19 2011 > @@ -19,7 +19,7 @@ > {0, 0} > }; > > -dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname, > +dl_funcptr _PyImport_GetDynLoadFunc(const char *shortname, > const char *pathname, FILE *fp) > { > dl_funcptr p; > > Modified: python/branches/py3k/Python/dynload_next.c > ============================================================================== > --- python/branches/py3k/Python/dynload_next.c (original) > +++ python/branches/py3k/Python/dynload_next.c Wed Feb 23 00:16:19 2011 > @@ -31,8 +31,8 @@ > #define LINKOPTIONS NSLINKMODULE_OPTION_BINDNOW| \ > NSLINKMODULE_OPTION_RETURN_ON_ERROR|NSLINKMODULE_OPTION_PRIVATE > #endif > -dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname, > - const char *pathname, FILE *fp) > +dl_funcptr _PyImport_GetDynLoadFunc(const char *shortname, > + const char *pathname, FILE *fp) > { > dl_funcptr p = NULL; > char funcname[258]; > > Modified: python/branches/py3k/Python/dynload_os2.c > ============================================================================== > --- python/branches/py3k/Python/dynload_os2.c (original) > +++ python/branches/py3k/Python/dynload_os2.c Wed Feb 23 00:16:19 2011 > @@ -15,7 +15,7 @@ > {0, 0} > }; > > -dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname, > +dl_funcptr _PyImport_GetDynLoadFunc(const char *shortname, > const char *pathname, FILE *fp) > { > dl_funcptr p; > > Modified: python/branches/py3k/Python/dynload_shlib.c > ============================================================================== > --- python/branches/py3k/Python/dynload_shlib.c (original) > +++ python/branches/py3k/Python/dynload_shlib.c Wed Feb 23 00:16:19 2011 > @@ -75,7 +75,7 @@ > static int nhandles = 0; > > > -dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname, > +dl_funcptr _PyImport_GetDynLoadFunc(const char *shortname, > const char *pathname, FILE *fp) > { > dl_funcptr p; > > Modified: python/branches/py3k/Python/dynload_win.c > ============================================================================== > --- python/branches/py3k/Python/dynload_win.c (original) > +++ python/branches/py3k/Python/dynload_win.c Wed Feb 23 00:16:19 2011 > @@ -171,7 +171,7 @@ > return NULL; > } > > -dl_funcptr _PyImport_GetDynLoadFunc(const char *fqname, const char *shortname, > +dl_funcptr _PyImport_GetDynLoadFunc(const char *shortname, > const char *pathname, FILE *fp) > { > dl_funcptr p; > > Modified: python/branches/py3k/Python/importdl.c > ============================================================================== > --- python/branches/py3k/Python/importdl.c (original) > +++ python/branches/py3k/Python/importdl.c Wed Feb 23 00:16:19 2011 > @@ -12,8 +12,7 @@ > > #include "importdl.h" > > -extern dl_funcptr _PyImport_GetDynLoadFunc(const char *name, > - const char *shortname, > +extern dl_funcptr _PyImport_GetDynLoadFunc(const char *shortname, > const char *pathname, FILE *fp); > > > @@ -48,7 +47,7 @@ > shortname = lastdot+1; > } > > - p0 = _PyImport_GetDynLoadFunc(name, shortname, pathname, fp); > + p0 = _PyImport_GetDynLoadFunc(shortname, pathname, fp); > p = (PyObject*(*)(void))p0; > if (PyErr_Occurred()) > goto error; From victor.stinner at haypocalc.com Wed Feb 23 12:31:14 2011 From: victor.stinner at haypocalc.com (Victor Stinner) Date: Wed, 23 Feb 2011 12:31:14 +0100 Subject: [Python-Dev] r88516 - in python/branches/py3k/Python: dynload_aix.c dynload_dl.c dynload_hpux.c dynload_next.c dynload_os2.c dynload_shlib.c dynload_win.c importdl.c In-Reply-To: References: <20110222231620.1668BEE9A5@mail.python.org> Message-ID: <1298460674.30842.0.camel@marge> Le mercredi 23 f?vrier 2011 ? 08:35 +0100, Georg Brandl a ?crit : > This commit introduced tabs, at least in dynload_dl.c. WHAT? No, I didn't introduced new tabs: dynload_dl.c always used tabs. Anyway, I converted tabs to spaces in r88527. Victor From hrvoje.niksic at avl.com Wed Feb 23 12:30:57 2011 From: hrvoje.niksic at avl.com (Hrvoje Niksic) Date: Wed, 23 Feb 2011 12:30:57 +0100 Subject: [Python-Dev] %-formatting depracation In-Reply-To: <20110222230300.46e426f2@pitrou.net> References: <4D6403D0.4030107@stoneleaf.us> <20110222230300.46e426f2@pitrou.net> Message-ID: <4D64EFF1.6000009@avl.com> On 02/22/2011 11:03 PM, Antoine Pitrou wrote: > I think there are many people still finding %-style more practical for > simple uses, It's also a clash of cultures. People coming from a C/Unix background typically find %-style format obvious and self-explanatory, while people coming from Java/DotNET background feel the same way about {}-style formats. From eric at trueblade.com Wed Feb 23 13:10:04 2011 From: eric at trueblade.com (Eric Smith) Date: Wed, 23 Feb 2011 07:10:04 -0500 Subject: [Python-Dev] Fwd: deep question re dict as formatting input In-Reply-To: <4D6455B8.309@trueblade.com> References: <4D644202.7010505@trueblade.com> <4D6455B8.309@trueblade.com> Message-ID: <4D64F91C.8080902@trueblade.com> On 02/22/2011 07:32 PM, Eric Smith wrote: > On 2/22/2011 6:28 PM, Steve Holden wrote: >> >> On Feb 22, 2011, at 3:08 PM, Eric Smith wrote: >> >>> Quoting PEP 3101: >>> >>> An example of the 'getitem' syntax: >>> >>> "My name is {0[name]}".format(dict(name='Fred')) >>> >>> It should be noted that the use of 'getitem' within a format string >>> is much more limited than its conventional usage. In the above example, >>> the string 'name' really is the literal string 'name', not a variable >>> named 'name'. The rules for parsing an item key are very simple. >>> If it starts with a digit, then it is treated as a number, otherwise >>> it is used as a string. >>> >> That's not strictly true: >> >>>>> d = {"Steve":"Holden", "Guido":"van Rossum", 21.2:"float"} >>>>> d[21.1] >> Traceback (most recent call last): >> File "", line 1, in >> KeyError: 21.1 >>>>> d[21.2] >> 'float' >>>>> "{0[21.2]}".format(d) >> Traceback (most recent call last): >> File "", line 1, in >> KeyError: '21.2' >>>>> > > You are correct, I didn't exactly implement the PEP on this point, > probably as a shortcut. I think there's an issue somewhere that > discusses this, but I can't find it. The CPython implementation is > really using "If every character is a digit, then it is treated as an > integer, otherwise it is used as a string". > > See find_name_split in Objects/stringlib/string_format.h, in particular > the call to get_integer() and the interpretation of the result. Just for the archives, I'll mention why it works this way. It's trying to support indexing by integers, as well as dictionary access using arbitrary keys. Both of course use the same syntax. In this case it must convert the index values into ints: >>> a = ['usr', 'var'] >>> '{0[0]} {0[1]}'.format(a) 'usr var' And in this case it doesn't: >>> a = {'one':'usr', 'two':'var'} >>> '{0[one]} {0[two]}'.format(a) 'usr var' Eric. From python-dev at masklinn.net Wed Feb 23 14:03:08 2011 From: python-dev at masklinn.net (Xavier Morel) Date: Wed, 23 Feb 2011 14:03:08 +0100 Subject: [Python-Dev] %-formatting depracation In-Reply-To: <4D64EFF1.6000009@avl.com> References: <4D6403D0.4030107@stoneleaf.us> <20110222230300.46e426f2@pitrou.net> <4D64EFF1.6000009@avl.com> Message-ID: On 2011-02-23, at 12:30 , Hrvoje Niksic wrote: > On 02/22/2011 11:03 PM, Antoine Pitrou wrote: >> I think there are many people still finding %-style more practical for >> simple uses, > > It's also a clash of cultures. People coming from a C/Unix background typically find %-style format obvious and self-explanatory, while people coming from Java/DotNET background feel the same way about {}-style formats. For Java it's debatable: the Java 5 string formatting APIs are all printf-style (java.io.PrintStream#printf[0], String#format[1], java.util.Formatter[2]). The older java.text.MessageFormat[3] (still used a lot for property lists as it's built for localization among other things) does use {}-style, though one quite different than Python's. [0] http://download.oracle.com/javase/1.5.0/docs/api/java/io/PrintStream.html#printf(java.lang.String,%20java.lang.Object...) [1] http://download.oracle.com/javase/1.5.0/docs/api/java/lang/String.html#format(java.lang.String,%20java.lang.Object?) [2] http://download.oracle.com/javase/1.5.0/docs/api/java/util/Formatter.html [3] http://download.oracle.com/javase/1.5.0/docs/api/java/text/MessageFormat.html From ncoghlan at gmail.com Wed Feb 23 14:21:02 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 23 Feb 2011 23:21:02 +1000 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <87bp23nvrf.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> <87bp23nvrf.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On Wed, Feb 23, 2011 at 3:51 PM, Stephen J. Turnbull wrote: > Jesus Cea writes: > > ?> Every time I read a message from [long, incomplete list] and > ?> so many others python-devs (not an exhaustive list, if you are not > ?> there, you probably should, sorry :), I feel I am faking my > ?> knowledge of Python :-). I am a pretender :). > > Sure. ?I suspect even some of those *on* the list feel that way > sometimes. ?That's what's so great about the list, the people who > contribute! I personally feel that way every time I realise just how much of the standard library I have never even seriously looked at (let alone used) and how much more there is to the Python ecosystem than just CPython (subscribing to Planet Python and the python tag on Stack Overflow has been truly eye opening in that regard). Heck, some day I may even get around to learning how to build a proper Python package ;) Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From ncoghlan at gmail.com Wed Feb 23 14:26:13 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 23 Feb 2011 23:26:13 +1000 Subject: [Python-Dev] svn outage on Friday In-Reply-To: <4D64A79B.8040607@v.loewis.de> References: <4D5A3990.4040902@v.loewis.de> <4D64A79B.8040607@v.loewis.de> Message-ID: On Wed, Feb 23, 2011 at 4:22 PM, "Martin v. L?wis" wrote: > The ViewVC configuration has significantly changed, so I originally > tried to adjust the old configuration. I went now the other path of > configuring starting with the new configuration template. I may have > broken things in the process; if so, please let me know. Post the > specific URL that gives troubles. Seems to be OK now when checking from my home machine - I'll check the misbehaving box again tomorrow. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From ncoghlan at gmail.com Wed Feb 23 14:42:21 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 23 Feb 2011 23:42:21 +1000 Subject: [Python-Dev] Fwd: deep question re dict as formatting input In-Reply-To: References: Message-ID: On Wed, Feb 23, 2011 at 9:32 AM, Senthil Kumaran wrote: > """ > Because keys are not quote-delimited, it is not possible to > ? ?specify arbitrary dictionary keys (e.g., the strings "10" or > ? ?":-]") from within a format string. > """ I was curious as to whether or not nested substitution could be used to avoid that limitation, but it would seem not: >>> "{0[{1}]}".format(d, 21.2) Traceback (most recent call last): File "", line 1, in KeyError: '{1}' Turns out that was also a deliberate design choice: """ These 'internal' replacement fields can only occur in the format specifier part of the replacement field. Internal replacement fields cannot themselves have format specifiers. This implies also that replacement fields cannot be nested to arbitrary levels. """ Ah, how (much more) confused would we be if we didn't have the PEPs and mailing list archives to remind ourselves of what we were thinking years ago... Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From rdmurray at bitdance.com Wed Feb 23 15:42:45 2011 From: rdmurray at bitdance.com (R. David Murray) Date: Wed, 23 Feb 2011 09:42:45 -0500 Subject: [Python-Dev] Fwd: deep question re dict as formatting input In-Reply-To: <4D6455B8.309@trueblade.com> References: <4D644202.7010505@trueblade.com> <4D6455B8.309@trueblade.com> Message-ID: <20110223144245.108E82371B2@kimball.webabinitio.net> On Tue, 22 Feb 2011 19:32:56 -0500, Eric Smith wrote: > You are correct, I didn't exactly implement the PEP on this point, > probably as a shortcut. I think there's an issue somewhere that > discusses this, but I can't find it. The CPython implementation is > really using "If every character is a digit, then it is treated as an > integer, otherwise it is used as a string". Perhaps you are thinking of http://bugs.python.org/issue7951. Not directly on point, but related. -- R. David Murray www.bitdance.com From solipsis at pitrou.net Wed Feb 23 16:58:55 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 23 Feb 2011 16:58:55 +0100 Subject: [Python-Dev] Link to issue tracker Message-ID: <20110223165855.10d63be9@pitrou.net> Hello, I think it was a slight mistake to remove the link to the issue tracker from the sidebar in the "core development" section. Dave Beazley just complained about it (http://twitter.com/dabeaz/status/40397577916661760) and I think it will probably confuse other people too. Could we add it back ? cheers Antoine. From eric at trueblade.com Wed Feb 23 17:01:38 2011 From: eric at trueblade.com (Eric Smith) Date: Wed, 23 Feb 2011 11:01:38 -0500 Subject: [Python-Dev] Fwd: deep question re dict as formatting input In-Reply-To: <20110223144245.108E82371B2@kimball.webabinitio.net> References: <4D644202.7010505@trueblade.com> <4D6455B8.309@trueblade.com> <20110223144245.108E82371B2@kimball.webabinitio.net> Message-ID: <4D652F62.5000708@trueblade.com> On 02/23/2011 09:42 AM, R. David Murray wrote: > On Tue, 22 Feb 2011 19:32:56 -0500, Eric Smith wrote: >> You are correct, I didn't exactly implement the PEP on this point, >> probably as a shortcut. I think there's an issue somewhere that >> discusses this, but I can't find it. The CPython implementation is >> really using "If every character is a digit, then it is treated as an >> integer, otherwise it is used as a string". > > Perhaps you are thinking of http://bugs.python.org/issue7951. Not > directly on point, but related. Yes, that's the one I was thinking of. Thanks, David. I'm not sure I agree with all of the points raised there, but it does some additional background on the issue. From g.rodola at gmail.com Wed Feb 23 18:18:05 2011 From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=) Date: Wed, 23 Feb 2011 18:18:05 +0100 Subject: [Python-Dev] Link to issue tracker In-Reply-To: <20110223165855.10d63be9@pitrou.net> References: <20110223165855.10d63be9@pitrou.net> Message-ID: +1, I often use that link as well. 2011/2/23 Antoine Pitrou : > > Hello, > > I think it was a slight mistake to remove the link to the issue tracker > from the sidebar in the "core development" section. Dave Beazley just > complained about it > (http://twitter.com/dabeaz/status/40397577916661760) and I think it > will probably confuse other people too. Could we add it back ? > > cheers > > Antoine. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com > From steve at holdenweb.com Wed Feb 23 19:02:47 2011 From: steve at holdenweb.com (Steve Holden) Date: Wed, 23 Feb 2011 10:02:47 -0800 Subject: [Python-Dev] Fwd: deep question re dict as formatting input In-Reply-To: References: Message-ID: <4B891A59-7AB5-4867-AFE9-3EA356A3CE7D@holdenweb.com> On Feb 23, 2011, at 5:42 AM, Nick Coghlan wrote: > Ah, how (much more) confused would we be if we didn't have the PEPs > and mailing list archives to remind ourselves of what we were thinking > years ago... > True. And how much more useful it would be if it were incorporated into the documentation after implementation. Too much of the format() stuff is demonstrated rather than explained. regards Steve From ethan at stoneleaf.us Wed Feb 23 19:18:58 2011 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 23 Feb 2011 10:18:58 -0800 Subject: [Python-Dev] Fwd: deep question re dict as formatting input In-Reply-To: <4D6455B8.309@trueblade.com> References: <4D644202.7010505@trueblade.com> <4D6455B8.309@trueblade.com> Message-ID: <4D654F92.90006@stoneleaf.us> Eric Smith wrote: > On 2/22/2011 6:28 PM, Steve Holden wrote: >> On Feb 22, 2011, at 3:08 PM, Eric Smith wrote: >>> Quoting PEP 3101: >>> >>> An example of the 'getitem' syntax: >>> >>> "My name is {0[name]}".format(dict(name='Fred')) >>> >>> It should be noted that the use of 'getitem' within a format string >>> is much more limited than its conventional usage. In the above example, >>> the string 'name' really is the literal string 'name', not a variable >>> named 'name'. The rules for parsing an item key are very simple. >>> If it starts with a digit, then it is treated as a number, otherwise >>> it is used as a string. >>> >> That's not strictly true: >> >>--> d = {"Steve":"Holden", "Guido":"van Rossum", 21.2:"float"} >>--> d[21.1] >> Traceback (most recent call last): >> File "", line 1, in >> KeyError: 21.1 >>--> d[21.2] >> 'float' >>--> "{0[21.2]}".format(d) >> Traceback (most recent call last): >> File "", line 1, in >> KeyError: '21.2' >> > > You are correct, I didn't exactly implement the PEP on this point, > probably as a shortcut. I think there's an issue somewhere that > discusses this, but I can't find it. The CPython implementation is > really using "If every character is a digit, then it is treated as an > integer, otherwise it is used as a string". Given the representation issues with floating point, I think the current behavior is desirable. Also, leaving digits with periods as strings would, I think, be more useful (Dewey Decimal, anyone?). ~Ethan~ From eric at trueblade.com Wed Feb 23 19:18:40 2011 From: eric at trueblade.com (Eric Smith) Date: Wed, 23 Feb 2011 13:18:40 -0500 (EST) Subject: [Python-Dev] Fwd: deep question re dict as formatting input In-Reply-To: <4B891A59-7AB5-4867-AFE9-3EA356A3CE7D@holdenweb.com> References: <4B891A59-7AB5-4867-AFE9-3EA356A3CE7D@holdenweb.com> Message-ID: <974ee64aafc02e1dff6a4949c4734af4.squirrel@mail.trueblade.com> > On Feb 23, 2011, at 5:42 AM, Nick Coghlan wrote: > >> Ah, how (much more) confused would we be if we didn't have the PEPs >> and mailing list archives to remind ourselves of what we were thinking >> years ago... >> > True. And how much more useful it would be if it were incorporated into > the documentation after implementation. Too much of the format() stuff is > demonstrated rather than explained. I think the documentation team has been pretty good about responding to format() issues that have been brought up in the bug tracker. Eric. From tjreedy at udel.edu Wed Feb 23 19:42:22 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 23 Feb 2011 13:42:22 -0500 Subject: [Python-Dev] 3.2.0 == 20th anniversary release Message-ID: As pointed out by Ramiro Morales on the Python-Argentina list (quoting Guido's blog post http://python-history.blogspot.com/2009/01/brief-timeline-of-python.html ) Python 0.9.0 was released on 20 Feb 1991 Python 3.2.0 was released on 20 Feb 2011 Python's come a long way. I look forward to the next 20. -- Terry Jan Reedy From brett at python.org Wed Feb 23 19:30:54 2011 From: brett at python.org (Brett Cannon) Date: Wed, 23 Feb 2011 10:30:54 -0800 Subject: [Python-Dev] Link to issue tracker In-Reply-To: <20110223165855.10d63be9@pitrou.net> References: <20110223165855.10d63be9@pitrou.net> Message-ID: I won't add the link back, but I will try to change the global link on the website to point to the devguide. python.org/dev/ at this point exists purely to not break pre-existing links. On Wed, Feb 23, 2011 at 07:58, Antoine Pitrou wrote: > > Hello, > > I think it was a slight mistake to remove the link to the issue tracker > from the sidebar in the "core development" section. Dave Beazley just > complained about it > (http://twitter.com/dabeaz/status/40397577916661760) and I think it > will probably confuse other people too. Could we add it back ? > > cheers > > Antoine. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Wed Feb 23 19:51:21 2011 From: guido at python.org (Guido van Rossum) Date: Wed, 23 Feb 2011 10:51:21 -0800 Subject: [Python-Dev] 3.2.0 == 20th anniversary release In-Reply-To: References: Message-ID: On Wed, Feb 23, 2011 at 10:42 AM, Terry Reedy wrote: > As pointed out by Ramiro Morales on the Python-Argentina list > (quoting Guido's blog post > http://python-history.blogspot.com/2009/01/brief-timeline-of-python.html > ) > Python 0.9.0 was released on 20 Feb 1991 > > Python 3.2.0 was released on 20 Feb 2011 > > Python's come a long way. > I look forward to the next 20. Me too! BTW very nice of Georg to time it this way. -- --Guido van Rossum (python.org/~guido) From solipsis at pitrou.net Wed Feb 23 19:52:05 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 23 Feb 2011 19:52:05 +0100 Subject: [Python-Dev] Link to issue tracker In-Reply-To: References: <20110223165855.10d63be9@pitrou.net> Message-ID: <20110223195205.5bb428e8@pitrou.net> On Wed, 23 Feb 2011 10:30:54 -0800 Brett Cannon wrote: > I won't add the link back, but I will try to change the global link on the > website to point to the devguide. python.org/dev/ at this point exists > purely to not break pre-existing links. There are items there that are out of scope for the dev guide (e.g. "Python.org Maintenance and Administration"). Also, I do believe that being able to report a bug immediately is very important. Reporting a bug doesn't mean you want to contribute code; it just means you've found an issue and would like the community to know (and possibly fix it). Regards Antoine. From brett at python.org Wed Feb 23 19:52:04 2011 From: brett at python.org (Brett Cannon) Date: Wed, 23 Feb 2011 10:52:04 -0800 Subject: [Python-Dev] [Python-checkins] r88503 - in python/branches/py3k: Lib/lib2to3/__main__.py Tools/scripts/2to3 In-Reply-To: References: <20110222191243.810C3F634@mail.python.org> Message-ID: I assume you are having me do this because you still plan to cut separate releases. Is there a minimum Python version that needs to be supported? On Tue, Feb 22, 2011 at 18:23, Benjamin Peterson wrote: > 2011/2/22 brett.cannon : > > Author: brett.cannon > > Date: Tue Feb 22 20:12:43 2011 > > New Revision: 88503 > > > > Log: > > Add lib2to3.__main__ to make it easier for debugging purposes to run > 2to3. > > Please revert this and do it in the sandbox. > > > > > Added: > > python/branches/py3k/Lib/lib2to3/__main__.py > > Modified: > > python/branches/py3k/Tools/scripts/2to3 > > > > Added: python/branches/py3k/Lib/lib2to3/__main__.py > > > ============================================================================== > > --- (empty file) > > +++ python/branches/py3k/Lib/lib2to3/__main__.py Tue Feb 22 > 20:12:43 2011 > > @@ -0,0 +1,4 @@ > > +import sys > > +from .main import main > > + > > +sys.exit(main("lib2to3.fixes")) > > > > Modified: python/branches/py3k/Tools/scripts/2to3 > > > ============================================================================== > > --- python/branches/py3k/Tools/scripts/2to3 (original) > > +++ python/branches/py3k/Tools/scripts/2to3 Tue Feb 22 20:12:43 2011 > > @@ -1,5 +1,4 @@ > > #!/usr/bin/env python > > -import sys > > -from lib2to3.main import main > > +import runpy > > > > -sys.exit(main("lib2to3.fixes")) > > +runpy.run_module('lib2to3', run_name='__main__', alter_sys=True) > > _______________________________________________ > > Python-checkins mailing list > > Python-checkins at python.org > > http://mail.python.org/mailman/listinfo/python-checkins > > > > > > -- > Regards, > Benjamin > _______________________________________________ > Python-checkins mailing list > Python-checkins at python.org > http://mail.python.org/mailman/listinfo/python-checkins > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.brandl at gmx.net Wed Feb 23 20:11:46 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Wed, 23 Feb 2011 20:11:46 +0100 Subject: [Python-Dev] 3.2.0 == 20th anniversary release In-Reply-To: References: Message-ID: On 23.02.2011 19:51, Guido van Rossum wrote: > On Wed, Feb 23, 2011 at 10:42 AM, Terry Reedy wrote: >> As pointed out by Ramiro Morales on the Python-Argentina list >> (quoting Guido's blog post >> http://python-history.blogspot.com/2009/01/brief-timeline-of-python.html >> ) >> Python 0.9.0 was released on 20 Feb 1991 >> >> Python 3.2.0 was released on 20 Feb 2011 >> >> Python's come a long way. >> I look forward to the next 20. > > Me too! > > BTW very nice of Georg to time it this way. As much as I'd like to claim it, it's pure coincidence where my planning is concerned. I knew that Python 0.9 was in 1991, so I knew about 20 years, but not about the exact date. Very nice! Maybe it was a subconscious thing :) cheers, Georg From alexander.belopolsky at gmail.com Wed Feb 23 20:16:24 2011 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 23 Feb 2011 14:16:24 -0500 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <4D648E63.2050106@jcea.es> References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> Message-ID: On Tue, Feb 22, 2011 at 11:34 PM, Jesus Cea wrote: .. > Issue filed. It already has a patch. That was fast!. Now I can sit back > waiting for 3.2.1 before touching my project again :). Mixed feelings > about the waiting. I hope it is short. It looks like you don't need delay your project: if you spell encoding as "latin-1", your pickle loads just fine: >>> with open("z.pickle", mode="rb") as f: pickle.load(f, encoding="latin-1") ... {'ya_volcados': {'comment': ''}} With encoding="latin1", it does fail: >>> with open("z.pickle", mode="rb") as f: pickle.load(f, encoding="latin1") ... Traceback (most recent call last): File "", line 1, in ValueError: operation forbidden on released memoryview object (For those not following the tracker issue, the z.pickle file was posted at .) There is still a bug, which is best demonstrated by >>> pickle.loads(b'\x80\x02U\x00.', encoding='latin1') Traceback (most recent call last): File "", line 1, in ValueError: operation forbidden on released memoryview object The fact that the above works with encoding='latin-1', >>> pickle.loads(b'\x80\x02U\x00.', encoding='latin-1') '' shows that there is probably more than one bug. From brett at python.org Wed Feb 23 20:21:58 2011 From: brett at python.org (Brett Cannon) Date: Wed, 23 Feb 2011 11:21:58 -0800 Subject: [Python-Dev] Link to issue tracker In-Reply-To: <20110223195205.5bb428e8@pitrou.net> References: <20110223165855.10d63be9@pitrou.net> <20110223195205.5bb428e8@pitrou.net> Message-ID: On Wed, Feb 23, 2011 at 10:52, Antoine Pitrou wrote: > On Wed, 23 Feb 2011 10:30:54 -0800 > Brett Cannon wrote: > > I won't add the link back, but I will try to change the global link on > the > > website to point to the devguide. python.org/dev/ at this point exists > > purely to not break pre-existing links. > > There are items there that are out of scope for the dev guide > (e.g. "Python.org Maintenance and Administration"). > Also, I do believe that being able to report a bug immediately is very > important. Reporting a bug doesn't mean you want to contribute code; it > just means you've found an issue and would like the community to know > (and possibly fix it). > Those are all linked from the devguide in the Resources section. IOW that sidebar is in the index doc already. > > Regards > > Antoine. > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin at python.org Wed Feb 23 20:36:51 2011 From: benjamin at python.org (Benjamin Peterson) Date: Wed, 23 Feb 2011 13:36:51 -0600 Subject: [Python-Dev] 3.2.0 == 20th anniversary release In-Reply-To: References: Message-ID: 2011/2/23 Georg Brandl : > On 23.02.2011 19:51, Guido van Rossum wrote: >> On Wed, Feb 23, 2011 at 10:42 AM, Terry Reedy wrote: >>> As pointed out by Ramiro Morales on the Python-Argentina list >>> (quoting Guido's blog post >>> http://python-history.blogspot.com/2009/01/brief-timeline-of-python.html >>> ) >>> Python 0.9.0 was released on 20 Feb 1991 >>> >>> Python 3.2.0 was released on 20 Feb 2011 >>> >>> Python's come a long way. >>> I look forward to the next 20. >> >> Me too! >> >> BTW very nice of Georg to time it this way. > > As much as I'd like to claim it, it's pure coincidence where my > planning is concerned. ?I knew that Python 0.9 was in 1991, so I > knew about 20 years, but not about the exact date. ?Very nice! > > Maybe it was a subconscious thing :) Or you realized later how nice it would be, grabbed the time machine, and fixed 10 release blockers on the 19th. :) -- Regards, Benjamin From benjamin at python.org Wed Feb 23 20:38:05 2011 From: benjamin at python.org (Benjamin Peterson) Date: Wed, 23 Feb 2011 13:38:05 -0600 Subject: [Python-Dev] [Python-checkins] r88503 - in python/branches/py3k: Lib/lib2to3/__main__.py Tools/scripts/2to3 In-Reply-To: References: <20110222191243.810C3F634@mail.python.org> Message-ID: 2011/2/23 Brett Cannon : > I assume you are having me do this because you still plan to cut separate > releases. Is there a minimum Python version that needs to be supported? 2.5 but that's only for benchmarking purposes IIRC. -- Regards, Benjamin From brett at python.org Wed Feb 23 20:41:20 2011 From: brett at python.org (Brett Cannon) Date: Wed, 23 Feb 2011 11:41:20 -0800 Subject: [Python-Dev] [Python-checkins] r88503 - in python/branches/py3k: Lib/lib2to3/__main__.py Tools/scripts/2to3 In-Reply-To: References: <20110222191243.810C3F634@mail.python.org> Message-ID: Does the benchmarking use the 2to3 script? I'm asking because package execution is not supported that far back. On Wed, Feb 23, 2011 at 11:38, Benjamin Peterson wrote: > 2011/2/23 Brett Cannon : > > I assume you are having me do this because you still plan to cut separate > > releases. Is there a minimum Python version that needs to be supported? > > 2.5 but that's only for benchmarking purposes IIRC. > > > > -- > Regards, > Benjamin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin at python.org Wed Feb 23 20:42:58 2011 From: benjamin at python.org (Benjamin Peterson) Date: Wed, 23 Feb 2011 13:42:58 -0600 Subject: [Python-Dev] [Python-checkins] r88503 - in python/branches/py3k: Lib/lib2to3/__main__.py Tools/scripts/2to3 In-Reply-To: References: <20110222191243.810C3F634@mail.python.org> Message-ID: 2011/2/23 Brett Cannon : > Does the benchmarking use the 2to3 script? I'm asking because package > execution is not supported that far back. Correct. But I suppose, it wouldn't really be harmful to add __main__. Just a no-op. -- Regards, Benjamin From martin at v.loewis.de Wed Feb 23 20:43:02 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Wed, 23 Feb 2011 20:43:02 +0100 Subject: [Python-Dev] 3.2.0 == 20th anniversary release In-Reply-To: References: Message-ID: <4D656346.901@v.loewis.de> > Or you realized later how nice it would be, grabbed the time machine, > and fixed 10 release blockers on the 19th. :) No no no. He actually grabbed the time machine, drove 20 years back, and gave it to Guido so he could release Python 0.9 in time. Guido then kept the machine ever since. Regards, Martin From martin at v.loewis.de Wed Feb 23 20:52:16 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Wed, 23 Feb 2011 20:52:16 +0100 Subject: [Python-Dev] Link to issue tracker In-Reply-To: References: <20110223165855.10d63be9@pitrou.net> Message-ID: <4D656570.1010002@v.loewis.de> Am 23.02.2011 19:30, schrieb Brett Cannon: > I won't add the link back Why not? It's a useful link apparently. The "Developer's Guide" link does not hint that it will be the only way to find the bug tracker. It's like adding the download page at the end of the tutorial - "you can get Python only if you read through this". Regards, Martin From solipsis at pitrou.net Wed Feb 23 20:53:40 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Wed, 23 Feb 2011 20:53:40 +0100 Subject: [Python-Dev] Link to issue tracker In-Reply-To: References: <20110223165855.10d63be9@pitrou.net> <20110223195205.5bb428e8@pitrou.net> Message-ID: <20110223205340.0b7276ce@pitrou.net> On Wed, 23 Feb 2011 11:21:58 -0800 Brett Cannon wrote: > On Wed, Feb 23, 2011 at 10:52, Antoine Pitrou wrote: > > > On Wed, 23 Feb 2011 10:30:54 -0800 > > Brett Cannon wrote: > > > I won't add the link back, but I will try to change the global link on > > the > > > website to point to the devguide. python.org/dev/ at this point exists > > > purely to not break pre-existing links. > > > > There are items there that are out of scope for the dev guide > > (e.g. "Python.org Maintenance and Administration"). > > Also, I do believe that being able to report a bug immediately is very > > important. Reporting a bug doesn't mean you want to contribute code; it > > just means you've found an issue and would like the community to know > > (and possibly fix it). > > > > Those are all linked from the devguide in the Resources section. IOW that > sidebar is in the index doc already. Yes, but I think it would be better if that link was more proeminent, either on python.org, or in the devguide. Currently it has become much less visible (you have to scroll down a page or two and hunt it in that section named "resources", assuming you know it is there at all). Of course, the Web site in general is not that good at presenting useful information first ;) Regards Antoine. From barry at python.org Wed Feb 23 20:54:40 2011 From: barry at python.org (Barry Warsaw) Date: Wed, 23 Feb 2011 14:54:40 -0500 Subject: [Python-Dev] 3.2.0 == 20th anniversary release In-Reply-To: <4D656346.901@v.loewis.de> References: <4D656346.901@v.loewis.de> Message-ID: <20110223145440.54515df7@python.org> On Feb 23, 2011, at 08:43 PM, Martin v. L?wis wrote: >> Or you realized later how nice it would be, grabbed the time machine, >> and fixed 10 release blockers on the 19th. :) > >No no no. He actually grabbed the time machine, drove 20 years back, >and gave it to Guido so he could release Python 0.9 in time. Guido >then kept the machine ever since. Keanu Reeves should definitely play Guido. I guess that means Alex Winter gets to play Georg. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From g.brandl at gmx.net Wed Feb 23 20:55:11 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Wed, 23 Feb 2011 20:55:11 +0100 Subject: [Python-Dev] r88516 - in python/branches/py3k/Python: dynload_aix.c dynload_dl.c dynload_hpux.c dynload_next.c dynload_os2.c dynload_shlib.c dynload_win.c importdl.c In-Reply-To: <1298460674.30842.0.camel@marge> References: <20110222231620.1668BEE9A5@mail.python.org> <1298460674.30842.0.camel@marge> Message-ID: On 23.02.2011 12:31, Victor Stinner wrote: > Le mercredi 23 f?vrier 2011 ? 08:35 +0100, Georg Brandl a ?crit : >> This commit introduced tabs, at least in dynload_dl.c. > > WHAT? No, I didn't introduced new tabs: dynload_dl.c always used tabs. Oh, sorry then: I thought the whole codebase had been converted. But apparently, some Gaulish villages resisted :) Georg From brett at python.org Wed Feb 23 21:06:43 2011 From: brett at python.org (Brett Cannon) Date: Wed, 23 Feb 2011 12:06:43 -0800 Subject: [Python-Dev] Link to issue tracker In-Reply-To: <20110223205340.0b7276ce@pitrou.net> References: <20110223165855.10d63be9@pitrou.net> <20110223195205.5bb428e8@pitrou.net> <20110223205340.0b7276ce@pitrou.net> Message-ID: On Wed, Feb 23, 2011 at 11:53, Antoine Pitrou wrote: > On Wed, 23 Feb 2011 11:21:58 -0800 > Brett Cannon wrote: > > On Wed, Feb 23, 2011 at 10:52, Antoine Pitrou > wrote: > > > > > On Wed, 23 Feb 2011 10:30:54 -0800 > > > Brett Cannon wrote: > > > > I won't add the link back, but I will try to change the global link > on > > > the > > > > website to point to the devguide. python.org/dev/ at this point > exists > > > > purely to not break pre-existing links. > > > > > > There are items there that are out of scope for the dev guide > > > (e.g. "Python.org Maintenance and Administration"). > > > Also, I do believe that being able to report a bug immediately is very > > > important. Reporting a bug doesn't mean you want to contribute code; it > > > just means you've found an issue and would like the community to know > > > (and possibly fix it). > > > > > > > Those are all linked from the devguide in the Resources section. IOW that > > sidebar is in the index doc already. > > Yes, but I think it would be better if that link was more proeminent, > either on python.org, or in the devguide. Currently it has become much > less visible (you have to scroll down a page or two and hunt it in that > section named "resources", assuming you know it is there at all). > The Resources section can move up the page, or at least the issue tracker link. We are not talking about a page that is hard to edit (unlike python.org). -Brett > > Of course, the Web site in general is not that good at presenting > useful information first ;) > > Regards > > Antoine. > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed Feb 23 21:05:49 2011 From: brett at python.org (Brett Cannon) Date: Wed, 23 Feb 2011 12:05:49 -0800 Subject: [Python-Dev] Link to issue tracker In-Reply-To: <4D656570.1010002@v.loewis.de> References: <20110223165855.10d63be9@pitrou.net> <4D656570.1010002@v.loewis.de> Message-ID: On Wed, Feb 23, 2011 at 11:52, "Martin v. L?wis" wrote: > Am 23.02.2011 19:30, schrieb Brett Cannon: > > I won't add the link back > > Why not? It's a useful link apparently. The "Developer's Guide" > link does not hint that it will be the only way to find the > bug tracker. > But python.org/dev/ is a dead page. I was trying to avoid adding a redirect for python.org/dev/ as I was afraid that it would lead to the website doing something silly like redirecting everything below that URL, but obviously this can continue since people seem to think that python.org/dev/ has anything useful on it (which it does not). -Brett > > It's like adding the download page at the end of the tutorial - > "you can get Python only if you read through this". > > Regards, > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed Feb 23 21:18:41 2011 From: brett at python.org (Brett Cannon) Date: Wed, 23 Feb 2011 12:18:41 -0800 Subject: [Python-Dev] Link to issue tracker In-Reply-To: References: <20110223165855.10d63be9@pitrou.net> <20110223195205.5bb428e8@pitrou.net> <20110223205340.0b7276ce@pitrou.net> Message-ID: I just added a Quick Links section to the devguide at the very top which is short and to the point. I also committed to pydotorg for python.org/dev/ to redirect to docs.python.org/devguide/, so this whole discussion is dealt with IMO. On Wed, Feb 23, 2011 at 12:06, Brett Cannon wrote: > > > On Wed, Feb 23, 2011 at 11:53, Antoine Pitrou wrote: > >> On Wed, 23 Feb 2011 11:21:58 -0800 >> Brett Cannon wrote: >> > On Wed, Feb 23, 2011 at 10:52, Antoine Pitrou >> wrote: >> > >> > > On Wed, 23 Feb 2011 10:30:54 -0800 >> > > Brett Cannon wrote: >> > > > I won't add the link back, but I will try to change the global link >> on >> > > the >> > > > website to point to the devguide. python.org/dev/ at this point >> exists >> > > > purely to not break pre-existing links. >> > > >> > > There are items there that are out of scope for the dev guide >> > > (e.g. "Python.org Maintenance and Administration"). >> > > Also, I do believe that being able to report a bug immediately is very >> > > important. Reporting a bug doesn't mean you want to contribute code; >> it >> > > just means you've found an issue and would like the community to know >> > > (and possibly fix it). >> > > >> > >> > Those are all linked from the devguide in the Resources section. IOW >> that >> > sidebar is in the index doc already. >> >> Yes, but I think it would be better if that link was more proeminent, >> either on python.org, or in the devguide. Currently it has become much >> less visible (you have to scroll down a page or two and hunt it in that >> section named "resources", assuming you know it is there at all). >> > > The Resources section can move up the page, or at least the issue tracker > link. We are not talking about a page that is hard to edit (unlike > python.org). > > -Brett > > >> >> Of course, the Web site in general is not that good at presenting >> useful information first ;) >> >> Regards >> >> Antoine. >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/brett%40python.org >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.brandl at gmx.net Wed Feb 23 21:30:20 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Wed, 23 Feb 2011 21:30:20 +0100 Subject: [Python-Dev] 3.2.0 == 20th anniversary release In-Reply-To: <4D656346.901@v.loewis.de> References: <4D656346.901@v.loewis.de> Message-ID: On 23.02.2011 20:43, "Martin v. L?wis" wrote: >> Or you realized later how nice it would be, grabbed the time machine, >> and fixed 10 release blockers on the 19th. :) > > No no no. He actually grabbed the time machine, drove 20 years back, > and gave it to Guido so he could release Python 0.9 in time. Guido > then kept the machine ever since. Uh oh. Temporal mechanics gives me headaches. Georg From foom at fuhm.net Wed Feb 23 21:38:50 2011 From: foom at fuhm.net (James Y Knight) Date: Wed, 23 Feb 2011 15:38:50 -0500 Subject: [Python-Dev] Link to issue tracker In-Reply-To: References: <20110223165855.10d63be9@pitrou.net> <4D656570.1010002@v.loewis.de> Message-ID: <74192470-92DE-4FDD-84FE-4D3ADAF316D8@fuhm.net> On Feb 23, 2011, at 3:05 PM, Brett Cannon wrote: > > > On Wed, Feb 23, 2011 at 11:52, "Martin v. L?wis" wrote: > Am 23.02.2011 19:30, schrieb Brett Cannon: > > I won't add the link back > > Why not? It's a useful link apparently. The "Developer's Guide" > link does not hint that it will be the only way to find the > bug tracker. > > But python.org/dev/ is a dead page. I was trying to avoid adding a redirect for python.org/dev/ as I was afraid that it would lead to the website doing something silly like redirecting everything below that URL, but obviously this can continue since people seem to think that python.org/dev/ has anything useful on it (which it does not). It seems unfortunate that the "Core Development" link now points directly to the devguide, since it unexpectedly breaks the navigation UI. It seemed rather more useful and consistent to have "Core Development" show the page with quick links. James -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at v.loewis.de Wed Feb 23 21:51:36 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Wed, 23 Feb 2011 21:51:36 +0100 Subject: [Python-Dev] Link to issue tracker In-Reply-To: References: <20110223165855.10d63be9@pitrou.net> <4D656570.1010002@v.loewis.de> Message-ID: <4D657358.1070602@v.loewis.de> > But python.org/dev/ is a dead page. I was > trying to avoid adding a redirect for python.org/dev/ > as I was afraid that it would lead to the > website doing something silly like redirecting everything below that > URL, but obviously this can continue since people seem to think that > python.org/dev/ has anything useful on it > (which it does not). Well, *I* ran into the problem because I hadn't reloaded the main page, and "Core Development" would still point to /dev. Now that I see that "Core Development" points to /devguide, I change my request to "please add the tracker link to the side menu of /devguide" (preferably along with a source repository link, and a linked title "More" going to #resources). As for redirects: it's certainly possible to redirect ^/dev$ to /devguide, leaving /dev..* alone. I can set this up if you want me to. Regards, Martin From brett at python.org Wed Feb 23 22:00:40 2011 From: brett at python.org (Brett Cannon) Date: Wed, 23 Feb 2011 13:00:40 -0800 Subject: [Python-Dev] Link to issue tracker In-Reply-To: <74192470-92DE-4FDD-84FE-4D3ADAF316D8@fuhm.net> References: <20110223165855.10d63be9@pitrou.net> <4D656570.1010002@v.loewis.de> <74192470-92DE-4FDD-84FE-4D3ADAF316D8@fuhm.net> Message-ID: On Wed, Feb 23, 2011 at 12:38, James Y Knight wrote: > > On Feb 23, 2011, at 3:05 PM, Brett Cannon wrote: > > > > On Wed, Feb 23, 2011 at 11:52, "Martin v. L?wis" wrote: > >> Am 23.02.2011 19:30, schrieb Brett Cannon: >> > I won't add the link back >> >> Why not? It's a useful link apparently. The "Developer's Guide" >> link does not hint that it will be the only way to find the >> bug tracker. >> > > But python.org/dev/ is a dead page. I was trying to avoid adding a > redirect for python.org/dev/ as I was afraid that it would lead to the > website doing something silly like redirecting everything below that URL, > but obviously this can continue since people seem to think that > python.org/dev/ has anything useful on it (which it does not). > > > It seems unfortunate that the "Core Development" link now points directly > to the devguide, since it unexpectedly breaks the navigation UI. It seemed > rather more useful and consistent to have "Core Development" show the page > with quick links. > Honestly, working on pydotorg is too bloody painful to even conceive of doing this purely to keep a single link on www.python.org. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Wed Feb 23 22:07:11 2011 From: guido at python.org (Guido van Rossum) Date: Wed, 23 Feb 2011 13:07:11 -0800 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> Message-ID: I'm guessing that one of these encoding names is recognized by the C code while the other one takes the slow path via the aliasing code. On Wed, Feb 23, 2011 at 11:16 AM, Alexander Belopolsky wrote: > On Tue, Feb 22, 2011 at 11:34 PM, Jesus Cea wrote: > .. >> Issue filed. It already has a patch. That was fast!. Now I can sit back >> waiting for 3.2.1 before touching my project again :). Mixed feelings >> about the waiting. I hope it is short. > > It looks like you don't need delay your project: if you spell encoding > as "latin-1", your pickle loads just fine: > > >>>> with open("z.pickle", mode="rb") as f: pickle.load(f, encoding="latin-1") > ... > {'ya_volcados': {'comment': ''}} > > > With encoding="latin1", it does fail: > >>>> with open("z.pickle", mode="rb") as f: pickle.load(f, encoding="latin1") > ... > Traceback (most recent call last): > ?File "", line 1, in > ValueError: operation forbidden on released memoryview object > > (For those not following the tracker issue, the z.pickle file was > posted at .) > > There is still a bug, which is best demonstrated by > >>>> pickle.loads(b'\x80\x02U\x00.', encoding='latin1') > Traceback (most recent call last): > ?File "", line 1, in > ValueError: operation forbidden on released memoryview object > > The fact that the above works with encoding='latin-1', > >>>> pickle.loads(b'\x80\x02U\x00.', encoding='latin-1') > '' > > shows that there is probably more than one bug. > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) From alexander.belopolsky at gmail.com Wed Feb 23 22:13:14 2011 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 23 Feb 2011 16:13:14 -0500 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> Message-ID: On Wed, Feb 23, 2011 at 4:07 PM, Guido van Rossum wrote: > I'm guessing that one of these encoding names is recognized by the C > code while the other one takes the slow path via the aliasing code. This is absolutely right. In fact I am going to propose adding strcmp(lower, "latin1") to the following test in PyUnicode_AsEncodedString(): else if ((strcmp(lower, "latin-1") == 0) || (strcmp(lower, "iso-8859-1") == 0)) return PyUnicode_EncodeLatin1(... I'll open a separate issue for that. In Python's own stdlib and tests "latin1" is a more common spelling than "latin-1", so it makes sense to optimize it. From brett at python.org Wed Feb 23 21:58:50 2011 From: brett at python.org (Brett Cannon) Date: Wed, 23 Feb 2011 12:58:50 -0800 Subject: [Python-Dev] Link to issue tracker In-Reply-To: <4D657358.1070602@v.loewis.de> References: <20110223165855.10d63be9@pitrou.net> <4D656570.1010002@v.loewis.de> <4D657358.1070602@v.loewis.de> Message-ID: On Wed, Feb 23, 2011 at 12:51, "Martin v. L?wis" wrote: > > But python.org/dev/ is a dead page. I was > > trying to avoid adding a redirect for python.org/dev/ > > as I was afraid that it would lead to the > > website doing something silly like redirecting everything below that > > URL, but obviously this can continue since people seem to think that > > python.org/dev/ has anything useful on it > > (which it does not). > > Well, *I* ran into the problem because I hadn't reloaded the main page, > and "Core Development" would still point to /dev. > > Now that I see that "Core Development" points to /devguide, > I change my request to "please add the tracker link to the side menu > of /devguide" (preferably along with a source repository link, > and a linked title "More" going to #resources). > I'll see what I can do. I added a Quick Links section at the very top of the main page so that can at least hold you over. > > As for redirects: it's certainly possible to redirect ^/dev$ to > /devguide, leaving /dev..* alone. I can set this up if you want me to. > Please. Or double-check what I put into pydotorg's redirect.txt will work properly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mal at egenix.com Wed Feb 23 22:23:29 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 23 Feb 2011 22:23:29 +0100 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> Message-ID: <4D657AD1.7000408@egenix.com> Alexander Belopolsky wrote: > On Wed, Feb 23, 2011 at 4:07 PM, Guido van Rossum wrote: >> I'm guessing that one of these encoding names is recognized by the C >> code while the other one takes the slow path via the aliasing code. > > This is absolutely right. In fact I am going to propose adding > strcmp(lower, "latin1") to the following test in > PyUnicode_AsEncodedString(): > > > else if ((strcmp(lower, "latin-1") == 0) || > (strcmp(lower, "iso-8859-1") == 0)) > return PyUnicode_EncodeLatin1(... > > I'll open a separate issue for that. In Python's own stdlib and tests > "latin1" is a more common spelling than "latin-1", so it makes sense > to optimize it. "Latin-1" is the official name and the one used internally by Python, so it would be good to have the test suite and Python code in general to use that variant of the name (just as "utf-8" is preferred over "utf8"). Instead of adding more aliases to the C code, please change the encoding names in the stdlib and test suite. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 23 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From alexander.belopolsky at gmail.com Wed Feb 23 22:34:01 2011 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 23 Feb 2011 16:34:01 -0500 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <4D657AD1.7000408@egenix.com> References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> <4D657AD1.7000408@egenix.com> Message-ID: On Wed, Feb 23, 2011 at 4:23 PM, M.-A. Lemburg wrote: .. > "Latin-1" is the official name and the one used internally by Python, > so it would be good to have the test suite and Python code in general > to use that variant of the name (just as "utf-8" is preferred over > "utf8"). > > Instead of adding more aliases to the C code, please change the > encoding names in the stdlib and test suite. I cannot agree with you on this one. Official or not, "latin-1" is much less commonly used than "latin1". Currently decode("latin1") is 10x slower than decode("latin-1") on short strings. We already have a check for "iso-8859-1" alias in PyUnicode_AsEncodedString(). Adding "latin1" (and possibly "utf8" as well) is likely to speed up many applications at minimal cost. From foom at fuhm.net Wed Feb 23 22:45:04 2011 From: foom at fuhm.net (James Y Knight) Date: Wed, 23 Feb 2011 16:45:04 -0500 Subject: [Python-Dev] Link to issue tracker In-Reply-To: References: <20110223165855.10d63be9@pitrou.net> <4D656570.1010002@v.loewis.de> <74192470-92DE-4FDD-84FE-4D3ADAF316D8@fuhm.net> Message-ID: On Feb 23, 2011, at 4:00 PM, Brett Cannon wrote: > On Wed, Feb 23, 2011 at 12:38, James Y Knight wrote: > > On Feb 23, 2011, at 3:05 PM, Brett Cannon wrote: > >> >> >> On Wed, Feb 23, 2011 at 11:52, "Martin v. L?wis" wrote: >> Am 23.02.2011 19:30, schrieb Brett Cannon: >> > I won't add the link back >> >> Why not? It's a useful link apparently. The "Developer's Guide" >> link does not hint that it will be the only way to find the >> bug tracker. >> >> But python.org/dev/ is a dead page. I was trying to avoid adding a redirect for python.org/dev/ as I was afraid that it would lead to the website doing something silly like redirecting everything below that URL, but obviously this can continue since people seem to think that python.org/dev/ has anything useful on it (which it does not). > > It seems unfortunate that the "Core Development" link now points directly to the devguide, since it unexpectedly breaks the navigation UI. It seemed rather more useful and consistent to have "Core Development" show the page with quick links. > > Honestly, working on pydotorg is too bloody painful to even conceive of doing this purely to keep a single link onwww.python.org. Well, presumably at least 5 links: Devguide, PEP index, buildbot, issue tracker, link to source code browser. But sure, I'm just a user, I have no idea how hard it is to edit a page on pydotorg (and no, I don't really want to know). But I seriously cannot imagine it's so hard that you can't leave a page with a few links there, that had already been written! Note how clicking everything else in the left navbar makes useful links appear below the item, and the rest of the page keep the same theme/general layout. "Core Development" is now the unexpected exception to that UI consistency, and is less useful because of it. James -------------- next part -------------- An HTML attachment was scrubbed... URL: From mal at egenix.com Wed Feb 23 22:54:34 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 23 Feb 2011 22:54:34 +0100 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> <4D657AD1.7000408@egenix.com> Message-ID: <4D65821A.30905@egenix.com> Alexander Belopolsky wrote: > On Wed, Feb 23, 2011 at 4:23 PM, M.-A. Lemburg wrote: > .. >> "Latin-1" is the official name and the one used internally by Python, >> so it would be good to have the test suite and Python code in general >> to use that variant of the name (just as "utf-8" is preferred over >> "utf8"). >> >> Instead of adding more aliases to the C code, please change the >> encoding names in the stdlib and test suite. > > I cannot agree with you on this one. Official or not, "latin-1" is > much less commonly used than "latin1". Currently decode("latin1") is > 10x slower than decode("latin-1") on short strings. We already have > a check for "iso-8859-1" alias in PyUnicode_AsEncodedString(). Adding > "latin1" (and possibly "utf8" as well) is likely to speed up many > applications at minimal cost. Fair enough, then add "latin1" and "utf8" to both PyUnicode_Decode() and PyUnicode_AsEncodedString(). Still, the stdlib and test suite should be examples of using the correct names. I only found these few cases where the wrong Latin-1 name is used in the stdlib: ./distutils/command/bdist_wininst.py: -- # convert back to bytes. "latin1" simply avoids any possible -- encoding="latin1") as script: -- script_data = script.read().encode("latin1") ./urllib/request.py: -- data = base64.decodebytes(data.encode('ascii')).decode('latin1') ./asynchat.py: -- encoding = 'latin1' ./ftplib.py: -- encoding = "latin1" ./sre_parse.py: -- encode = lambda x: x.encode('latin1') I get 12 hits for the test suite. Yet 108 for the correct name, so I can't follow your statement that the wrong variant is used more often. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 23 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From alexander.belopolsky at gmail.com Wed Feb 23 23:09:36 2011 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 23 Feb 2011 17:09:36 -0500 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <4D65821A.30905@egenix.com> References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> <4D657AD1.7000408@egenix.com> <4D65821A.30905@egenix.com> Message-ID: On Wed, Feb 23, 2011 at 4:54 PM, M.-A. Lemburg wrote: .. > Yet 108 for the correct name, so I can't follow your statement > that the wrong variant is used more often. Hmm, your grepping skills are probably better than mine. I get $ grep -iw latin-1 Lib/*.py | wc -l 24 and $ grep -iw latin1 Lib/test/*.py | wc -l 25 (I did get spurious hits with naive "grep latin1", so I retract my "more often" claim and just say that both spellings are equally common.) From alexander.belopolsky at gmail.com Wed Feb 23 23:21:54 2011 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 23 Feb 2011 17:21:54 -0500 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <4D657AD1.7000408@egenix.com> References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> <4D657AD1.7000408@egenix.com> Message-ID: On Wed, Feb 23, 2011 at 4:23 PM, M.-A. Lemburg wrote: .. > "Latin-1" is the official name and the one used internally by Python, In what sense is "Latin-1" the official name? The IANA charset registry has the following listing Name: ISO_8859-1:1987 [RFC1345,KXS2] MIBenum: 4 Source: ECMA registry Alias: iso-ir-100 Alias: ISO_8859-1 Alias: ISO-8859-1 (preferred MIME name) Alias: latin1 Alias: l1 Alias: IBM819 Alias: CP819 Alias: csISOLatin1 (See http://www.iana.org/assignments/character-sets) "Latin-1" spelling does appear in various unicode.org documents, but not in machine readable files as far as I can tell. From mal at egenix.com Wed Feb 23 23:21:56 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 23 Feb 2011 23:21:56 +0100 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> <4D657AD1.7000408@egenix.com> <4D65821A.30905@egenix.com> Message-ID: <4D658884.4060606@egenix.com> Alexander Belopolsky wrote: > On Wed, Feb 23, 2011 at 4:54 PM, M.-A. Lemburg wrote: > .. >> Yet 108 for the correct name, so I can't follow your statement >> that the wrong variant is used more often. > > Hmm, your grepping skills are probably better than mine. I get > > > $ grep -iw latin-1 Lib/*.py | wc -l > 24 > > and > > $ grep -iw latin1 Lib/test/*.py | wc -l > 25 > > (I did get spurious hits with naive "grep latin1", so I retract my > "more often" claim and just say that both spellings are equally > common.) I used a Python script based on re, perhaps that's why :-) grep only counts lines, not multiple instances on a single line and looking through the hits I found, there are a few false positives such as 'latin-10' or 'iso-latin-1'. Without those, I get 83 hits. If you open a ticket for this, I'll add the list of hits to that ticket. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 23 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From alexander.belopolsky at gmail.com Wed Feb 23 23:36:18 2011 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 23 Feb 2011 17:36:18 -0500 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <4D658884.4060606@egenix.com> References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> <4D657AD1.7000408@egenix.com> <4D65821A.30905@egenix.com> <4D658884.4060606@egenix.com> Message-ID: On Wed, Feb 23, 2011 at 5:21 PM, M.-A. Lemburg wrote: .. > If you open a ticket for this, I'll add the list of hits to > that ticket. > http://bugs.python.org/issue11303 From ethan at stoneleaf.us Wed Feb 23 23:46:06 2011 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 23 Feb 2011 14:46:06 -0800 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <4D65821A.30905@egenix.com> References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> <4D657AD1.7000408@egenix.com> <4D65821A.30905@egenix.com> Message-ID: <4D658E2E.3000907@stoneleaf.us> M.-A. Lemburg wrote: > Still, the stdlib and test suite should be examples of using the > correct names. I won't argue with the stdlib portion of your argument, but I would think that the best example of test code would be a complete and thorough check of all options. ~Ethan~ From barry at python.org Wed Feb 23 23:45:30 2011 From: barry at python.org (Barry Warsaw) Date: Wed, 23 Feb 2011 17:45:30 -0500 Subject: [Python-Dev] [RELEASED] Python 3.2 In-Reply-To: <1298245152.5269.24.camel@marge> References: <4D619437.7050507@python.org> <1298245152.5269.24.camel@marge> Message-ID: <20110223174530.2c3a6ae6@python.org> On Feb 21, 2011, at 12:39 AM, Victor Stinner wrote: >Le dimanche 20 f?vrier 2011 ? 23:22 +0100, Georg Brandl a ?crit : >> On behalf of the Python development team, I'm delighted to announce >> Python 3.2 final release. >> >> Python 3.2 is a continuation of the efforts to improve and stabilize the >> Python 3.x line. > >Congratulation to all Python developers for this wonderful release! And >a special kudo to our release manager, Georg. Indeed, great job Georg. I hereby nominate you for Python 3.3 RM. No good deed goes unpunished. :) >I hope that Python 3 is now stable enough to support migration of major >projects like Django, Twisted or Zope. Other important projets like >Distribute, Jinja2, PyQt, PyGObject, pygame, NumPy+SciPy and Sphinx are >already compatible with Python 3. Agreed! I hope porting to Python 3 can be a major theme for Pycon this year. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From mal at egenix.com Thu Feb 24 00:32:56 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 24 Feb 2011 00:32:56 +0100 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> <4D657AD1.7000408@egenix.com> Message-ID: <4D659928.7090404@egenix.com> Alexander Belopolsky wrote: > On Wed, Feb 23, 2011 at 4:23 PM, M.-A. Lemburg wrote: > .. >> "Latin-1" is the official name and the one used internally by Python, > > In what sense is "Latin-1" the official name? The IANA charset > registry has the following listing > > > Name: ISO_8859-1:1987 [RFC1345,KXS2] > MIBenum: 4 > Source: ECMA registry > Alias: iso-ir-100 > Alias: ISO_8859-1 > Alias: ISO-8859-1 (preferred MIME name) > Alias: latin1 > Alias: l1 > Alias: IBM819 > Alias: CP819 > Alias: csISOLatin1 > > (See http://www.iana.org/assignments/character-sets) Those are registered character set names, not necessarily standard names. Anyone can apply for new aliases to get added to that list. > "Latin-1" spelling does appear in various unicode.org documents, but > not in machine readable files as far as I can tell. "Latin-1" is short for "Latin Alphabet No. 1" and started out as ECMA-94 in 1985 and 1986: http://www.ecma-international.org/publications/standards/Ecma-094.htm ISO then applied their numbering scheme for the character set standard ISO-8859 in 1987 where "Latin-1" became "ISO-8859-1". Note that this was before the Internet took off. I assume that since the HTML standard used the more popular name "Latin-1" for its definition of the default character set and also made use of the term throughout the spec, it became the de-facto standard name for that character set at the time. I only learned about the term "ISO-8859-1" when starting to dive into the Unicode world late in the 1990s. "Latin-1" is also sometimes written as "ISO Latin-1", e.g. http://msdn.microsoft.com/en-us/library/ms537495(v=vs.85).aspx For much the same reasons, "ISO-10646" never really became popular, but "Unicode" eventually did. "ECMA-262" or "ISO/IEC 16262" just doesn't sound as good as "JavaScript" either :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 23 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From martin at v.loewis.de Thu Feb 24 00:40:25 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Thu, 24 Feb 2011 00:40:25 +0100 Subject: [Python-Dev] Link to issue tracker In-Reply-To: References: <20110223165855.10d63be9@pitrou.net> <4D656570.1010002@v.loewis.de> <4D657358.1070602@v.loewis.de> Message-ID: <4D659AE9.1050408@v.loewis.de> > As for redirects: it's certainly possible to redirect ^/dev$ to > /devguide, leaving /dev..* alone. I can set this up if you want me to. > > > Please. Or double-check what I put into pydotorg's redirect.txt will > work properly. What redirect.txt did you edit specifically? I have now changed redirects.conf, and it seems to work fine. Please let me know if there are any problems. Regards, Martin From brett at python.org Thu Feb 24 00:42:52 2011 From: brett at python.org (Brett Cannon) Date: Wed, 23 Feb 2011 15:42:52 -0800 Subject: [Python-Dev] Link to issue tracker In-Reply-To: <4D659AE9.1050408@v.loewis.de> References: <20110223165855.10d63be9@pitrou.net> <4D656570.1010002@v.loewis.de> <4D657358.1070602@v.loewis.de> <4D659AE9.1050408@v.loewis.de> Message-ID: On Wed, Feb 23, 2011 at 15:40, "Martin v. L?wis" wrote: > > As for redirects: it's certainly possible to redirect ^/dev$ to > > /devguide, leaving /dev..* alone. I can set this up if you want me > to. > > > > > > Please. Or double-check what I put into pydotorg's redirect.txt will > > work properly. > > What redirect.txt did you edit specifically? > It was beta.python.org/build/redirects.txt, but I went ahead and reverted the change since your solution works. > > I have now changed redirects.conf, and it seems to work fine. Please > let me know if there are any problems. > Works for me. Thanks, Martin! -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.belopolsky at gmail.com Thu Feb 24 00:56:14 2011 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 23 Feb 2011 18:56:14 -0500 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <4D659928.7090404@egenix.com> References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> <4D657AD1.7000408@egenix.com> <4D659928.7090404@egenix.com> Message-ID: On Wed, Feb 23, 2011 at 6:32 PM, M.-A. Lemburg wrote: > Alexander Belopolsky wrote: .. >> In what sense is "Latin-1" the official name? ?The IANA charset >> registry has the following listing >> >> >> Name: ISO_8859-1:1987 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[RFC1345,KXS2] >> MIBenum: 4 >> Source: ECMA registry >> Alias: iso-ir-100 >> Alias: ISO_8859-1 >> Alias: ISO-8859-1 (preferred MIME name) >> Alias: latin1 .. > "Latin-1" is short for "Latin Alphabet No. 1" and > started out as ECMA-94 in 1985 and 1986: This does not explain your preference of "Latin-1" over "Latin1". Both are perfectly valid abbreviations for "Latin Alphabet No. 1". The spelling without "-" has the advantage of being a valid Python identifier and a module name. The IANA registration for "latin1" and lack of that for "latin-1" most likely indicates that the former is more commonly found in machine readable metadata. From stephen at xemacs.org Thu Feb 24 02:14:59 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 24 Feb 2011 10:14:59 +0900 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <4D659928.7090404@egenix.com> References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> <4D657AD1.7000408@egenix.com> <4D659928.7090404@egenix.com> Message-ID: <878vx6nsh8.fsf@uwakimon.sk.tsukuba.ac.jp> M.-A. Lemburg writes: > "Latin-1" is short for "Latin Alphabet No. 1" [...]. > I assume that since the HTML standard used the more popular > name "Latin-1" for its definition of the default character set > and also made use of the term throughout the spec, it > became the de-facto standard name for that character set > at the time. As usual with de facto standards, it got "embraced and extended". I've seen people seriously contend that Windows-1252 is an "implementation" or (conformant) extension of "Latin-1", and that the EURO SIGN is now a member of "Latin-1". It's just too ambiguous for my taste; I avoid it in discussions of character sets, preferring to be thought idiosyncratic and pedantic. As for the spelling, I think "Latin-1" is slightly more readable than "Latin1", but the latter is in the same degree more typable. > For much the same reasons, "ISO-10646" never really became > popular, but "Unicode" eventually did. No, there are much more important reasons why "Unicode" became popular. IMHO, as an encoding standard ISO-10646 had a slight edge over Unicode in the early 1990s, before the two were unified as coded character sets. However, as a text processing system there simply was no comparison. Unicode provided a large number of standard facilities, and was clearly set to add to those, that were way outside of the scope of ISO 10646. Claiming Unicode conformance was a much bigger deal than ISO 10646 (not to mention having the "advantage" that you could *optionally* save Intel shorts to disk without swabbing them first). From digitalxero at gmail.com Thu Feb 24 02:48:04 2011 From: digitalxero at gmail.com (Dj Gilcrease) Date: Wed, 23 Feb 2011 20:48:04 -0500 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <878vx6nsh8.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> <4D657AD1.7000408@egenix.com> <4D659928.7090404@egenix.com> <878vx6nsh8.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: Google Code search limited to python latin1:?3,489 http://www.google.com/codesearch?hl=en&lr=&q=latin1+lang%3Apython&sbtn=Search latin-1: 5,604 http://www.google.com/codesearch?hl=en&lr=&q=latin-1+lang%3Apython&sbtn=Search utf8: 25,341 http://www.google.com/codesearch?hl=en&lr=&q=utf8+lang%3Apython&sbtn=Search utf-8: 179,806 http://www.google.com/codesearch?hl=en&lr=&q=utf-8+lang%3Apython&sbtn=Search Interesting that for Latin-1 the split of "wrong"/"right" is 40/60 and the split for utf8 is 15/85 From alexander.belopolsky at gmail.com Thu Feb 24 03:19:06 2011 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 23 Feb 2011 21:19:06 -0500 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> <4D657AD1.7000408@egenix.com> <4D659928.7090404@egenix.com> <878vx6nsh8.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On Wed, Feb 23, 2011 at 8:48 PM, Dj Gilcrease wrote: > Google Code search limited to python > > latin1:?3,489 http://www.google.com/codesearch?hl=en&lr=&q=latin1+lang%3Apython&sbtn=Search > latin-1: 5,604 http://www.google.com/codesearch?hl=en&lr=&q=latin-1+lang%3Apython&sbtn=Search > > utf8: 25,341 http://www.google.com/codesearch?hl=en&lr=&q=utf8+lang%3Apython&sbtn=Search > utf-8: 179,806 http://www.google.com/codesearch?hl=en&lr=&q=utf-8+lang%3Apython&sbtn=Search > > > Interesting that for Latin-1 the split of "wrong"/"right" is 40/60 and > the split for utf8 is 15/85 Your search is invalid. You hit things such as Latin1ClassModel which have no relevance to the issue at hand. From jnoller at gmail.com Thu Feb 24 04:05:50 2011 From: jnoller at gmail.com (Jesse Noller) Date: Wed, 23 Feb 2011 22:05:50 -0500 Subject: [Python-Dev] [RELEASED] Python 3.2 In-Reply-To: <20110223174530.2c3a6ae6@python.org> References: <4D619437.7050507@python.org> <1298245152.5269.24.camel@marge> <20110223174530.2c3a6ae6@python.org> Message-ID: On Wed, Feb 23, 2011 at 5:45 PM, Barry Warsaw wrote: > On Feb 21, 2011, at 12:39 AM, Victor Stinner wrote: > >>Le dimanche 20 f?vrier 2011 ? 23:22 +0100, Georg Brandl a ?crit : >>> On behalf of the Python development team, I'm delighted to announce >>> Python 3.2 final release. >>> >>> Python 3.2 is a continuation of the efforts to improve and stabilize the >>> Python 3.x line. >> >>Congratulation to all Python developers for this wonderful release! And >>a special kudo to our release manager, Georg. > > Indeed, great job Georg. ?I hereby nominate you for Python 3.3 RM. ?No good > deed goes unpunished. :) > >>I hope that Python 3 is now stable enough to support migration of major >>projects like Django, Twisted or Zope. Other important projets like >>Distribute, Jinja2, PyQt, PyGObject, pygame, NumPy+SciPy and Sphinx are >>already compatible with Python 3. > > Agreed! ?I hope porting to Python 3 can be a major theme for Pycon this year. > > -Barry It is. Trust me. From scott+python-dev at scottdial.com Thu Feb 24 04:22:05 2011 From: scott+python-dev at scottdial.com (Scott Dial) Date: Wed, 23 Feb 2011 22:22:05 -0500 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> <4D657AD1.7000408@egenix.com> <4D659928.7090404@egenix.com> <878vx6nsh8.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <4D65CEDD.5000404@scottdial.com> On 2/23/2011 9:19 PM, Alexander Belopolsky wrote: > On Wed, Feb 23, 2011 at 8:48 PM, Dj Gilcrease wrote: >> Google Code search limited to python >> >> latin1: 3,489 http://www.google.com/codesearch?hl=en&lr=&q=latin1+lang%3Apython&sbtn=Search >> latin-1: 5,604 http://www.google.com/codesearch?hl=en&lr=&q=latin-1+lang%3Apython&sbtn=Search latin1: 1,618 http://www.google.com/codesearch?hl=en&lr=&q=%28\%22latin1\%22|\%27latin1\%27%29+lang%3Apython&sbtn=Search latin-1: 2,241 http://www.google.com/codesearch?hl=en&lr=&q=%28\%22latin-1\%22|\%27latin-1\%27%29+lang%3Apython&sbtn=Search >> utf8: 25,341 http://www.google.com/codesearch?hl=en&lr=&q=utf8+lang%3Apython&sbtn=Search >> utf-8: 179,806 http://www.google.com/codesearch?hl=en&lr=&q=utf-8+lang%3Apython&sbtn=Search utf8 9,676 http://www.google.com/codesearch?hl=en&lr=&q=%28\%22utf8\%22|\%27utf8\%27%29+lang%3Apython&sbtn=Search utf-8 44,795 http://www.google.com/codesearch?hl=en&lr=&q=%28\%22utf-8\%22|\%27utf-8\%27%29+lang%3Apython&sbtn=Search > Your search is invalid. You hit things such as Latin1ClassModel which > have no relevance to the issue at hand. You get about the same ratio if you filter out only the quoted strings. -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From martin at v.loewis.de Thu Feb 24 07:43:50 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Thu, 24 Feb 2011 07:43:50 +0100 Subject: [Python-Dev] Link to issue tracker In-Reply-To: References: <20110223165855.10d63be9@pitrou.net> <4D656570.1010002@v.loewis.de> <4D657358.1070602@v.loewis.de> <4D659AE9.1050408@v.loewis.de> Message-ID: <4D65FE26.4060800@v.loewis.de> > What redirect.txt did you edit specifically? > > > It was beta.python.org/build/redirects.txt > , but I went ahead and > reverted the change since your solution works. Ah. That file isn't used, AFAICT, so I now deleted it. If there are any other redirects that you want to see active, please let me know. Regards, Martin From mal at egenix.com Thu Feb 24 10:02:10 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 24 Feb 2011 10:02:10 +0100 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> <4D657AD1.7000408@egenix.com> <4D659928.7090404@egenix.com> Message-ID: <4D661E92.1080909@egenix.com> Alexander Belopolsky wrote: > On Wed, Feb 23, 2011 at 6:32 PM, M.-A. Lemburg wrote: >> Alexander Belopolsky wrote: > .. >>> In what sense is "Latin-1" the official name? The IANA charset >>> registry has the following listing >>> >>> >>> Name: ISO_8859-1:1987 [RFC1345,KXS2] >>> MIBenum: 4 >>> Source: ECMA registry >>> Alias: iso-ir-100 >>> Alias: ISO_8859-1 >>> Alias: ISO-8859-1 (preferred MIME name) >>> Alias: latin1 > .. >> "Latin-1" is short for "Latin Alphabet No. 1" and >> started out as ECMA-94 in 1985 and 1986: > > This does not explain your preference of "Latin-1" over "Latin1". This is not my preference. See e.g. Wikipedia http://en.wikipedia.org/wiki/ISO/IEC_8859-1 It is common practice to replace spaces in descriptive names with a hyphen to come up with an identifier string (even Google does or undoes this when searching the net). Replacing spaces with an empty string is also an option, but doesn't read as well. > Both are perfectly valid abbreviations for "Latin Alphabet No. 1". > The spelling without "-" has the advantage of being a valid Python > identifier and a module name. The hyphens are converted to underscores by the lookup function in the encodings package. That turns the name into a valid Python module name. > The IANA registration for "latin1" and > lack of that for "latin-1" most likely indicates that the former is > more commonly found in machine readable metadata. I don't know why you emphasize so much on machine readable metadata. Python source code is machine readable, the Internet is machine readable, all documents found there are machine readable. As I said earlier on: the IANA registry is just that - a registry of names with the purpose of avoiding name clashes in the resp. name space. As such, it is not a standard, but merely a tool to map various aliases to a canoncial name. The fact that an alias is registered doesn't allow any implication on whether it's in wide-spread use or not, e.g. "csISOLatin1" gives me 6810 hits on Google. I get 788,000 hits for 'latin1 -"latin-1"' on Google, 'latin-1' gives 2,600,000 hits. Looks like it's still the preferred way to write that encoding name. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 24 2011) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From scott+python-dev at scottdial.com Thu Feb 24 17:59:57 2011 From: scott+python-dev at scottdial.com (Scott Dial) Date: Thu, 24 Feb 2011 11:59:57 -0500 Subject: [Python-Dev] Strange error importing a Pickle from 2.7 to 3.2 In-Reply-To: <4D661E92.1080909@egenix.com> References: <4D63A89A.20609@jcea.es> <87ei6zo510.fsf@uwakimon.sk.tsukuba.ac.jp> <4D648E63.2050106@jcea.es> <4D657AD1.7000408@egenix.com> <4D659928.7090404@egenix.com> <4D661E92.1080909@egenix.com> Message-ID: <4D668E8D.1020305@scottdial.com> On 2/24/2011 4:02 AM, M.-A. Lemburg wrote: > I get 788,000 hits for 'latin1 -"latin-1"' on Google, > 'latin-1' gives 2,600,000 hits. Looks like it's still > the preferred way to write that encoding name. That's bogus. You can't search for "latin-1" on Google, it isn't strict enough. The third hit is a url containing "latin1" and a title of "Latin 1". And it picks up things like "Latin 1: The Easy Way", which is a book on Latin. However, you *can* search much more strictly on Google Code Search, which gives 4,014 ("latin-1") to 13,597 ("latin1"). http://www.google.com/codesearch?hl=en&lr=&q=%28\%22latin1\%22|\%27latin1\%27%29&sbtn=Search http://www.google.com/codesearch?hl=en&lr=&q=%28\%22latin-1\%22|\%27latin-1\%27%29&sbtn=Search So, no, I don't think the development world aligns with your pedantry. That's not to say this is a popularity contest, but then let's not cite google hit counts as proof. -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From brett at python.org Thu Feb 24 19:42:27 2011 From: brett at python.org (Brett Cannon) Date: Thu, 24 Feb 2011 10:42:27 -0800 Subject: [Python-Dev] Link to issue tracker In-Reply-To: <4D65FE26.4060800@v.loewis.de> References: <20110223165855.10d63be9@pitrou.net> <4D656570.1010002@v.loewis.de> <4D657358.1070602@v.loewis.de> <4D659AE9.1050408@v.loewis.de> <4D65FE26.4060800@v.loewis.de> Message-ID: On Wed, Feb 23, 2011 at 22:43, "Martin v. L?wis" wrote: > > What redirect.txt did you edit specifically? > > > > > > It was beta.python.org/build/redirects.txt > > , but I went ahead and > > reverted the change since your solution works. > > Ah. That file isn't used, AFAICT, so I now deleted it. Are you sure? I added entries last week to that file and they worked when the website updated. > If there > are any other redirects that you want to see active, please > let me know. > Personally I cared about all of the redirects that were in that file pertaining to /dev. -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.rodola at gmail.com Thu Feb 24 20:51:20 2011 From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=) Date: Thu, 24 Feb 2011 20:51:20 +0100 Subject: [Python-Dev] r88501 - python/branches/py3k/Lib/smtplib.py In-Reply-To: References: <20110222155620.B82D2EE9B5@mail.python.org> Message-ID: Mmmm probably. smtplib patches aren't too big/many though. Should I revert the change? 2011/2/23 Georg Brandl : > You're sure this will not cause tedious conflicts with backports? > > Georg > > On 22.02.2011 16:56, giampaolo.rodola wrote: >> Author: giampaolo.rodola >> Date: Tue Feb 22 16:56:20 2011 >> New Revision: 88501 >> >> Log: >> smtlib.py PEP8 normalization via pep8.py script. >> >> Modified: >> ? ?python/branches/py3k/Lib/smtplib.py >> >> Modified: python/branches/py3k/Lib/smtplib.py >> ============================================================================== >> --- python/branches/py3k/Lib/smtplib.py ? ? ? (original) >> +++ python/branches/py3k/Lib/smtplib.py ? ? ? Tue Feb 22 16:56:20 2011 >> @@ -52,15 +52,15 @@ > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com > From g.brandl at gmx.net Thu Feb 24 20:53:10 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Thu, 24 Feb 2011 20:53:10 +0100 Subject: [Python-Dev] r88501 - python/branches/py3k/Lib/smtplib.py In-Reply-To: References: <20110222155620.B82D2EE9B5@mail.python.org> Message-ID: On 24.02.2011 20:51, Giampaolo Rodol? wrote: > Mmmm probably. smtplib patches aren't too big/many though. > Should I revert the change? It's probably fine if you do the same change to the maintenance branches as well. Georg From g.rodola at gmail.com Thu Feb 24 21:43:49 2011 From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=) Date: Thu, 24 Feb 2011 21:43:49 +0100 Subject: [Python-Dev] r88501 - python/branches/py3k/Lib/smtplib.py In-Reply-To: References: <20110222155620.B82D2EE9B5@mail.python.org> Message-ID: Done for Python 3.1 and 2.7. 2011/2/24 Georg Brandl : > On 24.02.2011 20:51, Giampaolo Rodol? wrote: >> Mmmm probably. smtplib patches aren't too big/many though. >> Should I revert the change? > > It's probably fine if you do the same change to the maintenance > branches as well. > > Georg > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com > From g.brandl at gmx.net Thu Feb 24 22:10:00 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Thu, 24 Feb 2011 22:10:00 +0100 Subject: [Python-Dev] [RELEASED] Python 3.2 In-Reply-To: <20110223174530.2c3a6ae6@python.org> References: <4D619437.7050507@python.org> <1298245152.5269.24.camel@marge> <20110223174530.2c3a6ae6@python.org> Message-ID: On 23.02.2011 23:45, Barry Warsaw wrote: > On Feb 21, 2011, at 12:39 AM, Victor Stinner wrote: > >>Le dimanche 20 f?vrier 2011 ? 23:22 +0100, Georg Brandl a ?crit : >>> On behalf of the Python development team, I'm delighted to announce >>> Python 3.2 final release. >>> >>> Python 3.2 is a continuation of the efforts to improve and stabilize the >>> Python 3.x line. >> >>Congratulation to all Python developers for this wonderful release! And >>a special kudo to our release manager, Georg. > > Indeed, great job Georg. I hereby nominate you for Python 3.3 RM. No good > deed goes unpunished. :) Well, I guess that makes sense. In a twisted way :) Georg From belopolsky at users.sourceforge.net Thu Feb 24 22:18:20 2011 From: belopolsky at users.sourceforge.net (Alexander Belopolsky) Date: Thu, 24 Feb 2011 16:18:20 -0500 Subject: [Python-Dev] [issue11286] Some "trivial" python 2.x pickles fails to load in Python 3.2 In-Reply-To: <1298581635.3722.2.camel@localhost.localdomain> References: <1298581635.3722.2.camel@localhost.localdomain> Message-ID: It seems appropriate to consult python-dev on this. I thought ValueError was for values that are valid Python objects but out of acceptable range of the function. Errors that can only be triggered in C code normally handled with either assert() or raise SystemError. I think you are splitting hairs too thin by distinguishing between stdlib and 3rd party extensions. On Thu, Feb 24, 2011 at 4:07 PM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> > I've committed the part of the patch which disallows a NULL data pointer >> > with PyMemoryView_FromBuffer in r88550 and r88551. >> >> Is it possible to create such buffer in Python (other than by >> exploiting a bug or writing a rogue extension module)? ?If not, this >> should be a SystemError or even just an assert() rather than >> ValueError. > > I'm against asserts for such use, since they get disabled in non-debug > mode (which is the mode 99.99% of users run in). > > As for SystemError, it means "Internal error in the Python interpreter", > which isn't the case here (most likely it's an error in an extension > module instead, possibly a third-party one). > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > From solipsis at pitrou.net Fri Feb 25 01:19:04 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 25 Feb 2011 01:19:04 +0100 Subject: [Python-Dev] Mercurial conversion repositories Message-ID: <20110225011904.3ed09de7@pitrou.net> Hello, Georg and I have been working on converting the SVN repository to Mercurial. We can now present you a test repository (actually, two). CPython repository: http://hg.python.org/cpython/ ------------------ This is the main conversion repository. It contains all history of trunk and py3k (since 1990!) up to now, including all maintenance branches starting from 2.0 up to 3.2. If you are a core developer, get your local clone of the repository using: $ hg clone ssh://hg at hg.python.org/cpython (this uses the same SSH key as your Subversion access; for more information about Mercurial and SSH keys, see the converted development FAQ: http://potrou.net/hgdevguide/faq.html#faq ) If you are not a core developer: $ hg clone http://hg.python.org/cpython Your clone will contain the following branches: $ hg branches default 68026:f12ef116dd10 3.2 68025:cef92ee1a323 2.7 68010:8174d00d0797 3.1 67955:5be8b695ea86 2.6 67287:5e26a860eded 2.5 65464:e4ecac76e499 trunk 62750:800f6c92c3ed 3.0 60075:1d05144224fe 2.4 58552:df72cac1899e 2.3 45731:a3d9a9730743 2.2 40444:d55ddc8c8501 2.1 30171:06fcccf6eca8 2.0 18214:dc0dfc9565cd The branch "default" is the current py3k branch from SVN. The branch "trunk" represents SVN trunk history until 2.7 was branched for maintenance. The full list of tags is too long to print here, but you can get it using: $ hg tags The size of the repository on-disk is (depending on your filesystem): $ du -hs .hg 176M .hg (the size of the network transfer is estimated to be around 80MB) You can commit and even push to this repository (the latter if you are a core developer). Since this is a test repository, whatever you push will be discarded when we do the final conversion. CPython with extra history: http://hg.python.org/cpythonextrahist/ -------------------------- This repository is bigger, and has a much more complicated topology. It is a superset of the other repository, and contains the totality of the branches from the SVN repository (it has more than 450 repository heads, of which 87 non-closed). It also weighs quite a bit more: $ du -hs .hg 248M .hg This repository is unnecessary for development work, since even for history-digging purposes the normal repository has the necessary information. This repository is only to preserve historical record of some of the non-trunk development work from the SVN repository (such as orphaned/deleted feature branches). Development guide: http://potrou.net/hgdevguide/ ----------------- This is the development guide adapted for Mercurial. You can get its sources from the branch "hg_transition" in http://hg.python.org/devguide/. Regards Antoine. From raymond.hettinger at gmail.com Fri Feb 25 01:46:57 2011 From: raymond.hettinger at gmail.com (Raymond Hettinger) Date: Thu, 24 Feb 2011 16:46:57 -0800 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110225011904.3ed09de7@pitrou.net> References: <20110225011904.3ed09de7@pitrou.net> Message-ID: <773AD9BF-95AF-4A58-80BF-7C2468C5F678@gmail.com> On Feb 24, 2011, at 4:19 PM, Antoine Pitrou wrote: > Georg and I have been working on converting the SVN repository to > Mercurial. We can now present you a test repository (actually, two). > > > CPython repository: http://hg.python.org/cpython/ Thank you both for all the effort you put in. I'll do some tests today. Raymond From brett at python.org Fri Feb 25 02:39:40 2011 From: brett at python.org (Brett Cannon) Date: Thu, 24 Feb 2011 17:39:40 -0800 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110225011904.3ed09de7@pitrou.net> References: <20110225011904.3ed09de7@pitrou.net> Message-ID: On Thu, Feb 24, 2011 at 16:19, Antoine Pitrou wrote: > > Hello, > > Georg and I have been working on converting the SVN repository to > Mercurial. We can now present you a test repository (actually, two). > Thanks to the both of you for moving this forward! > > > CPython repository: http://hg.python.org/cpython/ > ------------------ > > This is the main conversion repository. It contains all history of > trunk and py3k (since 1990!) up to now, including all maintenance > branches starting from 2.0 up to 3.2. > > If you are a core developer, get your local clone of the repository > using: > > $ hg clone ssh://hg at hg.python.org/cpython > > (this uses the same SSH key as your Subversion access; for more > information about Mercurial and SSH keys, see the converted development > FAQ: http://potrou.net/hgdevguide/faq.html#faq ) > > If you are not a core developer: > > $ hg clone http://hg.python.org/cpython > > Your clone will contain the following branches: > > $ hg branches > default 68026:f12ef116dd10 > 3.2 68025:cef92ee1a323 > 2.7 68010:8174d00d0797 > 3.1 67955:5be8b695ea86 > 2.6 67287:5e26a860eded > 2.5 65464:e4ecac76e499 > trunk 62750:800f6c92c3ed > 3.0 60075:1d05144224fe > 2.4 58552:df72cac1899e > 2.3 45731:a3d9a9730743 > 2.2 40444:d55ddc8c8501 > 2.1 30171:06fcccf6eca8 > 2.0 18214:dc0dfc9565cd > > The branch "default" is the current py3k branch from SVN. The branch > "trunk" represents SVN trunk history until 2.7 was branched for > maintenance. > Just to help justify it in my head, the trunk branch exists for the history and nothing more, right? I mean we are not even accepting commits on it after we branched so I assume there is no real new history there compared to 2.7. Could we actually close the branch so it isn't even visible by default to prevent confusing people? -Brett > > The full list of tags is too long to print here, but you can get it > using: > > $ hg tags > > The size of the repository on-disk is (depending on your filesystem): > > $ du -hs .hg > 176M .hg > > (the size of the network transfer is estimated to be around 80MB) > > You can commit and even push to this repository (the latter if you are a > core developer). Since this is a test repository, whatever you push > will be discarded when we do the final conversion. > > > CPython with extra history: http://hg.python.org/cpythonextrahist/ > -------------------------- > > This repository is bigger, and has a much more complicated topology. It > is a superset of the other repository, and contains the totality of the > branches from the SVN repository (it has more than 450 repository > heads, of which 87 non-closed). It also weighs quite a bit more: > > $ du -hs .hg > 248M .hg > > This repository is unnecessary for development work, since even for > history-digging purposes the normal repository has the necessary > information. This repository is only to preserve historical record of > some of the non-trunk development work from the SVN repository (such > as orphaned/deleted feature branches). > Just to give a comparison to svn, release-27maint is 243M and py3k is 231M (and that is with `make distclean` run). IOW the complete history of all branches of Python is just 5M bigger than just a checkout of 2.7. -Brett > > > Development guide: http://potrou.net/hgdevguide/ > ----------------- > > This is the development guide adapted for Mercurial. You can get its > sources from the branch "hg_transition" in > http://hg.python.org/devguide/. > > > Regards > > Antoine. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliben at gmail.com Fri Feb 25 06:38:32 2011 From: eliben at gmail.com (Eli Bendersky) Date: Fri, 25 Feb 2011 07:38:32 +0200 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110225011904.3ed09de7@pitrou.net> References: <20110225011904.3ed09de7@pitrou.net> Message-ID: On Fri, Feb 25, 2011 at 02:19, Antoine Pitrou wrote: > > Hello, > > Georg and I have been working on converting the SVN repository to > Mercurial. We can now present you a test repository (actually, two). > > > CPython repository: http://hg.python.org/cpython/ > ------------------ > > This is the main conversion repository. It contains all history of > trunk and py3k (since 1990!) up to now, including all maintenance > branches starting from 2.0 up to 3.2. > > If you are a core developer, get your local clone of the repository > using: > > ? ?$ hg clone ssh://hg at hg.python.org/cpython > > (this uses the same SSH key as your Subversion access; for more > information about Mercurial and SSH keys, see the converted development > FAQ: http://potrou.net/hgdevguide/faq.html#faq ) > Yay - Mercurial at last! Thanks for pushing this forward. I'll do some tests with the new repo later today. Eli From g.brandl at gmx.net Fri Feb 25 07:46:04 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Fri, 25 Feb 2011 07:46:04 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110225011904.3ed09de7@pitrou.net> References: <20110225011904.3ed09de7@pitrou.net> Message-ID: On 25.02.2011 01:19, Antoine Pitrou wrote: > > Hello, > > Georg and I have been working on converting the SVN repository to > Mercurial. We can now present you a test repository (actually, two). The implied agenda is that we would be *very* happy if we could do the final conversion during PyCon (we both won't be attending, so we have plenty of time ;) -- so that the sprints can already benefit from the agility provided by hg. That's a timescale of around two weeks, which should be plenty for testing. > CPython repository: http://hg.python.org/cpython/ > ------------------ > > This is the main conversion repository. It contains all history of > trunk and py3k (since 1990!) up to now, including all maintenance > branches starting from 2.0 up to 3.2. > > If you are a core developer, get your local clone of the repository > using: > > $ hg clone ssh://hg at hg.python.org/cpython > > (this uses the same SSH key as your Subversion access; for more > information about Mercurial and SSH keys, see the converted development > FAQ: http://potrou.net/hgdevguide/faq.html#faq ) [...] > You can commit and even push to this repository (the latter if you are a > core developer). Since this is a test repository, whatever you push > will be discarded when we do the final conversion. So, to stress this point: Please *do* experiment, commit and push stuff to this repository, especially if you've not worked with hg before. You can break nothing (or if you do, it's not your fault :) Georg From eliben at gmail.com Fri Feb 25 08:29:16 2011 From: eliben at gmail.com (Eli Bendersky) Date: Fri, 25 Feb 2011 09:29:16 +0200 Subject: [Python-Dev] strange buildbot fail Message-ID: Hi, Earlier today I've committed revision 88554, and a bit later a buildbot failure message was received: Builder AMD64 Windows Server 2008 hg-3.x build #47 failed with failed test_import, blamelist having my name because I made the last commit (apparently). Two other buildbots succeeded building and testing after my commit, as did my local tests. Some examination of the failed test shows no apparent connection to my commit. What can be done in cases like this? How to investigate further? Thanks in advance, Eli From dirkjan at ochtman.nl Fri Feb 25 08:50:16 2011 From: dirkjan at ochtman.nl (Dirkjan Ochtman) Date: Fri, 25 Feb 2011 08:50:16 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110225011904.3ed09de7@pitrou.net> References: <20110225011904.3ed09de7@pitrou.net> Message-ID: On Fri, Feb 25, 2011 at 01:19, Antoine Pitrou wrote: > Georg and I have been working on converting the SVN repository to > Mercurial. We can now present you a test repository (actually, two). Sorry everyone for taking so long on the conversion. Looks like Antoine and Georg have more time and energy to spend on this than I do, so I will let them pick up my slack. Cheers, Dirkjan From martin at v.loewis.de Fri Feb 25 09:09:36 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Fri, 25 Feb 2011 09:09:36 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110225011904.3ed09de7@pitrou.net> References: <20110225011904.3ed09de7@pitrou.net> Message-ID: <4D6763C0.3030904@v.loewis.de> > Georg and I have been working on converting the SVN repository to > Mercurial. We can now present you a test repository (actually, two). Thanks for working on this! How do you want bugs reported? Can you please update the PEP? I see at least the following deviations: - the extrahist repository is not mentioned - the branchmap is (apparently?) not evaluated; in particular, it's not clear whether the keep-clone branches went. - it's not clear what your view on the subversion repository is - do you keep the notion of discarded branches (i.e. branches that can only be discovered from looking at a copy of the subversion repository), or do you mean to convert everything? As for the cpythonextrahist repository: why are the heads all unnamed? How are you supposed to find anything in it? I think I would have liked the strategy of the PEP better (i.e. create clones for feature branches, rather than putting all in a single repository). Regards, Martin From nyamatongwe at gmail.com Fri Feb 25 09:13:49 2011 From: nyamatongwe at gmail.com (Neil Hodgson) Date: Fri, 25 Feb 2011 19:13:49 +1100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110225011904.3ed09de7@pitrou.net> References: <20110225011904.3ed09de7@pitrou.net> Message-ID: With hg 1.7.5 on Windows 7 I performed a non-core checkout: hg clone http://hg.python.org/cpython The eol extension is enabled in global settings. I looked at things a bit, opening some files and using the Tortoise Hg Repository Explorer. But made no actual changes. Running hg diff produces a large amount of output with almost all the *.decTest and most of the Windows build files (*.mk, *.sln, *.vcproj, *.bat) showing as changed but with identical text. I've had problems like this with Hg before (http://mercurial.selenic.com/bts/issue2287). The situation can be fixed by hg update to another version and then back to default. Neil From dirkjan at ochtman.nl Fri Feb 25 09:17:28 2011 From: dirkjan at ochtman.nl (Dirkjan Ochtman) Date: Fri, 25 Feb 2011 09:17:28 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <4D6763C0.3030904@v.loewis.de> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> Message-ID: On Fri, Feb 25, 2011 at 09:09, "Martin v. L?wis" wrote: > I think I would have liked the strategy of the PEP better (i.e. > create clones for feature branches, rather than putting all > in a single repository). Unnamed heads are trivial to convert to clones. Cheers, Dirkjan From martin at v.loewis.de Fri Feb 25 09:21:00 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Fri, 25 Feb 2011 09:21:00 +0100 Subject: [Python-Dev] strange buildbot fail In-Reply-To: References: Message-ID: <4D67666C.4080707@v.loewis.de> Am 25.02.2011 08:29, schrieb Eli Bendersky: > Hi, > Earlier today I've committed revision 88554, and a bit later a > buildbot failure message was received: > Builder AMD64 Windows Server 2008 hg-3.x build #47 failed with failed > test_import, blamelist having my name because I made the last commit > (apparently). > > Two other buildbots succeeded building and testing after my commit, as > did my local tests. Some examination of the failed test shows no > apparent connection to my commit. > You find the builder here: http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%20hg-3.x The specific build you can find here http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%20hg-3.x/builds/47 The failing build step is here http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%20hg-3.x/builds/47/steps/test/logs/stdio The failure message is this: test test_import failed -- Traceback (most recent call last): File "c:\buildslave-py3k\hg-3.x.curtin-win2008-amd64\build\lib\test\test_import.py", line 182, in test_failing_import_sticks self.assertRaises(ZeroDivisionError, __import__, TESTFN) AssertionError: ZeroDivisionError not raised by __import__ In re-running the test, the test succeeded: test_failing_import_sticks (test.test_import.ImportTests) ... ok So apparently, this test case has a transient failure. It's not obvious (to me) why there might be a transient failure in this test case. > What can be done in cases like this? How to investigate further? One way of dealing with it is to ignore it. If you do want to investigate further, try to reproduce the failure. It may be that the specific sequence in which the tests are executed can cause the failure. Or it's specific to the Windows installation, and some interaction with the virus scanner, in which case you should ask Brian for remote-desktop access to the build slave in order to reproduce it. HTH, Martin From martin at v.loewis.de Fri Feb 25 09:25:31 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Fri, 25 Feb 2011 09:25:31 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> Message-ID: <4D67677B.6060706@v.loewis.de> Am 25.02.2011 09:17, schrieb Dirkjan Ochtman: > On Fri, Feb 25, 2011 at 09:09, "Martin v. L?wis" wrote: >> I think I would have liked the strategy of the PEP better (i.e. >> create clones for feature branches, rather than putting all >> in a single repository). > > Unnamed heads are trivial to convert to clones. If there are hundreds of them, it's far from trivial. I don't even know how to find out which one to convert. Regards, Martin From dirkjan at ochtman.nl Fri Feb 25 09:29:05 2011 From: dirkjan at ochtman.nl (Dirkjan Ochtman) Date: Fri, 25 Feb 2011 09:29:05 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <4D67677B.6060706@v.loewis.de> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <4D67677B.6060706@v.loewis.de> Message-ID: On Fri, Feb 25, 2011 at 09:25, "Martin v. L?wis" wrote: > If there are hundreds of them, it's far from trivial. I don't even know > how to find out which one to convert. Right, I mostly mean it's trivial for Antoine or Georg to extract into a clone (at least that's how I was planning to do it, not sure what their idea is). Cheers, Dirkjan From martin at v.loewis.de Fri Feb 25 09:36:32 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Fri, 25 Feb 2011 09:36:32 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <4D67677B.6060706@v.loewis.de> Message-ID: <4D676A10.6090901@v.loewis.de> Am 25.02.2011 09:29, schrieb Dirkjan Ochtman: > On Fri, Feb 25, 2011 at 09:25, "Martin v. L?wis" wrote: >> If there are hundreds of them, it's far from trivial. I don't even know >> how to find out which one to convert. > > Right, I mostly mean it's trivial for Antoine or Georg to extract into > a clone (at least that's how I was planning to do it, not sure what > their idea is). Ah ok. So I guess that goes back to my original request - that the PEP be updated. Regards, Martin From juraj.ivancic at gmail.com Fri Feb 25 09:48:54 2011 From: juraj.ivancic at gmail.com (=?ISO-8859-2?Q?Juraj_Ivan=E8i=E6?=) Date: Fri, 25 Feb 2011 09:48:54 +0100 Subject: [Python-Dev] PyEval_InitThreads() no longer safe before Py_Initialize() in 3.2 Message-ID: It seems that PyEval_InitThreads() can no longer be called before Py_Initialize(). I get a fatal error in PyThreadState_GET(). This contradicts the documentation http://docs.python.org/release/3.2/c-api/init.html#PyEval_InitThreads Minimal repro: #include "Python.h" int main() { PyEval_InitThreads(); return 0; } From raymond.hettinger at gmail.com Fri Feb 25 10:50:13 2011 From: raymond.hettinger at gmail.com (Raymond Hettinger) Date: Fri, 25 Feb 2011 01:50:13 -0800 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <4D6763C0.3030904@v.loewis.de> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> Message-ID: <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> On Feb 25, 2011, at 12:09 AM, Martin v. L?wis wrote: > I think I would have liked the strategy of the PEP better (i.e. > create clones for feature branches, rather than putting all > in a single repository). In my brief tests, the single repository has been easy to work with. If they were separate, it would complicate backporting patches and merges. So, I'm happy with how George and Benjamin put this together. Raymond From solipsis at pitrou.net Fri Feb 25 13:52:58 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 25 Feb 2011 13:52:58 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> Message-ID: <20110225135258.3cae8851@pitrou.net> On Fri, 25 Feb 2011 19:13:49 +1100 Neil Hodgson wrote: > With hg 1.7.5 on Windows 7 I performed a non-core checkout: > > hg clone http://hg.python.org/cpython > > The eol extension is enabled in global settings. Yes, please try to disable it. The issue is we have a .hgeol in the repository right now (it's in the SVN repository too), but it doesn't match the reality of on-disk files, so when you update, the eol extension tries to "fix" those files. Regards Antoine. From solipsis at pitrou.net Fri Feb 25 14:08:51 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 25 Feb 2011 14:08:51 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> Message-ID: <20110225140851.5a655cfb@pitrou.net> On Thu, 24 Feb 2011 17:39:40 -0800 Brett Cannon wrote: > > > > Your clone will contain the following branches: > > > > $ hg branches > > default 68026:f12ef116dd10 > > 3.2 68025:cef92ee1a323 > > 2.7 68010:8174d00d0797 > > 3.1 67955:5be8b695ea86 > > 2.6 67287:5e26a860eded > > 2.5 65464:e4ecac76e499 > > trunk 62750:800f6c92c3ed > > 3.0 60075:1d05144224fe > > 2.4 58552:df72cac1899e > > 2.3 45731:a3d9a9730743 > > 2.2 40444:d55ddc8c8501 > > 2.1 30171:06fcccf6eca8 > > 2.0 18214:dc0dfc9565cd > > > > The branch "default" is the current py3k branch from SVN. The branch > > "trunk" represents SVN trunk history until 2.7 was branched for > > maintenance. > > > > Just to help justify it in my head, the trunk branch exists for the history > and nothing more, right? True. > Could we actually close the branch so it isn't even visible by default > to prevent confusing people? Yes, we can. This can be done post-conversion, actually. Something like: $ hg up trunk $ hg ci --close-branch -m "Close trunk" Regards Antoine. From g.brandl at gmx.net Fri Feb 25 14:14:17 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Fri, 25 Feb 2011 14:14:17 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <4D67677B.6060706@v.loewis.de> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <4D67677B.6060706@v.loewis.de> Message-ID: On 25.02.2011 09:25, "Martin v. L?wis" wrote: > Am 25.02.2011 09:17, schrieb Dirkjan Ochtman: >> On Fri, Feb 25, 2011 at 09:09, "Martin v. L?wis" wrote: >>> I think I would have liked the strategy of the PEP better (i.e. >>> create clones for feature branches, rather than putting all >>> in a single repository). >> >> Unnamed heads are trivial to convert to clones. > > If there are hundreds of them, it's far from trivial. I don't even know > how to find out which one to convert. The full-history repo has several ways to get at that information, so it's quite for us to extract feature branches as separate clones. Since most side-track branches won't actually be needed anymore, we'd like to reconstruct them on request. I assume you'd like to have pep-0383? Georg From barry at python.org Fri Feb 25 17:12:53 2011 From: barry at python.org (Barry Warsaw) Date: Fri, 25 Feb 2011 11:12:53 -0500 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> Message-ID: <20110225111253.2f34357e@limelight.wooz.org> On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote: > >On Feb 25, 2011, at 12:09 AM, Martin v. L?wis wrote: > >> I think I would have liked the strategy of the PEP better (i.e. >> create clones for feature branches, rather than putting all >> in a single repository). > >In my brief tests, the single repository has been easy to work with. >If they were separate, it would complicate backporting patches >and merges. So, I'm happy with how George and Benjamin put this together. The way I work with the Subversion branches is to have all the active branches checked out into separate directories under a common parent, e.g. ~/projects/python/py26 ~/projects/python/py27 ~/projects/python/trunk ~/projects/python/py31 ~/projects/python/py32 ~/projects/python/py3k This makes it very easy to just cd, svn up, make distclean, configure, make to test things. How can I do this with the hg clone when all the branches are in the single repository, but more or less hidden? After doing the 'hg clone' operation specified by Antoine, I'm left with a single cpython directory containing (iiuc) the contents of the 'default' branch. I'm sure I'm not the only one who works this way with Subversion. IWBN to cover this in the devguide (or is it there and I missed it?). Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From techtonik at gmail.com Fri Feb 25 17:13:09 2011 From: techtonik at gmail.com (anatoly techtonik) Date: Fri, 25 Feb 2011 18:13:09 +0200 Subject: [Python-Dev] 3.2.0 == 20th anniversary release In-Reply-To: References: <4D656346.901@v.loewis.de> Message-ID: On Wed, Feb 23, 2011 at 10:30 PM, Georg Brandl wrote: > On 23.02.2011 20:43, "Martin v. L?wis" wrote: >>> Or you realized later how nice it would be, grabbed the time machine, >>> and fixed 10 release blockers on the 19th. :) >> >> No no no. He actually grabbed the time machine, drove 20 years back, >> and gave it to Guido so he could release Python 0.9 in time. Guido >> then kept the machine ever since. > > Uh oh. Temporal mechanics gives me headaches. While SciPy conference folks are inventing pythonic API for that stuff, the most we can do now is analyze reasons for missing goals and aims from this period, and try to neutralize their effect as the Python grows. -- anatoly t. From solipsis at pitrou.net Fri Feb 25 17:29:01 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 25 Feb 2011 17:29:01 +0100 Subject: [Python-Dev] Mercurial conversion repositories References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> Message-ID: <20110225172901.36dffde6@pitrou.net> Hi Barry, > The way I work with the Subversion branches is to have all the active branches > checked out into separate directories under a common parent, e.g. > > ~/projects/python/py26 > ~/projects/python/py27 > ~/projects/python/trunk > ~/projects/python/py31 > ~/projects/python/py32 > ~/projects/python/py3k > > This makes it very easy to just cd, svn up, make distclean, configure, make to > test things. How can I do this with the hg clone when all the branches are > in the single repository, but more or less hidden? After doing the 'hg clone' > operation specified by Antoine, I'm left with a single cpython directory > containing (iiuc) the contents of the 'default' branch. Indeed, the default branch is checked out by default. But you can switch to another branch: $ hg sum parent: 68026:f12ef116dd10 tip In FTP.close() method, make sure to also close the socket object, not only the file. branch: default commit: (clean) update: (current) $ hg up 2.7 3310 files updated, 0 files merged, 378 files removed, 0 files unresolved $ hg sum parent: 68010:8174d00d0797 Merged revisions 88486 via svnmerge from branch: 2.7 commit: (clean) update: (current) ("hg sum" is a shorthand for "hg summary") Furthermore, once you have a local clone, you can clone it further to get several independent clones, and keep each of them updated on whatever branch you want. This makes it easy to replicate your workflow (by having a "master clone" - a mirror if you want - and then child clones that get updated from the master clone by running "hg pull"). > I'm sure I'm not the only one who works this way with Subversion. IWBN to > cover this in the devguide (or is it there and I missed it?). Use of "hg update" to switch between branches is mentioned in http://potrou.net/hgdevguide/setup.html#getting-the-source-code and also http://potrou.net/hgdevguide/coredev.html#read-write-checkout and also in http://potrou.net/hgdevguide/committing.html#porting-within-a-major-version. But a dedicated FAQ entry could be added. Regards Antoine. From g.brandl at gmx.net Fri Feb 25 17:31:45 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Fri, 25 Feb 2011 17:31:45 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110225111253.2f34357e@limelight.wooz.org> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> Message-ID: On 25.02.2011 17:12, Barry Warsaw wrote: > On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote: > >> >>On Feb 25, 2011, at 12:09 AM, Martin v. L?wis wrote: >> >>> I think I would have liked the strategy of the PEP better (i.e. >>> create clones for feature branches, rather than putting all >>> in a single repository). >> >>In my brief tests, the single repository has been easy to work with. >>If they were separate, it would complicate backporting patches >>and merges. So, I'm happy with how George and Benjamin put this together. > > The way I work with the Subversion branches is to have all the active branches > checked out into separate directories under a common parent, e.g. > > ~/projects/python/py26 > ~/projects/python/py27 > ~/projects/python/trunk > ~/projects/python/py31 > ~/projects/python/py32 > ~/projects/python/py3k > > This makes it very easy to just cd, svn up, make distclean, configure, make to > test things. How can I do this with the hg clone when all the branches are > in the single repository, but more or less hidden? After doing the 'hg clone' > operation specified by Antoine, I'm left with a single cpython directory > containing (iiuc) the contents of the 'default' branch. Two scenarios are possible: * You make a clone per branch with the full history, with the current branch being different in each of those. Since "hg update" updates to the head of the current branch, this should be easy to do. When you pull from the single repo you will get changes for the other branches as well, but they will not bother you. * You make a clone per branch, containing *only* the respective branch (with its ancestors). This is done by using "URI#branchname" as the source when cloning/pulling. Both should work equally well, with the former giving larger repository sizes, and the latter taking somewhat longer on the initial clone. Georg From g.brandl at gmx.net Fri Feb 25 17:42:55 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Fri, 25 Feb 2011 17:42:55 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> Message-ID: On 25.02.2011 17:31, Georg Brandl wrote: > On 25.02.2011 17:12, Barry Warsaw wrote: >> On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote: >> >>> >>>On Feb 25, 2011, at 12:09 AM, Martin v. L?wis wrote: >>> >>>> I think I would have liked the strategy of the PEP better (i.e. >>>> create clones for feature branches, rather than putting all >>>> in a single repository). >>> >>>In my brief tests, the single repository has been easy to work with. >>>If they were separate, it would complicate backporting patches >>>and merges. So, I'm happy with how George and Benjamin put this together. >> >> The way I work with the Subversion branches is to have all the active branches >> checked out into separate directories under a common parent, e.g. >> >> ~/projects/python/py26 >> ~/projects/python/py27 >> ~/projects/python/trunk >> ~/projects/python/py31 >> ~/projects/python/py32 >> ~/projects/python/py3k >> >> This makes it very easy to just cd, svn up, make distclean, configure, make to >> test things. How can I do this with the hg clone when all the branches are >> in the single repository, but more or less hidden? After doing the 'hg clone' >> operation specified by Antoine, I'm left with a single cpython directory >> containing (iiuc) the contents of the 'default' branch. > > Two scenarios are possible: > > * You make a clone per branch with the full history, with the current branch > being different in each of those. Since "hg update" updates to the head of > the current branch, this should be easy to do. When you pull from the single > repo you will get changes for the other branches as well, but they will not > bother you. > > * You make a clone per branch, containing *only* the respective branch (with > its ancestors). This is done by using "URI#branchname" as the source when > cloning/pulling. > > Both should work equally well, with the former giving larger repository sizes, > and the latter taking somewhat longer on the initial clone. Ah, and the latter obviously also won't work with the "hg-native" workflow (merging between the branches using hg merge). Georg From status at bugs.python.org Fri Feb 25 18:07:03 2011 From: status at bugs.python.org (Python tracker) Date: Fri, 25 Feb 2011 18:07:03 +0100 (CET) Subject: [Python-Dev] Summary of Python tracker Issues Message-ID: <20110225170703.F22FE1CC70@psf.upfronthosting.co.za> ACTIVITY SUMMARY (2011-02-18 - 2011-02-25) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2682 (+27) closed 20422 (+52) total 23104 (+79) Open issues with patches: 1137 Issues opened (56) ================== #11244: Negative tuple elements produce inefficient code. http://bugs.python.org/issue11244 opened by jdharper #11245: Implementation of IMAP IDLE in imaplib? http://bugs.python.org/issue11245 opened by Shay.Rojansky #11246: PyUnicode_FromFormat("%V") decodes the byte string from ISO-88 http://bugs.python.org/issue11246 opened by haypo #11247: Error sending packets to multicast IPV4 address http://bugs.python.org/issue11247 opened by dmahn #11250: 2to3 truncates files at formfeed character http://bugs.python.org/issue11250 opened by cgohlke #11253: autodocument first appearance of ctypes.wintypes constants http://bugs.python.org/issue11253 opened by techtonik #11254: distutils doesn't byte-compile .py files to __pycache__ during http://bugs.python.org/issue11254 opened by scoder #11255: 2to3 throws AttributeError during distutils installation with http://bugs.python.org/issue11255 opened by scoder #11256: inspect.getcallargs raises TypeError on valid arguments http://bugs.python.org/issue11256 opened by durban #11257: asyncore stores unnecessary object references http://bugs.python.org/issue11257 opened by mmarkk #11258: ctypes: Speed up find_library() on Linux by 500% http://bugs.python.org/issue11258 opened by jonash #11259: asynchat does not check if terminator is negative integer http://bugs.python.org/issue11259 opened by mmarkk #11260: smtpd-as-a-script feature should be documented and should use http://bugs.python.org/issue11260 opened by xmorel #11261: urlopen breaks when data parameter is used. http://bugs.python.org/issue11261 opened by david193 #11265: asyncore does not check for EAGAIN errno http://bugs.python.org/issue11265 opened by mmarkk #11266: asyncore does not handle EINTR in recv, send, connect, accept, http://bugs.python.org/issue11266 opened by mmarkk #11267: asyncore does not check for POLLERR and POLLHUP if neither rea http://bugs.python.org/issue11267 opened by mmarkk #11270: logging: RotatingFileHandler crash when opening the Logfile in http://bugs.python.org/issue11270 opened by RockstarVC #11271: concurrent.futures.ProcessPoolExecutor.map() slower than multi http://bugs.python.org/issue11271 opened by tbrink #11273: asyncore creates selec (or poll) on every iteration http://bugs.python.org/issue11273 opened by mmarkk #11275: Linking to gcc's gomp causes crash later. http://bugs.python.org/issue11275 opened by hoytak #11276: 2to3: imports fixer doesn't update references to modules speci http://bugs.python.org/issue11276 opened by Arfrever #11279: test_posix and lack of "id -G" support - less noise required? http://bugs.python.org/issue11279 opened by illumino #11281: smtplib: add ability to bind to specific source IP address/por http://bugs.python.org/issue11281 opened by paulos #11282: unittest document not keep consist with code http://bugs.python.org/issue11282 opened by ysj.ray #11283: incorrect pattern in the re module docs for conditional regex http://bugs.python.org/issue11283 opened by wesley.chun #11284: slow close file descriptors in subprocess, popen2, os.pepen* http://bugs.python.org/issue11284 opened by s7v7nislands #11287: Add context manager support to dbm modules http://bugs.python.org/issue11287 opened by ysj.ray #11289: smtplib context manager http://bugs.python.org/issue11289 opened by giampaolo.rodola #11290: ttk.Combobox['values'] String Conversion to Tcl http://bugs.python.org/issue11290 opened by claytondarwin #11291: poplib suppresses exception on QUIT http://bugs.python.org/issue11291 opened by giampaolo.rodola #11292: Curses - add A_REVERSE to attributes table http://bugs.python.org/issue11292 opened by sandro.tosi #11293: Distutils - read the file when using it in long_description http://bugs.python.org/issue11293 opened by sandro.tosi #11294: Locale - update & uniform ERA_*_FMT doc http://bugs.python.org/issue11294 opened by sandro.tosi #11297: Make ChainMap() public in the collections module. http://bugs.python.org/issue11297 opened by rhettinger #11298: unittest discovery needs better explanation http://bugs.python.org/issue11298 opened by blokeley #11299: Allow deepcopying and pickling paused generators http://bugs.python.org/issue11299 opened by cool-RR #11300: mmap() large file failures on Mac OS X docfix http://bugs.python.org/issue11300 opened by sdaoden #11302: Add more tests to test_ast.py http://bugs.python.org/issue11302 opened by vincele #11303: b'x'.decode('latin1') is much slower than b'x'.decode('latin-1 http://bugs.python.org/issue11303 opened by belopolsky #11305: TextIOWrapper.readline and str.splitlines have different behav http://bugs.python.org/issue11305 opened by benjamin.peterson #11306: mailbox should test for errno.EROFS http://bugs.python.org/issue11306 opened by matt #11307: re engine exhaustively explores more than necessary http://bugs.python.org/issue11307 opened by nikomatsakis #11309: #include in Objects/unicodetype_db.h and Objects/un http://bugs.python.org/issue11309 opened by dilyan.palauzov #11310: Document byte[s|array]() and byte[s|array](count) in docstring http://bugs.python.org/issue11310 opened by terry.reedy #11311: StringIO.readline(0) returns incorrect results http://bugs.python.org/issue11311 opened by scop #11312: Confusing sentence in file.readline() doc http://bugs.python.org/issue11312 opened by scop #11313: Speed up default encode()/decode() http://bugs.python.org/issue11313 opened by belopolsky #11314: Subprocess suffers 40% process creation overhead penalty http://bugs.python.org/issue11314 opened by Aaron.Sherman #11315: Cookie.py breaks when passed unicode, fix included http://bugs.python.org/issue11315 opened by Alexander.Tsepkov #11316: RFC822 header parsing API inconsistencies between httplib.HTTP http://bugs.python.org/issue11316 opened by jrjsmrtn #11318: Python 3.2 FAQ example code typo? http://bugs.python.org/issue11318 opened by Retro #11319: Command line option -t (and -tt) does not work for a particula http://bugs.python.org/issue11319 opened by jerome.radix #11320: Usage of API method Py_SetPath causes errors in Py_Initialize( http://bugs.python.org/issue11320 opened by palm.kevin #11321: 9th import of module _pickle always crashes http://bugs.python.org/issue11321 opened by palm.kevin #11322: encoding package's normalize_encoding() function is too slow http://bugs.python.org/issue11322 opened by lemburg Most recent 15 issues with no replies (15) ========================================== #11321: 9th import of module _pickle always crashes http://bugs.python.org/issue11321 #11320: Usage of API method Py_SetPath causes errors in Py_Initialize( http://bugs.python.org/issue11320 #11319: Command line option -t (and -tt) does not work for a particula http://bugs.python.org/issue11319 #11315: Cookie.py breaks when passed unicode, fix included http://bugs.python.org/issue11315 #11312: Confusing sentence in file.readline() doc http://bugs.python.org/issue11312 #11310: Document byte[s|array]() and byte[s|array](count) in docstring http://bugs.python.org/issue11310 #11300: mmap() large file failures on Mac OS X docfix http://bugs.python.org/issue11300 #11294: Locale - update & uniform ERA_*_FMT doc http://bugs.python.org/issue11294 #11293: Distutils - read the file when using it in long_description http://bugs.python.org/issue11293 #11292: Curses - add A_REVERSE to attributes table http://bugs.python.org/issue11292 #11291: poplib suppresses exception on QUIT http://bugs.python.org/issue11291 #11290: ttk.Combobox['values'] String Conversion to Tcl http://bugs.python.org/issue11290 #11283: incorrect pattern in the re module docs for conditional regex http://bugs.python.org/issue11283 #11282: unittest document not keep consist with code http://bugs.python.org/issue11282 #11279: test_posix and lack of "id -G" support - less noise required? http://bugs.python.org/issue11279 Most recent 15 issues waiting for review (15) ============================================= #11315: Cookie.py breaks when passed unicode, fix included http://bugs.python.org/issue11315 #11313: Speed up default encode()/decode() http://bugs.python.org/issue11313 #11310: Document byte[s|array]() and byte[s|array](count) in docstring http://bugs.python.org/issue11310 #11303: b'x'.decode('latin1') is much slower than b'x'.decode('latin-1 http://bugs.python.org/issue11303 #11302: Add more tests to test_ast.py http://bugs.python.org/issue11302 #11300: mmap() large file failures on Mac OS X docfix http://bugs.python.org/issue11300 #11298: unittest discovery needs better explanation http://bugs.python.org/issue11298 #11297: Make ChainMap() public in the collections module. http://bugs.python.org/issue11297 #11294: Locale - update & uniform ERA_*_FMT doc http://bugs.python.org/issue11294 #11293: Distutils - read the file when using it in long_description http://bugs.python.org/issue11293 #11292: Curses - add A_REVERSE to attributes table http://bugs.python.org/issue11292 #11291: poplib suppresses exception on QUIT http://bugs.python.org/issue11291 #11289: smtplib context manager http://bugs.python.org/issue11289 #11287: Add context manager support to dbm modules http://bugs.python.org/issue11287 #11284: slow close file descriptors in subprocess, popen2, os.pepen* http://bugs.python.org/issue11284 Top 10 most discussed issues (10) ================================= #11303: b'x'.decode('latin1') is much slower than b'x'.decode('latin-1 http://bugs.python.org/issue11303 40 msgs #11281: smtplib: add ability to bind to specific source IP address/por http://bugs.python.org/issue11281 13 msgs #11244: Negative tuple elements produce inefficient code. http://bugs.python.org/issue11244 11 msgs #11260: smtpd-as-a-script feature should be documented and should use http://bugs.python.org/issue11260 11 msgs #11243: email/message.py str conversion http://bugs.python.org/issue11243 10 msgs #11199: urllib hangs when closing connection http://bugs.python.org/issue11199 9 msgs #10791: Wrapping TextIOWrapper around gzip files http://bugs.python.org/issue10791 8 msgs #11298: unittest discovery needs better explanation http://bugs.python.org/issue11298 8 msgs #11015: Bring test.support docs up to date http://bugs.python.org/issue11015 7 msgs #11071: What's New review comments http://bugs.python.org/issue11071 7 msgs Issues closed (47) ================== #4681: mmap offset should be off_t instead of ssize_t, and size calcu http://bugs.python.org/issue4681 closed by pitrou #8914: Run clang's static analyzer http://bugs.python.org/issue8914 closed by brett.cannon #10512: regrtest ResourceWarning - unclosed sockets and files http://bugs.python.org/issue10512 closed by brett.cannon #10516: Add list.clear() and list.copy() http://bugs.python.org/issue10516 closed by georg.brandl #10826: pass_fds sometimes fails http://bugs.python.org/issue10826 closed by pitrou #10830: PyUnicode_FromFormatV("%c") doesn't support non-BMP characters http://bugs.python.org/issue10830 closed by haypo #10867: mmap.flush() issue msync() even if mapping was created with p http://bugs.python.org/issue10867 closed by mmarkk #10868: ABCMeta.register() should work as a decorator http://bugs.python.org/issue10868 closed by eric.araujo #10990: tests mutating sys.gettrace() w/o re-instating previous state http://bugs.python.org/issue10990 closed by brett.cannon #10992: tests failing when run under coverage http://bugs.python.org/issue10992 closed by brett.cannon #11074: fix tokenize so it can be reloaded http://bugs.python.org/issue11074 closed by brett.cannon #11085: expose _abcoll as collections.abc http://bugs.python.org/issue11085 closed by rhettinger #11086: add lib2to3/__main__.py http://bugs.python.org/issue11086 closed by brett.cannon #11089: ConfigParser 50x slower in 2.7 http://bugs.python.org/issue11089 closed by rhettinger #11168: UnicodeEncodeError on recusion limit if the script filename is http://bugs.python.org/issue11168 closed by haypo #11169: compileall doesn't support PEP 383 (undecodable paths/filename http://bugs.python.org/issue11169 closed by haypo #11184: Broken large file support on AIX http://bugs.python.org/issue11184 closed by georg.brandl #11187: PyUnicode_AsEncodedString: the bootstrap hack is no more neede http://bugs.python.org/issue11187 closed by haypo #11222: Python3.2rc3 fails to build on Mac OS X with a non-framework b http://bugs.python.org/issue11222 closed by ned.deily #11224: 3.2: tarfile.getmembers causes 100% cpu usage on Windows http://bugs.python.org/issue11224 closed by lars.gustaebel #11226: subprocesses experience mysterious delay in receiving stdin EO http://bugs.python.org/issue11226 closed by yaaang #11232: asyncore - don't throw a traceback when a client disconnects i http://bugs.python.org/issue11232 closed by giampaolo.rodola #11234: Error in What's new 3.2rc3 with sysconfig.get_config_var('SO') http://bugs.python.org/issue11234 closed by eric.araujo #11238: sets - refer to sets/frozenset in stdtypes http://bugs.python.org/issue11238 closed by eric.araujo #11248: Tails of generator get lost under zip() http://bugs.python.org/issue11248 closed by ezio.melotti #11249: Memory mismanagement with Py_tp_doc http://bugs.python.org/issue11249 closed by georg.brandl #11251: cmd.Cmd tab completion treats dashes as spaces http://bugs.python.org/issue11251 closed by Jon.McKenzie #11252: Handling statement OR assignment continuation '\' on Win32 pla http://bugs.python.org/issue11252 closed by georg.brandl #11262: re.sub replaces only first 32 matches with re.U flag http://bugs.python.org/issue11262 closed by SilentGhost #11263: Wrong link to source code of ftplib http://bugs.python.org/issue11263 closed by rhettinger #11264: Format Specification Mini-Language missing type 'i'? http://bugs.python.org/issue11264 closed by eric.smith #11268: 3.2 Mac OS X installer may fail if documentation was previousl http://bugs.python.org/issue11268 closed by ned.deily #11269: cgi.FieldStorage forgets to unquote field names when parsing m http://bugs.python.org/issue11269 closed by r.david.murray #11272: input() has trailing carriage return on windows http://bugs.python.org/issue11272 closed by haypo #11274: asyncore does not support epoll http://bugs.python.org/issue11274 closed by giampaolo.rodola #11277: test_zlib crashes under Snow Leopard buildbot http://bugs.python.org/issue11277 closed by pitrou #11278: raw_input() and input() not stripping EOL on win32 http://bugs.python.org/issue11278 closed by brian.curtin #11280: urllib2 http_error_302 calls undefined "getheaders" method http://bugs.python.org/issue11280 closed by orsenthil #11285: io.py standart stream setup crash http://bugs.python.org/issue11285 closed by sdaoden #11286: Some "trivial" python 2.x pickles fails to load in Python 3.2 http://bugs.python.org/issue11286 closed by belopolsky #11288: Python installed from MSI doesn't work http://bugs.python.org/issue11288 closed by loewis #11295: On Windows, Python crashes on ANSI / Windows-formatted source http://bugs.python.org/issue11295 closed by JonathanHayward #11296: Possible error in What's new in Python 3.2 : duplication of rs http://bugs.python.org/issue11296 closed by rhettinger #11301: cookielib.LWPCookieJar.save() doesn't save cookies http://bugs.python.org/issue11301 closed by mcencula #11304: Input/output tutorial - PI is rounded not truncated http://bugs.python.org/issue11304 closed by rhettinger #11308: extraneous link getit in the main website sidebar http://bugs.python.org/issue11308 closed by SilentGhost #11317: Documentation not updated to show string exceptions have been http://bugs.python.org/issue11317 closed by georg.brandl From solipsis at pitrou.net Fri Feb 25 18:24:26 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 25 Feb 2011 18:24:26 +0100 Subject: [Python-Dev] Mercurial conversion repositories References: <20110225011904.3ed09de7@pitrou.net> <20110225135258.3cae8851@pitrou.net> Message-ID: <20110225182426.5f087bfa@pitrou.net> On Fri, 25 Feb 2011 13:52:58 +0100 Antoine Pitrou wrote: > On Fri, 25 Feb 2011 19:13:49 +1100 > Neil Hodgson wrote: > > With hg 1.7.5 on Windows 7 I performed a non-core checkout: > > > > hg clone http://hg.python.org/cpython > > > > The eol extension is enabled in global settings. > > Yes, please try to disable it. The issue is we have a .hgeol in the > repository right now (it's in the SVN repository too), but it doesn't > match the reality of on-disk files, so when you update, the eol > extension tries to "fix" those files. It should now be fixed in current SVN, meaning the final conversion should be perfectly usable with the eol extension enabled. Do you find other issues under Windows? Have you tried pushing changes? Regards Antoine. From solipsis at pitrou.net Fri Feb 25 18:32:44 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 25 Feb 2011 18:32:44 +0100 Subject: [Python-Dev] r88580 - in python/branches/py3k: Doc/library/os.rst Doc/whatsnew/3.3.rst Lib/test/test_os.py Misc/NEWS Modules/posixmodule.c configure.in pyconfig.h.in References: <20110225143916.BEC74EE9A6@mail.python.org> Message-ID: <20110225183244.0e321e2e@pitrou.net> On Fri, 25 Feb 2011 15:39:16 +0100 (CET) giampaolo.rodola wrote: > +#else > + *((off_t*)addr) = PyLong_Check(arg) ? PyLong_AsLongLong(arg) > + : PyLong_AsLong(arg); > +#endif There's something fishy here. Why would you call PyLong_AsLong() if PyLong_Check() is false? Regards Antoine. From adrian at cadifra.com Fri Feb 25 18:40:53 2011 From: adrian at cadifra.com (Adrian Buehlmann) Date: Fri, 25 Feb 2011 18:40:53 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110225111253.2f34357e@limelight.wooz.org> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> Message-ID: <4D67E9A5.5030203@cadifra.com> On 2011-02-25 17:12, Barry Warsaw wrote: > On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote: > >> >> On Feb 25, 2011, at 12:09 AM, Martin v. L?wis wrote: >> >>> I think I would have liked the strategy of the PEP better (i.e. >>> create clones for feature branches, rather than putting all >>> in a single repository). >> >> In my brief tests, the single repository has been easy to work with. >> If they were separate, it would complicate backporting patches >> and merges. So, I'm happy with how George and Benjamin put this together. > > The way I work with the Subversion branches is to have all the active branches > checked out into separate directories under a common parent, e.g. > > ~/projects/python/py26 > ~/projects/python/py27 > ~/projects/python/trunk > ~/projects/python/py31 > ~/projects/python/py32 > ~/projects/python/py3k > > This makes it very easy to just cd, svn up, make distclean, configure, make to > test things. How can I do this with the hg clone when all the branches are > in the single repository, but more or less hidden? After doing the 'hg clone' > operation specified by Antoine, I'm left with a single cpython directory > containing (iiuc) the contents of the 'default' branch. > > I'm sure I'm not the only one who works this way with Subversion. IWBN to > cover this in the devguide (or is it there and I missed it?). I know (almost) nothing about developing Python (this is my first post to this list after lurking for quite a while now), but as a regular Mercurial contributor, I think the following could be useful for you: First, get an initial clone (let's name it 'master') over the wire using: [1] $ hg clone -U ssh://hg at hg.python.org/cpython master Then create a hardlinked clone [2] for working in each branch, specifying the branch to check out using option -u: $ hg clone master py26 -u 2.6 updating to branch 2.6 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master py27 -u 2.7 updating to branch 2.7 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master trunk -u trunk updating to branch trunk NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master py31 -u 3.1 updating to branch 3.1 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master py32 -u 3.2 updating to branch 3.2 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved This will be fast and save space as these local 'branch clones' will share diskspace inside .hg/store by using hardlinks, and you need to do the initial slow clone over the wire only once. Note that each of these branch clones will initially have your local master repo as the default path [3,4]. If you'd like to have the default push/pull path to point to ssh://hg at hg.python.org/cpython instead, you'd want to edit the [paths] section in the .hg/hgrc file in each of the branch repos. But of course you can also leave the default paths as they are and synchronize via the master repo (e.g. pull new changesets into master first, and then pull into the specific branch repo). [1] http://selenic.com/repo/hg/help/clone [2] http://mercurial.selenic.com/wiki/HardlinkedClones [3] http://www.selenic.com/mercurial/hgrc.5.html#paths [4] http://selenic.com/repo/hg/help/urls From vinay_sajip at yahoo.co.uk Fri Feb 25 19:10:28 2011 From: vinay_sajip at yahoo.co.uk (Vinay Sajip) Date: Fri, 25 Feb 2011 18:10:28 +0000 (UTC) Subject: [Python-Dev] Finding buildbot failures Message-ID: What's the easiest way of finding which tests failed on buildbot builds? I mean, is there anything easier than using the Web interface to browse to failing builds and then looking at the stdio output in a browser? Thanks, Vinay Sajip From rosslagerwall at gmail.com Fri Feb 25 19:11:20 2011 From: rosslagerwall at gmail.com (Ross Lagerwall) Date: Fri, 25 Feb 2011 20:11:20 +0200 Subject: [Python-Dev] r88580 - in python/branches/py3k: Doc/library/os.rst Doc/whatsnew/3.3.rst Lib/test/test_os.py Misc/NEWS Modules/posixmodule.c configure.in pyconfig.h.in In-Reply-To: <20110225183244.0e321e2e@pitrou.net> References: <20110225143916.BEC74EE9A6@mail.python.org> <20110225183244.0e321e2e@pitrou.net> Message-ID: <1298657480.3678.4.camel@hobo> On Fri, 2011-02-25 at 18:32 +0100, Antoine Pitrou wrote: > On Fri, 25 Feb 2011 15:39:16 +0100 (CET) > giampaolo.rodola wrote: > > > +#else > > + *((off_t*)addr) = PyLong_Check(arg) ? PyLong_AsLongLong(arg) > > + : PyLong_AsLong(arg); > > +#endif > > There's something fishy here. Why would you call PyLong_AsLong() if > PyLong_Check() is false? > I'm not entirely sure how that works (other than it seems to!). The code came from other places where large file support is, such as in ftruncate() and lseek() in the posix module. Ross > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/rosslagerwall%40gmail.com From solipsis at pitrou.net Fri Feb 25 19:35:10 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 25 Feb 2011 19:35:10 +0100 Subject: [Python-Dev] r88580 - in python/branches/py3k: Doc/library/os.rst Doc/whatsnew/3.3.rst Lib/test/test_os.py Misc/NEWS Modules/posixmodule.c configure.in pyconfig.h.in In-Reply-To: <1298657480.3678.4.camel@hobo> References: <20110225143916.BEC74EE9A6@mail.python.org> <20110225183244.0e321e2e@pitrou.net> <1298657480.3678.4.camel@hobo> Message-ID: <1298658910.3739.1.camel@localhost.localdomain> Le vendredi 25 f?vrier 2011 ? 20:11 +0200, Ross Lagerwall a ?crit : > On Fri, 2011-02-25 at 18:32 +0100, Antoine Pitrou wrote: > > On Fri, 25 Feb 2011 15:39:16 +0100 (CET) > > giampaolo.rodola wrote: > > > > > +#else > > > + *((off_t*)addr) = PyLong_Check(arg) ? PyLong_AsLongLong(arg) > > > + : PyLong_AsLong(arg); > > > +#endif > > > > There's something fishy here. Why would you call PyLong_AsLong() if > > PyLong_Check() is false? > > > > I'm not entirely sure how that works (other than it seems to!). > The code came from other places where large file support is, such as in > ftruncate() and lseek() in the posix module. Ok, then I guess that code was ported straightly from 2.x without really a thought. Thanks for your contribution, by the way! Regards Antoine. From solipsis at pitrou.net Fri Feb 25 19:36:07 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 25 Feb 2011 19:36:07 +0100 Subject: [Python-Dev] Finding buildbot failures References: Message-ID: <20110225193607.73117b01@pitrou.net> On Fri, 25 Feb 2011 18:10:28 +0000 (UTC) Vinay Sajip wrote: > What's the easiest way of finding which tests failed on buildbot builds? I mean, > is there anything easier than using the Web interface to browse to failing > builds and then looking at the stdio output in a browser? Not really, but that becomes quite easy once you're used to it. Good luck :) Regards Antoine. From fuzzyman at voidspace.org.uk Fri Feb 25 19:47:53 2011 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 25 Feb 2011 18:47:53 +0000 Subject: [Python-Dev] Finding buildbot failures In-Reply-To: References: Message-ID: <4D67F959.8080701@voidspace.org.uk> On 25/02/2011 18:10, Vinay Sajip wrote: > What's the easiest way of finding which tests failed on buildbot builds? I mean, > is there anything easier than using the Web interface to browse to failing > builds and then looking at the stdio output in a browser? That's one of the big advantages that Jenkins (nee Hudson) has over buildbot - drilling down into individual test failures through the web ui. Your test run needs to generate appropriate xml for that to work though. Michael > Thanks, > > Vinay Sajip > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From g.brandl at gmx.net Fri Feb 25 19:49:48 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Fri, 25 Feb 2011 19:49:48 +0100 Subject: [Python-Dev] Finding buildbot failures In-Reply-To: References: Message-ID: On 25.02.2011 19:10, Vinay Sajip wrote: > What's the easiest way of finding which tests failed on buildbot builds? I mean, > is there anything easier than using the Web interface to browse to failing > builds and then looking at the stdio output in a browser? Once every failure sent a mail to python-checkins; I had modified the email reporting to include as much info about the failed test as possible. However, there were so many of these emails that we discontinued sending them. Georg From exarkun at twistedmatrix.com Fri Feb 25 20:00:14 2011 From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com) Date: Fri, 25 Feb 2011 19:00:14 -0000 Subject: [Python-Dev] Finding buildbot failures In-Reply-To: <4D67F959.8080701@voidspace.org.uk> References: <4D67F959.8080701@voidspace.org.uk> Message-ID: <20110225190014.2231.1678753723.divmod.xquotient.58@localhost.localdomain> On 06:47 pm, fuzzyman at voidspace.org.uk wrote: >On 25/02/2011 18:10, Vinay Sajip wrote: >>What's the easiest way of finding which tests failed on buildbot >>builds? I mean, >>is there anything easier than using the Web interface to browse to >>failing >>builds and then looking at the stdio output in a browser? > >That's one of the big advantages that Jenkins (nee Hudson) has over >buildbot - drilling down into individual test failures through the web >ui. Your test run needs to generate appropriate xml for that to work >though. Buildbot can do this too. It can even do it without xml, although it does need *some* parseable format, which I think the Python test suite is a long way from. Jean-Paul From benjamin at python.org Fri Feb 25 20:39:27 2011 From: benjamin at python.org (Benjamin Peterson) Date: Fri, 25 Feb 2011 13:39:27 -0600 Subject: [Python-Dev] [Python-checkins] cpython (2.7): Update copyright years. In-Reply-To: References: Message-ID: 2011/2/25 barry.warsaw : > barry.warsaw pushed 9619d21d8198 to cpython: > > http://hg.python.org/cpython/rev/9619d21d8198 > changeset: ? 68030:9619d21d8198 > branch: ? ? ?2.7 > tag: ? ? ? ? tip > parent: ? ? ?68010:8174d00d0797 > user: ? ? ? ?Barry Warsaw > date: ? ? ? ?Fri Feb 25 14:35:22 2011 -0500 > summary: > ?Update copyright years. > > files: > ?Python/Python-ast.c > ?README > > diff --git a/Python/Python-ast.c b/Python/Python-ast.c > --- a/Python/Python-ast.c > +++ b/Python/Python-ast.c > @@ -2,7 +2,7 @@ > > > ?/* > - ? __version__ 82160. > + ? __version__ . Ah, this reminds me. Figuring out what to do with the AST version should probably be a hg roadmap topic. -- Regards, Benjamin From barry at python.org Fri Feb 25 20:43:15 2011 From: barry at python.org (Barry Warsaw) Date: Fri, 25 Feb 2011 14:43:15 -0500 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <4D67E9A5.5030203@cadifra.com> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> Message-ID: <20110225144315.3eebcafc@limelight.wooz.org> On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: >First, get an initial clone (let's name it 'master') over the wire >using: [1] > > $ hg clone -U ssh://hg at hg.python.org/cpython master > >Then create a hardlinked clone [2] for working in each branch, >specifying the branch to check out using option -u: > > $ hg clone master py26 -u 2.6 > updating to branch 2.6 > NNN files updated, 0 files merged, 0 files removed, 0 files unresolved > > $ hg clone master py27 -u 2.7 > updating to branch 2.7 > NNN files updated, 0 files merged, 0 files removed, 0 files unresolved > > $ hg clone master trunk -u trunk > updating to branch trunk > NNN files updated, 0 files merged, 0 files removed, 0 files unresolved > > $ hg clone master py31 -u 3.1 > updating to branch 3.1 > NNN files updated, 0 files merged, 0 files removed, 0 files unresolved > > $ hg clone master py32 -u 3.2 > updating to branch 3.2 > NNN files updated, 0 files merged, 0 files removed, 0 files unresolved > >Note that each of these branch clones will initially have your local >master repo as the default path [3,4]. If you'd like to have the default >push/pull path to point to ssh://hg at hg.python.org/cpython instead, you'd >want to edit the [paths] section in the .hg/hgrc file in each of the >branch repos. Thanks very much Adrian, this is exactly what I was looking for. It maps almost directly to my current mental model for working on Python in Subversion (and truth be told, also how I do/did it with Bazaar). It does leave me with an empty 'master' directory that I basically won't touch, though I suppose I could hide it in a dot-filename. And I have to remember to fiddle with .hg/hgrc when I clone a new branch working directory, but I guess that's mostly a one-time cost. I'll have to remember that 'hg pull' does not update the working copy by default, and eventually I'll figure out the whole merge thing. One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes my editor and always shows me a 'diff -u' in the commit message buffer. This is incredibly handy because I don't have to remember to do the diff in a different window, and I always have all the information I want right there to craft the commit message. It doesn't look like this is possible with 'hg commit' though, right? Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Fri Feb 25 20:45:18 2011 From: barry at python.org (Barry Warsaw) Date: Fri, 25 Feb 2011 14:45:18 -0500 Subject: [Python-Dev] [Python-checkins] cpython (2.7): Update copyright years. In-Reply-To: References: Message-ID: <20110225144518.1ae921c1@limelight.wooz.org> On Feb 25, 2011, at 01:39 PM, Benjamin Peterson wrote: >Ah, this reminds me. Figuring out what to do with the AST version >should probably be a hg roadmap topic. Is there a bug tracker for the conversion? -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From g.brandl at gmx.net Fri Feb 25 20:53:10 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Fri, 25 Feb 2011 20:53:10 +0100 Subject: [Python-Dev] [Python-checkins] cpython (2.7): Update copyright years. In-Reply-To: <20110225144518.1ae921c1@limelight.wooz.org> References: <20110225144518.1ae921c1@limelight.wooz.org> Message-ID: On 25.02.2011 20:45, Barry Warsaw wrote: > On Feb 25, 2011, at 01:39 PM, Benjamin Peterson wrote: > >>Ah, this reminds me. Figuring out what to do with the AST version >>should probably be a hg roadmap topic. > > Is there a bug tracker for the conversion? There's todo.txt in the pymigr repo. Georg From solipsis at pitrou.net Fri Feb 25 20:57:53 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 25 Feb 2011 20:57:53 +0100 Subject: [Python-Dev] Mercurial conversion repositories References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> Message-ID: <20110225205753.3d011f68@pitrou.net> On Fri, 25 Feb 2011 14:43:15 -0500 Barry Warsaw wrote: > > I'll have to remember that 'hg pull' does not update the working copy by > default, and eventually I'll figure out the whole merge thing. You can use "hg pull -u" to update (and "hg pull -uv" if you want to see the list of updated files). > One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes > my editor and always shows me a 'diff -u' in the commit message buffer. This > is incredibly handy because I don't have to remember to do the diff in a > different window, and I always have all the information I want right there to > craft the commit message. It doesn't look like this is possible with 'hg > commit' though, right? Should be customizable: http://mercurial.selenic.com/wiki/CommitMessageTemplate http://mercurial.selenic.com/wiki/DiffsInCommitMessageInVIM (never tried myself) Regards Antoine. From phil at freehackers.org Fri Feb 25 21:04:12 2011 From: phil at freehackers.org (Philippe Fremy) Date: Fri, 25 Feb 2011 21:04:12 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110225144315.3eebcafc@limelight.wooz.org> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> Message-ID: <4D680B3C.4040209@freehackers.org> On 25/02/2011 20:43, Barry Warsaw wrote: > > One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes > my editor and always shows me a 'diff -u' in the commit message buffer. This > is incredibly handy because I don't have to remember to do the diff in a > different window, and I always have all the information I want right there to > craft the commit message. It doesn't look like this is possible with 'hg > commit' though, right? What you are asking for is available in TortoiseHg which absolutely rocks (if you are not allergic to the idea of a graphical tool). You can even select indvidually inside a file which lines to commit or not. A bit risky but very handy when you have a few oneliners to commit or not to commit. cheers, Philippe From nyamatongwe at gmail.com Fri Feb 25 22:40:14 2011 From: nyamatongwe at gmail.com (Neil Hodgson) Date: Sat, 26 Feb 2011 08:40:14 +1100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110225182426.5f087bfa@pitrou.net> References: <20110225011904.3ed09de7@pitrou.net> <20110225135258.3cae8851@pitrou.net> <20110225182426.5f087bfa@pitrou.net> Message-ID: Antoine Pitrou: > It should now be fixed in current SVN, meaning the final conversion > should be perfectly usable with the eol extension enabled. Good. > Do you find other issues under Windows? Have you tried pushing changes? Since I'm not a member of core developers I used a http pull and can't push: C:\u\cpython>hg push pushing to http://hg.python.org/cpython searching for changes remote: ssl required Neil From solipsis at pitrou.net Fri Feb 25 22:43:17 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 25 Feb 2011 22:43:17 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> <20110225135258.3cae8851@pitrou.net> <20110225182426.5f087bfa@pitrou.net> Message-ID: <1298670197.3739.7.camel@localhost.localdomain> Le samedi 26 f?vrier 2011 ? 08:40 +1100, Neil Hodgson a ?crit : > Antoine Pitrou: > > > It should now be fixed in current SVN, meaning the final conversion > > should be perfectly usable with the eol extension enabled. > > Good. > > > Do you find other issues under Windows? Have you tried pushing changes? > > Since I'm not a member of core developers I used a http pull and can't push: Ok, well that's expected then ;) Sorry for the confusion. Regards Antoine. From barry at python.org Fri Feb 25 22:46:00 2011 From: barry at python.org (Barry Warsaw) Date: Fri, 25 Feb 2011 16:46:00 -0500 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <4D680B3C.4040209@freehackers.org> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D680B3C.4040209@freehackers.org> Message-ID: <20110225164600.415f8e04@limelight.wooz.org> On Feb 25, 2011, at 09:04 PM, Philippe Fremy wrote: >What you are asking for is available in TortoiseHg which absolutely >rocks (if you are not allergic to the idea of a graphical tool). Like shellfish, bee-strings, and Perl I'm afraid. :) >You can even select indvidually inside a file which lines to commit or >not. A bit risky but very handy when you have a few oneliners to commit >or not to commit. You mean, TortoiseHg supports incremental commits on a single file? That's kind of neat, but scary. ;) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From solipsis at pitrou.net Fri Feb 25 23:24:56 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 25 Feb 2011 23:24:56 +0100 Subject: [Python-Dev] r88589 - python/branches/py3k/Lib/test/test_logging.py References: <20110225170243.CC07AEE9BD@mail.python.org> Message-ID: <20110225232456.0be6176a@pitrou.net> On Fri, 25 Feb 2011 18:02:43 +0100 (CET) vinay.sajip wrote: > Author: vinay.sajip > Date: Fri Feb 25 18:02:43 2011 > New Revision: 88589 > > Log: > logging: enabled test which was intermittently failing on buildbots. Looks like it fails again: ( http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2671/steps/test/logs/stdio ) ====================================================================== ERROR: test_compute_rollover_MIDNIGHT (test.test_logging.TimedRotatingFileHandlerTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 1990, in tearDown os.unlink(self.fn) WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'c:\\users\\db3l\\appdata\\local\\temp\\test_logging-2-vhc3k5.log' ====================================================================== FAIL: test_compute_rollover_MIDNIGHT (test.test_logging.TimedRotatingFileHandlerTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 2053, in test_compute_rollover self.assertEqual(exp, rh.computeRollover(0.0)) AssertionError: 82800 != 18000.0 ====================================================================== FAIL: test_compute_rollover_S (test.test_logging.TimedRotatingFileHandlerTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 1981, in setUp BaseTest.setUp(self) File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 95, in setUp raise AssertionError('Unexpected handlers: %s' % hlist) AssertionError: Unexpected handlers: [] ====================================================================== FAIL: test_compute_rollover_W0 (test.test_logging.TimedRotatingFileHandlerTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 1981, in setUp BaseTest.setUp(self) File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", line 95, in setUp raise AssertionError('Unexpected handlers: %s' % hlist) AssertionError: Unexpected handlers: [] From guido at python.org Fri Feb 25 23:43:01 2011 From: guido at python.org (Guido van Rossum) Date: Fri, 25 Feb 2011 14:43:01 -0800 Subject: [Python-Dev] Let's get PEP 380 into Python 3.3 Message-ID: Now that the language moratorium is lifted, let's make sure to get PEP 380 implemented for Python 3.3. I think there are some minor issues to be resolved, but I don't think that should stop someone from doing a first pass of the implementation (especially since a version for 2.6 already exists). (OTOH I am not much enamored with cofunctions, PEP 3152.) -- --Guido van Rossum (python.org/~guido) From greg.ewing at canterbury.ac.nz Sat Feb 26 00:01:12 2011 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sat, 26 Feb 2011 12:01:12 +1300 Subject: [Python-Dev] Let's get PEP 380 into Python 3.3 References: Message-ID: From: Guido van Rossum > (OTOH I am not much enamored with cofunctions, PEP 3152.) That's okay, I don't like it much myself in its current form. I plan to revisit it at some point, but there's no hurry. -- Greg This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. From cs at zip.com.au Sat Feb 26 01:04:59 2011 From: cs at zip.com.au (Cameron Simpson) Date: Sat, 26 Feb 2011 11:04:59 +1100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110225144315.3eebcafc@limelight.wooz.org> References: <20110225144315.3eebcafc@limelight.wooz.org> Message-ID: <20110226000459.GA27783@cskk.homeip.net> On 25Feb2011 14:43, Barry Warsaw wrote: | [...] And I have to | remember to fiddle with .hg/hgrc when I clone a new branch working directory, | but I guess that's mostly a one-time cost. Hmm. Why do you need to fiddle with the hgrc? Just curious. | I'll have to remember that 'hg pull' does not update the working copy by | default, and eventually I'll figure out the whole merge thing. "hg fetch" does though. That's my usual incanation. | One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes | my editor and always shows me a 'diff -u' in the commit message buffer. This | is incredibly handy because I don't have to remember to do the diff in a | different window, and I always have all the information I want right there to | craft the commit message. It doesn't look like this is possible with 'hg | commit' though, right? CVS had that problem. I had a wrapper somewhere that masquerades as $EDITOR and writes a diff into the commit buffer as you describe. [ Digs through my hg repository... ] Ok; then it took the form of a script called "cvscommit" that set $EDITOR to the command "cvscommit-editor", wrote the diff stuff, invoked "cvs commit". That ran "cvscommit-editor", which invoked the old $EDITOR and off you went. I would think editing the hgrc to set the hg editor and using the commit hooks would streamline this for Mercurial so you could do the usual "hg commit" command without going through the outer wrapper. I'll devote a little time today, since I've missed this little hack:-( Interested? Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ We don't just *borrow* words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary. - James D. Nicoli From guido at python.org Sat Feb 26 01:23:09 2011 From: guido at python.org (Guido van Rossum) Date: Fri, 25 Feb 2011 16:23:09 -0800 Subject: [Python-Dev] Let's get PEP 380 into Python 3.3 In-Reply-To: References: Message-ID: Ok. Will you hvae time to port your patches to 3.3? On Fri, Feb 25, 2011 at 3:01 PM, Greg Ewing wrote: > From: Guido van Rossum > >> (OTOH I am not much enamored with cofunctions, PEP 3152.) > > That's okay, I don't like it much myself in its current form. > I plan to revisit it at some point, but there's no hurry. > > -- > Greg > > This email may be confidential and subject to legal privilege, it may > not reflect the views of the University of Canterbury, and it is not > guaranteed to be virus free. If you are not an intended recipient, > please notify the sender immediately and erase all copies of the message > and any attachments. > > Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more > information. > -- --Guido van Rossum (python.org/~guido) From jnoller at gmail.com Sat Feb 26 01:47:21 2011 From: jnoller at gmail.com (Jesse Noller) Date: Fri, 25 Feb 2011 19:47:21 -0500 Subject: [Python-Dev] Let's get PEP 380 into Python 3.3 In-Reply-To: References: Message-ID: On Fri, Feb 25, 2011 at 5:43 PM, Guido van Rossum wrote: > Now that the language moratorium is lifted, let's make sure to get PEP > 380 implemented for Python 3.3. I think there are some minor issues to > be resolved, but I don't think that should stop someone from doing a > first pass of the implementation (especially since a version for 2.6 > already exists). > > (OTOH I am not much enamored with cofunctions, PEP 3152.) > Yay! From jsbueno at python.org.br Sat Feb 26 01:58:40 2011 From: jsbueno at python.org.br (Joao S. O. Bueno) Date: Fri, 25 Feb 2011 21:58:40 -0300 Subject: [Python-Dev] Let's get PEP 380 into Python 3.3 In-Reply-To: References: Message-ID: On Fri, Feb 25, 2011 at 8:01 PM, Greg Ewing wrote: > From: Guido van Rossum > >> (OTOH I am not much enamored with cofunctions, PEP 3152.) > > That's okay, I don't like it much myself in its current form. > I plan to revisit it at some point, but there's no hurry. I've just gone through PEP 3152 - and the first though that occurred me is that a decorator is perfectly usable instead of the new proposed keyword "codef". (It would need to be able to set special attributes in the function to indicate its nature) Besides not adding a new keyword, it would allow for different (concurrently running? ) types of co-functions to be created and benefit from the other mechanisms. But maybe considerations about this should be take place on python-ideas only? > -- > Greg > From merwok at netwok.org Sat Feb 26 01:49:46 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sat, 26 Feb 2011 01:49:46 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110225144315.3eebcafc@limelight.wooz.org> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> Message-ID: <4D684E2A.90005@netwok.org> Hi, Le 25/02/2011 20:43, Barry Warsaw a ?crit : > On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: > [snip] >> Note that each of these branch clones will initially have your local >> master repo as the default path [3,4]. If you'd like to have the default >> push/pull path to point to ssh://hg at hg.python.org/cpython instead, you'd >> want to edit the [paths] section in the .hg/hgrc file in each of the >> branch repos. I plan on having one clone per branch but pushing and pulling from only one repository, so I don?t need to edit hgrcs. > It does leave me with an empty 'master' directory that I basically won't > touch, though I suppose I could hide it in a dot-filename. Or have the master clone do double duty as the py3k clone. (IOW, I have 2.7 3.1 3.2 py3k, I pull/push in py3k and also do merges and new features in py3k). > And I have to remember to fiddle with .hg/hgrc when I clone a new branch > working directory, but I guess that's mostly a one-time cost. You don?t, see above. I?ve wanted to tell you something for a long time: Mercurial branches are not at all like Bazaar branches. See http://mercurial.selenic.com/wiki/Branch and http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ Anecdote: I migrated from Subversion to Mercurial a few years ago, and found Mercurial branches very intuitive. When I saw mentions of Bazaar branches I was driven nuts by (what I saw as) the conflation between a branch and a clone. Later I understood how it made sense from the perspective of Bazaar, so I shifted my judgment from ?insanely confusing? to ?a particular choice that I don?t approve? . What I?m saying is that a lot of Bazaar terminology using ?branch? does not map as-is to Mercurial. We clone a repo, we pull from a repo/clone, we have named branches (e.g. 3.2) in a repo, we have unnamed branches on one named branch. I think you know that already, since you went from using Bazaar terms applied to Mercurial to mixing terms from both (?clone a new branch working directory? ? ?clone a repo?, probably). I salute your willingness to learn Mercurial, considering how fluent (and fluffly) you appear to be with Bazaar. > I'll have to remember that 'hg pull' does not update the working copy by > default, That pull does not update is a feature: The operation between a remote repo and the local repo (the .hg directory) is separate from the operation from the local repo to the working directory. When you know that you want pull + update (like when you have a clean working directory), you use ?hg pull -u?. (I don?t like the fetch command.) > and eventually I'll figure out the whole merge thing. Without anything specific, I?ll point to some resources: Short tuto: http://hginit.com/04.html Concepts and examples: http://mercurial.selenic.com/wiki/Merge Longer narratives: http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html > One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes > my editor and always shows me a 'diff -u' in the commit message buffer. This > is incredibly handy because I don't have to remember to do the diff in a > different window, and I always have all the information I want right there to > craft the commit message. You speak to my heart, sir. In your ~/.hgrc, under the section [ui], set ?editor = path/to/mercurial/source/hgeditor? and enjoy your diffs. I use it and love it. If you want to commit a subset of your local changes, I use http://mercurial.selenic.com/wiki/CrecordExtension , a curses-based diff selection UI that works like a charm. Kind regards, your friendly Mercurial whippersnapper From martin at v.loewis.de Sat Feb 26 03:01:52 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Sat, 26 Feb 2011 03:01:52 +0100 Subject: [Python-Dev] [Python-checkins] pymigr: Update todo In-Reply-To: References: Message-ID: <4D685F10.3090803@v.loewis.de> > After migration > =============== > > +* set up automatic installation of changes to ssh keys, decide upon > + account managers I would like account managers to be decided before the conversion. I personally won't be available as an account manager anymore. The new account managers are then, of course, free to establish any workflow they deem appropriate. > +* adapt build identification for Windows build process I think this should also be done before the migration. Regards, Martin From ezio.melotti at gmail.com Sat Feb 26 03:08:02 2011 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Sat, 26 Feb 2011 04:08:02 +0200 Subject: [Python-Dev] Finding buildbot failures In-Reply-To: References: Message-ID: <4D686082.8010202@gmail.com> On 25/02/2011 20.10, Vinay Sajip wrote: > What's the easiest way of finding which tests failed on buildbot builds? I mean, > is there anything easier than using the Web interface to browse to failing > builds and then looking at the stdio output in a browser? > You can try bbreport (http://code.google.com/p/bbreport/wiki/Screenshots): hg clone https://bbreport.googlecode.com/hg/ bbreport cd bbreport python bbreport --help python bbreport 3.x (There is some issue with hg revision numbers that I haven't fixed yet, but the above command should work fine) Best Regards, Ezio Melotti > Thanks, > > Vinay Sajip > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ezio.melotti%40gmail.com > From ncoghlan at gmail.com Sat Feb 26 03:32:04 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 26 Feb 2011 12:32:04 +1000 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110225011904.3ed09de7@pitrou.net> References: <20110225011904.3ed09de7@pitrou.net> Message-ID: On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou wrote: > ? ?$ hg branches > ? ?default ? ? ? ? ? ? ? ? ? ?68026:f12ef116dd10 > ? ?3.2 ? ? ? ? ? ? ? ? ? ? ? ?68025:cef92ee1a323 > ? ?2.7 ? ? ? ? ? ? ? ? ? ? ? ?68010:8174d00d0797 > ? ?3.1 ? ? ? ? ? ? ? ? ? ? ? ?67955:5be8b695ea86 > ? ?2.6 ? ? ? ? ? ? ? ? ? ? ? ?67287:5e26a860eded > ? ?2.5 ? ? ? ? ? ? ? ? ? ? ? ?65464:e4ecac76e499 > ? ?trunk ? ? ? ? ? ? ? ? ? ? ?62750:800f6c92c3ed > ? ?3.0 ? ? ? ? ? ? ? ? ? ? ? ?60075:1d05144224fe > ? ?2.4 ? ? ? ? ? ? ? ? ? ? ? ?58552:df72cac1899e > ? ?2.3 ? ? ? ? ? ? ? ? ? ? ? ?45731:a3d9a9730743 > ? ?2.2 ? ? ? ? ? ? ? ? ? ? ? ?40444:d55ddc8c8501 > ? ?2.1 ? ? ? ? ? ? ? ? ? ? ? ?30171:06fcccf6eca8 > ? ?2.0 ? ? ? ? ? ? ? ? ? ? ? ?18214:dc0dfc9565cd > > The branch "default" is the current py3k branch from SVN. The branch > "trunk" represents SVN trunk history until 2.7 was branched for > maintenance. Would it be possible to name "trunk" as "2.x" instead? Otherwise I could see people getting confused and asking why trunk was closed, and/or not the same as "default". Looking very nice, though! :) Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From solipsis at pitrou.net Sat Feb 26 06:36:17 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 26 Feb 2011 06:36:17 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> Message-ID: <20110226063617.3ad5cc6c@pitrou.net> On Sat, 26 Feb 2011 12:32:04 +1000 Nick Coghlan wrote: > On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou wrote: > > ? ?$ hg branches > > ? ?default ? ? ? ? ? ? ? ? ? ?68026:f12ef116dd10 > > ? ?3.2 ? ? ? ? ? ? ? ? ? ? ? ?68025:cef92ee1a323 > > ? ?2.7 ? ? ? ? ? ? ? ? ? ? ? ?68010:8174d00d0797 > > ? ?3.1 ? ? ? ? ? ? ? ? ? ? ? ?67955:5be8b695ea86 > > ? ?2.6 ? ? ? ? ? ? ? ? ? ? ? ?67287:5e26a860eded > > ? ?2.5 ? ? ? ? ? ? ? ? ? ? ? ?65464:e4ecac76e499 > > ? ?trunk ? ? ? ? ? ? ? ? ? ? ?62750:800f6c92c3ed > > ? ?3.0 ? ? ? ? ? ? ? ? ? ? ? ?60075:1d05144224fe > > ? ?2.4 ? ? ? ? ? ? ? ? ? ? ? ?58552:df72cac1899e > > ? ?2.3 ? ? ? ? ? ? ? ? ? ? ? ?45731:a3d9a9730743 > > ? ?2.2 ? ? ? ? ? ? ? ? ? ? ? ?40444:d55ddc8c8501 > > ? ?2.1 ? ? ? ? ? ? ? ? ? ? ? ?30171:06fcccf6eca8 > > ? ?2.0 ? ? ? ? ? ? ? ? ? ? ? ?18214:dc0dfc9565cd > > > > The branch "default" is the current py3k branch from SVN. The branch > > "trunk" represents SVN trunk history until 2.7 was branched for > > maintenance. > > Would it be possible to name "trunk" as "2.x" instead? Otherwise I > could see people getting confused and asking why trunk was closed, > and/or not the same as "default". That was my first idea, but then I realized that the branch includes 1.x and even pre-1.0 commits, so "2.x" might actually be more confusing/misleading and hide the fact that the full trunk history is there. I think people should simply get used to the idea that "default" is /the/ main branch in Mercurial (*). It's even easier to remember IMHO ("trunk" sounds a bit obscure at first, for a non-native English speaker). (*) but it's not any special really, it's just the branch you get by... default ;) Regards Antoine. From g.brandl at gmx.net Sat Feb 26 07:34:12 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Sat, 26 Feb 2011 07:34:12 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> Message-ID: On 26.02.2011 03:32, Nick Coghlan wrote: > On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou wrote: >> $ hg branches >> default 68026:f12ef116dd10 >> 3.2 68025:cef92ee1a323 >> 2.7 68010:8174d00d0797 >> 3.1 67955:5be8b695ea86 >> 2.6 67287:5e26a860eded >> 2.5 65464:e4ecac76e499 >> trunk 62750:800f6c92c3ed >> 3.0 60075:1d05144224fe >> 2.4 58552:df72cac1899e >> 2.3 45731:a3d9a9730743 >> 2.2 40444:d55ddc8c8501 >> 2.1 30171:06fcccf6eca8 >> 2.0 18214:dc0dfc9565cd >> >> The branch "default" is the current py3k branch from SVN. The branch >> "trunk" represents SVN trunk history until 2.7 was branched for >> maintenance. > > Would it be possible to name "trunk" as "2.x" instead? Otherwise I > could see people getting confused and asking why trunk was closed, > and/or not the same as "default". Problem is, you then have 1.5.2 released from the 2.x branch :) Georg From hagen at zhuliguan.net Sat Feb 26 10:09:33 2011 From: hagen at zhuliguan.net (=?UTF-8?B?SGFnZW4gRsO8cnN0ZW5hdQ==?=) Date: Sat, 26 Feb 2011 10:09:33 +0100 Subject: [Python-Dev] set iteration order Message-ID: Hi, I just hunted down a change in behaviour between Python 3.1 and 3.2 to possibly changed iteration order of sets due to the optimization in issue #8685. Of course, this order shouldn't be relied on in the first place, but the side effect of the optimization might be worth mentioning in "What's new", maybe also pointing out that the old behaviour can be simulated with {x for x in a if x not in b} in place of "a-b". Cheers, Hagen From martin at v.loewis.de Sat Feb 26 10:29:33 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 26 Feb 2011 10:29:33 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110226063617.3ad5cc6c@pitrou.net> References: <20110225011904.3ed09de7@pitrou.net> <20110226063617.3ad5cc6c@pitrou.net> Message-ID: <4D68C7FD.6020005@v.loewis.de> > I think people should simply get used to the idea that "default" is > /the/ main branch in Mercurial (*). It's even easier to remember IMHO > ("trunk" sounds a bit obscure at first, for a non-native English > speaker). +1. People will recognize "trunk" as a svn think. If that doesn't clue them in, they will ask, and every other person will know. Regards, Martin From eric at trueblade.com Sat Feb 26 10:28:58 2011 From: eric at trueblade.com (Eric Smith) Date: Sat, 26 Feb 2011 04:28:58 -0500 Subject: [Python-Dev] PyEval_InitThreads() no longer safe before Py_Initialize() in 3.2 In-Reply-To: References: Message-ID: <4D68C7DA.30409@trueblade.com> Can you open an issue in the bug tracker? Thanks. On 2/25/2011 3:48 AM, Juraj Ivan?i? wrote: > It seems that PyEval_InitThreads() can no longer be called before > Py_Initialize(). I get a fatal error in PyThreadState_GET(). > This contradicts the documentation > > http://docs.python.org/release/3.2/c-api/init.html#PyEval_InitThreads > > Minimal repro: > > #include "Python.h" > int main() > { > PyEval_InitThreads(); > return 0; > } > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com > > From martin at v.loewis.de Sat Feb 26 10:52:02 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Sat, 26 Feb 2011 10:52:02 +0100 Subject: [Python-Dev] [Python-checkins] cpython (trunk): Close the "trunk" branch. In-Reply-To: References: Message-ID: <4D68CD42.5050005@v.loewis.de> > http://hg.python.org/cpython/rev/41071f447b15 > changeset: 68041:41071f447b15 > branch: trunk > tag: tip > parent: 62750:800f6c92c3ed > user: Georg Brandl > date: Sat Feb 26 07:48:21 2011 +0100 > summary: > Close the "trunk" branch. What's the effect of "closing" a branch in Mercurial? I can still commit to it, hg branches still shows it (but shows 3.2 as "inactive"???). How can I find out that the branch is closed? Regards, Martin From juraj.ivancic at gmail.com Sat Feb 26 10:53:00 2011 From: juraj.ivancic at gmail.com (=?ISO-8859-2?Q?Juraj_Ivan=E8i=E6?=) Date: Sat, 26 Feb 2011 10:53:00 +0100 Subject: [Python-Dev] PyEval_InitThreads() no longer safe before Py_Initialize() in 3.2 In-Reply-To: <4D68C7DA.30409@trueblade.com> References: <4D68C7DA.30409@trueblade.com> Message-ID: On 26.2.2011 10:28, Eric Smith wrote: > On 2/25/2011 3:48 AM, Juraj Ivan?i? wrote: >> It seems that PyEval_InitThreads() can no longer be called before >> Py_Initialize(). I get a fatal error in PyThreadState_GET(). >> This contradicts the documentation >> >> http://docs.python.org/release/3.2/c-api/init.html#PyEval_InitThreads >> >> Minimal repro: >> >> #include "Python.h" >> int main() >> { >> PyEval_InitThreads(); >> return 0; >> } > > Can you open an issue in the bug tracker? http://bugs.python.org/issue11329 From vinay_sajip at yahoo.co.uk Sat Feb 26 10:54:19 2011 From: vinay_sajip at yahoo.co.uk (Vinay Sajip) Date: Sat, 26 Feb 2011 09:54:19 +0000 (UTC) Subject: [Python-Dev] Finding buildbot failures References: <4D686082.8010202@gmail.com> Message-ID: Ezio Melotti gmail.com> writes: > You can try bbreport (http://code.google.com/p/bbreport/wiki/Screenshots): > > hg clone https://bbreport.googlecode.com/hg/ bbreport > cd bbreport > python bbreport --help > python bbreport 3.x > > (There is some issue with hg revision numbers that I haven't fixed yet, > but the above command should work fine) Thanks, Ezio, that's really handy! Just what I needed. Example output (for those who haven't used the tool) is at https://gist.github.com/845082 Regards, Vinay Sajip From cool-rr at cool-rr.com Sat Feb 26 13:52:34 2011 From: cool-rr at cool-rr.com (cool-RR) Date: Sat, 26 Feb 2011 14:52:34 +0200 Subject: [Python-Dev] Why does TemporaryDirectory not wait for `__enter__`? Message-ID: Hello, I noticed that the `TemporaryDirectory` context manager creates the folder on `__init__` rather than on `__enter__`, resulting in complexity, bugs, and hackarounds in `__del__`. I assume there's a good reason for this decision. What is it? Thanks, Ram. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Sat Feb 26 14:16:33 2011 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 26 Feb 2011 13:16:33 +0000 Subject: [Python-Dev] Finding buildbot failures In-Reply-To: <20110225190014.2231.1678753723.divmod.xquotient.58@localhost.localdomain> References: <4D67F959.8080701@voidspace.org.uk> <20110225190014.2231.1678753723.divmod.xquotient.58@localhost.localdomain> Message-ID: <4D68FD31.70901@voidspace.org.uk> On 25/02/2011 19:00, exarkun at twistedmatrix.com wrote: > On 06:47 pm, fuzzyman at voidspace.org.uk wrote: >> On 25/02/2011 18:10, Vinay Sajip wrote: >>> What's the easiest way of finding which tests failed on buildbot >>> builds? I mean, >>> is there anything easier than using the Web interface to browse to >>> failing >>> builds and then looking at the stdio output in a browser? >> >> That's one of the big advantages that Jenkins (nee Hudson) has over >> buildbot - drilling down into individual test failures through the >> web ui. Your test run needs to generate appropriate xml for that to >> work though. > > Buildbot can do this too. It can even do it without xml, although it > does need *some* parseable format, which I think the Python test suite > is a long way from. > That would be a great improvement to the Python buildbot infrastructure. (Probably a bit small for a GSOC project on its own.) I've had great success using pyjunitxml to generate Hudson compatible reports from unittest test runs (extremely easy to use), and if buildbot *can* handle junit xml format reports then it may be the path of least resistance: https://launchpad.net/pyjunitxml I tried searching (both google and the buildbot docs) for ways to generate more complete reports or to integrate junitxml with builbot, but failed. Can you point me at anything? All the best, Michael > Jean-Paul > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From exarkun at twistedmatrix.com Sat Feb 26 14:46:13 2011 From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com) Date: Sat, 26 Feb 2011 13:46:13 -0000 Subject: [Python-Dev] Finding buildbot failures In-Reply-To: <4D68FD31.70901@voidspace.org.uk> References: <4D67F959.8080701@voidspace.org.uk> <20110225190014.2231.1678753723.divmod.xquotient.58@localhost.localdomain> <4D68FD31.70901@voidspace.org.uk> Message-ID: <20110226134613.2231.442001115.divmod.xquotient.66@localhost.localdomain> On 01:16 pm, fuzzyman at voidspace.org.uk wrote: >On 25/02/2011 19:00, exarkun at twistedmatrix.com wrote: >>On 06:47 pm, fuzzyman at voidspace.org.uk wrote: >>>On 25/02/2011 18:10, Vinay Sajip wrote: >>>>What's the easiest way of finding which tests failed on buildbot >>>>builds? I mean, >>>>is there anything easier than using the Web interface to browse to >>>>failing >>>>builds and then looking at the stdio output in a browser? >>> >>>That's one of the big advantages that Jenkins (nee Hudson) has over >>>buildbot - drilling down into individual test failures through the >>>web ui. Your test run needs to generate appropriate xml for that to >>>work though. >> >>Buildbot can do this too. It can even do it without xml, although it >>does need *some* parseable format, which I think the Python test suite >>is a long way from. > >That would be a great improvement to the Python buildbot >infrastructure. (Probably a bit small for a GSOC project on its own.) >I've had great success using pyjunitxml to generate Hudson compatible >reports from unittest test runs (extremely easy to use), and if >buildbot *can* handle junit xml format reports then it may be the path >of least resistance: > > https://launchpad.net/pyjunitxml > >I tried searching (both google and the buildbot docs) for ways to >generate more complete reports or to integrate junitxml with builbot, >but failed. Can you point me at anything? I think this is the relevant pages in the buildbot manual for custom reporting: http://buildbot.net/buildbot/docs/latest/BuildStep-LogFiles.html #BuildStep-LogFiles There's also http://buildbot.net/buildbot/docs/latest/SubunitShellCommand.html#SubunitShellCommand which is basically the same idea as junitxml, but not actually junitxml itself, so I'd probably go that way. However if you really need junitxml for something, there are tools for converting between subunit and junitxml. Jean-Paul From ethan at stoneleaf.us Sat Feb 26 15:19:09 2011 From: ethan at stoneleaf.us (Ethan Furman) Date: Sat, 26 Feb 2011 06:19:09 -0800 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110226063617.3ad5cc6c@pitrou.net> References: <20110225011904.3ed09de7@pitrou.net> <20110226063617.3ad5cc6c@pitrou.net> Message-ID: <4D690BDD.2000600@stoneleaf.us> Antoine Pitrou wrote: > On Sat, 26 Feb 2011 12:32:04 +1000 > Nick Coghlan wrote: >> On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou wrote: >>> $ hg branches >>> default 68026:f12ef116dd10 >>> 3.2 68025:cef92ee1a323 >>> 2.7 68010:8174d00d0797 >>> 3.1 67955:5be8b695ea86 >>> 2.6 67287:5e26a860eded >>> 2.5 65464:e4ecac76e499 >>> trunk 62750:800f6c92c3ed >>> 3.0 60075:1d05144224fe >>> 2.4 58552:df72cac1899e >>> 2.3 45731:a3d9a9730743 >>> 2.2 40444:d55ddc8c8501 >>> 2.1 30171:06fcccf6eca8 >>> 2.0 18214:dc0dfc9565cd >>> >>> The branch "default" is the current py3k branch from SVN. The branch >>> "trunk" represents SVN trunk history until 2.7 was branched for >>> maintenance. >> Would it be possible to name "trunk" as "2.x" instead? Otherwise I >> could see people getting confused and asking why trunk was closed, >> and/or not the same as "default". > > That was my first idea, but then I realized that the branch includes 1.x > and even pre-1.0 commits, so "2.x" might actually be more > confusing/misleading and hide the fact that the full trunk history is > there. Maybe prePy3k, then? Trunk, after all, is not very descriptive. Or is that name also inaccurate? ~Ethan~ From ncoghlan at gmail.com Sat Feb 26 15:39:16 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 27 Feb 2011 00:39:16 +1000 Subject: [Python-Dev] Why does TemporaryDirectory not wait for `__enter__`? In-Reply-To: References: Message-ID: On Sat, Feb 26, 2011 at 10:52 PM, cool-RR wrote: > Hello, > I noticed that the `TemporaryDirectory` context manager creates the folder > on `__init__` rather than on `__enter__`, resulting in complexity, bugs, and > hackarounds in `__del__`. I assume there's a good reason for this decision. > What is it? >From the docstring: "This has the same behavior as mkdtemp but can be used as a context manager." Like files, it *can* be used as a context manager, but doesn't have to be. Also, the complexity wouldn't go away even if the directory creation was delayed until the __enter__ invocation. People can still call __enter__ directly, so __del__ would still be obliged to try to clear things up as best it could. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From merwok at netwok.org Sat Feb 26 15:40:43 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sat, 26 Feb 2011 15:40:43 +0100 Subject: [Python-Dev] [Python-checkins] r88526 - in python/branches/release32-maint/Lib: collections.py test/test_collections.py In-Reply-To: <20110223082806.3AC47EE9E3@mail.python.org> References: <20110223082806.3AC47EE9E3@mail.python.org> Message-ID: <4D6910EB.4020908@netwok.org> Hi, > Author: raymond.hettinger > New Revision: 88526 > Log: Add tests for the collections helper class and sync-up with py3k branch. > Modified: python/branches/release32-maint/Lib/collections.py > + def new_child(self): # like Django's Context.push() > + 'New ChainMap with a new dict followed by all previous maps.' > + return self.__class__({}, *self.maps) > + > + @property > + def parents(self): # like Django's Context.pop() > + 'New ChainMap from maps[1:].' > + return self.__class__(*self.maps[1:]) Isn?t this considered a new feature, unsuitable for 3.2? (I mean no disrespect, I just want to understand better what kind of changes can go in each type of branch.) Regards From ncoghlan at gmail.com Sat Feb 26 15:40:59 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 27 Feb 2011 00:40:59 +1000 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> Message-ID: On Sat, Feb 26, 2011 at 4:34 PM, Georg Brandl wrote: >> Would it be possible to name "trunk" as "2.x" instead? Otherwise I >> could see people getting confused and asking why trunk was closed, >> and/or not the same as "default". > > Problem is, you then have 1.5.2 released from the 2.x branch :) In that case, "legacy-trunk" would seem clearer. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From ncoghlan at gmail.com Sat Feb 26 15:42:04 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 27 Feb 2011 00:42:04 +1000 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <4D68C7FD.6020005@v.loewis.de> References: <20110225011904.3ed09de7@pitrou.net> <20110226063617.3ad5cc6c@pitrou.net> <4D68C7FD.6020005@v.loewis.de> Message-ID: On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. L?wis" wrote: >> I think people should simply get used to the idea that "default" is >> /the/ main branch in Mercurial (*). It's even easier to remember IMHO >> ("trunk" sounds a bit obscure at first, for a non-native English >> speaker). > > +1. People will recognize "trunk" as a svn think. If that doesn't > clue them in, they will ask, and every other person will know. But why not choose a name where they don't even have to ask? Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From andy-python at hammerhartes.de Sat Feb 26 15:42:41 2011 From: andy-python at hammerhartes.de (=?ISO-8859-1?Q?Andreas_St=FChrk?=) Date: Sat, 26 Feb 2011 14:42:41 +0000 Subject: [Python-Dev] Why does TemporaryDirectory not wait for `__enter__`? In-Reply-To: References: Message-ID: Hi On Sat, Feb 26, 2011 at 12:52 PM, cool-RR wrote: > I noticed that the `TemporaryDirectory` context manager creates the folder > on `__init__` rather than on `__enter__`, resulting in complexity, bugs, and > hackarounds in `__del__`. I assume there's a good reason for this decision. > What is it? The reason is that you can use `TemporaryDirectory` without a context manager too. Note that creating things in `__init__` rather than in `__enter__` isn't unusual -- it is done in the same way for regular files. I'm not sure what you mean with "hackarounds in `__del__`", but I assume you mean the code in `cleanup()`. That code tries to do the right thing on interpreter shutdown when parts of the interpreter are already gone and it emits a `ResourceWarning` if called implicitly (IOW: when you didn't use `TemporaryDirectory` as a context manager and didn't call its `cleanup()` method). So a bit of complexity is there, but it really isn't about where the directory is created. Regards, Andreas From solipsis at pitrou.net Sat Feb 26 15:44:08 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 26 Feb 2011 15:44:08 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> <20110226063617.3ad5cc6c@pitrou.net> <4D68C7FD.6020005@v.loewis.de> Message-ID: <1298731448.3704.1.camel@localhost.localdomain> Le dimanche 27 f?vrier 2011 ? 00:42 +1000, Nick Coghlan a ?crit : > On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. L?wis" wrote: > >> I think people should simply get used to the idea that "default" is > >> /the/ main branch in Mercurial (*). It's even easier to remember IMHO > >> ("trunk" sounds a bit obscure at first, for a non-native English > >> speaker). > > > > +1. People will recognize "trunk" as a svn think. If that doesn't > > clue them in, they will ask, and every other person will know. > > But why not choose a name where they don't even have to ask? Doesn't "trunk" represent exactly what it is (the former SVN trunk)? Other names would probably be less exact or less precise. Regards Antoine. From cool-rr at cool-rr.com Sat Feb 26 15:45:48 2011 From: cool-rr at cool-rr.com (cool-RR) Date: Sat, 26 Feb 2011 16:45:48 +0200 Subject: [Python-Dev] Why does TemporaryDirectory not wait for `__enter__`? In-Reply-To: References: Message-ID: On Sat, Feb 26, 2011 at 4:39 PM, Nick Coghlan wrote: > On Sat, Feb 26, 2011 at 10:52 PM, cool-RR wrote: > > Hello, > > I noticed that the `TemporaryDirectory` context manager creates the > folder > > on `__init__` rather than on `__enter__`, resulting in complexity, bugs, > and > > hackarounds in `__del__`. I assume there's a good reason for this > decision. > > What is it? > > From the docstring: "This has the same behavior as mkdtemp but can be > used as a context manager." Like files, it *can* be used as a context > manager, but doesn't have to be. > > Also, the complexity wouldn't go away even if the directory creation > was delayed until the __enter__ invocation. People can still call > __enter__ directly, so __del__ would still be obliged to try to clear > things up as best it could. > > Cheers, > Nick. I think that if someone calls `__enter__` directly, he takes the responsibility of calling `__exit__`, so we don't really have to help him with `__del__`. But other than that I understand the motivation for making it start on `__init__` rather then `__enter__`. I'll just make my own version of it that will work on `__enter__` instead. Thanks, Ram. -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Sat Feb 26 15:48:44 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 26 Feb 2011 15:48:44 +0100 Subject: [Python-Dev] Why does TemporaryDirectory not wait for `__enter__`? References: Message-ID: <20110226154844.220f6468@pitrou.net> On Sun, 27 Feb 2011 00:39:16 +1000 Nick Coghlan wrote: > On Sat, Feb 26, 2011 at 10:52 PM, cool-RR wrote: > > Hello, > > I noticed that the `TemporaryDirectory` context manager creates the folder > > on `__init__` rather than on `__enter__`, resulting in complexity, bugs, and > > hackarounds in `__del__`. I assume there's a good reason for this decision. > > What is it? > > >From the docstring: "This has the same behavior as mkdtemp but can be > used as a context manager." Like files, it *can* be used as a context > manager, but doesn't have to be. > > Also, the complexity wouldn't go away even if the directory creation > was delayed until the __enter__ invocation. People can still call > __enter__ directly, so __del__ would still be obliged to try to clear > things up as best it could. Calling __enter__ directly without caring to call __exit__ afterwards should certainly be considered a user bug (not to mention of dubious utility in this case, since it's easier to spell mkdtemp() than TemporaryDirectory().__enter__()). Regards Antoine. From fuzzyman at voidspace.org.uk Sat Feb 26 15:53:30 2011 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 26 Feb 2011 14:53:30 +0000 Subject: [Python-Dev] Finding buildbot failures In-Reply-To: <20110226134613.2231.442001115.divmod.xquotient.66@localhost.localdomain> References: <4D67F959.8080701@voidspace.org.uk> <20110225190014.2231.1678753723.divmod.xquotient.58@localhost.localdomain> <4D68FD31.70901@voidspace.org.uk> <20110226134613.2231.442001115.divmod.xquotient.66@localhost.localdomain> Message-ID: <4D6913EA.6070405@voidspace.org.uk> On 26/02/2011 13:46, exarkun at twistedmatrix.com wrote: > On 01:16 pm, fuzzyman at voidspace.org.uk wrote: >> On 25/02/2011 19:00, exarkun at twistedmatrix.com wrote: >>> On 06:47 pm, fuzzyman at voidspace.org.uk wrote: >>>> On 25/02/2011 18:10, Vinay Sajip wrote: >>>>> What's the easiest way of finding which tests failed on buildbot >>>>> builds? I mean, >>>>> is there anything easier than using the Web interface to browse to >>>>> failing >>>>> builds and then looking at the stdio output in a browser? >>>> >>>> That's one of the big advantages that Jenkins (nee Hudson) has over >>>> buildbot - drilling down into individual test failures through the >>>> web ui. Your test run needs to generate appropriate xml for that to >>>> work though. >>> >>> Buildbot can do this too. It can even do it without xml, although >>> it does need *some* parseable format, which I think the Python test >>> suite is a long way from. >> >> That would be a great improvement to the Python buildbot >> infrastructure. (Probably a bit small for a GSOC project on its own.) >> I've had great success using pyjunitxml to generate Hudson compatible >> reports from unittest test runs (extremely easy to use), and if >> buildbot *can* handle junit xml format reports then it may be the >> path of least resistance: >> >> https://launchpad.net/pyjunitxml >> >> I tried searching (both google and the buildbot docs) for ways to >> generate more complete reports or to integrate junitxml with builbot, >> but failed. Can you point me at anything? > > I think this is the relevant pages in the buildbot manual for custom > reporting: > > http://buildbot.net/buildbot/docs/latest/BuildStep-LogFiles.html > #BuildStep-LogFiles > > There's also > http://buildbot.net/buildbot/docs/latest/SubunitShellCommand.html#SubunitShellCommand > > > which is basically the same idea as junitxml, but not actually > junitxml itself, so I'd probably go that way. However if you really > need junitxml for something, there are tools for converting between > subunit and junitxml. Thanks Jean-Paul. Michael > > Jean-Paul > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From fuzzyman at voidspace.org.uk Sat Feb 26 15:57:16 2011 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 26 Feb 2011 14:57:16 +0000 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <1298731448.3704.1.camel@localhost.localdomain> References: <20110225011904.3ed09de7@pitrou.net> <20110226063617.3ad5cc6c@pitrou.net> <4D68C7FD.6020005@v.loewis.de> <1298731448.3704.1.camel@localhost.localdomain> Message-ID: <4D6914CC.70404@voidspace.org.uk> On 26/02/2011 14:44, Antoine Pitrou wrote: > Le dimanche 27 f?vrier 2011 ? 00:42 +1000, Nick Coghlan a ?crit : >> On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. L?wis" wrote: >>>> I think people should simply get used to the idea that "default" is >>>> /the/ main branch in Mercurial (*). It's even easier to remember IMHO >>>> ("trunk" sounds a bit obscure at first, for a non-native English >>>> speaker). >>> +1. People will recognize "trunk" as a svn think. If that doesn't >>> clue them in, they will ask, and every other person will know. >> But why not choose a name where they don't even have to ask? > Doesn't "trunk" represent exactly what it is (the former SVN trunk)? > Other names would probably be less exact or less precise. Well, except for the prevalence of "trunk" as terminology to mean "place where current development happens". It will lead to odd conversations like: "is trunk the trunk?", "no trunk is what used to be trunk, default is now trunk". Renaming it "legacy-trunk" is no less precise, but more explicative. Michael > Regards > > Antoine. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html From solipsis at pitrou.net Sat Feb 26 15:57:34 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 26 Feb 2011 15:57:34 +0100 Subject: [Python-Dev] Mercurial conversion repositories References: <20110225011904.3ed09de7@pitrou.net> <20110226063617.3ad5cc6c@pitrou.net> <4D68C7FD.6020005@v.loewis.de> <1298731448.3704.1.camel@localhost.localdomain> Message-ID: <20110226155734.54045763@pitrou.net> On Sat, 26 Feb 2011 15:44:08 +0100 Antoine Pitrou wrote: > Le dimanche 27 f?vrier 2011 ? 00:42 +1000, Nick Coghlan a ?crit : > > On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. L?wis" wrote: > > >> I think people should simply get used to the idea that "default" is > > >> /the/ main branch in Mercurial (*). It's even easier to remember IMHO > > >> ("trunk" sounds a bit obscure at first, for a non-native English > > >> speaker). > > > > > > +1. People will recognize "trunk" as a svn think. If that doesn't > > > clue them in, they will ask, and every other person will know. > > > > But why not choose a name where they don't even have to ask? > > Doesn't "trunk" represent exactly what it is (the former SVN trunk)? > Other names would probably be less exact or less precise. Although I now admit "legacy-trunk" sounds quite accurate, and conveys a clear warning to anyone wondering if they should use it. Regards Antoine. From ncoghlan at gmail.com Sat Feb 26 16:16:42 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 27 Feb 2011 01:16:42 +1000 Subject: [Python-Dev] [Python-checkins] r88526 - in python/branches/release32-maint/Lib: collections.py test/test_collections.py In-Reply-To: <4D6910EB.4020908@netwok.org> References: <20110223082806.3AC47EE9E3@mail.python.org> <4D6910EB.4020908@netwok.org> Message-ID: On Sun, Feb 27, 2011 at 12:40 AM, ?ric Araujo wrote: > Isn?t this considered a new feature, unsuitable for 3.2? ?(I mean no > disrespect, I just want to understand better what kind of changes can go > in each type of branch.) collections._ChainMap itself is private, so changes can be made to its API even in a maintenance branch. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From merwok at netwok.org Sat Feb 26 16:17:51 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sat, 26 Feb 2011 16:17:51 +0100 Subject: [Python-Dev] [Python-checkins] r88526 - in python/branches/release32-maint/Lib: collections.py test/test_collections.py In-Reply-To: References: <20110223082806.3AC47EE9E3@mail.python.org> <4D6910EB.4020908@netwok.org> Message-ID: <4D69199F.7030908@netwok.org> > collections._ChainMap itself is private, so changes can be made to its > API even in a maintenance branch. Makes perfect sense, thanks for the reply :) Cheers From martin at v.loewis.de Sat Feb 26 17:02:07 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 26 Feb 2011 17:02:07 +0100 Subject: [Python-Dev] [Python-checkins] cpython (trunk): Close the "trunk" branch. In-Reply-To: <20110226110612.2766c0da@pitrou.net> References: <4D68CD42.5050005@v.loewis.de> <20110226110612.2766c0da@pitrou.net> Message-ID: <4D6923FF.9050204@v.loewis.de> > Committing reopened it So what's the point of closing it, then? What effect does that achieve? Regards, Martin From solipsis at pitrou.net Sat Feb 26 17:11:13 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 26 Feb 2011 17:11:13 +0100 Subject: [Python-Dev] [Python-checkins] cpython (trunk): Close the "trunk" branch. In-Reply-To: <4D6923FF.9050204@v.loewis.de> References: <4D68CD42.5050005@v.loewis.de> <20110226110612.2766c0da@pitrou.net> <4D6923FF.9050204@v.loewis.de> Message-ID: <1298736673.3704.6.camel@localhost.localdomain> Le samedi 26 f?vrier 2011 ? 17:02 +0100, "Martin v. L?wis" a ?crit : > > Committing reopened it > > So what's the point of closing it, then? What effect does that > achieve? Again, as I said, it doesn't get displayed anymore with the standard commands "hg branches" and "hg heads". Consider it a convention rather than some kind of hard stop against future commits. Regards Antoine. From martin at v.loewis.de Sat Feb 26 17:17:35 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 26 Feb 2011 17:17:35 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> <20110226063617.3ad5cc6c@pitrou.net> <4D68C7FD.6020005@v.loewis.de> Message-ID: <4D69279F.8030002@v.loewis.de> Am 26.02.2011 15:42, schrieb Nick Coghlan: > On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. L?wis" wrote: >>> I think people should simply get used to the idea that "default" is >>> /the/ main branch in Mercurial (*). It's even easier to remember IMHO >>> ("trunk" sounds a bit obscure at first, for a non-native English >>> speaker). >> >> +1. People will recognize "trunk" as a svn think. If that doesn't >> clue them in, they will ask, and every other person will know. > > But why not choose a name where they don't even have to ask? That could be better. Unfortunately, nobody has proposed a name that has this property and is also correct. Regards, Martin From martin at v.loewis.de Sat Feb 26 17:27:20 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 26 Feb 2011 17:27:20 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110226155734.54045763@pitrou.net> References: <20110225011904.3ed09de7@pitrou.net> <20110226063617.3ad5cc6c@pitrou.net> <4D68C7FD.6020005@v.loewis.de> <1298731448.3704.1.camel@localhost.localdomain> <20110226155734.54045763@pitrou.net> Message-ID: <4D6929E8.1090401@v.loewis.de> > Although I now admit "legacy-trunk" sounds quite accurate, and conveys > a clear warning to anyone wondering if they should use it. To stay in tree terminology, I propose "stump" (*). Or "rotten-trunk". Bikeshedding is such a fun activity :-) Regards, Martin (*) m-w.com: "the part of a plant and especially a tree remaining attached to the root after the trunk is cut" From stutzbach at google.com Sat Feb 26 17:38:18 2011 From: stutzbach at google.com (Daniel Stutzbach) Date: Sat, 26 Feb 2011 08:38:18 -0800 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> Message-ID: On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan wrote: > Would it be possible to name "trunk" as "2.x" instead? Otherwise I > could see people getting confused and asking why trunk was closed, > and/or not the same as "default". > Can we just get rid of "trunk" altogether? It's history is a strict subset of the 2.7 branch's history, isn't it? -- Daniel Stutzbach -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Sat Feb 26 17:44:45 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 26 Feb 2011 17:44:45 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> Message-ID: <1298738685.3704.10.camel@localhost.localdomain> Le samedi 26 f?vrier 2011 ? 08:38 -0800, Daniel Stutzbach a ?crit : > On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan > wrote: > Would it be possible to name "trunk" as "2.x" instead? > Otherwise I > could see people getting confused and asking why trunk was > closed, > and/or not the same as "default". > > > Can we just get rid of "trunk" altogether? It's history is a strict > subset of the 2.7 branch's history, isn't it? Named branches are exclusive, they can't be a subset of each other ;) (in other words: 2.7 starts where trunk stops; trunk changesets are strict ancestors of 2.7) Regards Antoine. From merwok at netwok.org Sat Feb 26 17:49:32 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sat, 26 Feb 2011 17:49:32 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <1298738685.3704.10.camel@localhost.localdomain> References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> Message-ID: <4D692F1C.8090200@netwok.org> Le 26/02/2011 17:44, Antoine Pitrou a ?crit : >> Can we just get rid of "trunk" altogether? It's history is a strict >> subset of the 2.7 branch's history, isn't it? > > Named branches are exclusive, they can't be a subset of each other ;) Can we just use default for trunk and py3k? For the time when both trunk and py3k were active, it would create two unnamed branches on the default branch, but one merge would solve that. Regards From ncoghlan at gmail.com Sat Feb 26 17:57:23 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 27 Feb 2011 02:57:23 +1000 Subject: [Python-Dev] [Python-checkins] r88601 - peps/trunk/pep-0385.txt In-Reply-To: <20110225191207.51301EE985@mail.python.org> References: <20110225191207.51301EE985@mail.python.org> Message-ID: On Sat, Feb 26, 2011 at 5:12 AM, antoine.pitrou wrote: > +In practice, most Mercurial users under Windows don't seem to have a need > +for the ``eol`` extension, though, and personal experience using a > +Linux-generated SVN checkout through a shared folder under Windows seems > +to confirm that modern tools work well without it. Feedback from the Mozilla and XEmacs folks at the time of that discussion suggested that EOL issues *were* a potential issue, and that having to revert unintentional commits of CRLF line endings was an annoyingly common problem. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From solipsis at pitrou.net Sat Feb 26 18:00:19 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 26 Feb 2011 18:00:19 +0100 Subject: [Python-Dev] Mercurial conversion repositories References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> <4D692F1C.8090200@netwok.org> Message-ID: <20110226180019.337a7057@pitrou.net> On Sat, 26 Feb 2011 17:49:32 +0100 ?ric Araujo wrote: > Le 26/02/2011 17:44, Antoine Pitrou a ?crit : > >> Can we just get rid of "trunk" altogether? It's history is a strict > >> subset of the 2.7 branch's history, isn't it? > > > > Named branches are exclusive, they can't be a subset of each other ;) > > Can we just use default for trunk and py3k? For the time when both > trunk and py3k were active, it would create two unnamed branches on the > default branch, but one merge would solve that. IMO, a dummy merge at the tip of the default branch may confuse users looking at the history, especially if they try a graphical display of the DAG (e.g. "hg glog" or the graph page in the Web UI). Besides, it would precisely make it harder to distinguish between trunk and py3k development at the time both took place in parallel. Regards Antoine. From ncoghlan at gmail.com Sat Feb 26 18:11:27 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 27 Feb 2011 03:11:27 +1000 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110226180019.337a7057@pitrou.net> References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> <4D692F1C.8090200@netwok.org> <20110226180019.337a7057@pitrou.net> Message-ID: On Sun, Feb 27, 2011 at 3:00 AM, Antoine Pitrou wrote: > Besides, it would precisely make it harder to distinguish between > trunk and py3k development at the time both took place in parallel. With the legacy branches now being closed so they don't appear in the default output from hg commands, I'm fine with keeping the old "trunk" name from SVN. It was only when those commands were displaying both "trunk" and "default" that it bothered me. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From merwok at netwok.org Sat Feb 26 18:11:45 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sat, 26 Feb 2011 18:11:45 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110226180019.337a7057@pitrou.net> References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> <4D692F1C.8090200@netwok.org> <20110226180019.337a7057@pitrou.net> Message-ID: <4D693451.3040001@netwok.org> >> Can we just use default for trunk and py3k? For the time when both >> trunk and py3k were active, it would create two unnamed branches on the >> default branch, but one merge would solve that. > > IMO, a dummy merge at the tip of the default branch may confuse users > looking at the history, especially if they try a graphical display of > the DAG (e.g. "hg glog" or the graph page in the Web UI). The dummy merge would not stay long: The commits targeted at 3.3 would be its children. > Besides, it would precisely make it harder to distinguish between > trunk and py3k development at the time both took place in parallel. IIUC, there would be two parallel lines of history (unnnamed branches). Would that be hard to read? Regards From tjreedy at udel.edu Sat Feb 26 18:25:20 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 26 Feb 2011 12:25:20 -0500 Subject: [Python-Dev] set iteration order In-Reply-To: References: Message-ID: On 2/26/2011 4:09 AM, Hagen F?rstenau wrote: > Hi, > > I just hunted down a change in behaviour between Python 3.1 and 3.2 to > possibly changed iteration order of sets due to the optimization in > issue #8685. Of course, this order shouldn't be relied on in the first > place, but the side effect of the optimization might be worth mentioning > in "What's new", maybe also pointing out that the old behaviour can be > simulated with {x for x in a if x not in b} in place of "a-b". -1 Code with any dependence on the iteration order of unordered collections (other than the guarantee that d.keys() and d.values() match at any given time as long as d is unchanged) is buggy. It is not the place of What's new to cater to buggy code. Besides which, there is no guarantee that the 'x in a' part of the suggestion will will remain the same from version to version or even from run to run. -- Terry Jan Reedy From stutzbach at google.com Sat Feb 26 18:27:56 2011 From: stutzbach at google.com (Daniel Stutzbach) Date: Sat, 26 Feb 2011 09:27:56 -0800 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <1298738685.3704.10.camel@localhost.localdomain> References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> Message-ID: On Sat, Feb 26, 2011 at 8:44 AM, Antoine Pitrou wrote: > Le samedi 26 f?vrier 2011 ? 08:38 -0800, Daniel Stutzbach a ?crit : > > Can we just get rid of "trunk" altogether? It's history is a strict > > subset of the 2.7 branch's history, isn't it? > > Named branches are exclusive, they can't be a subset of each other ;) > (in other words: 2.7 starts where trunk stops; trunk changesets are > strict ancestors of 2.7) > Maybe I don't fully understand how Mercurial branches work or how it defines terminology (in fact, that is likely :) ). What's the difference between the statement "trunk changesets are strict ancestors of 2.7" and the statement "trunk's history is a strict subset of 2.7's history"? -- Daniel Stutzbach -------------- next part -------------- An HTML attachment was scrubbed... URL: From merwok at netwok.org Sat Feb 26 18:32:01 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sat, 26 Feb 2011 18:32:01 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> Message-ID: <4D693911.4000004@netwok.org> >> Named branches are exclusive, they can't be a subset of each other ;) Actually, they can. Take the example of the Mercurial repo itself. They fix bugs in the stable branch and add features in default. When they merge stable into default and commit, default becomes a superset of stable. That is to say, someone pulling default also gets the changesets from stable that are ancestors of the merge changset. Or in other words, if you check out default, you get all bug fixes from stable. HTH From solipsis at pitrou.net Sat Feb 26 18:32:26 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 26 Feb 2011 18:32:26 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> Message-ID: <1298741546.3704.11.camel@localhost.localdomain> Le samedi 26 f?vrier 2011 ? 09:27 -0800, Daniel Stutzbach a ?crit : > On Sat, Feb 26, 2011 at 8:44 AM, Antoine Pitrou > wrote: > Le samedi 26 f?vrier 2011 ? 08:38 -0800, Daniel Stutzbach a > ?crit : > > > Can we just get rid of "trunk" altogether? It's history is > a strict > > subset of the 2.7 branch's history, isn't it? > > > Named branches are exclusive, they can't be a subset of each > other ;) > (in other words: 2.7 starts where trunk stops; trunk > changesets are > strict ancestors of 2.7) > > > Maybe I don't fully understand how Mercurial branches work or how it > defines terminology (in fact, that is likely :) ). What's the > difference between the statement "trunk changesets are strict > ancestors of 2.7" and the statement "trunk's history is a strict > subset of 2.7's history"? Apparently you overlooked the first statement: "Named branches are exclusive". In other words, a changeset can be in only one named branch. So it's impossible for a branch to be a subset or superset of another. (except the trivial case of an empty branch :-)). From martin at v.loewis.de Sat Feb 26 18:36:02 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Sat, 26 Feb 2011 18:36:02 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <1298738685.3704.10.camel@localhost.localdomain> References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> Message-ID: <4D693A02.4000104@v.loewis.de> Am 26.02.2011 17:44, schrieb Antoine Pitrou: > Le samedi 26 f?vrier 2011 ? 08:38 -0800, Daniel Stutzbach a ?crit : >> On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan >> wrote: >> Would it be possible to name "trunk" as "2.x" instead? >> Otherwise I >> could see people getting confused and asking why trunk was >> closed, >> and/or not the same as "default". >> >> >> Can we just get rid of "trunk" altogether? It's history is a strict >> subset of the 2.7 branch's history, isn't it? > > Named branches are exclusive, they can't be a subset of each other ;) > (in other words: 2.7 starts where trunk stops; trunk changesets are > strict ancestors of 2.7) But is there a need to have any changesets in the "trunk" named branch? Couldn't the historical changesets just be in an unnamed branch, being ancestor of so many named branches? I'd like to prevent people from mistakenly committing onto the trunk, which would be easiest if trunk didn't exist at all. Regards, Martin From solipsis at pitrou.net Sat Feb 26 18:54:02 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 26 Feb 2011 18:54:02 +0100 Subject: [Python-Dev] pymigr: Ask for hgeol-checking hook. References: Message-ID: <20110226185402.14b66d79@pitrou.net> On Sat, 26 Feb 2011 18:48:17 +0100 martin.v.loewis wrote: > * some hook should prevent pushing python files indented by tabs. > * some hook should prevent pushing to the 2.x trunk. > +* some hook should prevent breaking EOL conventions. We don't have such hook in SVN, why would we need one with Mercurial ? From solipsis at pitrou.net Sat Feb 26 18:55:40 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 26 Feb 2011 18:55:40 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <4D693A02.4000104@v.loewis.de> References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> <4D693A02.4000104@v.loewis.de> Message-ID: <1298742940.3704.17.camel@localhost.localdomain> Le samedi 26 f?vrier 2011 ? 18:36 +0100, "Martin v. L?wis" a ?crit : > Am 26.02.2011 17:44, schrieb Antoine Pitrou: > > Le samedi 26 f?vrier 2011 ? 08:38 -0800, Daniel Stutzbach a ?crit : > >> On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan > >> wrote: > >> Would it be possible to name "trunk" as "2.x" instead? > >> Otherwise I > >> could see people getting confused and asking why trunk was > >> closed, > >> and/or not the same as "default". > >> > >> > >> Can we just get rid of "trunk" altogether? It's history is a strict > >> subset of the 2.7 branch's history, isn't it? > > > > Named branches are exclusive, they can't be a subset of each other ;) > > (in other words: 2.7 starts where trunk stops; trunk changesets are > > strict ancestors of 2.7) > > But is there a need to have any changesets in the "trunk" named branch? > Couldn't the historical changesets just be in an unnamed branch, being > ancestor of so many named branches? There is no such thing as an "unnamed branch". What would "hg branches" show? An empty space? > I'd like to prevent people from mistakenly committing onto the trunk, > which would be easiest if trunk didn't exist at all. Well, the push you request in the todo should do the trick. We can also call it "legacy-trunk", too :) Regards Antoine. From martin at v.loewis.de Sat Feb 26 19:05:50 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 26 Feb 2011 19:05:50 +0100 Subject: [Python-Dev] pymigr: Ask for hgeol-checking hook. In-Reply-To: <20110226185402.14b66d79@pitrou.net> References: <20110226185402.14b66d79@pitrou.net> Message-ID: <4D6940FE.509@v.loewis.de> Am 26.02.2011 18:54, schrieb Antoine Pitrou: > On Sat, 26 Feb 2011 18:48:17 +0100 > martin.v.loewis wrote: >> * some hook should prevent pushing python files indented by tabs. >> * some hook should prevent pushing to the 2.x trunk. >> +* some hook should prevent breaking EOL conventions. > > We don't have such hook in SVN, why would we need one with Mercurial ? In subversion, it's a builtin feature of subversion (svn:eol-style); subversion will automatically convert all files correctly (if svn:eol-style is specified correctly, which it is, for most of the files). In Mercurial, it's just a hook, and optional. So we can't be sure all users use it correctly - and in my (limited) experience with Mercurial, chances are high that users will make mistakes in that respect (i.e. in one out of one cross-platform projects, a committer had issues with CRLF, leading to catastrophic repository corruption). So I think it's absolutely necessary that files with incorrect eol-style are blocked from being pushed. Or else we will all suffer and eventually die :-) Regards, Martin From barry at python.org Sat Feb 26 19:08:47 2011 From: barry at python.org (Barry Warsaw) Date: Sat, 26 Feb 2011 13:08:47 -0500 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <4D684E2A.90005@netwok.org> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> Message-ID: <20110226130847.05daf511@limelight.wooz.org> On Feb 26, 2011, at 01:49 AM, ?ric Araujo wrote: >Le 25/02/2011 20:43, Barry Warsaw a ?crit : >> On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: >> [snip] >>> Note that each of these branch clones will initially have your local >>> master repo as the default path [3,4]. If you'd like to have the default >>> push/pull path to point to ssh://hg at hg.python.org/cpython instead, you'd >>> want to edit the [paths] section in the .hg/hgrc file in each of the >>> branch repos. > >I plan on having one clone per branch but pushing and pulling from only >one repository, so I don?t need to edit hgrcs. So let's start from the basics. I want separate working directories for each active line-of-development (I'll use that term instead of "branch"), e.g. working directories containing the tip of the 2.6 LoD, 2.7, 3.1, 3.2, and 3.3. I will not be doing feature or bug development in any of these directories. They are purely for local tracking of the remote masters. Thus, I want to be able to synchronize any one of those LoDs against the remote master with one command, like I would using Subversion's 'svn up'. I clone the remote repository using the command in the devguide, so I now have a 'cpython' directory containing the history of all LoDs, but with a working directory that reflects the 'default' LoD. Now, in the parent of 'cpython', I do the following to get my separate-directory-LoDs: $ hg clone -u 2.6 cpython py26 $ hg clone -u 2.7 cpython py27 # repeat and rinse for all other active LoDs (Aside: that cpython directory still bugs me. It doesn't naturally reflect a LoD, so why do I have to stare at it? Yes, I can make it play double duty by naming it "3.3" or whatever and updating it to the 3.3 LoD, but that feels artificial.) Now I want to synchronize my local py27 directory with the state of that LoD on python.org. This is a two step process: $ cd py27 # now I want to synchronize $ (cd ../cpython && hg pull) $ hg pull -u Editing hgrc to point to hg.python.org means the sync-to-remote-master operation is one command. I could do this: $ cd py27 # now I want to synchronize $ hg pull -u ssh://hg at hg.python.org/cpython but I'm not going to remember that url every time. It wouldn't be so bad if Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does. >Anecdote: I migrated from Subversion to Mercurial a few years ago, and >found Mercurial branches very intuitive. When I saw mentions of Bazaar >branches I was driven nuts by (what I saw as) the conflation between a >branch and a clone. Later I understood how it made sense from the >perspective of Bazaar, so I shifted my judgment from ?insanely >confusing? to ?a particular choice that I don?t approve? . That's funny because to my eyes, Mercurial conflates "branches" and "clones". Why a clone operation should give me the history for all lines-of-development inside a working directory for one "arbitrary" one strikes me as bizarre (pardon the pun :). I get that for folks who like the "svn switch" method of working on multiple LoDs, this probably makes a lot of sense. I don't personally like or trust that approach much though. >What I?m saying is that a lot of Bazaar terminology using ?branch? does >not map as-is to Mercurial. We clone a repo, we pull from a repo/clone, >we have named branches (e.g. 3.2) in a repo, we have unnamed branches on >one named branch. I think you know that already, since you went from >using Bazaar terms applied to Mercurial to mixing terms from both >(?clone a new branch working directory? ? ?clone a repo?, probably). I >salute your willingness to learn Mercurial, considering how fluent (and >fluffly) you appear to be with Bazaar. This is an inevitable problem with trying to converse fluently about three major dVCSs and at least one or two other non-dVCSs. They all use the same words to mean vaguely similar things, but quickly get bogged down in the implementation details assigned to those words. It all makes perfect sense when you've been immersed in those technologies, but it makes discussions and comparisons exceedingly difficult. I've no doubt it's doubly painful to many people who have no prior experience with a dVCS. (Aside: Bazaar could have potentially eased these folks transition because you can use Bazaar just like you would Subversion - as a centralized VCS -- without stopping others from using it with full dVCS features on the same code base. I don't know if Mercurial offers the same flexibility.) It's a little like trying to teach Python to a Java programmer. "Object", "Class", "Instance", "Import" all mean roughly similar things, which lulls you into a false sense of understanding. We learn by holding up the new to the light of the familiar and looking for interference patterns. :) >> I'll have to remember that 'hg pull' does not update the working copy by >> default, > >That pull does not update is a feature: The operation between a remote >repo and the local repo (the .hg directory) is separate from the >operation from the local repo to the working directory. When you know >that you want pull + update (like when you have a clean working >directory), you use ?hg pull -u?. (I don?t like the fetch command.) Sure, I get that. Again, this feature appears odd because I have the full history of all LoDs embedded in a working directory of a single LoD. With the arrangement I outlined above (which is independent of the dVCS backing it), it makes no sense for each LoD working directory to contain all the history of all the other LoDs. In Bazaar, a "branch" is an independent LoD and it's "repository" contains only its own history. Sure, it might have identical history with other LoDs up to the point of divergence, and I have ways to efficiently share that history across multiple LoD working directories, but they are still separate and I don't need them if I don't care about them. With Mercurial, all history for all LoDs in a repository always come along for the ride. >You speak to my heart, sir. In your ~/.hgrc, under the section [ui], >set ?editor = path/to/mercurial/source/hgeditor? and enjoy your diffs. >I use it and love it. Great, I'll try that, thanks. One thing Mercurial and Bazaar definitely share is a wealth of magical awesomeness hidden in manpages, wiki pages, mailing list posts, people's heads, configuration files, and source code. :) >If you want to commit a subset of your local changes, I use >http://mercurial.selenic.com/wiki/CrecordExtension , a curses-based diff >selection UI that works like a charm. I very rarely want to do that. It's more common (but still, IME not *that* common) to commit the changes to just a few files at a time. One thing Bazaar has that's very nice is the ability to "shelve" some changes for a time. Let's say I'm working on a bug and I want to merge your changes in or sync to the master. I can shelve some or all of my uncommitted changes, which saves them essentially out-of-the-way patch files, and then reverts my uncommitted changes. Unshelving then is the process of re-applying those patch files, and yes, resolving conflicts. This is also a great way to work when you want to do test-driven-development but need to do some exploration first. You can hack around non-TDD until you're confident of your approach, shelve all your changes, then incrementally apply them back as you write each test. I'm sure Mercurial has something equally awesome lurking about. :) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Sat Feb 26 19:12:25 2011 From: barry at python.org (Barry Warsaw) Date: Sat, 26 Feb 2011 13:12:25 -0500 Subject: [Python-Dev] [Python-checkins] cpython: improve license In-Reply-To: References: Message-ID: <20110226131225.2f310fc4@limelight.wooz.org> Notice the subject line. Can we make commit messages contain the named branch that the change applies to? The 'cpython' in the header doesn't really tell me whether I should care about this diff or not. Say the change applied to 2.6 but I only care about Python 3. It would be nice if I could just delete this message without reading the body. I guess it's possible for change notifications to encompass multiple named branches though, right? I'm not sure what to do about that, but it seems like a less common use case. -Barry On Feb 26, 2011, at 07:05 PM, benjamin.peterson wrote: >benjamin.peterson pushed 0873fb83f1e2 to cpython: > >http://hg.python.org/cpython/rev/0873fb83f1e2 >changeset: 68052:0873fb83f1e2 >tag: tip >user: Benjamin Peterson >date: Sat Feb 26 12:06:36 2011 -0600 >summary: > improve license > >files: > LICENSE -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From solipsis at pitrou.net Sat Feb 26 19:13:29 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 26 Feb 2011 19:13:29 +0100 Subject: [Python-Dev] pymigr: Ask for hgeol-checking hook. In-Reply-To: <4D6940FE.509@v.loewis.de> References: <20110226185402.14b66d79@pitrou.net> <4D6940FE.509@v.loewis.de> Message-ID: <1298744009.3704.25.camel@localhost.localdomain> > In Mercurial, it's just a hook, and optional. So we can't be sure all > users use it correctly - and in my (limited) experience with Mercurial, > chances are high that users will make mistakes in that respect (i.e. > in one out of one cross-platform projects, a committer had issues > with CRLF, leading to catastrophic repository corruption). ?Catastrophic? repository ?corruption?? This sounds very strongly like an urban legend. Perhaps some files had later to be fixed. But that shouldn't be out of the realm of normal Mercurial commands (aka "edit file to fix endings, then hg commit and hg push"). > So I think it's absolutely necessary that files with incorrect > eol-style are blocked from being pushed. Or else we will all > suffer and eventually die :-) Well, the latter is a given, isn't it? ;) Anyway, hgeol actually seems to include such a hook. I'll try to enable it. Regards Antoine. From martin at v.loewis.de Sat Feb 26 19:18:41 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Sat, 26 Feb 2011 19:18:41 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <1298742940.3704.17.camel@localhost.localdomain> References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> <4D693A02.4000104@v.loewis.de> <1298742940.3704.17.camel@localhost.localdomain> Message-ID: <4D694401.1000009@v.loewis.de> >> But is there a need to have any changesets in the "trunk" named branch? >> Couldn't the historical changesets just be in an unnamed branch, being >> ancestor of so many named branches? > > There is no such thing as an "unnamed branch". What would "hg branches" > show? An empty space? hg branches doesn't list unnamed branches. "hg heads" omits any branch name for unnamed branches. See the cpythonextras repository for examples: changeset: 72694:e65daae6cf44 user: Antoine Pitrou date: Mon Feb 21 21:30:55 2011 +0000 summary: Try s/UINT_MAX/INT_MAX/ This is listed as a head, but not of a named branch. >> I'd like to prevent people from mistakenly committing onto the trunk, >> which would be easiest if trunk didn't exist at all. > > Well, the push you request in the todo should do the trick. Yes, that would also work. However, when then somebody proposed that we may not need the trunk branch at all in the conversion result (which I still think is the case - we don't need it), I noticed that this would solve the problem in a more clean manner. > We can also call it "legacy-trunk", too :) I think we can do better. I also dislike "hg log --only-branch default" to only go back to 2006 (to aeefba456e4d), when this revision actually does have a parent (namely, on the trunk branch, 4b41806a0326). So I would propose this attribution to branches: - everything that is ancestor of the default branch is attributed to the default branch, back to the very beginning of the repository. - Everything currently on trunk that wouldn't be on default is then attributed to the oldest branch that it is an ancestor of, in the order 2.0, 2.1, 2.2, ... 2.7. So e.g. the 2.7 branch would go back to where it branched from the 2.6 branch (after the actual creation of the 2.6 branch in svn), which would go back to where it branched from 2.5, and so on. Regards, Martin From martin at v.loewis.de Sat Feb 26 19:19:37 2011 From: martin at v.loewis.de (=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 26 Feb 2011 19:19:37 +0100 Subject: [Python-Dev] [Python-checkins] cpython: improve license In-Reply-To: <20110226131225.2f310fc4@limelight.wooz.org> References: <20110226131225.2f310fc4@limelight.wooz.org> Message-ID: <4D694439.5010004@v.loewis.de> Am 26.02.2011 19:12, schrieb Barry Warsaw: > Notice the subject line. Can we make commit messages contain the named branch > that the change applies to? If you don't want this request to be forgotten, add it to todo.txt in the pymigr repo. Regards, Martin From barry at python.org Sat Feb 26 19:23:10 2011 From: barry at python.org (Barry Warsaw) Date: Sat, 26 Feb 2011 13:23:10 -0500 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <4D693911.4000004@netwok.org> References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> <4D693911.4000004@netwok.org> Message-ID: <20110226132310.3dc2da5f@limelight.wooz.org> On Feb 26, 2011, at 06:32 PM, ?ric Araujo wrote: >>> Named branches are exclusive, they can't be a subset of each other ;) > >Actually, they can. Take the example of the Mercurial repo itself. They >fix bugs in the stable branch and add features in default. When they >merge stable into default and commit, default becomes a superset of >stable. That is to say, someone pulling default also gets the >changesets from stable that are ancestors of the merge changset. Or in >other words, if you check out default, you get all bug fixes from stable. That makes sense, but correct me if I'm wrong, it's the 'merge' operation that made this happen, right? A merge essentially brings the changesets from one branch into another. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From martin at v.loewis.de Sat Feb 26 19:23:49 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Sat, 26 Feb 2011 19:23:49 +0100 Subject: [Python-Dev] pymigr: Ask for hgeol-checking hook. In-Reply-To: <1298744009.3704.25.camel@localhost.localdomain> References: <20110226185402.14b66d79@pitrou.net> <4D6940FE.509@v.loewis.de> <1298744009.3704.25.camel@localhost.localdomain> Message-ID: <4D694535.6070207@v.loewis.de> Am 26.02.2011 19:13, schrieb Antoine Pitrou: > >> In Mercurial, it's just a hook, and optional. So we can't be sure all >> users use it correctly - and in my (limited) experience with Mercurial, >> chances are high that users will make mistakes in that respect (i.e. >> in one out of one cross-platform projects, a committer had issues >> with CRLF, leading to catastrophic repository corruption). > > ?Catastrophic? repository ?corruption?? This sounds very strongly like > an urban legend. > Perhaps some files had later to be fixed. But that shouldn't be out of > the realm of normal Mercurial commands (aka "edit file to fix endings, > then hg commit and hg push"). It actually happened to me, so please trust me that it's not a legend. Yes, I could fix it with hg commands, and a lot of text editing. It took me a day, I considered the repository corrupted so that I actually had to branch from the last ok revision, and redo all checkins since (I also discarded changes which I didn't chose to redo). It was a real catastrophe to me. Since the changes actually changed all lines, "hg blame" became useless, which was unacceptable. Regards, Martin From solipsis at pitrou.net Sat Feb 26 19:39:13 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 26 Feb 2011 19:39:13 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <4D694401.1000009@v.loewis.de> References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> <4D693A02.4000104@v.loewis.de> <1298742940.3704.17.camel@localhost.localdomain> <4D694401.1000009@v.loewis.de> Message-ID: <1298745553.3704.31.camel@localhost.localdomain> > >> But is there a need to have any changesets in the "trunk" named branch? > >> Couldn't the historical changesets just be in an unnamed branch, being > >> ancestor of so many named branches? > > > > There is no such thing as an "unnamed branch". What would "hg branches" > > show? An empty space? > > hg branches doesn't list unnamed branches. "hg heads" omits any branch > name for unnamed branches. See the cpythonextras repository for examples: > > changeset: 72694:e65daae6cf44 > user: Antoine Pitrou > date: Mon Feb 21 21:30:55 2011 +0000 > summary: Try s/UINT_MAX/INT_MAX/ It's not on an unnamed branch, it's on the "default" branch (which is omitted for concision by "hg log" and other commands with a similar output). > >> I'd like to prevent people from mistakenly committing onto the trunk, > >> which would be easiest if trunk didn't exist at all. > > > > Well, the push you request in the todo should do the trick. > > Yes, that would also work. However, when then somebody proposed that > we may not need the trunk branch at all in the conversion result > (which I still think is the case - we don't need it), I noticed > that this would solve the problem in a more clean manner. But you *need* the changesets from the trunk branch. You are just arguing for giving them another label (including "" or "default"), hence: > > We can also call it "legacy-trunk", too :) > > I think we can do better. I also dislike "hg log --only-branch default" > to only go back to 2006 (to aeefba456e4d), when this revision actually > does have a parent (namely, on the trunk branch, 4b41806a0326). I'm not convinced that small quirks of using "hg log" are important at this point. Also, you could try other options of "hg log" such as "--follow". If we called ex-trunk the same name as ex-py3k ("default"), things would probably be quite more confusing, since inspecting a changeset wouldn't tell you immediately where it comes from (2.x or 3.x development). Regards Antoine. From robertc at robertcollins.net Sat Feb 26 19:48:29 2011 From: robertc at robertcollins.net (Robert Collins) Date: Sun, 27 Feb 2011 07:48:29 +1300 Subject: [Python-Dev] Why does TemporaryDirectory not wait for `__enter__`? In-Reply-To: References: Message-ID: On Sun, Feb 27, 2011 at 3:45 AM, cool-RR wrote: > I think that if someone calls `__enter__` directly, he takes the > responsibility of calling `__exit__`, so we don't really have to help him > with `__del__`. > But other than that I understand the motivation for making it start on > `__init__` rather then `__enter__`. I'll just make my own version of it that > will work on `__enter__` instead. > Thanks, > Ram. TempDir from 'fixtures' (http://pypi.python.org/pypi/fixtures) will do what you want - __enter__ creates the directory, __exit__ deletes it. Cheers, Rob From stutzbach at google.com Sat Feb 26 19:40:03 2011 From: stutzbach at google.com (Daniel Stutzbach) Date: Sat, 26 Feb 2011 10:40:03 -0800 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <1298742940.3704.17.camel@localhost.localdomain> References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> <4D693A02.4000104@v.loewis.de> <1298742940.3704.17.camel@localhost.localdomain> Message-ID: On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou wrote: > There is no such thing as an "unnamed branch". What would "hg branches" > show? An empty space? > I understand now why I was confused. I had previously read the sentence "Both Git and Mercurial support unnamed local branches." at http://mercurial.selenic.com/wiki/BranchingExplained But as I dig deeper, I see that there is only one unnamed branch, and it actually does have an implicit name: "default". It appears Mercurial supports at least three different kinds of branching: cloning (similar to Bazaar), bookmarks (similar to git), and named branches. So a named branch can contain more than one branch. Were there reasons for going with named branches over bookmarks? PEP 385 discusses only cloning and named branches. I'm just curious, not trying to start a long discussion. :-) -- Daniel Stutzbach -------------- next part -------------- An HTML attachment was scrubbed... URL: From santoso.wijaya at gmail.com Sat Feb 26 19:54:00 2011 From: santoso.wijaya at gmail.com (Santoso Wijaya) Date: Sat, 26 Feb 2011 10:54:00 -0800 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110226132310.3dc2da5f@limelight.wooz.org> References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> <4D693911.4000004@netwok.org> <20110226132310.3dc2da5f@limelight.wooz.org> Message-ID: A Mercurial 'merge' is simply a creation of another changeset, which has two parents: the current tip of the branch you're working on, and the changeset you are merging with. ~/santa On Sat, Feb 26, 2011 at 10:23 AM, Barry Warsaw wrote: > On Feb 26, 2011, at 06:32 PM, ?ric Araujo wrote: > > >>> Named branches are exclusive, they can't be a subset of each other ;) > > > >Actually, they can. Take the example of the Mercurial repo itself. They > >fix bugs in the stable branch and add features in default. When they > >merge stable into default and commit, default becomes a superset of > >stable. That is to say, someone pulling default also gets the > >changesets from stable that are ancestors of the merge changset. Or in > >other words, if you check out default, you get all bug fixes from stable. > > That makes sense, but correct me if I'm wrong, it's the 'merge' operation > that > made this happen, right? A merge essentially brings the changesets from > one > branch into another. > > -Barry > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/santoso.wijaya%40gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From santoso.wijaya at gmail.com Sat Feb 26 19:56:59 2011 From: santoso.wijaya at gmail.com (Santoso Wijaya) Date: Sat, 26 Feb 2011 10:56:59 -0800 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> <4D693A02.4000104@v.loewis.de> <1298742940.3704.17.camel@localhost.localdomain> Message-ID: >From http://mercurial.selenic.com/wiki/Branch#Named_branches: [...] a good rule of thumb is to use branch names sparingly and for rather longer lived concepts like "release branches" (rel-1, rel-2, etc) and rather not for short lived work of single developers So I think named branches make sense here. Bookmarks are really for potential branches, experimental features, for example, for easier navigation for the developer's convenience. Named branches, on the other hand, are better for posterity reasons. ~/santa On Sat, Feb 26, 2011 at 10:40 AM, Daniel Stutzbach wrote: > On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou wrote: > >> There is no such thing as an "unnamed branch". What would "hg branches" >> show? An empty space? >> > > I understand now why I was confused. I had previously read the sentence > "Both Git and Mercurial support unnamed local branches." at > http://mercurial.selenic.com/wiki/BranchingExplained > > But as I dig deeper, I see that there is only one unnamed branch, and it > actually does have an implicit name: "default". > > It appears Mercurial supports at least three different kinds of branching: > cloning (similar to Bazaar), bookmarks (similar to git), and named branches. > So a named branch can contain more than one branch. > > Were there reasons for going with named branches over bookmarks? PEP 385 > discusses only cloning and named branches. I'm just curious, not trying to > start a long discussion. :-) > > -- > Daniel Stutzbach > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/santoso.wijaya%40gmail.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdmurray at bitdance.com Sat Feb 26 20:05:18 2011 From: rdmurray at bitdance.com (R. David Murray) Date: Sat, 26 Feb 2011 14:05:18 -0500 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110226130847.05daf511@limelight.wooz.org> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> <20110226130847.05daf511@limelight.wooz.org> Message-ID: <20110226190518.37F381FF8A4@kimball.webabinitio.net> On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw wrote: > $ cd py27 # now I want to synchronize > $ hg pull -u ssh://hg at hg.python.org/cpython > > but I'm not going to remember that url every time. It wouldn't be so bad if > Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does. How does setting it in the hgrc differ from "remebering" it? I've never been comfortable with the bzr --remember option because I'm never sure what it is remembering. Much easier for me to see it in a config file. But, then, that's how my brain works, and other people's will work differently. > On Feb 26, 2011, at 01:49 AM, ??ric Araujo wrote: > >Anecdote: I migrated from Subversion to Mercurial a few years ago, and > >found Mercurial branches very intuitive. When I saw mentions of Bazaar > >branches I was driven nuts by (what I saw as) the conflation between a > >branch and a clone. Later I understood how it made sense from the > >perspective of Bazaar, so I shifted my judgment from ???insanely > >confusing??? to ???a particular choice that I don???t approve??? . > > That's funny because to my eyes, Mercurial conflates "branches" and "clones". > Why a clone operation should give me the history for all lines-of-development > inside a working directory for one "arbitrary" one strikes me as bizarre > (pardon the pun :). I get that for folks who like the "svn switch" method of > working on multiple LoDs, this probably makes a lot of sense. I don't > personally like or trust that approach much though. I agree with you that I don't trust the 'svn switch' style. I also find it slow. However.... > >That pull does not update is a feature: The operation between a remote > >repo and the local repo (the .hg directory) is separate from the > >operation from the local repo to the working directory. When you know > >that you want pull + update (like when you have a clean working > >directory), you use ???hg pull -u???. (I don???t like the fetch command.) > > Sure, I get that. Again, this feature appears odd because I have the full > history of all LoDs embedded in a working directory of a single LoD. With the > arrangement I outlined above (which is independent of the dVCS backing it), it > makes no sense for each LoD working directory to contain all the history of > all the other LoDs. > > In Bazaar, a "branch" is an independent LoD and it's "repository" contains > only its own history. Sure, it might have identical history with other LoDs > up to the point of divergence, and I have ways to efficiently share that > history across multiple LoD working directories, but they are still separate > and I don't need them if I don't care about them. With Mercurial, all history > for all LoDs in a repository always come along for the ride. I find bazaar's model confusing, and hg's intuitive, just like ??ric. And consider that I learned bazaar before mercurial. To me, it makes perfect sense that in a DVCS the "unit" is a directory containing a repository and a working copy, and that the repository is *the* repository. That is, it has everything related to the project in it, just like the master SVN repository does (plus, since it is a DVCS, whatever I've committed locally but not pushed to the master). To have a repository that only has some of the stuff in it is, IMO, confusing. I advocated for having all the Python history in one repo partly for that reason. I can intellectually see your point about not really *needing* the stuff for the LODs if you are only working on LOD X, but just like 'svn switch' makes me uncomfortable, I'm just not *comfortable* not having the whole repo in there :) As an example, with mercurial, I feel comfortable moving directories around and renaming them (with the help of google it took me about 1 minute to figure out how to keep the association between the repository instances intact). With bazaar I got in trouble trying to do that, because the interrelationship between the working copy directories (and their subsets of the repo?) and the master repo(?) was not clear. I never did figure out how to make it work, I ended up starting over with a new clone. Now, as I get farther into learning mercurial I may well find things that are just as confusing as I found that aspect of bazaar, but at least I am comfortable with the outermost layer: the repo is the repo is the repo. -- R. David Murray www.bitdance.com From solipsis at pitrou.net Sat Feb 26 20:29:12 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 26 Feb 2011 20:29:12 +0100 Subject: [Python-Dev] of branches and heads In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> <4D693A02.4000104@v.loewis.de> <1298742940.3704.17.camel@localhost.localdomain> Message-ID: <20110226202912.7d4813ba@pitrou.net> On Sat, 26 Feb 2011 10:40:03 -0800 Daniel Stutzbach wrote: > On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou wrote: > > > There is no such thing as an "unnamed branch". What would "hg branches" > > show? An empty space? > > I understand now why I was confused. I had previously read the sentence > "Both Git and Mercurial support unnamed local branches." at > http://mercurial.selenic.com/wiki/BranchingExplained > > But as I dig deeper, I see that there is only one unnamed branch, and it > actually does have an implicit name: "default". Ok, so beware, the term "branch" can conflate two concepts: - a path in the topology (or line of development) - a "named branch" in hg terminology So, actually, hg promotes a slightly different terminology: - a "head" is a changeset without a child in the topology - a "branch" usually means a "named branch": a set of changesets bearing the same label (e.g. "default"); that label is freely chosen by the committer at any point, and enforces no topological characteristic (even though in practice it will have, since it's the whole point from the user's perspective, and also because hg's default behaviour and concept of a "current branch" encourages it) A (named) branch can have zero, one, or several heads: - zero head: if all branch-local heads have a child in another named branch (for example, "trunk" is linearly followed by "2.7") - several heads: if several lines of development were started in this branch without bothering to give them separate names When you have several heads on a branch, you can merge them together if you want to reconcile the lines of development they represent. When you have several branches with at least one head each, you can also merge them together: you must be careful to choose which named branch the merge changeset will be part of (for example, if you want to merge "3.1" into "3.2", you will certainly want the merge changeset to be part of "3.2", otherwise "3.1" will get a lot of unwanted features ;-)). Note: a branch with zero head is marked "inactive" in "hg branches". This basically means that it has already been merged in another branch. (of course, you can still develop in that branch, which will certainly create a new head as soon as you commit your first new changeset) Regards Antoine. From solipsis at pitrou.net Sat Feb 26 20:30:41 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 26 Feb 2011 20:30:41 +0100 Subject: [Python-Dev] pymigr: Ask for hgeol-checking hook. In-Reply-To: <4D694535.6070207@v.loewis.de> References: <20110226185402.14b66d79@pitrou.net> <4D6940FE.509@v.loewis.de> <1298744009.3704.25.camel@localhost.localdomain> <4D694535.6070207@v.loewis.de> Message-ID: <20110226203041.79e378c4@pitrou.net> Martin, I have now enabled the eol hook on the test repo (a quick test seemed to show it works). Could you test again? Regards Antoine. On Sat, 26 Feb 2011 19:23:49 +0100 "Martin v. L?wis" wrote: > Am 26.02.2011 19:13, schrieb Antoine Pitrou: > > > >> In Mercurial, it's just a hook, and optional. So we can't be sure all > >> users use it correctly - and in my (limited) experience with Mercurial, > >> chances are high that users will make mistakes in that respect (i.e. > >> in one out of one cross-platform projects, a committer had issues > >> with CRLF, leading to catastrophic repository corruption). > > > > ?Catastrophic? repository ?corruption?? This sounds very strongly like > > an urban legend. > > Perhaps some files had later to be fixed. But that shouldn't be out of > > the realm of normal Mercurial commands (aka "edit file to fix endings, > > then hg commit and hg push"). > > It actually happened to me, so please trust me that it's not a legend. > Yes, I could fix it with hg commands, and a lot of text editing. > It took me a day, I considered the repository corrupted so that I > actually had to branch from the last ok revision, and redo all checkins > since (I also discarded changes which I didn't chose to redo). It was > a real catastrophe to me. > > Since the changes actually changed all lines, "hg blame" became useless, > which was unacceptable. > > Regards, > Martin From brett at python.org Sat Feb 26 20:45:36 2011 From: brett at python.org (Brett Cannon) Date: Sat, 26 Feb 2011 11:45:36 -0800 Subject: [Python-Dev] r88589 - python/branches/py3k/Lib/test/test_logging.py In-Reply-To: <20110225232456.0be6176a@pitrou.net> References: <20110225170243.CC07AEE9BD@mail.python.org> <20110225232456.0be6176a@pitrou.net> Message-ID: And if it gets disabled again it should be a skipped test instead of a commented-out test to better keep track that it's turned off. On Fri, Feb 25, 2011 at 14:24, Antoine Pitrou wrote: > On Fri, 25 Feb 2011 18:02:43 +0100 (CET) > vinay.sajip wrote: > > Author: vinay.sajip > > Date: Fri Feb 25 18:02:43 2011 > > New Revision: 88589 > > > > Log: > > logging: enabled test which was intermittently failing on buildbots. > > > Looks like it fails again: > > ( > http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2671/steps/test/logs/stdio) > > ====================================================================== > ERROR: test_compute_rollover_MIDNIGHT > (test.test_logging.TimedRotatingFileHandlerTest) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", > line 1990, in tearDown > os.unlink(self.fn) > WindowsError: [Error 32] The process cannot access the file because it is > being used by another process: > 'c:\\users\\db3l\\appdata\\local\\temp\\test_logging-2-vhc3k5.log' > > ====================================================================== > FAIL: test_compute_rollover_MIDNIGHT > (test.test_logging.TimedRotatingFileHandlerTest) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", > line 2053, in test_compute_rollover > self.assertEqual(exp, rh.computeRollover(0.0)) > AssertionError: 82800 != 18000.0 > > ====================================================================== > FAIL: test_compute_rollover_S > (test.test_logging.TimedRotatingFileHandlerTest) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", > line 1981, in setUp > BaseTest.setUp(self) > File > "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", > line 95, in setUp > raise AssertionError('Unexpected handlers: %s' % hlist) > AssertionError: Unexpected handlers: [ 0x0DAFC5B0>] > > ====================================================================== > FAIL: test_compute_rollover_W0 > (test.test_logging.TimedRotatingFileHandlerTest) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", > line 1981, in setUp > BaseTest.setUp(self) > File > "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py", > line 95, in setUp > raise AssertionError('Unexpected handlers: %s' % hlist) > AssertionError: Unexpected handlers: [ 0x0DAFC5B0>] > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Sat Feb 26 20:56:18 2011 From: brett at python.org (Brett Cannon) Date: Sat, 26 Feb 2011 11:56:18 -0800 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110225164600.415f8e04@limelight.wooz.org> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D680B3C.4040209@freehackers.org> <20110225164600.415f8e04@limelight.wooz.org> Message-ID: On Fri, Feb 25, 2011 at 13:46, Barry Warsaw wrote: > On Feb 25, 2011, at 09:04 PM, Philippe Fremy wrote: > > >What you are asking for is available in TortoiseHg which absolutely > >rocks (if you are not allergic to the idea of a graphical tool). > > Like shellfish, bee-strings, and Perl I'm afraid. :) > > >You can even select indvidually inside a file which lines to commit or > >not. A bit risky but very handy when you have a few oneliners to commit > >or not to commit. > > You mean, TortoiseHg supports incremental commits on a single file? That's > kind of neat, but scary. ;) > The record extension lets regular Mercurial do that as well. I think git supports a similar thing. -Brett > > -Barry > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Sat Feb 26 21:09:58 2011 From: brett at python.org (Brett Cannon) Date: Sat, 26 Feb 2011 12:09:58 -0800 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110226130847.05daf511@limelight.wooz.org> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> <20110226130847.05daf511@limelight.wooz.org> Message-ID: On Sat, Feb 26, 2011 at 10:08, Barry Warsaw wrote: > On Feb 26, 2011, at 01:49 AM, ?ric Araujo wrote: > > >Le 25/02/2011 20:43, Barry Warsaw a ?crit : > >> On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: > >> [snip] > >>> Note that each of these branch clones will initially have your local > >>> master repo as the default path [3,4]. If you'd like to have the > default > >>> push/pull path to point to ssh://hg at hg.python.org/cpython instead, > you'd > >>> want to edit the [paths] section in the .hg/hgrc file in each of the > >>> branch repos. > > > >I plan on having one clone per branch but pushing and pulling from only > >one repository, so I don?t need to edit hgrcs. > > So let's start from the basics. I want separate working directories for > each > active line-of-development (I'll use that term instead of "branch"), > e.g. working directories containing the tip of the 2.6 LoD, 2.7, 3.1, 3.2, > and > 3.3. I will not be doing feature or bug development in any of these > directories. They are purely for local tracking of the remote masters. > Thus, > I want to be able to synchronize any one of those LoDs against the remote > master with one command, like I would using Subversion's 'svn up'. > For other people's benefit, LoD == line of development (I think). > > I clone the remote repository using the command in the devguide, so I now > have > a 'cpython' directory containing the history of all LoDs, but with a > working > directory that reflects the 'default' LoD. Now, in the parent of > 'cpython', I > do the following to get my separate-directory-LoDs: > > $ hg clone -u 2.6 cpython py26 > $ hg clone -u 2.7 cpython py27 > # repeat and rinse for all other active LoDs > > That's one way of doing it. > (Aside: that cpython directory still bugs me. It doesn't naturally reflect > a > LoD, so why do I have to stare at it? Yes, I can make it play double duty > by > naming it "3.3" or whatever and updating it to the 3.3 LoD, but that feels > artificial.) > It's a clone repository of CPython; the name makes perfect sense. You are focusing on what the repository happens to be updated to ATM, not the fact that the repository itself represents any and all LoDs. > > Now I want to synchronize my local py27 directory with the state of that > LoD > on python.org. This is a two step process: > > $ cd py27 # now I want to synchronize > $ (cd ../cpython && hg pull) > $ hg pull -u > > Editing hgrc to point to hg.python.org means the sync-to-remote-master > operation is one command. > > I could do this: > > $ cd py27 # now I want to synchronize > $ hg pull -u ssh://hg at hg.python.org/cpython > > but I'm not going to remember that url every time. It wouldn't be so bad > if > Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar > does. > So does Hg: simply edit your .hgrc to have it both pull and push to the same URL. Or you can save yourself some trouble, and simply clone the repository at a specific branch: hg clone ssh://hg at hg.python.org/cpython#2.7 I believe that might even strip out other history outside the scope of the branch. > > >Anecdote: I migrated from Subversion to Mercurial a few years ago, and > >found Mercurial branches very intuitive. When I saw mentions of Bazaar > >branches I was driven nuts by (what I saw as) the conflation between a > >branch and a clone. Later I understood how it made sense from the > >perspective of Bazaar, so I shifted my judgment from ?insanely > >confusing? to ?a particular choice that I don?t approve? . > > That's funny because to my eyes, Mercurial conflates "branches" and > "clones". > Why a clone operation should give me the history for all > lines-of-development > inside a working directory for one "arbitrary" one strikes me as bizarre > (pardon the pun :). Because Hg views a clone as that: a clone of the entire repository. A branch just happens to be a part of the repository. And because it is the entire repository it has to have you point somewhere, so it goes with default since a lot of people never even work somewhere other than on default. > I get that for folks who like the "svn switch" method of > working on multiple LoDs, this probably makes a lot of sense. I don't > personally like or trust that approach much though. > Neither do I in an svn context and why Hg does let you check out just a branch and have all pulls and pushes only go to that branch. > > >What I?m saying is that a lot of Bazaar terminology using ?branch? does > >not map as-is to Mercurial. We clone a repo, we pull from a repo/clone, > >we have named branches (e.g. 3.2) in a repo, we have unnamed branches on > >one named branch. I think you know that already, since you went from > >using Bazaar terms applied to Mercurial to mixing terms from both > >(?clone a new branch working directory? ? ?clone a repo?, probably). I > >salute your willingness to learn Mercurial, considering how fluent (and > >fluffly) you appear to be with Bazaar. > > This is an inevitable problem with trying to converse fluently about three > major dVCSs and at least one or two other non-dVCSs. They all use the same > words to mean vaguely similar things, but quickly get bogged down in the > implementation details assigned to those words. It all makes perfect sense > when you've been immersed in those technologies, but it makes discussions > and > comparisons exceedingly difficult. I've no doubt it's doubly painful to > many > people who have no prior experience with a dVCS. > > (Aside: Bazaar could have potentially eased these folks transition because > you > can use Bazaar just like you would Subversion - as a centralized VCS -- > without stopping others from using it with full dVCS features on the same > code > base. I don't know if Mercurial offers the same flexibility.) > > It's a little like trying to teach Python to a Java programmer. "Object", > "Class", "Instance", "Import" all mean roughly similar things, which lulls > you > into a false sense of understanding. We learn by holding up the new to the > light of the familiar and looking for interference patterns. :) > Yes, fun isn't it? Makes me that much more glad I don't have to care about other DVCSs anymore; make the decision of which one to go through was painful partially for this reason. > > >> I'll have to remember that 'hg pull' does not update the working copy by > >> default, > > > >That pull does not update is a feature: The operation between a remote > >repo and the local repo (the .hg directory) is separate from the > >operation from the local repo to the working directory. When you know > >that you want pull + update (like when you have a clean working > >directory), you use ?hg pull -u?. (I don?t like the fetch command.) > > Sure, I get that. Again, this feature appears odd because I have the full > history of all LoDs embedded in a working directory of a single LoD. Not single, _current_. I know you don't like the whole svn switch approach that this is like, but Hg is very much about "don't forget a thing", which is why you need to view a clone as a clone repository that you are choosing to view in a certain way at any moment in time instead of as a single branch that just happens to be carrying around the weight of other branches. Totally different approaches to VCS. > With the > arrangement I outlined above (which is independent of the dVCS backing it), > it > makes no sense for each LoD working directory to contain all the history of > all the other LoDs. > As I said above, use the # format and you skip this issue (I think). > > In Bazaar, a "branch" is an independent LoD and it's "repository" contains > only its own history. Sure, it might have identical history with other > LoDs > up to the point of divergence, and I have ways to efficiently share that > history across multiple LoD working directories, but they are still > separate > and I don't need them if I don't care about them. With Mercurial, all > history > for all LoDs in a repository always come along for the ride. > > >You speak to my heart, sir. In your ~/.hgrc, under the section [ui], > >set ?editor = path/to/mercurial/source/hgeditor? and enjoy your diffs. > >I use it and love it. > > Great, I'll try that, thanks. One thing Mercurial and Bazaar definitely > share > is a wealth of magical awesomeness hidden in manpages, wiki pages, mailing > list posts, people's heads, configuration files, and source code. :) > > >If you want to commit a subset of your local changes, I use > >http://mercurial.selenic.com/wiki/CrecordExtension , a curses-based diff > >selection UI that works like a charm. > > I very rarely want to do that. It's more common (but still, IME not *that* > common) to commit the changes to just a few files at a time. One thing > Bazaar > has that's very nice is the ability to "shelve" some changes for a time. > Let's say I'm working on a bug and I want to merge your changes in or sync > to > the master. I can shelve some or all of my uncommitted changes, which > saves > them essentially out-of-the-way patch files, and then reverts my > uncommitted > changes. Unshelving then is the process of re-applying those patch files, > and > yes, resolving conflicts. > Hg's is the mq (Mercurial Queue) extension. > > This is also a great way to work when you want to do > test-driven-development > but need to do some exploration first. You can hack around non-TDD until > you're confident of your approach, shelve all your changes, then > incrementally > apply them back as you write each test. I'm sure Mercurial has something > equally awesome lurking about. :) They all have the same history from the Linux kernel for the patch queue concept. I suspect it's pretty universally implemented, just with different command names (of course as gods forbid it be consistent). -------------- next part -------------- An HTML attachment was scrubbed... URL: From timothy.c.delaney at gmail.com Sat Feb 26 21:25:51 2011 From: timothy.c.delaney at gmail.com (Tim Delaney) Date: Sun, 27 Feb 2011 07:25:51 +1100 Subject: [Python-Dev] [Python-checkins] cpython (trunk): Close the "trunk" branch. In-Reply-To: <4D6923FF.9050204@v.loewis.de> References: <4D68CD42.5050005@v.loewis.de> <20110226110612.2766c0da@pitrou.net> <4D6923FF.9050204@v.loewis.de> Message-ID: On 27 February 2011 03:02, "Martin v. L?wis" wrote: > > Committing reopened it > > So what's the point of closing it, then? What effect does that > achieve? http://stackoverflow.com/questions/4099345/is-it-possible-to-reopen-a-closed-branch-in-mercurial/4101279#4101279 The closed flag is just used to filter out closed branches from hg branches and hg heads unless you use the --closed option - it doesn't prevent you from using the branches. Basically, it reduces the noise, especially if you have very branchy development like I personally prefer (a named branch per task/issue). If you only use anonymous branches, except for your feature branches (e.g. 3.2, 2.7) then you'd probably never close a branch. Tim Delaney -------------- next part -------------- An HTML attachment was scrubbed... URL: From timothy.c.delaney at gmail.com Sat Feb 26 21:32:05 2011 From: timothy.c.delaney at gmail.com (Tim Delaney) Date: Sun, 27 Feb 2011 07:32:05 +1100 Subject: [Python-Dev] [Python-checkins] cpython: improve license In-Reply-To: <20110226131225.2f310fc4@limelight.wooz.org> References: <20110226131225.2f310fc4@limelight.wooz.org> Message-ID: On 27 February 2011 05:12, Barry Warsaw wrote: > I guess it's possible for change notifications to encompass multiple named > branches though, right? I'm not sure what to do about that, but it seems > like > a less common use case. > Are the change notifications per-commit? If so, there's no way that a single change notification could be for more than one named branch. If the notifications are per-pull/per-push, then yes it could be for multiple branches. In either case, it should definitely be possible to put the name(s) of the branches in the change notifications - in either type of hook you can inspect the changesets and determine what branch they are on. Tim Delaney -------------- next part -------------- An HTML attachment was scrubbed... URL: From timothy.c.delaney at gmail.com Sat Feb 26 21:43:36 2011 From: timothy.c.delaney at gmail.com (Tim Delaney) Date: Sun, 27 Feb 2011 07:43:36 +1100 Subject: [Python-Dev] pymigr: Ask for hgeol-checking hook. In-Reply-To: <4D694535.6070207@v.loewis.de> References: <20110226185402.14b66d79@pitrou.net> <4D6940FE.509@v.loewis.de> <1298744009.3704.25.camel@localhost.localdomain> <4D694535.6070207@v.loewis.de> Message-ID: On 27 February 2011 05:23, "Martin v. L?wis" wrote: > It actually happened to me, so please trust me that it's not a legend. > Yes, I could fix it with hg commands, and a lot of text editing. > It took me a day, I considered the repository corrupted so that I > actually had to branch from the last ok revision, and redo all checkins > since (I also discarded changes which I didn't chose to redo). It was > a real catastrophe to me. > > Since the changes actually changed all lines, "hg blame" became useless, > which was unacceptable. > I'd disagree that that is catastrophic repository corruption - it's fixable by creating a new clone from before the "corruption", discarding the old one and redoing the changes (possibly via cherry-picking). Catastrophic corruption of a mercurial repository happens when the history itself becomes corrupted. This should never happen under normal usage, but it is possible to happen if you commit using an older version of hg to a repo that's been created (or modified) by a newer version. You can pull from a newer version repo using the older version, but you shouldn't ever commit to it (including pushing) except through the "remote" interfaces (where the remote hg is the one doing the actual commits). Tim Delaney -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Sat Feb 26 21:49:39 2011 From: barry at python.org (Barry Warsaw) Date: Sat, 26 Feb 2011 15:49:39 -0500 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <4D684E2A.90005@netwok.org> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> Message-ID: <20110226154939.41972d08@limelight.wooz.org> On Feb 26, 2011, at 01:49 AM, ?ric Araujo wrote: >You speak to my heart, sir. In your ~/.hgrc, under the section [ui], >set ?editor = path/to/mercurial/source/hgeditor? and enjoy your diffs. >I use it and love it. Except it doesn't quite work the way I want it to (hg 1.6.3). It opens your editor with two files, one is the commit message and the other is the diff. (The script itself is a bit buggy too. ;) But it's a good clue, and I've modified the default hgeditor script to get closer, and fix the bug I noticed. I basically append the diff to the temporary log message file. It's still not right though because if the diff lines aren't prepended with 'HG:', they end up in the commit message. Arg. Oh well, I can clearly hack a more complicated script together. It's such a blindingly obvious improvement, it's too bad 'hg commit' doesn't DTRT by default. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From timothy.c.delaney at gmail.com Sat Feb 26 21:49:55 2011 From: timothy.c.delaney at gmail.com (Tim Delaney) Date: Sun, 27 Feb 2011 07:49:55 +1100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> Message-ID: On 27 February 2011 01:40, Nick Coghlan wrote: > On Sat, Feb 26, 2011 at 4:34 PM, Georg Brandl wrote: > >> Would it be possible to name "trunk" as "2.x" instead? Otherwise I > >> could see people getting confused and asking why trunk was closed, > >> and/or not the same as "default". > > > > Problem is, you then have 1.5.2 released from the 2.x branch :) > > In that case, "legacy-trunk" would seem clearer. +1 Exactly what I was about to suggest. Tim Delaney -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Sat Feb 26 22:06:45 2011 From: barry at python.org (Barry Warsaw) Date: Sat, 26 Feb 2011 16:06:45 -0500 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110226190518.37F381FF8A4@kimball.webabinitio.net> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> <20110226130847.05daf511@limelight.wooz.org> <20110226190518.37F381FF8A4@kimball.webabinitio.net> Message-ID: <20110226160645.5c5d28e6@limelight.wooz.org> On Feb 26, 2011, at 02:05 PM, R. David Murray wrote: >On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw wrote: >> $ cd py27 # now I want to synchronize >> $ hg pull -u ssh://hg at hg.python.org/cpython >> >> but I'm not going to remember that url every time. It wouldn't be so bad if >> Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does. > >How does setting it in the hgrc differ from "remebering" it? It's different because you don't use a familiar interface to set it (i.e hg). You have to know to hack a file to make it work. That's not awesome user interface. ;) >I've never been comfortable with the bzr --remember option because I'm never >sure what it is remembering. Much easier for me to see it in a config file. >But, then, that's how my brain works, and other people's will work >differently. It's easy to tell what it remembers because it's exactly what you told it to remember ;). But I guess you're talking about push and pull automatically remembering the location when none was previously set. I love that feature. And of course, bzr 'remembers' by setting a value in a config file, which of course you *could* hack if you wanted to. It's just that you don't normally have to open your editor and remember which value in which config file you have to manually modify to set the push and pull locations. I think that's a win, but YMMV. :) Oh, and 'bzr info' always tells you what the push and pull locations are. >I find bazaar's model confusing, and hg's intuitive, just like ??ric. >And consider that I learned bazaar before mercurial. To me, it makes >perfect sense that in a DVCS the "unit" is a directory containing >a repository and a working copy, and that the repository is *the* >repository. That is, it has everything related to the project in it, >just like the master SVN repository does (plus, since it is a DVCS, >whatever I've committed locally but not pushed to the master). To have >a repository that only has some of the stuff in it is, IMO, confusing. >I advocated for having all the Python history in one repo partly for >that reason. I would feel better about Mercurial's if the repo where not intimately tied with a default working tree (yes, I know -U). In a sense, that's what Bazaar's shared repositories are: a place where all your history goes. In Bazaar's model though, it's not tied to a specific working tree, and it's hidden in a dot-directory. It's still kind of beside the point - this is the way Mercurial works, and I don't really mean this thread to be an in-depth comparison between the two. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From solipsis at pitrou.net Sat Feb 26 22:20:04 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 26 Feb 2011 22:20:04 +0100 Subject: [Python-Dev] Mercurial conversion repositories References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> <20110226130847.05daf511@limelight.wooz.org> <20110226190518.37F381FF8A4@kimball.webabinitio.net> <20110226160645.5c5d28e6@limelight.wooz.org> Message-ID: <20110226222004.1d9e0596@pitrou.net> On Sat, 26 Feb 2011 16:06:45 -0500 Barry Warsaw wrote: > > >I find bazaar's model confusing, and hg's intuitive, just like ??ric. > >And consider that I learned bazaar before mercurial. To me, it makes > >perfect sense that in a DVCS the "unit" is a directory containing > >a repository and a working copy, and that the repository is *the* > >repository. That is, it has everything related to the project in it, > >just like the master SVN repository does (plus, since it is a DVCS, > >whatever I've committed locally but not pushed to the master). To have > >a repository that only has some of the stuff in it is, IMO, confusing. > >I advocated for having all the Python history in one repo partly for > >that reason. > > I would feel better about Mercurial's if the repo where not intimately tied > with a default working tree (yes, I know -U). In a sense, that's what > Bazaar's shared repositories are: a place where all your history goes. In > Bazaar's model though, it's not tied to a specific working tree, and it's > hidden in a dot-directory. Often (but not always), when you're wanting to do something, there's an extension for Mercurial which can be enabled ;) http://mercurial.selenic.com/wiki/ShareExtension Regards Antoine. From grigory.javadyan at gmail.com Sat Feb 26 22:23:16 2011 From: grigory.javadyan at gmail.com (Grigory Javadyan) Date: Sun, 27 Feb 2011 01:23:16 +0400 Subject: [Python-Dev] Unbinding a name referenced by an enclosing scope - error in documentation? Message-ID: Hi, guys I'm not sure if python-dev is the right place to write to, but I'm really curious about this: >From the Python Language reference: > It is illegal to unbind a name referenced by an enclosing scope; the compiler will report a SyntaxError. But when I run the following code: a = 3 def x(): global a del(a) print(a) x() it works fine; and when I change the order of calls: x() print(a) I get a NameError, not a SyntaxError. Now I asked the same question on python-list and people suggested that the true meaning of that rule is: >>> def f(): ... a = 42 ... def g(): ... nonlocal a ... del a ... SyntaxError: can not delete variable 'a' referenced in nested scope Which looks weird, because the name is referenced in the _enclosed_ scope, not the _enclosing_ scope. Is there a typo in the documentation or am I missing something? From barry at python.org Sat Feb 26 22:30:47 2011 From: barry at python.org (Barry Warsaw) Date: Sat, 26 Feb 2011 16:30:47 -0500 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> <20110226130847.05daf511@limelight.wooz.org> Message-ID: <20110226163047.66140688@limelight.wooz.org> On Feb 26, 2011, at 12:09 PM, Brett Cannon wrote: >For other people's benefit, LoD == line of development (I think). Yes. It's just a word that isn't intimately tied to the implementation details of a specific dVCS. >> I clone the remote repository using the command in the devguide, so I now >> have >> a 'cpython' directory containing the history of all LoDs, but with a >> working >> directory that reflects the 'default' LoD. Now, in the parent of >> 'cpython', I >> do the following to get my separate-directory-LoDs: >> >> $ hg clone -u 2.6 cpython py26 >> $ hg clone -u 2.7 cpython py27 >> # repeat and rinse for all other active LoDs >> >> >That's one way of doing it. I'm sure there are many different ways of setting things up. I am totally in favor of the devguide documenting and encouraging one particular way, and I'm sure Mercurial will prove to be a flexible tool that can conform to user's preferences rather than the other way 'round. >> (Aside: that cpython directory still bugs me. It doesn't naturally reflect >> a >> LoD, so why do I have to stare at it? Yes, I can make it play double duty >> by >> naming it "3.3" or whatever and updating it to the 3.3 LoD, but that feels >> artificial.) >> >It's a clone repository of CPython; the name makes perfect sense. You are >focusing on what the repository happens to be updated to ATM, not the fact >that the repository itself represents any and all LoDs. No, I get all that. I'm just not sure why I should care where all the history is stored. I'm not actually going to do any coding in the cpython directory, so it just seems like a wart I have to carry around. But as I said before, this is the Mercurial Way, so be it. >> Now I want to synchronize my local py27 directory with the state of that >> LoD >> on python.org. This is a two step process: >> >> $ cd py27 # now I want to synchronize >> $ (cd ../cpython && hg pull) >> $ hg pull -u >> >> Editing hgrc to point to hg.python.org means the sync-to-remote-master >> operation is one command. >> >> I could do this: >> >> $ cd py27 # now I want to synchronize >> $ hg pull -u ssh://hg at hg.python.org/cpython >> >> but I'm not going to remember that url every time. It wouldn't be so bad >> if >> Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar >> does. >> > >So does Hg: simply edit your .hgrc to have it both pull and push to the same >URL. Right, see my follow up to RDM. >Or you can save yourself some trouble, and simply clone the repository at a >specific branch: > > hg clone ssh://hg at hg.python.org/cpython#2.7 > >I believe that might even strip out other history outside the scope of the >branch. That might be a better way if it doesn't slurp down the entire repository history. >> >Anecdote: I migrated from Subversion to Mercurial a few years ago, and >> >found Mercurial branches very intuitive. When I saw mentions of Bazaar >> >branches I was driven nuts by (what I saw as) the conflation between a >> >branch and a clone. Later I understood how it made sense from the >> >perspective of Bazaar, so I shifted my judgment from ?insanely >> >confusing? to ?a particular choice that I don?t approve? . >> >> That's funny because to my eyes, Mercurial conflates "branches" and >> "clones". >> Why a clone operation should give me the history for all >> lines-of-development >> inside a working directory for one "arbitrary" one strikes me as bizarre >> (pardon the pun :). > >Because Hg views a clone as that: a clone of the entire repository. A branch >just happens to be a part of the repository. And because it is the entire >repository it has to have you point somewhere, so it goes with default since >a lot of people never even work somewhere other than on default. Yep, I get all that. It's Mercurial's model of the world. >Yes, fun isn't it? Makes me that much more glad I don't have to care about >other DVCSs anymore; make the decision of which one to go through was >painful partially for this reason. Lucky you! I interact with tons of projects, so I still have to deal with everything from CVS to git. This will be my first serious foray into hg, and for that I'm glad. And really, *any* dVCS is better than a non-dVCS, so I'm really happy this is finally happening, despite any initial grumbling you're reading into my posts. :) >> >> I'll have to remember that 'hg pull' does not update the working copy by >> >> default, >> > >> >That pull does not update is a feature: The operation between a remote >> >repo and the local repo (the .hg directory) is separate from the >> >operation from the local repo to the working directory. When you know >> >that you want pull + update (like when you have a clean working >> >directory), you use ?hg pull -u?. (I don?t like the fetch command.) >> >> Sure, I get that. Again, this feature appears odd because I have the full >> history of all LoDs embedded in a working directory of a single LoD. > >Not single, _current_. I know you don't like the whole svn switch approach >that this is like, but Hg is very much about "don't forget a thing", which >is why you need to view a clone as a clone repository that you are choosing >to view in a certain way at any moment in time instead of as a single branch >that just happens to be carrying around the weight of other branches. >Totally different approaches to VCS. No really, I do get all that! I just don't like it much. Maybe it'll grow on me though. >> I very rarely want to do that. It's more common (but still, IME not *that* >> common) to commit the changes to just a few files at a time. One thing >> Bazaar >> has that's very nice is the ability to "shelve" some changes for a time. >> Let's say I'm working on a bug and I want to merge your changes in or sync >> to >> the master. I can shelve some or all of my uncommitted changes, which >> saves >> them essentially out-of-the-way patch files, and then reverts my >> uncommitted >> changes. Unshelving then is the process of re-applying those patch files, >> and >> yes, resolving conflicts. >> > >Hg's is the mq (Mercurial Queue) extension. I think mq is more like quilt than shelve. The moral equivalents in Bazaar would probably be the loom and pipeline extensions. >> This is also a great way to work when you want to do >> test-driven-development >> but need to do some exploration first. You can hack around non-TDD until >> you're confident of your approach, shelve all your changes, then >> incrementally >> apply them back as you write each test. I'm sure Mercurial has something >> equally awesome lurking about. :) > >They all have the same history from the Linux kernel for the patch queue >concept. I suspect it's pretty universally implemented, just with different >command names (of course as gods forbid it be consistent). Truth to that. I've often advocated for the big three to converge on repository format and wire protocol, and for them to innovate and differentiate on ui. The models might be different enough that you couldn't do it 100%, but the existence of mapping extensions (e.g. hg-git, bzr-hg) seems to imply that they're pretty darn close. If we had this, then all the hand wringing about which dVCS to choose would be essentially moot. You'd just pick the cli and gui clients you preferred. Really, sweating over the dVCS tool detracts from what you do care about, which is developing Python! -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From barry at python.org Sat Feb 26 22:32:23 2011 From: barry at python.org (Barry Warsaw) Date: Sat, 26 Feb 2011 16:32:23 -0500 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110226222004.1d9e0596@pitrou.net> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> <20110226130847.05daf511@limelight.wooz.org> <20110226190518.37F381FF8A4@kimball.webabinitio.net> <20110226160645.5c5d28e6@limelight.wooz.org> <20110226222004.1d9e0596@pitrou.net> Message-ID: <20110226163223.78e020b2@limelight.wooz.org> On Feb 26, 2011, at 10:20 PM, Antoine Pitrou wrote: >Often (but not always), when you're wanting to do something, there's an >extension for Mercurial which can be enabled ;) >http://mercurial.selenic.com/wiki/ShareExtension You sound like an iPhone commercial: "There's an app for that." :) -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From benjamin at python.org Sat Feb 26 22:33:57 2011 From: benjamin at python.org (Benjamin Peterson) Date: Sat, 26 Feb 2011 15:33:57 -0600 Subject: [Python-Dev] Unbinding a name referenced by an enclosing scope - error in documentation? In-Reply-To: References: Message-ID: 2011/2/26 Grigory Javadyan : >>>> def f(): > ... ? ? a = 42 > ... ? ? def g(): > ... ? ? ? ? ? ? nonlocal a > ... ? ? ? ? ? ? del a > ... > SyntaxError: can not delete variable 'a' referenced in nested scope > > Which looks weird, because the name is referenced in the _enclosed_ > scope, not the _enclosing_ scope. Is there a typo in the documentation > or am I missing something? Actually you can do that now 3.2+. I've now removed that sentence;. -- Regards, Benjamin From merwok at netwok.org Sat Feb 26 22:36:47 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sat, 26 Feb 2011 22:36:47 +0100 Subject: [Python-Dev] [Python-checkins] hooks: Fix checkbranch hook In-Reply-To: References: Message-ID: <4D69726F.5000803@netwok.org> > + if branch in ('trunk', 'legacy-trunk', > + '2.0', '2.1', '2.2', '2.3', '2.4', '3.0'): Wouldn?t using a whitelist instead of a blacklist protect against new named branches too? From brett at python.org Sat Feb 26 22:37:04 2011 From: brett at python.org (Brett Cannon) Date: Sat, 26 Feb 2011 13:37:04 -0800 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110226163047.66140688@limelight.wooz.org> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> <20110226130847.05daf511@limelight.wooz.org> <20110226163047.66140688@limelight.wooz.org> Message-ID: On Sat, Feb 26, 2011 at 13:30, Barry Warsaw wrote: > On Feb 26, 2011, at 12:09 PM, Brett Cannon wrote: > > >For other people's benefit, LoD == line of development (I think). > > Yes. It's just a word that isn't intimately tied to the implementation > details of a specific dVCS. > > >> I clone the remote repository using the command in the devguide, so I > now > >> have > >> a 'cpython' directory containing the history of all LoDs, but with a > >> working > >> directory that reflects the 'default' LoD. Now, in the parent of > >> 'cpython', I > >> do the following to get my separate-directory-LoDs: > >> > >> $ hg clone -u 2.6 cpython py26 > >> $ hg clone -u 2.7 cpython py27 > >> # repeat and rinse for all other active LoDs > >> > >> > >That's one way of doing it. > > I'm sure there are many different ways of setting things up. I am totally > in > favor of the devguide documenting and encouraging one particular way, and > I'm > sure Mercurial will prove to be a flexible tool that can conform to user's > preferences rather than the other way 'round. > > >> (Aside: that cpython directory still bugs me. It doesn't naturally > reflect > >> a > >> LoD, so why do I have to stare at it? Yes, I can make it play double > duty > >> by > >> naming it "3.3" or whatever and updating it to the 3.3 LoD, but that > feels > >> artificial.) > >> > >It's a clone repository of CPython; the name makes perfect sense. You are > >focusing on what the repository happens to be updated to ATM, not the fact > >that the repository itself represents any and all LoDs. > > No, I get all that. I'm just not sure why I should care where all the > history > is stored. I'm not actually going to do any coding in the cpython > directory, > so it just seems like a wart I have to carry around. But as I said before, > this is the Mercurial Way, so be it. > > >> Now I want to synchronize my local py27 directory with the state of that > >> LoD > >> on python.org. This is a two step process: > >> > >> $ cd py27 # now I want to synchronize > >> $ (cd ../cpython && hg pull) > >> $ hg pull -u > >> > >> Editing hgrc to point to hg.python.org means the sync-to-remote-master > >> operation is one command. > >> > >> I could do this: > >> > >> $ cd py27 # now I want to synchronize > >> $ hg pull -u ssh://hg at hg.python.org/cpython > >> > >> but I'm not going to remember that url every time. It wouldn't be so > bad > >> if > >> Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar > >> does. > >> > > > >So does Hg: simply edit your .hgrc to have it both pull and push to the > same > >URL. > > Right, see my follow up to RDM. > > >Or you can save yourself some trouble, and simply clone the repository at > a > >specific branch: > > > > hg clone ssh://hg at hg.python.org/cpython#2.7 > > > >I believe that might even strip out other history outside the scope of the > >branch. > > That might be a better way if it doesn't slurp down the entire repository > history. > > >> >Anecdote: I migrated from Subversion to Mercurial a few years ago, and > >> >found Mercurial branches very intuitive. When I saw mentions of Bazaar > >> >branches I was driven nuts by (what I saw as) the conflation between a > >> >branch and a clone. Later I understood how it made sense from the > >> >perspective of Bazaar, so I shifted my judgment from ?insanely > >> >confusing? to ?a particular choice that I don?t approve? . > >> > >> That's funny because to my eyes, Mercurial conflates "branches" and > >> "clones". > >> Why a clone operation should give me the history for all > >> lines-of-development > >> inside a working directory for one "arbitrary" one strikes me as bizarre > >> (pardon the pun :). > > > >Because Hg views a clone as that: a clone of the entire repository. A > branch > >just happens to be a part of the repository. And because it is the entire > >repository it has to have you point somewhere, so it goes with default > since > >a lot of people never even work somewhere other than on default. > > Yep, I get all that. It's Mercurial's model of the world. > > >Yes, fun isn't it? Makes me that much more glad I don't have to care about > >other DVCSs anymore; make the decision of which one to go through was > >painful partially for this reason. > > Lucky you! I interact with tons of projects, so I still have to deal with > everything from CVS to git. This will be my first serious foray into hg, > and > for that I'm glad. And really, *any* dVCS is better than a non-dVCS, so > I'm > really happy this is finally happening, despite any initial grumbling > you're > reading into my posts. :) > > >> >> I'll have to remember that 'hg pull' does not update the working copy > by > >> >> default, > >> > > >> >That pull does not update is a feature: The operation between a remote > >> >repo and the local repo (the .hg directory) is separate from the > >> >operation from the local repo to the working directory. When you know > >> >that you want pull + update (like when you have a clean working > >> >directory), you use ?hg pull -u?. (I don?t like the fetch command.) > >> > >> Sure, I get that. Again, this feature appears odd because I have the > full > >> history of all LoDs embedded in a working directory of a single LoD. > > > >Not single, _current_. I know you don't like the whole svn switch approach > >that this is like, but Hg is very much about "don't forget a thing", which > >is why you need to view a clone as a clone repository that you are > choosing > >to view in a certain way at any moment in time instead of as a single > branch > >that just happens to be carrying around the weight of other branches. > >Totally different approaches to VCS. > > No really, I do get all that! I just don't like it much. Maybe it'll grow > on > me though. > > >> I very rarely want to do that. It's more common (but still, IME not > *that* > >> common) to commit the changes to just a few files at a time. One thing > >> Bazaar > >> has that's very nice is the ability to "shelve" some changes for a time. > >> Let's say I'm working on a bug and I want to merge your changes in or > sync > >> to > >> the master. I can shelve some or all of my uncommitted changes, which > >> saves > >> them essentially out-of-the-way patch files, and then reverts my > >> uncommitted > >> changes. Unshelving then is the process of re-applying those patch > files, > >> and > >> yes, resolving conflicts. > >> > > > >Hg's is the mq (Mercurial Queue) extension. > > I think mq is more like quilt than shelve. The moral equivalents in Bazaar > would probably be the loom and pipeline extensions. > > >> This is also a great way to work when you want to do > >> test-driven-development > >> but need to do some exploration first. You can hack around non-TDD > until > >> you're confident of your approach, shelve all your changes, then > >> incrementally > >> apply them back as you write each test. I'm sure Mercurial has > something > >> equally awesome lurking about. :) > > > >They all have the same history from the Linux kernel for the patch queue > >concept. I suspect it's pretty universally implemented, just with > different > >command names (of course as gods forbid it be consistent). > > Truth to that. > > I've often advocated for the big three to converge on repository format and > wire protocol, and for them to innovate and differentiate on ui. The > models > might be different enough that you couldn't do it 100%, but the existence > of > mapping extensions (e.g. hg-git, bzr-hg) seems to imply that they're pretty > darn close. > > If we had this, then all the hand wringing about which dVCS to choose would > be > essentially moot. You'd just pick the cli and gui clients you preferred. > Really, sweating over the dVCS tool detracts from what you do care about, > which is developing Python! There is hg-git, but that is hg on top of git. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nyamatongwe at gmail.com Sat Feb 26 22:39:29 2011 From: nyamatongwe at gmail.com (Neil Hodgson) Date: Sun, 27 Feb 2011 08:39:29 +1100 Subject: [Python-Dev] pymigr: Ask for hgeol-checking hook. In-Reply-To: <4D694535.6070207@v.loewis.de> References: <20110226185402.14b66d79@pitrou.net> <4D6940FE.509@v.loewis.de> <1298744009.3704.25.camel@localhost.localdomain> <4D694535.6070207@v.loewis.de> Message-ID: Line end problems do occur in real projects. A scintilla-cocoa project was branched off Scintilla to support the Cocoa GUI framework on OS X. Here is one of the revisions in that project: http://bazaar.launchpad.net/~mike-lischke/scintilla-cocoa/trunk/revision/5#include/ScintillaWidget.h If the ScintillaWidget.h changes aren't visible (after a brief wait) then click on the arrow next to it. There are only 3 real changed lines in this file (which are changing comments from C++ to C) but the whole file appears to have been changed. This is far from the worst I have seen with some revisions showing almost every line in a project changed. There are several effects from this: 1) The blame command loses usefulness as all lines in the file appear to be from this revision. 2) Downloads become bigger, and take longer. 3) Fixing the issues takes time, effort and junks the history further. Neil From digitalxero at gmail.com Sat Feb 26 22:48:05 2011 From: digitalxero at gmail.com (Dj Gilcrease) Date: Sat, 26 Feb 2011 16:48:05 -0500 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> <20110226130847.05daf511@limelight.wooz.org> Message-ID: On Sat, Feb 26, 2011 at 3:09 PM, Brett Cannon wrote: > Hg's is the mq (Mercurial Queue) extension. I prefer the hg shelve plugin (http://mercurial.selenic.com/wiki/ShelveExtension) for this, more intuitive to me From solipsis at pitrou.net Sat Feb 26 22:50:25 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 26 Feb 2011 22:50:25 +0100 Subject: [Python-Dev] [Python-checkins] hooks: Fix checkbranch hook References: <4D69726F.5000803@netwok.org> Message-ID: <20110226225025.691466c8@pitrou.net> On Sat, 26 Feb 2011 22:36:47 +0100 ?ric Araujo wrote: > > + if branch in ('trunk', 'legacy-trunk', > > + '2.0', '2.1', '2.2', '2.3', '2.4', '3.0'): > > Wouldn?t using a whitelist instead of a blacklist protect against new > named branches too? Then we will have to fix the hook each time we want to add a new legitimate branch. I have no preference really. Regards Antoine. From greg.ewing at canterbury.ac.nz Sat Feb 26 23:26:42 2011 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sun, 27 Feb 2011 11:26:42 +1300 Subject: [Python-Dev] of branches and heads References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> <4D693A02.4000104@v.loewis.de> <1298742940.3704.17.camel@localhost.localdomain> <20110226202912.7d4813ba@pitrou.net> Message-ID: From: Antoine Pitrou > - a "branch" usually means a "named branch": a set of changesets > bearing the same label (e.g. "default"); that label is freely chosen > by the committer at any point, and enforces no topological > characteristic There are *some* topological restrictions, because hg won't let you assign a branch name that's been used before to a node unless one of its parents has that name. So you can't create two disconnected subgraphs whose nodes have the same branch name. -- Greg This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. From greg.ewing at canterbury.ac.nz Sat Feb 26 23:30:43 2011 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sun, 27 Feb 2011 11:30:43 +1300 Subject: [Python-Dev] Unbinding a name referenced by an enclosing scope - error in documentation? References: Message-ID: From: Grigory Javadyan > ... def f(): > ... a = 42 > ... def g(): > ... nonlocal a > ... del a > ... > SyntaxError: can not delete variable 'a' referenced in nested scope Is there a rational for this? It seems inconsistent -- if you can assign to names in outer scopes, you should be able to del them as well. -- Greg This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. From benjamin at python.org Sat Feb 26 23:36:12 2011 From: benjamin at python.org (Benjamin Peterson) Date: Sat, 26 Feb 2011 16:36:12 -0600 Subject: [Python-Dev] Unbinding a name referenced by an enclosing scope - error in documentation? In-Reply-To: References: Message-ID: 2011/2/26 Greg Ewing : > From: Grigory Javadyan >> ... def f(): >> ... ? ? a = 42 >> ... ? ? def g(): >> ... ? ? ? ? ? ? nonlocal a >> ... ? ? ? ? ? ? del a >> ... >> SyntaxError: can not delete variable 'a' referenced in nested scope > > Is there a rational for this? It seems inconsistent -- if you can > assign to names in outer scopes, you should be able to del them > as well. Notice that it's now been changed... -- Regards, Benjamin From adrian at cadifra.com Sat Feb 26 23:45:24 2011 From: adrian at cadifra.com (Adrian Buehlmann) Date: Sat, 26 Feb 2011 23:45:24 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110226160645.5c5d28e6@limelight.wooz.org> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> <20110226130847.05daf511@limelight.wooz.org> <20110226190518.37F381FF8A4@kimball.webabinitio.net> <20110226160645.5c5d28e6@limelight.wooz.org> Message-ID: <4D698284.60305@cadifra.com> On 2011-02-26 22:06, Barry Warsaw wrote: > On Feb 26, 2011, at 02:05 PM, R. David Murray wrote: > >> On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw wrote: >>> $ cd py27 # now I want to synchronize >>> $ hg pull -u ssh://hg at hg.python.org/cpython >>> >>> but I'm not going to remember that url every time. It wouldn't be so bad if >>> Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does. >> >> How does setting it in the hgrc differ from "remebering" it? > > It's different because you don't use a familiar interface to set it (i.e hg). > You have to know to hack a file to make it work. That's not awesome user > interface. ;) You'd have to take this up with Mercurial's BDFL Matt. He is a strong advocate for teaching users to learn edit their .hg/hgrc files. And he's quite firm on not wanting to have Mercurial touch .hg/hgrc -- with the single exception being to write a initial .hg/hgrc on 'hg clone', containing the default path with the location from where the repo was cloned. Regarding Bazaar: FWIW, I periodically retried the speed of 'bzr check' - and always gave up again looking at bzr due to the horrible slowness of that command. If I have to use a DVCS I want to be able to check the integrity of my clones in reasonable time. I do it with a cron job on our internal server here and I expect it to have finished checking all our repos when I get to my desk in the morning and look into my email inbox, reading the daily email with the result of the verify runs. After all, we do have everything secured with hashes, so we can use them, don't we? >> I've never been comfortable with the bzr --remember option because I'm never >> sure what it is remembering. Much easier for me to see it in a config file. >> But, then, that's how my brain works, and other people's will work >> differently. > > It's easy to tell what it remembers because it's exactly what you told it to > remember ;). But I guess you're talking about push and pull automatically > remembering the location when none was previously set. I love that feature. > > And of course, bzr 'remembers' by setting a value in a config file, which of > course you *could* hack if you wanted to. It's just that you don't normally > have to open your editor and remember which value in which config file you > have to manually modify to set the push and pull locations. I think that's a > win, but YMMV. :) > > Oh, and 'bzr info' always tells you what the push and pull locations are. You can use 'hg paths' for that: See http://selenic.com/repo/hg/help/paths or 'hg help paths' on the command line. >> I find bazaar's model confusing, and hg's intuitive, just like ??ric. >> And consider that I learned bazaar before mercurial. To me, it makes >> perfect sense that in a DVCS the "unit" is a directory containing >> a repository and a working copy, and that the repository is *the* >> repository. That is, it has everything related to the project in it, >> just like the master SVN repository does (plus, since it is a DVCS, >> whatever I've committed locally but not pushed to the master). To have >> a repository that only has some of the stuff in it is, IMO, confusing. >> I advocated for having all the Python history in one repo partly for >> that reason. > > I would feel better about Mercurial's if the repo where not intimately tied > with a default working tree (yes, I know -U). In a sense, that's what > Bazaar's shared repositories are: a place where all your history goes. In > Bazaar's model though, it's not tied to a specific working tree, and it's > hidden in a dot-directory. > > It's still kind of beside the point - this is the way Mercurial works, and I > don't really mean this thread to be an in-depth comparison between the two. I'm quite surprised indeed to read that much about Bazaar in this thread here :) From stutzbach at google.com Sun Feb 27 00:08:19 2011 From: stutzbach at google.com (Daniel Stutzbach) Date: Sat, 26 Feb 2011 15:08:19 -0800 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> <20110226130847.05daf511@limelight.wooz.org> <20110226163047.66140688@limelight.wooz.org> Message-ID: On Sat, Feb 26, 2011 at 1:37 PM, Brett Cannon wrote: > There is hg-git, but that is hg on top of git. > Actually, hg-git is bidirectional. The hg-git documentation is written from the perspective of an hg client talking to a git server, but for a DVCS "client" and "server" are a matter of perspective. I spent some time on Friday setting up hg-git on my workstation and making a few test commits. It took me awhile to figure out how to get everything working, but it seems to work smoothly now. At some point I'll update http://wiki.python.org/moin/Git with instructions. -- Daniel Stutzbach -------------- next part -------------- An HTML attachment was scrubbed... URL: From digitalxero at gmail.com Sun Feb 27 00:13:15 2011 From: digitalxero at gmail.com (Dj Gilcrease) Date: Sat, 26 Feb 2011 18:13:15 -0500 Subject: [Python-Dev] hg extensions was Mercurial conversion repositories Message-ID: So reading the thread about the conversion and the dev guide at http://potrou.net/hgdevguide/ there seems to not be a list of recommended extensions that the python devs should have and use, only a few examples of their use. so I figured I would build up a list for other people to add to / comment on File Format Management eol http://mercurial.selenic.com/wiki/EolExtension required flake8 http://pypi.python.org/pypi/flake8/ recommended especially for new commiters as it will validate pep8 compliance and check for common errors *Maybe update it to do pep7 compliance checks on the c files as well? Patch Management mq http://mercurial.selenic.com/wiki/MqExtension This is the one the devguide uses in examples rebase http://mercurial.selenic.com/wiki/RebaseExtension used with the --collapse option it is very easy to build up a patch patch with incremental commits, but discard the private history of the developer This one makes more sense to me personally then mq and fits how my standard workflow goes better shelve http://mercurial.selenic.com/wiki/ShelveExtension Store un commited changes away so they dont affect generation of the patch transplant http://mercurial.selenic.com/wiki/TransplantExtension required to port patches between major versions record http://mercurial.selenic.com/wiki/RecordExtension Allows cherry picking of commits to build a patch, Also works with mq Crecord http://mercurial.selenic.com/wiki/CrecordExtension appears to be a c optimized version or record Branch Management bookmarks http://mercurial.selenic.com/wiki/BookmarksExtension Great for tracking bug fix work without needing to create a separate working directory recommended that the central repo NOT have the extension enabled so as to ensure bookmarks are a local only tracking system From merwok at netwok.org Sun Feb 27 00:19:56 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sun, 27 Feb 2011 00:19:56 +0100 Subject: [Python-Dev] hg extensions (was: Mercurial conversion repositories) In-Reply-To: References: Message-ID: <4D698A9C.3010505@netwok.org> Hi, > shelve > http://mercurial.selenic.com/wiki/ShelveExtension > Store un commited changes away so they dont affect generation > of the patch I never use it. > transplant > http://mercurial.selenic.com/wiki/TransplantExtension > required to port patches between major versions That?s actually not clear in the current PEP / devguide. > record > http://mercurial.selenic.com/wiki/RecordExtension > Allows cherry picking of commits to build a patch, Also works with mq ?Cherry-picking? means ?selecting some changesets for pull?, not ?selecting some diff hunks for commit?. > Crecord > http://mercurial.selenic.com/wiki/CrecordExtension > appears to be a c optimized version or record Not at all. It has the same functionality as record, only in a curses UI instead of an unusable line-based interface. > Branch Management > bookmarks > http://mercurial.selenic.com/wiki/BookmarksExtension > Great for tracking bug fix work without needing to create a > separate working directory Never use them. Clones are okay. Regards From merwok at netwok.org Sun Feb 27 00:21:23 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sun, 27 Feb 2011 00:21:23 +0100 Subject: [Python-Dev] [Python-checkins] hooks: Fix checkbranch hook In-Reply-To: <20110226225025.691466c8@pitrou.net> References: <4D69726F.5000803@netwok.org> <20110226225025.691466c8@pitrou.net> Message-ID: <4D698AF3.1010207@netwok.org> > Then we will have to fix the hook each time we want to add a new > legitimate branch. The alternative is to edit the hook each time we want to remove a former legitimate branch, plus have another hook to refuse new named branches. > I have no preference really. Looks like a ?0 to me :) Regards From merwok at netwok.org Sun Feb 27 00:24:10 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sun, 27 Feb 2011 00:24:10 +0100 Subject: [Python-Dev] hg extensions In-Reply-To: <4D698A9C.3010505@netwok.org> References: <4D698A9C.3010505@netwok.org> Message-ID: <4D698B9A.5070102@netwok.org> > Never use them. Clones are okay. s/use/used/ From digitalxero at gmail.com Sun Feb 27 00:37:15 2011 From: digitalxero at gmail.com (Dj Gilcrease) Date: Sat, 26 Feb 2011 18:37:15 -0500 Subject: [Python-Dev] hg extensions (was: Mercurial conversion repositories) In-Reply-To: <4D698A9C.3010505@netwok.org> References: <4D698A9C.3010505@netwok.org> Message-ID: On Sat, Feb 26, 2011 at 6:19 PM, ?ric Araujo wrote: >> ? ?transplant >> ? ? ? ? http://mercurial.selenic.com/wiki/TransplantExtension >> ? ? ? ? required to port patches between major versions > That?s actually not clear in the current PEP / devguide. http://potrou.net/hgdevguide/committing.html#porting-between-major-versions > >> ? ? record >> ? ? ? ? http://mercurial.selenic.com/wiki/RecordExtension >> ? ? ? ? Allows cherry picking of commits to build a patch, Also works with mq > ?Cherry-picking? means ?selecting some changesets for pull?, not > ?selecting some diff hunks for commit?. /shrug to me you cherry pick what you want to commit, shelve the rest, create your patch then unshelve and continue development. Just a matter of semantics :) > >> ? ? Crecord >> ? ? ? ? http://mercurial.selenic.com/wiki/CrecordExtension >> ? ? ? ? appears to be a c optimized version or record > Not at all. ?It has the same functionality as record, only in a curses > UI instead of an unusable line-based interface. Ya I have never used either of them > >> Branch Management >> ? ? bookmarks >> ? ? ? ? http://mercurial.selenic.com/wiki/BookmarksExtension >> ? ? ? ? Great for tracking bug fix work without needing to create a >> separate working directory > Never use them. ?Clones are okay. Same here but not everyone likes to do that and in the dev guide they use an example of working with only 1 working directory so the bookmark extension would be useful to people who want to follow that method of development From adrian at cadifra.com Sun Feb 27 00:41:05 2011 From: adrian at cadifra.com (Adrian Buehlmann) Date: Sun, 27 Feb 2011 00:41:05 +0100 Subject: [Python-Dev] hg extensions was Mercurial conversion repositories In-Reply-To: References: Message-ID: <4D698F91.4060602@cadifra.com> On 2011-02-27 00:13, Dj Gilcrease wrote: > Branch Management > bookmarks > http://mercurial.selenic.com/wiki/BookmarksExtension Bookmarks will be in Mercurial core for Mercurial 1.8, which will be released in a few days (March 1st). So, with 1.8 it's no longer needed to enable this extension in the configuration -- the feature will be built-in. From hagen at zhuliguan.net Sun Feb 27 00:44:17 2011 From: hagen at zhuliguan.net (=?ISO-8859-1?Q?Hagen_F=FCrstenau?=) Date: Sun, 27 Feb 2011 00:44:17 +0100 Subject: [Python-Dev] set iteration order In-Reply-To: References: Message-ID: > Code with any dependence on the iteration order of unordered collections > (other than the guarantee that d.keys() and d.values() match at any > given time as long as d is unchanged) is buggy. It's not a matter of dependence on iteration order, but of reproducibility (in my case there were minor numerical differences due to different iteration orders). I think we also warn about changes in pseudorandom number sequences, although you could argue that no code should depend on specific pseudorandom numbers. Cheers, Hagen From merwok at netwok.org Sun Feb 27 00:55:42 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sun, 27 Feb 2011 00:55:42 +0100 Subject: [Python-Dev] set iteration order In-Reply-To: References: Message-ID: <4D6992FE.5060801@netwok.org> > It's not a matter of dependence on iteration order, but of > reproducibility (in my case there were minor numerical differences due > to different iteration orders). Can you give a code example? I don?t understand your case. Regards From steve at pearwood.info Sun Feb 27 01:06:04 2011 From: steve at pearwood.info (Steven D'Aprano) Date: Sun, 27 Feb 2011 11:06:04 +1100 Subject: [Python-Dev] set iteration order In-Reply-To: References: Message-ID: <4D69956C.2060902@pearwood.info> Hagen F?rstenau wrote: >> Code with any dependence on the iteration order of unordered collections >> (other than the guarantee that d.keys() and d.values() match at any >> given time as long as d is unchanged) is buggy. > > It's not a matter of dependence on iteration order, but of > reproducibility (in my case there were minor numerical differences due > to different iteration orders). If those differences are insignificant to you, then why do you care? If they are significant enough that (say) tests were failing, then your results depend on the iteration order of a set, and your code is buggy and should be fixed. Or perhaps your tests are too strict. > I think we also warn about changes in > pseudorandom number sequences, although you could argue that no code > should depend on specific pseudorandom numbers. The random module provides an API for repeating sequences of pseudorandom numbers: the seed. So you *can* depend on specific numbers, if you need to. Sets and dicts do not provide any such API. The order even changes with the history of the object: two equal sets can have different iteration orders. Personally, I don't care whether or not we mention that set iteration order has changed. It seems too trivial to worry much about it. +0 -- Steven From solipsis at pitrou.net Sun Feb 27 01:06:57 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 27 Feb 2011 01:06:57 +0100 Subject: [Python-Dev] hg extensions (was: Mercurial conversion repositories) References: <4D698A9C.3010505@netwok.org> Message-ID: <20110227010657.12c047da@pitrou.net> > >> Branch Management > >> ? ? bookmarks > >> ? ? ? ? http://mercurial.selenic.com/wiki/BookmarksExtension > >> ? ? ? ? Great for tracking bug fix work without needing to create a > >> separate working directory > > Never use them. ?Clones are okay. > > Same here but not everyone likes to do that and in the dev guide they > use an example of working with only 1 working directory so the > bookmark extension would be useful to people who want to follow that > method of development I've just tried bookmarks and I find them very cumbersome compared to named branches (which, unfortunately, can't remain local). I wonder what guided their design. (the core issue being that a bookmark blindly follows every commit you do, while you would need it to follow upstream instead!) Regards Antoine. From solipsis at pitrou.net Sun Feb 27 01:09:45 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 27 Feb 2011 01:09:45 +0100 Subject: [Python-Dev] set iteration order References: Message-ID: <20110227010945.2cb57e45@pitrou.net> On Sat, 26 Feb 2011 10:09:33 +0100 Hagen F?rstenau wrote: > > I just hunted down a change in behaviour between Python 3.1 and 3.2 to > possibly changed iteration order of sets due to the optimization in > issue #8685. Of course, this order shouldn't be relied on in the first > place, but the side effect of the optimization might be worth mentioning > in "What's new", maybe also pointing out that the old behaviour can be > simulated with {x for x in a if x not in b} in place of "a-b". I'm against such a mention. It would give the impression that we support some semblance of reproduceability in iteration order, which is not true. If you use sets or dicts, you must deal with the fact that the iteration order will be totally random from your (the programmer's) POV. Regards Antoine. From merwok at netwok.org Sun Feb 27 01:25:12 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sun, 27 Feb 2011 01:25:12 +0100 Subject: [Python-Dev] hg extensions In-Reply-To: <20110227010657.12c047da@pitrou.net> References: <4D698A9C.3010505@netwok.org> <20110227010657.12c047da@pitrou.net> Message-ID: <4D6999E8.3050406@netwok.org> > I've just tried bookmarks and I find them very cumbersome compared to > named branches (which, unfortunately, can't remain local). I wonder > what guided their design. Mimicking git branches. > (the core issue being that a bookmark blindly follows every commit you > do, while you would need it to follow upstream instead!) I don?t really understand (I don?t really want to, I don?t care for bookmarks), but maybe this will help: http://mercurial.selenic.com/wiki/BookmarksExtension#Configuration Regards From barry at python.org Sun Feb 27 01:50:26 2011 From: barry at python.org (Barry Warsaw) Date: Sat, 26 Feb 2011 19:50:26 -0500 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <4D698284.60305@cadifra.com> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> <20110226130847.05daf511@limelight.wooz.org> <20110226190518.37F381FF8A4@kimball.webabinitio.net> <20110226160645.5c5d28e6@limelight.wooz.org> <4D698284.60305@cadifra.com> Message-ID: <20110226195026.5dc7eb3b@limelight.wooz.org> On Feb 26, 2011, at 11:45 PM, Adrian Buehlmann wrote: >You'd have to take this up with Mercurial's BDFL Matt. He is a strong >advocate for teaching users to learn edit their .hg/hgrc files. Well, I guess it's doubtful I'd change his mind then. :) >Regarding Bazaar: FWIW, I periodically retried the speed of 'bzr check' >- and always gave up again looking at bzr due to the horrible slowness >of that command. If I have to use a DVCS I want to be able to check the >integrity of my clones in reasonable time. I do it with a cron job on >our internal server here and I expect it to have finished checking all >our repos when I get to my desk in the morning and look into my email >inbox, reading the daily email with the result of the verify runs. > >After all, we do have everything secured with hashes, so we can use >them, don't we? Do you know how thorough 'bzr check' is? I don't, but then I've never used it or felt the need to. ;) >> Oh, and 'bzr info' always tells you what the push and pull locations are. > >You can use 'hg paths' for that: Nice, thanks. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From solipsis at pitrou.net Sun Feb 27 01:51:38 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 27 Feb 2011 01:51:38 +0100 Subject: [Python-Dev] hg extensions References: <4D698A9C.3010505@netwok.org> <20110227010657.12c047da@pitrou.net> <4D6999E8.3050406@netwok.org> Message-ID: <20110227015138.2bec54fa@pitrou.net> On Sun, 27 Feb 2011 01:25:12 +0100 ?ric Araujo wrote: > > I've just tried bookmarks and I find them very cumbersome compared to > > named branches (which, unfortunately, can't remain local). I wonder > > what guided their design. > > Mimicking git branches. I've hardly ever used git but I would be surprised if its change tracking abilities were so poor. > > (the core issue being that a bookmark blindly follows every commit you > > do, while you would need it to follow upstream instead!) > > I don?t really understand (I don?t really want to, I don?t care for > bookmarks), but maybe this will help: > http://mercurial.selenic.com/wiki/BookmarksExtension#Configuration That's vaguely better (since it allows to advance one bookmark instead of both), but it still doesn't allow tracking incoming upstream changes. Meaning that as soon as I "hg pull" (not to mention "hg merge"), I lose the ability to easily make a collapsed diff of my local changes. Regards Antoine. From solipsis at pitrou.net Sun Feb 27 01:59:48 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 27 Feb 2011 01:59:48 +0100 Subject: [Python-Dev] hg extensions was Mercurial conversion repositories References: Message-ID: <20110227015948.5906fd2f@pitrou.net> Hi, On Sat, 26 Feb 2011 18:13:15 -0500 Dj Gilcrease wrote: > > File Format Management > eol > http://mercurial.selenic.com/wiki/EolExtension > required Actually, it isn't *required* on each developer's setup, since we now have a hook that refuses bogus changegroups (if needed, we can even refuse individual changesets). In most situations, even without the eol extension line endings won't get modified anyway. > flake8 > http://pypi.python.org/pypi/flake8/ > recommended especially for new commiters as it will validate > pep8 compliance and check for common errors IMHO, nothing replaces human reviews and communication for style and other likewise issues. > Patch Management > mq > rebase > shelve All these depend on each developer's taste, as long as only collapsed patches get submitted and committed. > transplant > http://mercurial.selenic.com/wiki/TransplantExtension > required to port patches between major versions Not really required, and actually controversial since it commits automatically (we would like people to commit and test *before* committing, otherwise buildbots can get bogus changesets and spurious failures). > bookmarks > http://mercurial.selenic.com/wiki/BookmarksExtension > Great for tracking bug fix work without needing to create a > separate working directory > recommended that the central repo NOT have the extension > enabled so as to ensure bookmarks are a local only tracking system Actually quite poor for tracking bug fix work (see my other messages in this thread :-)). Regards Antoine. From adrian at cadifra.com Sun Feb 27 02:15:51 2011 From: adrian at cadifra.com (Adrian Buehlmann) Date: Sun, 27 Feb 2011 02:15:51 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110226195026.5dc7eb3b@limelight.wooz.org> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> <20110226130847.05daf511@limelight.wooz.org> <20110226190518.37F381FF8A4@kimball.webabinitio.net> <20110226160645.5c5d28e6@limelight.wooz.org> <4D698284.60305@cadifra.com> <20110226195026.5dc7eb3b@limelight.wooz.org> Message-ID: <4D69A5C7.2000903@cadifra.com> On 2011-02-27 01:50, Barry Warsaw wrote: > On Feb 26, 2011, at 11:45 PM, Adrian Buehlmann wrote: > >> You'd have to take this up with Mercurial's BDFL Matt. He is a strong >> advocate for teaching users to learn edit their .hg/hgrc files. > > Well, I guess it's doubtful I'd change his mind then. :) Yep. >> Regarding Bazaar: FWIW, I periodically retried the speed of 'bzr check' >> - and always gave up again looking at bzr due to the horrible slowness >> of that command. If I have to use a DVCS I want to be able to check the >> integrity of my clones in reasonable time. I do it with a cron job on >> our internal server here and I expect it to have finished checking all >> our repos when I get to my desk in the morning and look into my email >> inbox, reading the daily email with the result of the verify runs. >> >> After all, we do have everything secured with hashes, so we can use >> them, don't we? > > Do you know how thorough 'bzr check' is? I don't, but then I've never used it > or felt the need to. ;) That's quite amazing. If I talk with people about that, it often turns out that they don't check the integrity of their repos. Well, hg verify *is* through and fast enough. That's good enough for me. And being slow is not sufficient to earn my trust. FWIW, be aware that Mercurial does not do integrity checks on normal operations, so chances are you will be able to use a repo that fails verify for quite a while -- without even noticing it. For example you can remove *some* file X inside .hg/store/data and continue to add history to that repo without any sign of errors, as long as the file X isn't used during the operations you do. From raymond.hettinger at gmail.com Sun Feb 27 02:30:58 2011 From: raymond.hettinger at gmail.com (Raymond Hettinger) Date: Sat, 26 Feb 2011 17:30:58 -0800 Subject: [Python-Dev] set iteration order In-Reply-To: <20110227010945.2cb57e45@pitrou.net> References: <20110227010945.2cb57e45@pitrou.net> Message-ID: <4D6DE8DD-94A4-427E-8B7A-3C502C0B84B7@gmail.com> On Feb 26, 2011, at 4:09 PM, Antoine Pitrou wrote: > On Sat, 26 Feb 2011 10:09:33 +0100 > Hagen F?rstenau wrote: >> >> I just hunted down a change in behaviour between Python 3.1 and 3.2 to >> possibly changed iteration order of sets due to the optimization in >> issue #8685. Of course, this order shouldn't be relied on in the first >> place, but the side effect of the optimization might be worth mentioning >> in "What's new", maybe also pointing out that the old behaviour can be >> simulated with {x for x in a if x not in b} in place of "a-b". > > I'm against such a mention. It would give the impression that we > support some semblance of reproduceability in iteration order, which is > not true. If you use sets or dicts, you must deal with the fact that > the iteration order will be totally random from your (the programmer's) > POV. I concur with Antoine. Also, it wasn't the iteration order that changed; sets still iterate in the same order. What changed was the algorithm for creating a new set using a set difference operation. Raymond From barry at python.org Sun Feb 27 03:21:07 2011 From: barry at python.org (Barry Warsaw) Date: Sat, 26 Feb 2011 21:21:07 -0500 Subject: [Python-Dev] hg commit with diff -u output (was Re: hg extensions was Mercurial conversion repositories) In-Reply-To: <20110227015948.5906fd2f@pitrou.net> References: <20110227015948.5906fd2f@pitrou.net> Message-ID: <20110226212107.670b907e@limelight.wooz.org> FWIW, this modification to hgeditor does a reasonable approximation of 'bzr commit' including the diff -u output. Cheers, -Barry #!/bin/sh # # This is an example of using HGEDITOR to create of diff to review the # changes while commiting. # If you want to pass your favourite editor some other parameters # only for Mercurial, modify this: case "${EDITOR}" in "") EDITOR="sensible-editor" ;; emacs) EDITOR="$EDITOR -nw" ;; gvim|vim) EDITOR="$EDITOR -f -o" ;; esac HGTMP="" cleanup_exit() { rm -rf "$HGTMP" } # Remove temporary files even if we get interrupted trap "cleanup_exit" 0 # normal exit trap "exit 255" HUP INT QUIT ABRT TERM HGTMP=$(mktemp -d ${TMPDIR-/tmp}/hgeditor.XXXXXX) [ x$HGTMP != x -a -d $HGTMP ] || { echo "Could not create temporary directory! Exiting." 1>&2 exit 1 } ( grep '^HG: changed' "$1" | cut -b 13- | while read changed; do "$HG" diff "$changed" >> "$HGTMP/diff" done ) cat "$1" > "$HGTMP/msg" LINES=`wc -l $HGTMP/msg` echo "" >> "$HGTMP/msg" cat "$HGTMP/diff" >> "$HGTMP/msg" MD5=$(which md5sum 2>/dev/null) || MD5=$(which md5 2>/dev/null) [ -x "${MD5}" ] && CHECKSUM=`${MD5} "$HGTMP/msg"` $EDITOR "$HGTMP/msg" || exit $? if [ -x "${MD5}" ] then echo "$CHECKSUM" | ${MD5} -c >/dev/null 2>&1 && exit 13 fi cat "$HGTMP/msg" | head -n $LINES > "$HGTMP/commit" mv "$HGTMP/commit" "$1" exit $? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From martin at v.loewis.de Sun Feb 27 07:46:51 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 27 Feb 2011 07:46:51 +0100 Subject: [Python-Dev] hg extensions was Mercurial conversion repositories In-Reply-To: <20110227015948.5906fd2f@pitrou.net> References: <20110227015948.5906fd2f@pitrou.net> Message-ID: <4D69F35B.3020602@v.loewis.de> > Actually, it isn't *required* on each developer's setup, since we > now have a hook that refuses bogus changegroups (if needed, we can even > refuse individual changesets). In most situations, even without the > eol extension line endings won't get modified anyway. I think this is overly optimistic. Visual Studio will break all your files if you don't use that extension (and you actually use it to modify source code). Regards, Martin From martin at v.loewis.de Sun Feb 27 08:09:21 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 27 Feb 2011 08:09:21 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <1298745553.3704.31.camel@localhost.localdomain> References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> <4D693A02.4000104@v.loewis.de> <1298742940.3704.17.camel@localhost.localdomain> <4D694401.1000009@v.loewis.de> <1298745553.3704.31.camel@localhost.localdomain> Message-ID: <4D69F8A1.7030109@v.loewis.de> >> changeset: 72694:e65daae6cf44 >> user: Antoine Pitrou >> date: Mon Feb 21 21:30:55 2011 +0000 >> summary: Try s/UINT_MAX/INT_MAX/ > > It's not on an unnamed branch, it's on the "default" branch (which is > omitted for concision by "hg log" and other commands with a similar > output). It's probably a terminology issue, but: the changeset can't be "on" the default "branch", because the head of the default branch (called "tip", IIUC) isn't a descendant of that changeset. It's parent is changeset: 72693:d9769c8a828b user: Antoine Pitrou date: Mon Feb 21 21:25:39 2011 +0000 summary: temp branch to debug crashes on snow leopard buildbot so you have called it "temporary branch" in subversion. I got go with that term also, if "unnamed branch" is confusing. >> I think we can do better. I also dislike "hg log --only-branch default" >> to only go back to 2006 (to aeefba456e4d), when this revision actually >> does have a parent (namely, on the trunk branch, 4b41806a0326). > > I'm not convinced that small quirks of using "hg log" are important at > this point. Also, you could try other options of "hg log" such as > "--follow". IIUC, --follow doesn't help. It traces history across renames and copies, which is not what I want to overcome when trying to produce the full history of the py3k branch. As for "small quirks ... important at this point": this point is the *only* chance to get it right. If you get it wrong now, we will have to deal with it forever (or rather until we switch to the next version control system). If you chose to convert in the way it currently does: fine with me, as long as the choice was deliberate (rather than coincidental). > If we called ex-trunk the same name as ex-py3k ("default"), things would > probably be quite more confusing, since inspecting a changeset wouldn't > tell you immediately where it comes from (2.x or 3.x development). I would it call default only up to the point where the py3k branch was branched off trunk. All changes up to this point actually *do* belong to both branches. Python 3's history goes all the way back to 0.9, and I'm sure you can still find code in 3.2 which was written 20 years ago. Change sets created after 3.x was forked off should certainly live on a separate mercurial branch - it would be reasonable to call this branch then 2.x. Regards, Martin From martin at v.loewis.de Sun Feb 27 08:12:10 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 27 Feb 2011 08:12:10 +0100 Subject: [Python-Dev] of branches and heads In-Reply-To: <20110226202912.7d4813ba@pitrou.net> References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> <4D693A02.4000104@v.loewis.de> <1298742940.3704.17.camel@localhost.localdomain> <20110226202912.7d4813ba@pitrou.net> Message-ID: <4D69F94A.1060805@v.loewis.de> > So, actually, hg promotes a slightly different terminology: > - a "head" is a changeset without a child in the topology So what do you call the LoD leading up to a head? (i.e. the set of changesets that are ancestors of a head and not ancestors of any other head) Regards, Martin From martin at v.loewis.de Sun Feb 27 08:17:40 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Sun, 27 Feb 2011 08:17:40 +0100 Subject: [Python-Dev] pymigr: Ask for hgeol-checking hook. In-Reply-To: <20110226203041.79e378c4@pitrou.net> References: <20110226185402.14b66d79@pitrou.net> <4D6940FE.509@v.loewis.de> <1298744009.3704.25.camel@localhost.localdomain> <4D694535.6070207@v.loewis.de> <20110226203041.79e378c4@pitrou.net> Message-ID: <4D69FA94.4050201@v.loewis.de> Am 26.02.2011 20:30, schrieb Antoine Pitrou: > > Martin, I have now enabled the eol hook on the test repo (a quick test > seemed to show it works). Could you test again? It seems to work fine, thanks. I modified a file with Visual Studio, and that changed all line endings. I then decided to "fix" it by changing the line endings again. It now thinks I last edited every line in the file... I think we should ask Windows users to enable the eol extension before they start editing with Visual Studio, and we should ask people to redo the changes if a change is rejected by that hook (rather than trying to fix the line endings with another commit). Regards, Martin From martin at v.loewis.de Sun Feb 27 08:26:36 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Sun, 27 Feb 2011 08:26:36 +0100 Subject: [Python-Dev] [Python-checkins] hooks: Fix checkbranch hook In-Reply-To: <4D698AF3.1010207@netwok.org> References: <4D69726F.5000803@netwok.org> <20110226225025.691466c8@pitrou.net> <4D698AF3.1010207@netwok.org> Message-ID: <4D69FCAC.8000808@v.loewis.de> Am 27.02.2011 00:21, schrieb ?ric Araujo: >> Then we will have to fix the hook each time we want to add a new >> legitimate branch. > The alternative is to edit the hook each time we want to remove a former > legitimate branch, plus have another hook to refuse new named branches. The question is whether developers would create named branches if they are asked not to (except when they are release manager). There is nothing that prevents people from tagging the tree currently in subversion, but most of the time, only the release manager does any tagging. If you think that it's a likely problem that people create named branches by mistake, then we should have a hook. Regards, Martin From ncoghlan at gmail.com Sun Feb 27 08:48:34 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 27 Feb 2011 17:48:34 +1000 Subject: [Python-Dev] [Python-checkins] hooks: Fix checkbranch hook In-Reply-To: <4D69FCAC.8000808@v.loewis.de> References: <4D69726F.5000803@netwok.org> <20110226225025.691466c8@pitrou.net> <4D698AF3.1010207@netwok.org> <4D69FCAC.8000808@v.loewis.de> Message-ID: On Sun, Feb 27, 2011 at 5:26 PM, "Martin v. L?wis" wrote: > There is nothing that prevents people from tagging the tree currently > in subversion, but most of the time, only the release manager does any > tagging. > > If you think that it's a likely problem that people create named > branches by mistake, then we should have a hook. I suspect the concern is that people may create named branches locally as part of their own workflow, then mistakenly push those branches instead of collapsing back to a single commit against the relevant line of development. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From hagen at zhuliguan.net Sun Feb 27 09:41:28 2011 From: hagen at zhuliguan.net (=?UTF-8?B?SGFnZW4gRsO8cnN0ZW5hdQ==?=) Date: Sun, 27 Feb 2011 09:41:28 +0100 Subject: [Python-Dev] set iteration order In-Reply-To: <4D6992FE.5060801@netwok.org> References: <4D6992FE.5060801@netwok.org> Message-ID: >> It's not a matter of dependence on iteration order, but of >> reproducibility (in my case there were minor numerical differences due >> to different iteration orders). > > Can you give a code example? I don?t understand your case. It's a bit involved (that's why it took me a while to locate the difference in behavior), but it boils down to a (learning) algorithm that in principle should not care about order of input data, but will in practice show slightly different numerical behavior. I ran into the problem when trying to exactly reproduce previously published experimental results. Of course, I should have anticipated this and fixed some arbitrary order in the first place. I just thought a note about this change might save someone in a similar situation some confusion. Cheers, Hagen From adrian at cadifra.com Sun Feb 27 11:42:21 2011 From: adrian at cadifra.com (Adrian Buehlmann) Date: Sun, 27 Feb 2011 11:42:21 +0100 Subject: [Python-Dev] of branches and heads In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> <4D693A02.4000104@v.loewis.de> <1298742940.3704.17.camel@localhost.localdomain> <20110226202912.7d4813ba@pitrou.net> Message-ID: <4D6A2A8D.9000301@cadifra.com> On 2011-02-26 23:26, Greg Ewing wrote: > From: Antoine Pitrou >> - a "branch" usually means a "named branch": a set of changesets >> bearing the same label (e.g. "default"); that label is freely chosen >> by the committer at any point, and enforces no topological >> characteristic > > There are *some* topological restrictions, because hg won't > let you assign a branch name that's been used before to a node > unless one of its parents has that name. So you can't create > two disconnected subgraphs whose nodes have the same branch > name. That's not completely correct. You *can* do that. Mercurial by default assumes you're probably in error if you are trying to create such disconnected branch name subgraphs, but you can convince it that it's really what you want by doing: hg branch --force Example (glog command requires the graphlog extension enabled [1]): $ hg init a $ cd a $ echo foo > bla $ hg ci -Am1 adding bla $ hg branch b1 marked working directory as branch b1 $ hg ci -m2 $ hg branch default abort: a branch of the same name already exists (use 'hg update' to switch to it) $ hg branch --force default marked working directory as branch default $ hg ci -m3 created new head $ hg glog --template "{rev}, {branch}\n" @ 2, default | o 1, b1 | o 0, default [1] http://mercurial.selenic.com/wiki/GraphlogExtension From sandro.tosi at gmail.com Sun Feb 27 15:05:25 2011 From: sandro.tosi at gmail.com (Sandro Tosi) Date: Sun, 27 Feb 2011 14:05:25 +0000 Subject: [Python-Dev] [Python-checkins] devguide (hg_transition): patchcheck does work In-Reply-To: References: Message-ID: On Sun, Feb 27, 2011 at 03:17, eric.araujo wrote: > eric.araujo pushed f325d743c385 to devguide: > > http://hg.python.org/devguide/rev/f325d743c385 > changeset: ? 331:f325d743c385 > branch: ? ? ?hg_transition > user: ? ? ? ??ric Araujo > date: ? ? ? ?Sat Feb 26 17:30:51 2011 +0100 > summary: > ?patchcheck does work > > files: > ?patch.rst > > diff --git a/patch.rst b/patch.rst > --- a/patch.rst > +++ b/patch.rst > @@ -114,15 +114,13 @@ > ?Generation > ?'''''''''' > > -.. XXX [commented out] make patchcheck doesn't work with non-SVN workflow > +To perform a quick sanity check on your patch, you can run:: > > - ? To perform a quick sanity check on your patch, you can run:: > + ? make patchcheck > > - ? ? ? make patchcheck > - > - ? This will check and/or fix various common things people forget to do for > - ? patches, such as adding any new files needing for the patch to work (do not > - ? that not all checks apply to non-core developers). > +This will check and/or fix various common things people forget to do for > +patches, such as adding any new files needing for the patch to work (do not (do note Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi From sandro.tosi at gmail.com Sun Feb 27 15:27:02 2011 From: sandro.tosi at gmail.com (Sandro Tosi) Date: Sun, 27 Feb 2011 14:27:02 +0000 Subject: [Python-Dev] [Python-checkins] devguide: List common gotchas people might come across when doing coverage work. In-Reply-To: References: Message-ID: On Sun, Feb 27, 2011 at 06:31, brett.cannon wrote: > +When writing new tests to increase coverage, do take note of the style of tests > +already provided for a module (e.g., whitebox, blackbox, etc.). As > +some modules are primarily maintained by a single core developer they may have > +a specific preference as to what kind of test is used (e.g., whitebox) and > +prefer that other types of tests not be used (e.g., blackbox). When in doubt, > +stick with whitebox testing in order to properly exercise the code. Do you think it could be nice to have a reference to what whitebox/blackbox testing is, ie http://en.wikipedia.org/wiki/White-box_testing http://en.wikipedia.org/wiki/Black-box_testing ? Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi From solipsis at pitrou.net Sun Feb 27 16:08:21 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 27 Feb 2011 16:08:21 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <4D69F8A1.7030109@v.loewis.de> References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> <4D693A02.4000104@v.loewis.de> <1298742940.3704.17.camel@localhost.localdomain> <4D694401.1000009@v.loewis.de> <1298745553.3704.31.camel@localhost.localdomain> <4D69F8A1.7030109@v.loewis.de> Message-ID: <20110227160821.15bd2922@pitrou.net> On Sun, 27 Feb 2011 08:09:21 +0100 "Martin v. L?wis" wrote: > >> changeset: 72694:e65daae6cf44 > >> user: Antoine Pitrou > >> date: Mon Feb 21 21:30:55 2011 +0000 > >> summary: Try s/UINT_MAX/INT_MAX/ > > > > It's not on an unnamed branch, it's on the "default" branch (which is > > omitted for concision by "hg log" and other commands with a similar > > output). > > It's probably a terminology issue, but: the changeset can't be "on" > the default "branch", because the head of the default branch (called > "tip", IIUC) isn't a descendant of that changeset. Well, a branch (or named branch) in hg terminology can have several heads (see the other email about heads and branches). Also, just so you know, "tip" is simply the latest (in pull or commit order) changeset in the local repository. It can be in any branch (for example, if you pull of bunch of changesets someone made in "3.2", then your tip will be in branch "3.2"). I hope it all starts to make sense ;) Regards Antoine. From solipsis at pitrou.net Sun Feb 27 16:12:01 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 27 Feb 2011 16:12:01 +0100 Subject: [Python-Dev] hg extensions was Mercurial conversion repositories In-Reply-To: <4D69F35B.3020602@v.loewis.de> References: <20110227015948.5906fd2f@pitrou.net> <4D69F35B.3020602@v.loewis.de> Message-ID: <20110227161201.0d0b215d@pitrou.net> On Sun, 27 Feb 2011 07:46:51 +0100 "Martin v. L?wis" wrote: > > Actually, it isn't *required* on each developer's setup, since we > > now have a hook that refuses bogus changegroups (if needed, we can even > > refuse individual changesets). In most situations, even without the > > eol extension line endings won't get modified anyway. > > I think this is overly optimistic. Visual Studio will break all your > files if you don't use that extension (and you actually use it to > modify source code). My assumption was that most developers don't use MSVC, so most of them don't risk breaking eols ;) True, for Windows devs it might be necessary to promote it. Regards Antoine. From solipsis at pitrou.net Sun Feb 27 16:18:43 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 27 Feb 2011 16:18:43 +0100 Subject: [Python-Dev] devguide (hg_transition): Advertise hg import over patch. References: Message-ID: <20110227161843.6c71f8d1@pitrou.net> On Sun, 27 Feb 2011 04:17:06 +0100 eric.araujo wrote: > Advertise hg import over patch. > > hg import understands the extended git diff format, which supports renames, > changes to the executable bit and changes in binary files. Yes, but it's too easy to forget the awkward "--no-commit" option. "patch" doesn't involve such quirks. > patch doesn?t > do anything useful with that information, and also requires downloading and > setup on Windows. Well, chances are TortoiseHG comes with an UI to apply patches (TortoiseSVN had one), so the command-line instructions may be of little use to them. Regards Antoine. From stutzbach at google.com Sun Feb 27 16:23:18 2011 From: stutzbach at google.com (Daniel Stutzbach) Date: Sun, 27 Feb 2011 07:23:18 -0800 Subject: [Python-Dev] of branches and heads In-Reply-To: <4D6A2A8D.9000301@cadifra.com> References: <20110225011904.3ed09de7@pitrou.net> <1298738685.3704.10.camel@localhost.localdomain> <4D693A02.4000104@v.loewis.de> <1298742940.3704.17.camel@localhost.localdomain> <20110226202912.7d4813ba@pitrou.net> <4D6A2A8D.9000301@cadifra.com> Message-ID: On Sun, Feb 27, 2011 at 2:42 AM, Adrian Buehlmann wrote: > On 2011-02-26 23:26, Greg Ewing wrote: > > There are *some* topological restrictions, because hg won't > > let you assign a branch name that's been used before to a node > > unless one of its parents has that name. So you can't create > > two disconnected subgraphs whose nodes have the same branch > > name. > > That's not completely correct. You *can* do that. > Can we create a hook on the server to reject changesets like that? -- Daniel Stutzbach -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Sun Feb 27 16:23:29 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 28 Feb 2011 01:23:29 +1000 Subject: [Python-Dev] hg extensions was Mercurial conversion repositories In-Reply-To: <20110227161201.0d0b215d@pitrou.net> References: <20110227015948.5906fd2f@pitrou.net> <4D69F35B.3020602@v.loewis.de> <20110227161201.0d0b215d@pitrou.net> Message-ID: On Mon, Feb 28, 2011 at 1:12 AM, Antoine Pitrou wrote: > On Sun, 27 Feb 2011 07:46:51 +0100 > "Martin v. L?wis" wrote: >> > Actually, it isn't *required* on each developer's setup, since we >> > now have a hook that refuses bogus changegroups (if needed, we can even >> > refuse individual changesets). ?In most situations, even without the >> > eol extension line endings won't get modified anyway. >> >> I think this is overly optimistic. Visual Studio will break all your >> files if you don't use that extension (and you actually use it to >> modify source code). > > My assumption was that most developers don't use MSVC, so most of them > don't risk breaking eols ;) > True, for Windows devs it might be necessary to promote it. Windows devs were the original target audience, yes :) Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From solipsis at pitrou.net Sun Feb 27 16:21:15 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 27 Feb 2011 16:21:15 +0100 Subject: [Python-Dev] devguide (hg_transition): patchcheck does work References: Message-ID: <20110227162115.0a2cda9f@pitrou.net> On Sun, 27 Feb 2011 04:17:07 +0100 eric.araujo wrote: > summary: > patchcheck does work How does it find out which changesets it should operate on? From stutzbach at google.com Sun Feb 27 16:25:41 2011 From: stutzbach at google.com (Daniel Stutzbach) Date: Sun, 27 Feb 2011 07:25:41 -0800 Subject: [Python-Dev] [Python-checkins] hooks: Fix checkbranch hook In-Reply-To: References: <4D69726F.5000803@netwok.org> <20110226225025.691466c8@pitrou.net> <4D698AF3.1010207@netwok.org> <4D69FCAC.8000808@v.loewis.de> Message-ID: On Sat, Feb 26, 2011 at 11:48 PM, Nick Coghlan wrote: > On Sun, Feb 27, 2011 at 5:26 PM, "Martin v. L?wis" > wrote: > > If you think that it's a likely problem that people create named > > branches by mistake, then we should have a hook. > > I suspect the concern is that people may create named branches locally > as part of their own workflow, then mistakenly push those branches > instead of collapsing back to a single commit against the relevant > line of development. > +1 -- Daniel Stutzbach -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Sun Feb 27 16:22:48 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 27 Feb 2011 16:22:48 +0100 Subject: [Python-Dev] devguide (hg_transition): Minor edits and typo fixes. References: Message-ID: <20110227162248.70b2195b@pitrou.net> On Sun, 27 Feb 2011 04:17:09 +0100 eric.araujo wrote: > > - Move a link target after its use > - Add a todo about tracker markup > - Remove one XXX that was in a warning block, not a comment Well, this is a XXX because that means we could find something else to advocate, not because the reader must take it as a warning. From scott+python-dev at scottdial.com Sun Feb 27 16:35:43 2011 From: scott+python-dev at scottdial.com (Scott Dial) Date: Sun, 27 Feb 2011 10:35:43 -0500 Subject: [Python-Dev] devguide (hg_transition): Advertise hg import over patch. In-Reply-To: <20110227161843.6c71f8d1@pitrou.net> References: <20110227161843.6c71f8d1@pitrou.net> Message-ID: <4D6A6F4F.40907@scottdial.com> On 2/27/2011 10:18 AM, Antoine Pitrou wrote: > Well, chances are TortoiseHG comes with an UI to apply patches > (TortoiseSVN had one), so the command-line instructions may be of > little use to them. I don't believe TortoiseHG has such a feature (or I can't find it), although if you have TortoiseSVN, you can still use that as a patch tool. -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu From adrian at cadifra.com Sun Feb 27 17:01:37 2011 From: adrian at cadifra.com (Adrian Buehlmann) Date: Sun, 27 Feb 2011 17:01:37 +0100 Subject: [Python-Dev] devguide (hg_transition): Advertise hg import over patch. In-Reply-To: <4D6A6F4F.40907@scottdial.com> References: <20110227161843.6c71f8d1@pitrou.net> <4D6A6F4F.40907@scottdial.com> Message-ID: <4D6A7561.8040801@cadifra.com> On 2011-02-27 16:35, Scott Dial wrote: > On 2/27/2011 10:18 AM, Antoine Pitrou wrote: >> Well, chances are TortoiseHG comes with an UI to apply patches >> (TortoiseSVN had one), so the command-line instructions may be of >> little use to them. > > I don't believe TortoiseHG has such a feature (or I can't find it), > although if you have TortoiseSVN, you can still use that as a patch tool. TortoiseHg can import patches just fine. FWIW, we are very close to releasing TortoiseHg 2.0 (due March 1st), which ported the current Gtk based TortoiseHg to Qt (although, it was more like a rewrite :-). For the old Gtk TortoiseHg, see the online docs here: http://tortoisehg.bitbucket.org/manual/1.1/patches.html#import-patches Homepage for the Qt port: https://bitbucket.org/tortoisehg/thg/wiki/Home For people on Windows, we have beta installers for the new Qt based TortoiseHg at: https://bitbucket.org/tortoisehg/thg/downloads Feedback is welcome on thg-dev at googlegroups.com or tortoisehg-discuss at lists.sourceforge.net (we moved the development list to google groups) From merwok at netwok.org Sun Feb 27 17:20:46 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sun, 27 Feb 2011 17:20:46 +0100 Subject: [Python-Dev] devguide (hg_transition): patchcheck does work In-Reply-To: <20110227162115.0a2cda9f@pitrou.net> References: <20110227162115.0a2cda9f@pitrou.net> Message-ID: <4D6A79DE.1030909@netwok.org> Le 27/02/2011 16:21, Antoine Pitrou a ?crit : >> summary: >> patchcheck does work > How does it find out which changesets it should operate on? It operates on changed files, just like with Subversion: http://hg.python.org/cpython/file/tip/Tools/scripts/patchcheck.py#l40 ? hg status --added --modified --no-status You can use it while making a commit, or when you collapse many commits into one diff (and apply it with hg import --no-commit). Rewriting patchcheck to work on diffs is another thing, see http://bugs.python.org/issue8999#msg109255 I agree that the part about patchcheck should have a note to explain that it works with uncommitted changes, not MQ patches or changesets. Regards From merwok at netwok.org Sun Feb 27 17:23:44 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Sun, 27 Feb 2011 17:23:44 +0100 Subject: [Python-Dev] devguide (hg_transition): Minor edits and typo fixes. In-Reply-To: <20110227162248.70b2195b@pitrou.net> References: <20110227162248.70b2195b@pitrou.net> Message-ID: <4D6A7A90.8020002@netwok.org> Le 27/02/2011 16:22, Antoine Pitrou a ?crit : >> - Remove one XXX that was in a warning block, not a comment > Well, this is a XXX because that means we could find something else to > advocate, not because the reader must take it as a warning. My point was that that should be either a comment with an XXX marker or a user-visible reST warning. I chose the latter, I have no problem changing it to the former. Regards From g.brandl at gmx.net Sun Feb 27 17:38:26 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Sun, 27 Feb 2011 17:38:26 +0100 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110226154939.41972d08@limelight.wooz.org> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> <20110226154939.41972d08@limelight.wooz.org> Message-ID: On 26.02.2011 21:49, Barry Warsaw wrote: > On Feb 26, 2011, at 01:49 AM, ?ric Araujo wrote: > >>You speak to my heart, sir. In your ~/.hgrc, under the section [ui], >>set ?editor = path/to/mercurial/source/hgeditor? and enjoy your diffs. >>I use it and love it. > > Except it doesn't quite work the way I want it to (hg 1.6.3). It opens your > editor with two files, one is the commit message and the other is the diff. > (The script itself is a bit buggy too. ;) > > But it's a good clue, and I've modified the default hgeditor script to get > closer, and fix the bug I noticed. I basically append the diff to the > temporary log message file. It's still not right though because if the diff > lines aren't prepended with 'HG:', they end up in the commit message. Arg. > > Oh well, I can clearly hack a more complicated script together. It's such a > blindingly obvious improvement, it's too bad 'hg commit' doesn't DTRT by > default. While I understand the usefulness of the diff feature, it is not useful to everyone, e.g. those using almost exclusively ``commit -m message``. Of course it would be nice if hg made it easier (a hgrc option, for example) to do this. BTW, I had not heard of hgeditor before, and wrote a small hg extension to do what you want (with HG: prefix :) before I saw that others had already replied with hgeditor. The extension had 10 lines of code. Georg From martin at v.loewis.de Sun Feb 27 19:20:04 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 27 Feb 2011 19:20:04 +0100 Subject: [Python-Dev] hg extensions was Mercurial conversion repositories In-Reply-To: <20110227161201.0d0b215d@pitrou.net> References: <20110227015948.5906fd2f@pitrou.net> <4D69F35B.3020602@v.loewis.de> <20110227161201.0d0b215d@pitrou.net> Message-ID: <4D6A95D4.5030902@v.loewis.de> >> I think this is overly optimistic. Visual Studio will break all your >> files if you don't use that extension (and you actually use it to >> modify source code). > > My assumption was that most developers don't use MSVC, so most of them > don't risk breaking eols ;) > True, for Windows devs it might be necessary to promote it. If I change code on Windows, I always use MSVC to edit it. It's best integrated with the build process and the debugger. If I change Python code on Windows, I use vim or IDLE. Different MSVC releases took different approaches wrt. LF-separated files. For a long time, new lines added would be CRLF, whereas existing line endings would remain unchanged, resulting in a mix of line endings. It appears that VS 2008 now uniformly converts the entire file to CRLF on first edit. Regards, Martin From martin at v.loewis.de Sun Feb 27 19:22:28 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 27 Feb 2011 19:22:28 +0100 Subject: [Python-Dev] hg extensions was Mercurial conversion repositories In-Reply-To: References: <20110227015948.5906fd2f@pitrou.net> <4D69F35B.3020602@v.loewis.de> <20110227161201.0d0b215d@pitrou.net> Message-ID: <4D6A9664.6070204@v.loewis.de> >> My assumption was that most developers don't use MSVC, so most of them >> don't risk breaking eols ;) >> True, for Windows devs it might be necessary to promote it. > > Windows devs were the original target audience, yes :) I meant to say that earlier: thanks to everybody involved in the original development of the eol extension. It originated from python-dev, and, with the switchover taking so long as it took, it's a standard extension of Mercurial releases by now. In the Tortoise Global Settings GUI, there is even a checkbox to activate it. Regards, Martin From greg.ewing at canterbury.ac.nz Sun Feb 27 21:28:57 2011 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Mon, 28 Feb 2011 09:28:57 +1300 Subject: [Python-Dev] Let's get PEP 380 into Python 3.3 In-Reply-To: References: Message-ID: <4D6AB409.40001@canterbury.ac.nz> Guido van Rossum wrote: > Ok. Will you hvae time to port your patches to 3.3? I'm not sure -- I'll see what I can do. -- Greg From nyamatongwe at gmail.com Sun Feb 27 23:11:47 2011 From: nyamatongwe at gmail.com (Neil Hodgson) Date: Mon, 28 Feb 2011 09:11:47 +1100 Subject: [Python-Dev] devguide (hg_transition): Advertise hg import over patch. In-Reply-To: <4D6A6F4F.40907@scottdial.com> References: <20110227161843.6c71f8d1@pitrou.net> <4D6A6F4F.40907@scottdial.com> Message-ID: Scott Dial: > I don't believe TortoiseHG has such a feature (or I can't find it), > although if you have TortoiseSVN, you can still use that as a patch tool. The Import... command is in the Synchronize menu of Hg Repository Explorer. There is no GUI equivalent to --no-commit but you can exit the commit message editor without saving which causes the commit to be abandoned with the patch still having been applied. Neil From nyamatongwe at gmail.com Sun Feb 27 23:21:51 2011 From: nyamatongwe at gmail.com (Neil Hodgson) Date: Mon, 28 Feb 2011 09:21:51 +1100 Subject: [Python-Dev] devguide (hg_transition): Advertise hg import over patch. In-Reply-To: <4D6A7561.8040801@cadifra.com> References: <20110227161843.6c71f8d1@pitrou.net> <4D6A6F4F.40907@scottdial.com> <4D6A7561.8040801@cadifra.com> Message-ID: Adrian Buehlmann: > FWIW, we are very close to releasing TortoiseHg 2.0 (due March 1st), > which ported the current Gtk based TortoiseHg to Qt (although, it was > more like a rewrite :-). I hope this is going to be fast. One of the reasons I chose Hg over Bzr for another project was that the Bzr GUI tools which are written using Qt are much slower, particularly when starting. A cold start of Bazaar Explorer takes around 7 seconds on a new fast machine compared with under a second to launch Hg Repository Explorer. Warm starts and internal actions are better but the Hg GUI tools are still much smoother than Bzr's. This slowness is quite common for Qt applications and I think is because of the large set of DLLs that are loaded. Qt Creator is better at around 4 seconds for a cold launch but, naturally, it doesn't matter for an environment which you use for an extended period like Qt Creator. It does matter for a VCS tool that you may invoke hundreds of times in a day. Neil From adrian at cadifra.com Mon Feb 28 00:10:10 2011 From: adrian at cadifra.com (Adrian Buehlmann) Date: Mon, 28 Feb 2011 00:10:10 +0100 Subject: [Python-Dev] devguide (hg_transition): Advertise hg import over patch. In-Reply-To: References: <20110227161843.6c71f8d1@pitrou.net> <4D6A6F4F.40907@scottdial.com> <4D6A7561.8040801@cadifra.com> Message-ID: <4D6AD9D2.7060901@cadifra.com> On 2011-02-27 23:21, Neil Hodgson wrote: > Adrian Buehlmann: > >> FWIW, we are very close to releasing TortoiseHg 2.0 (due March 1st), >> which ported the current Gtk based TortoiseHg to Qt (although, it was >> more like a rewrite :-). > > I hope this is going to be fast. Here, the Workbench window [1] starts in under 2s (Windows 7 x64 on Intel Core2 Quad). As installed with the x64 msi (installs true 64 bit exe's, including 64 bit command line hg). There's quite a lot of demand loading behind the scenes. So it's fast even for repos with many changesets. [1] http://tortoisehg.bitbucket.org/manual/2.0/workbench.html (brand new first manual version by Steve was just uploaded a few minutes ago :) From stephen at xemacs.org Mon Feb 28 04:29:24 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 28 Feb 2011 12:29:24 +0900 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110225164600.415f8e04@limelight.wooz.org> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D680B3C.4040209@freehackers.org> <20110225164600.415f8e04@limelight.wooz.org> Message-ID: <87lj10degb.fsf@uwakimon.sk.tsukuba.ac.jp> Barry Warsaw writes: > You mean, TortoiseHg supports incremental commits on a single file? That's > kind of neat, but scary. ;) Darcs people have been doing this for, well, for as long as Darcs has existed. It's not scary at all. In fact, in Darcs you can select hunks across files, too. From barry at python.org Mon Feb 28 16:08:26 2011 From: barry at python.org (Barry Warsaw) Date: Mon, 28 Feb 2011 10:08:26 -0500 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> <20110226154939.41972d08@limelight.wooz.org> Message-ID: <20110228100826.6812ad30@limelight.wooz.org> On Feb 27, 2011, at 05:38 PM, Georg Brandl wrote: >While I understand the usefulness of the diff feature, it is not useful to >everyone, e.g. those using almost exclusively ``commit -m message``. The editor window doesn't pop up when you provide the -m flag, so the diff output is not relevant. >Of course it would be nice if hg made it easier (a hgrc option, for example) >to do this. Sure. >BTW, I had not heard of hgeditor before, and wrote a small hg extension to >do what you want (with HG: prefix :) before I saw that others had already >replied with hgeditor. The extension had 10 lines of code. We should find a place (i.e. repository) to stash these useful add-ons and hacks so that all Python developers can find them. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From solipsis at pitrou.net Mon Feb 28 16:15:38 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 28 Feb 2011 16:15:38 +0100 Subject: [Python-Dev] Mercurial conversion repositories References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> <20110226154939.41972d08@limelight.wooz.org> <20110228100826.6812ad30@limelight.wooz.org> Message-ID: <20110228161538.36b825ac@pitrou.net> On Mon, 28 Feb 2011 10:08:26 -0500 Barry Warsaw wrote: > > >BTW, I had not heard of hgeditor before, and wrote a small hg extension to > >do what you want (with HG: prefix :) before I saw that others had already > >replied with hgeditor. The extension had 10 lines of code. > > We should find a place (i.e. repository) to stash these useful add-ons and > hacks so that all Python developers can find them. I think you can simply add them somewhere on the hg wiki: http://mercurial.selenic.com/wiki/ and then link to the pages from our own wiki, or the developer's FAQ. Regards Antoine. From solipsis at pitrou.net Mon Feb 28 16:19:10 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 28 Feb 2011 16:19:10 +0100 Subject: [Python-Dev] devguide (hg_transition): Advertise hg import over patch. References: <20110227161843.6c71f8d1@pitrou.net> <4D6A6F4F.40907@scottdial.com> <4D6A7561.8040801@cadifra.com> <4D6AD9D2.7060901@cadifra.com> Message-ID: <20110228161910.4f88407a@pitrou.net> On Mon, 28 Feb 2011 00:10:10 +0100 Adrian Buehlmann wrote: > > Here, the Workbench window [1] starts in under 2s (Windows 7 x64 on > Intel Core2 Quad). As installed with the x64 msi (installs true 64 bit > exe's, including 64 bit command line hg). > > There's quite a lot of demand loading behind the scenes. So it's fast > even for repos with many changesets. > > [1] http://tortoisehg.bitbucket.org/manual/2.0/workbench.html I have to say the TortoiseHg manual looks impressively comprehensive! Regards Antoine. From solipsis at pitrou.net Mon Feb 28 19:15:58 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 28 Feb 2011 19:15:58 +0100 Subject: [Python-Dev] Please sync your feature branches Message-ID: <20110228191558.6cfeaef7@pitrou.net> Hello, In preparation for the hg switch, I would recommend that, if you have any feature branches managed with svnmerge, you sync them with the py3k branch before we switch. That way, it will make it easier to "bridge the gap" when you create a new repository for your work after the switch (the svnmerge information isn't retained in the converted repo). For the record, and as mentioned in the updated PEP 385, we plan to do the final conversion on the 5th (that is next Saturday). Regards Antoine. From g.brandl at gmx.net Mon Feb 28 19:51:04 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Mon, 28 Feb 2011 19:51:04 +0100 Subject: [Python-Dev] Please sync your feature branches In-Reply-To: <20110228191558.6cfeaef7@pitrou.net> References: <20110228191558.6cfeaef7@pitrou.net> Message-ID: On 28.02.2011 19:15, Antoine Pitrou wrote: > > Hello, > > In preparation for the hg switch, I would recommend that, if you have > any feature branches managed with svnmerge, you sync them with the py3k > branch before we switch. That way, it will make it easier to "bridge > the gap" when you create a new repository for your work after the > switch (the svnmerge information isn't retained in the converted repo). > > For the record, and as mentioned in the updated PEP 385, we plan to do > the final conversion on the 5th (that is next Saturday). And similarly, please backport any pending changesets (using svnmerge or not), so that we're prepared for the new workflow. Georg From solipsis at pitrou.net Mon Feb 28 20:54:42 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 28 Feb 2011 20:54:42 +0100 Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt References: <20110228182236.5F675EE982@mail.python.org> <4D6BEB1B.1040004@udel.edu> Message-ID: <20110228205442.257dcae1@pitrou.net> On Mon, 28 Feb 2011 13:36:11 -0500 Terry Reedy wrote: > > > + an existing branch. The pusher then has to merge the superfetatory heads > > 'superfetatory'? I have no idea of what this is, neither does > merriam-webster.com ;-). There are some Google hits, though... Not sure if they are of people making the same mistakes as I do ;) Regards Antoine. From benjamin at python.org Mon Feb 28 20:56:23 2011 From: benjamin at python.org (Benjamin Peterson) Date: Mon, 28 Feb 2011 13:56:23 -0600 Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt In-Reply-To: <20110228205442.257dcae1@pitrou.net> References: <20110228182236.5F675EE982@mail.python.org> <4D6BEB1B.1040004@udel.edu> <20110228205442.257dcae1@pitrou.net> Message-ID: 2011/2/28 Antoine Pitrou : > On Mon, 28 Feb 2011 13:36:11 -0500 > Terry Reedy wrote: >> >> > + ?an existing branch. ?The pusher then has to merge the superfetatory heads >> >> 'superfetatory'? I have no idea of what this is, neither does >> merriam-webster.com ;-). > > There are some Google hits, though... Not sure if they are of people > making the same mistakes as I do ;) Endly, perhaps it will be adopted. Did you mean "superfluous" though? -- Regards, Benjamin From solipsis at pitrou.net Mon Feb 28 20:58:56 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 28 Feb 2011 20:58:56 +0100 Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt In-Reply-To: References: <20110228182236.5F675EE982@mail.python.org> <4D6BEB1B.1040004@udel.edu> <20110228205442.257dcae1@pitrou.net> Message-ID: <1298923136.3692.4.camel@localhost.localdomain> Le lundi 28 f?vrier 2011 ? 13:56 -0600, Benjamin Peterson a ?crit : > 2011/2/28 Antoine Pitrou : > > On Mon, 28 Feb 2011 13:36:11 -0500 > > Terry Reedy wrote: > >> > >> > + an existing branch. The pusher then has to merge the superfetatory heads > >> > >> 'superfetatory'? I have no idea of what this is, neither does > >> merriam-webster.com ;-). > > > > There are some Google hits, though... Not sure if they are of people > > making the same mistakes as I do ;) > > Endly, perhaps it will be adopted. Did you mean "superfluous" though? I really meant superfetatory (it's slightly different: superfluous is simply useless, while superfetatory implies that it's in excess). From benjamin at python.org Mon Feb 28 21:01:19 2011 From: benjamin at python.org (Benjamin Peterson) Date: Mon, 28 Feb 2011 14:01:19 -0600 Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt In-Reply-To: <1298923136.3692.4.camel@localhost.localdomain> References: <20110228182236.5F675EE982@mail.python.org> <4D6BEB1B.1040004@udel.edu> <20110228205442.257dcae1@pitrou.net> <1298923136.3692.4.camel@localhost.localdomain> Message-ID: 2011/2/28 Antoine Pitrou : > Le lundi 28 f?vrier 2011 ? 13:56 -0600, Benjamin Peterson a ?crit : >> 2011/2/28 Antoine Pitrou : >> > On Mon, 28 Feb 2011 13:36:11 -0500 >> > Terry Reedy wrote: >> >> >> >> > + ?an existing branch. ?The pusher then has to merge the superfetatory heads >> >> >> >> 'superfetatory'? I have no idea of what this is, neither does >> >> merriam-webster.com ;-). >> > >> > There are some Google hits, though... Not sure if they are of people >> > making the same mistakes as I do ;) >> >> Endly, perhaps it will be adopted. Did you mean "superfluous" though? > > I really meant superfetatory (it's slightly different: superfluous is > simply useless, while superfetatory implies that it's in excess). superfluous - "in excess of what is required or sufficient" -- Regards, Benjamin From g.brandl at gmx.net Mon Feb 28 21:07:58 2011 From: g.brandl at gmx.net (Georg Brandl) Date: Mon, 28 Feb 2011 21:07:58 +0100 Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt In-Reply-To: <1298923136.3692.4.camel@localhost.localdomain> References: <20110228182236.5F675EE982@mail.python.org> <4D6BEB1B.1040004@udel.edu> <20110228205442.257dcae1@pitrou.net> <1298923136.3692.4.camel@localhost.localdomain> Message-ID: On 28.02.2011 20:58, Antoine Pitrou wrote: > Le lundi 28 f?vrier 2011 ? 13:56 -0600, Benjamin Peterson a ?crit : >> 2011/2/28 Antoine Pitrou : >> > On Mon, 28 Feb 2011 13:36:11 -0500 >> > Terry Reedy wrote: >> >> >> >> > + an existing branch. The pusher then has to merge the superfetatory heads >> >> >> >> 'superfetatory'? I have no idea of what this is, neither does >> >> merriam-webster.com ;-). >> > >> > There are some Google hits, though... Not sure if they are of people >> > making the same mistakes as I do ;) >> >> Endly, perhaps it will be adopted. Did you mean "superfluous" though? > > I really meant superfetatory (it's slightly different: superfluous is > simply useless, while superfetatory implies that it's in excess). Maybe "supernumerary" serves? Georg From raymond.hettinger at gmail.com Mon Feb 28 21:53:14 2011 From: raymond.hettinger at gmail.com (Raymond Hettinger) Date: Mon, 28 Feb 2011 12:53:14 -0800 Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt In-Reply-To: References: <20110228182236.5F675EE982@mail.python.org> <4D6BEB1B.1040004@udel.edu> <20110228205442.257dcae1@pitrou.net> <1298923136.3692.4.camel@localhost.localdomain> Message-ID: <9774EE64-D7E2-40BB-B1D1-892B70652E4F@gmail.com> On Feb 28, 2011, at 12:07 PM, Georg Brandl wrote: > On 28.02.2011 20:58, Antoine Pitrou wrote: >> Le lundi 28 f?vrier 2011 ? 13:56 -0600, Benjamin Peterson a ?crit : >>> 2011/2/28 Antoine Pitrou : >>>> On Mon, 28 Feb 2011 13:36:11 -0500 >>>> Terry Reedy wrote: >>>>> >>>>>> + an existing branch. The pusher then has to merge the superfetatory heads >>>>> >>>>> 'superfetatory'? I have no idea of what this is, neither does >>>>> merriam-webster.com ;-). >>>> >>>> There are some Google hits, though... Not sure if they are of people >>>> making the same mistakes as I do ;) >>> >>> Endly, perhaps it will be adopted. Did you mean "superfluous" though? >> >> I really meant superfetatory (it's slightly different: superfluous is >> simply useless, while superfetatory implies that it's in excess). > > Maybe "supernumerary" serves? Plain, everyday English would serve better than using words which people need to look-up. How about: "The pusher should the merge extra, unused heads" or somesuch. Raymond From barry at python.org Mon Feb 28 22:07:48 2011 From: barry at python.org (Barry Warsaw) Date: Mon, 28 Feb 2011 16:07:48 -0500 Subject: [Python-Dev] Mercurial conversion repositories In-Reply-To: <20110228161538.36b825ac@pitrou.net> References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> <20110226154939.41972d08@limelight.wooz.org> <20110228100826.6812ad30@limelight.wooz.org> <20110228161538.36b825ac@pitrou.net> Message-ID: <20110228160748.1be8b814@limelight.wooz.org> On Feb 28, 2011, at 04:15 PM, Antoine Pitrou wrote: >On Mon, 28 Feb 2011 10:08:26 -0500 >Barry Warsaw wrote: >> >> >BTW, I had not heard of hgeditor before, and wrote a small hg extension to >> >do what you want (with HG: prefix :) before I saw that others had already >> >replied with hgeditor. The extension had 10 lines of code. >> >> We should find a place (i.e. repository) to stash these useful add-ons and >> hacks so that all Python developers can find them. > >I think you can simply add them somewhere on the hg wiki: >http://mercurial.selenic.com/wiki/ >and then link to the pages from our own wiki, or the developer's FAQ. If they're of general use to the hg community, sure. Otherwise, it might be good to have a place of our own for our own repository tools. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From solipsis at pitrou.net Mon Feb 28 22:10:34 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 28 Feb 2011 22:10:34 +0100 Subject: [Python-Dev] Mercurial conversion repositories References: <20110225011904.3ed09de7@pitrou.net> <4D6763C0.3030904@v.loewis.de> <8219A855-64DC-4DF0-A067-DAE20BF98A73@gmail.com> <20110225111253.2f34357e@limelight.wooz.org> <4D67E9A5.5030203@cadifra.com> <20110225144315.3eebcafc@limelight.wooz.org> <4D684E2A.90005@netwok.org> <20110226154939.41972d08@limelight.wooz.org> <20110228100826.6812ad30@limelight.wooz.org> <20110228161538.36b825ac@pitrou.net> <20110228160748.1be8b814@limelight.wooz.org> Message-ID: <20110228221034.53ebe810@pitrou.net> On Mon, 28 Feb 2011 16:07:48 -0500 Barry Warsaw wrote: > On Feb 28, 2011, at 04:15 PM, Antoine Pitrou wrote: > > >On Mon, 28 Feb 2011 10:08:26 -0500 > >Barry Warsaw wrote: > >> > >> >BTW, I had not heard of hgeditor before, and wrote a small hg extension to > >> >do what you want (with HG: prefix :) before I saw that others had already > >> >replied with hgeditor. The extension had 10 lines of code. > >> > >> We should find a place (i.e. repository) to stash these useful add-ons and > >> hacks so that all Python developers can find them. > > > >I think you can simply add them somewhere on the hg wiki: > >http://mercurial.selenic.com/wiki/ > >and then link to the pages from our own wiki, or the developer's FAQ. > > If they're of general use to the hg community, sure. Otherwise, it might be > good to have a place of our own for our own repository tools. Well, your diff-in-the-commit-editor-window is certainly not CPython-specific ;) Regards Antoine. From martin at v.loewis.de Mon Feb 28 22:59:43 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 28 Feb 2011 22:59:43 +0100 Subject: [Python-Dev] Finding buildbot failures In-Reply-To: <4D68FD31.70901@voidspace.org.uk> References: <4D67F959.8080701@voidspace.org.uk> <20110225190014.2231.1678753723.divmod.xquotient.58@localhost.localdomain> <4D68FD31.70901@voidspace.org.uk> Message-ID: <4D6C1ACF.3030503@v.loewis.de> >>> That's one of the big advantages that Jenkins (nee Hudson) has over >>> buildbot - drilling down into individual test failures through the >>> web ui. Your test run needs to generate appropriate xml for that to >>> work though. >> >> Buildbot can do this too. It can even do it without xml, although it >> does need *some* parseable format, which I think the Python test suite >> is a long way from. >> > > That would be a great improvement to the Python buildbot infrastructure. So would you be willing to contribute the necessary changes? Regards, Martin From martin at v.loewis.de Mon Feb 28 23:26:19 2011 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 28 Feb 2011 23:26:19 +0100 Subject: [Python-Dev] Please sync your feature branches In-Reply-To: <20110228191558.6cfeaef7@pitrou.net> References: <20110228191558.6cfeaef7@pitrou.net> Message-ID: <4D6C210B.2010709@v.loewis.de> > In preparation for the hg switch, I would recommend that, if you have > any feature branches managed with svnmerge, you sync them with the py3k > branch before we switch. That way, it will make it easier to "bridge > the gap" when you create a new repository for your work after the > switch (the svnmerge information isn't retained in the converted repo). Is that really going to work? I.e. will Mercurial be able to merge from default to one of the feature branches? If so, what will be the procedure? What would be the exact steps to try this out on the PEP 382 branch (say)? Regards, Martin From solipsis at pitrou.net Mon Feb 28 23:45:06 2011 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 28 Feb 2011 23:45:06 +0100 Subject: [Python-Dev] Please sync your feature branches In-Reply-To: <4D6C210B.2010709@v.loewis.de> References: <20110228191558.6cfeaef7@pitrou.net> <4D6C210B.2010709@v.loewis.de> Message-ID: <1298933106.3692.10.camel@localhost.localdomain> Le lundi 28 f?vrier 2011 ? 23:26 +0100, "Martin v. L?wis" a ?crit : > > In preparation for the hg switch, I would recommend that, if you have > > any feature branches managed with svnmerge, you sync them with the py3k > > branch before we switch. That way, it will make it easier to "bridge > > the gap" when you create a new repository for your work after the > > switch (the svnmerge information isn't retained in the converted repo). > > Is that really going to work? I.e. will Mercurial be able to merge from > default to one of the feature branches? If so, what will be the > procedure? What would be the exact steps to try this out on the PEP 382 > branch (say)? I've sketched out the steps in http://potrou.net/hgdevguide/committing.html#long-term-development-of-features It doesn't cover importing work from SVN, but it should be as simple as "apply your current patch" where the text says "You can now work on your feature". A caveat of these instructions is that pushing a whole cpython-based repo will be quite slow unless you have a large upload bandwidth (most users have asymmetric connections). So we would like to offer a special command for committers to make a clone of a repository *from the server, to the server*. In my current prototype this is spelled as: ssh hg at hg.python.org clone for example: ssh hg at hg.python.org clone cpython features/pep-382 where "features/pep-382" will be a new repo on hg.python.org cloned from the cpython repo on hg.python.org. Meaning no heavy network transfer occurs. Then you clone the dest repo and the only changesets will have to push will be those representing your own work. If you think the "remote clone" trick above is good enough, I'll publicize it in the devguide. Regards Antoine. From steve at pearwood.info Mon Feb 28 23:40:56 2011 From: steve at pearwood.info (Steven D'Aprano) Date: Tue, 01 Mar 2011 09:40:56 +1100 Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt In-Reply-To: <1298923136.3692.4.camel@localhost.localdomain> References: <20110228182236.5F675EE982@mail.python.org> <4D6BEB1B.1040004@udel.edu> <20110228205442.257dcae1@pitrou.net> <1298923136.3692.4.camel@localhost.localdomain> Message-ID: <4D6C2478.2070201@pearwood.info> Antoine Pitrou wrote: > Le lundi 28 f?vrier 2011 ? 13:56 -0600, Benjamin Peterson a ?crit : >> 2011/2/28 Antoine Pitrou : >>> On Mon, 28 Feb 2011 13:36:11 -0500 >>> Terry Reedy wrote: >>>>> + an existing branch. The pusher then has to merge the superfetatory heads >>>> 'superfetatory'? I have no idea of what this is, neither does >>>> merriam-webster.com ;-). >>> There are some Google hits, though... Not sure if they are of people >>> making the same mistakes as I do ;) >> Endly, perhaps it will be adopted. Did you mean "superfluous" though? > > I really meant superfetatory (it's slightly different: superfluous is > simply useless, while superfetatory implies that it's in excess). My wife has a copy of the shorter Oxford English dictionary, so we looked it up. There's no listing for superfetatory, but there is "superfetation": 1. a second conception occurring during pregnancy; the formation of a second fetus in a uterus already pregnant; 1b. botany the fertilization of the same ovule by two different kinds of pollen; 2. (figurative) additional or super-abundant production or occurrence; the growth or accretion of one thing on another; and instance of this; an accretion; an excrescence. She commented that sesquipedalian words like superfetation are probably either specialised jargon, or known by people like Clive James and very few others :) I think that superfluous simply means "excess to requirements but merely useless", while superfetatory would imply harmfully in excess. In any case, it's a wonderful word and I will try to casually drop it into conversation every now and then to annoy people *wink* -- Steven From martin at v.loewis.de Mon Feb 28 23:54:46 2011 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Mon, 28 Feb 2011 23:54:46 +0100 Subject: [Python-Dev] Please sync your feature branches In-Reply-To: <1298933106.3692.10.camel@localhost.localdomain> References: <20110228191558.6cfeaef7@pitrou.net> <4D6C210B.2010709@v.loewis.de> <1298933106.3692.10.camel@localhost.localdomain> Message-ID: <4D6C27B6.5000601@v.loewis.de> Am 28.02.2011 23:45, schrieb Antoine Pitrou: > Le lundi 28 f?vrier 2011 ? 23:26 +0100, "Martin v. L?wis" a ?crit : >>> In preparation for the hg switch, I would recommend that, if you have >>> any feature branches managed with svnmerge, you sync them with the py3k >>> branch before we switch. That way, it will make it easier to "bridge >>> the gap" when you create a new repository for your work after the >>> switch (the svnmerge information isn't retained in the converted repo). >> >> Is that really going to work? I.e. will Mercurial be able to merge from >> default to one of the feature branches? If so, what will be the >> procedure? What would be the exact steps to try this out on the PEP 382 >> branch (say)? > > I've sketched out the steps in > http://potrou.net/hgdevguide/committing.html#long-term-development-of-features > > It doesn't cover importing work from SVN But that's what I was specifically asking about: if I svnmerge my feature branch now - what specifically do I gain? Why are you asking me to do that? Why does doing so make it easier to "bridge the gap"? Regards, Martin From merwok at netwok.org Mon Feb 28 23:56:56 2011 From: merwok at netwok.org (=?UTF-8?B?w4lyaWMgQXJhdWpv?=) Date: Mon, 28 Feb 2011 23:56:56 +0100 Subject: [Python-Dev] r88676 - peps/trunk/pep-0385.txt In-Reply-To: <4D6C2478.2070201@pearwood.info> References: <20110228182236.5F675EE982@mail.python.org> <4D6BEB1B.1040004@udel.edu> <20110228205442.257dcae1@pitrou.net> <1298923136.3692.4.camel@localhost.localdomain> <4D6C2478.2070201@pearwood.info> Message-ID: <4D6C2838.4000706@netwok.org> > I really meant superfetatory Those damn French people with their foreign words.