Re: [Python-Dev] Stable build slaves authority

[Martin v. Löwis]

> #python-dev thought that VS express was all that was needed; then here,
> it seemed to me that Martin said that you needed the full version of VS
> or perhaps a complex setup with the SDK compiler; but you seem to be
> interpreting Martin that the SDK provides everything and nothing else is
> needed.

I think I forgot earlier discussion on how to use the SDK. It may well
be that it can be used to build Python with no VS installed, but it's
not what I meant - I meant that I actually don't know.

>   1. Is someone else (Hi, Brian) providing a 64-bit windows slave, so
> there isn't actually any need for me to go through the effort of it?

With the Windows build slaves: they come and go. So having two of them
might be a good idea.

>   2. If not, is all that's needed is the SDK to build 64-bit Python?

I think that you will need to find out on your own. And, even if it's
possible, the next question is whether what the buildbot scripts do
actually works without VS (but we could adjust them).

> Basically, it comes down to: 'it' being a 64-bit windows slave, is it
> actually needed from me (i.e., is a more apt expert not providing it),
> and can anyone actually say what the requirements are for making it
> happen?

As for "needed", well, we a are all volunteers. This project will
certainly survive without a 64-bit Windows build slave (it did
so in the last months).

As for saying what the requirements are: probably nobody can.

> I have computing resources, cycles, and time that's free to offer up:
> but the differing responses here makes me unsure if I'm being useful or
> not in trying here :)

Well, the differing responses really demonstrate that it's also
expertise that is lacking throughout. If you are motivated, please
try to find out how to build Python on AMD64 with free-as-in-beer
Microsoft tools, and provide a patch to PCbuild/readme.txt.

Having such a setup then tested regularly is certainly worthwhile.

Regards,
Martin
___
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] socket.fromfd() documentation problem

[Kálmán Gergely]

On 10/06/10 14:12, Victor Stinner wrote:

Le mercredi 06 octobre 2010 09:34:05, Kálmán Gergely a écrit :
   

Nevertheless what are your thoughts on this? Should I file a bug report
for it?
 

It will be fixed faster if you open an issue and attach a patch ;-)

   


Just did: http://bugs.python.org/issue10099

Kalman Gergely
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] A new warning category?

[Antoine Pitrou]

Hello,

In the http://bugs.python.org/issue10093 discussion, I proposed to add a
specific warning category for unclosed files. The rationale is that
these warnings will happen in destructors and therefore filtering by
line number and filename doesn't make sense. So a new category would be
useful in order to allow defining specific rules.
Do you think it would go against the moratorium?

As for the category name, I would suggest ResourceWarning if we use it
specifically for resource-consumption warnings. Or perhaps DebugWarning
if we want to put all kinds of debugging helpers in it.

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] A new warning category?

[Antoine Pitrou]

On Thu, 14 Oct 2010 11:25:39 +0200
Antoine Pitrou  wrote:
> 
> Hello,
> 
> In the http://bugs.python.org/issue10093 discussion, I proposed to add a
> specific warning category for unclosed files. The rationale is that
> these warnings will happen in destructors and therefore filtering by
> line number and filename doesn't make sense. So a new category would be
> useful in order to allow defining specific rules.
> Do you think it would go against the moratorium?

Come to think of it, another reason for a separate warning category is
that we problably want those disabled by default (unless we're running
in pydebug mode perhaps).

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] A new warning category?

