Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Mon, 15 Oct 2012 23:18:04 -0700, Ned Deily wrote: > In article <20121016043352.ga21...@snakebite.org>, > Trent Nelson wrote: > > Any objections to regenerating configure with autoconf 2.69? The > > current version is based off 2.68, which was release on the 22nd > > of September 2010. 2.69 was released on the 24th of April, 2012. > > > > (There are some fixes for the more esoteric UNIX platforms that > > Snakebite will benefit from. Also, I struggled to find a box > > with 2.68 even installed when I needed to regenerate configure > > this weekend; it seems all package management/ports have bumped > > to 2.69.) > > > > If there are no objections, can it be applied across the board? > > 2.7, 3.2, 3.3 and 3.x? > > I believe it is the case that we don't currently require a specific > version of autoconf. autoconf is only run when making a committer makes > a change to configure.ac et al and then it is run on the committer's > machine. So whatever is checked in for those files reflects the version > of autoconf that the committer used. My understanding is that we use a specific version of autoconf. The reason is that otherwise we end up with useless churn in the repo as the generated file changes when different committers use different versions. In the past we have had issues with a new autoconf version actually breaking the Python build, so we also need to test a new version before switching to it. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Tue, Oct 16, 2012 at 12:12:35AM -0700, R. David Murray wrote: > On Mon, 15 Oct 2012 23:18:04 -0700, Ned Deily wrote: > > In article <20121016043352.ga21...@snakebite.org>, > > Trent Nelson wrote: > > > Any objections to regenerating configure with autoconf 2.69? The > > > current version is based off 2.68, which was release on the 22nd > > > of September 2010. 2.69 was released on the 24th of April, 2012. > > > > > > (There are some fixes for the more esoteric UNIX platforms that > > > Snakebite will benefit from. Also, I struggled to find a box > > > with 2.68 even installed when I needed to regenerate configure > > > this weekend; it seems all package management/ports have bumped > > > to 2.69.) > > > > > > If there are no objections, can it be applied across the board? > > > 2.7, 3.2, 3.3 and 3.x? > > > > I believe it is the case that we don't currently require a specific > > version of autoconf. autoconf is only run when making a committer makes > > a change to configure.ac et al and then it is run on the committer's > > machine. So whatever is checked in for those files reflects the version > > of autoconf that the committer used. > > My understanding is that we use a specific version of autoconf. > The reason is that otherwise we end up with useless churn in the repo > as the generated file changes when different committers use different > versions. Indeed; the 2.68->2.69 bump results in a 746 line diff for configure. > In the past we have had issues with a new autoconf version > actually breaking the Python build, so we also need to test a new version > before switching to it. If there are no objections in principle to the bump (i.e. nobody is aware of any existing 2.69 incompatibilities), my plan is to bump, then make sure all the build slaves and Snakebite machines work with the new version. If 2.69 introduces insurmountable build issues, I'll simply revert back to 2.68 (with some notes at the top of configure.ac mentioning the issues with 2.69). Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
In article <20121016071236.0792d250...@webabinitio.net>, "R. David Murray" wrote: > My understanding is that we use a specific version of autoconf. > The reason is that otherwise we end up with useless churn in the repo > as the generated file changes when different committers use different > versions. In the past we have had issues with a new autoconf version > actually breaking the Python build, so we also need to test a new version > before switching to it. Well, there was a test in the past for a specific version of autoconf but I believe that was removed. I see that the default branch configure.ac contains AC_PREREQ(2.65) but the most recently checked-in version of configure was generated with 2.68. I understand about the desirability of avoiding a lot of churn although it seems to me to not be a huge thing; build breaking is another matter, of course. If we are going to mandate a specific version again, that should be documented and checked for. -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues Pending Review
On 14.10.12 21:38, mar...@v.loewis.de wrote: In case nobody picks it up, my 5-for-1 offer still stands: if you review five issues, I'll review one of yours. What 50 issues you want I'll review. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
> My understanding is that we use a specific version of autoconf. > The reason is that otherwise we end up with useless churn in the repo > as the generated file changes when different committers use different > versions. In the past we have had issues with a new autoconf version > actually breaking the Python build, so we also need to test a new version > before switching to it. Well, so I guess all committers will have to use the same Linux/FreeBSD/whatever distribution then? AFAICT there's no requirement regarding the mercurial version used by committers either. Charles ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Tue, Oct 16, 2012 at 01:04:46AM -0700, Ned Deily wrote: > In article <20121016071236.0792d250...@webabinitio.net>, > "R. David Murray" wrote: > > My understanding is that we use a specific version of autoconf. > > The reason is that otherwise we end up with useless churn in the repo > > as the generated file changes when different committers use different > > versions. In the past we have had issues with a new autoconf version > > actually breaking the Python build, so we also need to test a new version > > before switching to it. > > Well, there was a test in the past for a specific version of autoconf > but I believe that was removed. I see that the default branch > configure.ac contains AC_PREREQ(2.65) but the most recently checked-in > version of configure was generated with 2.68. That's a good point regarding AC_PREREQ. I think there's been a general unspoken rule to try and minimize 'configure' churn, which means using the same version of autoconf that the previous person used. > I understand about the > desirability of avoiding a lot of churn although it seems to me to not > be a huge thing; I don't know, the churn is usually offensive enough to warrant using the same autoconf version. It's impossible to vet a configure.ac change if you're regenerating configure with a different version of autoconf. > build breaking is another matter, of course. If we are > going to mandate a specific version again, that should be documented and > checked for. My preference: bump to 2.69 and set AC_PREREQ(2.69). If 2.69 proves unworkable, revert back to 2.68 and AC_PREREQ(2.68). I definitely like the idea of explicitly setting the version being used via AC_PREREQ, as this will prevent accidental version churn being checked in by a committer inadvertently. > -- > Ned Deily, > n...@acm.org Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Tue, Oct 16, 2012 at 01:43:37AM -0700, Charles-François Natali wrote: > > My understanding is that we use a specific version of autoconf. > > The reason is that otherwise we end up with useless churn in the repo > > as the generated file changes when different committers use different > > versions. In the past we have had issues with a new autoconf version > > actually breaking the Python build, so we also need to test a new version > > before switching to it. > > Well, so I guess all committers will have to use the same > Linux/FreeBSD/whatever distribution then? > AFAICT there's no requirement regarding the mercurial version used by > committers either. Autoconf is a special case though. Different versions of autoconf produce wildly different outputs for 'configure', making it impossible to vet configure.ac changes by reviewing the configure diff. It doesn't matter which OS or Mercurial version a developer uses as they don't implicitly affect any versioned resources; autoconf does. Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
Charles-François Natali wrote: > Well, so I guess all committers will have to use the same > Linux/FreeBSD/whatever distribution then? > AFAICT there's no requirement regarding the mercurial version used by > committers either. It should be sufficient to install autoconf-x.y into /home/user/bin or something similar. Installing autoconf from source really takes about 3 minutes. Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
> It should be sufficient to install autoconf-x.y into /home/user/bin or > something similar. Installing autoconf from source really takes about > 3 minutes. Well, maybe, maybe not. autoconf depends on a least m4 and Perl, and you may very well have a compatibility issue here. That's why most distributions have package managers, and in 2012 we're past the './configure && make && make install". > It doesn't matter which OS or Mercurial version a developer uses as > they don't implicitly affect any versioned resources; autoconf does. If you're worried about the noise in diff, it's never been a problem at least to me (just don't post a configure diff for review, the configure.ac is enough). If you're worried about runtime compatibility, then autoconf is not your only worry. Proper build also depends on the target shell, target toolchain (gcc, libc, etc). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Tue, Oct 16, 2012 at 12:12:35AM -0700, R. David Murray wrote: > On Mon, 15 Oct 2012 23:18:04 -0700, Ned Deily wrote: > > In article <20121016043352.ga21...@snakebite.org>, > > Trent Nelson wrote: > > > Any objections to regenerating configure with autoconf 2.69? The > > > current version is based off 2.68, which was release on the 22nd > > > of September 2010. 2.69 was released on the 24th of April, 2012. > > > > > > (There are some fixes for the more esoteric UNIX platforms that > > > Snakebite will benefit from. Also, I struggled to find a box > > > with 2.68 even installed when I needed to regenerate configure > > > this weekend; it seems all package management/ports have bumped > > > to 2.69.) > > > > > > If there are no objections, can it be applied across the board? > > > 2.7, 3.2, 3.3 and 3.x? > > > > I believe it is the case that we don't currently require a specific > > version of autoconf. autoconf is only run when making a committer makes > > a change to configure.ac et al and then it is run on the committer's > > machine. So whatever is checked in for those files reflects the version > > of autoconf that the committer used. > > My understanding is that we use a specific version of autoconf. > The reason is that otherwise we end up with useless churn in the repo > as the generated file changes when different committers use different > versions. In the past we have had issues with a new autoconf version > actually breaking the Python build, so we also need to test a new version > before switching to it. Just to put this in perspective, here's a change I made to configure.ac over the weekend as part of #15819: % hg diff configure.ac diff -r 51ce9830d85a configure.ac --- a/configure.ac Sat Oct 13 11:58:23 2012 -0400 +++ b/configure.ac Tue Oct 16 09:12:56 2012 + @@ -9,6 +9,9 @@ AC_INIT(python, PYTHON_VERSION, http://bugs.python.org/) +BUILDDIR="`pwd`" +AC_SUBST(BUILDDIR) + AC_SUBST(HGVERSION) AC_SUBST(HGTAG) AC_SUBST(HGBRANCH) With the correct version of autoconf (2.68), this generates the following diff to configure: % hg diff configure diff -r 51ce9830d85a configure --- a/configure Sat Oct 13 11:58:23 2012 -0400 +++ b/configure Tue Oct 16 09:15:04 2012 + @@ -714,6 +714,7 @@ HGBRANCH HGTAG HGVERSION +BUILDDIR target_alias host_alias build_alias @@ -2719,6 +2720,9 @@ +BUILDDIR="`pwd`" + + However, the 2.69 version of autoconf generates this monster of a configure diff: http://hydrogen.snakebite.net/~cpython/configure.diff As you can see, it's impossible to figure out what my configure.ac change was from that diff. Which is why I'm proposing we leverage AC_PREREQ to prevent inadvertent autoconf version churn. Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Tue, 16 Oct 2012 05:05:23 -0400 Trent Nelson wrote: > On Tue, Oct 16, 2012 at 01:43:37AM -0700, Charles-François Natali wrote: > > > My understanding is that we use a specific version of autoconf. > > > The reason is that otherwise we end up with useless churn in the repo > > > as the generated file changes when different committers use different > > > versions. In the past we have had issues with a new autoconf version > > > actually breaking the Python build, so we also need to test a new version > > > before switching to it. > > > > Well, so I guess all committers will have to use the same > > Linux/FreeBSD/whatever distribution then? > > AFAICT there's no requirement regarding the mercurial version used by > > committers either. > > Autoconf is a special case though. Different versions of autoconf > produce wildly different outputs for 'configure', making it impossible > to vet configure.ac changes by reviewing the configure diff. Isn't it enough to review the configure.ac diff? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Tue, Oct 16, 2012 at 02:17:35AM -0700, Charles-François Natali wrote: > > It should be sufficient to install autoconf-x.y into /home/user/bin or > > something similar. Installing autoconf from source really takes about > > 3 minutes. > > Well, maybe, maybe not. > autoconf depends on a least m4 and Perl, and you may very well have a > compatibility issue here. > That's why most distributions have package managers, and in 2012 we're > past the './configure && make && make install". If you're unable to get 2.69 (or whatever) installed for whatever reason, you can always just commit configure.ac and ask another committer to regenerate configure with the correct version. (In my case, I couldn't find a single Snakebite box that had 2.68 installed; out of 20-something hosts, everything had 2.69, which is partly why I'd like to bump to 2.69.) > > It doesn't matter which OS or Mercurial version a developer uses as > > they don't implicitly affect any versioned resources; autoconf does. > > If you're worried about the noise in diff, it's never been a problem > at least to me (just don't post a configure diff for review, the > configure.ac is enough). > > If you're worried about runtime compatibility, then autoconf is not > your only worry. Proper build also depends on the target shell, target > toolchain (gcc, libc, etc). Ignoring diff noise, what I'm suggesting is that we formalize the version used to build configure, as opposed to just accepting that "configure was built with whatever arbitrary version of autoconf the last developer that modified configure.ac had installed". If you look at configure's history, we pretty much already follow this informally. Anyway, back to the original question: does anyone know of reasons we shouldn't bump to 2.69? Any known incompatibilities? Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
Trent Nelson wrote: > > build breaking is another matter, of course. If we are > > going to mandate a specific version again, that should be documented and > > checked for. > > My preference: bump to 2.69 and set AC_PREREQ(2.69). If 2.69 proves > unworkable, revert back to 2.68 and AC_PREREQ(2.68). > > I definitely like the idea of explicitly setting the version being > used via AC_PREREQ, as this will prevent accidental version churn > being checked in by a committer inadvertently. Bear in mind that AC_PREREQ sets the minimum required version. It cannot be used to prevent from running newer autoconf in the future. Petri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Merge issue #15936: Add link from os.urandom to random.SystemRandom
Am 16.10.2012 um 12:15 schrieb andrew.svetlov : > + For easy to use interface to system randomness please see > + :class:`random.SystemRandom`. Is it just my non-native speaker ears, or should there be an “an” before “easy”? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Merge issue #15936: Add link from os.urandom to random.SystemRandom
I dont feel anything wrong with it, but I'm also not native speaker. On Tue, Oct 16, 2012 at 1:23 PM, Hynek Schlawack wrote: > Am 16.10.2012 um 12:15 schrieb andrew.svetlov : > >> + For easy to use interface to system randomness please see >> + :class:`random.SystemRandom`. > > Is it just my non-native speaker ears, or should there be an “an” before > “easy”? > ___ > Python-checkins mailing list > python-check...@python.org > http://mail.python.org/mailman/listinfo/python-checkins -- Thanks, Andrew Svetlov ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Merge issue #15936: Add link from os.urandom to random.SystemRandom
On 10/16/2012 11:23 AM, Hynek Schlawack wrote: Am 16.10.2012 um 12:15 schrieb andrew.svetlov : + For easy to use interface to system randomness please see + :class:`random.SystemRandom`. Is it just my non-native speaker ears, or should there be an “an” before “easy”? There should. And "for system randomness" is hard to follow. I would have written it as For an easy-to-use interface to the random number generator provided by your platform, please see :class:`random.SystemRandom`. //arry/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Merge issue #15936: Add link from os.urandom to random.SystemRandom
Am 16.10.2012 12:43, schrieb Larry Hastings: > On 10/16/2012 11:23 AM, Hynek Schlawack wrote: >> Am 16.10.2012 um 12:15 schrieb andrew.svetlov : >> >>> + For easy to use interface to system randomness please see >>> + :class:`random.SystemRandom`. >> Is it just my non-native speaker ears, or should there be an “an” before >> “easy”? > > There should. And "for system randomness" is hard to follow. I would > have written it as > > For an easy-to-use interface to the random number generator provided > by your platform, please see :class:`random.SystemRandom`. I don't like the phrase "easy-to-use" at all. IMO it can't get any easier than "give my X random bytes". random.SystemRandom is simply a high level interface that is mostly compatible with the random module. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Merge issue #15936: Add link from os.urandom to random.SystemRandom
Well. I rephrased text following suggestion from Larry Hastings. If there are need more clarification please reopen #15936 On Tue, Oct 16, 2012 at 1:52 PM, Christian Heimes wrote: > Am 16.10.2012 12:43, schrieb Larry Hastings: >> On 10/16/2012 11:23 AM, Hynek Schlawack wrote: >>> Am 16.10.2012 um 12:15 schrieb andrew.svetlov : >>> + For easy to use interface to system randomness please see + :class:`random.SystemRandom`. >>> Is it just my non-native speaker ears, or should there be an “an” before >>> “easy”? >> >> There should. And "for system randomness" is hard to follow. I would >> have written it as >> >> For an easy-to-use interface to the random number generator provided >> by your platform, please see :class:`random.SystemRandom`. > > I don't like the phrase "easy-to-use" at all. IMO it can't get any > easier than "give my X random bytes". random.SystemRandom is simply a > high level interface that is mostly compatible with the random module. > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Merge issue #15936: Add link from os.urandom to random.SystemRandom
On Tue, 16 Oct 2012 12:52:25 +0200 Christian Heimes wrote: > Am 16.10.2012 12:43, schrieb Larry Hastings: > > On 10/16/2012 11:23 AM, Hynek Schlawack wrote: > >> Am 16.10.2012 um 12:15 schrieb andrew.svetlov : > >> > >>> + For easy to use interface to system randomness please see > >>> + :class:`random.SystemRandom`. > >> Is it just my non-native speaker ears, or should there be an “an” before > >> “easy”? > > > > There should. And "for system randomness" is hard to follow. I would > > have written it as > > > > For an easy-to-use interface to the random number generator provided > > by your platform, please see :class:`random.SystemRandom`. > > I don't like the phrase "easy-to-use" at all. IMO it can't get any > easier than "give my X random bytes". random.SystemRandom is simply a > high level interface that is mostly compatible with the random module. I guess it's easy to use if you need something other than raw bytes. But, yes, I would call it "higher level" rather than "easy to use" (I don't think there's a need for hyphens, by the way). Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Merge issue #15936: Add link from os.urandom to random.SystemRandom
Antoine Pitrou writes: > But, yes, I would call it "higher level" rather than "easy to use" > (I don't think there's a need for hyphens, by the way). You don't need them to get the point across, but elderly grammar pedants will think better of you if you use the hyphens. Personally, I hope they'll be used. I'm tired of the assumption that "illiterate techie" is a redundant phrase. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.3): Tweak the threaded example in concurrent.futures
On Tue, 16 Oct 2012 14:51:21 +0200 (CEST)
nick.coghlan wrote:
>
> + # We can use a with statement to ensure threads are cleaned up promptly
> with concurrent.futures.ThreadPoolExecutor(max_workers=5) as executor:
> - future_to_url = dict((executor.submit(load_url, url, 60), url)
> -for url in URLS)
> -
> - for future in concurrent.futures.as_completed(future_to_url):
> - url = future_to_url[future]
> - if future.exception() is not None:
> - print('%r generated an exception: %s' % (url,
> -future.exception()))
> + # Start the load operations and mark each future with its URL
> + load_urls = [executor.submit(load_url, url, 60) for url in URLS]
> + for future, url in zip(load_urls, URLS):
> + future.url = url
Adding an "url" attribute here looks a bit ugly to me. Why not use a
dict comprehension for future_to_url?
Regards
Antoine.
--
Software development and contracting: http://pro.pitrou.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.3): Tweak the threaded example in concurrent.futures
On Tue, Oct 16, 2012 at 10:58 PM, Antoine Pitrou wrote: > Adding an "url" attribute here looks a bit ugly to me. Why not use a > dict comprehension for future_to_url? No reason other than the fact it didn't occur to me to do so. Fixed :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issues Pending Review
> Hello, I have some issues pending 'patch review' hanging for more than >> two weeks, could somebody please check them out? >> > > In case nobody picks it up, my 5-for-1 offer still stands: if you review > five issues, I'll review one of yours. > Is that a general offer or just for the OP? :-) Seriously, getting an issue reviewed by Martin is something worth fighting for, and reviewing other 5 issues seems like a small price. This is not to imply that Martin doesn't review others' issues often enough, just that his reviews come from a high authority and can almost always put a final resolution on the problem. Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Oct 16, 2012, at 05:32 AM, Trent Nelson wrote: > Anyway, back to the original question: does anyone know of reasons > we shouldn't bump to 2.69? Any known incompatibilities? There will be problems building with 2.69 on Ubuntus older than 12.10, and Debians older than wheezy. % rmadison autoconf autoconf | 2.61-4 | hardy | source, all autoconf | 2.65-3ubuntu1 | lucid | source, all autoconf | 2.67-2ubuntu1 | natty | source, all autoconf | 2.68-1ubuntu1 | oneiric | source, all autoconf | 2.68-1ubuntu2 | precise | source, all autoconf | 2.69-1ubuntu1 | quantal | source, all % rmadison -u debian autoconf autoconf | 2.67-2 | squeeze | source, all autoconf | 2.69-1 | wheezy | source, all autoconf | 2.69-1 | sid | source, all FWIW, precise is Ubuntu 12.04 LTS, so it carries Python 2.7 and 3.2. I think it would be fine to update the default branch (i.e. 3.4), but I'm not sure what benefit you gain from making this change to stable branches, and you could potentially cause build problems, which you may not find out about for a while, e.g. when 2.7.4 is released and all the distros go to update. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Tue, Oct 16, 2012 at 11:27:24AM +0200, Antoine Pitrou wrote: > On Tue, 16 Oct 2012 05:05:23 -0400 > Trent Nelson wrote: > > On Tue, Oct 16, 2012 at 01:43:37AM -0700, Charles-François Natali wrote: > > > > My understanding is that we use a specific version of autoconf. > > > > The reason is that otherwise we end up with useless churn in the repo > > > > as the generated file changes when different committers use different > > > > versions. In the past we have had issues with a new autoconf version > > > > actually breaking the Python build, so we also need to test a new > > > > version > > > > before switching to it. > > > > > > Well, so I guess all committers will have to use the same > > > Linux/FreeBSD/whatever distribution then? > > > AFAICT there's no requirement regarding the mercurial version used by > > > committers either. > > > > Autoconf is a special case though. Different versions of autoconf > > produce wildly different outputs for 'configure', making it impossible > > to vet configure.ac changes by reviewing the configure diff. > > Isn't it enough to review the configure.ac diff? > That's the ideal but it's been wrong in the past and may possibly be wrong in the future as well. Anecdotally, in the Linux distribution I package for we have a conversation about whether we should apply patches to configure.ac and then run autoreconf (or equivalent) or include the patches to ocnfigure about once a year. Although the latter has been pretty stable for several autoconf version updates enough people have bad memories of those times when bumping autoconf revisions that there's always a vocal contingent who advocate shipping patches to the actual configure scripts (they're under the impression the package maintainer will actually audit the configure patch that autoconf generated to see if there's breakage that way). -Toshio pgpKtINQd1o1B.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.3): Tweak the threaded example in concurrent.futures
On Tue, Oct 16, 2012 at 5:51 AM, nick.coghlan
wrote:
> http://hg.python.org/cpython/rev/a3f27289ec68
> changeset: 79746:a3f27289ec68
> branch: 3.3
> + except Exception as exc:
> + print('%r generated an exception: %s' % (url, exc))
> else:
> - print('%r page is %d bytes' % (url, len(future.result(
> + print('%r page is %d bytes' % (url, len(data)))
I'm not suggesting this particular example be changed, but going
forward should we prefer the newer str.format() approach to
formatting?
http://docs.python.org/dev/library/stdtypes.html#printf-style-string-formatting
I've also seen references in the docs to the "old %-style formatting,"
but maybe old is meant more in the sense of having been around longer
than discouraged.
--Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/16/2012 09:47 AM, Barry Warsaw wrote: > On Oct 16, 2012, at 05:32 AM, Trent Nelson wrote: > >> Anyway, back to the original question: does anyone know of reasons >> we shouldn't bump to 2.69? Any known incompatibilities? > > There will be problems building with 2.69 on Ubuntus older than > 12.10, and Debians older than wheezy. > > % rmadison autoconf autoconf | 2.61-4 | hardy | source, > all autoconf | 2.65-3ubuntu1 | lucid | source, all autoconf | > 2.67-2ubuntu1 | natty | source, all autoconf | 2.68-1ubuntu1 | > oneiric | source, all autoconf | 2.68-1ubuntu2 | precise | > source, all autoconf | 2.69-1ubuntu1 | quantal | source, all % > rmadison -u debian autoconf autoconf | 2.67-2 | squeeze | source, all > autoconf | 2.69-1 | wheezy | source, all autoconf | 2.69-1 | sid > | source, all > > FWIW, precise is Ubuntu 12.04 LTS, so it carries Python 2.7 and 3.2. > I think it would be fine to update the default branch (i.e. 3.4), but > I'm not sure what benefit you gain from making this change to stable > branches, and you could potentially cause build problems, which you > may not find out about for a while, e.g. when 2.7.4 is released and > all the distros go to update. Agreed: this is really the same issue as bumping the VisualStudio version (or any other build tooling) inside a release line: too much potential for breakage for little gain. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB9eq8ACgkQ+gerLs4ltQ5gWQCcDDjMRWcUDagb6dhZCK+5pSVs dVIAoLH+S205plmi22RS0aBaF5GxnTmn =PrEy -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Tue, Oct 16, 2012 at 11:18 AM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10/16/2012 09:47 AM, Barry Warsaw wrote: > > On Oct 16, 2012, at 05:32 AM, Trent Nelson wrote: > > > >> Anyway, back to the original question: does anyone know of reasons > >> we shouldn't bump to 2.69? Any known incompatibilities? > > > > There will be problems building with 2.69 on Ubuntus older than > > 12.10, and Debians older than wheezy. > > > > % rmadison autoconf autoconf | 2.61-4 | hardy | source, > > all autoconf | 2.65-3ubuntu1 | lucid | source, all autoconf | > > 2.67-2ubuntu1 | natty | source, all autoconf | 2.68-1ubuntu1 | > > oneiric | source, all autoconf | 2.68-1ubuntu2 | precise | > > source, all autoconf | 2.69-1ubuntu1 | quantal | source, all % > > rmadison -u debian autoconf autoconf | 2.67-2 | squeeze | source, all > > autoconf | 2.69-1 | wheezy | source, all autoconf | 2.69-1 | sid > > | source, all > > > > FWIW, precise is Ubuntu 12.04 LTS, so it carries Python 2.7 and 3.2. > > I think it would be fine to update the default branch (i.e. 3.4), but > > I'm not sure what benefit you gain from making this change to stable > > branches, and you could potentially cause build problems, which you > > may not find out about for a while, e.g. when 2.7.4 is released and > > all the distros go to update. > > Agreed: this is really the same issue as bumping the VisualStudio > version (or any other build tooling) inside a release line: too much > potential for breakage for little gain. > I think Barry's suggestion of updating default and leaving stable versions alone is a good one. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Tue, Oct 16, 2012 at 08:23:00AM -0700, Brett Cannon wrote: >On Tue, Oct 16, 2012 at 11:18 AM, Tres Seaver >wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > On 10/16/2012 09:47 AM, Barry Warsaw wrote: > > On Oct 16, 2012, at 05:32 AM, Trent Nelson wrote: > > > >> Anyway, back to the original question: does anyone know of reasons > >> we shouldn't bump to 2.69? A Any known incompatibilities? > > > > There will be problems building with 2.69 on Ubuntus older than > > 12.10, and Debians older than wheezy. > > > > % rmadison autoconf autoconf | A A 2.61-4 | A A A A hardy | > source, > > all autoconf | 2.65-3ubuntu1 | A A A A lucid | source, all > autoconf | > > 2.67-2ubuntu1 | A A A A natty | source, all autoconf | > 2.68-1ubuntu1 | > > oneiric | source, all autoconf | 2.68-1ubuntu2 | A A A precise | > > source, all autoconf | 2.69-1ubuntu1 | A A A quantal | source, all > % > > rmadison -u debian autoconf autoconf | 2.67-2 | squeeze | source, all > > autoconf | 2.69-1 | wheezy A | source, all autoconf | 2.69-1 | sid > > | source, all > > > > FWIW, precise is Ubuntu 12.04 LTS, so it carries Python 2.7 and 3.2. > > I think it would be fine to update the default branch (i.e. 3.4), but > > I'm not sure what benefit you gain from making this change to stable > > branches, and you could potentially cause build problems, which you > > may not find out about for a while, e.g. when 2.7.4 is released and > > all the distros go to update. > > Agreed: A this is really the same issue as bumping the VisualStudio > version (or any other build tooling) inside a release line: A too much > potential for breakage for little gain. > >I think Barry's suggestion of updating default and leaving stable versions >alone is a good one.A Bumped 3.4 to 2.69 in 79763:74b95194ba86! Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
On Tue, 2012-10-16 at 10:59 +0200, Stefan Krah wrote: > Charles-François Natali wrote: > > Well, so I guess all committers will have to use the same > > Linux/FreeBSD/whatever distribution then? > > AFAICT there's no requirement regarding the mercurial version used by > > committers either. > > It should be sufficient to install autoconf-x.y into /home/user/bin or > something similar. Installing autoconf from source really takes about > 3 minutes. FWIW this was also documented in the devguide, as of: http://hg.python.org/devguide/rev/5432be4d4e1a though that description was then removed in: http://hg.python.org/devguide/rev/27be97280cff ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Merge issue #15936: Add link from os.urandom to random.SystemRandom
On 2012-10-16 12:59, Stephen J. Turnbull wrote: Antoine Pitrou writes: > But, yes, I would call it "higher level" rather than "easy to use" > (I don't think there's a need for hyphens, by the way). You don't need them to get the point across, but elderly grammar pedants will think better of you if you use the hyphens. Personally, I hope they'll be used. +1 > I'm tired of the assumption that "illiterate techie" is a redundant phrase. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69
Trent Nelson wrote: [SNIP] diff -r 51ce9830d85a configure.ac --- a/configure.ac Sat Oct 13 11:58:23 2012 -0400 +++ b/configure.ac Tue Oct 16 09:12:56 2012 + @@ -9,6 +9,9 @@ AC_INIT(python, PYTHON_VERSION, http://bugs.python.org/) +BUILDDIR="`pwd`" ^ http://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Preset-Output-Variables.html [SNIP] However, the 2.69 version of autoconf generates this monster of a configure diff: It is python project rule to keep generated files into repository. Roumen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