[Steven D'Aprano]

On Thu, 14 Oct 2010 08:25:39 pm Antoine Pitrou wrote:
> Hello,
>
> In the http://bugs.python.org/issue10093 discussion, I proposed to
> add a specific warning category for unclosed files. The rationale is
> that these warnings will happen in destructors and therefore
> filtering by line number and filename doesn't make sense. So a new
> category would be useful in order to allow defining specific rules.

Sounds like a reasonable suggestion to me.

> Do you think it would go against the moratorium?

It's not clear to me one way or the other, but I suspect yes.


-- 
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r85463 - python/branches/py3k/Lib/test/test_import.py

[Barry Warsaw]

On Oct 14, 2010, at 09:34 AM, georg.brandl wrote:

>Author: georg.brandl
>Date: Thu Oct 14 09:34:56 2010
>New Revision: 85463
>
>Log:
>Better check for "any optimize option given".
>
>Modified:
>   python/branches/py3k/Lib/test/test_import.py
>
>Modified: python/branches/py3k/Lib/test/test_import.py
>==
>--- python/branches/py3k/Lib/test/test_import.py   (original)
>+++ python/branches/py3k/Lib/test/test_import.py   Thu Oct 14 09:34:56 2010
>@@ -521,7 +521,7 @@
> self.assertTrue(os.path.exists('__pycache__'))
> self.assertTrue(os.path.exists(os.path.join(
> '__pycache__', '{}.{}.py{}'.format(
>-TESTFN, self.tag, sys.flags.optimize and 'o' or 'c'
>+TESTFN, self.tag, __debug__ and 'c' or 'o'

You might want to use imp.cache_from_source() instead for consistency.

> 
> @unittest.skipUnless(os.name == 'posix',
>  "test meaningful only on posix systems")

-Barry


signature.asc
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] Stable build slaves authority

[Brian Curtin]

On Thu, Oct 14, 2010 at 01:00, Stephen Hansen

> wrote:

> On 10/13/10 10:28 PM, Jeroen Ruigrok van der Werven wrote:
> > -On [20101014 00:55], Brian Curtin (brian.cur...@gmail.com) wrote:
> >> Correct. There are a few hacky ways to get Express to use the x64 SDK,
> or so I
> >> read.
> >
> > I think Martin meant that you wouldn't need VS Express if you install the
> > Windows SDK, since it provides all the tools in the SDK to build Python.
>
> There's mixed signals here, and I'm not sure what they all mean. I have
> a Win7-64bit box that I am willing to use to run a buildslave, if its
> possible to do so.
>
> #python-dev thought that VS express was all that was needed; then here,
> it seemed to me that Martin said that you needed the full version of VS
> or perhaps a complex setup with the SDK compiler; but you seem to be
> interpreting Martin that the SDK provides everything and nothing else is
> needed.
>
> Then again on top of that, my offer may be mooted-- if Brian Curtin is
> going to host a x86_64 windows slave then I don't need to worry about
> this because its being provided otherwise.




> I'm willing to put up with the particular windows-specific difficulties
> that go with running a buildslave (especially with David Bolen's AutoIt
> scripts which may ease things): but I'm not entirely sure from these
> varied results if its even possible or needed.
>
> So, my questions are:
>  1. Is someone else (Hi, Brian) providing a 64-bit windows slave, so
> there isn't actually any need for me to go through the effort of it?
>

I'm planning to -- just need a little time to sit down and get the box ready
to go. I would say that one build slave is good, two is better. If you feel
up to the task, go right ahead. As one of the few Windows users around here,
I'd certainly appreciate more Windows testing.

One of my motivations in providing a build slave is execution of the newly
added os.symlink support starting in Windows Vista. Since os.symlink
requires a certain privilege, it's not tested on any of the current build
slaves. I plan to work out a way for my build slave to get these tests
executed, rather than just running them on my desktop boxes.


>  2. If not, is all that's needed is the SDK to build 64-bit Python?


Sorry for my confusion earlier - I was focused on the VS Express part,
rather than the minimum requirement to build Python (which doesn't *require*
VS at all, it's just a nice tool to build it). Supposedly the 64-bit SDK by
itself should build a 64-bit Python -- I say "supposedly" because I haven't
done this myself. I've read that only using the 32-bit SDK does this fine --
also have not done this myself.

I understand that doesn't really answer your question, but hopefully my
previous involvement seems more clear.
___
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] r85481 - in python/branches/py3k: Misc/NEWS configure.in

[Brett Cannon]

Doesn't autoconf need to be run to regenerate configure?

On Thu, Oct 14, 2010 at 08:24, matthias.klose
 wrote:
> Author: matthias.klose
> Date: Thu Oct 14 17:24:22 2010
> New Revision: 85481
>
> Log:
> - Issue #10094: Use versioned .so files on GNU/kfreeBSD and the GNU Hurd.
>
>
> Modified:
>   python/branches/py3k/Misc/NEWS
>   python/branches/py3k/configure.in
>
> Modified: python/branches/py3k/Misc/NEWS
> ==
> --- python/branches/py3k/Misc/NEWS      (original)
> +++ python/branches/py3k/Misc/NEWS      Thu Oct 14 17:24:22 2010
> @@ -61,6 +61,11 @@
>
>  - Issue #7287: Demo/imputil/knee.py was removed.
>
> +Build
> +-
> +
> +- Issue #10094: Use versioned .so files on GNU/kfreeBSD and the GNU Hurd.
> +
>
>  What's New in Python 3.2 Alpha 3?
>  =
>
> Modified: python/branches/py3k/configure.in
> ==
> --- python/branches/py3k/configure.in   (original)
> +++ python/branches/py3k/configure.in   Thu Oct 14 17:24:22 2010
> @@ -3652,7 +3652,8 @@
>                esac
>                ;;
>        CYGWIN*)   SO=.dll;;
> -       Linux*)    SO=.${SOABI}.so;;
> +       Linux*|GNU*)
> +                  SO=.${SOABI}.so;;
>        *)         SO=.so;;
>        esac
>  else
> ___
> Python-checkins mailing list
> python-check...@python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
___
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] A new warning category?

[Brett Cannon]

On Thu, Oct 14, 2010 at 02:25, Antoine Pitrou  wrote:
>
> Hello,
>
> In the http://bugs.python.org/issue10093 discussion, I proposed to add a
> specific warning category for unclosed files. The rationale is that
> these warnings will happen in destructors and therefore filtering by
> line number and filename doesn't make sense. So a new category would be
> useful in order to allow defining specific rules.
> Do you think it would go against the moratorium?

As one of the co-authors of the PEP I say no.

>
> As for the category name, I would suggest ResourceWarning if we use it
> specifically for resource-consumption warnings. Or perhaps DebugWarning
> if we want to put all kinds of debugging helpers in it.

I say start with ResourceWarning and if we decide to generalize we can
make ResourceWarning subclass DebugWarning without breaking code.
___
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] Stable build slaves authority

[Antoine Pitrou]

On Thu, 14 Oct 2010 08:07:46 +0200
Georg Brandl  wrote:
> 
> Very nice.  http://www.python.org/dev/buildbot/stable/ is completely
> green at the moment -- which means that I can now indeed take failures
> seriously in the future.  Previously, two of four "stables" for py3k
> were not even connected for ages (and yes, I should have complained
> earlier.  As we progress into the beta stage, I will take buildbot
> failures and release blockers more seriously).

For the record, I've setup one of the stable buildbots ("AMD64 Gentoo
Wide") to test wide unicode buils.
Also, one of the unstable buildbots ("x86 debian parallel") now runs
its tests with -OO, at Georg's request.

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

[Python-Dev] Issue 10094

[Barry Warsaw]

Posting this here first, though it's looking less like a Python bug and more
like an environment problem, or issue with something in Ubuntu.

I'm running the regular test suite for the py3k branch and seeing this failure
on Ubuntu 10.10:

http://bugs.python.org/issue10094
test_urllib.py fails with RuntimeError on Ubuntu 10.10

It's completely consistent.  It happens with the regular test suite, or just
running test_urllib.py, and it does not happen with any other test afaict.
I've gone way back in svn, pulled down earlier alphas that I know worked and
they all exhibit the bug.

This only happens on Ubuntu 10.10 machines (afaict so far), both i386 and
x86_64.  It does not happen on Ubuntu 10.04 64bit VMs, nor does it happen on
Debian squeeze.

I'll continue to investigate, but since it's damn perplexing I just wanted to
see if anybody had any thoughts on the problem.

Cheers,
-Barry


signature.asc
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] Issue 10094

[Guido van Rossum]

Could it be IPv6?

On Thu, Oct 14, 2010 at 10:04 AM, Barry Warsaw  wrote:
> Posting this here first, though it's looking less like a Python bug and more
> like an environment problem, or issue with something in Ubuntu.
>
> I'm running the regular test suite for the py3k branch and seeing this failure
> on Ubuntu 10.10:
>
> http://bugs.python.org/issue10094
> test_urllib.py fails with RuntimeError on Ubuntu 10.10
>
> It's completely consistent.  It happens with the regular test suite, or just
> running test_urllib.py, and it does not happen with any other test afaict.
> I've gone way back in svn, pulled down earlier alphas that I know worked and
> they all exhibit the bug.
>
> This only happens on Ubuntu 10.10 machines (afaict so far), both i386 and
> x86_64.  It does not happen on Ubuntu 10.04 64bit VMs, nor does it happen on
> Debian squeeze.
>
> I'll continue to investigate, but since it's damn perplexing I just wanted to
> see if anybody had any thoughts on the problem.
>
> 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/guido%40python.org
>
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue 10094

[Senthil Kumaran]

On Thu, Oct 14, 2010 at 10:29:12AM -0700, Guido van Rossum wrote:
> Could it be IPv6?

The error message says,

  File "Lib/test/test_urllib.py", line 121, in setUp
for k in os.environ.keys():
  File "/home/barry/projects/python/py3k/Lib/_abcoll.py", line 410, in __iter__
for key in self._mapping:
  File "/home/barry/projects/python/py3k/Lib/os.py", line 441, in __iter__
for key in self._data:
RuntimeError: dictionary changed size during iteration

I doubt if it is related to underlying IP. 

I thought it was with test runner (or threads) and the way we use EnvironGuard
in the tests. 

I have observed in a very inconsistent manner earlier, surprising that is
always failing on Ubuntu 10.10.

-- 
Senthil
___
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] Issue 10094

[Barry Warsaw]

On Oct 14, 2010, at 10:29 AM, Guido van Rossum wrote:

>Could it be IPv6?

I don't think so.  I have IPv6 disabled on at least one of the machines.
Also, I'm sure this failure did not occur before Ubuntu 10.10 final.

It also fails on Python 3.1.

-Barry


signature.asc
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] Issue 10094

[Antoine Pitrou]

On Thu, 14 Oct 2010 13:04:01 -0400
Barry Warsaw  wrote:
> Posting this here first, though it's looking less like a Python bug and more
> like an environment problem, or issue with something in Ubuntu.
> 
> I'm running the regular test suite for the py3k branch and seeing this failure
> on Ubuntu 10.10:
> 
> http://bugs.python.org/issue10094
> test_urllib.py fails with RuntimeError on Ubuntu 10.10
> 
> It's completely consistent.  It happens with the regular test suite, or just
> running test_urllib.py, and it does not happen with any other test afaict.

An easy way to reproduce is to have an environment variable named
"PROXY":

$ PROXY=toto ./python -m test.regrtest -F test_urllib
[  1] test_urllib
Warning -- os.environ was modified by test_urllib
test test_urllib failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/debug/Lib/test/test_urllib.py", line 121, in
setUp for k in os.environ.keys():
  File "/home/antoine/py3k/debug/Lib/_abcoll.py", line 410, in __iter__
for key in self._mapping:
  File "/home/antoine/py3k/debug/Lib/os.py", line 441, in __iter__
for key in self._data:
RuntimeError: dictionary changed size during iteration


There doesn't seem to be anything really mysterious, actually. The
exception message says it all :)

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] Issue 10094

[Senthil Kumaran]

On Thu, Oct 14, 2010 at 07:38:58PM +0200, Antoine Pitrou wrote:
> An easy way to reproduce is to have an environment variable named
> "PROXY":
> 
> $ PROXY=toto ./python -m test.regrtest -F test_urllib
> [  1] test_urllib
> Warning -- os.environ was modified by test_urllib
> test test_urllib failed -- Traceback (most recent call last):
>   File "/home/antoine/py3k/debug/Lib/test/test_urllib.py", line 121, in
> setUp for k in os.environ.keys():
>   File "/home/antoine/py3k/debug/Lib/_abcoll.py", line 410, in __iter__
> for key in self._mapping:
>   File "/home/antoine/py3k/debug/Lib/os.py", line 441, in __iter__
> for key in self._data:
> RuntimeError: dictionary changed size during iteration
> 
> There doesn't seem to be anything really mysterious, actually. The
> exception message says it all :)

That is indeed the case. It a bug to be fixed.

-- 
Senthil
___
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] r85486 - python/branches/py3k/configure

[Daniel Stutzbach]

On Thu, Oct 14, 2010 at 12:38 PM, barry.warsaw
wrote:

> -# Generated by GNU Autoconf 2.65 for python 3.2.
> +# Generated by GNU Autoconf 2.67 for python 3.2.
>

Was the change in autoconf versions intentional and/or is it a problem?

-- 
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] Issue 10094

[Barry Warsaw]

On Oct 14, 2010, at 07:38 PM, Antoine Pitrou wrote:

>There doesn't seem to be anything really mysterious, actually. The
>exception message says it all :)

Yep.  Looks like Ubuntu 10.10 added UBUNTU_MENUPROXY to the default
environment and that's what's killing it.  I'll bet those Ubuntu buildbots are
not running Maverick.

Oh well, mystery solved at least.  I'll work on a patch.

-Barry


signature.asc
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] A new warning category?

[Martin v. Löwis]

Am 14.10.2010 11:25, schrieb Antoine Pitrou:
> 
> Hello,
> 
> In the http://bugs.python.org/issue10093 discussion, I proposed to add a
> specific warning category for unclosed files. The rationale is that
> these warnings will happen in destructors and therefore filtering by
> line number and filename doesn't make sense. So a new category would be
> useful in order to allow defining specific rules.
> Do you think it would go against the moratorium?

I think that warning categories are a library feature: they are
mentioned in the library documentation, and not mentioned in the
reference manual (in fact, only a single warning *is* mentioned in
the reference manual, namely that exceptions in __del__ are printed -
which actually doesn't use the warnings module).

If it is the library feature, then it is exempt from the moratorium:

Allowed to Change
The standard library

As the standard library is not directly tied to the language
definition it is not covered by this moratorium.

Regards,
Martin
___
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] r85486 - python/branches/py3k/configure

[Martin v. Löwis]

Am 14.10.2010 19:57, schrieb Daniel Stutzbach:
> On Thu, Oct 14, 2010 at 12:38 PM, barry.warsaw
> mailto:python-check...@python.org>> wrote:
> 
> -# Generated by GNU Autoconf 2.65 for python 3.2.
> +# Generated by GNU Autoconf 2.67 for python 3.2.
> 
> 
> Was the change in autoconf versions intentional and/or is it a problem? 

I think it was intentional (at least deliberate), but I think it is a
problem and should be reverted. There is, at any point, the official
version that Python uses for autoconf, which at the moment is 2.65.
The rationale is that with changing autoconf versions, the actual
configure script will change forth and back, confusing attributions
(svn blame).

Regards,
Martin
___
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] r85486 - python/branches/py3k/configure

[Benjamin Peterson]

2010/10/14 "Martin v. Löwis" :
> Am 14.10.2010 19:57, schrieb Daniel Stutzbach:
>> On Thu, Oct 14, 2010 at 12:38 PM, barry.warsaw
>> mailto:python-check...@python.org>> wrote:
>>
>>     -# Generated by GNU Autoconf 2.65 for python 3.2.
>>     +# Generated by GNU Autoconf 2.67 for python 3.2.
>>
>>
>> Was the change in autoconf versions intentional and/or is it a problem?
>
> I think it was intentional (at least deliberate), but I think it is a
> problem and should be reverted. There is, at any point, the official
> version that Python uses for autoconf, which at the moment is 2.65.
> The rationale is that with changing autoconf versions, the actual
> configure script will change forth and back, confusing attributions
> (svn blame).

Why would anyone annotate configure? configure.in is stable wrt to
autoconf versions.



-- 
Regards,
Benjamin
___
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] r85486 - python/branches/py3k/configure

[Barry Warsaw]

On Oct 14, 2010, at 08:27 PM, Martin v. Löwis wrote:

>I think it was intentional (at least deliberate), but I think it is a
>problem and should be reverted. There is, at any point, the official
>version that Python uses for autoconf, which at the moment is 2.65.
>The rationale is that with changing autoconf versions, the actual
>configure script will change forth and back, confusing attributions
>(svn blame).

While it's true that we use AC_PREREQ(2.65), that specifies only the minimum
version of autoconf required.  Any time configure.in changes, configure has to
change too, and since it's a generated file, I think svn blame on configure is
kind of useless.

Should we appoint an autoconf BDFL who can commit changes after configure.in
is changed?  Is it possible to pin the autoconf version (not just floor it)?

-Barry


signature.asc
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] r85486 - python/branches/py3k/configure

[Martin v. Löwis]

>> I think it was intentional (at least deliberate), but I think it is a
>> problem and should be reverted. There is, at any point, the official
>> version that Python uses for autoconf, which at the moment is 2.65.
>> The rationale is that with changing autoconf versions, the actual
>> configure script will change forth and back, confusing attributions
>> (svn blame).
> 
> Why would anyone annotate configure? configure.in is stable wrt to
> autoconf versions.

Ok, it's more an issue with aesthetics, and also reproducibility
(what if somebody tests a configure change correctly, but it then
breaks with an older autoconf version?)

However, if people don't see this as a problem, we can also give
up the strictness of requiring an exact autoconf version (and
autoconf will already check for a minimum).

Regards,
Martin
___
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] r85486 - python/branches/py3k/configure

[Benjamin Peterson]

2010/10/14 "Martin v. Löwis" :
>>> I think it was intentional (at least deliberate), but I think it is a
>>> problem and should be reverted. There is, at any point, the official
>>> version that Python uses for autoconf, which at the moment is 2.65.
>>> The rationale is that with changing autoconf versions, the actual
>>> configure script will change forth and back, confusing attributions
>>> (svn blame).
>>
>> Why would anyone annotate configure? configure.in is stable wrt to
>> autoconf versions.
>
> Ok, it's more an issue with aesthetics, and also reproducibility
> (what if somebody tests a configure change correctly, but it then
> breaks with an older autoconf version?)
>
> However, if people don't see this as a problem, we can also give
> up the strictness of requiring an exact autoconf version (and
> autoconf will already check for a minimum).

I don't see it as any more of a problem than upgrading against other
dependencies (like gcc?).



-- 
Regards,
Benjamin
___
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] r85486 - python/branches/py3k/configure

[Martin v. Löwis]

> I don't see it as any more of a problem than upgrading against other
> dependencies (like gcc?).

Ok, so let's drop the requirement then.

Regards,
Martin
___
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] r85486 - python/branches/py3k/configure

[Barry Warsaw]

On Oct 14, 2010, at 09:11 PM, Martin v. Löwis wrote:

>> I don't see it as any more of a problem than upgrading against other
>> dependencies (like gcc?).
>
>Ok, so let's drop the requirement then.

Good for me.  Is there a place where this requirement is documented?

-Barry


signature.asc
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] r85486 - python/branches/py3k/configure

[Martin v. Löwis]

> Is it possible to pin the autoconf version (not just floor it)?

Not that I know of, no.

> Should we appoint an autoconf BDFL who can commit changes after configure.in
> is changed?  

Most recently, it was between me and Benjamin most of the time, and that
seems to have worked fine. Now Benjamin has ruled that we stop
pinning it. I still have my reservations, but no real objective
objection (i.e. -0)

Regards,
Martin
___
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