From dickinsm at gmail.com  Tue Dec  1 14:16:59 2009
From: dickinsm at gmail.com (Mark Dickinson)
Date: Tue, 1 Dec 2009 13:16:59 +0000
Subject: [Python-Dev] Drop support for ones' complement machines?
Message-ID: <5c6f2a5d0912010516t1f8bcf3ckb8c9f3029ba1b0f3@mail.gmail.com>

Question:  should the CPython source compile cleanly and work
correctly on (mostly ancient or hypothetical) machines that use
ones' complement or sign-and-magnitude to represent signed integers?

I'd like to explicitly document and make use of the following assumptions
about the underlying C implementation for CPython.  These assumptions
go beyond what's guaranteed by the various C and C++ standards, but
seem to be almost universally satisfied on modern machines:

 - signed integers are represented using two's complement
 - for signed integers the bit pattern 100....000 is not a trap representation;
   hence INT_MIN = -INT_MAX-1, LONG_MIN = -LONG_MAX-1, etc.
 - conversion from an unsigned type to a signed type wraps modulo
   2**(width of unsigned type).

Any thoughts, comments or objections?  This may seem academic
(and perhaps it is), but it affects the possible solutions to e.g.,

http://bugs.python.org/issue7406

The assumptions listed above are already tacitly used in various bits
of the CPython source (Objects/intobject.c notably makes use of the
first two assumptions in the implementations of int_and, int_or and
int_xor), while other bits of code make a special effort to *not* assume
more than the C standards allow.  Whatever the answer to the initial
question is, it seems worth having an explicitly documented policy.

If we want Python's core source to remain 100% standards-compliant,
then int_and, int_or, etc. should be rewritten with ones' complement
and sign-and-magnitude machines in mind.  That's certainly feasible,
but it seems silly to do such a rewrite without a good reason.
Python-dev agreement that ones' complement machines should be
supported would, of course, be a good reason.

Mark

From martin at v.loewis.de  Tue Dec  1 14:46:51 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 01 Dec 2009 14:46:51 +0100
Subject: [Python-Dev] Drop support for ones' complement machines?
In-Reply-To: <5c6f2a5d0912010516t1f8bcf3ckb8c9f3029ba1b0f3@mail.gmail.com>
References: <5c6f2a5d0912010516t1f8bcf3ckb8c9f3029ba1b0f3@mail.gmail.com>
Message-ID: <4B151E4B.4070103@v.loewis.de>

Mark Dickinson wrote:
> Question:  should the CPython source compile cleanly and work
> correctly on (mostly ancient or hypothetical) machines that use
> ones' complement or sign-and-magnitude to represent signed integers?

I think that's the wrong question to ask. What you really meant to ask
(IIUC) is this: Should CPython be allowed to invoke behavior that is
declared undefined by the C standard, but has a clear meaning when
assuming two's complement?

This is different from your question, by taking into account that
compilers may perform optimization based on the promises of the C
standard.

For example, compiling

int f(int a)
{
        if (a+1>a)
                return 6;
        else
                return 7;
}

with gcc 4.3.4, with -O2 -fomit-frame-pointer, compiles this
to

f:
        movl    $6, %eax
        ret

IOW, the compiler determines that the function will always
return 6 (*). If you assume that the int type is guaranteed
in two's complement, then the generated code would be wrong
(and Python would not work correctly).

So this isn't about unrealistic and outdated hardware, but about
current and real problems. Therefore, I don't think we should make
assumptions beyond what standard C guarantees.

Regards,
Martin

(*) If you wonder why the gcc behavior is conforming to C:
if a+1 does not overflow, it will be indeed greater than a,
and the result is 6.
If a+1 does overflow, undefined behavior occurs, and the
program may do whatever it desires, including returning 6.

From dickinsm at gmail.com  Tue Dec  1 15:02:17 2009
From: dickinsm at gmail.com (Mark Dickinson)
Date: Tue, 1 Dec 2009 14:02:17 +0000
Subject: [Python-Dev] Drop support for ones' complement machines?
In-Reply-To: <4B151E4B.4070103@v.loewis.de>
References: <5c6f2a5d0912010516t1f8bcf3ckb8c9f3029ba1b0f3@mail.gmail.com>
	<4B151E4B.4070103@v.loewis.de>
Message-ID: <5c6f2a5d0912010602v9878d4ev8408ad00ec33bdda@mail.gmail.com>

On Tue, Dec 1, 2009 at 1:46 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> Mark Dickinson wrote:
>> Question: ?should the CPython source compile cleanly and work
>> correctly on (mostly ancient or hypothetical) machines that use
>> ones' complement or sign-and-magnitude to represent signed integers?
>
> I think that's the wrong question to ask. What you really meant to ask
> (IIUC) is this: Should CPython be allowed to invoke behavior that is
> declared undefined by the C standard, but has a clear meaning when
> assuming two's complement?

No, the original question really was the question that I meant to ask.  :)

I absolutely agree that CPython shouldn't invoke undefined behaviour,
precisely because of the risk of gcc (or some other compiler)
optimizing based on the assumption that undefined behaviour never
happens.  This is why I opened issue 7406.

So my question, and the listed assumptions, are about implementation-
defined behaviour, not undefined behaviour.  For the 3 assumptions listed,
gcc obeys all those assumptions (see section 4.5 of the GCC manual).

http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Integers-implementation.html

Personally I can't think of any good reason not to make these assumptions.

Mark

From martin at v.loewis.de  Tue Dec  1 16:32:12 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 01 Dec 2009 16:32:12 +0100
Subject: [Python-Dev] Drop support for ones' complement machines?
In-Reply-To: <5c6f2a5d0912010602v9878d4ev8408ad00ec33bdda@mail.gmail.com>
References: <5c6f2a5d0912010516t1f8bcf3ckb8c9f3029ba1b0f3@mail.gmail.com>	
	<4B151E4B.4070103@v.loewis.de>
	<5c6f2a5d0912010602v9878d4ev8408ad00ec33bdda@mail.gmail.com>
Message-ID: <4B1536FC.7030501@v.loewis.de>

> No, the original question really was the question that I meant to ask.  :)

Ok. Then the reference to issue 7406 is really confusing, as this is
about undefined behavior - why does the answer to your question affect
the resolution of this issue?

> I absolutely agree that CPython shouldn't invoke undefined behaviour,
> precisely because of the risk of gcc (or some other compiler)
> optimizing based on the assumption that undefined behaviour never
> happens.  This is why I opened issue 7406.
> 
> So my question, and the listed assumptions, are about implementation-
> defined behaviour, not undefined behaviour.  For the 3 assumptions listed,
> gcc obeys all those assumptions (see section 4.5 of the GCC manual).
> 
> http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Integers-implementation.html

I think gcc makes promises here beyond resolving implementation-defined
behavior. For bitshift operators, C99 says (6.5.7)

       [#4] The result of E1  <<  E2  is  E1  left-shifted  E2  bit
       positions; vacated bits are filled with zeros.  If E1 has an
       unsigned type, the value of the result  is  E1?2E2,  reduced
       modulo  one more than the maximum value representable in the
       result type.  If E1 has a signed type and nonnegative value,
       and E1?2E2 is representable in the result type, then that is
       the resulting value; otherwise, the behavior is undefined.

       [#5] The result of E1 >>  E2  is  E1  right-shifted  E2  bit
       positions.  If E1 has an unsigned type or if E1 has a signed
       type and a nonnegative value, the value of the result is the
       integral part of the quotient of E1 divided by the quantity,
       2 raised to the power E2.  If E1 has a  signed  type  and  a
       negative  value,  the  resulting  value  is  implementation-
       defined.

Notice that only right-shift is implementation-defined. The left-shift
of a negative value invokes undefined behavior, even though gcc
guarantees that the sign bit will shift out the way it would under
two's complement.

So I'm still opposed to codifying your assumptions if that would mean
that CPython could now start relying on left-shift to behave in a
certain way. For right-shift, your assumptions won't help for
speculation about the result: I think it's realistic that some
implementations sign-extend, yet others perform the shift unsigned
(i.e. zero-extend).

I'd rather prefer to explicitly list what CPython assumes about the
outcome of specific operations. If this is just about &, |, ^, and ~,
then its fine with me.

Regards,
Martin

From dickinsm at gmail.com  Tue Dec  1 16:57:30 2009
From: dickinsm at gmail.com (Mark Dickinson)
Date: Tue, 1 Dec 2009 15:57:30 +0000
Subject: [Python-Dev] Drop support for ones' complement machines?
In-Reply-To: <4B1536FC.7030501@v.loewis.de>
References: <5c6f2a5d0912010516t1f8bcf3ckb8c9f3029ba1b0f3@mail.gmail.com>
	<4B151E4B.4070103@v.loewis.de>
	<5c6f2a5d0912010602v9878d4ev8408ad00ec33bdda@mail.gmail.com>
	<4B1536FC.7030501@v.loewis.de>
Message-ID: <5c6f2a5d0912010757y6f2ab07al84b0184a1f8baead@mail.gmail.com>

On Tue, Dec 1, 2009 at 3:32 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> No, the original question really was the question that I meant to ask. ?:)
>
> Ok. Then the reference to issue 7406 is really confusing, as this is
> about undefined behavior - why does the answer to your question affect
> the resolution of this issue?

Apologies for the lack of clarity.

So in issue 7406 I'm complaining (amongst other things) that int_add
uses the expression 'x+y', where x and y are longs, and expects this
expression to wrap modulo 2**n on overflow.  As you say, this is
undefined behaviour.  One obvious way to fix it is to write

  (long)((unsigned long)x + (unsigned long)y)

instead.

But *here's* the problem:  this still isn't a portable solution!
It no longer depends on undefined behaviour, but it *does*
depend on implementation-defined behaviour:  namely, what happens
when an unsigned long that's greater than LONG_MAX is converted to
long.  (See C99 6.3.1.3., paragraph 3:  "Otherwise, the new type is
signed and the value cannot be represented in it; either the result is
implementation-defined or an implementation-defined signal is raised.")

It's this implementation-defined behaviour that I'd like to assume.

> I think gcc makes promises here beyond resolving implementation-defined
> behavior. For bitshift operators, C99 says (6.5.7)
> [...]

Yes, I'm very well aware of the issues with shifting signed integers;  I'm
not proposing making any assumptions here.

> So I'm still opposed to codifying your assumptions if that would mean
> that CPython could now start relying on left-shift to behave in a
> certain way. For right-shift, your assumptions won't help for
> speculation about the result: I think it's realistic that some
> implementations sign-extend, yet others perform the shift unsigned
> (i.e. zero-extend).
>
> I'd rather prefer to explicitly list what CPython assumes about the
> outcome of specific operations. If this is just about &, |, ^, and ~,
> then its fine with me.

I'm not even interested in going this far:  I only want to make explicit
the three assumptions I specified in my original post:

 - signed integers are represented using two's complement

 - for signed integers the bit pattern 100....000 is not a trap representation

 - conversion from an unsigned type to a signed type wraps modulo
   2**(width of unsigned type).

(Though I think these assumptions do in fact completely determine
the behaviour of &, |, ^, ~.)

As far as I know these are almost universally satisfied for current
C implementations, and there's little reason not to assume them,
but I didn't want to document and use these assumptions without
consulting python-dev first.

Mark

From martin at v.loewis.de  Tue Dec  1 17:08:58 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 01 Dec 2009 17:08:58 +0100
Subject: [Python-Dev] Drop support for ones' complement machines?
In-Reply-To: <5c6f2a5d0912010757y6f2ab07al84b0184a1f8baead@mail.gmail.com>
References: <5c6f2a5d0912010516t1f8bcf3ckb8c9f3029ba1b0f3@mail.gmail.com>	<4B151E4B.4070103@v.loewis.de>	<5c6f2a5d0912010602v9878d4ev8408ad00ec33bdda@mail.gmail.com>	<4B1536FC.7030501@v.loewis.de>
	<5c6f2a5d0912010757y6f2ab07al84b0184a1f8baead@mail.gmail.com>
Message-ID: <4B153F9A.6080307@v.loewis.de>

>> I'd rather prefer to explicitly list what CPython assumes about the
>> outcome of specific operations. If this is just about &, |, ^, and ~,
>> then its fine with me.
> 
> I'm not even interested in going this far:

I still am: with your list of assumptions, it is unclear (to me, at
least) what the consequences are. So I'd rather see an explicit list
of consequences, instead of buying a pig in a poke.

Regards,
Martin

From foom at fuhm.net  Tue Dec  1 17:17:00 2009
From: foom at fuhm.net (James Y Knight)
Date: Tue, 1 Dec 2009 11:17:00 -0500
Subject: [Python-Dev] Drop support for ones' complement machines?
In-Reply-To: <4B153F9A.6080307@v.loewis.de>
References: <5c6f2a5d0912010516t1f8bcf3ckb8c9f3029ba1b0f3@mail.gmail.com>	<4B151E4B.4070103@v.loewis.de>	<5c6f2a5d0912010602v9878d4ev8408ad00ec33bdda@mail.gmail.com>	<4B1536FC.7030501@v.loewis.de>
	<5c6f2a5d0912010757y6f2ab07al84b0184a1f8baead@mail.gmail.com>
	<4B153F9A.6080307@v.loewis.de>
Message-ID: <822C94CD-54D7-4AEA-860C-B294027B1A11@fuhm.net>


On Dec 1, 2009, at 11:08 AM, Martin v. L?wis wrote:

>>> I'd rather prefer to explicitly list what CPython assumes about the
>>> outcome of specific operations. If this is just about &, |, ^, and ~,
>>> then its fine with me.
>> 
>> I'm not even interested in going this far:
> 
> I still am: with your list of assumptions, it is unclear (to me, at
> least) what the consequences are. So I'd rather see an explicit list
> of consequences, instead of buying a pig in a poke.

I think all that needs to be defined is that conversion from unsigned to signed, and (negative) signed to unsigned integers have 2's complement wrapping semantics, and does not affect the bit pattern in memory.

Stating it that way makes it clearer that all you're assuming is the operation of the cast operators, and it seems to me that it implies the other requirements.

James

From dickinsm at gmail.com  Tue Dec  1 17:19:27 2009
From: dickinsm at gmail.com (Mark Dickinson)
Date: Tue, 1 Dec 2009 16:19:27 +0000
Subject: [Python-Dev] Drop support for ones' complement machines?
In-Reply-To: <4B153F9A.6080307@v.loewis.de>
References: <5c6f2a5d0912010516t1f8bcf3ckb8c9f3029ba1b0f3@mail.gmail.com>
	<4B151E4B.4070103@v.loewis.de>
	<5c6f2a5d0912010602v9878d4ev8408ad00ec33bdda@mail.gmail.com>
	<4B1536FC.7030501@v.loewis.de>
	<5c6f2a5d0912010757y6f2ab07al84b0184a1f8baead@mail.gmail.com>
	<4B153F9A.6080307@v.loewis.de>
Message-ID: <5c6f2a5d0912010819n323ee716yd7520194c0799104@mail.gmail.com>

On Tue, Dec 1, 2009 at 4:08 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>>> I'd rather prefer to explicitly list what CPython assumes about the
>>> outcome of specific operations. If this is just about &, |, ^, and ~,
>>> then its fine with me.
>>
>> I'm not even interested in going this far:
>
> I still am: with your list of assumptions, it is unclear (to me, at
> least) what the consequences are. So I'd rather see an explicit list
> of consequences, instead of buying a pig in a poke.

Okay;  though I think that my list of assumptions is easier to check
directly for any given implementation:  it corresponds
exactly to items 2 and 4 in C99 J.3.5, and any conforming
C implementation is required to explicitly document how it
behaves with regard to these items.

I'm not sure how to decide which particular consequences
should be listed, but those for &, |, ^ and ~ could certainly
be included.

Mark

From dickinsm at gmail.com  Tue Dec  1 17:24:08 2009
From: dickinsm at gmail.com (Mark Dickinson)
Date: Tue, 1 Dec 2009 16:24:08 +0000
Subject: [Python-Dev] Drop support for ones' complement machines?
In-Reply-To: <822C94CD-54D7-4AEA-860C-B294027B1A11@fuhm.net>
References: <5c6f2a5d0912010516t1f8bcf3ckb8c9f3029ba1b0f3@mail.gmail.com>
	<4B151E4B.4070103@v.loewis.de>
	<5c6f2a5d0912010602v9878d4ev8408ad00ec33bdda@mail.gmail.com>
	<4B1536FC.7030501@v.loewis.de>
	<5c6f2a5d0912010757y6f2ab07al84b0184a1f8baead@mail.gmail.com>
	<4B153F9A.6080307@v.loewis.de>
	<822C94CD-54D7-4AEA-860C-B294027B1A11@fuhm.net>
Message-ID: <5c6f2a5d0912010824i45f0ffd5q8854c55b8f4eed6b@mail.gmail.com>

On Tue, Dec 1, 2009 at 4:17 PM, James Y Knight <foom at fuhm.net> wrote:
> I think all that needs to be defined is that conversion from unsigned to signed, and (negative) signed to unsigned integers have 2's complement wrapping semantics, and does not affect the bit pattern in memory.

Yes, I think everything does pretty much follow from this, since for ones'
complement or sign-and-magnitude these wrapping semantics are impossible,
because the signed type doesn't have enough distinct possible values.

> Stating it that way makes it clearer that all you're assuming is the operation of the cast operators, and it seems to me that it implies the other requirements.

Agreed.

Thanks,

Mark

From alexander.belopolsky at gmail.com  Tue Dec  1 17:47:45 2009
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 1 Dec 2009 11:47:45 -0500
Subject: [Python-Dev] Drop support for ones' complement machines?
In-Reply-To: <5c6f2a5d0912010824i45f0ffd5q8854c55b8f4eed6b@mail.gmail.com>
References: <5c6f2a5d0912010516t1f8bcf3ckb8c9f3029ba1b0f3@mail.gmail.com>
	<4B151E4B.4070103@v.loewis.de>
	<5c6f2a5d0912010602v9878d4ev8408ad00ec33bdda@mail.gmail.com>
	<4B1536FC.7030501@v.loewis.de>
	<5c6f2a5d0912010757y6f2ab07al84b0184a1f8baead@mail.gmail.com>
	<4B153F9A.6080307@v.loewis.de>
	<822C94CD-54D7-4AEA-860C-B294027B1A11@fuhm.net>
	<5c6f2a5d0912010824i45f0ffd5q8854c55b8f4eed6b@mail.gmail.com>
Message-ID: <d38f5330912010847r2c7a0fc3xe22ad4b6102a23d@mail.gmail.com>

On Tue, Dec 1, 2009 at 11:24 AM, Mark Dickinson <dickinsm at gmail.com> wrote:
> On Tue, Dec 1, 2009 at 4:17 PM, James Y Knight <foom at fuhm.net> wrote:
>> I think all that needs to be defined is that conversion from unsigned to signed, and (negative) signed to
>>  unsigned integers have 2's complement wrapping semantics, and does not affect the bit pattern in memory.


I don't know if this particular implementation defined behavior is
safe to be relied upon. I just want to suggest that if any such
assumption is made in the code, a test should be added to configure to
complain loudly if a platform violating the assumption is found in the
future.

From rambham at gmail.com  Tue Dec  1 18:01:53 2009
From: rambham at gmail.com (Ram Bhamidipaty)
Date: Tue, 1 Dec 2009 09:01:53 -0800
Subject: [Python-Dev] possible bug in python importing pyc files
Message-ID: <b5e72010912010901h1b739376i8691581b248818f0@mail.gmail.com>

Hi,

I have some code that exhibits behavior that might be a python import bug.

The code is part of a set of unit tests. One test in passes when no .pyc files
exist, but fails when the pyc file is present on disk. My code is not doing any
thing special with import or pickle or anything "fancy". I have confirmed the
behavior in 2.6.4, as well the svn 2.6 version. The svn 2.7 version
always fails.
All builds were production builds (not debug).

The code that shows this problem is owned by my company, I'm not sure
if I would be able to produce it to create a bug report. But I do have some time
to help debug the problem.

What steps should I take to try to isolate the problem?

Thanks for any info.
-Ram

From dickinsm at gmail.com  Tue Dec  1 18:22:35 2009
From: dickinsm at gmail.com (Mark Dickinson)
Date: Tue, 1 Dec 2009 17:22:35 +0000
Subject: [Python-Dev] Drop support for ones' complement machines?
In-Reply-To: <d38f5330912010847r2c7a0fc3xe22ad4b6102a23d@mail.gmail.com>
References: <5c6f2a5d0912010516t1f8bcf3ckb8c9f3029ba1b0f3@mail.gmail.com>
	<4B151E4B.4070103@v.loewis.de>
	<5c6f2a5d0912010602v9878d4ev8408ad00ec33bdda@mail.gmail.com>
	<4B1536FC.7030501@v.loewis.de>
	<5c6f2a5d0912010757y6f2ab07al84b0184a1f8baead@mail.gmail.com>
	<4B153F9A.6080307@v.loewis.de>
	<822C94CD-54D7-4AEA-860C-B294027B1A11@fuhm.net>
	<5c6f2a5d0912010824i45f0ffd5q8854c55b8f4eed6b@mail.gmail.com>
	<d38f5330912010847r2c7a0fc3xe22ad4b6102a23d@mail.gmail.com>
Message-ID: <5c6f2a5d0912010922j465ded2q7769326d87d4981b@mail.gmail.com>

On Tue, Dec 1, 2009 at 4:47 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
>> On Tue, Dec 1, 2009 at 4:17 PM, James Y Knight <foom at fuhm.net> wrote:
>>> I think all that needs to be defined is that conversion from unsigned to signed, and (negative) signed to
>>> ?unsigned integers have 2's complement wrapping semantics, and does not affect the bit pattern in memory.
>
>
> I don't know if this particular implementation defined behavior is
> safe to be relied upon. I just want to suggest that if any such
> assumption is made in the code, a test should be added to configure to
> complain loudly if a platform violating the assumption is found in the
> future.

That sounds like a good idea.  An extension of that would be to define
an UNSIGNED_TO_SIGNED macro (insert better name here) which,
depending on the result of the configure test, either used a direct cast
or a workaround.  E.g., for an unsigned long x,

  ((x) >= 0 ? (long)(x) : ~(long)~(x))

always gives the appropriate wraparound semantics (I think), assuming
two's complement with no trap representation.

Mark

From dickinsm at gmail.com  Tue Dec  1 18:25:04 2009
From: dickinsm at gmail.com (Mark Dickinson)
Date: Tue, 1 Dec 2009 17:25:04 +0000
Subject: [Python-Dev] Drop support for ones' complement machines?
In-Reply-To: <5c6f2a5d0912010922j465ded2q7769326d87d4981b@mail.gmail.com>
References: <5c6f2a5d0912010516t1f8bcf3ckb8c9f3029ba1b0f3@mail.gmail.com>
	<4B151E4B.4070103@v.loewis.de>
	<5c6f2a5d0912010602v9878d4ev8408ad00ec33bdda@mail.gmail.com>
	<4B1536FC.7030501@v.loewis.de>
	<5c6f2a5d0912010757y6f2ab07al84b0184a1f8baead@mail.gmail.com>
	<4B153F9A.6080307@v.loewis.de>
	<822C94CD-54D7-4AEA-860C-B294027B1A11@fuhm.net>
	<5c6f2a5d0912010824i45f0ffd5q8854c55b8f4eed6b@mail.gmail.com>
	<d38f5330912010847r2c7a0fc3xe22ad4b6102a23d@mail.gmail.com>
	<5c6f2a5d0912010922j465ded2q7769326d87d4981b@mail.gmail.com>
Message-ID: <5c6f2a5d0912010925m23f8e270k180147d3fb37df47@mail.gmail.com>

On Tue, Dec 1, 2009 at 5:22 PM, Mark Dickinson <dickinsm at gmail.com> wrote:
> or a workaround. ?E.g., for an unsigned long x,
>
>  ((x) >= 0 ? (long)(x) : ~(long)~(x))
>
> always gives the appropriate wraparound semantics (I think), assuming

Sorry;  should have tested.  Try:

((x) <= LONG_MAX ? (long)(x) : ~(long)~(x))

Mark

From martin at v.loewis.de  Tue Dec  1 18:45:53 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 01 Dec 2009 18:45:53 +0100
Subject: [Python-Dev] Drop support for ones' complement machines?
In-Reply-To: <5c6f2a5d0912010819n323ee716yd7520194c0799104@mail.gmail.com>
References: <5c6f2a5d0912010516t1f8bcf3ckb8c9f3029ba1b0f3@mail.gmail.com>	
	<4B151E4B.4070103@v.loewis.de>	
	<5c6f2a5d0912010602v9878d4ev8408ad00ec33bdda@mail.gmail.com>	
	<4B1536FC.7030501@v.loewis.de>	
	<5c6f2a5d0912010757y6f2ab07al84b0184a1f8baead@mail.gmail.com>	
	<4B153F9A.6080307@v.loewis.de>
	<5c6f2a5d0912010819n323ee716yd7520194c0799104@mail.gmail.com>
Message-ID: <4B155651.7020706@v.loewis.de>

>>>> I'd rather prefer to explicitly list what CPython assumes about the
>>>> outcome of specific operations. If this is just about &, |, ^, and ~,
>>>> then its fine with me.
>>> I'm not even interested in going this far:
>> I still am: with your list of assumptions, it is unclear (to me, at
>> least) what the consequences are. So I'd rather see an explicit list
>> of consequences, instead of buying a pig in a poke.
> 
> Okay;  though I think that my list of assumptions is easier to check
> directly for any given implementation:  it corresponds
> exactly to items 2 and 4 in C99 J.3.5, and any conforming
> C implementation is required to explicitly document how it
> behaves with regard to these items.

I'm in favor stating the assumptions the way you do (*), I just
want to have an additional explicit statement what consequences
you assume out of these assumptions.

> I'm not sure how to decide which particular consequences
> should be listed, but those for &, |, ^ and ~ could certainly
> be included.

It should give the CPython contributors an indication what kind
of code would be ok, and which would not. Perhaps it should include
both a black list and a white list: some may assume that two's
complement already provides guarantees on left-shift, when it
actually does not (**).

Regards,
Martin

(*) I wonder why you are not talking about padding bits
(6.2.6.2p1)
(**) I also wonder why C fails to make left-shift
implementation-defined, perhaps with an even stronger binding
to the options for the integer representation.

From guido at python.org  Tue Dec  1 19:05:43 2009
From: guido at python.org (Guido van Rossum)
Date: Tue, 1 Dec 2009 10:05:43 -0800
Subject: [Python-Dev] possible bug in python importing pyc files
In-Reply-To: <b5e72010912010901h1b739376i8691581b248818f0@mail.gmail.com>
References: <b5e72010912010901h1b739376i8691581b248818f0@mail.gmail.com>
Message-ID: <ca471dc20912011005u457d42deh7aa3777e321be1ed@mail.gmail.com>

What kind of failure do you get? A a failed test, a Python exception,
or a core dump?

Are you sure there is no code in your app or in your tests that looks
at __file__ and trips up over if it ends in '.pyc' instead of '.py' ?

Are you importing from zipfiles (e.g. eggs you've downloaded)?

Can you remember a time when this wasn't happening? Were you using a
different Python version then or was your application + tests
different? If it wasn't happening with an earlier version of Python,
please confirm -- this helps us believe that the problem isn't
somewhere in your app.

It would be very useful to isolate the problem to the existence or
non-existence of a single .pyc file -- if as you think there is a bug
in the .pyc reading or writing, it must be a very rare test and is
likely only triggered by one particular file.

The first step would probably be to boil down the problem to a
particular unit test. (If you are using Python's unittest.main()
driver, there are command line flags to run only a specific test, so
that should be easy enough.) Then remove all .pyc files, run the test
again, and see which .pyc files are created by running it. Then
confirm that the test fails. Then delete half the .pyc files and see
if the test still fails. You can then start bisecting by removing more
or fewer .pyc files until you've boiled it down to one particular .pyc
file. Then look at the source and see if there's something funny (e.g.
is it very long, or does it have a very long token or expression?).

On Tue, Dec 1, 2009 at 9:01 AM, Ram Bhamidipaty <rambham at gmail.com> wrote:
> Hi,
>
> I have some code that exhibits behavior that might be a python import bug.
>
> The code is part of a set of unit tests. One test in passes when no .pyc files
> exist, but fails when the pyc file is present on disk. My code is not doing any
> thing special with import or pickle or anything "fancy". I have confirmed the
> behavior in 2.6.4, as well the svn 2.6 version. The svn 2.7 version
> always fails.
> All builds were production builds (not debug).
>
> The code that shows this problem is owned by my company, I'm not sure
> if I would be able to produce it to create a bug report. But I do have some time
> to help debug the problem.
>
> What steps should I take to try to isolate the problem?
>
> Thanks for any info.
> -Ram
> _______________________________________________
> 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 martin at v.loewis.de  Tue Dec  1 19:12:32 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 01 Dec 2009 19:12:32 +0100
Subject: [Python-Dev] possible bug in python importing pyc files
In-Reply-To: <b5e72010912010901h1b739376i8691581b248818f0@mail.gmail.com>
References: <b5e72010912010901h1b739376i8691581b248818f0@mail.gmail.com>
Message-ID: <4B155C90.9070806@v.loewis.de>

> The code that shows this problem is owned by my company, I'm not sure
> if I would be able to produce it to create a bug report. But I do have some time
> to help debug the problem.
> 
> What steps should I take to try to isolate the problem?

Try isolating the precise instruction that behaves incorrectly (when the
.pyc is present). If you have already a failing test case, this should
be fairly easy to do. Some variable apparently has a value that it must
not have, or some operation yields a result that it must not yield. Find
out where it first behaves incorrectly in the failing case.

To do so, you may want to familiarize with pdb. Put

import pdb;pdb.set_trace()

into the failing test case, and try single-stepping through it. Make
sure stdin/stdout doesn't get redirected, since that confused pdb.

HTH,
Martin

From rambham at gmail.com  Tue Dec  1 18:28:45 2009
From: rambham at gmail.com (Ram Bhamidipaty)
Date: Tue, 1 Dec 2009 09:28:45 -0800
Subject: [Python-Dev] import issue - solved
Message-ID: <b5e72010912010928h227271abl1d71649d67e8ad61@mail.gmail.com>

Please ignore my earlier message. The problem turned out to
be having a file "test1.py" in the current directory that somehow
was interfering with unit testing.
-Ram

From dickinsm at gmail.com  Tue Dec  1 22:58:47 2009
From: dickinsm at gmail.com (Mark Dickinson)
Date: Tue, 1 Dec 2009 21:58:47 +0000
Subject: [Python-Dev] Drop support for ones' complement machines?
In-Reply-To: <4B155651.7020706@v.loewis.de>
References: <5c6f2a5d0912010516t1f8bcf3ckb8c9f3029ba1b0f3@mail.gmail.com>
	<4B151E4B.4070103@v.loewis.de>
	<5c6f2a5d0912010602v9878d4ev8408ad00ec33bdda@mail.gmail.com>
	<4B1536FC.7030501@v.loewis.de>
	<5c6f2a5d0912010757y6f2ab07al84b0184a1f8baead@mail.gmail.com>
	<4B153F9A.6080307@v.loewis.de>
	<5c6f2a5d0912010819n323ee716yd7520194c0799104@mail.gmail.com>
	<4B155651.7020706@v.loewis.de>
Message-ID: <5c6f2a5d0912011358h17dc51d2s4c8657d9d3f3f77e@mail.gmail.com>

[Mark]
> I'm not sure how to decide which particular consequences
> should be listed, but those for &, |, ^ and ~ could certainly
> be included.

[Martin]
> It should give the CPython contributors an indication what kind
> of code would be ok, and which would not. Perhaps it should include
> both a black list and a white list: some may assume that two's
> complement already provides guarantees on left-shift, when it
> actually does not (**).

Okay.  I'll have to think about this a bit;  I'll try to come up with
some suitable wording.

> (*) I wonder why you are not talking about padding bits
> (6.2.6.2p1)

Good point.  Mostly because I haven't recently encountered any
code where it matters, I suppose.  But there's certainly CPython
source that assumes no padding bits:  long_hash in longobject.c
is one example that comes to mind:  it assumes that the number
of value bits in an unsigned long is 8*SIZEOF_LONG.

> (**) I also wonder why C fails to make left-shift
> implementation-defined, perhaps with an even stronger binding
> to the options for the integer representation.

I wonder too.  The C rationale document doesn't
have anything to say on this subject.

Mark

From berserker_r at hotmail.com  Wed Dec  2 11:45:22 2009
From: berserker_r at hotmail.com (Berserker)
Date: Wed, 02 Dec 2009 11:45:22 +0100
Subject: [Python-Dev] orphan tstate problem
Message-ID: <hf5gg2$8ft$1@ger.gmane.org>

Hi, I'm developing a software which embeds Python as scripting language.
The software acts as webserver and for each request it peeks a thread 
from a pool which in turn loads a python script to generate the response 
(something like mod_python).
Since each http request is "independent" from others one, I need to 
create a new interpreter with its own dictionary every time.
I'm exposing lots of C++ wrapped code and, in order to provide a sort of 
"parallelism" between each request, I'm using this mechanism for each 
registered callback:

P = python core
A = my application

P: invokes the registered C callback
A: PyEval_SaveThread (allows others threads to run/resume their scripts)
A: invoke C/C++ application's functions (which don't touch CPython API)
A: PyEval_RestoreThread (takes back the lock)
P: resume the execution of the script

(the above schema is the same of 
Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS documented in ceval.h at 
line 83)

The problem I have encountered is that when I process two requests 
simultaneously, Python reports the fatal error "ceval: orphan tstate".
I'm not an expert of the CPython internals API but I take a look at the 
file ceval.c (actually I'm using python 2x but in the 3x version I 
noticed it's the same) and the code involved is:

/* Give another thread a chance */

if (PyThreadState_Swap(NULL) != tstate)
    Py_FatalError("ceval: tstate mix-up");
PyThread_release_lock(interpreter_lock);

/* Other threads may run now */

PyThread_acquire_lock(interpreter_lock, 1);
if (PyThreadState_Swap(tstate) != NULL)
    Py_FatalError("ceval: orphan tstate");

Can anyone explain me the meaning of those fatal errors (in particular 
the "orphan tstate" one)? Why the return value should be null?
As far as I understand after the "PyThread_release_lock" others threads 
are allowed to run and, if you take a look again at my above schema, 
PyThreadState_Swap is supposed to be called between 
PyThread_release_lock/PyThread_acquire_lock, exactly where the comment 
"Other threads may run now" is placed. If i changed the code in order to 
not fire a fatal error after the second PyThreadState_Swap everything
seems to work fine, but I'm afraid it's not the "proper" solution and I 
need to understand the meaning of that fatal error.

Sorry for the long post and for my bad english, I hope that someone 
could really help me.

Thanks


From ncoghlan at gmail.com  Wed Dec  2 14:17:52 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 02 Dec 2009 23:17:52 +1000
Subject: [Python-Dev] orphan tstate problem
In-Reply-To: <hf5gg2$8ft$1@ger.gmane.org>
References: <hf5gg2$8ft$1@ger.gmane.org>
Message-ID: <4B166900.1040509@gmail.com>

Berserker wrote:
> Sorry for the long post and for my bad english, I hope that someone
> could really help me.

Unfortunately, this isn't the right list - python-dev is for development
*of* Python rather than development *with* Python (and the latter
includes using the CPython C API).

I suggest trying again either on the general python list
(python-list at python.org) or else on the C API special interest group
(capi-sig at python.org).

Regards,
Nick.

P.S. Off the top of my head, I would be asking if you have done anything
to initialise the embedded Python's threading support, since the
interpreter assumes single threaded operation by default and you don't
mention initialising the thread support in your message ("import
threading" on the Python side will do it, or else there's a C API call
to do it explicitly).

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From eric at trueblade.com  Thu Dec  3 12:19:30 2009
From: eric at trueblade.com (Eric Smith)
Date: Thu, 03 Dec 2009 06:19:30 -0500
Subject: [Python-Dev] Unicode locale values in 2.7
Message-ID: <4B179EC2.9040705@trueblade.com>

While researching http://bugs.python.org/issue7327, I've come to the
conclusion that trunk handles locales incorrectly in regards to Unicode.
Fixing this would be the first step toward resolving this issue with 
float and Decimal locale-aware formatting.

The issue concerns the locale "cs_CZ.UTF-8", and the "thousands_sep"
value (among others). The C struct lconv (in Linux) contains '\xc2\xa0'
for thousands_sep. In py3k this is handled by calling mbstowcs (which is
locale-aware) and then PyUnicode_FromWideChar, so the value is converted
to u"\xa0" (non-breaking space).

But in trunk, the value is just used as-is. So when formating a decimal,
for example, '\xc2\xa0' is just inserted into the result, such as:
>>> format(Decimal('1000'), 'n')
'1\xc2\xa0000'
This doesn't make much sense, and causes an error when converting it to
unicode:
>>> format(Decimal('1000'), u'n')
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/root/python/trunk/Lib/decimal.py", line 3609, in __format__
     return _format_number(self._sign, intpart, fracpart, exp, spec)
   File "/root/python/trunk/Lib/decimal.py", line 5704, in _format_number
     return _format_align(sign, intpart+fracpart, spec)
   File "/root/python/trunk/Lib/decimal.py", line 5595, in _format_align
     result = unicode(result)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 1:
ordinal not in range(128)

I believe that the correct solution is to do what py3k does in locale,
which is to convert the struct lconv values to unicode. But since this
would be a disruptive change if universally applied, I'd like to propose
that we only convert to unicode if the values won't fit into a str.

So the algorithm would be something like:
1. call mbstowcs
2. if every value in the result is in the range [32, 126], return a str
3. otherwise, return a unicode

This would mean that for most locales, the current behavior in trunk
wouldn't change: the locale.localeconv() values would continue to be
str. Only for those locales where the values wouldn't fit into a str
would unicode be returned.

Does this seem like an acceptable change?

Eric.

PS: Thanks to Mark Dickinson and others on irc and on the issue for
helping in formulating this.


From solipsis at pitrou.net  Thu Dec  3 12:33:34 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 3 Dec 2009 11:33:34 +0000 (UTC)
Subject: [Python-Dev] Unicode locale values in 2.7
References: <4B179EC2.9040705@trueblade.com>
Message-ID: <loom.20091203T122844-242@post.gmane.org>

Eric Smith <eric <at> trueblade.com> writes:
> 
> But in trunk, the value is just used as-is. So when formating a decimal,
> for example, '\xc2\xa0' is just inserted into the result, such as:
> >>> format(Decimal('1000'), 'n')
> '1\xc2\xa0000'
> This doesn't make much sense,

Why doesn't it make sense? It's normal UTF-8.
The same thing happens when the monetary sign is non-ASCII, see
Lib/test/test_locale.py for an example.

> I believe that the correct solution is to do what py3k does in locale,
> which is to convert the struct lconv values to unicode. But since this
> would be a disruptive change if universally applied, I'd like to propose
> that we only convert to unicode if the values won't fit into a str.

This would still be disruptive, because some programs may rely on these values
being bytestrings in the current locale encoding.

I'd say don't try to fix this, and encourage people to use py3k if they really
want safe unicode+locale. Proper unicode behaviour is one of py3k's main
features after all.

Regards

Antoine.



From dickinsm at gmail.com  Thu Dec  3 12:55:11 2009
From: dickinsm at gmail.com (Mark Dickinson)
Date: Thu, 3 Dec 2009 11:55:11 +0000
Subject: [Python-Dev] Unicode locale values in 2.7
In-Reply-To: <loom.20091203T122844-242@post.gmane.org>
References: <4B179EC2.9040705@trueblade.com>
	<loom.20091203T122844-242@post.gmane.org>
Message-ID: <5c6f2a5d0912030355g51dacfbfjf94e44fdd446217e@mail.gmail.com>

On Thu, Dec 3, 2009 at 11:33 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Eric Smith <eric <at> trueblade.com> writes:
>>
>> But in trunk, the value is just used as-is. So when formating a decimal,
>> for example, '\xc2\xa0' is just inserted into the result, such as:
>> >>> format(Decimal('1000'), 'n')
>> '1\xc2\xa0000'
>> This doesn't make much sense,
>
> Why doesn't it make sense? It's normal UTF-8.
> The same thing happens when the monetary sign is non-ASCII, see
> Lib/test/test_locale.py for an example.

Well, one problem is that it messes up character counts.  Suppose
you're aware that the thousands separator might be a single multibyte
character, and you want to produce a unicode result that's zero-padded
to a width of 6.  There's currently no sensible way of doing this that
I can see:

format(Decimal('1000'), '06n').decode('utf-8') gives a string of length 5

format(Decimal('1000'), u'06n') fails with a UnicodeDecodeError.

Mark

From solipsis at pitrou.net  Thu Dec  3 13:04:00 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 03 Dec 2009 13:04:00 +0100
Subject: [Python-Dev] Unicode locale values in 2.7
In-Reply-To: <5c6f2a5d0912030355g51dacfbfjf94e44fdd446217e@mail.gmail.com>
References: <4B179EC2.9040705@trueblade.com>
	<loom.20091203T122844-242@post.gmane.org>
	<5c6f2a5d0912030355g51dacfbfjf94e44fdd446217e@mail.gmail.com>
Message-ID: <1259841840.3349.5.camel@localhost>


> Well, one problem is that it messes up character counts.

Well, I know it does. That's why py3k is inherently better than 2.x's
bytestrings-by-default behaviour. There's a reason we don't try to
backport py3k's unicode goodness to 2.x, and that's it would be terribly
messy to do so while retaining some measure of backwards compatibility.

(By the way, I would mention that relying on locale to get number
formatting right regardless of the actual user is optimistic, borderline
foolish ;-))

cheers

Antoine.



From martin at v.loewis.de  Thu Dec  3 14:49:13 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 03 Dec 2009 14:49:13 +0100
Subject: [Python-Dev] Unicode locale values in 2.7
In-Reply-To: <4B179EC2.9040705@trueblade.com>
References: <4B179EC2.9040705@trueblade.com>
Message-ID: <4B17C1D9.9020206@v.loewis.de>

> But in trunk, the value is just used as-is. So when formating a decimal,
> for example, '\xc2\xa0' is just inserted into the result, such as:
>>>> format(Decimal('1000'), 'n')
> '1\xc2\xa0000'
> This doesn't make much sense

I agree with Antoine: it makes sense, and is the correct answer, given
the locale definition.

Now, I think that the locale definition is flawed - it's *not* a
property of the Czech language or culture that the "no-break space"
character is the thousands-separator. If anything other than the regular
space should be the thousands separator, it should be "thin space", and
it should be used in all locales on a system that currently use space.
Having it just in the Czech locale is a misconfiguration, IMO.

But if we accept the system's locale definition, then the above is
certainly the right answer.

> and causes an error when converting it to
> unicode:
>>>> format(Decimal('1000'), u'n')

You'll need to decode in the locale's encoding, then it would
work. Unfortunately, that is difficult to achieve.

> I believe that the correct solution is to do what py3k does in locale,
> which is to convert the struct lconv values to unicode. But since this
> would be a disruptive change if universally applied, I'd like to propose
> that we only convert to unicode if the values won't fit into a str.

I think Guido is on record for objecting to that kind of API strongly.

> So the algorithm would be something like:
> 1. call mbstowcs
> 2. if every value in the result is in the range [32, 126], return a str
> 3. otherwise, return a unicode

Not sure what API you are describing here - the algorithm for doing
what?

> This would mean that for most locales, the current behavior in trunk
> wouldn't change: the locale.localeconv() values would continue to be
> str. Only for those locales where the values wouldn't fit into a str
> would unicode be returned.
> 
> Does this seem like an acceptable change?

Definitely not. This will be just for 2.7, and I see no point in
producing such an incompatibility. Applications may already perform
the conversion themselves, and that would break under such a change.

Regards,
Martin


From cesare.di.mauro at gmail.com  Thu Dec  3 21:03:33 2009
From: cesare.di.mauro at gmail.com (Cesare Di Mauro)
Date: Thu, 3 Dec 2009 21:03:33 +0100
Subject: [Python-Dev] wpython is back
In-Reply-To: <4B0FDDB3.9010605@cheimes.de>
References: <c184dbd10911261350v1e776c9r4a58b403288f9367@mail.gmail.com>
	<hen3l6$sgn$1@ger.gmane.org>
	<ca471dc20911261555q7798631u923b038411ed6456@mail.gmail.com>
	<c184dbd10911262201y285e35e0j34573251410a4a97@mail.gmail.com>
	<4B0FDDB3.9010605@cheimes.de>
Message-ID: <c184dbd10912031203u3f507988ta33952a36880687e@mail.gmail.com>

2009/11/27 Christian Heimes <lists at cheimes.de>

> Cesare Di Mauro wrote:
> >
> > You'll find some at page 28
> > here<
> http://wpython.googlecode.com/files/Beyond%20Bytecode%20-%20A%20Wordcode-based%20Python.pdf
> >
> > ..
> >
> > Mart made more interesting
> > ones<http://www.mail-archive.com/python-dev at python.org/msg43282.html
> >with
> > Unladen benchmarks.
>
> The PDF document sounded interesting and I was tempted to test WPython.
> Unfortunately it doesn't compile on my box:
>
> $ make
> gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
> -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o
> Python/ast.o Python/ast.c
>
>
> Python/ast.c:30: warning: ?enum _expr_const? declared inside parameter
> list
> Python/ast.c:30: warning: its scope is only this definition or
> declaration, which is probably not what you want
>
> Python/ast.c:335: warning: ?enum _expr_const? declared inside parameter
> list
> Python/ast.c:335: error: parameter 2 (?constant?) has incomplete type
>
> Python/ast.c: In function ?Const?:
>
> Python/ast.c:341: error: ?Const_kind? undeclared (first use in this
> function)
>
> Python/ast.c:341: error: (Each undeclared identifier is reported only
> once
> Python/ast.c:341: error: for each function it appears in.)
>
> Python/ast.c:342: error: ?union <anonymous>? has no member named ?Const?
>
> Python/ast.c:343: error: ?union <anonymous>? has no member named ?Const?
>
> Python/ast.c: In function ?set_context?:
>
> Python/ast.c:457: error: ?Const_kind? undeclared (first use in this
> function)
>
> Python/ast.c: At top level:
>
> Python/ast.c:591: warning: ?enum _expr_const? declared inside parameter
> list
> Python/ast.c:590: error: conflicting types for ?seq_for_testlist?
>
> Python/ast.c:29: note: previous declaration of ?seq_for_testlist? was here
> [...]
>
> $ gcc --version
> gcc (Ubuntu 4.4.1-4ubuntu8) 4.4.1
> $ uname -a
> Linux hamiller 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC
> 2009 x86_64 GNU/Linux
>
>
I have created a new project at Google Code:
http://code.google.com/p/wpython2/ using Mercurial for the repository.

The master (Python 2.6.4) code is located into the default repository:
https://wpython2.googlecode.com/hg/

The wpython (version 1.0) clone is in:
https://wpython10.wpython2.googlecode.com/hg/

Sources are available in:
http://code.google.com/p/wpython2/downloads/list

wpython 1.0 is an almost complete replacement for Python 2.6.4 (except for
Doc/library.dis.rst, which I'll update later, when I stop adding or changing
opcodes).

I have changed the ASDL grammar (in Parser/Python.asdl) so that there's no
need to overwrite Include/Python-ast.h, and I've added full support for
constants to the AST code (I left Num_kind and Str_kind untouched right now,
but I plan to remove them in the next release, since Const_kind is able to
hold any kind of constant object).

Now you shouldn't have problems compiling it.

Cesare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091203/eb86f8bd/attachment-0001.htm>

From ben+python at benfinney.id.au  Fri Dec  4 04:49:44 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 04 Dec 2009 14:49:44 +1100
Subject: [Python-Dev] Troubled by changes to PyPI usage agreement
Message-ID: <87ocmfjt47.fsf@benfinney.id.au>

Howdy all,

In the Subversion repository for PyPI, this revision appeared:

=====
$ bzr info .
Repository checkout (format: 2a)
Location:
  repository checkout root: .
        checkout of branch: https://svn.python.org/packages/trunk/pypi
         shared repository: /home/bignose/Projects/python/pypi

$ bzr log --revision 655
------------------------------------------------------------
revno: 655
svn revno: 690 (on /trunk/pypi)
committer: martin.von.loewis
timestamp: Sun 2009-11-29 17:15:12 +0000
message:
  Update usage agreement according to Van Lindberg's instructions.
=====

The revision modifies various files for the web interface, changing the
wording of an agreement and requiring an ?I agree? checkbox to be
checked.

=====
$ bzr diff --change 655 | diffstat
 templates/openid_return.pt |   28 +++++++++++++++++++---------
 templates/register.pt      |   32 +++++++++++++++++++++++---------
 webui.py                   |    6 ++++++
 3 files changed, 48 insertions(+), 18 deletions(-)
=====

The new wording is one that I can't agree to:

=====
[?]
+             <li>Content is restricted to Python packages and related information only.</li>
+             <li>Any content uploaded to PyPI is provided on a non-confidential basis.</li>
+             <li>The PSF is free to use or disseminate any content that I upload on an 
+               unrestricted basis for any purpose. In particular, the PSF and all other 
+               users of the web site are granted an irrevocable, worldwide, royalty-free, 
+               nonexclusive license to reproduce, distribute, transmit, display, perform, 
+               and publish the content, including in digital form.</li>
+             <li>I represent and warrant that I have complied with all government 
+               regulations [?]
=====

The content that I submit to PyPI is licensed under specific license
terms. That certainly does *not* allow the PSF to ?use or disseminate
any content that I upload on an unrestricted basis for any purpose?,
etc.; it allows only those acts permitted by the license terms granted
in the work.

I have already registered an account at PyPI, and never agreed to this
wording. (The previous wording was much less broad and unobjectionable.)
I would not have noticed it changing if I had not been investigating the
PyPI website source code.

Will the PSF claim I am bound by it anyway? What about future changes?

Why was this wording chosen? How does the PSF propose to reconcile this
with copyright holders's chosen license terms for their work?

-- 
 \       ?Timid men prefer the calm of despotism to the boisterous sea |
  `\                                    of liberty.? ?Thomas Jefferson |
_o__)                                                                  |
Ben Finney


From benjamin at python.org  Fri Dec  4 05:12:31 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Thu, 3 Dec 2009 22:12:31 -0600
Subject: [Python-Dev] Troubled by changes to PyPI usage agreement
In-Reply-To: <87ocmfjt47.fsf@benfinney.id.au>
References: <87ocmfjt47.fsf@benfinney.id.au>
Message-ID: <1afaf6160912032012k4416e542ue27e3945df5f4dcd@mail.gmail.com>

2009/12/3 Ben Finney <ben+python at benfinney.id.au>:
> Howdy all,

Hi Ben,
Could I ask why you cced this to python-dev, too? I thought the last
string of pypi related emails, we agreed the correct place for this
was the catalog-sig.



-- 
Regards,
Benjamin

From ben+python at benfinney.id.au  Fri Dec  4 05:22:58 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 4 Dec 2009 15:22:58 +1100
Subject: [Python-Dev] Troubled by changes to PyPI usage agreement
In-Reply-To: <1afaf6160912032012k4416e542ue27e3945df5f4dcd@mail.gmail.com>
References: <87ocmfjt47.fsf@benfinney.id.au>
	<1afaf6160912032012k4416e542ue27e3945df5f4dcd@mail.gmail.com>
Message-ID: <20091204042258.GW23922@benfinney.id.au>

On 03-Dec-2009, Benjamin Peterson wrote:
> Hi Ben,
> Could I ask why you cced this to python-dev, too? I thought the last
> string of pypi related emails, we agreed the correct place for this
> was the catalog-sig.

I did consider that. But it seems this change is being asserted by the
PSF. At the least, it seems to need clarification by Python insiders
who may not be reading the ?catalog-sig? forum.

Sorry for not making the reason for the cross-post clearer.

-- 
 \          ?I moved into an all-electric house. I forgot and left the |
  `\   porch light on all day. When I got home the front door wouldn't |
_o__)                                            open.? ?Steven Wright |
Ben Finney <ben at benfinney.id.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091204/06000eb8/attachment.pgp>

From martin at v.loewis.de  Fri Dec  4 10:12:39 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Fri, 04 Dec 2009 10:12:39 +0100
Subject: [Python-Dev] Troubled by changes to PyPI usage agreement
In-Reply-To: <20091204042258.GW23922@benfinney.id.au>
References: <87ocmfjt47.fsf@benfinney.id.au>	<1afaf6160912032012k4416e542ue27e3945df5f4dcd@mail.gmail.com>
	<20091204042258.GW23922@benfinney.id.au>
Message-ID: <4B18D287.6070003@v.loewis.de>

Ben Finney wrote:
> On 03-Dec-2009, Benjamin Peterson wrote:
>> Hi Ben,
>> Could I ask why you cced this to python-dev, too? I thought the last
>> string of pypi related emails, we agreed the correct place for this
>> was the catalog-sig.
> 
> I did consider that. But it seems this change is being asserted by the
> PSF. At the least, it seems to need clarification by Python insiders
> who may not be reading the ?catalog-sig? forum.
> 
> Sorry for not making the reason for the cross-post clearer.

Well, python-dev and the PSF have not much to do with each other,
either. You can reach the PSF at psf at python.org.

Regards,
Martin

From ben+python at benfinney.id.au  Fri Dec  4 10:37:06 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 04 Dec 2009 20:37:06 +1100
Subject: [Python-Dev] Troubled by changes to PyPI usage agreement
References: <87ocmfjt47.fsf@benfinney.id.au>
	<1afaf6160912032012k4416e542ue27e3945df5f4dcd@mail.gmail.com>
	<20091204042258.GW23922@benfinney.id.au>
	<4B18D287.6070003@v.loewis.de>
Message-ID: <873a3rjd19.fsf@benfinney.id.au>

"Martin v. L?wis" <martin at v.loewis.de> writes:

> Well, python-dev and the PSF have not much to do with each other,
> either. You can reach the PSF at psf at python.org.

Okay, thanks.

Folks, I consider this thread on ?python-dev? done. I'll start again
with a new thread crossing between the PSF at the address Martin gives,
and ?catalog-sig?; if you're interested, please join that thread and let
this one end.

-- 
 \      ?Reichel's Law: A body on vacation tends to remain on vacation |
  `\            unless acted upon by an outside force.? ?Carol Reichel |
_o__)                                                                  |
Ben Finney


From status at bugs.python.org  Fri Dec  4 18:07:29 2009
From: status at bugs.python.org (Python tracker)
Date: Fri,  4 Dec 2009 18:07:29 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20091204170729.C903478668@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (11/27/09 - 12/04/09)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 2501 open (+17) / 16755 closed (+14) / 19256 total (+31)

Open issues with patches:   998

Average duration of open issues: 695 days.
Median duration of open issues: 451 days.

Open Issues Breakdown
   open  2466 (+17)
pending    34 ( +0)

Issues Created Or Reopened (31)
_______________________________

optparse Documentation References Example Files that do not Exis 11/28/09
       http://bugs.python.org/issue7404    created  MarkRoddy                     
       patch                                                                   

compiling python 3.1.1 using cygwin 1.7.0 and gcc 4.3.4          11/28/09
       http://bugs.python.org/issue7405    created  lopgok                        
                                                                               

int arithmetic relies on C signed overflow behaviour             11/29/09
       http://bugs.python.org/issue7406    created  mark.dickinson                
                                                                               

Minor Queue doc improvement                                      11/29/09
       http://bugs.python.org/issue7407    created  flub                          
       patch                                                                   

test_distutils fails on Mac OS X 10.5                            11/29/09
CLOSED http://bugs.python.org/issue7408    created  titus                         
                                                                               

cleanup now deepcopy copies instance methods                     11/29/09
CLOSED http://bugs.python.org/issue7409    created  rbcollins                     
       patch                                                                   

deepcopy of itertools.count resets the count                     11/30/09
CLOSED http://bugs.python.org/issue7410    created  rbcollins                     
                                                                               

allow import from file having name containing hyphen or blank    11/30/09
CLOSED http://bugs.python.org/issue7411    created  pfeldman at verizon.net          
                                                                               

distutils install race condition                                 11/30/09
       http://bugs.python.org/issue7412    created  illume                        
                                                                               

datetime.datetime.isoformat truncation problem                   12/01/09
       http://bugs.python.org/issue7413    created  exarkun                       
       patch, needs review                                                     

Format code "C" is missing from skipitem() in getargs.c          12/01/09
CLOSED http://bugs.python.org/issue7414    created  casevh                        
       patch                                                                   

PyUnicode_FromEncodedObject() uses PyObject_AsCharBuffer()       12/01/09
       http://bugs.python.org/issue7415    created  scoder                        
                                                                               

select module compile errors breaks OS X multi-architecture buil 12/01/09
CLOSED http://bugs.python.org/issue7416    created  ned.deily                     
                                                                               

open builtin has no signature in docstring                       12/01/09
       http://bugs.python.org/issue7417    created  englabenny                    
       patch                                                                   

hashlib : the names of the different hash algorithms             12/01/09
       http://bugs.python.org/issue7418    created  chaica_                       
       patch                                                                   

Crash in _locale.setlocale on windows                            12/01/09
CLOSED http://bugs.python.org/issue7419    created  amaury.forgeotdarc            
                                                                               

turtle - turtle.update() doesn't override turtle.tracer()        12/01/09
CLOSED http://bugs.python.org/issue7420    created  dragon                        
                                                                               

Given                                                            12/01/09
CLOSED http://bugs.python.org/issue7421    created  Fallen                        
                                                                               

Document inspect.get(full)argspec limitation to Python function  12/01/09
       http://bugs.python.org/issue7422    created  tjreedy                       
                                                                               

nested generator expression produces strange results             12/02/09
CLOSED http://bugs.python.org/issue7423    created  bogklug                       
                                                                               

segmentation fault in listextend during install                  12/02/09
       http://bugs.python.org/issue7424    created  jon.buller                    
                                                                               

[PATCH] Improve the robustness of "pydoc -k" in the face of brok 12/02/09
       http://bugs.python.org/issue7425    created  dmalcolm                      
       patch                                                                   

StringIO and with statement                                      12/03/09
       http://bugs.python.org/issue7426    created  jmfauth                       
                                                                               

BadStatusLine is hell to debug                                   12/03/09
       http://bugs.python.org/issue7427    created  djc                           
                                                                               

Possible memory issue with optparse                              12/03/09
CLOSED http://bugs.python.org/issue7428    created  wfspotz                       
                                                                               

PrettyPrinter cannot print dicts with unsortable keys            12/03/09
CLOSED http://bugs.python.org/issue7429    created  maranos                       
                                                                               

"cmp" still sends messages                                       12/03/09
CLOSED http://bugs.python.org/issue7430    created  LambertDW                     
                                                                               

UnboundLocalError during test.test_linecache.LineCacheTests      12/03/09
CLOSED http://bugs.python.org/issue7431    created  ivank                         
       patch                                                                   

Py3k doc: "from __future__ import division" not necessary        12/03/09
       http://bugs.python.org/issue7432    created  jaredgrubb                    
                                                                               

MemoryView memory_getbuf causes segfaults, double call to tp_rel 12/03/09
       http://bugs.python.org/issue7433    created  pv                            
                                                                               

pprint doesn't know how to print a namedtuple                    12/04/09
       http://bugs.python.org/issue7434    created  afoglia                       
                                                                               



Issues Now Closed (40)
______________________

deepcopy doesn't copy instance methods                            731 days
       http://bugs.python.org/issue1515    pitrou                        
       patch                                                                   

Automatically disable pymalloc when running under valgrind        624 days
       http://bugs.python.org/issue2422    benjamin.peterson             
       patch                                                                   

Mac build_install.py script fetches unavailable SQLite version    623 days
       http://bugs.python.org/issue2441    ghaering                      
       patch                                                                   

Make '%F' and float.__format__('F') convert results to upper cas  500 days
       http://bugs.python.org/issue3382    eric.smith                    
       patch, easy                                                             

PyObject_GetAttr() to get special methods                         486 days
       http://bugs.python.org/issue3471    benjamin.peterson             
                                                                               

faster long multiplication                                        431 days
       http://bugs.python.org/issue3944    mark.dickinson                
       patch                                                                   

Popen(..., cwd=...) does not set PWD environment variable         421 days
       http://bugs.python.org/issue4057    r.david.murray                
                                                                               

Do not embed manifest files in *.pyd when compiling with	MSVC     415 days
       http://bugs.python.org/issue4120    loewis                        
       patch                                                                   

10e667.__format__('+') should return 'inf'                        366 days
       http://bugs.python.org/issue4482    eric.smith                    
       patch                                                                   

Exception traceback is incorrect for strange exception handling   361 days
       http://bugs.python.org/issue4486    pitrou                        
       patch, needs review                                                     

Objects/bytesobject.c should include stringdefs.h, instead of de  230 days
       http://bugs.python.org/issue5748    eric.smith                    
       easy                                                                    

Unicode issue with tempfile on Windows                            193 days
       http://bugs.python.org/issue6077    amaury.forgeotdarc            
       patch, needs review                                                     

test_posix getcwd test leaves tmp  dir                             70 days
       http://bugs.python.org/issue6974    r.david.murray                
                                                                               

range() fails with long integers                                   70 days
       http://bugs.python.org/issue6985    mark.dickinson                
                                                                               

decimal.py: use DivisionImpossible and DivisionUndefined           58 days
       http://bugs.python.org/issue7046    rhettinger                    
                                                                               

decimal.py: logb: round the result if it is greater than prec      62 days
       http://bugs.python.org/issue7048    mark.dickinson                
       patch                                                                   

urllib2.urlopen() timeout argument ignored after redirect          48 days
       http://bugs.python.org/issue7118    orsenthil                     
                                                                               

Unclear warning for subprocess.call                                43 days
       http://bugs.python.org/issue7177    pjenvey                       
                                                                               

select module - kevent ident field 64 bit issue                    36 days
       http://bugs.python.org/issue7211    ned.deily                     
       patch                                                                   

test_multiprocessing fails consistently with 'signal 12' on Free   22 days
       http://bugs.python.org/issue7272    db3l                          
       patch, buildbot                                                         

format: minimum width: UTF-8 separators and decimal points         19 days
       http://bugs.python.org/issue7327    eric.smith                    
                                                                               

Add initgroups to the posix/os modules                             16 days
       http://bugs.python.org/issue7333    pitrou                        
       patch                                                                   

os.write and os.close on pipe from separate threads hangs on Mac    5 days
       http://bugs.python.org/issue7401    ronaldoussoren                
                                                                               

Race condition in logging._acquireLock()?                           0 days
       http://bugs.python.org/issue7403    vinay.sajip                   
                                                                               

test_distutils fails on Mac OS X 10.5                               0 days
       http://bugs.python.org/issue7408    titus                         
                                                                               

cleanup now deepcopy copies instance methods                        0 days
       http://bugs.python.org/issue7409    benjamin.peterson             
       patch                                                                   

deepcopy of itertools.count resets the count                        1 days
       http://bugs.python.org/issue7410    rhettinger                    
                                                                               

allow import from file having name containing hyphen or blank       0 days
       http://bugs.python.org/issue7411    pitrou                        
                                                                               

Format code "C" is missing from skipitem() in getargs.c             2 days
       http://bugs.python.org/issue7414    mark.dickinson                
       patch                                                                   

select module compile errors breaks OS X multi-architecture buil    0 days
       http://bugs.python.org/issue7416    ronaldoussoren                
                                                                               

Crash in _locale.setlocale on windows                               0 days
       http://bugs.python.org/issue7419    amaury.forgeotdarc            
                                                                               

turtle - turtle.update() doesn't override turtle.tracer()           0 days
       http://bugs.python.org/issue7420    r.david.murray                
                                                                               

Given                                                               0 days
       http://bugs.python.org/issue7421    eric.smith                    
                                                                               

nested generator expression produces strange results                0 days
       http://bugs.python.org/issue7423    r.david.murray                
                                                                               

Possible memory issue with optparse                                 0 days
       http://bugs.python.org/issue7428    loewis                        
                                                                               

PrettyPrinter cannot print dicts with unsortable keys               0 days
       http://bugs.python.org/issue7429    r.david.murray                
                                                                               

"cmp" still sends messages                                          1 days
       http://bugs.python.org/issue7430    mark.dickinson                
                                                                               

UnboundLocalError during test.test_linecache.LineCacheTests         0 days
       http://bugs.python.org/issue7431    r.david.murray                
       patch                                                                   

0.0 and -0.0 identified, with surprising results                   35 days
       http://bugs.python.org/issue1678380 mark.dickinson                
       patch                                                                   

chown broken on 64bit                                             882 days
       http://bugs.python.org/issue1747858 pitrou                        
       64bit                                                                   



Top Issues Most Discussed (10)
______________________________

 14 test_distutils fails on Mac OS X 10.5                              0 days
closed  http://bugs.python.org/issue7408   

 14 format: minimum width: UTF-8 separators and decimal points        19 days
closed  http://bugs.python.org/issue7327   

 10 open builtin has no signature in docstring                         3 days
open    http://bugs.python.org/issue7417   

  7 os.write and os.close on pipe from separate threads hangs on Ma    5 days
closed  http://bugs.python.org/issue7401   

  6 deepcopy doesn't copy instance methods                           731 days
closed  http://bugs.python.org/issue1515   

  5 MemoryView memory_getbuf causes segfaults, double call to tp_re    1 days
open    http://bugs.python.org/issue7433   

  5 10e667.__format__('+') should return 'inf'                       366 days
closed  http://bugs.python.org/issue4482   

  5 Popen(..., cwd=...) does not set PWD environment variable        421 days
closed  http://bugs.python.org/issue4057   

  5 Make '%F' and float.__format__('F') convert results to upper ca  500 days
closed  http://bugs.python.org/issue3382   

  4 datetime.datetime.isoformat truncation problem                     4 days
open    http://bugs.python.org/issue7413   




From tlesher at gmail.com  Fri Dec  4 23:01:48 2009
From: tlesher at gmail.com (Tim Lesher)
Date: Fri, 4 Dec 2009 17:01:48 -0500
Subject: [Python-Dev] Windows make_buildinfo changes in 2.6 and
	cross-compilation
Message-ID: <9613db600912041401s4aadfa27h30a22db9f5329ddc@mail.gmail.com>

I ran across this while trying to upgrade our company's internal Windows CE
build from 2.5.2 to either 2.6 or 3.1.

In the 2.5 era, the Windows version of make_buildinfo used to fall back to
just copying the getbuildinfo.c file from \Modules if subwcrev failed; since
2.6, make_buildinfo fails the build if the compilation of getbuildinfo.c
fails when make_buildinfo is run, without falling back to copying.

Any reason not to keep the fallback strategy in the process?

The new process fails in cross-compilation scenarios (like building for
Windows CE on a Windows host) because, while the VC++ solution can be told
to build native (win32) binaries for make_buildinfo and make_versioninfo,
when make_buildinfo tries to compile via its hardcoded call to cl.exe, it
tries to use the cross-compiler without the required flags from the
cross-compilation configs in the vcproj files.

Thanks!

-- 
Tim Lesher <tlesher at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091204/4ee6b969/attachment.htm>

From brett at python.org  Sat Dec  5 01:54:18 2009
From: brett at python.org (Brett Cannon)
Date: Fri, 4 Dec 2009 16:54:18 -0800
Subject: [Python-Dev] who wants to be sprint coach @ PyCon 2010?
Message-ID: <bbaeab100912041654t890b10bwe23d1ca650cd5a36@mail.gmail.com>

I can't afford to attend PyCon beyond the language summit and the conference
itself this year (down to about my last year of my PhD and need every last
dime I have left in saving to avoid school debt), so for the first time
since PyCon started back in 2003, I have to miss out on attending the
sprints.

That means my traditional role as sprint coach for the core is up for grabs
for someone else to take on. Since early-bird registration is open for about
a month (ends Jan 6) I wanted to get this email out now instead of wait in
case it influences someone's plan to attend the sprints.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091204/52efaed2/attachment-0001.htm>

From solipsis at pitrou.net  Sat Dec  5 02:20:04 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 5 Dec 2009 01:20:04 +0000 (UTC)
Subject: [Python-Dev] Rules for the Tools directory
Message-ID: <hfccg4$4sv$1@ger.gmane.org>

Hello, 

I was going to suggest adding ccbench and iobench to the Tools directory, 
so I wonder whether there are any rules for putting stuff there?

Thank you

Antoine.


From brett at python.org  Sat Dec  5 05:31:09 2009
From: brett at python.org (Brett Cannon)
Date: Fri, 4 Dec 2009 20:31:09 -0800
Subject: [Python-Dev] Rules for the Tools directory
In-Reply-To: <hfccg4$4sv$1@ger.gmane.org>
References: <hfccg4$4sv$1@ger.gmane.org>
Message-ID: <bbaeab100912042031u58bc9172m43c4493e893350e4@mail.gmail.com>

On Fri, Dec 4, 2009 at 17:20, Antoine Pitrou <solipsis at pitrou.net> wrote:

> Hello,
>
> I was going to suggest adding ccbench and iobench to the Tools directory,
> so I wonder whether there are any rules for putting stuff there?
>
>
Much like the Demos directory, there are no rules.

-Brett



> Thank you
>
> 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: <http://mail.python.org/pipermail/python-dev/attachments/20091204/ea4cb9ac/attachment.htm>

From ncoghlan at gmail.com  Sat Dec  5 09:49:13 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 05 Dec 2009 18:49:13 +1000
Subject: [Python-Dev] Rules for the Tools directory
In-Reply-To: <bbaeab100912042031u58bc9172m43c4493e893350e4@mail.gmail.com>
References: <hfccg4$4sv$1@ger.gmane.org>
	<bbaeab100912042031u58bc9172m43c4493e893350e4@mail.gmail.com>
Message-ID: <4B1A1E89.6040305@gmail.com>

Brett Cannon wrote:
> 
> 
> On Fri, Dec 4, 2009 at 17:20, Antoine Pitrou <solipsis at pitrou.net
> <mailto:solipsis at pitrou.net>> wrote:
> 
>     Hello,
> 
>     I was going to suggest adding ccbench and iobench to the Tools
>     directory,
>     so I wonder whether there are any rules for putting stuff there?
> 
> 
> Much like the Demos directory, there are no rules.

I wouldn't go quite that far - while those directories aren't controlled
in the same way as the interpreter and the standard library, there's
still the fact that this is code that the PSF will end up redistributing.

That means the basic rules for any checkin still apply:
- PSF must have the necessary legal rights to redistribute the code
(usually via a Contributor Agreement)
- code should be of good quality

At least checking for objections on python-dev first is probably a good
idea as well (in this case, I think both ccbench and iobench make good
additions).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From stefan-usenet at bytereef.org  Sat Dec  5 12:18:47 2009
From: stefan-usenet at bytereef.org (Stefan Krah)
Date: Sat, 5 Dec 2009 12:18:47 +0100
Subject: [Python-Dev] Sort out formatting differences in decimal and float
Message-ID: <20091205111847.GA251@mail.bytereef.org>

Hi,

I'm in the process of implementing formatting in my C-decimal module.
Since testing is quite time consuming, I would appreciate a binding
decision on how the following should be formatted:

>>> from decimal import *
>>> format(float(1234), '020,g')
'0,000,000,000,001,234'
>>> format(float(1234), '0=20,g')
'0,000,000,000,001,234'
>>> 
>>> format(Decimal(1234), '020,g')
'0,000,000,000,001,234'
>>> format(Decimal(1234), '0=20,g')
'0000000000000001,234'

>>> format(Decimal('nan'), '020,g')
'                 NaN'
>>> format(Decimal('nan'), '0=20,g')
'00000000000000000NaN'


You can see that float literally follows PEP-3101:

"If the width field is preceded by a zero ('0') character, this enables
 zero-padding.  This is equivalent to an alignment type of '=' and a
 fill character of '0'."


The advantage of decimal is that the user has the option to suppress
commas. The behaviour of float is slightly easier to implement in C.


So the options are:

   a) 020 is always equivalent to 0=20

   b) 020 is not always equivalent to 0=20



Stefan Krah



From dickinsm at gmail.com  Sat Dec  5 13:23:26 2009
From: dickinsm at gmail.com (Mark Dickinson)
Date: Sat, 5 Dec 2009 12:23:26 +0000
Subject: [Python-Dev] Sort out formatting differences in decimal and
	float
In-Reply-To: <20091205111847.GA251@mail.bytereef.org>
References: <20091205111847.GA251@mail.bytereef.org>
Message-ID: <5c6f2a5d0912050423n15238876hb6e4df943e8adeb@mail.gmail.com>

On Sat, Dec 5, 2009 at 11:18 AM, Stefan Krah <stefan-usenet at bytereef.org> wrote:
> Hi,
>
> I'm in the process of implementing formatting in my C-decimal module.
> Since testing is quite time consuming, I would appreciate a binding
> decision on how the following should be formatted:
>
>>>> from decimal import *
>>>> format(float(1234), '020,g')
> '0,000,000,000,001,234'
>>>> format(float(1234), '0=20,g')
> '0,000,000,000,001,234'
>>>>
>>>> format(Decimal(1234), '020,g')
> '0,000,000,000,001,234'
>>>> format(Decimal(1234), '0=20,g')
> '0000000000000001,234'

I like the Decimal behaviour better, but then I might be a little biased.  :-)

I find it odd that, for float formatting, the choice of fill character
affects whether commas are inserted:

Python 3.2a0 (py3k:76671, Dec  4 2009, 18:55:54)
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> format(float(1234), '0=20,g')
'0,000,000,000,001,234'
>>> format(float(1234), '1=20,g')
'1111111111111111,234'
>>> format(float(1234), 'X=20,g')
'XXXXXXXXXXXXXXX1,234'

Mark

From skip at pobox.com  Sat Dec  5 14:18:37 2009
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 5 Dec 2009 07:18:37 -0600
Subject: [Python-Dev] Sort out formatting differences in decimal and
 float
In-Reply-To: <20091205111847.GA251@mail.bytereef.org>
References: <20091205111847.GA251@mail.bytereef.org>
Message-ID: <19226.23981.479396.165048@montanaro.dyndns.org>


Sorry for being a curmudgeon, however...

    >>> format(Decimal(1234), '020,g')
    '0,000,000,000,001,234'
    >>> format(Decimal(1234), '0=20,g')
    '0000000000000001,234'

Why in the world would you ever want to insert commas as separators and not
use them consistently?

    >>> format(Decimal('nan'), '020,g')
    '                 NaN'
    >>> format(Decimal('nan'), '0=20,g')
    '00000000000000000NaN'

Why in the world would you ever want to zero pad Nan (or Inf, for that matter)?

    Stefan> The advantage of decimal is that the user has the option to
    Stefan> suppress commas. The behaviour of float is slightly easier to
    Stefan> implement in C.

Why?  If the user asked for them why would you want to suppress (some of)
them?

Skip

From fetchinson at googlemail.com  Sat Dec  5 15:00:34 2009
From: fetchinson at googlemail.com (Daniel Fetchinson)
Date: Sat, 5 Dec 2009 15:00:34 +0100
Subject: [Python-Dev] Sort out formatting differences in decimal and
	float
In-Reply-To: <19226.23981.479396.165048@montanaro.dyndns.org>
References: <20091205111847.GA251@mail.bytereef.org>
	<19226.23981.479396.165048@montanaro.dyndns.org>
Message-ID: <fbe2e2100912050600w35130409y7e03fb9304a5f39f@mail.gmail.com>

> Sorry for being a curmudgeon, however...
>
>     >>> format(Decimal(1234), '020,g')
>     '0,000,000,000,001,234'
>     >>> format(Decimal(1234), '0=20,g')
>     '0000000000000001,234'
>
> Why in the world would you ever want to insert commas as separators and not
> use them consistently?
>
>     >>> format(Decimal('nan'), '020,g')
>     '                 NaN'
>     >>> format(Decimal('nan'), '0=20,g')
>     '00000000000000000NaN'
>
> Why in the world would you ever want to zero pad Nan (or Inf, for that
> matter)?

Because you didn't know in advance that the number ending up in your
format call was a nan (or inf)?

Cheers,
Daniel

>     Stefan> The advantage of decimal is that the user has the option to
>     Stefan> suppress commas. The behaviour of float is slightly easier to
>     Stefan> implement in C.
>
> Why?  If the user asked for them why would you want to suppress (some of)
> them?



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

From dickinsm at gmail.com  Sat Dec  5 15:13:19 2009
From: dickinsm at gmail.com (Mark Dickinson)
Date: Sat, 5 Dec 2009 14:13:19 +0000
Subject: [Python-Dev] Sort out formatting differences in decimal and
	float
In-Reply-To: <19226.23981.479396.165048@montanaro.dyndns.org>
References: <20091205111847.GA251@mail.bytereef.org>
	<19226.23981.479396.165048@montanaro.dyndns.org>
Message-ID: <5c6f2a5d0912050613g31812391r75ee723e3802011b@mail.gmail.com>

On Sat, Dec 5, 2009 at 1:18 PM,  <skip at pobox.com> wrote:
>
> ? ?>>> format(Decimal(1234), '020,g')
> ? ?'0,000,000,000,001,234'
> ? ?>>> format(Decimal(1234), '0=20,g')
> ? ?'0000000000000001,234'
>
> Why in the world would you ever want to insert commas as separators and not
> use them consistently?

So should commas be inserted for any fill character at all?  Or should
only '0' be special-cased?  What about other digits used as fill characters?
What about other non-ascii zeros?  Should those be special-cased too?

I'm reluctant to add extra special cases and complication to what's
already quite a complicated specification;  it seems better to keep
it simple (well, as simple as possible) and orthogonal.

There's already a good way to ask for zero padding, by using the leading
zero, as in '020,g'.  Why would you use '0=20,g' instead?  I'm not sure
that the 'X=...' notation was intended to be used for zero padding.

Mark

From eric at trueblade.com  Sat Dec  5 15:20:26 2009
From: eric at trueblade.com (Eric Smith)
Date: Sat, 05 Dec 2009 09:20:26 -0500
Subject: [Python-Dev] Sort out formatting differences in decimal
	and	float
In-Reply-To: <5c6f2a5d0912050423n15238876hb6e4df943e8adeb@mail.gmail.com>
References: <20091205111847.GA251@mail.bytereef.org>
	<5c6f2a5d0912050423n15238876hb6e4df943e8adeb@mail.gmail.com>
Message-ID: <4B1A6C2A.3080601@trueblade.com>

Mark Dickinson wrote:
> I find it odd that, for float formatting, the choice of fill character
> affects whether commas are inserted:
> 
> Python 3.2a0 (py3k:76671, Dec  4 2009, 18:55:54)
> [GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> format(float(1234), '0=20,g')
> '0,000,000,000,001,234'
>>>> format(float(1234), '1=20,g')
> '1111111111111111,234'
>>>> format(float(1234), 'X=20,g')
> 'XXXXXXXXXXXXXXX1,234'

I haven't spent a lot of time looking at it, but this might be related 
to http://bugs.python.org/issue6902 .

I'll move this up in my queue.

Eric.


From skip at pobox.com  Sat Dec  5 16:17:12 2009
From: skip at pobox.com (skip at pobox.com)
Date: Sat, 5 Dec 2009 09:17:12 -0600
Subject: [Python-Dev] Sort out formatting differences in decimal and
 float
In-Reply-To: <5c6f2a5d0912050613g31812391r75ee723e3802011b@mail.gmail.com>
References: <20091205111847.GA251@mail.bytereef.org>
	<19226.23981.479396.165048@montanaro.dyndns.org>
	<5c6f2a5d0912050613g31812391r75ee723e3802011b@mail.gmail.com>
Message-ID: <19226.31096.511233.965897@montanaro.dyndns.org>


    Mark> So should commas be inserted for any fill character at all? 

While I'm at it, it makes no sense to me to pad numbers with anything other
than whitespace or zero.  (BTW: I have never liked the new format() stuff,
so I will be sticking with %-formatting as long as it exists in Python.  My
apologies if I don't understand some amazing generality about format(), but
if you do dumb stuff like ask for comma separation of a number then ask to
pad it with '*' you get what you deserve.)

    Mark> There's already a good way to ask for zero padding, by using the
    Mark> leading zero, as in '020,g'.  Why would you use '0=20,g' instead?

Note to the implementers: '0=20,g' has no mnemonic significance as far as I
can tell.  I thought it was my mail program failing to properly decode a bit
of quoted printable text.

Skip

From benjamin at python.org  Sat Dec  5 19:38:31 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Sat, 5 Dec 2009 12:38:31 -0600
Subject: [Python-Dev] [RELEASED] Python 2.7 alpha 1
Message-ID: <1afaf6160912051038r697f3f48r48109624c478d9bc@mail.gmail.com>

On behalf of the Python development team, I'm pleased to announce the first
alpha release of Python 2.7.

Python 2.7 is scheduled to be the last major version in the 2.x series.  It
includes many features that were first released in Python 3.1.  The faster io
module, the new nested with statement syntax, improved float repr, and the
memoryview object have been backported from 3.1. Other features include an
ordered dictionary implementation, unittests improvements, and support for ttk
Tile in Tkinter.  For a more extensive list of changes in 2.7, see
http://doc.python.org/dev/doc/whatsnew/2.7.html or Misc/NEWS in the Python
distribution.  Please note that this is a development release, intended as a
preview of new features for the community, and is thus not suitable for
production use.

To download Python 2.7 visit:

     http://www.python.org/download/releases/2.7/

The 2.7 documentation can be found at:

     http://docs.python.org/2.7

Please consider trying Python 2.7 with your code and reporting any bugs you may
notice to:

     http://bugs.python.org


Have fun!

--
Benjamin Peterson
Release Manager
benjamin at python.org
(on behalf of the entire python-dev team and 2.7's contributors)

From benjamin at python.org  Sat Dec  5 19:54:36 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Sat, 5 Dec 2009 12:54:36 -0600
Subject: [Python-Dev] [RELEASED] Python 2.7 alpha 1
In-Reply-To: <1afaf6160912051038r697f3f48r48109624c478d9bc@mail.gmail.com>
References: <1afaf6160912051038r697f3f48r48109624c478d9bc@mail.gmail.com>
Message-ID: <1afaf6160912051054i3abf3e4fxd17fcfc11d2fde0b@mail.gmail.com>

My apologies. The whatsnew link is actually
http://docs.python.org/dev/whatsnew/2.7.

2009/12/5 Benjamin Peterson <benjamin at python.org>:
> On behalf of the Python development team, I'm pleased to announce the first
> alpha release of Python 2.7.



-- 
Regards,
Benjamin

From scott+python-dev at scottdial.com  Sat Dec  5 19:55:13 2009
From: scott+python-dev at scottdial.com (Scott Dial)
Date: Sat, 05 Dec 2009 13:55:13 -0500
Subject: [Python-Dev] [RELEASED] Python 2.7 alpha 1
In-Reply-To: <1afaf6160912051038r697f3f48r48109624c478d9bc@mail.gmail.com>
References: <1afaf6160912051038r697f3f48r48109624c478d9bc@mail.gmail.com>
Message-ID: <4B1AAC91.3080303@scottdial.com>

Benjamin Peterson wrote:
> On behalf of the Python development team, I'm pleased to announce the first
> alpha release of Python 2.7.

Was there a call for bugs that should be reviewed for this release?

I once again will prod for attention to this show-stopping bug for using
IMAP-SSL:

http://bugs.python.org/issue5949
Title: IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs

-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu

From brett at python.org  Sat Dec  5 20:47:44 2009
From: brett at python.org (Brett Cannon)
Date: Sat, 5 Dec 2009 11:47:44 -0800
Subject: [Python-Dev] [RELEASED] Python 2.7 alpha 1
In-Reply-To: <4B1AAC91.3080303@scottdial.com>
References: <1afaf6160912051038r697f3f48r48109624c478d9bc@mail.gmail.com> 
	<4B1AAC91.3080303@scottdial.com>
Message-ID: <bbaeab100912051147i4d48fdafu6c8c66e486dc6fe2@mail.gmail.com>

On Sat, Dec 5, 2009 at 10:55, Scott Dial
<scott+python-dev at scottdial.com<scott%2Bpython-dev at scottdial.com>
> wrote:

> Benjamin Peterson wrote:
> > On behalf of the Python development team, I'm pleased to announce the
> first
> > alpha release of Python 2.7.
>
> Was there a call for bugs that should be reviewed for this release?
>
>
No. Since this is an alpha release this is more about discovering new bugs
than than trying to make sure we have everything squashed. When we approach
the first beta release is when I would start pressing on getting key bugs
fixed.

-Brett



> I once again will prod for attention to this show-stopping bug for using
> IMAP-SSL:
>
> http://bugs.python.org/issue5949
> Title: IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs
>
> --
> Scott Dial
> scott at scottdial.com
> scodial at cs.indiana.edu
> _______________________________________________
> 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: <http://mail.python.org/pipermail/python-dev/attachments/20091205/bf0cdf19/attachment.htm>

From ncoghlan at gmail.com  Sun Dec  6 00:28:29 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 06 Dec 2009 09:28:29 +1000
Subject: [Python-Dev] Sort out formatting differences in decimal and
	float
In-Reply-To: <19226.31096.511233.965897@montanaro.dyndns.org>
References: <20091205111847.GA251@mail.bytereef.org>	<19226.23981.479396.165048@montanaro.dyndns.org>	<5c6f2a5d0912050613g31812391r75ee723e3802011b@mail.gmail.com>
	<19226.31096.511233.965897@montanaro.dyndns.org>
Message-ID: <4B1AEC9D.1070408@gmail.com>

skip at pobox.com wrote:

>  My
> apologies if I don't understand some amazing generality about format()

>>> format("Header", '=^20s')
'=======Header======='

>>> "Format a single object {0!r}, multiple times in a single string.
Year: {0.year}; Month: {0.month}; Day: {0.day}; Formatted:
{0:%Y-%M-%d}".format(datetime.now())
'Format a single object datetime.datetime(2009, 12, 6, 9, 16, 0,
875018), multiple times in a single string. Year: 2009; Month: 12; Day:
6; Formatted: 2009-16-06'

>>> "Use keyword arguments easily: {x}, {y}, {z}".format(x=1, y=2, z=3)
'Use keyword arguments easily: 1, 2, 3'

For the things that mod formatting already allows you to do, our aim is
to get format() functionality at least on par with what mod formatting
supports (it should be most of the way there with the number formatting
cleanups for 2.7/3.2). For the rest of the features (explicit position
references, centre alignment, arbitrary fill characters, attribute and
subscript references, type defined formatting control), mod formatting
isn't even in the game.

Getting rid of the magic behaviour associated with the use of tuples on
the right hand side is also valuable:

>>> "%s" % (1, 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: not all arguments converted during string formatting
>>> "{}".format((1, 2))
'(1, 2)'

Developers that are already used to the limitations of mod formatting
are expected to take some time to decide if they care about the extra
features offered by the format method, but for new developers it should
be an easy choice.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From tjreedy at udel.edu  Sun Dec  6 02:35:08 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 05 Dec 2009 20:35:08 -0500
Subject: [Python-Dev] Sort out formatting differences in decimal and
	float
In-Reply-To: <4B1AEC9D.1070408@gmail.com>
References: <20091205111847.GA251@mail.bytereef.org>	<19226.23981.479396.165048@montanaro.dyndns.org>	<5c6f2a5d0912050613g31812391r75ee723e3802011b@mail.gmail.com>	<19226.31096.511233.965897@montanaro.dyndns.org>
	<4B1AEC9D.1070408@gmail.com>
Message-ID: <hff1oa$adm$1@ger.gmane.org>

Nick Coghlan wrote:
> skip at pobox.com wrote:
> 
>>  My
>> apologies if I don't understand some amazing generality about format()
> 
>>>> format("Header", '=^20s')
> '=======Header======='
> 
>>>> "Format a single object {0!r}, multiple times in a single string.
> Year: {0.year}; Month: {0.month}; Day: {0.day}; Formatted:
> {0:%Y-%M-%d}".format(datetime.now())
> 'Format a single object datetime.datetime(2009, 12, 6, 9, 16, 0,
> 875018), multiple times in a single string. Year: 2009; Month: 12; Day:
> 6; Formatted: 2009-16-06'
> 
>>>> "Use keyword arguments easily: {x}, {y}, {z}".format(x=1, y=2, z=3)
> 'Use keyword arguments easily: 1, 2, 3'
> 
> For the things that mod formatting already allows you to do, our aim is
> to get format() functionality at least on par with what mod formatting
> supports (it should be most of the way there with the number formatting
> cleanups for 2.7/3.2). For the rest of the features (explicit position
> references, centre alignment, arbitrary fill characters, attribute and
> subscript references, type defined formatting control), mod formatting
> isn't even in the game.
> 
> Getting rid of the magic behaviour associated with the use of tuples on
> the right hand side is also valuable:
> 
>>>> "%s" % (1, 2)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: not all arguments converted during string formatting
>>>> "{}".format((1, 2))
> '(1, 2)'

A nice demonstration of what an excellent piece of work the new .format 
is or is becoming. I would still like it to be a goal for 3.2 that all 
stdlib modules that work with formats accept the new formats and not 
just % formats.

Mark Summerfield only covered .format in his book on Python 3 programimg 
and I hated to tell him that there was at least one module in the stdlib 
that currently (3.1) requires the old style.

Terry Jan Reedy


From ncoghlan at gmail.com  Sun Dec  6 03:50:41 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 06 Dec 2009 12:50:41 +1000
Subject: [Python-Dev] Sort out formatting differences in decimal
	and	float
In-Reply-To: <hff1oa$adm$1@ger.gmane.org>
References: <20091205111847.GA251@mail.bytereef.org>	<19226.23981.479396.165048@montanaro.dyndns.org>	<5c6f2a5d0912050613g31812391r75ee723e3802011b@mail.gmail.com>	<19226.31096.511233.965897@montanaro.dyndns.org>	<4B1AEC9D.1070408@gmail.com>
	<hff1oa$adm$1@ger.gmane.org>
Message-ID: <4B1B1C01.2040909@gmail.com>

Terry Reedy wrote:
> A nice demonstration of what an excellent piece of work the new .format
> is or is becoming. I would still like it to be a goal for 3.2 that all
> stdlib modules that work with formats accept the new formats and not
> just % formats.
> 
> Mark Summerfield only covered .format in his book on Python 3 programimg
> and I hated to tell him that there was at least one module in the stdlib
> that currently (3.1) requires the old style.

Yes, we do need to do that. It would be nice if we could come up with a
cleaner solution than a proliferation of parallel APIs everywhere though :(

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From kristjan at ccpgames.com  Tue Dec  8 13:45:52 2009
From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=)
Date: Tue, 8 Dec 2009 12:45:52 +0000
Subject: [Python-Dev] recursive closures - reference leak
Message-ID: <930F189C8A437347B80DF2C156F7EC7F09906751C4@exchis.ccp.ad.local>

Hello there.

Consider this code:

def factorial(n):
                def helper(n):
                               if n:
                                               return n*helper(n-1)
                               else:
                                               return 1
                return helper(n)

Ok, this is a bit contrived, but there are other valid reasons for calling a closure recursively.
The problem with this is that once you have called factorial() once, you end up with a recursive cycle.  "factorial" has become a cell object, referencing the "helper" function, which again refers to the outer cell object.  This requires "gc" to clean up.  Also, it is entirely non-obvious.  the problem becomes worse if the inner function also refers to some large, temporary variable, since it will get caught up in the reference loop.

A workaround is this.  Replace the final line with:
                try:
                               return helper(n)
                finally:
                                helper = None


This clears the cell before function exit.  Note that it is not possible to "del" it, you get a syntax error for that.

Now, the reason I'm posting this here, and not to python-lang, is this:  Is there a way to implement  this differently so that this pattern doesn't result in a cycle?
Possible ideas would be:

1)      clear "helper" on function exit.  Not good if the internal function is exported, though.

2)      Use have 'helper' store a weakref to the cell object

Cheers,
Kristj?n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091208/8a2b56b2/attachment.htm>

From hrvoje.niksic at avl.com  Tue Dec  8 14:52:06 2009
From: hrvoje.niksic at avl.com (Hrvoje Niksic)
Date: Tue, 08 Dec 2009 14:52:06 +0100
Subject: [Python-Dev] recursive closures - reference leak
In-Reply-To: <930F189C8A437347B80DF2C156F7EC7F09906751C4@exchis.ccp.ad.local>
References: <930F189C8A437347B80DF2C156F7EC7F09906751C4@exchis.ccp.ad.local>
Message-ID: <4B1E5A06.5020802@avl.com>

Kristj?n Valur J?nsson wrote:
> The problem with this is that once you have called factorial() once, you 
> end up with a recursive cycle.  ?factorial? has become a cell object, 
> referencing the ?helper? function, which again refers to the outer cell 
> object.  This requires ?gc? to clean up.  Also, it is entirely 
> non-obvious.  the problem becomes worse if the inner function also 
> refers to some large, temporary variable, since it will get caught up in 
> the reference loop.

What problem are you referring to?  Python has a gc exactly to deal with 
situations like this one.  Surely you are aware that the cycle collector 
is invoked automatically without requiring user intervention.  What 
specific issue are you trying to work around?

From kristjan at ccpgames.com  Tue Dec  8 15:44:21 2009
From: kristjan at ccpgames.com (=?utf-8?B?S3Jpc3Rqw6FuIFZhbHVyIErDs25zc29u?=)
Date: Tue, 8 Dec 2009 14:44:21 +0000
Subject: [Python-Dev] recursive closures - reference leak
In-Reply-To: <4B1E5A06.5020802@avl.com>
References: <930F189C8A437347B80DF2C156F7EC7F09906751C4@exchis.ccp.ad.local>
	<4B1E5A06.5020802@avl.com>
Message-ID: <930F189C8A437347B80DF2C156F7EC7F0990675263@exchis.ccp.ad.local>



> -----Original Message-----
> From: Hrvoje Niksic [mailto:hrvoje.niksic at avl.com]
> Sent: 8. desember 2009 13:52
> To: Kristj?n Valur J?nsson
> Cc: python-dev at python.org
> Subject: Re: [Python-Dev] recursive closures - reference leak
> What problem are you referring to?  Python has a gc exactly to deal
> with
> situations like this one.  Surely you are aware that the cycle
> collector
> is invoked automatically without requiring user intervention.  What
> specific issue are you trying to work around?

Ah, yes.  In my particular case, I'm running a cluster of hundreds of nodes, supporting 50.000 players in a real-time space simulation.  We disable GC because of its unpredictable performance impact and are careful to avoid reference cycles.  We use gc from time to time to _find_ those cases that our programmers have missed, and fix them.  This is how I stumbled upon this particular reference cycle that even a high level programmer would not have expected to have created.  This is, IMHO the best use you can make of "gc":  Help you code well, not let you cope with sloppy code :)

K


From solipsis at pitrou.net  Tue Dec  8 15:55:06 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 8 Dec 2009 14:55:06 +0000 (UTC)
Subject: [Python-Dev] recursive closures - reference cycle
References: <930F189C8A437347B80DF2C156F7EC7F09906751C4@exchis.ccp.ad.local>
Message-ID: <loom.20091208T153516-777@post.gmane.org>

Kristj?n Valur J?nsson <kristjan <at> ccpgames.com> writes:
> 
> The problem with this is that once you have called
> factorial() once, you end up with a recursive cycle.

You don't need a closure to exhibit a reference cycle. A global function is 
enough:

>>> def helper(n):
...  if n:
...   return n*helper(n-1)
...  else:
...   return 1
... 
>>> helper.func_globals['helper'] is helper
True


If you really want to avoid this you can prevent the function from depending
on its outside environment:

>>> from functools import partial
>>> def helper2(rec, n):
...  if n:
...   return n*rec(rec, n-1)
...  else:
...   return 1
... 
>>> factorial = partial(helper2, helper2)
>>> "helper2" in factorial.func.func_globals
True
>>> del helper2
>>> "helper2" in factorial.func.func_globals
False
>>> factorial(3)
6


Regards

Antoine.



From fijall at gmail.com  Tue Dec  8 15:58:13 2009
From: fijall at gmail.com (Maciej Fijalkowski)
Date: Tue, 8 Dec 2009 15:58:13 +0100
Subject: [Python-Dev] recursive closures - reference leak
In-Reply-To: <930F189C8A437347B80DF2C156F7EC7F0990675263@exchis.ccp.ad.local>
References: <930F189C8A437347B80DF2C156F7EC7F09906751C4@exchis.ccp.ad.local>
	<4B1E5A06.5020802@avl.com>
	<930F189C8A437347B80DF2C156F7EC7F0990675263@exchis.ccp.ad.local>
Message-ID: <693bc9ab0912080658g24903721s5692132cdaca065@mail.gmail.com>

>
> Ah, yes. ?In my particular case, I'm running a cluster of hundreds of nodes, supporting 50.000 players in a real-time space simulation. ?We disable GC because of its unpredictable performance impact and are careful to avoid reference cycles. ?We use gc from time to time to _find_ those cases that our programmers have missed, and fix them. ?This is how I stumbled upon this particular reference cycle that even a high level programmer would not have expected to have created. ?This is, IMHO the best use you can make of "gc": ?Help you code well, not let you cope with sloppy code :)
>
> K
>

Then it is a bit your fault. There is nothing particularly wrong with
creating reference cycles (ie you can't avoid having a gc running in
Java or Jython or anything else basically). Note that disabling gc
does not mean that you will not have unpredictable pauses. Consider
for example that if you loose a reference to a very long chain of
objects, you can have arbitrarily many frees being called before
anything else can happen.

Cheers,
fijal

From daniel at stutzbachenterprises.com  Tue Dec  8 16:04:11 2009
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Tue, 8 Dec 2009 09:04:11 -0600
Subject: [Python-Dev] recursive closures - reference leak
In-Reply-To: <693bc9ab0912080658g24903721s5692132cdaca065@mail.gmail.com>
References: <930F189C8A437347B80DF2C156F7EC7F09906751C4@exchis.ccp.ad.local>
	<4B1E5A06.5020802@avl.com>
	<930F189C8A437347B80DF2C156F7EC7F0990675263@exchis.ccp.ad.local>
	<693bc9ab0912080658g24903721s5692132cdaca065@mail.gmail.com>
Message-ID: <eae285400912080704k5f25f10fx8ba31da0173495c1@mail.gmail.com>

2009/12/8 Maciej Fijalkowski <fijall at gmail.com>

> Note that disabling gc
> does not mean that you will not have unpredictable pauses. Consider
> for example that if you loose a reference to a very long chain of
> objects, you can have arbitrarily many frees being called before
> anything else can happen.
>

That strikes me as a *predictable* long pause.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091208/d3209960/attachment.htm>

From kristjan at ccpgames.com  Tue Dec  8 16:58:13 2009
From: kristjan at ccpgames.com (=?utf-8?B?S3Jpc3Rqw6FuIFZhbHVyIErDs25zc29u?=)
Date: Tue, 8 Dec 2009 15:58:13 +0000
Subject: [Python-Dev] recursive closures - reference leak
In-Reply-To: <eae285400912080704k5f25f10fx8ba31da0173495c1@mail.gmail.com>
References: <930F189C8A437347B80DF2C156F7EC7F09906751C4@exchis.ccp.ad.local>
	<4B1E5A06.5020802@avl.com>
	<930F189C8A437347B80DF2C156F7EC7F0990675263@exchis.ccp.ad.local>
	<693bc9ab0912080658g24903721s5692132cdaca065@mail.gmail.com>
	<eae285400912080704k5f25f10fx8ba31da0173495c1@mail.gmail.com>
Message-ID: <930F189C8A437347B80DF2C156F7EC7F09906752B7@exchis.ccp.ad.local>

Yes.  Just ?in-time releaseing of objects is much preferable to delayed release.
They tend to be in the cache, the individual runs of releases are smaller and have less of an individual impact.
a gc.collect() cycle visits a large amount of objects that it won?t release causing cache thrashing.
There is a reason we disabled ?gc?, and it is simply because we get lower cpu and smoother execution.
K

From: daniel.stutzbach at gmail.com [mailto:daniel.stutzbach at gmail.com] On Behalf Of Daniel Stutzbach
Sent: 8. desember 2009 15:04
To: Maciej Fijalkowski
Cc: Kristj?n Valur J?nsson; python-dev at python.org
Subject: Re: [Python-Dev] recursive closures - reference leak

2009/12/8 Maciej Fijalkowski <fijall at gmail.com<mailto:fijall at gmail.com>>
Note that disabling gc
does not mean that you will not have unpredictable pauses. Consider
for example that if you loose a reference to a very long chain of
objects, you can have arbitrarily many frees being called before
anything else can happen.

That strikes me as a *predictable* long pause.
--

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091208/77d15dd6/attachment.htm>

From kristjan at ccpgames.com  Tue Dec  8 17:15:56 2009
From: kristjan at ccpgames.com (=?utf-8?B?S3Jpc3Rqw6FuIFZhbHVyIErDs25zc29u?=)
Date: Tue, 8 Dec 2009 16:15:56 +0000
Subject: [Python-Dev] recursive closures - reference cycle
In-Reply-To: <loom.20091208T153516-777@post.gmane.org>
References: <930F189C8A437347B80DF2C156F7EC7F09906751C4@exchis.ccp.ad.local>
	<loom.20091208T153516-777@post.gmane.org>
Message-ID: <930F189C8A437347B80DF2C156F7EC7F09906752CF@exchis.ccp.ad.local>



> -----Original Message-----
> From: python-dev-bounces+kristjan=ccpgames.com at python.org
> [mailto:python-dev-bounces+kristjan=ccpgames.com at python.org] On Behalf
> Of Antoine Pitrou
> Sent: 8. desember 2009 14:55
> To: python-dev at python.org
> Subject: Re: [Python-Dev] recursive closures - reference cycle
> 
> Kristj?n Valur J?nsson <kristjan <at> ccpgames.com> writes:
> >
> > The problem with this is that once you have called
> > factorial() once, you end up with a recursive cycle.
> 
> You don't need a closure to exhibit a reference cycle. A global
> function is
> enough:
> 
> >>> def helper(n):
> ...  if n:
> ...   return n*helper(n-1)
> ...  else:
> ...   return 1
> ...
> >>> helper.func_globals['helper'] is helper
> True
> 
yes, because:
func_globals is globals() == True

You don't need recursion for this to be true.  And as soon as you delete "helper" from globals() it goes away.
w = wearref.weakref(helper)
del helper
w() == False.

> 
> If you really want to avoid this you can prevent the function from
> depending
> on its outside environment:
> 
> >>> from functools import partial
> >>> def helper2(rec, n):
> ...  if n:
> ...   return n*rec(rec, n-1)
> ...  else:
> ...   return 1
> ...
> >>> factorial = partial(helper2, helper2)
> >>> "helper2" in factorial.func.func_globals
> True
> >>> del helper2
> >>> "helper2" in factorial.func.func_globals
> False
> >>> factorial(3)
> 6

Interesting, pass itself in as an argument.
Yes, there are ways around this, I know.  But you have to agree that it is unexpected, no?
Somethign for the "reference cycle FAQ."

Anyway, I?ll return to my lair now, thanks for your time python-dev :)

K

From ziade.tarek at gmail.com  Tue Dec  8 18:16:51 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 8 Dec 2009 18:16:51 +0100
Subject: [Python-Dev] Proposing PEP 386 for addition
Message-ID: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>

Hello,

On behalf of the Distutils-SIG, I would like to propose PEP 386 for
inclusion in the sdtlib, and have a final discussion here on
Python-dev.

http://www.python.org/dev/peps/pep-0386

This PEP has been discussed for some time in Distutils-SIG, and we
agreed there that it's important to have it accepted for the future of
packaging because:

1/ it will offer interoperability for all Python package managers out
there. (namely: Distutils, Distribute, Setuptools, Pip, PyPM)
2/ it will provide a reference for OS packagers, so they can translate
automatically Python distributions versions in their own schemes.

Choosing a schema was quite controversial because every development
team have their own version scheme. But notice that it is not in the
scope of this PEP to come up with an universal versioning schema,
intended to support many or all existing versioning schemas. There
will always be competing grammars, either mandated by distro or
project policies or by historical reasons and we cannot expect that to
change.

The goal of this PEP is rather to provide a standard reference schema
that is able to express the usual versioning semantics, so it's
possible to parse any alternative versioning schema and transform it
into a compliant one. This is how OS packagers usually deal with the
existing version schemas and is a preferable alternative than
supporting an arbitrary set of versioning schemas.

I believe that the current situation is as close to consensus as we
will get on distutils-sig, and in the interests of avoiding months of
further discussion which won't take things any further, I propose to
allow final comments from python-dev and then look for a final
decision.

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org |????????????! |????????????

From tjreedy at udel.edu  Tue Dec  8 20:45:11 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 08 Dec 2009 14:45:11 -0500
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
Message-ID: <hfmac3$fqn$1@ger.gmane.org>

Tarek Ziad? wrote:
> Hello,
> 
> On behalf of the Distutils-SIG, I would like to propose PEP 386 for
> inclusion in the sdtlib, and have a final discussion here on
> Python-dev.
> 
> http://www.python.org/dev/peps/pep-0386

Some English copy editor comments:

"and it will optionally allow to use that field"
I believe you mean
"and it will optionally allow use of that field"

"requires zope.interface, as long as its version is superior to 3.5.0."
"requires zope.interface with a version greater than 3.5.0."

"It is not in the scope of this PEP to come with an universal versioning 
schema,intended to support..."
I believe you mean
"It is not in the scope of this PEP to provide a universal versioning 
schema intended to support..."



From python at mrabarnett.plus.com  Tue Dec  8 21:31:59 2009
From: python at mrabarnett.plus.com (MRAB)
Date: Tue, 08 Dec 2009 20:31:59 +0000
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <hfmac3$fqn$1@ger.gmane.org>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<hfmac3$fqn$1@ger.gmane.org>
Message-ID: <4B1EB7BF.50005@mrabarnett.plus.com>

Terry Reedy wrote:
> Tarek Ziad? wrote:
>> Hello,
>>
>> On behalf of the Distutils-SIG, I would like to propose PEP 386 for
>> inclusion in the sdtlib, and have a final discussion here on
>> Python-dev.
>>
>> http://www.python.org/dev/peps/pep-0386
> 
> Some English copy editor comments:
> 
> "and it will optionally allow to use that field"
> I believe you mean
> "and it will optionally allow use of that field"
> 
> "requires zope.interface, as long as its version is superior to 3.5.0."
> "requires zope.interface with a version greater than 3.5.0."
> 
[snip]

I assume this does mean > 3.5.0. If instead it means >= 3.5.0 then it
would be clearer as "3.5.0 or greater/above/later".


From rowen at uw.edu  Tue Dec  8 21:54:54 2009
From: rowen at uw.edu (Russell E. Owen)
Date: Tue, 08 Dec 2009 12:54:54 -0800
Subject: [Python-Dev] Proposing PEP 386 for addition
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
Message-ID: <rowen-C374EB.12545408122009@news.gmane.org>

In article 
<94bdd2610912080916s2dbb79d0ub8a77295bba9266e at mail.gmail.com>,
 Tarek Ziad? <ziade.tarek at gmail.com> wrote:

> http://www.python.org/dev/peps/pep-0386

It looks great to me. Very complete and easy to understand.

-- Russell


From greg.ewing at canterbury.ac.nz  Tue Dec  8 23:08:42 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 09 Dec 2009 11:08:42 +1300
Subject: [Python-Dev] recursive closures - reference cycle
In-Reply-To: <930F189C8A437347B80DF2C156F7EC7F09906752CF@exchis.ccp.ad.local>
References: <930F189C8A437347B80DF2C156F7EC7F09906751C4@exchis.ccp.ad.local>
	<loom.20091208T153516-777@post.gmane.org>
	<930F189C8A437347B80DF2C156F7EC7F09906752CF@exchis.ccp.ad.local>
Message-ID: <4B1ECE6A.6090005@canterbury.ac.nz>

You could use a class:

   class factorial():

     def fac(self, n):
       if n == 0:
         return 1
       else:
         return n * self.fac(n - 1)

     def __call__(self, n):
       return self.fac(n)

   factorial = factorial()

   print factorial(5)

-- 
Greg


From ziade.tarek at gmail.com  Wed Dec  9 00:13:42 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 9 Dec 2009 00:13:42 +0100
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <hfmac3$fqn$1@ger.gmane.org>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<hfmac3$fqn$1@ger.gmane.org>
Message-ID: <94bdd2610912081513tdc5471m5d883e77e1a92163@mail.gmail.com>

On Tue, Dec 8, 2009 at 8:45 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> Tarek Ziad? wrote:
>>
>> Hello,
>>
>> On behalf of the Distutils-SIG, I would like to propose PEP 386 for
>> inclusion in the sdtlib, and have a final discussion here on
>> Python-dev.
>>
>> http://www.python.org/dev/peps/pep-0386
>
> Some English copy editor comments:
>
> "and it will optionally allow to use that field"
> I believe you mean
> "and it will optionally allow use of that field"
>
> "requires zope.interface, as long as its version is superior to 3.5.0."
> "requires zope.interface with a version greater than 3.5.0."
>
> "It is not in the scope of this PEP to come with an universal versioning
> schema,intended to support..."
> I believe you mean
> "It is not in the scope of this PEP to provide a universal versioning schema
> intended to support..."

Applied, thank you

From yjoshi at starentnetworks.com  Wed Dec  9 09:51:40 2009
From: yjoshi at starentnetworks.com (Joshi, Yateen)
Date: Wed, 9 Dec 2009 14:21:40 +0530
Subject: [Python-Dev] Issues with multiprocessing
Message-ID: <3BD53621E5C8E54594130AF5459379EE135B8FA5@exchindia4.starentnetworks.com>

Hi,

 

I have an application that uses multiprocessing pools
(multiprocessing.Pool(processes=.....)). There are multiple such pools
and each pool has configurable number of processes. Once the process is
spawned, it keeps on executing and does the needed processing. If there
is nothing to process (like ftp'ing files from some source, if the files
are not there, the process would sleep for some time, and then again
check for files, that way, it is a infinite loop with some sleep), the
process 'sleeps' for some time and continues.

 

I am using a T5220, Solaris box with Solaris 10. 

Problem -there are multiple pools and multiple processes, i am seeing
that not all the processes get spawned. They get spawned when the sleep
time is increased (say from 0.1 sec to 1 sec). If I further increase the
number of processes, again some process do not get spawned. For that, I
further need to increase the sleep time (say to 2 sec), then the
processes get spawned.

 

Typically, in a multiprocessing I would expect that if a process sleeps
for even a small time, other processes should get their chance to
execute, but this does not seem to be happening here. Can you please
throw some light on it?

 

Thanks and Regards,

 

Yateen V. Joshi

 


This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091209/376cf03e/attachment.htm>

From fuzzyman at voidspace.org.uk  Wed Dec  9 12:22:42 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 09 Dec 2009 11:22:42 +0000
Subject: [Python-Dev] Issues with multiprocessing
In-Reply-To: <3BD53621E5C8E54594130AF5459379EE135B8FA5@exchindia4.starentnetworks.com>
References: <3BD53621E5C8E54594130AF5459379EE135B8FA5@exchindia4.starentnetworks.com>
Message-ID: <4B1F8882.60600@voidspace.org.uk>

On 09/12/2009 08:51, Joshi, Yateen wrote:
>
> Hi,
>
> I have an application that uses multiprocessing pools 
> (multiprocessing.Pool(processes=.....)). There are multiple such pools 
> and each pool has configurable number of processes. Once the process 
> is spawned, it keeps on executing and does the needed processing. If 
> there is nothing to process (like ftp'ing files from some source, if 
> the files are not there, the process would sleep for some time, and 
> then again check for files, that way, it is a infinite loop with some 
> sleep), the process 'sleeps' for some time and continues.
>
> I am using a T5220, Solaris box with Solaris 10.
>
> Problem --there are multiple pools and multiple processes, i am seeing 
> that not all the processes get spawned. They get spawned when the 
> sleep time is increased (say from 0.1 sec to 1 sec). If I further 
> increase the number of processes, again some process do not get 
> spawned. For that, I further need to increase the sleep time (say to 2 
> sec), then the processes get spawned.
>
> Typically, in a multiprocessing I would expect that if a process 
> sleeps for even a small time, other processes should get their chance 
> to execute, but this does not seem to be happening here. Can you 
> please throw some light on it?
>

Hello Joshi,

This email list is for the development of Python, not for developing 
with Python. A better place to try would be the python-list 
(comp.lang.python - which has both google groups and gmane gateways).

All the best,

Michael Foord


> Thanks and Regards,
>
> Yateen V. Joshi
>
> This email and any attachments may contain legally privileged and/or 
> confidential information of Starent Networks, Corp. and is intended 
> only for the individual or entity named in the message. The 
> information transmitted may not be used to create or change any 
> contractual obligations of Starent Networks, Corp. Any review, 
> retransmission, dissemination or other use of, or taking of any action 
> in reliance upon this e-mail and its attachments by persons or 
> entities other than the intended recipient is prohibited. If you are 
> not the intended recipient, please notify the sender immediately -- by 
> replying to this message or by sending an email to 
> postmaster at starentnetworks.com -- and destroy all copies of this 
> message and any attachments without reading or disclosing their 
> contents. Thank you.
>
>
> _______________________________________________
> 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.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091209/b859660f/attachment.htm>

From cybersol at yahoo.com  Wed Dec  9 05:53:18 2009
From: cybersol at yahoo.com (Michael Mysinger)
Date: Tue, 8 Dec 2009 20:53:18 -0800 (PST)
Subject: [Python-Dev] Proposing PEP 386 for addition
Message-ID: <772583.98842.qm@web55501.mail.re4.yahoo.com>

More English language fixes:

-In Python there are no real restriction yet on how a project should
+In Python there are no real restrictions yet on how a project should

-Furthermore, this will make OS packagers work easier when repackaging standards
-compliant distributions, as of now it can be difficult to decide how two
+Furthermore, this will make OS packagers' work easier when repackaging standards
+compliant distributions, because as of now it can be difficult to decide how two
 ? 
-to support many or all existing versioning schemas.
+to support all or even most of existing versioning schemas.? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ???
-reasons and we cannot expect that to change.? ? ? ? ? ? ? ? ? ? ? ? ? +reasons that we cannot expect to change.? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ???
-version schemas and is a preferable alternative than supporting
+version schemas and is a preferable alternative to supporting

-there should be possible to express more than one versioning level
+it should be possible to express more than one versioning level


-The problem with this is that while it allows expressing requisite any
-nesting level it doesn't allow to express special meaning versions
-(pre and post-releases as well as development versions), as expressed in? +The problem with this is that while it allows expressing any
+nesting level it doesn't allow giving special meaning to versions
+(pre- and post-releases as well as development versions) as expressed in

-Also, notice that Distutils version classes are not really used in the
+Also, note that Distutils version classes are not really used in the? ? ? 

-which does not enforce any rule for the version, but 
+which does not enforce any rules for the version, but 

-Setuptools function is quite spread because it's used by tools
+Setuptools function is quite widespread because it's used by tools ? ? ? 

-post-releases -- which apparently is used by a number of projects
+post-releases -- which apparently are used by a number of projects

This one is particularly critical to your intended meaning as I read it:
-before a <tt class="docutils literal"><span class="pre">.post345</span></tt> marker.
+before a <tt class="docutils literal"><span class="pre">.post456</span></tt> marker.

Technical question:

I don't know what notation this versioning schema was trying for, especially in regards to what the +'s mean:
N.N[.N]+[abc]N[.N]+[.postN+][.devN+]
Am I missing something here? You could maybe explain what the pluses mean in the PEP, and why some are inside the [] and others are outside.

Or a regular expression version like this might be more specific. 
N.N(.N)?([abc]N(.N)?)?(.postN)?(.devN)?

Or an linux help version like this may be more readible.
N.N[.N][{abc}N[.N]][.postN][.devN]

Cheers,
Michael Mysinger
(longtime python-dev lurker)



      

From kristjan at ccpgames.com  Wed Dec  9 13:03:52 2009
From: kristjan at ccpgames.com (=?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=)
Date: Wed, 9 Dec 2009 12:03:52 +0000
Subject: [Python-Dev] recursive closures - reference cycle
In-Reply-To: <4B1ECE6A.6090005@canterbury.ac.nz>
References: <930F189C8A437347B80DF2C156F7EC7F09906751C4@exchis.ccp.ad.local>
	<loom.20091208T153516-777@post.gmane.org>
	<930F189C8A437347B80DF2C156F7EC7F09906752CF@exchis.ccp.ad.local>
	<4B1ECE6A.6090005@canterbury.ac.nz>
Message-ID: <930F189C8A437347B80DF2C156F7EC7F0990675504@exchis.ccp.ad.local>

> -----Original Message-----
> From: python-dev-bounces+kristjan=ccpgames.com at python.org
> [mailto:python-dev-bounces+kristjan=ccpgames.com at python.org] On Behalf
> Of Greg Ewing
> Sent: 8. desember 2009 22:09
> To: python-dev at python.org
> Subject: Re: [Python-Dev] recursive closures - reference cycle
> 
> You could use a class:

Yes, and a number of different workarounds.  That's not really the issue.  The issue is that what looks like a perfectly safe idiom (calling a function recursively) happens to create a reference cycle if that function is a closure.
This is a non-obvious "gotcha" that I must now educate my team about.

Note that at least parts of the library strive to avoid reference cycles even though "gc" exists.  An example being xlm.minidom.Document.unlink()

Cheers,

Kristj?n


From floris.bruynooghe at gmail.com  Wed Dec  9 13:21:36 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Wed, 9 Dec 2009 12:21:36 +0000
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <772583.98842.qm@web55501.mail.re4.yahoo.com>
References: <772583.98842.qm@web55501.mail.re4.yahoo.com>
Message-ID: <20091209122136.GA19650@laurie.devork>

On Tue, Dec 08, 2009 at 08:53:18PM -0800, Michael Mysinger wrote:
> Technical question:
> 
> I don't know what notation this versioning schema was trying for, especially in regards to what the +'s mean:
> N.N[.N]+[abc]N[.N]+[.postN+][.devN+]
> Am I missing something here? You could maybe explain what the pluses mean in the PEP, and why some are inside the [] and others are outside.
> 
> Or a regular expression version like this might be more specific. 
> N.N(.N)?([abc]N(.N)?)?(.postN)?(.devN)?

The full regex (stripped from named groups) is the rather unreadable:

\d+\.\d+(\.\d+)*([abc]?\d+(\.\d+)*)?((\.post\d+)?(\.dev\d+)?)?

(And hopfully I didn't make a mistake here)

So the '+' in the pseudo notation above roughly means "one or more"
with the brackets meaning "zero or one" so plus and brackets combined
result into "zero or more".  But even then it's might be missing
square brackets around the whole of "[abc]N[.N]+".

Note that the meaning of the contents of the brackets changes too
("abc" is a choice, .postN+ is the recursive notation) so it'll
probably never work exactly.  So maybe the PEP should also include the
full regex for exactness.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From solipsis at pitrou.net  Wed Dec  9 13:30:35 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 9 Dec 2009 12:30:35 +0000 (UTC)
Subject: [Python-Dev] recursive closures - reference leak
References: <930F189C8A437347B80DF2C156F7EC7F09906751C4@exchis.ccp.ad.local>
	<4B1E5A06.5020802@avl.com>
	<930F189C8A437347B80DF2C156F7EC7F0990675263@exchis.ccp.ad.local>
	<693bc9ab0912080658g24903721s5692132cdaca065@mail.gmail.com>
	<eae285400912080704k5f25f10fx8ba31da0173495c1@mail.gmail.com>
	<930F189C8A437347B80DF2C156F7EC7F09906752B7@exchis.ccp.ad.local>
Message-ID: <loom.20091209T132921-446@post.gmane.org>

Kristj?n Valur J?nsson <kristjan <at> ccpgames.com> writes:
> 
> a gc.collect() cycle visits a large amount of objects that it
> won?t release causing cache thrashing.
> 
> There is a reason we disabled ?gc?, and it is simply because we
> get lower cpu and smoother execution.

Could you try to enable the gc with Python trunk and report whether it does
fewer and/or shorter gc collections? The gc has been optimized a bit compared to
2.6 and earlier.

Thank you

Antoine.



From jnoller at gmail.com  Wed Dec  9 13:52:46 2009
From: jnoller at gmail.com (Jesse Noller)
Date: Wed, 9 Dec 2009 07:52:46 -0500
Subject: [Python-Dev] Issues with multiprocessing
In-Reply-To: <4B1F8882.60600@voidspace.org.uk>
References: <3BD53621E5C8E54594130AF5459379EE135B8FA5@exchindia4.starentnetworks.com>
	<4B1F8882.60600@voidspace.org.uk>
Message-ID: <4222a8490912090452h3cbc2565x1295759695e31e7f@mail.gmail.com>

On Wed, Dec 9, 2009 at 6:22 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> On 09/12/2009 08:51, Joshi, Yateen wrote:
>
> Hi,
>
>
>
> I have an application that uses multiprocessing pools
> (multiprocessing.Pool(processes=?..)). There are multiple such pools and
> each pool has configurable number of processes. Once the process is spawned,
> it keeps on executing and does the needed processing. If there is nothing to
> process (like ftp?ing files from some source, if the files are not there,
> the process would sleep for some time, and then again check for files, that
> way, it is a infinite loop with some sleep), the process ?sleeps? for some
> time and continues.
>
>
>
> I am using a T5220, Solaris box with Solaris 10.
>
> Problem ?there are multiple pools and multiple processes, i am seeing that
> not all the processes get spawned. They get spawned when the sleep time is
> increased (say from 0.1 sec to 1 sec). If I further increase the number of
> processes, again some process do not get spawned. For that, I further need
> to increase the sleep time (say to 2 sec), then the processes get spawned.
>
>
>
> Typically, in a multiprocessing I would expect that if a process sleeps for
> even a small time, other processes should get their chance to execute, but
> this does not seem to be happening here. Can you please throw some light on
> it?
>
> Hello Joshi,
>
> This email list is for the development of Python, not for developing with
> Python. A better place to try would be the python-list (comp.lang.python -
> which has both google groups and gmane gateways).
>
> All the best,
>
> Michael Foord
>


Additionally, if you suspect there is a reproducible box (preferably
not just on solaris, which I do not have access to) please file it in
the tracker.

From lregebro at jarn.com  Wed Dec  9 17:27:28 2009
From: lregebro at jarn.com (Lennart Regebro)
Date: Wed, 9 Dec 2009 17:27:28 +0100
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
Message-ID: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>

I just ran the tests for zope.testing on Python 2.7, and the results are not
good. It seems that there are multiple minor difference in the output
formatting of the testresults between 2.7 and previous 2.x versions. The
result is that all the tests that test testing (zope.testing includes a
testrunner) fails.

Is these changes necessary? It's going to be hell to test any form of
testrunner under both 2.6 and 2.7 if the formatting of test results have
changed.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091209/f879a6f7/attachment.htm>

From benjamin at python.org  Wed Dec  9 17:29:38 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Wed, 9 Dec 2009 10:29:38 -0600
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
Message-ID: <1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>

2009/12/9 Lennart Regebro <lregebro at jarn.com>:
> Is these changes necessary? It's going to be hell to test any form of
> testrunner under both 2.6 and 2.7 if the formatting of test results have
> changed.

Could you mention what specific changes are causing problems?



-- 
Regards,
Benjamin

From fuzzyman at voidspace.org.uk  Wed Dec  9 17:34:20 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 09 Dec 2009 16:34:20 +0000
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
Message-ID: <4B1FD18C.2080107@voidspace.org.uk>

On 09/12/2009 16:27, Lennart Regebro wrote:
> I just ran the tests for zope.testing on Python 2.7, and the results 
> are not good. It seems that there are multiple minor difference in the 
> output formatting of the testresults between 2.7 and previous 2.x 
> versions. The result is that all the tests that test testing 
> (zope.testing includes a testrunner) fails.
>
> Is these changes necessary? It's going to be hell to test any form of 
> testrunner under both 2.6 and 2.7 if the formatting of test results 
> have changed.

Can you be more specific? How has formatting changed and how has that 
broken your tests?

Relying on specific formatting for test results *sounds* like you are 
relying on an implementation detail (although this is one of the reasons 
that I rarely use doctest exception in documentation - because it 
depends on implementation details like the repr of objects...)

Some of the failure reporting in unittest has *improved* in Python 2.7 - 
are you feeding the output of unittest back into doctest... ?

All the best,

Michael Foord
>
> -- 
> Lennart Regebro: Python, Zope, Plone, Grok
> http://regebro.wordpress.com/
> +33 661 58 14 64
>
>
> _______________________________________________
> 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.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091209/5d0bd2b8/attachment.htm>

From fdrake at acm.org  Wed Dec  9 17:43:54 2009
From: fdrake at acm.org (Fred Drake)
Date: Wed, 9 Dec 2009 11:43:54 -0500
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com> 
	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>
Message-ID: <9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>

On Wed, Dec 9, 2009 at 11:29 AM, Benjamin Peterson <benjamin at python.org> wrote:
> Could you mention what specific changes are causing problems?

I'd be glad to head Lennart confirm this, but I suspect this is
primarily changes in exception messages; 2.7 in many places provides
better messages.

I found some of this with a few of the Zope-related packages that I
tried testing under pre-2.7 versions of Python.  If this is what
Lennart's referring to, I consider this to be a problem with the
tests.  Unfortunately, doctest lends itself to having tests that check
these sorts of implementation details, and the Zope community has
certainly succumbed to that temptation.

Evolving the tests to avoid depending on these sorts of implementation
details is reasonable, IMO, and cuold even be considered a bugfix by
the Zope community.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller

From lregebro at jarn.com  Wed Dec  9 18:11:29 2009
From: lregebro at jarn.com (Lennart Regebro)
Date: Wed, 9 Dec 2009 18:11:29 +0100
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <4B1FD18C.2080107@voidspace.org.uk>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<4B1FD18C.2080107@voidspace.org.uk>
Message-ID: <319e029f0912090911u2e64e957mb18319d95f147d58@mail.gmail.com>

On Wed, Dec 9, 2009 at 17:34, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> Can you be more specific?

Only with an insane amount of work. I'll hold that off for a while.

> Relying on specific formatting for test results *sounds* like you are relying on an implementation detail

Yeah, but that's doctests for you. And it's a mode of testing that
makes sense when you test testrunners, as the result of a testrunner
is the output. It's extremely hard to *not* test a testrunner without
looking at the output.

> Some of the failure reporting in unittest has *improved* in Python 2.7 - are you feeding the output of unittest back into doctest... ?

Yes, as this is a testrunner being tested.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From olemis at gmail.com  Wed Dec  9 18:14:24 2009
From: olemis at gmail.com (Olemis Lang)
Date: Wed, 9 Dec 2009 12:14:24 -0500
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <4B1FD18C.2080107@voidspace.org.uk>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<4B1FD18C.2080107@voidspace.org.uk>
Message-ID: <24ea26600912090914ob4047c0h638bb6ab55e3ed26@mail.gmail.com>

On Wed, Dec 9, 2009 at 11:34 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> On 09/12/2009 16:27, Lennart Regebro wrote:
>
> I just ran the tests for zope.testing on Python 2.7, and the results are not
> good. It seems that there are multiple minor difference in the output
> formatting of the testresults between 2.7 and previous 2.x versions. The
> result is that all the tests that test testing (zope.testing includes a
> testrunner) fails.
>
> Is these changes necessary? It's going to be hell to test any form of
> testrunner under both 2.6 and 2.7 if the formatting of test results have
> changed.
>

This is fuzzy . It is necessary to be more precise and describe what
happens in detail.

Besides, I think that it's also necessary to mention (briefly) how
tests look like . Perhaps this is a situation where many fragile tests
[1]_ have been written and something

>
> Relying on specific formatting for test results *sounds* like you are
> relying on an implementation detail

This makes sense (~65% , and not because it's partially wrong but
because of subjective interpretations and criteria) . Perhaps the best
way would be to analyze contents of test results . The nature of test
runners implies that many features (e.g. formatting used to display
test results) are not standard . OTOH , the contents in instances of
TestResult are (should be more) standard, thereby it's (probably)
better to analyze the contents recorded in there (using doctest or
unittest, or ... ;o)

PS: I'm talking loud with my eyes closed , just a few preliminary
thoughts while waiting for the details ;o)

>
> Some of the failure reporting in unittest has *improved* in Python 2.7 - are
> you feeding the output of unittest back into doctest... ?
>

... and I'm assuming that this is what's been done, isn't it ?

.. [1] Fragile tests
        (http://xunitpatterns.com/Fragile%20Test.html)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

From lregebro at jarn.com  Wed Dec  9 18:23:11 2009
From: lregebro at jarn.com (Lennart Regebro)
Date: Wed, 9 Dec 2009 18:23:11 +0100
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>
	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>
Message-ID: <319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>

On Wed, Dec 9, 2009 at 17:43, Fred Drake <fdrake at acm.org> wrote:
> On Wed, Dec 9, 2009 at 11:29 AM, Benjamin Peterson <benjamin at python.org> wrote:
>> Could you mention what specific changes are causing problems?
>
> I'd be glad to head Lennart confirm this, but I suspect this is
> primarily changes in exception messages; 2.7 in many places provides
> better messages.

Ouch, that is *not* good. That's going to break tests for all
doctests, not just zope.testing (which obviously is a special case). I
know PythonZope 3 has changes there do, and that's annoying in itself
but acceptable since Python 3 doesn't promise to be backwards
compatible, but a similar change in 2.7 is something I would consider
a bug.

> I found some of this with a few of the Zope-related packages that I
> tried testing under pre-2.7 versions of Python.

You remember which one?

> ?If this is what Lennart's referring to,

No, the only modules I've run under 2.7 so far is zope.interface which
passes the tests, zope.exception which has no doctests and zope.event,
which has 4 lines of code. :)

And zope.testing, then, which is massive and had loads and loads of
tests, mostly doctests.

> I consider this to be a problem with the tests.

If the exception format has changed, I consider it a bug. Possibly a
bug in doctest, as the only way to test for exceptions in that case is
like this:

    >>> try:
    ...     throw_an_exception()
    ...     print "Did not throw the exception"
    ... except DesiredException:
    ...     print "passed"
    passed

And that frankly is rather ugly. That's how I have done with doctests
when porting to Python 3 so far. I don't think it's a good idea to
require it for Python 2.7 as well.

> Evolving the tests to avoid depending on these sorts of implementation
> details is reasonable, IMO, and cuold even be considered a bugfix by
> the Zope community.

Evolving doctest.py so it can handle this by itself would be
considered a bugfix by me. :)
-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From olemis at gmail.com  Wed Dec  9 18:29:39 2009
From: olemis at gmail.com (Olemis Lang)
Date: Wed, 9 Dec 2009 12:29:39 -0500
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <24ea26600912090914ob4047c0h638bb6ab55e3ed26@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<4B1FD18C.2080107@voidspace.org.uk>
	<24ea26600912090914ob4047c0h638bb6ab55e3ed26@mail.gmail.com>
Message-ID: <24ea26600912090929r25d4e5cbgc262182ba86b22ad@mail.gmail.com>

On Wed, Dec 9, 2009 at 12:14 PM, Olemis Lang <olemis at gmail.com> wrote:
> On Wed, Dec 9, 2009 at 11:34 AM, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
>> On 09/12/2009 16:27, Lennart Regebro wrote:
>>
>> I just ran the tests for zope.testing on Python 2.7, and the results are not
>> good. It seems that there are multiple minor difference in the output
>> formatting of the testresults between 2.7 and previous 2.x versions. The
>> result is that all the tests that test testing (zope.testing includes a
>> testrunner) fails.
>>
>> Is these changes necessary?

Well all Pythons need to change their (skin?) from time to time , isn't it ?
:P

>> It's going to be hell to test any form of
>> testrunner under both 2.6 and 2.7 if the formatting of test results have
>> changed.
>>
>
> This is fuzzy . It is necessary to be more precise and describe what
> happens in detail.
>

Sorry I didn't see your confirmation in the last msg you posted to the list .

@Fred Drake <fdrake at acm dot org>
{{{
Evolving the tests to avoid depending on these sorts of implementation
details is reasonable, IMO, and cuold even be considered a bugfix by
the Zope community.
}}}

Salomon says :

  - Problem could impact beyond Zope itself
  - unittest has been very stable (until now) so many solutions might be
    tightly coupled to its implementation details (e.g. formatting and reports)
  - so why not to include an option in order to keep runners compatible with
    < 2.7 ?

A dinosaur will not become a Python in just a few days
;o)

> Besides, I think that it's also necessary to mention (briefly) how
> tests look like . Perhaps this is a situation where many fragile tests
> [1]_ have been written and something
>

... changed somewhere and your tests suddenly don't pass anymore
:(

>
> PS: I'm talking loud with my eyes closed , just a few preliminary
> thoughts while waiting for the details ;o)
>

... opening my eyes

:o)

> .. [1] Fragile tests
> ? ? ? ?(http://xunitpatterns.com/Fragile%20Test.html)
>

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Depurando errores en aplicaciones web CGI con Python  -
http://feedproxy.google.com/~r/simelo-es/~3/xxyDHHH1YZ8/depurando-errores-en-aplicaciones-web.html

From olemis at gmail.com  Wed Dec  9 18:33:10 2009
From: olemis at gmail.com (Olemis Lang)
Date: Wed, 9 Dec 2009 12:33:10 -0500
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>
	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
Message-ID: <24ea26600912090933o37a2834ap192819054a2a237b@mail.gmail.com>

On Wed, Dec 9, 2009 at 12:23 PM, Lennart Regebro <lregebro at jarn.com> wrote:
> On Wed, Dec 9, 2009 at 17:43, Fred Drake <fdrake at acm.org> wrote:
>> On Wed, Dec 9, 2009 at 11:29 AM, Benjamin Peterson <benjamin at python.org> wrote:
>
>> Evolving the tests to avoid depending on these sorts of implementation
>> details is reasonable, IMO, and cuold even be considered a bugfix by
>> the Zope community.
>
> Evolving doctest.py so it can handle this by itself would be
> considered a bugfix by me. :)

+1

This seems to be a better solution

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Depurando errores en aplicaciones web CGI con Python  -
http://feedproxy.google.com/~r/simelo-es/~3/xxyDHHH1YZ8/depurando-errores-en-aplicaciones-web.html

From ianb at colorstudy.com  Wed Dec  9 18:45:58 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 9 Dec 2009 11:45:58 -0600
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com> 
	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com> 
	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com> 
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
Message-ID: <b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com>

On Wed, Dec 9, 2009 at 11:23 AM, Lennart Regebro <lregebro at jarn.com> wrote:

>  > Evolving the tests to avoid depending on these sorts of implementation
> > details is reasonable, IMO, and cuold even be considered a bugfix by
> > the Zope community.
>
> Evolving doctest.py so it can handle this by itself would be
> considered a bugfix by me. :)


It's about time doctest got another run of development anyway.  I can
imagine a couple features that might help:

* Already in there, but sometimes hard to enable, is ellipsis.  Can you
already do this?


    >>> throw_an_exception()
    Traceback (most recent call last):
        ...
    DesiredException: ...

I'd like to see doctests be able to enable the ELLIPSIS option internally
and globally (currently it can only be enabled outside the doctest, or for a
single line).

* Another option might be something version-specific, like:

    >>> throw_an_exception() # +python<2.7
    ... old exception ...
    >>> throw_an_exception() # +python>=2.7
    ... new exception ...

* Maybe slightly more general, would be the ability to extend OutputCheckers
more easily than currently.  Maybe for instance "# py_version(less=2.7)"
would enable the "py_version" output checker, which would always succeed if
the version was greater than or equal to 2.7 (effectively ignoring the
output).  Or, maybe checkers could be extended so they could actually
suppress the execution of code (avoiding throw_an_exception() from being
called twice).

* Or, something more explicit than ELLIPSIS but able also be more flexible
than currently possible, like:

    >>> throw_an_exception()
    Traceback (most recent call last):
        ...
    DesiredException: [[2.6 error message | 2.7 error message]]

-- 
Ian Bicking  |  http://blog.ianbicking.org  |
http://topplabs.org/civichacker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091209/dfc47c3e/attachment-0001.htm>

From rdmurray at bitdance.com  Wed Dec  9 18:52:22 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 09 Dec 2009 12:52:22 -0500
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>
	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
Message-ID: <20091209175222.563671F9F9B@kimball.webabinitio.net>

On Wed, 09 Dec 2009 18:23:11 +0100, Lennart Regebro wrote:
> If the exception format has changed, I consider it a bug. Possibly a
> bug in doctest, as the only way to test for exceptions in that case is
> like this:
> 
>     >>> try:
>     ...     throw_an_exception()
>     ...     print "Did not throw the exception"
>     ... except DesiredException:
>     ...     print "passed"
>     passed
> 
> And that frankly is rather ugly. That's how I have done with doctests
> when porting to Python 3 so far. I don't think it's a good idea to
> require it for Python 2.7 as well.

If it's a bug it would have to be in doctest, since the format of
traceback messages is explicitly *not* part of the Python API.

In what way is the doctest ellipsis support not sufficient for this
case?

--David (RDM)

From fuzzyman at voidspace.org.uk  Wed Dec  9 18:55:45 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 09 Dec 2009 17:55:45 +0000
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
Message-ID: <4B1FE4A1.5020303@voidspace.org.uk>

On 09/12/2009 17:23, Lennart Regebro wrote:
> [snip...]
>> Evolving the tests to avoid depending on these sorts of implementation
>> details is reasonable, IMO, and cuold even be considered a bugfix by
>> the Zope community.
>>      
> Evolving doctest.py so it can handle this by itself would be
> considered a bugfix by me. :)
>    

That may or may not be possible (it certainly sounds like a good 
change). You still haven't told us what change it is that breaks things, 
so it is a little hard to know what to fix.

Some of the unittest failure messages have changed as well, and it is 
just as likely to be those. Some of them were truly awful (default error 
message for assertTrue was "AssertionError: None") so I would be very 
reluctant to revert those.

Even if doctest is changed (more templating so that you can specify 
exception messages more easily) it will probably still require some 
changes to the tests. Finding an alternative testing technique for your 
test runners may or may not be more work...

Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog



From lregebro at jarn.com  Wed Dec  9 18:56:03 2009
From: lregebro at jarn.com (Lennart Regebro)
Date: Wed, 9 Dec 2009 18:56:03 +0100
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>
	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
	<b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com>
Message-ID: <319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com>

On Wed, Dec 9, 2009 at 18:45, Ian Bicking <ianb at colorstudy.com> wrote:
> It's about time doctest got another run of development anyway. ?I can
> imagine a couple features that might help:
> * Already in there, but sometimes hard to enable, is ellipsis. ?Can you
> already do this?
>
> ?? ?>>>?throw_an_exception()
> ?? ?Traceback (most recent call last):
> ?? ? ? ?...
> ?? ?DesiredException: ...

I think so, but what you need is:

>     >>> throw_an_exception()
>     Traceback (most recent call last):
>         ...
>    ...DesiredException: ...

Because one of the changes in Python 3 is that you now get the full
class path to the exception.

> * Maybe slightly more general, would be the ability to extend OutputCheckers
> more easily than currently. ?Maybe for instance "# py_version(less=2.7)"
> would enable the "py_version" output checker, which would always succeed if
> the version was greater than or equal to 2.7 (effectively ignoring the
> output). ?Or, maybe checkers could be extended so they could actually
> suppress the execution of code (avoiding throw_an_exception() from being
> called twice).

zope.testing has an output checker to which you can add transformers,
that's run on both the expected and actual output. Something like that
might work. We could then have a transformer that handles differences
in exception formats by default.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From lregebro at jarn.com  Wed Dec  9 19:01:32 2009
From: lregebro at jarn.com (Lennart Regebro)
Date: Wed, 9 Dec 2009 19:01:32 +0100
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <4B1FE4A1.5020303@voidspace.org.uk>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>
	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
	<4B1FE4A1.5020303@voidspace.org.uk>
Message-ID: <319e029f0912091001w1b62dde7g8f1f91a53ee00e19@mail.gmail.com>

On Wed, Dec 9, 2009 at 18:55, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
> That may or may not be possible (it certainly sounds like a good change).
> You still haven't told us what change it is that breaks things

There are many changes, and it's already clear from the responses here
that people consider most of them improvements, and the case of
testing testrunners is special enough that I already can feel that
nobody is going to care, so I'm not going to spend the hours I'm going
to need to document the changes, it seems a waste of time. I suspect
zope.testing just won't be tested on Python 2.7. Let's hope it
continues to work on it. :)

But changes in the exception format will affect everyone using
doctests, so that's more serious, and will need to be handled. If we
can get a similar change into 3.2 so we can handle the exception
format changes between 2.6 and 3.x that would be an added bonus.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From exarkun at twistedmatrix.com  Wed Dec  9 19:02:41 2009
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Wed, 09 Dec 2009 18:02:41 -0000
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <319e029f0912090911u2e64e957mb18319d95f147d58@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<4B1FD18C.2080107@voidspace.org.uk>
	<319e029f0912090911u2e64e957mb18319d95f147d58@mail.gmail.com>
Message-ID: <20091209180241.2549.1139656274.divmod.xquotient.585@localhost.localdomain>

On 05:11 pm, lregebro at jarn.com wrote:
>On Wed, Dec 9, 2009 at 17:34, Michael Foord <fuzzyman at voidspace.org.uk> 
>wrote:
>>Can you be more specific?
>
>Only with an insane amount of work. I'll hold that off for a while.

I don't know if this is related at all (and I guess we won't until 
Lennart can be more specific :), but here are some Twisted unit test 
failures which are probably due to unittest changes in 2.7:

===============================================================================
[FAIL]: twisted.trial.test.test_loader.LoaderTest.test_sortCases

Traceback (most recent call last):
  File 
"/home/buildslave/pybot/trunk.glass-x86/build/Twisted/twisted/trial/test/test_loader.py", 
line 167, in test_sortCases
    [test._testMethodName for test in suite._tests])
twisted.trial.unittest.FailTest: not equal:
a = ['test_b', 'test_c', 'test_a']
b = ['test_c', 'test_b', 'test_a']

===============================================================================
[FAIL]: twisted.trial.test.test_loader.ZipLoadingTest.test_sortCases

Traceback (most recent call last):
  File 
"/home/buildslave/pybot/trunk.glass-x86/build/Twisted/twisted/trial/test/test_loader.py", 
line 167, in test_sortCases
    [test._testMethodName for test in suite._tests])
twisted.trial.unittest.FailTest: not equal:
a = ['test_b', 'test_c', 'test_a']
b = ['test_c', 'test_b', 'test_a']

===============================================================================
[FAIL]: twisted.trial.test.test_tests.TestSkipMethods.test_reasons

Traceback (most recent call last):
  File 
"/home/buildslave/pybot/trunk.glass-x86/build/Twisted/twisted/trial/test/test_tests.py", 
line 143, in test_reasons
    str(reason))
twisted.trial.unittest.FailTest: not equal:
a = 'skip1 (twisted.trial.test.test_tests.SkippingTests)'
b = 'skip1'

===============================================================================
[FAIL]: twisted.trial.test.test_class.AttributeSharing.test_shared

Traceback (most recent call last):
  File 
"/home/buildslave/pybot/trunk.glass-x86/build/Twisted/twisted/trial/test/test_class.py", 
line 131, in test_shared
    'test_2')
twisted.trial.unittest.FailTest: not equal:
a = 'test_2 (twisted.trial.test.test_class.ClassAttributeSharer)'
b = 'test_2'

===============================================================================

I'm not opposed to the improvement of unittest (or any part of Python). 
Perhaps more of the improvements can be provided in new APIs rather than 
by changing the behavior of existing APIs, though.

Jean-Paul

From lregebro at jarn.com  Wed Dec  9 19:03:38 2009
From: lregebro at jarn.com (Lennart Regebro)
Date: Wed, 9 Dec 2009 19:03:38 +0100
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <20091209175222.563671F9F9B@kimball.webabinitio.net>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>
	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
	<20091209175222.563671F9F9B@kimball.webabinitio.net>
Message-ID: <319e029f0912091003g4fa1dda9u51f5c95980b77039@mail.gmail.com>

On Wed, Dec 9, 2009 at 18:52, R. David Murray <rdmurray at bitdance.com> wrote:
> In what way is the doctest ellipsis support not sufficient for this
> case?

For 2.7 it's probably going to work, as the changes there (from what I
can see amongst the massive failures I get in zope.testing) is that
there is a couple of lines extra. In 3.x though the format changes
from

    AnException:

to

   themodule.AnException:

and it seems ellipsis can't handle that case. At least it doesn't work for me.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From fuzzyman at voidspace.org.uk  Wed Dec  9 19:09:26 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 09 Dec 2009 18:09:26 +0000
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <20091209180241.2549.1139656274.divmod.xquotient.585@localhost.localdomain>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>	<4B1FD18C.2080107@voidspace.org.uk>	<319e029f0912090911u2e64e957mb18319d95f147d58@mail.gmail.com>
	<20091209180241.2549.1139656274.divmod.xquotient.585@localhost.localdomain>
Message-ID: <4B1FE7D6.7020803@voidspace.org.uk>

On 09/12/2009 18:02, exarkun at twistedmatrix.com wrote:
> On 05:11 pm, lregebro at jarn.com wrote:
>> On Wed, Dec 9, 2009 at 17:34, Michael Foord 
>> <fuzzyman at voidspace.org.uk> wrote:
>>> Can you be more specific?
>>
>> Only with an insane amount of work. I'll hold that off for a while.
>
> I don't know if this is related at all (and I guess we won't until 
> Lennart can be more specific :), but here are some Twisted unit test 
> failures which are probably due to unittest changes in 2.7:
>
> =============================================================================== 
>
> [FAIL]: twisted.trial.test.test_loader.LoaderTest.test_sortCases
>
> Traceback (most recent call last):
>  File 
> "/home/buildslave/pybot/trunk.glass-x86/build/Twisted/twisted/trial/test/test_loader.py", 
> line 167, in test_sortCases
>    [test._testMethodName for test in suite._tests])
> twisted.trial.unittest.FailTest: not equal:
> a = ['test_b', 'test_c', 'test_a']
> b = ['test_c', 'test_b', 'test_a']
>

Is the order significant? Can you just compare sorted versions of the 
lists instead?

If the order *is* significant I would be interested to know which change 
caused this.

> =============================================================================== 
>
> [FAIL]: twisted.trial.test.test_loader.ZipLoadingTest.test_sortCases
>
> Traceback (most recent call last):
>  File 
> "/home/buildslave/pybot/trunk.glass-x86/build/Twisted/twisted/trial/test/test_loader.py", 
> line 167, in test_sortCases
>    [test._testMethodName for test in suite._tests])
> twisted.trial.unittest.FailTest: not equal:
> a = ['test_b', 'test_c', 'test_a']
> b = ['test_c', 'test_b', 'test_a']

Ditto.

>
> =============================================================================== 
>
> [FAIL]: twisted.trial.test.test_tests.TestSkipMethods.test_reasons
>
> Traceback (most recent call last):
>  File 
> "/home/buildslave/pybot/trunk.glass-x86/build/Twisted/twisted/trial/test/test_tests.py", 
> line 143, in test_reasons
>    str(reason))
> twisted.trial.unittest.FailTest: not equal:
> a = 'skip1 (twisted.trial.test.test_tests.SkippingTests)'
> b = 'skip1'
>
> =============================================================================== 
>
> [FAIL]: twisted.trial.test.test_class.AttributeSharing.test_shared
>
> Traceback (most recent call last):
>  File 
> "/home/buildslave/pybot/trunk.glass-x86/build/Twisted/twisted/trial/test/test_class.py", 
> line 131, in test_shared
>    'test_2')
> twisted.trial.unittest.FailTest: not equal:
> a = 'test_2 (twisted.trial.test.test_class.ClassAttributeSharer)'
> b = 'test_2'
>

These two test failures are due to the change in repr of something I 
guess? Is a or b the original output?


> =============================================================================== 
>
>
> I'm not opposed to the improvement of unittest (or any part of 
> Python). Perhaps more of the improvements can be provided in new APIs 
> rather than by changing the behavior of existing APIs, though.

Well, introducing lots of new APIs has its own problems of course. 
Hearing about difficulties changes cause is good though (the reason for 
alphas I guess) and if it is possible to work out why things are broken 
then maybe we can still have the new functionality without the breakage.

The problem with Lennart's report is that it is just "things are broken" 
without much clue. I am sympathetic to this (working out *exactly* what 
is broken in someone else's code can be a painful chore) but I'm not 
sure what can be done about it without more detail.

All the best,

Michael

>
> Jean-Paul


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog



From fdrake at acm.org  Wed Dec  9 19:10:01 2009
From: fdrake at acm.org (Fred Drake)
Date: Wed, 9 Dec 2009 13:10:01 -0500
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com> 
	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com> 
	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com> 
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
Message-ID: <9cee7ab80912091010k7ccabbfekadbbd3212a02f964@mail.gmail.com>

On Wed, Dec 9, 2009 at 12:23 PM, Lennart Regebro <lregebro at jarn.com> wrote:
> You remember which one?

Sorry, that was several months back.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller

From solipsis at pitrou.net  Wed Dec  9 19:17:29 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Wed, 9 Dec 2009 18:17:29 +0000 (UTC)
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<4B1FD18C.2080107@voidspace.org.uk>
	<319e029f0912090911u2e64e957mb18319d95f147d58@mail.gmail.com>
	<20091209180241.2549.1139656274.divmod.xquotient.585@localhost.localdomain>
Message-ID: <loom.20091209T191558-268@post.gmane.org>

<exarkun <at> twistedmatrix.com> writes:
> 
> I don't know if this is related at all (and I guess we won't until 
> Lennart can be more specific :), but here are some Twisted unit test 
> failures which are probably due to unittest changes in 2.7:

You should do a specific diagnosis for each of these failures, and perhaps post
issues on the tracker. It's not obvious to me that they are due to significant
unittest changes rather than, say, text formatting details or even a
misunderstanding about how the APIs work.

Regards

Antoine.



From olemis at gmail.com  Wed Dec  9 19:40:29 2009
From: olemis at gmail.com (Olemis Lang)
Date: Wed, 9 Dec 2009 13:40:29 -0500
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>
	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
	<b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com>
Message-ID: <24ea26600912091040y75f7f60cnee2bd0a8509b26b3@mail.gmail.com>

On Wed, Dec 9, 2009 at 12:45 PM, Ian Bicking <ianb at colorstudy.com> wrote:
> On Wed, Dec 9, 2009 at 11:23 AM, Lennart Regebro <lregebro at jarn.com> wrote:
>>
>> > Evolving the tests to avoid depending on these sorts of implementation
>> > details is reasonable, IMO, and cuold even be considered a bugfix by
>> > the Zope community.
>>
>> Evolving doctest.py so it can handle this by itself would be
>> considered a bugfix by me. :)
>
> It's about time doctest got another run of development anyway.

+1 ... that's why I implemented `dutest` BTW (I wanted more out of doctest ;o)

> I can
> imagine a couple features that might help:
>
> * Already in there, but sometimes hard to enable, is ellipsis. ?Can you
> already do this?
>
> ?? ?>>>?throw_an_exception()
> ?? ?Traceback (most recent call last):
> ?? ? ? ?...
> ?? ?DesiredException: ...
>

Probably useful ... unless /me want to match something inside the
error message (which seems very hard to specify if error messages
change from time to time )

> I'd like to see doctests be able to enable the ELLIPSIS option internally
> and globally (currently it can only be enabled outside the doctest, or for a
> single line).
>

Depending on what you mean when you mention ?internally and globally?
, you could do such kinds of things with `dutest` too

> * Another option might be something version-specific, like:
> ?? ?>>> throw_an_exception() # +python<2.7
> ?? ?... old exception ...
> ?? ?>>> throw_an_exception() # +python>=2.7
> ?? ?... new exception ...

You mean skip LOCs if python version is not ?compatible? with the one
specified in the doctests (e.g. # +python>=2.7) ?

> Maybe for instance "# py_version(less=2.7)"
>
[...]
>
> Or, maybe checkers could be extended so they could actually
> suppress the execution of code (avoiding throw_an_exception() from being
> called twice).

Ah ! Just what I thought !

IMO that choice should be made explicit in the test code but once
again doctest does not support something like

{{{
>>> if sys.version_info[:3] <= (2, 7) :
...           throw_an_exception()
?<old exception>
... else :
...           throw_an_exception() # +python>=2.7
...
?<new exception>
}}}

I'd definitely prefer something like that or like what you've
mentioned before (i.e. # +python<2.7)
but the idea needs to be refined ;o)

To be more explicit, the main limitation is that you cannot make
assertions for individual statements inside blocks (e.g. if, for ,
...) mainly because that's not how interactive sessions look like

;o)

> * Maybe slightly more general, would be the ability to extend OutputCheckers
> more easily than currently.

You can definitely play with these kind of things (e.g. change
OutputCheckers at runtime ;o) by using `dutest`  ;o)

> * Or, something more explicit than ELLIPSIS but able also be more flexible
> than currently possible, like:
> ?? ?>>> throw_an_exception()
> ?? ?Traceback (most recent call last):
> ?? ? ? ?...
> ?? ?DesiredException: [[2.6 error message | 2.7 error message]]

IMO, this would be limited to be used only with tracebacks, and
ellipsis are more general than that (match against anything) My
preferences above.

PS: Sorry for the commercials . I'm just mentioning that there's
something out there that enhances doctest to support some features you
mentioned , that was proposed some time ago to be included in stdlib
[3]_ and (at least in theory) is waiting for assessment &| approval .
That time the main stopper was its recent release [1]_ , now it has
about (184 + 60 + 117 = 361 downloads from PyPI ;o) [2]_ ...

.. [3] [Python-Dev] An OO API for doctest / unittest integration...
        (http://mail.python.org/pipermail/python-dev/2008-August/081761.html)

.. [1] [Python-Dev] An OO API for doctest / unittest integration...
        (http://mail.python.org/pipermail/python-dev/2008-August/081762.html)

.. [2] Download dutest @ PyPI
        (http://pypi.python.org/pypi/dutest)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Depurando errores en aplicaciones web CGI con Python  -
http://feedproxy.google.com/~r/simelo-es/~3/xxyDHHH1YZ8/depurando-errores-en-aplicaciones-web.html

From greg.ewing at canterbury.ac.nz  Wed Dec  9 23:00:47 2009
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 10 Dec 2009 11:00:47 +1300
Subject: [Python-Dev] recursive closures - reference cycle
In-Reply-To: <930F189C8A437347B80DF2C156F7EC7F0990675504@exchis.ccp.ad.local>
References: <930F189C8A437347B80DF2C156F7EC7F09906751C4@exchis.ccp.ad.local>
	<loom.20091208T153516-777@post.gmane.org>
	<930F189C8A437347B80DF2C156F7EC7F09906752CF@exchis.ccp.ad.local>
	<4B1ECE6A.6090005@canterbury.ac.nz>
	<930F189C8A437347B80DF2C156F7EC7F0990675504@exchis.ccp.ad.local>
Message-ID: <4B201E0F.6000006@canterbury.ac.nz>

Kristj?n Valur J?nsson wrote:

> Yes, and a number of different workarounds.  That's not really the issue.  The issue is that what looks like a perfectly safe idiom (calling a function recursively) happens to create a reference cycle if that function is a closure.
> This is a non-obvious "gotcha" that I must now educate my team about.

Documentation seems to be about the only thing that can be
done about this. Recursion inherently involve self-reference,
and that's going to create reference cycles somewhere,
somehow.

You get a reference cycle with top-level recursion too, the
only difference is that just one cycle is created when the
module is imported, rather than one every time you call
the function.

This is only a problem if you care about avoiding cycles,
and if you do, this is just one of many subtle ways of creating
them.

It's hard to tell where abouts in the docs to put information
about this, however. It really relates to a certain
pattern of using language features rather than to any
particular feature.

Maybe there should be a section devoted to avoidance of
reference cycles where all of these known pitfalls can be
pointed out.

-- 
Greg

From martin at v.loewis.de  Wed Dec  9 23:37:11 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 09 Dec 2009 23:37:11 +0100
Subject: [Python-Dev] recursive closures - reference cycle
In-Reply-To: <930F189C8A437347B80DF2C156F7EC7F0990675504@exchis.ccp.ad.local>
References: <930F189C8A437347B80DF2C156F7EC7F09906751C4@exchis.ccp.ad.local>	<loom.20091208T153516-777@post.gmane.org>	<930F189C8A437347B80DF2C156F7EC7F09906752CF@exchis.ccp.ad.local>	<4B1ECE6A.6090005@canterbury.ac.nz>
	<930F189C8A437347B80DF2C156F7EC7F0990675504@exchis.ccp.ad.local>
Message-ID: <4B202697.5010103@v.loewis.de>

> Yes, and a number of different workarounds.  That's not really the
> issue.  The issue is that what looks like a perfectly safe idiom
> (calling a function recursively) happens to create a reference cycle
> if that function is a closure. This is a non-obvious "gotcha" that I
> must now educate my team about.

I'm not sure why you call that non-obvious. As Antoine(?) pointed
out, *any* recursive function calls a reference cycle, and that is
not surprising, because the function refers to itself, so the function
definition is *obviously* cyclic (i.e. from within the function body,
you can get back to the function object).

I know you dismissed the global function example as non-relevant,
because the cycle is through the globals dictionary (i.e. any global
function is in a cycle, whether it is recursive or not), and because
it is possible to break the cycle (by deleting the function from the
globals). However, that's beside the point, because
a) it is an optimization that closures are only cyclic when they
   need to be (i.e. a nested function only keeps references to those
   name bindings that are mentioned in its body, rather than referencing
   the entire closure), and
b) it is also possible to break the cycle in the closure case, by
   setting the cell target to None (say), and
c) the actual problem that you are having is not that the nested
   functions create cycles, but that you get a fresh one every time
   you call the outer function (so that you get the impression of
   a memory leak).

> Note that at least parts of the library strive to avoid reference
> cycles even though "gc" exists.  An example being
> xlm.minidom.Document.unlink()

That doesn't avoid reference cycles. Instead, it helps breaking them
(as a minidom tree *is* cyclic). minidom has this explicit API for
breaking cycles because it predated the introduction of cyclic GC
in Python.

Regards,
Martin

From p.f.moore at gmail.com  Thu Dec 10 00:47:37 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 9 Dec 2009 23:47:37 +0000
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>
	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
	<b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com>
	<319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com>
Message-ID: <79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com>

2009/12/9 Lennart Regebro <lregebro at jarn.com>:
> On Wed, Dec 9, 2009 at 18:45, Ian Bicking <ianb at colorstudy.com> wrote:
>> It's about time doctest got another run of development anyway. ?I can
>> imagine a couple features that might help:
>> * Already in there, but sometimes hard to enable, is ellipsis. ?Can you
>> already do this?
>>
>> ?? ?>>>?throw_an_exception()
>> ?? ?Traceback (most recent call last):
>> ?? ? ? ?...
>> ?? ?DesiredException: ...
>
> I think so, but what you need is:
>
>> ? ? >>> throw_an_exception()
>> ? ? Traceback (most recent call last):
>> ? ? ? ? ...
>> ? ?...DesiredException: ...

No you don't. From the manual:

"""
When the IGNORE_EXCEPTION_DETAIL doctest option is is specified,
everything following the leftmost colon is ignored.
"""

So just use #doctest: +IGNORE_EXCEPTION_DETAIL

Paul.

From ianb at colorstudy.com  Thu Dec 10 00:49:20 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Wed, 9 Dec 2009 17:49:20 -0600
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com> 
	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com> 
	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com> 
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com> 
	<b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com> 
	<319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com> 
	<79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com>
Message-ID: <b654cd2e0912091549x6121dd18ieb2b53672430eed8@mail.gmail.com>

On Wed, Dec 9, 2009 at 5:47 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> 2009/12/9 Lennart Regebro <lregebro at jarn.com>:
>> On Wed, Dec 9, 2009 at 18:45, Ian Bicking <ianb at colorstudy.com> wrote:
>>> It's about time doctest got another run of development anyway. ?I can
>>> imagine a couple features that might help:
>>> * Already in there, but sometimes hard to enable, is ellipsis. ?Can you
>>> already do this?
>>>
>>> ?? ?>>>?throw_an_exception()
>>> ?? ?Traceback (most recent call last):
>>> ?? ? ? ?...
>>> ?? ?DesiredException: ...
>>
>> I think so, but what you need is:
>>
>>> ? ? >>> throw_an_exception()
>>> ? ? Traceback (most recent call last):
>>> ? ? ? ? ...
>>> ? ?...DesiredException: ...
>
> No you don't. From the manual:
>
> """
> When the IGNORE_EXCEPTION_DETAIL doctest option is is specified,
> everything following the leftmost colon is ignored.
> """
>
> So just use #doctest: +IGNORE_EXCEPTION_DETAIL

Maybe that could be extended to also ignore everything up to a period
(i.e., ignore the module name that seems to show up in 2.7 exception
names, but not in previous versions).


-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker

From cybersol at yahoo.com  Thu Dec 10 06:41:01 2009
From: cybersol at yahoo.com (Michael Mysinger)
Date: Thu, 10 Dec 2009 05:41:01 +0000 (UTC)
Subject: [Python-Dev] Proposing PEP 386 for addition
References: <772583.98842.qm@web55501.mail.re4.yahoo.com>
	<20091209122136.GA19650@laurie.devork>
Message-ID: <loom.20091210T061530-869@post.gmane.org>

Floris Bruynooghe <floris.bruynooghe <at> gmail.com> writes:

> On Tue, Dec 08, 2009 at 08:53:18PM -0800, Michael Mysinger wrote:
> > I don't know what notation this versioning schema was trying for, especially
in regards to what the +'s mean:
> > N.N[.N]+[abc]N[.N]+[.postN+][.devN+]
> > 
> The full regex (stripped from named groups) is the rather unreadable:
> \d+\.\d+(\.\d+)*([abc]?\d+(\.\d+)*)?((\.post\d+)?(\.dev\d+)?)?

The ()? around the combination of post and dev is not needed. I also think
[abc]? should just be [abc], as one letter is required to proceed the digit in
that case, and the full regular expression does help to distinguish exactly
which of those two is required by the PEP. 

> So the '+' in the pseudo notation above roughly means "one or more"
> with the brackets meaning "zero or one" so plus and brackets combined
> result into "zero or more".  But even then it's might be missing
> square brackets around the whole of "[abc]N[.N]+".

What is confusing about the +'s is that they are not consistent. If your regular
expression with my modifications above is right, then using the substitions 'N
for \d+', '{} for []', '[] for ()?' and '+ for *' leaves:

N.N[.N]+[{abc}N[.N]+][.postN][.devN]

Notice that the last two +'s are gone, and overall I think this is more
consistent psuedo-code.   
 
> Note that the meaning of the contents of the brackets changes too
> ("abc" is a choice, .postN+ is the recursive notation) so it'll
> probably never work exactly.  So maybe the PEP should also include the
> full regex for exactness.
> 
> Regards
> Floris

Yes, it probably should have the full regex for absolute clarity, and it can
still have some type of psuedo-code for easier reading, but inconsistent
psuedo-code just adds confusion instead of simplification.

Cheers,
Michael



From lregebro at jarn.com  Thu Dec 10 09:32:38 2009
From: lregebro at jarn.com (Lennart Regebro)
Date: Thu, 10 Dec 2009 09:32:38 +0100
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>
	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
	<b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com>
	<319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com>
	<79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com>
Message-ID: <319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com>

On Thu, Dec 10, 2009 at 00:47, Paul Moore <p.f.moore at gmail.com> wrote:
>> I think so, but what you need is:
>>
>>> ? ? >>> throw_an_exception()
>>> ? ? Traceback (most recent call last):
>>> ? ? ? ? ...
>>> ? ?...DesiredException: ...
>
> No you don't. From the manual:
>
> """
> When the IGNORE_EXCEPTION_DETAIL doctest option is is specified,
> everything following the leftmost colon is ignored.
> """

Note that the difference is *before* the leftmost colon.

On Thu, Dec 10, 2009 at 00:49, Ian Bicking <ianb at colorstudy.com> wrote:
> Maybe that could be extended to also ignore everything up to a period
> (i.e., ignore the module name that seems to show up in 2.7 exception
> names, but not in previous versions).

That sounds good to me.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From mborch at gmail.com  Thu Dec 10 09:44:01 2009
From: mborch at gmail.com (Malthe Borch)
Date: Thu, 10 Dec 2009 09:44:01 +0100
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
Message-ID: <4B20B4D1.10502@gmail.com>

On 12/8/09 6:16 PM, Tarek Ziad? wrote:
> I believe that the current situation is as close to consensus as we
> will get on distutils-sig, and in the interests of avoiding months of
> further discussion which won't take things any further, I propose to
> allow final comments from python-dev and then look for a final
> decision.

Great work, Tarek. I think you've managed to establish a good body of 
knowledge on this and the proposal seems sound.

That said, I think the terms ``LooseVersion`` and ``StrictVersion`` are 
less than optimal. Really, what's meant is ``LexicalVersion`` and 
``ChronologicalVersion`` (or ``NumberedVersion``). It's not about 
strictness or looseness.

Also, the word "rational" is not familiar to me in the context of 
versions; is this term known outside of this proposal? I couldn't find 
any reference to it.

\malthe


From floris.bruynooghe at gmail.com  Thu Dec 10 10:44:35 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Thu, 10 Dec 2009 09:44:35 +0000
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <loom.20091210T061530-869@post.gmane.org>
References: <772583.98842.qm@web55501.mail.re4.yahoo.com>
	<20091209122136.GA19650@laurie.devork>
	<loom.20091210T061530-869@post.gmane.org>
Message-ID: <20091210094435.GA23831@laurie.devork>

On Thu, Dec 10, 2009 at 05:41:01AM +0000, Michael Mysinger wrote:
> Floris Bruynooghe <floris.bruynooghe <at> gmail.com> writes:
> 
> > On Tue, Dec 08, 2009 at 08:53:18PM -0800, Michael Mysinger wrote:
> > > I don't know what notation this versioning schema was trying for, especially
> in regards to what the +'s mean:
> > > N.N[.N]+[abc]N[.N]+[.postN+][.devN+]
> > > 
> > The full regex (stripped from named groups) is the rather unreadable:
> > \d+\.\d+(\.\d+)*([abc]?\d+(\.\d+)*)?((\.post\d+)?(\.dev\d+)?)?
> 
> The ()? around the combination of post and dev is not needed. I also think
> [abc]? should just be [abc], as one letter is required to proceed the digit in
> that case, and the full regular expression does help to distinguish exactly
> which of those two is required by the PEP. 

You are right

> If your regular expression with my modifications above is right,
> then using the substitions 'N for \d+', '{} for []', '[] for ()?'
> and '+ for *' leaves:
> 
> N.N[.N]+[{abc}N[.N]+][.postN][.devN]
> 
> Notice that the last two +'s are gone, and overall I think this is more
> consistent psuedo-code.

That's quite readable and more consistent then the original
pseudo-code, I like it.


Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From ssteinerx at gmail.com  Thu Dec 10 13:24:06 2009
From: ssteinerx at gmail.com (ssteinerX@gmail.com)
Date: Thu, 10 Dec 2009 07:24:06 -0500
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <4B20B4D1.10502@gmail.com>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<4B20B4D1.10502@gmail.com>
Message-ID: <B23BD94C-1D88-4C4A-88A7-2179F1056EAC@gmail.com>


On Dec 10, 2009, at 3:44 AM, Malthe Borch wrote:

> On 12/8/09 6:16 PM, Tarek Ziad? wrote:
>> I believe that the current situation is as close to consensus as we
>> will get on distutils-sig, and in the interests of avoiding months of
>> further discussion which won't take things any further, I propose to
>> allow final comments from python-dev and then look for a final
>> decision.
> 
> Great work, Tarek. I think you've managed to establish a good body of knowledge on this and the proposal seems sound.
> 
> That said, I think the terms ``LooseVersion`` and ``StrictVersion`` are less than optimal. Really, what's meant is ``LexicalVersion`` and ``ChronologicalVersion`` (or ``NumberedVersion``). It's not about strictness or looseness.

I agree about the impreciseness of these terms.  I'm not sure what the correct terminology is...

> Also, the word "rational" is not familiar to me in the context of versions; is this term known outside of this proposal? I couldn't find any reference to it.

No, it's a made-up use.  I'm not sure if there's some "standard" terminology for referring to versioning schemes...

S


From dsdale24 at gmail.com  Thu Dec 10 13:40:06 2009
From: dsdale24 at gmail.com (Darren Dale)
Date: Thu, 10 Dec 2009 07:40:06 -0500
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <B23BD94C-1D88-4C4A-88A7-2179F1056EAC@gmail.com>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<4B20B4D1.10502@gmail.com>
	<B23BD94C-1D88-4C4A-88A7-2179F1056EAC@gmail.com>
Message-ID: <a08e5f80912100440l4738b078u61f075e50889c612@mail.gmail.com>

On Thu, Dec 10, 2009 at 7:24 AM, ssteinerX at gmail.com
<ssteinerx at gmail.com> wrote:
>
> On Dec 10, 2009, at 3:44 AM, Malthe Borch wrote:
>
>> On 12/8/09 6:16 PM, Tarek Ziad? wrote:
>>> I believe that the current situation is as close to consensus as we
>>> will get on distutils-sig, and in the interests of avoiding months of
>>> further discussion which won't take things any further, I propose to
>>> allow final comments from python-dev and then look for a final
>>> decision.
>>
>> Great work, Tarek. I think you've managed to establish a good body of knowledge on this and the proposal seems sound.
>>
>> That said, I think the terms ``LooseVersion`` and ``StrictVersion`` are less than optimal. Really, what's meant is ``LexicalVersion`` and ``ChronologicalVersion`` (or ``NumberedVersion``). It's not about strictness or looseness.
>
> I agree about the impreciseness of these terms. ?I'm not sure what the correct terminology is...

Those aren't new proposals, though, they already exist in distutils.

Darren

From mborch at gmail.com  Thu Dec 10 13:43:39 2009
From: mborch at gmail.com (Malthe Borch)
Date: Thu, 10 Dec 2009 13:43:39 +0100
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <a08e5f80912100440l4738b078u61f075e50889c612@mail.gmail.com>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<4B20B4D1.10502@gmail.com>
	<B23BD94C-1D88-4C4A-88A7-2179F1056EAC@gmail.com>
	<a08e5f80912100440l4738b078u61f075e50889c612@mail.gmail.com>
Message-ID: <c66fb64e0912100443x74dabe0l2a932ff4c6dbca18@mail.gmail.com>

2009/12/10 Darren Dale <dsdale24 at gmail.com>:
> Those aren't new proposals, though, they already exist in distutils.

I see. Thanks for clarifying ???maybe the PEP should better explain this.

\malthe

From ziade.tarek at gmail.com  Thu Dec 10 14:15:22 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 10 Dec 2009 14:15:22 +0100
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <772583.98842.qm@web55501.mail.re4.yahoo.com>
References: <772583.98842.qm@web55501.mail.re4.yahoo.com>
Message-ID: <94bdd2610912100515s7b1c9035s1ecb824b5e71605e@mail.gmail.com>

On Wed, Dec 9, 2009 at 5:53 AM, Michael Mysinger <cybersol at yahoo.com> wrote:
> More English language fixes:

I have just applied them. Thanks.

Tarek

From dsdale24 at gmail.com  Thu Dec 10 14:16:08 2009
From: dsdale24 at gmail.com (Darren Dale)
Date: Thu, 10 Dec 2009 08:16:08 -0500
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <c66fb64e0912100443x74dabe0l2a932ff4c6dbca18@mail.gmail.com>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<4B20B4D1.10502@gmail.com>
	<B23BD94C-1D88-4C4A-88A7-2179F1056EAC@gmail.com>
	<a08e5f80912100440l4738b078u61f075e50889c612@mail.gmail.com>
	<c66fb64e0912100443x74dabe0l2a932ff4c6dbca18@mail.gmail.com>
Message-ID: <a08e5f80912100516r71d753echb4460384a319a2a7@mail.gmail.com>

On Thu, Dec 10, 2009 at 7:43 AM, Malthe Borch <mborch at gmail.com> wrote:
> 2009/12/10 Darren Dale <dsdale24 at gmail.com>:
>> Those aren't new proposals, though, they already exist in distutils.
>
> I see. Thanks for clarifying ???maybe the PEP should better explain this.

It is already pretty clear:

"Distutils currently provides a StrictVersion and a LooseVersion class
that can be used to manage versions."

Darren

From ziade.tarek at gmail.com  Thu Dec 10 14:19:26 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 10 Dec 2009 14:19:26 +0100
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <4B20B4D1.10502@gmail.com>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<4B20B4D1.10502@gmail.com>
Message-ID: <94bdd2610912100519n43614c84n63c37794ec8f5d7b@mail.gmail.com>

On Thu, Dec 10, 2009 at 9:44 AM, Malthe Borch <mborch at gmail.com> wrote:
[..]
> Great work, Tarek. I think you've managed to establish a good body of
> knowledge on this and the proposal seems sound.

Thanks :)

>
> That said, I think the terms ``LooseVersion`` and ``StrictVersion`` are less
> than optimal. Really, what's meant is ``LexicalVersion`` and
> ``ChronologicalVersion`` (or ``NumberedVersion``). It's not about strictness
> or looseness.

I've added a note explaining that these exists since years in
Distutils, for clarity.

> Also, the word "rational" is not familiar to me in the context of versions;
> is this term known outside of this proposal? I couldn't find any reference
> to it.

Do you have a better suggestion ? I was thinking about StandardVersion
but "Standard"
doesn't really express what we want to achieve here I think,

Regards,
Tarek

From ziade.tarek at gmail.com  Thu Dec 10 14:20:44 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 10 Dec 2009 14:20:44 +0100
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <20091210094435.GA23831@laurie.devork>
References: <772583.98842.qm@web55501.mail.re4.yahoo.com>
	<20091209122136.GA19650@laurie.devork>
	<loom.20091210T061530-869@post.gmane.org>
	<20091210094435.GA23831@laurie.devork>
Message-ID: <94bdd2610912100520s6e2c6222ua890ce09cea2e79d@mail.gmail.com>

On Thu, Dec 10, 2009 at 10:44 AM, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:
[..]
>> N.N[.N]+[{abc}N[.N]+][.postN][.devN]
>>
>> Notice that the last two +'s are gone, and overall I think this is more
>> consistent psuedo-code.
>
> That's quite readable and more consistent then the original
> pseudo-code, I like it.

Thanks, I have applied it. I have also added the full regular
expression in the PEP so things are clearer.

Regards,
Tarek

From eric at trueblade.com  Thu Dec 10 14:42:21 2009
From: eric at trueblade.com (Eric Smith)
Date: Thu, 10 Dec 2009 08:42:21 -0500
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <94bdd2610912100519n43614c84n63c37794ec8f5d7b@mail.gmail.com>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>	<4B20B4D1.10502@gmail.com>
	<94bdd2610912100519n43614c84n63c37794ec8f5d7b@mail.gmail.com>
Message-ID: <4B20FABD.4010508@trueblade.com>

Tarek Ziad? wrote:
>> Also, the word "rational" is not familiar to me in the context of versions;
>> is this term known outside of this proposal? I couldn't find any reference
>> to it.
> 
> Do you have a better suggestion ? I was thinking about StandardVersion
> but "Standard"
> doesn't really express what we want to achieve here I think,

NormalizedVersion?

From solipsis at pitrou.net  Thu Dec 10 14:54:51 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Thu, 10 Dec 2009 13:54:51 +0000 (UTC)
Subject: [Python-Dev] Proposing PEP 386 for addition
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<4B20B4D1.10502@gmail.com>
	<94bdd2610912100519n43614c84n63c37794ec8f5d7b@mail.gmail.com>
Message-ID: <loom.20091210T145433-494@post.gmane.org>

Tarek Ziad? <ziade.tarek <at> gmail.com> writes:
> 
> Do you have a better suggestion ? I was thinking about StandardVersion
> but "Standard"
> doesn't really express what we want to achieve here I think,

I think StandardVersion is fine.



From dsdale24 at gmail.com  Thu Dec 10 15:10:49 2009
From: dsdale24 at gmail.com (Darren Dale)
Date: Thu, 10 Dec 2009 09:10:49 -0500
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <loom.20091210T145433-494@post.gmane.org>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<4B20B4D1.10502@gmail.com>
	<94bdd2610912100519n43614c84n63c37794ec8f5d7b@mail.gmail.com>
	<loom.20091210T145433-494@post.gmane.org>
Message-ID: <a08e5f80912100610l48312c5do5b85c7a07376a5d1@mail.gmail.com>

On Thu, Dec 10, 2009 at 8:54 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Tarek Ziad? <ziade.tarek <at> gmail.com> writes:
>>
>> Do you have a better suggestion ? I was thinking about StandardVersion
>> but "Standard"
>> doesn't really express what we want to achieve here I think,
>
> I think StandardVersion is fine.

I prefer StandardVersion as well. Rational (according to websters.com):

1.	agreeable to reason; reasonable; sensible: a rational plan for
economic development.
2.	having or exercising reason, sound judgment, or good sense: a calm
and rational negotiator.

Standard (according to websters.com):

1.	something considered by an authority or by general consent as a
basis of comparison; an approved model.
2.	an object that is regarded as the usual or most common size or form
of its kind
3.	a rule or principle that is used as a basis for judgment

Darren

From tjreedy at udel.edu  Thu Dec 10 20:25:54 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 10 Dec 2009 14:25:54 -0500
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>	<b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com>	<319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com>	<79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com>
	<319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com>
Message-ID: <hfri00$5js$1@ger.gmane.org>

Lennart Regebro wrote:
> On Thu, Dec 10, 2009 at 00:47, Paul Moore <p.f.moore at gmail.com> wrote:

>> When the IGNORE_EXCEPTION_DETAIL doctest option is is specified,
>> everything following the leftmost colon is ignored.
>> """
> 
> Note that the difference is *before* the leftmost colon.
> 
> On Thu, Dec 10, 2009 at 00:49, Ian Bicking <ianb at colorstudy.com> wrote:
>> Maybe that could be extended to also ignore everything up to a period
>> (i.e., ignore the module name that seems to show up in 2.7 exception
>> names, but not in previous versions).
> 
> That sounds good to me.

Since the intent of IGNORE_EXCEPTION_DETAIL is to make doctests immune 
to implementation version specific changes, it seems to me that 
extending its technical meaning is required to carry out its intent.


From p.f.moore at gmail.com  Thu Dec 10 20:50:52 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Thu, 10 Dec 2009 19:50:52 +0000
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>
	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
	<b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com>
	<319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com>
	<79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com>
	<319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com>
Message-ID: <79990c6b0912101150i6e680784w40b202886678c862@mail.gmail.com>

2009/12/10 Lennart Regebro <lregebro at jarn.com>:
> On Thu, Dec 10, 2009 at 00:47, Paul Moore <p.f.moore at gmail.com> wrote:
>>> I think so, but what you need is:
>>>
>>>> ? ? >>> throw_an_exception()
>>>> ? ? Traceback (most recent call last):
>>>> ? ? ? ? ...
>>>> ? ?...DesiredException: ...
>>
>> No you don't. From the manual:
>>
>> """
>> When the IGNORE_EXCEPTION_DETAIL doctest option is is specified,
>> everything following the leftmost colon is ignored.
>> """
>
> Note that the difference is *before* the leftmost colon.

Ah, sorry. I missed that important point...

Paul.

From regebro at gmail.com  Thu Dec 10 21:19:49 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Thu, 10 Dec 2009 21:19:49 +0100
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <hfri00$5js$1@ger.gmane.org>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>
	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
	<b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com>
	<319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com>
	<79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com>
	<319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com>
	<hfri00$5js$1@ger.gmane.org>
Message-ID: <319e029f0912101219q7f1c730ai7fe12b41f3914bed@mail.gmail.com>

On Thu, Dec 10, 2009 at 20:25, Terry Reedy <tjreedy at udel.edu> wrote:
> Since the intent of IGNORE_EXCEPTION_DETAIL is to make doctests immune to
> implementation version specific changes, it seems to me that extending its
> technical meaning is required to carry out its intent.

Would this be considered bugfixy enough to get into 3.1-branch as well
as 2.7? It really is damn annoying when you try to port doctests to
Python 3, and it would be great if we wouldn't have to wait for 3.2.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From benjamin at python.org  Thu Dec 10 21:24:41 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Thu, 10 Dec 2009 14:24:41 -0600
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <319e029f0912101219q7f1c730ai7fe12b41f3914bed@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>
	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
	<b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com>
	<319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com>
	<79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com>
	<319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com>
	<hfri00$5js$1@ger.gmane.org>
	<319e029f0912101219q7f1c730ai7fe12b41f3914bed@mail.gmail.com>
Message-ID: <1afaf6160912101224i36562613r1462f432d6ae88ed@mail.gmail.com>

2009/12/10 Lennart Regebro <regebro at gmail.com>:
> On Thu, Dec 10, 2009 at 20:25, Terry Reedy <tjreedy at udel.edu> wrote:
>> Since the intent of IGNORE_EXCEPTION_DETAIL is to make doctests immune to
>> implementation version specific changes, it seems to me that extending its
>> technical meaning is required to carry out its intent.
>
> Would this be considered bugfixy enough to get into 3.1-branch as well
> as 2.7? It really is damn annoying when you try to port doctests to
> Python 3, and it would be great if we wouldn't have to wait for 3.2.

I think a patch would be helpful before deciding that.



-- 
Regards,
Benjamin

From ben+python at benfinney.id.au  Fri Dec 11 01:14:16 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 11 Dec 2009 11:14:16 +1100
Subject: [Python-Dev] Proposing PEP 386 for addition
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
Message-ID: <87ocm674fb.fsf@benfinney.id.au>

Tarek Ziad? <ziade.tarek at gmail.com> writes:

> I believe that the current situation is as close to consensus as we
> will get on distutils-sig, and in the interests of avoiding months of
> further discussion which won't take things any further, I propose to
> allow final comments from python-dev and then look for a final
> decision.

I don't see any information in the PEP for alternate proposals that were
made during its drafting. It's customary to explain what alternative
proposals have been advanced, and give the PEP champion's explanation of
why they weren't chosen.

This is, of course, in the interests of forestalling further repetition
of those same discussions.

-- 
 \       ?My business is to teach my aspirations to conform themselves |
  `\              to fact, not to try and make facts harmonise with my |
_o__)                   aspirations.? ?Thomas Henry Huxley, 1860-09-23 |
Ben Finney


From regebro at gmail.com  Fri Dec 11 01:31:47 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 11 Dec 2009 01:31:47 +0100
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <1afaf6160912101224i36562613r1462f432d6ae88ed@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
	<b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com>
	<319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com>
	<79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com>
	<319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com>
	<hfri00$5js$1@ger.gmane.org>
	<319e029f0912101219q7f1c730ai7fe12b41f3914bed@mail.gmail.com>
	<1afaf6160912101224i36562613r1462f432d6ae88ed@mail.gmail.com>
Message-ID: <319e029f0912101631p4e00e006kb26aaba90bf53cdc@mail.gmail.com>

On Thu, Dec 10, 2009 at 21:24, Benjamin Peterson <benjamin at python.org> wrote:
> 2009/12/10 Lennart Regebro <regebro at gmail.com>:
>> On Thu, Dec 10, 2009 at 20:25, Terry Reedy <tjreedy at udel.edu> wrote:
>>> Since the intent of IGNORE_EXCEPTION_DETAIL is to make doctests immune to
>>> implementation version specific changes, it seems to me that extending its
>>> technical meaning is required to carry out its intent.
>>
>> Would this be considered bugfixy enough to get into 3.1-branch as well
>> as 2.7? It really is damn annoying when you try to port doctests to
>> Python 3, and it would be great if we wouldn't have to wait for 3.2.
>
> I think a patch would be helpful before deciding that.

OK, I'll will try to produce that,

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Fri Dec 11 01:49:33 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Dec 2009 01:49:33 +0100
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <87ocm674fb.fsf@benfinney.id.au>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<87ocm674fb.fsf@benfinney.id.au>
Message-ID: <94bdd2610912101649r70ef222btd03ecfb236f2a000@mail.gmail.com>

On Fri, Dec 11, 2009 at 1:14 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
> Tarek Ziad? <ziade.tarek at gmail.com> writes:
>
>> I believe that the current situation is as close to consensus as we
>> will get on distutils-sig, and in the interests of avoiding months of
>> further discussion which won't take things any further, I propose to
>> allow final comments from python-dev and then look for a final
>> decision.
>
> I don't see any information in the PEP for alternate proposals that were
> made during its drafting. It's customary to explain what alternative
> proposals have been advanced, and give the PEP champion's explanation of
> why they weren't chosen.

Since most discussions at the end were about the precise syntax of the
versions schema,
(using "-" instead of ".")  I don't see the point of adding in the PEP
text itself the list of
those proposals, and why each one of them was not kept.

Now by "alternate" if you mean a proposal that is completely different
from what is in the PEP,
I don't recall that we had any viable alternative proposals in the discussions.
By "viable" I mean something that provides what we need : a schema that
allows us to compare final versions, but also development, pre and
post-release versions.

> This is, of course, in the interests of forestalling further repetition
> of those same discussions.

Right, I see what you mean, and I was indeed expecting that some
people were going to ask things that we already talked about at
Distutils-SIG.

My intent if this happens, is to provide very concise answers here,
that correspond to a summary
of what has been said, and if required with some links to some
relevant mails at Distutils-SIG.

IOW, the process should be fairly short here (unless we find out we
are missing a big point somehow in the PEP), so if you do think about
something that should be talked about (e.g. if you think the PEP is
not right for any particular reason), please let's discuss it.

Regards
Tarek

From rdmurray at bitdance.com  Fri Dec 11 04:07:55 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 10 Dec 2009 22:07:55 -0500
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <94bdd2610912101649r70ef222btd03ecfb236f2a000@mail.gmail.com>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<87ocm674fb.fsf@benfinney.id.au>
	<94bdd2610912101649r70ef222btd03ecfb236f2a000@mail.gmail.com>
Message-ID: <20091211030755.928C01FA598@kimball.webabinitio.net>

On Fri, 11 Dec 2009 01:49:33 +0100, =?ISO-8859-1?Q?Tarek_Ziad=E9?= <ziade.tarek at gmail.com> wrote:
> On Fri, Dec 11, 2009 at 1:14 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
> > I don't see any information in the PEP for alternate proposals that were
> > made during its drafting. It's customary to explain what alternative
> > proposals have been advanced, and give the PEP champion's explanation of
> > why they weren't chosen.
[...] 
> > This is, of course, in the interests of forestalling further repetition
> > of those same discussions.
> 
> Right, I see what you mean, and I was indeed expecting that some
> people were going to ask things that we already talked about at
> Distutils-SIG.
> 
> My intent if this happens, is to provide very concise answers here,
> that correspond to a summary of what has been said, and if required
> with some links to some relevant mails at Distutils-SIG.

IMO, if you have to answer here, then it should go into the PEP as
Ben suggests.  If I recall correctly, such summaries in PEPs
often link to the relevant discussion threads.

--David

From ben+python at benfinney.id.au  Fri Dec 11 06:15:15 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 11 Dec 2009 16:15:15 +1100
Subject: [Python-Dev] Proposing PEP 386 for addition
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<87ocm674fb.fsf@benfinney.id.au>
	<94bdd2610912101649r70ef222btd03ecfb236f2a000@mail.gmail.com>
Message-ID: <87tyvy5bx8.fsf@benfinney.id.au>

Tarek Ziad? <ziade.tarek at gmail.com> writes:

> Now by "alternate" if you mean a proposal that is completely different
> from what is in the PEP, I don't recall that we had any viable
> alternative proposals in the discussions. By "viable" I mean something
> that provides what we need : a schema that allows us to compare final
> versions, but also development, pre and post-release versions.

Yes, I'm referring to the discussion that were had over ?why do we want
special keywords that mess with the default alphanumerical ordering of
version string components?? discussion.

That needs to be addressed in the PEP, since it's germane to the
explanation for the PEP's existence.

> > This is, of course, in the interests of forestalling further
> > repetition of those same discussions.
>
> Right, I see what you mean, and I was indeed expecting that some
> people were going to ask things that we already talked about at
> Distutils-SIG.
>
> My intent if this happens, is to provide very concise answers here,

No, the PEP document itself should either contain the questions and
answers, or contain a link to the discussion along with a brief summary
of what it was about and a explicit statement of its outcome.

-- 
 \         ?I think there is a world market for maybe five computers.? |
  `\                             ?Thomas Watson, chairman of IBM, 1943 |
_o__)                                                                  |
Ben Finney


From ncoghlan at gmail.com  Fri Dec 11 11:23:36 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 11 Dec 2009 20:23:36 +1000
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <a08e5f80912100610l48312c5do5b85c7a07376a5d1@mail.gmail.com>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>	<4B20B4D1.10502@gmail.com>	<94bdd2610912100519n43614c84n63c37794ec8f5d7b@mail.gmail.com>	<loom.20091210T145433-494@post.gmane.org>
	<a08e5f80912100610l48312c5do5b85c7a07376a5d1@mail.gmail.com>
Message-ID: <4B221DA8.5060509@gmail.com>

Darren Dale wrote:
> On Thu, Dec 10, 2009 at 8:54 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> Tarek Ziad? <ziade.tarek <at> gmail.com> writes:
>>> Do you have a better suggestion ? I was thinking about StandardVersion
>>> but "Standard"
>>> doesn't really express what we want to achieve here I think,
>> I think StandardVersion is fine.
> 
> I prefer StandardVersion as well. Rational (according to websters.com):

Eric's suggestion of NormalizedVersion sounds best to me - it exactly
describes the intended role of the class.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From ncoghlan at gmail.com  Fri Dec 11 11:29:41 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 11 Dec 2009 20:29:41 +1000
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <1afaf6160912101224i36562613r1462f432d6ae88ed@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>	<1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com>	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>	<b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com>	<319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com>	<79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com>	<319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com>	<hfri00$5js$1@ger.gmane.org>	<319e029f0912101219q7f1c730ai7fe12b41f3914bed@mail.gmail.com>
	<1afaf6160912101224i36562613r1462f432d6ae88ed@mail.gmail.com>
Message-ID: <4B221F15.70904@gmail.com>

Benjamin Peterson wrote:
> 2009/12/10 Lennart Regebro <regebro at gmail.com>:
>> On Thu, Dec 10, 2009 at 20:25, Terry Reedy <tjreedy at udel.edu> wrote:
>>> Since the intent of IGNORE_EXCEPTION_DETAIL is to make doctests immune to
>>> implementation version specific changes, it seems to me that extending its
>>> technical meaning is required to carry out its intent.
>> Would this be considered bugfixy enough to get into 3.1-branch as well
>> as 2.7? It really is damn annoying when you try to port doctests to
>> Python 3, and it would be great if we wouldn't have to wait for 3.2.
> 
> I think a patch would be helpful before deciding that.

Agreed that a patch is needed before deciding, but I support the idea
that this be classed as a bug in IGNORE_EXCEPTION_DETAIL - the presence
or absence of module information in the printout of the Exception name
shouldn't make the test fail.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From ziade.tarek at gmail.com  Fri Dec 11 11:40:10 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Dec 2009 11:40:10 +0100
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <87tyvy5bx8.fsf@benfinney.id.au>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<87ocm674fb.fsf@benfinney.id.au>
	<94bdd2610912101649r70ef222btd03ecfb236f2a000@mail.gmail.com>
	<87tyvy5bx8.fsf@benfinney.id.au>
Message-ID: <94bdd2610912110240k758155afxdebc07918fc923b4@mail.gmail.com>

On Fri, Dec 11, 2009 at 6:15 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
[..]
>
> No, the PEP document itself should either contain the questions and
> answers, or contain a link to the discussion along with a brief summary
> of what it was about and a explicit statement of its outcome.

Ok then, I'll add a section summarizing the history of the discussions
in that case.

Regards
Tarek

From ziade.tarek at gmail.com  Fri Dec 11 11:41:56 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Fri, 11 Dec 2009 11:41:56 +0100
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <4B221DA8.5060509@gmail.com>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<4B20B4D1.10502@gmail.com>
	<94bdd2610912100519n43614c84n63c37794ec8f5d7b@mail.gmail.com>
	<loom.20091210T145433-494@post.gmane.org>
	<a08e5f80912100610l48312c5do5b85c7a07376a5d1@mail.gmail.com>
	<4B221DA8.5060509@gmail.com>
Message-ID: <94bdd2610912110241y5a023f09m639ad57637b6f8e0@mail.gmail.com>

On Fri, Dec 11, 2009 at 11:23 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Darren Dale wrote:
>> On Thu, Dec 10, 2009 at 8:54 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>> Tarek Ziad? <ziade.tarek <at> gmail.com> writes:
>>>> Do you have a better suggestion ? I was thinking about StandardVersion
>>>> but "Standard"
>>>> doesn't really express what we want to achieve here I think,
>>> I think StandardVersion is fine.
>>
>> I prefer StandardVersion as well. Rational (according to websters.com):
>
> Eric's suggestion of NormalizedVersion sounds best to me - it exactly
> describes the intended role of the class.

Ok, NormalizedVersion is fine with me, I'll change the doc + code accordingly

Regards
Tarek

From status at bugs.python.org  Fri Dec 11 18:07:17 2009
From: status at bugs.python.org (Python tracker)
Date: Fri, 11 Dec 2009 18:07:17 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20091211170717.1D9A378603@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (12/04/09 - 12/11/09)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 2526 open (+34) / 16775 closed (+11) / 19301 total (+45)

Open issues with patches:  1007

Average duration of open issues: 694 days.
Median duration of open issues: 450 days.

Open Issues Breakdown
   open  2492 (+34)
pending    33 ( +0)

Issues Created Or Reopened (45)
_______________________________

Int/Long: some tests are duplicate and error messages refer to " 12/04/09
CLOSED http://bugs.python.org/issue7435    created  flox                          
       patch                                                                   

Define 'object with assignable attributes'                       12/04/09
       http://bugs.python.org/issue7436    created  tjreedy                       
                                                                               

OS X 2.6.4 installer fails on 10.3 with two corrupted	file names 12/05/09
       http://bugs.python.org/issue7437    created  ned.deily                     
                                                                               

Allow to use a part of subprocess module during building Python  12/05/09
       http://bugs.python.org/issue7438    created  Arfrever                      
       patch, needs review                                                     

Bug or expected behavior?  I cannot tell.                        12/05/09
CLOSED http://bugs.python.org/issue7439    created  LambertDW                     
                                                                               

distutils shows incorrect Python version in MSI installers       12/05/09
       http://bugs.python.org/issue7440    created  MarioVilas                    
                                                                               

Py3.1: Fatal Python Error: Py_Initialize...unknown encoding: chc 12/05/09
       http://bugs.python.org/issue7441    created  lieryan                       
                                                                               

decimal.py: format failure with locale specifier                 12/05/09
       http://bugs.python.org/issue7442    created  skrah                         
                                                                               

test.support.unlink issue on Windows platform                    12/05/09
       http://bugs.python.org/issue7443    created  asvetlov                      
       patch, needs review                                                     

Allow for a default method in the JSON decoder                   12/05/09
CLOSED http://bugs.python.org/issue7444    created  dhgoldman                     
                                                                               

urllib2 (and urllib) should raise error for incomplete response  12/05/09
       http://bugs.python.org/issue7445    created  gotgenes                      
                                                                               

http.cookies.BaseCookie (and SimpleCookie) can't be load from di 12/05/09
CLOSED http://bugs.python.org/issue7446    created  tcourbon                      
                                                                               

Sum() doc and behavior mismatch                                  12/06/09
       http://bugs.python.org/issue7447    created  tjreedy                       
                                                                               

when piping output between subprocesses some fd is left open blo 12/06/09
       http://bugs.python.org/issue7448    created  nosklo                        
                                                                               

A number tests "crash" if python is compiled --without-threads   12/06/09
       http://bugs.python.org/issue7449    created  r.david.murray                
       patch, easy                                                             

document that os.chmod accepts an octal digit mode               12/07/09
       http://bugs.python.org/issue7450    created  clutchski                     
                                                                               

improve json decoding performance                                12/07/09
       http://bugs.python.org/issue7451    created  pitrou                        
       patch                                                                   

Invalid mnemonic 'fnstcw'                                        12/07/09
CLOSED http://bugs.python.org/issue7452    created  srid                          
                                                                               

HPUX 11.00: socketmodule.c -- error 1588: "AI_PASSIVE" undefined 12/08/09
       http://bugs.python.org/issue7453    created  srid                          
                                                                               

Solaris SPARC: _multiprocessing.so: symbol sem_timedwait: refere 12/08/09
       http://bugs.python.org/issue7454    created  srid                          
                                                                               

cPickle: stack underflow in load_pop()                           12/08/09
       http://bugs.python.org/issue7455    created  haypo                         
       patch                                                                   

rfc822.Message.getheaders undocumented                           12/08/09
CLOSED http://bugs.python.org/issue7456    created  tarek                         
                                                                               

Adding a read_pkg_file to DistributionMetadata                   12/08/09
CLOSED http://bugs.python.org/issue7457    created  tarek                         
                                                                               

crash in str.rfind() with an invalid start value                 12/08/09
       http://bugs.python.org/issue7458    created  haypo                         
       patch                                                                   

Magic word incorrect in Python 3                                 12/08/09
CLOSED http://bugs.python.org/issue7459    created  Arfrever                      
       patch                                                                   

extended slicing not sufficiently covered in docs                12/08/09
       http://bugs.python.org/issue7460    created  donlorenzo                    
                                                                               

os.popen() objects don't support the context manager protocol    12/08/09
CLOSED http://bugs.python.org/issue7461    created  pitrou                        
       patch                                                                   

Implement fastsearch algorithm for rfind/rindex                  12/08/09
       http://bugs.python.org/issue7462    created  flox                          
       patch                                                                   

PyDateTime_IMPORT() causes compiler warnings                     12/09/09
       http://bugs.python.org/issue7463    created  murrayc                       
                                                                               

circular reference in HTTPResponse by urllib2                    12/09/09
       http://bugs.python.org/issue7464    created  krisvale                      
       patch                                                                   

Call to another class's constructor in unittest.TestCase.setUp r 12/10/09
CLOSED http://bugs.python.org/issue7465    created  awaltman                      
                                                                               

Segmentation fault after about 20 seconds on lenovo T500         12/10/09
       http://bugs.python.org/issue7466    created  LambertDW                     
       patch                                                                   

The zipfile module does not check files' CRCs, including in ZipF 12/10/09
       http://bugs.python.org/issue7467    created  dougturk                      
                                                                               

PyErr_Format documentation doesn't mention all format codes      12/10/09
       http://bugs.python.org/issue7468    created  ronaldoussoren                
                                                                               

Design and History FAQ entry on Floating Point does not mention  12/10/09
       http://bugs.python.org/issue7469    created  r.david.murray                
       easy                                                                    

logger.StreamHandler emit encoding fallback is wrong             12/10/09
CLOSED http://bugs.python.org/issue7470    created  cboos                         
       patch                                                                   

GZipFile.readline too slow                                       12/10/09
       http://bugs.python.org/issue7471    created  asnakelover                   
                                                                               

email.encoders.encode_7or8bit(): typo "iso-2202".  "iso-2022" is 12/10/09
       http://bugs.python.org/issue7472    created  ynkdir                        
                                                                               

Compile error when building a 3-way universal framework when a 2 12/10/09
       http://bugs.python.org/issue7473    created  prniii                        
                                                                               

multiprocessing.managers.SyncManager managed object creation fai 12/10/09
       http://bugs.python.org/issue7474    created  etzool                        
                                                                               

codecs missing: base64 bz2 hex zlib ...                          12/11/09
       http://bugs.python.org/issue7475    reopened flox                          
       patch                                                                   

pipes.quote does not handle zero-length args correctly           12/10/09
       http://bugs.python.org/issue7476    created  jjwiseman                     
                                                                               

kqueue timers don't work properly                                12/11/09
       http://bugs.python.org/issue7477    created  hasan                         
                                                                               

_sqlite3 doesn't catch PyDict_SetItem error                      12/11/09
       http://bugs.python.org/issue7478    created  haypo                         
       patch                                                                   

os.lchmod is not present                                         12/11/09
       http://bugs.python.org/issue7479    created  bluegeek                      
                                                                               



Issues Now Closed (24)
______________________

Update to latest ElementTree in Python 2.7                        818 days
       http://bugs.python.org/issue1143    pitrou                        
       patch                                                                   

Can't pickle partial functions                                    483 days
       http://bugs.python.org/issue1398    alexandre.vassalotti          
                                                                               

Remove cmp parameter to list.sort() and builtin.sorted()          699 days
       http://bugs.python.org/issue1771    gvanrossum                    
                                                                               

meaningful whitespace can be lost in rfc822_escape                682 days
       http://bugs.python.org/issue1923    tarek                         
       easy                                                                    

add ftp-tls support to ftplib - RFC 4217                          667 days
       http://bugs.python.org/issue2054    pitrou                        
       patch                                                                   

I/O operation on closed socket: improve the error message         339 days
       http://bugs.python.org/issue4853    haypo                         
       patch                                                                   

cPickle - module object has no attribute                          262 days
       http://bugs.python.org/issue5509    rb                            
                                                                               

Implement a way to change the python process name                 249 days
       http://bugs.python.org/issue5672    loewis                        
       patch                                                                   

_json crash on scanner/encoder initialization error                75 days
       http://bugs.python.org/issue6986    pitrou                        
       patch                                                                   

Problems running threaded Tkinter program under OS X IDLE          46 days
       http://bugs.python.org/issue7190    ronaldoussoren                
                                                                               

StringIO and with statement                                         1 days
       http://bugs.python.org/issue7426    alexandre.vassalotti          
                                                                               

Int/Long: some tests are duplicate and error messages refer to "    1 days
       http://bugs.python.org/issue7435    mark.dickinson                
       patch                                                                   

Bug or expected behavior?  I cannot tell.                           1 days
       http://bugs.python.org/issue7439    brett.cannon                  
                                                                               

Allow for a default method in the JSON decoder                      0 days
       http://bugs.python.org/issue7444    bob.ippolito                  
                                                                               

http.cookies.BaseCookie (and SimpleCookie) can't be load from di    0 days
       http://bugs.python.org/issue7446    amaury.forgeotdarc            
                                                                               

Invalid mnemonic 'fnstcw'                                           4 days
       http://bugs.python.org/issue7452    ronaldoussoren                
                                                                               

rfc822.Message.getheaders undocumented                              0 days
       http://bugs.python.org/issue7456    tarek                         
                                                                               

Adding a read_pkg_file to DistributionMetadata                      0 days
       http://bugs.python.org/issue7457    tarek                         
                                                                               

Magic word incorrect in Python 3                                    1 days
       http://bugs.python.org/issue7459    benjamin.peterson             
       patch                                                                   

os.popen() objects don't support the context manager protocol       0 days
       http://bugs.python.org/issue7461    pitrou                        
       patch                                                                   

Call to another class's constructor in unittest.TestCase.setUp r    0 days
       http://bugs.python.org/issue7465    r.david.murray                
                                                                               

logger.StreamHandler emit encoding fallback is wrong                1 days
       http://bugs.python.org/issue7470    vinay.sajip                   
       patch                                                                   

add support for thread function result storage                   1438 days
       http://bugs.python.org/issue1395552 mykhal                        
       patch                                                                   

sys.getfilesystemencoding                                        1293 days
       http://bugs.python.org/issue1495089 r.david.murray                
                                                                               



Top Issues Most Discussed (10)
______________________________

 27 IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs         219 days
open    http://bugs.python.org/issue5949   

 18 Invalid mnemonic 'fnstcw'                                          4 days
closed  http://bugs.python.org/issue7452   

 12 codecs missing: base64 bz2 hex zlib ...                            0 days
open    http://bugs.python.org/issue7475   

 12 json C serializer performance tied to structure depth on some s  136 days
open    http://bugs.python.org/issue6594   

 11 crash in str.rfind() with an invalid start value                   3 days
open    http://bugs.python.org/issue7458   

  9 Segmentation fault after about 20 seconds on lenovo T500           2 days
open    http://bugs.python.org/issue7466   

  9 Implement a way to change the python process name                249 days
closed  http://bugs.python.org/issue5672   

  9 csv module: add header row to DictWriter                        1220 days
open    http://bugs.python.org/issue1537721

  8 GZipFile.readline too slow                                         1 days
open    http://bugs.python.org/issue7471   

  8 Remove cmp parameter to list.sort() and builtin.sorted()         699 days
closed  http://bugs.python.org/issue1771   




From starsareblueandfaraway at gmail.com  Fri Dec 11 19:31:02 2009
From: starsareblueandfaraway at gmail.com (Roy Hyunjin Han)
Date: Fri, 11 Dec 2009 13:31:02 -0500
Subject: [Python-Dev] Splitting something into two steps produces different
	behavior from doing it in one fell swoop in Python 2.6.2
Message-ID: <6a5569ec0912111031i55790214if78e3aaa5708c7dc@mail.gmail.com>

While debugging a network algorithm in Python 2.6.2, I encountered
some strange behavior and was wondering whether it has to do with some
sort of code optimization that Python does behind the scenes.


************
After initialization: defaultdict(<type 'set'>, {1: set([1])})
Popping and updating in two steps: defaultdict(<type 'set'>, {1: set([1])})
************
After initialization: defaultdict(<type 'set'>, {1: set([1])})
Popping and updating in one step: defaultdict(<type 'set'>, {})


import collections
print '************'
x = collections.defaultdict(set)
x[1].update([1])
print 'After initialization: %s' % x
items = x.pop(1)
x[1].update(items)
print 'Popping and updating in two steps: %s' % x
print '************'
y = collections.defaultdict(set)
y[1].update([1])
print 'After initialization: %s' % y
y[1].update(y.pop(1))
print 'Popping and updating in one step: %s' % y
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inOneStepVSTwoSteps.py
Type: application/octet-stream
Size: 394 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091211/323e9c41/attachment.obj>

From john.arbash.meinel at gmail.com  Fri Dec 11 19:36:52 2009
From: john.arbash.meinel at gmail.com (John Arbash Meinel)
Date: Fri, 11 Dec 2009 12:36:52 -0600
Subject: [Python-Dev] Splitting something into two steps produces
 different behavior from doing it in one fell swoop in Python 2.6.2
In-Reply-To: <6a5569ec0912111031i55790214if78e3aaa5708c7dc@mail.gmail.com>
References: <6a5569ec0912111031i55790214if78e3aaa5708c7dc@mail.gmail.com>
Message-ID: <4B229144.7030204@gmail.com>

Roy Hyunjin Han wrote:
> While debugging a network algorithm in Python 2.6.2, I encountered
> some strange behavior and was wondering whether it has to do with some
> sort of code optimization that Python does behind the scenes.
> 
> 
> ************
> After initialization: defaultdict(<type 'set'>, {1: set([1])})
> Popping and updating in two steps: defaultdict(<type 'set'>, {1: set([1])})
> ************
> After initialization: defaultdict(<type 'set'>, {1: set([1])})
> Popping and updating in one step: defaultdict(<type 'set'>, {})
> 
> 
> import collections
> print '************'
> x = collections.defaultdict(set)
> x[1].update([1])
> print 'After initialization: %s' % x
> items = x.pop(1)
> x[1].update(items)
> print 'Popping and updating in two steps: %s' % x
> print '************'
> y = collections.defaultdict(set)
> y[1].update([1])
> print 'After initialization: %s' % y
> y[1].update(y.pop(1))
> print 'Popping and updating in one step: %s' % y
> 

y[1].update(y.pop(1))

is going to be evaluating y[1] before it evaluates y.pop(1).
Which means that it has the original set returned, which is then removed
by y.pop, and updated.

You probably get the same behavior without using a defaultdict:
  y.setdefault(1, set()).update(y.pop(1))
  ^^^^^^^^^^^^^^^^^^^^^^- evaluated first


Oh and I should probably give the standard: "This list is for the
development *of* python, not development *with* python."

John
=:->

From python at mrabarnett.plus.com  Fri Dec 11 20:43:35 2009
From: python at mrabarnett.plus.com (MRAB)
Date: Fri, 11 Dec 2009 19:43:35 +0000
Subject: [Python-Dev] Splitting something into two steps produces
 different behavior from doing it in one fell swoop in Python 2.6.2
In-Reply-To: <4B229144.7030204@gmail.com>
References: <6a5569ec0912111031i55790214if78e3aaa5708c7dc@mail.gmail.com>
	<4B229144.7030204@gmail.com>
Message-ID: <4B22A0E7.6080107@mrabarnett.plus.com>

John Arbash Meinel wrote:
> Roy Hyunjin Han wrote:
>> While debugging a network algorithm in Python 2.6.2, I encountered
>> some strange behavior and was wondering whether it has to do with some
>> sort of code optimization that Python does behind the scenes.
>>
>>
>> ************
>> After initialization: defaultdict(<type 'set'>, {1: set([1])})
>> Popping and updating in two steps: defaultdict(<type 'set'>, {1: set([1])})
>> ************
>> After initialization: defaultdict(<type 'set'>, {1: set([1])})
>> Popping and updating in one step: defaultdict(<type 'set'>, {})
>>
>>
>> import collections
>> print '************'
>> x = collections.defaultdict(set)
>> x[1].update([1])
>> print 'After initialization: %s' % x
>> items = x.pop(1)
>> x[1].update(items)
>> print 'Popping and updating in two steps: %s' % x
>> print '************'
>> y = collections.defaultdict(set)
>> y[1].update([1])
>> print 'After initialization: %s' % y
>> y[1].update(y.pop(1))
>> print 'Popping and updating in one step: %s' % y
>>
> 
> y[1].update(y.pop(1))
> 
> is going to be evaluating y[1] before it evaluates y.pop(1).
> Which means that it has the original set returned, which is then removed
> by y.pop, and updated.
> 
> You probably get the same behavior without using a defaultdict:
>   y.setdefault(1, set()).update(y.pop(1))
>   ^^^^^^^^^^^^^^^^^^^^^^- evaluated first
> 
> 
> Oh and I should probably give the standard: "This list is for the
> development *of* python, not development *with* python."
> 
To me the question was whether Python was behaving correctly; the
behaviour was more subtle than the legendary mutable default argument.

From regebro at gmail.com  Fri Dec 11 21:32:58 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Fri, 11 Dec 2009 21:32:58 +0100
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <1afaf6160912101224i36562613r1462f432d6ae88ed@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
	<b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com>
	<319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com>
	<79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com>
	<319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com>
	<hfri00$5js$1@ger.gmane.org>
	<319e029f0912101219q7f1c730ai7fe12b41f3914bed@mail.gmail.com>
	<1afaf6160912101224i36562613r1462f432d6ae88ed@mail.gmail.com>
Message-ID: <319e029f0912111232kb31e3e9j9e2ac42472db7c41@mail.gmail.com>

On Thu, Dec 10, 2009 at 21:24, Benjamin Peterson <benjamin at python.org> wrote:
>
> 2009/12/10 Lennart Regebro <regebro at gmail.com>:
> > On Thu, Dec 10, 2009 at 20:25, Terry Reedy <tjreedy at udel.edu> wrote:
> >> Since the intent of IGNORE_EXCEPTION_DETAIL is to make doctests immune to
> >> implementation version specific changes, it seems to me that extending its
> >> technical meaning is required to carry out its intent.
> >
> > Would this be considered bugfixy enough to get into 3.1-branch as well
> > as 2.7? It really is damn annoying when you try to port doctests to
> > Python 3, and it would be great if we wouldn't have to wait for 3.2.
>
> I think a patch would be helpful before deciding that.

Should I start a bug report in the tracker for this?

The diff in the code is:

                 # Another chance if they didn't care about the detail.
                 elif self.optionflags & IGNORE_EXCEPTION_DETAIL:
-                    m1 = re.match(r'[^:]*:', example.exc_msg)
-                    m2 = re.match(r'[^:]*:', exc_msg)
-                    if m1 and m2 and check(m1.group(0), m2.group(0),
+                    m1 = re.match(r'(?:[^:]*\.)?([^:]*:)', example.exc_msg)
+                    m2 = re.match(r'(?:[^:]*\.)?([^:]*:)', exc_msg)
+                    if m1 and m2 and check(m1.group(1), m2.group(1),
                                            self.optionflags):
                         outcome = SUCCESS

But obviously I have patches for both py3k and trunk with tests and
updated documentation as well.
As you see the diff is pretty simple, it's just a more complex regex.
-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From exarkun at twistedmatrix.com  Fri Dec 11 21:36:38 2009
From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com)
Date: Fri, 11 Dec 2009 20:36:38 -0000
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <4B1FE7D6.7020803@voidspace.org.uk>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<4B1FD18C.2080107@voidspace.org.uk>
	<319e029f0912090911u2e64e957mb18319d95f147d58@mail.gmail.com>
	<20091209180241.2549.1139656274.divmod.xquotient.585@localhost.localdomain>
	<4B1FE7D6.7020803@voidspace.org.uk>
Message-ID: <20091211203638.2549.215247270.divmod.xquotient.708@localhost.localdomain>

On 9 Dec, 06:09 pm, fuzzyman at voidspace.org.uk wrote:
>On 09/12/2009 18:02, exarkun at twistedmatrix.com wrote:
>>On 05:11 pm, lregebro at jarn.com wrote:
>>>On Wed, Dec 9, 2009 at 17:34, Michael Foord 
>>><fuzzyman at voidspace.org.uk> wrote:
>>>>Can you be more specific?
>>>
>>>Only with an insane amount of work. I'll hold that off for a while.
>>
>>I don't know if this is related at all (and I guess we won't until 
>>Lennart can be more specific :), but here are some Twisted unit test 
>>failures which are probably due to unittest changes in 2.7:
>>
>>===============================================================================
>>[FAIL]: twisted.trial.test.test_loader.LoaderTest.test_sortCases
>>
>>Traceback (most recent call last):
>>  File 
>>"/home/buildslave/pybot/trunk.glass-x86/build/Twisted/twisted/trial/test/test_loader.py", 
>>line 167, in test_sortCases
>>    [test._testMethodName for test in suite._tests])
>>twisted.trial.unittest.FailTest: not equal:
>>a = ['test_b', 'test_c', 'test_a']
>>b = ['test_c', 'test_b', 'test_a']
>
>Is the order significant? Can you just compare sorted versions of the 
>lists instead?
>
>If the order *is* significant I would be interested to know which 
>change caused this.

It looks like a change to shortDescription may be responsible for all 
the failures mentioned here.

The order *is* significant (it's a test for how tests are ordered...). 
The sorting code (which wasn't super awesome, I'll admit) it uses was 
broken by the change in the return value of shortDescription, something 
which is much more obvious in some of the other failures.
>[snip]
>>a = 'skip1 (twisted.trial.test.test_tests.SkippingTests)'
>>b = 'skip1'
>
>These two test failures are due to the change in repr of something I 
>guess? Is a or b the original output?

b is the original, a is the produced value.  Here's a simpler example:

Python 2.6.4 (r264:75706, Nov  2 2009, 14:38:03) [GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>from twisted.test.test_abstract import AddressTests
>>>AddressTests('test_decimalDotted').shortDescription()
'test_decimalDotted'
>>>

Python 2.7a0 (trunk:76325M, Nov 16 2009, 09:50:40) [GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>from twisted.test.test_abstract import AddressTests
>>>AddressTests('test_decimalDotted').shortDescription()
'test_decimalDotted (twisted.test.test_abstract.AddressTests)'
>>>

Aside from compatibility issues, this seems like a not-too-ideal change 
in behavior for a method named "shortDescription", at least to me. 
Going out on a limb, I'll guess that it was made in order to provide a 
different user-facing experience in the stdlib's test runner.  If that's 
right, then I think it would make sense to revert shortDescription back 
to the previous behavior and either introduce a new method which returns 
this string or just put the logic all into the display code instead.
>>
>>I'm not opposed to the improvement of unittest (or any part of 
>>Python). Perhaps more of the improvements can be provided in new APIs 
>>rather than by changing the behavior of existing APIs, though.
>
>Well, introducing lots of new APIs has its own problems of course.

It seems to me that it typically has fewer problems.
>Hearing about difficulties changes cause is good though (the reason for 
>alphas I guess) and if it is possible to work out why things are broken 
>then maybe we can still have the new functionality without the 
>breakage.

Of course.  Also, I should have pointed this out in my previous email, 
this information about failures is always easily available, at least for 
Twisted (and at most for any project interested in participating in the 
project), on the community buildbots page:

  http://www.python.org/dev/buildbot/community/trunk/

So anyone who cares to can check to see if their changes have broken 
things right away, instead of only finding out 6 or 12 or 18 months 
later. :)
>The problem with Lennart's report is that it is just "things are 
>broken" without much clue. I am sympathetic to this (working out 
>*exactly* what is broken in someone else's code can be a painful chore) 
>but I'm not sure what can be done about it without more detail.

Certainly.  Perhaps Zope would like to add something to the community 
builders page.

Thanks,

Jean-Paul

From lregebro at jarn.com  Fri Dec 11 21:51:12 2009
From: lregebro at jarn.com (Lennart Regebro)
Date: Fri, 11 Dec 2009 21:51:12 +0100
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <20091211203638.2549.215247270.divmod.xquotient.708@localhost.localdomain>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<4B1FD18C.2080107@voidspace.org.uk>
	<319e029f0912090911u2e64e957mb18319d95f147d58@mail.gmail.com>
	<20091209180241.2549.1139656274.divmod.xquotient.585@localhost.localdomain>
	<4B1FE7D6.7020803@voidspace.org.uk>
	<20091211203638.2549.215247270.divmod.xquotient.708@localhost.localdomain>
Message-ID: <319e029f0912111251o65e0701cuc69cc51b7d3f0adf@mail.gmail.com>

On Fri, Dec 11, 2009 at 21:36,  <exarkun at twistedmatrix.com> wrote:
> Certainly. ?Perhaps Zope would like to add something to the community
> builders page.

The Zope Component Architecture would be nice to test like that. Much
of the rest of Zope needs massaging between python versions, so that
may not be useful.

 http://www.python.org/dev/buildbot/community/trunk/

So anyone who cares to can check to see if their changes have broken
things right away, instead of only finding out 6 or 12 or 18 months
later. :)

Cc:ing zope-dev for opinions.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From starsareblueandfaraway at gmail.com  Fri Dec 11 21:52:38 2009
From: starsareblueandfaraway at gmail.com (Roy Hyunjin Han)
Date: Fri, 11 Dec 2009 15:52:38 -0500
Subject: [Python-Dev] Splitting something into two steps produces
	different behavior from doing it in one fell swoop in Python 2.6.2
In-Reply-To: <4B22A0E7.6080107@mrabarnett.plus.com>
References: <6a5569ec0912111031i55790214if78e3aaa5708c7dc@mail.gmail.com>
	<4B229144.7030204@gmail.com> <4B22A0E7.6080107@mrabarnett.plus.com>
Message-ID: <6a5569ec0912111252s54f14115ifa48cc3f54b7cae0@mail.gmail.com>

On Fri, Dec 11, 2009 at 2:43 PM, MRAB <python at mrabarnett.plus.com> wrote:
> John Arbash Meinel wrote:
>>
>> Roy Hyunjin Han wrote:
>>>
>>> While debugging a network algorithm in Python 2.6.2, I encountered
>>> some strange behavior and was wondering whether it has to do with some
>>> sort of code optimization that Python does behind the scenes.
>>>
>>>
>>> ************
>>> After initialization: defaultdict(<type 'set'>, {1: set([1])})
>>> Popping and updating in two steps: defaultdict(<type 'set'>, {1:
>>> set([1])})
>>> ************
>>> After initialization: defaultdict(<type 'set'>, {1: set([1])})
>>> Popping and updating in one step: defaultdict(<type 'set'>, {})
>>>
>>>
>>> import collections
>>> print '************'
>>> x = collections.defaultdict(set)
>>> x[1].update([1])
>>> print 'After initialization: %s' % x
>>> items = x.pop(1)
>>> x[1].update(items)
>>> print 'Popping and updating in two steps: %s' % x
>>> print '************'
>>> y = collections.defaultdict(set)
>>> y[1].update([1])
>>> print 'After initialization: %s' % y
>>> y[1].update(y.pop(1))
>>> print 'Popping and updating in one step: %s' % y
>>>
>>
>> y[1].update(y.pop(1))
>>
>> is going to be evaluating y[1] before it evaluates y.pop(1).
>> Which means that it has the original set returned, which is then removed
>> by y.pop, and updated.
>>
>> You probably get the same behavior without using a defaultdict:
>> ?y.setdefault(1, set()).update(y.pop(1))
>> ?^^^^^^^^^^^^^^^^^^^^^^- evaluated first
>>
>>
>> Oh and I should probably give the standard: "This list is for the
>> development *of* python, not development *with* python."
>>
> To me the question was whether Python was behaving correctly; the
> behaviour was more subtle than the legendary mutable default argument.

Thanks, John and MRAB.  I was pointing it out on this list because I
felt like it was counterintuitive and that the result should be the
same whether the developer decides to do it in two steps or in one
step.

From ncoghlan at gmail.com  Sat Dec 12 01:34:47 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 12 Dec 2009 10:34:47 +1000
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <319e029f0912111232kb31e3e9j9e2ac42472db7c41@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>	<9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com>	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>	<b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com>	<319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com>	<79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com>	<319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com>	<hfri00$5js$1@ger.gmane.org>	<319e029f0912101219q7f1c730ai7fe12b41f3914bed@mail.gmail.com>	<1afaf6160912101224i36562613r1462f432d6ae88ed@mail.gmail.com>
	<319e029f0912111232kb31e3e9j9e2ac42472db7c41@mail.gmail.com>
Message-ID: <4B22E527.6030304@gmail.com>

Lennart Regebro wrote:
> On Thu, Dec 10, 2009 at 21:24, Benjamin Peterson <benjamin at python.org> wrote:
>> 2009/12/10 Lennart Regebro <regebro at gmail.com>:
>>> On Thu, Dec 10, 2009 at 20:25, Terry Reedy <tjreedy at udel.edu> wrote:
>>>> Since the intent of IGNORE_EXCEPTION_DETAIL is to make doctests immune to
>>>> implementation version specific changes, it seems to me that extending its
>>>> technical meaning is required to carry out its intent.
>>> Would this be considered bugfixy enough to get into 3.1-branch as well
>>> as 2.7? It really is damn annoying when you try to port doctests to
>>> Python 3, and it would be great if we wouldn't have to wait for 3.2.
>> I think a patch would be helpful before deciding that.
> 
> Should I start a bug report in the tracker for this?

Yep.

> The diff in the code is:
> 
>                  # Another chance if they didn't care about the detail.
>                  elif self.optionflags & IGNORE_EXCEPTION_DETAIL:
> -                    m1 = re.match(r'[^:]*:', example.exc_msg)
> -                    m2 = re.match(r'[^:]*:', exc_msg)
> -                    if m1 and m2 and check(m1.group(0), m2.group(0),
> +                    m1 = re.match(r'(?:[^:]*\.)?([^:]*:)', example.exc_msg)
> +                    m2 = re.match(r'(?:[^:]*\.)?([^:]*:)', exc_msg)
> +                    if m1 and m2 and check(m1.group(1), m2.group(1),
>                                             self.optionflags):
>                          outcome = SUCCESS
> 
> But obviously I have patches for both py3k and trunk with tests and
> updated documentation as well.
> As you see the diff is pretty simple, it's just a more complex regex.

Looks reasonable to me, although any backport to existing branches will
be Benjamin's call for 3.1 and Barry's for 2.6 (as the respective
release managers).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From ncoghlan at gmail.com  Sat Dec 12 01:59:49 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 12 Dec 2009 10:59:49 +1000
Subject: [Python-Dev] Splitting something into two steps
 produces	different behavior from doing it in one fell swoop in Python 2.6.2
In-Reply-To: <6a5569ec0912111252s54f14115ifa48cc3f54b7cae0@mail.gmail.com>
References: <6a5569ec0912111031i55790214if78e3aaa5708c7dc@mail.gmail.com>	<4B229144.7030204@gmail.com>
	<4B22A0E7.6080107@mrabarnett.plus.com>
	<6a5569ec0912111252s54f14115ifa48cc3f54b7cae0@mail.gmail.com>
Message-ID: <4B22EB05.5010803@gmail.com>

Roy Hyunjin Han wrote:
> On Fri, Dec 11, 2009 at 2:43 PM, MRAB <python at mrabarnett.plus.com> wrote:
>> John Arbash Meinel wrote:
>>> y[1].update(y.pop(1))
>>>
>>> is going to be evaluating y[1] before it evaluates y.pop(1).
>>> Which means that it has the original set returned, which is then removed
>>> by y.pop, and updated.
>> To me the question was whether Python was behaving correctly; the
>> behaviour was more subtle than the legendary mutable default argument.
> 
> Thanks, John and MRAB.  I was pointing it out on this list because I
> felt like it was counterintuitive and that the result should be the
> same whether the developer decides to do it in two steps or in one
> step.

It follows the standard left-to-right evaluation order within an expression:

<subexpr1>(<subexpr2>)

(i.e. a function call always determines which function is going to be
called before determining any arguments to be passed)

Splitting it into two lines then clearly changes the evaluation order:

temp = <subexpr2>
<subexpr1>(temp)

I'm not sure what behaviour could be suggested as being more intuitive -
the problem in this case arose due to both referencing and mutating the
same object in a single statement, which is always going to be
problematic from an ordering point of view, since it depends on subtle
details of statement definitions that people often won't know. Better to
split the mutation and the reference into separate statements so the
intended order is clear regardless of how well the reader knows the
subtleties of Python's evaluation order.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From tseaver at palladion.com  Sat Dec 12 04:36:45 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Fri, 11 Dec 2009 22:36:45 -0500
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <319e029f0912111251o65e0701cuc69cc51b7d3f0adf@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>	<4B1FD18C.2080107@voidspace.org.uk>	<319e029f0912090911u2e64e957mb18319d95f147d58@mail.gmail.com>	<20091209180241.2549.1139656274.divmod.xquotient.585@localhost.localdomain>	<4B1FE7D6.7020803@voidspace.org.uk>	<20091211203638.2549.215247270.divmod.xquotient.708@localhost.localdomain>
	<319e029f0912111251o65e0701cuc69cc51b7d3f0adf@mail.gmail.com>
Message-ID: <4B230FCD.7070008@palladion.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lennart Regebro wrote:
> On Fri, Dec 11, 2009 at 21:36,  <exarkun at twistedmatrix.com> wrote:
>> Certainly.  Perhaps Zope would like to add something to the community
>> builders page.
> 
> The Zope Component Architecture would be nice to test like that. Much
> of the rest of Zope needs massaging between python versions, so that
> may not be useful.
> 
>  http://www.python.org/dev/buildbot/community/trunk/
> 
> So anyone who cares to can check to see if their changes have broken
> things right away, instead of only finding out 6 or 12 or 18 months
> later. :)
> 
> Cc:ing zope-dev for opinions.

+1 in general to the idea:  we should be able to put together a
"buildcompat"-style buildout which would be autoamatable under buildbot.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksjD80ACgkQ+gerLs4ltQ5IggCeOzMSYJ3rYAXNdkj1f/03gkfJ
usAAn2gYe8DN550roU+VXl8cHSOyI6uY
=f1Ww
-----END PGP SIGNATURE-----


From rob.cliffe at btinternet.com  Sat Dec 12 09:36:34 2009
From: rob.cliffe at btinternet.com (Rob Cliffe)
Date: Sat, 12 Dec 2009 08:36:34 -0000
Subject: [Python-Dev] Backslash at end of raw string
Message-ID: <3A380D6D54E94B82ADF4AB5C62E48199@robslaptop>

Python (e.g. 2.5) does not accept a backslash as the LAST character of a raw string:

>>> r"\"
  File "<stdin>", line 1
    r"\"
        ^
Syntax Error: EOL while scanning single-quoted string.

path = r'\MyDir\MySubDir\'  # raises same error
path = r'\MyDir\MySubDir'   # no error

Isn't this a bug?

Rob Cliffe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091212/a8afb55b/attachment.htm>

From ben+python at benfinney.id.au  Sat Dec 12 09:50:02 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sat, 12 Dec 2009 19:50:02 +1100
Subject: [Python-Dev] Backslash at end of raw string
References: <3A380D6D54E94B82ADF4AB5C62E48199@robslaptop>
Message-ID: <87ein060g5.fsf@benfinney.id.au>

"Rob Cliffe" <rob.cliffe at btinternet.com> writes:

> Syntax Error: EOL while scanning single-quoted string.

[?]

> Isn't this a bug?

It has a report <URL:http://bugs.python.org/issue1271> but is not a bug
<URL:http://www.python.org/doc/faq/general/#why-can-t-raw-strings-r-strings-end-with-a-backslash>.

-- 
 \         ?Broken promises don't upset me. I just think, why did they |
  `\                                         believe me?? ?Jack Handey |
_o__)                                                                  |
Ben Finney


From ziade.tarek at gmail.com  Sat Dec 12 12:31:29 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 12 Dec 2009 12:31:29 +0100
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <87tyvy5bx8.fsf@benfinney.id.au>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<87ocm674fb.fsf@benfinney.id.au>
	<94bdd2610912101649r70ef222btd03ecfb236f2a000@mail.gmail.com>
	<87tyvy5bx8.fsf@benfinney.id.au>
Message-ID: <94bdd2610912120331m37a7248eld3834aa10771481c@mail.gmail.com>

On Fri, Dec 11, 2009 at 6:15 AM, Ben Finney
[..]
>
> Yes, I'm referring to the discussion that were had over ?why do we want
> special keywords that mess with the default alphanumerical ordering of
> version string components?? discussion.
>
> That needs to be addressed in the PEP, since it's germane to the
> explanation for the PEP's existence.

I've started to add another section in the PEP to summarize this
discussion but then I realized that we are already giving the answer
in the PEP in the  "Requisites and current status"

I made it clearer though, by adding an extra sentence with an example.

Requesite #2 :
"""
2. most projects need special meaning versions for "pre-releases" (such as
   "alpha", "beta", "rc"), and these have widely used aliases ("a" stands
   for "alpha", "b" for "beta" and "c" for "rc"). And these pre-release
   versions makes it impossible to use a simple alphanumerical ordering
   of the version string components. (Example: 3.1a1 < 3.1)
"""


Let me know if you think this is enough and addresses your concern,

Regards
Tarek

From ziade.tarek at gmail.com  Sat Dec 12 21:02:13 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 12 Dec 2009 21:02:13 +0100
Subject: [Python-Dev] First draft of "sysconfig"
Message-ID: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>

Hello,

A while ago I've proposed to refactor the APIs that provides access to
the installation paths and configuration variables at runtime into a
single module called "sysconfig", and make it easier for all
implementations to work with them.

I've started a branch and worked on it, and I'd like to ask here for
some feedback. And in particular from Jython and IronPython people
because they would probably need to work in that file for their
implementation and/or propose things to add. My understanding is that
we have people like Phillip (Jenvey), Michael F., Frank W. in this
list so they can comment directly and I don't need to cross-post this
mail elsewhere.

== Installation schemes ==

First, the module contains the installation schemes for each platform
CPython uses.
An install scheme is a mapping where the key is the "code" name for a
directory, and
the value the path of that directory, with some $variable that can be expanded.

Install schemes are stored in a private mapping, where the keys are
usually the value of os.name,
and the value, the mapping I've mentionned earlier.

So, for example, the paths for win32 are:

_INSTALL_SCHEMES = {
  ...
  'nt': {
        'stdlib': '$base/Lib',
        'platstdlib': '$base/Lib',
        'purelib': '$base/Lib/site-packages',
        'platlib': '$base/Lib/site-packages',
        'include': '$base/include',
        'platinclude': '$base/include',
        'scripts': '$base/Scripts',
        'data'   : '$base',
        },
  ...
}

where each key corresponds to a directory that contains some Python files:

- stdlib : root of the standard library
- platstdlib: root of platform-specific elements of the standard library
- purelib: the site-packages directory for pure python modules
- platlib: the site-packages directory for platform-specific modules
- include: the include dir
- platinclude: the include dir for platform-specific files
- scripts: the directory where scripts are added
- data: the directory where data file are added

All these directory are read and used by:
- distutils when a package is installed, so the install command can
dispatch files in the right place
- site.py, when Python is initialized

IOW, any part of the stdlib can use these paths to locate and work
with Python files.

The public APIs are:

* get_path_names() : returns a list of the path names ("stdlib",
"platstdlib", etc.)

* get_paths(scheme, vars)  : Returns a mapping containing an install scheme.
   - "scheme" is the name of the scheme, if not provided will get the
default scheme of the current platform
   - vars is an optonal mapping that can provide values for the
various $variables. Notice that they all have
      default values, for example $base == sys.prefix.

    for example: get_paths('nt')

* get_path(name, scheme, vars): Returns one path corresponding to the scheme.

  for example : get_paths('stdlib', 'nt')

Those API are generic, but maybe we could add specific APIs like:

* get_stdlib_path('nt')

These API are basically a refactoring of what already exist in
distutils/command/install.py

== Configuration variables ==

distutils.sysconfig currently provides some APIs to read values from
files like Makefile and pyconfig.h.

These API have been placed in the global sysconfig module:

* get_config_vars(): return a dictionary of all configuration
variables relevant for the current platform.

* get_config_var(name): Return the value of a single variable

* get_platform():  Return a string that identifies the current
platform. (this one is used by site.py for example)

* get_python_version() : return the short python version
(sys.version[:3]) -- this one could probably go away but is useful
because that's the marker used by Python in some paths.

== code, status, next steps ==

The code of the module can be viewed here, it's a revamp of distutils.sysconfig:

http://svn.python.org/view/*checkout*/python/branches/tarek_sysconfig/Lib/sysconfig.py?content-type=text%2Fplain

I've refactored distutils/ and site.py so they work with this new
module, and added deprecation warnings in distutils.sysconfig.

All tests pass in the branch, but note that the code is still using
the .h and Makefile files. This will probably be removed later in
favor of a static _sysconfig.py file generated when Python is built,
containing the variables sysconfig reads. I'll do this second step
after I get some feedback on the proposal.

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From brett at python.org  Sat Dec 12 22:35:39 2009
From: brett at python.org (Brett Cannon)
Date: Sat, 12 Dec 2009 13:35:39 -0800
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
Message-ID: <bbaeab100912121335x23ef592ew6d8207af2001f7fa@mail.gmail.com>

On Sat, Dec 12, 2009 at 12:02, Tarek Ziad? <ziade.tarek at gmail.com> wrote:

> Hello,
>
> A while ago I've proposed to refactor the APIs that provides access to
> the installation paths and configuration variables at runtime into a
> single module called "sysconfig", and make it easier for all
> implementations to work with them.
>
> I've started a branch and worked on it, and I'd like to ask here for
> some feedback. And in particular from Jython and IronPython people
> because they would probably need to work in that file for their
> implementation and/or propose things to add. My understanding is that
> we have people like Phillip (Jenvey), Michael F., Frank W. in this
> list so they can comment directly and I don't need to cross-post this
> mail elsewhere.
>
> == Installation schemes ==
>
> First, the module contains the installation schemes for each platform
> CPython uses.
> An install scheme is a mapping where the key is the "code" name for a
> directory, and
> the value the path of that directory, with some $variable that can be
> expanded.
>
> Install schemes are stored in a private mapping, where the keys are
> usually the value of os.name,
> and the value, the mapping I've mentionned earlier.
>
> So, for example, the paths for win32 are:
>
> _INSTALL_SCHEMES = {
>  ...
>  'nt': {
>        'stdlib': '$base/Lib',
>        'platstdlib': '$base/Lib',
>        'purelib': '$base/Lib/site-packages',
>        'platlib': '$base/Lib/site-packages',
>        'include': '$base/include',
>        'platinclude': '$base/include',
>        'scripts': '$base/Scripts',
>        'data'   : '$base',
>        },
>  ...
> }
>
>
Are you using string.Template because this code needs to run on installs
older than 2.6?

-Brett




> where each key corresponds to a directory that contains some Python files:
>
> - stdlib : root of the standard library
> - platstdlib: root of platform-specific elements of the standard library
> - purelib: the site-packages directory for pure python modules
> - platlib: the site-packages directory for platform-specific modules
> - include: the include dir
> - platinclude: the include dir for platform-specific files
> - scripts: the directory where scripts are added
> - data: the directory where data file are added
>
> All these directory are read and used by:
> - distutils when a package is installed, so the install command can
> dispatch files in the right place
> - site.py, when Python is initialized
>
> IOW, any part of the stdlib can use these paths to locate and work
> with Python files.
>
> The public APIs are:
>
> * get_path_names() : returns a list of the path names ("stdlib",
> "platstdlib", etc.)
>
> * get_paths(scheme, vars)  : Returns a mapping containing an install
> scheme.
>   - "scheme" is the name of the scheme, if not provided will get the
> default scheme of the current platform
>   - vars is an optonal mapping that can provide values for the
> various $variables. Notice that they all have
>      default values, for example $base == sys.prefix.
>
>    for example: get_paths('nt')
>
> * get_path(name, scheme, vars): Returns one path corresponding to the
> scheme.
>
>  for example : get_paths('stdlib', 'nt')
>
> Those API are generic, but maybe we could add specific APIs like:
>
> * get_stdlib_path('nt')
>
> These API are basically a refactoring of what already exist in
> distutils/command/install.py
>
> == Configuration variables ==
>
> distutils.sysconfig currently provides some APIs to read values from
> files like Makefile and pyconfig.h.
>
> These API have been placed in the global sysconfig module:
>
> * get_config_vars(): return a dictionary of all configuration
> variables relevant for the current platform.
>
> * get_config_var(name): Return the value of a single variable
>
> * get_platform():  Return a string that identifies the current
> platform. (this one is used by site.py for example)
>
> * get_python_version() : return the short python version
> (sys.version[:3]) -- this one could probably go away but is useful
> because that's the marker used by Python in some paths.
>
> == code, status, next steps ==
>
> The code of the module can be viewed here, it's a revamp of
> distutils.sysconfig:
>
>
> http://svn.python.org/view/*checkout*/python/branches/tarek_sysconfig/Lib/sysconfig.py?content-type=text%2Fplain
>
> I've refactored distutils/ and site.py so they work with this new
> module, and added deprecation warnings in distutils.sysconfig.
>
> All tests pass in the branch, but note that the code is still using
> the .h and Makefile files. This will probably be removed later in
> favor of a static _sysconfig.py file generated when Python is built,
> containing the variables sysconfig reads. I'll do this second step
> after I get some feedback on the proposal.
>
> Regards
> Tarek
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091212/cd6e62a9/attachment-0001.htm>

From ziade.tarek at gmail.com  Sat Dec 12 23:13:24 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 12 Dec 2009 23:13:24 +0100
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <bbaeab100912121335x23ef592ew6d8207af2001f7fa@mail.gmail.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<bbaeab100912121335x23ef592ew6d8207af2001f7fa@mail.gmail.com>
Message-ID: <94bdd2610912121413g5783d634p9b2b65a98fe50f67@mail.gmail.com>

On Sat, Dec 12, 2009 at 10:35 PM, Brett Cannon <brett at python.org> wrote:
[...]
>> ?'nt': {
>> ? ? ? ?'stdlib': '$base/Lib',
>> ? ? ? ?'platstdlib': '$base/Lib',
>> ? ? ? ?'purelib': '$base/Lib/site-packages',
>> ? ? ? ?'platlib': '$base/Lib/site-packages',
>> ? ? ? ?'include': '$base/include',
>> ? ? ? ?'platinclude': '$base/include',
>> ? ? ? ?'scripts': '$base/Scripts',
>> ? ? ? ?'data' ? : '$base',
>> ? ? ? ?},
>> ?...
>> }
>>
>
> Are you using string.Template because this code needs to run on installs
> older than 2.6?
> -Brett

Not really. That's mostly because I reused the existing implementation
and I found them quite readable in that case. But a string.Formatter
could work well here too I guess.

Tarek

From brett at python.org  Sat Dec 12 23:18:29 2009
From: brett at python.org (Brett Cannon)
Date: Sat, 12 Dec 2009 14:18:29 -0800
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <94bdd2610912121413g5783d634p9b2b65a98fe50f67@mail.gmail.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com> 
	<bbaeab100912121335x23ef592ew6d8207af2001f7fa@mail.gmail.com> 
	<94bdd2610912121413g5783d634p9b2b65a98fe50f67@mail.gmail.com>
Message-ID: <bbaeab100912121418g604c827dq99b5acc3153ccb09@mail.gmail.com>

On Sat, Dec 12, 2009 at 14:13, Tarek Ziad? <ziade.tarek at gmail.com> wrote:

> On Sat, Dec 12, 2009 at 10:35 PM, Brett Cannon <brett at python.org> wrote:
> [...]
> >>  'nt': {
> >>        'stdlib': '$base/Lib',
> >>        'platstdlib': '$base/Lib',
> >>        'purelib': '$base/Lib/site-packages',
> >>        'platlib': '$base/Lib/site-packages',
> >>        'include': '$base/include',
> >>        'platinclude': '$base/include',
> >>        'scripts': '$base/Scripts',
> >>        'data'   : '$base',
> >>        },
> >>  ...
> >> }
> >>
> >
> > Are you using string.Template because this code needs to run on installs
> > older than 2.6?
> > -Brett
>
> Not really. That's mostly because I reused the existing implementation
> and I found them quite readable in that case. But a string.Formatter
> could work well here too I guess.


Just figured that with formatters the way of the future that
"{base}/include" would work just as well and be "future-proof".

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091212/22f44d7c/attachment.htm>

From ziade.tarek at gmail.com  Sat Dec 12 23:25:06 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 12 Dec 2009 23:25:06 +0100
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <bbaeab100912121418g604c827dq99b5acc3153ccb09@mail.gmail.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<bbaeab100912121335x23ef592ew6d8207af2001f7fa@mail.gmail.com>
	<94bdd2610912121413g5783d634p9b2b65a98fe50f67@mail.gmail.com>
	<bbaeab100912121418g604c827dq99b5acc3153ccb09@mail.gmail.com>
Message-ID: <94bdd2610912121425v59ff7982q930e072909d0de00@mail.gmail.com>

On Sat, Dec 12, 2009 at 11:18 PM, Brett Cannon <brett at python.org> wrote:
[..]
>> Not really. That's mostly because I reused the existing implementation
>> and I found them quite readable in that case. But a string.Formatter
>> could work well here too I guess.
>
> Just figured that with formatters the way of the future that
> "{base}/include" would work just as well and be "future-proof".
> -Brett

Sure, I'll change it that way, thanks for the tip

Tarek

From eric at trueblade.com  Sun Dec 13 01:03:56 2009
From: eric at trueblade.com (Eric Smith)
Date: Sat, 12 Dec 2009 19:03:56 -0500
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <94bdd2610912121413g5783d634p9b2b65a98fe50f67@mail.gmail.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>	<bbaeab100912121335x23ef592ew6d8207af2001f7fa@mail.gmail.com>
	<94bdd2610912121413g5783d634p9b2b65a98fe50f67@mail.gmail.com>
Message-ID: <4B242F6C.5050609@trueblade.com>

Tarek Ziad? wrote:
> On Sat, Dec 12, 2009 at 10:35 PM, Brett Cannon <brett at python.org> wrote:
> [...]
>>>  'nt': {
>>>        'stdlib': '$base/Lib',
>>>        'platstdlib': '$base/Lib',
>>>        'purelib': '$base/Lib/site-packages',
>>>        'platlib': '$base/Lib/site-packages',
>>>        'include': '$base/include',
>>>        'platinclude': '$base/include',
>>>        'scripts': '$base/Scripts',
>>>        'data'   : '$base',
>>>        },
>>>  ...
>>> }
>>>
>> Are you using string.Template because this code needs to run on installs
>> older than 2.6?
>> -Brett
> 
> Not really. That's mostly because I reused the existing implementation
> and I found them quite readable in that case. But a string.Formatter
> could work well here too I guess.

I don't really understand the complete context, but I think you want 
str.format(), not string.Formatter here.

Eric.

From brett at python.org  Sun Dec 13 01:43:54 2009
From: brett at python.org (Brett Cannon)
Date: Sat, 12 Dec 2009 16:43:54 -0800
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <bbaeab100912121643m31fb5d01i9ab50a497c36a61f@mail.gmail.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<bbaeab100912121335x23ef592ew6d8207af2001f7fa@mail.gmail.com>
	<94bdd2610912121413g5783d634p9b2b65a98fe50f67@mail.gmail.com>
	<4B242F6C.5050609@trueblade.com>
	<bbaeab100912121643m31fb5d01i9ab50a497c36a61f@mail.gmail.com>
Message-ID: <bbaeab100912121643y4933683ekc0131843a1586015@mail.gmail.com>

That's what I meant.

[From my phone]

On Dec 12, 2009 4:32 PM, "Eric Smith" <eric at trueblade.com> wrote:

Tarek Ziad? wrote: > > On Sat, Dec 12, 2009 at 10:35 PM, Brett Cannon <
brett at python.org> wrote: > [....
I don't really understand the complete context, but I think you want
str.format(), not string.Formatter here.

Eric.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091212/e66b2ff7/attachment.htm>

From benjamin at python.org  Sun Dec 13 02:00:00 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Sat, 12 Dec 2009 19:00:00 -0600
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <319e029f0912111232kb31e3e9j9e2ac42472db7c41@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com>
	<b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com>
	<319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com>
	<79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com>
	<319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com>
	<hfri00$5js$1@ger.gmane.org>
	<319e029f0912101219q7f1c730ai7fe12b41f3914bed@mail.gmail.com>
	<1afaf6160912101224i36562613r1462f432d6ae88ed@mail.gmail.com>
	<319e029f0912111232kb31e3e9j9e2ac42472db7c41@mail.gmail.com>
Message-ID: <1afaf6160912121700l7950617cmcbc3dce19dbcb742@mail.gmail.com>

2009/12/11 Lennart Regebro <regebro at gmail.com>:
> Should I start a bug report in the tracker for this?

Yes, please.



-- 
Regards,
Benjamin

From ben+python at benfinney.id.au  Sun Dec 13 09:53:41 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Sun, 13 Dec 2009 19:53:41 +1100
Subject: [Python-Dev] Proposing PEP 386 for addition
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<87ocm674fb.fsf@benfinney.id.au>
	<94bdd2610912101649r70ef222btd03ecfb236f2a000@mail.gmail.com>
	<87tyvy5bx8.fsf@benfinney.id.au>
	<94bdd2610912120331m37a7248eld3834aa10771481c@mail.gmail.com>
Message-ID: <87638b5k6i.fsf@benfinney.id.au>

Tarek Ziad? <ziade.tarek at gmail.com> writes:

> I've started to add another section in the PEP to summarize this
> discussion but then I realized that we are already giving the answer
> in the PEP in the "Requisites and current status"
>
> I made it clearer though, by adding an extra sentence with an example.

Thank you.

> Requesite #2 :
> """
> 2. most projects need special meaning versions for "pre-releases"
> (such as

I don't think ?most projects need? is supported by evidence.

Fortunately, for the argument in the PEP, you don't need ?most projects
need? to be true; you only need ?a significant number of projects?. It
could be a small minority, but if it is a significantly large minority
that still justifies addressing the need.

So, change this to ?a significant number of projects need? and I think
it's a fair statement.

> Let me know if you think this is enough and addresses your concern,

Thank you for working to make this a good PEP.

-- 
 \       Moriarty: ?Forty thousand million billion dollars? That money |
  `\            must be worth a fortune!? ?The Goon Show, _The Sale of |
_o__)                                                       Manhattan_ |
Ben Finney


From regebro at gmail.com  Sun Dec 13 12:13:44 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Sun, 13 Dec 2009 12:13:44 +0100
Subject: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
In-Reply-To: <1afaf6160912121700l7950617cmcbc3dce19dbcb742@mail.gmail.com>
References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com>
	<b654cd2e0912090945q421e90a0hd8c093ed82b14a82@mail.gmail.com>
	<319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com>
	<79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com>
	<319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com>
	<hfri00$5js$1@ger.gmane.org>
	<319e029f0912101219q7f1c730ai7fe12b41f3914bed@mail.gmail.com>
	<1afaf6160912101224i36562613r1462f432d6ae88ed@mail.gmail.com>
	<319e029f0912111232kb31e3e9j9e2ac42472db7c41@mail.gmail.com>
	<1afaf6160912121700l7950617cmcbc3dce19dbcb742@mail.gmail.com>
Message-ID: <319e029f0912130313h5674da4dn689c48c83fc773db@mail.gmail.com>

Issue submitted: http://bugs.python.org/issue7490

-- 
Med Vaemjelig Groet
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Sun Dec 13 12:48:16 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 13 Dec 2009 12:48:16 +0100
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <87638b5k6i.fsf@benfinney.id.au>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<87ocm674fb.fsf@benfinney.id.au>
	<94bdd2610912101649r70ef222btd03ecfb236f2a000@mail.gmail.com>
	<87tyvy5bx8.fsf@benfinney.id.au>
	<94bdd2610912120331m37a7248eld3834aa10771481c@mail.gmail.com>
	<87638b5k6i.fsf@benfinney.id.au>
Message-ID: <94bdd2610912130348x6112e219x5741d3de943c10e9@mail.gmail.com>

On Sun, Dec 13, 2009 at 9:53 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
> Tarek Ziad? <ziade.tarek at gmail.com> writes:
>
>> I've started to add another section in the PEP to summarize this
>> discussion but then I realized that we are already giving the answer
>> in the PEP in the "Requisites and current status"
>>
>> I made it clearer though, by adding an extra sentence with an example.
>
> Thank you.
>
>> Requesite #2 :
>> """
>> 2. most projects need special meaning versions for "pre-releases"
>> (such as
>
> I don't think ?most projects need? is supported by evidence.
>
> Fortunately, for the argument in the PEP, you don't need ?most projects
> need? to be true; you only need ?a significant number of projects?. It
> could be a small minority, but if it is a significantly large minority
> that still justifies addressing the need.
>
> So, change this to ?a significant number of projects need? and I think
> it's a fair statement.
>
>> Let me know if you think this is enough and addresses your concern,
>
> Thank you for working to make this a good PEP.

Done. Thanks for your help.

Tarek

From ziade.tarek at gmail.com  Sun Dec 13 12:56:50 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sun, 13 Dec 2009 12:56:50 +0100
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <4B221DA8.5060509@gmail.com>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<4B20B4D1.10502@gmail.com>
	<94bdd2610912100519n43614c84n63c37794ec8f5d7b@mail.gmail.com>
	<loom.20091210T145433-494@post.gmane.org>
	<a08e5f80912100610l48312c5do5b85c7a07376a5d1@mail.gmail.com>
	<4B221DA8.5060509@gmail.com>
Message-ID: <94bdd2610912130356r5e6d973ft2e5a414b08afa106@mail.gmail.com>

On Fri, Dec 11, 2009 at 11:23 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
[..]
>
> Eric's suggestion of NormalizedVersion sounds best to me - it exactly
> describes the intended role of the class.
>

Done. Steve Steiner added a nice functional test that tries the scheme
on *all* pypi versions:

MacZiade:distutilsver tarek$ nosetests -s .
Loading saved pypi data...
Results:
--------
Total Packages  :  8654
Already Match   :  7604.0 (87.87%)
Have Suggestion :  624.0 (7.21%)
No Suggestion   :  426.0 (4.92%)
......
----------------------------------------------------------------------
Ran 6 tests in 0.463s

OK

IOW, the current scheme works as-is for 88% of the packages, and is
able to transform
7% of the remainings. The 5% that are not workable are mostly packages
with versions
like : (extracts)

- .000001
- working proof of concept
- release candidate 3
- 1.0dev-BZR-r42-panta-elasticworld.org-20091021153851-6ijlut5dkxndxw1h
- beta pre csound
- etc..

Furthermore, I've seen some patterns in those 5% that can be worked
out so I'll probably be able to lower it to 3%

Tarek

From mal at egenix.com  Mon Dec 14 10:52:50 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 14 Dec 2009 10:52:50 +0100
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
Message-ID: <4B260AF2.3000802@egenix.com>

Tarek Ziad? wrote:
> == code, status, next steps ==
> 
> The code of the module can be viewed here, it's a revamp of distutils.sysconfig:
> 
> http://svn.python.org/view/*checkout*/python/branches/tarek_sysconfig/Lib/sysconfig.py?content-type=text%2Fplain
> 
> I've refactored distutils/ and site.py so they work with this new
> module, and added deprecation warnings in distutils.sysconfig.

I think we really need to do something about these kinds of
deprecations.

IMHO, there is no need to deprecate an entry point if the code
has just moved to some other location in the stdlib.

A simple note in the documentation and the NEWS file should be
enough to get programmers to use the new location for code that
doesn't have to work with older Python versions.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 14 2009)
>>> 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 steven.bethard at gmail.com  Mon Dec 14 19:04:00 2009
From: steven.bethard at gmail.com (Steven Bethard)
Date: Mon, 14 Dec 2009 10:04:00 -0800
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
Message-ID: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>

So there wasn't really any more feedback on the last post of the
argparse PEP other than a typo fix and another +1.

  http://www.python.org/dev/peps/pep-0389/

Can I get a pronouncement? Here's a summary of the responses. (Please
correct me if I misinterpreted anyone.)

* Floris Bruynooghe +1
* Brett Cannon +1
* Nick Coghlan +1
* Michael Foord +1
* Yuval Greenfield +1
* Doug Hellmann +1
* Kevin Jacobs +1
* Paul Moore +1
* Jesse Noller +1
* Fernando Perez +1
* Jon Ribbens +1
* Vinay Sajip +1
* Barry Warsaw +1

* Antoine Pitrou -0
* Martin v. L?wis -0

* M.-A. Lemburg -1

Note that I've interpreted those who were opposed to the deprecation
of getopt as -0 since the PEP no longer proposes that, only the
deprecation of optparse. (People who opposed optparse's deprecation
are still -1.)

If there's any other information that would be helpful for a
pronouncement, please let me know.

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
        --- The Hiphopopotamus

From dinov at microsoft.com  Mon Dec 14 19:10:01 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 14 Dec 2009 18:10:01 +0000
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD04D81D51@TK5EX14MBXC118.redmond.corp.microsoft.com>

Tarek wrote:
> == Installation schemes ==
> 
> First, the module contains the installation schemes for each platform
> CPython uses.
> An install scheme is a mapping where the key is the "code" name for a
> directory, and
> the value the path of that directory, with some $variable that can be
> expanded.
> 
> Install schemes are stored in a private mapping, where the keys are
> usually the value of os.name,
> and the value, the mapping I've mentionned earlier.
> 
> So, for example, the paths for win32 are:
> 
> _INSTALL_SCHEMES = {
>   ...
>   'nt': {
>         'stdlib': '$base/Lib',
>         'platstdlib': '$base/Lib',
>         'purelib': '$base/Lib/site-packages',
>         'platlib': '$base/Lib/site-packages',
>         'include': '$base/include',
>         'platinclude': '$base/include',
>         'scripts': '$base/Scripts',
>         'data'   : '$base',
>         },
>   ...
> }

Not mentioned here are the user schemes.  Looking at the code it seems that
_getuserbase is adding "Python" to the path on nt.  Isn't that redundant?
The paths in _INSTALL_SCHEMES already include "Python".

Also w/ user dirs in general - I think there should be some implementation 
specific portion of the path as well.  Right now I think IronPython and 
CPython will end up with the same user paths for the same versions which 
could cause problems if someone releases separate modules for IronPython
and CPython for some reason (or if users just want different sets of
things installed for different interpreters).

> * get_platform():  Return a string that identifies the current
> platform. (this one is used by site.py for example)

I wonder if this would make more sense a built-in.  Ultimately it seems 
like the interpreter implementation knows best about what aspects of
it's underlying platform would require different libraries.

With the existing code I think IronPython would return "cli" everywhere 
(because os.name == 'nt' on Windows but posix on Linux & Mac OS/X but 
we still don't have uname).  I think Jython will return something like 
java1.6.0_17 because it's os.name is java - which might be more specific
than is necessary.  

Also if the purpose of this is for platform specific build directories
it might be interesting to have multiple return values.  For example in
IronPython the minimal thing we'd want I think is a "cli" directory for
.NET assemblies.  But there could also be native extensions which are
platform specific so we'd want "cli-x86" and "cli-x64" depending upon
the platform.  Jython might want the same thing as they add ctypes
support.

From ianb at colorstudy.com  Mon Dec 14 19:22:53 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon, 14 Dec 2009 12:22:53 -0600
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
Message-ID: <b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>

On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard
<steven.bethard at gmail.com> wrote:
> So there wasn't really any more feedback on the last post of the
> argparse PEP other than a typo fix and another +1.

I just converted a script over to argparse.  It seems nice enough, I
was doing a two-level command, and it was quite handy for that.

One concern I had is that the naming seems at times trivially
different than optparse, just because "opt" or "option" is replaced by
"arg" or "argument".  So .add_option becomes .add_argument, and
OptionParser becomes ArgumentParser.  This seems unnecessary to me,
and it make converting the application harder than it had to be.  It
wasn't hard, but it could have been really easy.  There are a couple
other details like this that I think are worth resolving if argparse
really is supposed to replace optparse.

I'd change this language:
"The optparse module is deprecated, and has been replaced by the
argparse module."
To:
"The optparse module is deprecated and will not be developed further;
development will continue with the argparse module"

There's a lot of scripts using optparse, and if they are successfully
using it there's no reason to stop using it.  The proposed language
seems to imply it is wrong to keep using optparse, which I don't think
is the case.  And people can pick up on this kind of language and get
all excitable about it.

-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker

From steven.bethard at gmail.com  Mon Dec 14 19:43:14 2009
From: steven.bethard at gmail.com (Steven Bethard)
Date: Mon, 14 Dec 2009 10:43:14 -0800
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
Message-ID: <d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>

On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking <ianb at colorstudy.com> wrote:
> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard
> <steven.bethard at gmail.com> wrote:
>> So there wasn't really any more feedback on the last post of the
>> argparse PEP other than a typo fix and another +1.
>
> I just converted a script over to argparse. ?It seems nice enough, I
> was doing a two-level command, and it was quite handy for that.
>
> One concern I had is that the naming seems at times trivially
> different than optparse, just because "opt" or "option" is replaced by
> "arg" or "argument". ?So .add_option becomes .add_argument, and
> OptionParser becomes ArgumentParser. ?This seems unnecessary to me,
> and it make converting the application harder than it had to be. ?It
> wasn't hard, but it could have been really easy. ?There are a couple
> other details like this that I think are worth resolving if argparse
> really is supposed to replace optparse.

Thanks for the feedback. Could you comment further on exactly what
would be sufficient? It would be easy, for example, to add a subclass
of ArgumentParser called OptionParser that has an add_option method.
Do you also need the following things to work?

* options, args = parser.parse_args() # options and args aren't
separate in argparse
* type='int', etc. # string type names aren't used in argparse
* action='store_false' default value is None # it's True in argparse

These latter kind of changes seem sketchier to me - they would make
the initial conversion easier, but would make using argparse normally
harder.

> I'd change this language:
> "The optparse module is deprecated, and has been replaced by the
> argparse module."
> To:
> "The optparse module is deprecated and will not be developed further;
> development will continue with the argparse module"

Done. Thanks!

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
        --- The Hiphopopotamus

From ianb at colorstudy.com  Mon Dec 14 20:04:03 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon, 14 Dec 2009 13:04:03 -0600
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com> 
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com> 
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
Message-ID: <b654cd2e0912141104l345a8064j58fdcb294dcfb80c@mail.gmail.com>

On Mon, Dec 14, 2009 at 12:43 PM, Steven Bethard
<steven.bethard at gmail.com> wrote:
> On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking <ianb at colorstudy.com> wrote:
>> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard
>> <steven.bethard at gmail.com> wrote:
>>> So there wasn't really any more feedback on the last post of the
>>> argparse PEP other than a typo fix and another +1.
>>
>> I just converted a script over to argparse. ?It seems nice enough, I
>> was doing a two-level command, and it was quite handy for that.
>>
>> One concern I had is that the naming seems at times trivially
>> different than optparse, just because "opt" or "option" is replaced by
>> "arg" or "argument". ?So .add_option becomes .add_argument, and
>> OptionParser becomes ArgumentParser. ?This seems unnecessary to me,
>> and it make converting the application harder than it had to be. ?It
>> wasn't hard, but it could have been really easy. ?There are a couple
>> other details like this that I think are worth resolving if argparse
>> really is supposed to replace optparse.
>
> Thanks for the feedback. Could you comment further on exactly what
> would be sufficient? It would be easy, for example, to add a subclass
> of ArgumentParser called OptionParser that has an add_option method.
> Do you also need the following things to work?

Well, to argue against myself: having another class like OptionParser
also feels like backward compatibility cruft.  argparse is close
enough to optparse (which is good) that I just wish it was a bit
closer.

> * options, args = parser.parse_args() # options and args aren't
> separate in argparse

This is a substantive enough difference that I don't really mind it,
though if OptionParser really was a different class then maybe
parse_args should act the same as optparse.OptionParser.  What happens
if you have positional arguments, but haven't declared any such
arguments with .add_argument?  Does it just result in an error?  I
suppose it must.

> * type='int', etc. # string type names aren't used in argparse

This seems simple to support and unambiguous, so yeah.

> * action='store_false' default value is None # it's True in argparse

I don't personally care about this; I agree the None default in
optparse is sometimes peculiar (also for action='count' and
action='append', where 0 and [] are the sensible defaults).

Also I'd like %prog and %default supported, which should be fairly
simple; heck, you could just do something like usage.replace('%prog',
'%(prog)s') before substitution.  Since %prog isn't otherwise valid
(unless it was %%prog, which seems unlikely?) this seems easy.


Ideally I really wish ArgumentParser was just named OptionParser, and
that .add_argument was .add_option, and that argparse's current
parse_args was named something different, so both the optparse
parse_args (which returns (options, args)) and argparse's different
parse_args return value could coexist.  Also generally if the common
small bits of optparse (like type='int' and %prog) just worked, even
if they weren't really extensible in the same manner as optparse.

Another thing I just noticed is that argparse using -v for version
where optparse does not (it only adds --version); most of my scripts
that use -v to mean --verbose, causing problems.  Since this is a poll
question on the argparse site I assume this is an outstanding question
for argparse, but just generally I think that doing things the same
way as optparse should be preferred when at all reasonable.


-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker

From fuzzyman at voidspace.org.uk  Mon Dec 14 20:11:40 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 14 Dec 2009 19:11:40 +0000
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <b654cd2e0912141104l345a8064j58fdcb294dcfb80c@mail.gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<b654cd2e0912141104l345a8064j58fdcb294dcfb80c@mail.gmail.com>
Message-ID: <4B268DEC.8030501@voidspace.org.uk>

On 14/12/2009 19:04, Ian Bicking wrote:
> [snip...]
> Another thing I just noticed is that argparse using -v for version
> where optparse does not (it only adds --version); most of my scripts
> that use -v to mean --verbose, causing problems.  Since this is a poll
> question on the argparse site I assume this is an outstanding question
> for argparse, but just generally I think that doing things the same
> way as optparse should be preferred when at all reasonable.
>
>
>    

I also use -v for verbose in a few scripts (including options to 
unittest when run with python -m). I've seen -V as a common abbreviation 
for --version (I've just used this with Mono for example).

All the best,

Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog



From olemis at gmail.com  Mon Dec 14 20:12:48 2009
From: olemis at gmail.com (Olemis Lang)
Date: Mon, 14 Dec 2009 14:12:48 -0500
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
Message-ID: <24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com>

On Mon, Dec 14, 2009 at 1:43 PM, Steven Bethard
<steven.bethard at gmail.com> wrote:
> On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking <ianb at colorstudy.com> wrote:
>> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard
>> <steven.bethard at gmail.com> wrote:
>>> So there wasn't really any more feedback on the last post of the
>>> argparse PEP other than a typo fix and another +1.
>>
>> I just converted a script over to argparse. ?It seems nice enough, I
>> was doing a two-level command, and it was quite handy for that.
>>
>> One concern I had is that the naming seems at times trivially
>> different than optparse, just because "opt" or "option" is replaced by
>> "arg" or "argument". ?So .add_option becomes .add_argument, and
>> OptionParser becomes ArgumentParser. ?This seems unnecessary to me,
>> and it make converting the application harder than it had to be. ?It
>> wasn't hard, but it could have been really easy. ?There are a couple
>> other details like this that I think are worth resolving if argparse
>> really is supposed to replace optparse.
>
> Thanks for the feedback. Could you comment further on exactly what
> would be sufficient? It would be easy, for example, to add a subclass
> of ArgumentParser called OptionParser that has an add_option method.
> Do you also need the following things to work?
>
> * options, args = parser.parse_args() # options and args aren't
> separate in argparse
> * type='int', etc. # string type names aren't used in argparse
> * action='store_false' default value is None # it's True in argparse
>
> These latter kind of changes seem sketchier to me - they would make
> the initial conversion easier, but would make using argparse normally
> harder.
>

I thought that one of the following approaches would be considered :

  - let optparse remain in stdlib (as is or not ...)
  - re-implement optparse (i.e. a module having the same name ;o) using
    argparse

isn't it ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Free jacknife 1.3.4 v2 Download - mac software  -
http://feedproxy.google.com/~r/TracGViz-full/~3/q0HBIH_50wQ/

From simon at brunningonline.net  Mon Dec 14 20:35:08 2009
From: simon at brunningonline.net (Simon Brunning)
Date: Mon, 14 Dec 2009 19:35:08 +0000
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <b654cd2e0912141104l345a8064j58fdcb294dcfb80c@mail.gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<b654cd2e0912141104l345a8064j58fdcb294dcfb80c@mail.gmail.com>
Message-ID: <8c7f10c60912141135v58a99f9dp6f2bb0e84ffd5c3a@mail.gmail.com>

2009/12/14 Ian Bicking <ianb at colorstudy.com>:
> Another thing I just noticed is that argparse using -v for version
> where optparse does not (it only adds --version); most of my scripts
> that use -v to mean --verbose, causing problems.

Oh, me too.

-- 
Cheers,
Simon B.

From olemis at gmail.com  Mon Dec 14 20:35:21 2009
From: olemis at gmail.com (Olemis Lang)
Date: Mon, 14 Dec 2009 14:35:21 -0500
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <4B268DEC.8030501@voidspace.org.uk>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<b654cd2e0912141104l345a8064j58fdcb294dcfb80c@mail.gmail.com>
	<4B268DEC.8030501@voidspace.org.uk>
Message-ID: <24ea26600912141135o7dd98f10ka5537fb23472cd1d@mail.gmail.com>

On Mon, Dec 14, 2009 at 2:11 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> On 14/12/2009 19:04, Ian Bicking wrote:
>>
>> [snip...]
>> Another thing I just noticed is that argparse using -v for version
>> where optparse does not (it only adds --version); most of my scripts
>> that use -v to mean --verbose, causing problems. ?Since this is a poll
>> question on the argparse site I assume this is an outstanding question
>> for argparse, but just generally I think that doing things the same
>> way as optparse should be preferred when at all reasonable.
>>
>
> I also use -v for verbose in a few scripts (including options to unittest
> when run with python -m). I've seen -V as a common abbreviation for
> --version (I've just used this with Mono for example).
>

Many Unix commands accept these switches too . AFAICR there was an
standard (well ...) set of command line options for Unix systems
(can't find a link :-/ )

.. [1] Command-Line Options
        (http://www.faqs.org/docs/artu/ch10s05.html)


-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Automated init.  -
http://bitbucket.org/osimons/trac-rpc-mq/changeset/e122336d1eb2/

From solipsis at pitrou.net  Mon Dec 14 20:37:42 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 14 Dec 2009 19:37:42 +0000 (UTC)
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<b654cd2e0912141104l345a8064j58fdcb294dcfb80c@mail.gmail.com>
	<4B268DEC.8030501@voidspace.org.uk>
Message-ID: <loom.20091214T203706-854@post.gmane.org>

Michael Foord <fuzzyman <at> voidspace.org.uk> writes:
> 
> I also use -v for verbose in a few scripts (including options to 
> unittest when run with python -m). I've seen -V as a common abbreviation 
> for --version (I've just used this with Mono for example).

+1 for letting -v mean "--verbose". This is a really common wish.




From dickinsm at gmail.com  Mon Dec 14 20:38:18 2009
From: dickinsm at gmail.com (Mark Dickinson)
Date: Mon, 14 Dec 2009 19:38:18 +0000
Subject: [Python-Dev] Request commit privileges for Stefan Krah
Message-ID: <5c6f2a5d0912141138w55242a4br6dee22c574894557@mail.gmail.com>

I'd like to request that Stefan Krah be granted commit privileges to the Python
svn repository, for the sole purpose of working on a (yet to be created)
py3k-decimal-in-c branch.

Stefan has produced a C library 'libmpdec' implementing (fast!) arbitrary
precision decimal arithmetic, together with a Python extension module
'Cdecimal' that provides full compatibility with Python's decimal module.
The current version of the code can be found at:

  http://www.bytereef.org/libmpdec-download.html

It's currently licensed under the GNU Affero General Public License, but
Stefan has indicated that he's willing to relicense it to the PSF under
a contributor agreement.

We'd like to start work on a branch that integrates Stefan's work into the
Python source tree, with the hope that this work could be considered for
inclusion in py3k when it's completed.

While I haven't yet done anything resembling a thorough code review of
Stefan's code, the code I have looked at has seemed very high quality,
and gives me a high degree of confidence in its correctness.  Stefan's also
done a truly ridiculous amount of correctness and compatibility testing of
this code, and in the process discovered several corner case bugs in
Python's decimal module.

(I'm not yet asking for a decision on *whether* the decimal module should
be replaced with a C version;  that decision should be easier to make once
Stefan's code is fully integrated into the branch, and we have some timings
and benchmarks to show the performance benefit.  There are also various
other questions about a C version of decimal that will eventually need to
addressed, but I don't want to distract from the main point of this message.)

Mark

From tjreedy at udel.edu  Mon Dec 14 20:48:53 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 14 Dec 2009 14:48:53 -0500
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
Message-ID: <hg64r3$1tc$1@ger.gmane.org>

On 12/14/2009 1:43 PM, Steven Bethard wrote:
> On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking<ianb at colorstudy.com>  wrote:
>> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard
>> <steven.bethard at gmail.com>  wrote:
>>> So there wasn't really any more feedback on the last post of the
>>> argparse PEP other than a typo fix and another +1.
>>
>> I just converted a script over to argparse.  It seems nice enough, I
>> was doing a two-level command, and it was quite handy for that.
>>
>> One concern I had is that the naming seems at times trivially
>> different than optparse, just because "opt" or "option" is replaced by
>> "arg" or "argument".  So .add_option becomes .add_argument, and
>> OptionParser becomes ArgumentParser.  This seems unnecessary to me,
>> and it make converting the application harder than it had to be.  It
>> wasn't hard, but it could have been really easy.  There are a couple
>> other details like this that I think are worth resolving if argparse
>> really is supposed to replace optparse.
>
> Thanks for the feedback. Could you comment further on exactly what
> would be sufficient? It would be easy, for example, to add a subclass
> of ArgumentParser called OptionParser that has an add_option method.
> Do you also need the following things to work?
[snip]

I have not ever used optparse. So if I were to use argparse in the 
future, I would strongly prefer that it be free of back-compatibility cruft.

Would it be possible to use the 2to3 machinery to write an opt_to_arg 
conversion tool? This could easily take care of the naming differences.

Terry Jan Reedy


From steven.bethard at gmail.com  Mon Dec 14 20:55:17 2009
From: steven.bethard at gmail.com (Steven Bethard)
Date: Mon, 14 Dec 2009 11:55:17 -0800
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <24ea26600912141135o7dd98f10ka5537fb23472cd1d@mail.gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<b654cd2e0912141104l345a8064j58fdcb294dcfb80c@mail.gmail.com>
	<4B268DEC.8030501@voidspace.org.uk>
	<24ea26600912141135o7dd98f10ka5537fb23472cd1d@mail.gmail.com>
Message-ID: <d11dcfba0912141155n5ce794b9n4fc60c9606778281@mail.gmail.com>

On Mon, Dec 14, 2009 at 11:35 AM, Olemis Lang <olemis at gmail.com> wrote:
> On Mon, Dec 14, 2009 at 2:11 PM, Michael Foord
>> On 14/12/2009 19:04, Ian Bicking wrote:
>>> Another thing I just noticed is that argparse using -v for version
>>> where optparse does not (it only adds --version); most of my scripts
>>> that use -v to mean --verbose, causing problems. ?Since this is a poll
>>> question on the argparse site I assume this is an outstanding question
>>
>> I also use -v for verbose in a few scripts (including options to unittest
>> when run with python -m). I've seen -V as a common abbreviation for
>> --version (I've just used this with Mono for example).
>
> Many Unix commands accept these switches too . AFAICR there was an
> standard (well ...) set of command line options for Unix systems
> (can't find a link :-/ )

Just to be clear, argparse doesn't force you to use -v/--version.
That's just the default if you specify the version= argument to the
ArgumentParser constructor. You can configure version flags much more
flexibly using add_argument(..., action='version').

But yes, it's a poll right now on the argparse website
(http://code.google.com/p/argparse/) and if you feel strongly about
it, please add your vote there (rather than here).

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
        --- The Hiphopopotamus

From steven.bethard at gmail.com  Mon Dec 14 21:00:37 2009
From: steven.bethard at gmail.com (Steven Bethard)
Date: Mon, 14 Dec 2009 12:00:37 -0800
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com>
Message-ID: <d11dcfba0912141200k1045d1b0w322de2753ab35ca4@mail.gmail.com>

On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang <olemis at gmail.com> wrote:
> I thought that one of the following approaches would be considered :
>
> ?- let optparse remain in stdlib (as is or not ...)
> ?- re-implement optparse (i.e. a module having the same name ;o) using
> ? ?argparse
>
> isn't it ?

Please read the PEP if you haven't, particularly the "Why isn't the
functionality just being added to optparse?" section. I don't believe
it is sensible to re-implement all of optparse. What Ian Bicking is
proposing, I believe, is simpler -- adding a few aliases here and
there so that you don't have to rename so many things when you're
upgrading from optparse to argparse.

For what it's worth, I'm still not sure it's a good idea, for exactly
the reason Ian points out - "having another class like OptionParser
also feels like backward compatibility cruft".

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
        --- The Hiphopopotamus

From tim.peters at gmail.com  Mon Dec 14 21:01:54 2009
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 14 Dec 2009 15:01:54 -0500
Subject: [Python-Dev] Request commit privileges for Stefan Krah
In-Reply-To: <5c6f2a5d0912141138w55242a4br6dee22c574894557@mail.gmail.com>
References: <5c6f2a5d0912141138w55242a4br6dee22c574894557@mail.gmail.com>
Message-ID: <1f7befae0912141201h73a42c19q2409126a94e0e3ad@mail.gmail.com>

[Mark Dickinson]
> I'd like to request that Stefan Krah be granted commit privileges to the Python
> svn repository, for the sole purpose of working on a (yet to be created)
> py3k-decimal-in-c branch.

+1.  I haven't commented on any of this, but I've watched it, and
Stefan appears easy enough to work with and does very high-quality
work.


> ...
> (I'm not yet asking for a decision on *whether* the decimal module should
> be replaced with a C version; ?that decision should be easier to make once
> Stefan's code is fully integrated into the branch, and we have some timings
> and benchmarks to show the performance benefit. ?There are also various
> other questions about a C version of decimal that will eventually need to
> addressed, but I don't want to distract from the main point of this message.)

Me neither, which is why I repeated that part ;-)  A development
branch is exactly the right thing to do at this point, and Stefan
needs commit privs to work on that.

From olemis at gmail.com  Mon Dec 14 21:20:45 2009
From: olemis at gmail.com (Olemis Lang)
Date: Mon, 14 Dec 2009 15:20:45 -0500
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <d11dcfba0912141200k1045d1b0w322de2753ab35ca4@mail.gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com>
	<d11dcfba0912141200k1045d1b0w322de2753ab35ca4@mail.gmail.com>
Message-ID: <24ea26600912141220l5cd6c001o20bcd7538cfd05c7@mail.gmail.com>

On Mon, Dec 14, 2009 at 3:00 PM, Steven Bethard
<steven.bethard at gmail.com> wrote:
> On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang <olemis at gmail.com> wrote:
>> I thought that one of the following approaches would be considered :
>>
>> ?- let optparse remain in stdlib (as is or not ...)
>> ?- re-implement optparse (i.e. a module having the same name ;o) using
>> ? ?argparse
>>
>> isn't it ?
>
> Please read the PEP if you haven't, particularly the "Why isn't the
> functionality just being added to optparse?" section. I don't believe
> it is sensible to re-implement all of optparse. What Ian Bicking is
> proposing, I believe, is simpler -- adding a few aliases here and
> there so that you don't have to rename so many things when you're
> upgrading from optparse to argparse.
>

Well, I was actually thinking about adding such aliases in that module
and leave argparse just like it is today (and make the aliases as
compatible with optparse as possible ;o). So probably we're talking
about very similar things that will be placed in different places in
stdlib .

> For what it's worth, I'm still not sure it's a good idea,

... at least that way changes to have optparse-like interface will be
in a separate module. Or otherwise implement optparse like shown below

{{{
#!python

from argparse.optparse import *
}}}

and do the rest in argparse (it's the same anyway ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Initial version of protocol-provider patch. Patch does not currently
apply cleanly - it hasn'...  -
http://bitbucket.org/osimons/trac-rpc-mq/changeset/b302540a1608/

From ncoghlan at gmail.com  Mon Dec 14 21:21:05 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Dec 2009 06:21:05 +1000
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <loom.20091214T203706-854@post.gmane.org>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>	<b654cd2e0912141104l345a8064j58fdcb294dcfb80c@mail.gmail.com>	<4B268DEC.8030501@voidspace.org.uk>
	<loom.20091214T203706-854@post.gmane.org>
Message-ID: <4B269E31.6060408@gmail.com>

Antoine Pitrou wrote:
> Michael Foord <fuzzyman <at> voidspace.org.uk> writes:
>> I also use -v for verbose in a few scripts (including options to 
>> unittest when run with python -m). I've seen -V as a common abbreviation 
>> for --version (I've just used this with Mono for example).
> 
> +1 for letting -v mean "--verbose". This is a really common wish.

Agreed, all my scripts do that. -V is the short form I expect for --version.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From solipsis at pitrou.net  Mon Dec 14 21:20:52 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 14 Dec 2009 20:20:52 +0000 (UTC)
Subject: [Python-Dev] Request commit privileges for Stefan Krah
References: <5c6f2a5d0912141138w55242a4br6dee22c574894557@mail.gmail.com>
Message-ID: <loom.20091214T211902-41@post.gmane.org>


Hello,

Mark Dickinson <dickinsm <at> gmail.com> writes:
> 
> I'd like to request that Stefan Krah be granted commit privileges to the Python
> svn repository, for the sole purpose of working on a (yet to be created)
> py3k-decimal-in-c branch.

Regardless of whether the commit rights are granted (I am not against it), isn't
it sufficient to clone one of the Mercurial branches at
http://code.python.org/hg and maintain a public py3k-decimal-in-c branch
somewhere (e.g. bitbucket)?

Or would hosting the branch in the SVN give it the required visibility?

Regards

Antoine.



From solipsis at pitrou.net  Mon Dec 14 21:35:22 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 14 Dec 2009 20:35:22 +0000 (UTC)
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com>
	<d11dcfba0912141200k1045d1b0w322de2753ab35ca4@mail.gmail.com>
Message-ID: <loom.20091214T213355-735@post.gmane.org>

Steven Bethard <steven.bethard <at> gmail.com> writes:
> 
> Please read the PEP if you haven't, particularly the "Why isn't the
> functionality just being added to optparse?" section. I don't believe
> it is sensible to re-implement all of optparse. What Ian Bicking is
> proposing, I believe, is simpler -- adding a few aliases here and
> there so that you don't have to rename so many things when you're
> upgrading from optparse to argparse.

Although I am of the people who think working modules shouldn't be deprecated, I
also don't think adding compatibility aliases is a good idea. They only make the
APIs more bloated and maintenance more tedious. Let's keep the new APIs clean of
any unnecessary baggage.

Regards

Antoine.



From ncoghlan at gmail.com  Mon Dec 14 21:46:23 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Dec 2009 06:46:23 +1000
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <d11dcfba0912141200k1045d1b0w322de2753ab35ca4@mail.gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>	<24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com>
	<d11dcfba0912141200k1045d1b0w322de2753ab35ca4@mail.gmail.com>
Message-ID: <4B26A41F.5020009@gmail.com>

Steven Bethard wrote:
> On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang <olemis at gmail.com> wrote:
>> I thought that one of the following approaches would be considered :
>>
>>  - let optparse remain in stdlib (as is or not ...)
>>  - re-implement optparse (i.e. a module having the same name ;o) using
>>    argparse
>>
>> isn't it ?
> 
> Please read the PEP if you haven't, particularly the "Why isn't the
> functionality just being added to optparse?" section. I don't believe
> it is sensible to re-implement all of optparse. What Ian Bicking is
> proposing, I believe, is simpler -- adding a few aliases here and
> there so that you don't have to rename so many things when you're
> upgrading from optparse to argparse.
> 
> For what it's worth, I'm still not sure it's a good idea, for exactly
> the reason Ian points out - "having another class like OptionParser
> also feels like backward compatibility cruft".

People also need to remember the very conservative deprecation path for
optparse proposed in the PEP - never deprecated in 2.x, and only a
PendingDeprecationWarning in 3.x up until 3.4 (likely to happen some
time in 2013).

With that kind of slow deprecation path, adding further backwards
compatibility cruft to argparse itself seems redundant - the name
changes from option to argument were instituted for a reason (since the
scope of argparse really is wider than that of optparse).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From starsareblueandfaraway at gmail.com  Mon Dec 14 22:04:56 2009
From: starsareblueandfaraway at gmail.com (Roy Hyunjin Han)
Date: Mon, 14 Dec 2009 16:04:56 -0500
Subject: [Python-Dev] Splitting something into two steps produces
	different behavior from doing it in one fell swoop in Python 2.6.2
In-Reply-To: <4B22EB05.5010803@gmail.com>
References: <6a5569ec0912111031i55790214if78e3aaa5708c7dc@mail.gmail.com>
	<4B229144.7030204@gmail.com> <4B22A0E7.6080107@mrabarnett.plus.com>
	<6a5569ec0912111252s54f14115ifa48cc3f54b7cae0@mail.gmail.com>
	<4B22EB05.5010803@gmail.com>
Message-ID: <6a5569ec0912141304t35f94791n6b45a20ca9442a83@mail.gmail.com>

On Fri, Dec 11, 2009 at 7:59 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> It follows the standard left-to-right evaluation order within an expression:
>
> <subexpr1>(<subexpr2>)
>
> (i.e. a function call always determines which function is going to be
> called before determining any arguments to be passed)
>
> Splitting it into two lines then clearly changes the evaluation order:
>
> temp = <subexpr2>
> <subexpr1>(temp)
>
> I'm not sure what behaviour could be suggested as being more intuitive -
> the problem in this case arose due to both referencing and mutating the
> same object in a single statement, which is always going to be
> problematic from an ordering point of view, since it depends on subtle
> details of statement definitions that people often won't know. Better to
> split the mutation and the reference into separate statements so the
> intended order is clear regardless of how well the reader knows the
> subtleties of Python's evaluation order.
>
> Cheers,
> Nick.
>

Thanks for the explanation, Nick.  I understand what is happening now.
 y[1].update resolves to the update() method of the old set referenced
by y[1], but this set is then popped so that the update() manages to
change the old set, but not the new one that is returned by any
subsequent reference to y[1].  I suppose I will have to keep this in
two statements.  A similar thing happened with the SWIG extensions for
GDAL, in which one had to separate statements so that SWIG objects
were not destroyed prematurely, i.e. no more one-liners.

From olemis at gmail.com  Mon Dec 14 22:10:20 2009
From: olemis at gmail.com (Olemis Lang)
Date: Mon, 14 Dec 2009 16:10:20 -0500
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <4B26A41F.5020009@gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com>
	<d11dcfba0912141200k1045d1b0w322de2753ab35ca4@mail.gmail.com>
	<4B26A41F.5020009@gmail.com>
Message-ID: <24ea26600912141310w77d07c42hc244f9ecc1642b9f@mail.gmail.com>

On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Steven Bethard wrote:
>> On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang <olemis at gmail.com> wrote:
>>> I thought that one of the following approaches would be considered :
>>>
>>> ?1 - let optparse remain in stdlib (as is or not ...)
>>> ?2 - re-implement optparse (i.e. a module having the same name ;o) using
>>> ? ?argparse
>>>
>>> isn't it ?
>>
>> Please read the PEP if you haven't, particularly the "Why isn't the
>> functionality just being added to optparse?" section. I don't believe
>> it is sensible to re-implement all of optparse.
>>
[...]
>>
>> For what it's worth, I'm still not sure it's a good idea, for exactly
>> the reason Ian points out - "having another class like OptionParser
>> also feels like backward compatibility cruft".
>
> People also need to remember the very conservative deprecation path for
> optparse proposed in the PEP - never deprecated in 2.x,

So, I don't get it . What's the difference between this and the first
option I mentioned above ? I am probably missing the obvious but if
optparse will be ?never deprecated in 2.x? then what's gonna happen ?
The only options I see are mentioned above (and I thought it was the
first one ;o) :

  - If (1) is the right one then -0 for considering backwards compatibility
  - If (2) is the right one then IMO, +1 for adding ?further backwards
    compatibility cruft? in a separate module and remove it in Python 3.5

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Looking for a technique to create flexible, graphical dashboards ...
- http://feedproxy.google.com/~r/TracGViz-full/~3/r7Zcyrg1n3U/019aa74e7095d047

From dickinsm at gmail.com  Mon Dec 14 22:17:51 2009
From: dickinsm at gmail.com (Mark Dickinson)
Date: Mon, 14 Dec 2009 21:17:51 +0000
Subject: [Python-Dev] Request commit privileges for Stefan Krah
In-Reply-To: <loom.20091214T211902-41@post.gmane.org>
References: <5c6f2a5d0912141138w55242a4br6dee22c574894557@mail.gmail.com>
	<loom.20091214T211902-41@post.gmane.org>
Message-ID: <5c6f2a5d0912141317o2535f224q3315d7a522ef1924@mail.gmail.com>

On Mon, Dec 14, 2009 at 8:20 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Mark Dickinson <dickinsm <at> gmail.com> writes:
>> I'd like to request that Stefan Krah be granted commit privileges to the Python
>> svn repository, for the sole purpose of working on a (yet to be created)
>> py3k-decimal-in-c branch.
>
> Regardless of whether the commit rights are granted (I am not against it), isn't
> it sufficient to clone one of the Mercurial branches at
> http://code.python.org/hg and maintain a public py3k-decimal-in-c branch
> somewhere (e.g. bitbucket)?

Sure;  I guess that would work too, especially if there's a preference
for hg over
svn.  It might be nice to have the commit history in the official
repository, though.

Mark

From dinov at microsoft.com  Mon Dec 14 22:45:11 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Mon, 14 Dec 2009 21:45:11 +0000
Subject: [Python-Dev] Microsoft contributor agreement received?
Message-ID: <1A472770E042064698CB5ADC83A12ACD04D8F72D@TK5EX14MBXC118.redmond.corp.microsoft.com>

I'm not sure the best place to verify this so I'm starting here.  I'm told we finally faxed in our contributor agreement (to the number listed at http://www.python.org/psf/contrib/) about a week and a half ago.  I'd just like to make sure that someone has received it.  Is anyone here able to confirm that it went through fine?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091214/9860300b/attachment.htm>

From ziade.tarek at gmail.com  Mon Dec 14 23:12:42 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 14 Dec 2009 23:12:42 +0100
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <4B260AF2.3000802@egenix.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<4B260AF2.3000802@egenix.com>
Message-ID: <94bdd2610912141412s22f04dc6i94b713ade0d8b90a@mail.gmail.com>

On Mon, Dec 14, 2009 at 10:52 AM, M.-A. Lemburg <mal at egenix.com> wrote:
[..]
>> I've refactored distutils/ and site.py so they work with this new
>> module, and added deprecation warnings in distutils.sysconfig.
>
> I think we really need to do something about these kinds of
> deprecations.
>
> IMHO, there is no need to deprecate an entry point if the code
> has just moved to some other location in the stdlib.
>
> A simple note in the documentation and the NEWS file should be
> enough to get programmers to use the new location for code that
> doesn't have to work with older Python versions.

There are both cases in fact: some APIs have just moved, and some have
changed. So I guess I could keep a deprecation warning only for the
latter.

Regards
Tarek

From steven.bethard at gmail.com  Mon Dec 14 23:37:43 2009
From: steven.bethard at gmail.com (Steven Bethard)
Date: Mon, 14 Dec 2009 14:37:43 -0800
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <24ea26600912141310w77d07c42hc244f9ecc1642b9f@mail.gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com>
	<d11dcfba0912141200k1045d1b0w322de2753ab35ca4@mail.gmail.com>
	<4B26A41F.5020009@gmail.com>
	<24ea26600912141310w77d07c42hc244f9ecc1642b9f@mail.gmail.com>
Message-ID: <d11dcfba0912141437h66ee8fa8he8c9c2287b7dbdd3@mail.gmail.com>

On Mon, Dec 14, 2009 at 1:10 PM, Olemis Lang <olemis at gmail.com> wrote:
> On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang <olemis at gmail.com> wrote:
>>>> I thought that one of the following approaches would be considered :
>>>> ?1 - let optparse remain in stdlib (as is or not ...)
>>>> ?2 - re-implement optparse (i.e. a module having the same name ;o) using
>>>> ? ?argparse
>>
>> People also need to remember the very conservative deprecation path for
>> optparse proposed in the PEP - never deprecated in 2.x,
>
> So, I don't get it . What's the difference between this and the first
> option I mentioned above ? I am probably missing the obvious but if
> optparse will be ?never deprecated in 2.x? then what's gonna happen ?
> The only options I see are mentioned above (and I thought it was the
> first one ;o) :
>
> ?- If (1) is the right one then -0 for considering backwards compatibility
> ?- If (2) is the right one then IMO, +1 for adding ?further backwards
> ? ?compatibility cruft? in a separate module and remove it in Python 3.5

If you're only concerned about 2.X, then yes, optparse will *never* be
removed from 2.X. There will be a deprecation note in the 2.X
documentation but deprecation warnings will only be issued when the -3
flag is specified. Please see the "Deprecation of optparse" section of
the PEP:

http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
        --- The Hiphopopotamus

From ben+python at benfinney.id.au  Mon Dec 14 23:43:52 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 15 Dec 2009 09:43:52 +1100
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<b654cd2e0912141104l345a8064j58fdcb294dcfb80c@mail.gmail.com>
Message-ID: <87hbrt41nb.fsf@benfinney.id.au>

Ian Bicking <ianb at colorstudy.com> writes:

> Ideally I really wish ArgumentParser was just named OptionParser, and
> that .add_argument was .add_option, and that argparse's current
> parse_args was named something different, so both the optparse
> parse_args (which returns (options, args)) and argparse's different
> parse_args return value could coexist.

-1 for pretending that ?option? and ?argument? mean the same thing. They
really don't (the former is a strict subset of the latter), and it would
be confusing legacy cruft if argparse had names that imply it. The names
chosen in the argparse library are good.

> if OptionParser really was a different class then maybe parse_args
> should act the same as optparse.OptionParser.

+1 for ?optparse API and external behaviour re-implemented as an
?optparse? module using argparse as the underlying implementation?, to
allow exactly the sort of ease of transition you're describing.

Of course, that +1 is only support for ?someone else does the work?. I
don't need optparse to remain if I have argparse in the standard
library. +0 for deprecating optparse.

-- 
 \        ?? it's best to confuse only one issue at a time.? ?Brian W. |
  `\    Kernighan and Dennis M. Ritchie, _The C programming language_, |
_o__)                                                             1988 |
Ben Finney


From ziade.tarek at gmail.com  Mon Dec 14 23:58:08 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 14 Dec 2009 23:58:08 +0100
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD04D81D51@TK5EX14MBXC118.redmond.corp.microsoft.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD04D81D51@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <94bdd2610912141458m52da21ear4970506a37214e6@mail.gmail.com>

2009/12/14 Dino Viehland <dinov at microsoft.com>:
[..]
> Not mentioned here are the user schemes. ?Looking at the code it seems that
> _getuserbase is adding "Python" to the path on nt. ?Isn't that redundant?
> The paths in _INSTALL_SCHEMES already include "Python".
>

Right that's a small bug in the refactoring (there's an extra /) but
there will be a bit of redundancy
on "Python", at the end nevertheless:

The base directory in win32 for the user scheme in is :

APPDATA *or* ~/Python

(under linux it's ~/.local)

then various subdirectories are added in that directory, and some of
them starts with "PythonXY", like:

~/Python/Python26/..

See http://www.python.org/dev/peps/pep-0370/#specification


> Also w/ user dirs in general - I think there should be some implementation
> specific portion of the path as well. ?Right now I think IronPython and
> CPython will end up with the same user paths for the same versions which
> could cause problems if someone releases separate modules for IronPython
> and CPython for some reason (or if users just want different sets of
> things installed for different interpreters).

Yes that's one point someone raised (can't recall who) and the idea was to
have a separate top directory for user dirs, that would start with the name
of the implementation:

so for Windows:

~/Python/Python26/..
~/IronPython/../
~/Jython/../

and for Linux and al, I am not sure but maybe a prefix for
Jython/etc.. could be used
for all paths.

~/.locale/lib/python/2.6/site-packages/...
~/.locale/jython/lib/python/2.6/site-packages/...

(I didn't digg on how Jython organizes things yet, any hint would be
appreciated)

>
>> * get_platform(): ?Return a string that identifies the current
>> platform. (this one is used by site.py for example)
>
> I wonder if this would make more sense a built-in. ?Ultimately it seems
> like the interpreter implementation knows best about what aspects of
> it's underlying platform would require different libraries.
>
> With the existing code I think IronPython would return "cli" everywhere
> (because os.name == 'nt' on Windows but posix on Linux & Mac OS/X but
> we still don't have uname). ?I think Jython will return something like
> java1.6.0_17 because it's os.name is java - which might be more specific
> than is necessary.

Ok so it sounds like it would be easier to cook that value in a built-in in each
implementation,

>
> Also if the purpose of this is for platform specific build directories
> it might be interesting to have multiple return values. ?For example in
> IronPython the minimal thing we'd want I think is a "cli" directory for
> .NET assemblies. ?But there could also be native extensions which are
> platform specific so we'd want "cli-x86" and "cli-x64" depending upon
> the platform. ?Jython might want the same thing as they add ctypes
> support.

So like, having an architecture marker, that defaults to the current ?

   get_platform(architecture=platform.architecture)

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From solipsis at pitrou.net  Tue Dec 15 00:17:00 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 14 Dec 2009 23:17:00 +0000 (UTC)
Subject: [Python-Dev] First draft of "sysconfig"
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD04D81D51@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <loom.20091215T001328-630@post.gmane.org>

Dino Viehland <dinov <at> microsoft.com> writes:
> 
> > * get_platform():  Return a string that identifies the current
> > platform. (this one is used by site.py for example)
> 
> I wonder if this would make more sense a built-in.  Ultimately it seems 
> like the interpreter implementation knows best about what aspects of
> it's underlying platform would require different libraries.

I don't think it makes sense to make a builtin of such a little used,
non-performance critical API.
If we want to factor out all implementation-specific things, we could add a
module dedicated to that (e.g. "_interpreter") and have other modules (os,
platform, sysconfig...) draw from that.

Regards

Antoine.



From dinov at microsoft.com  Tue Dec 15 01:00:12 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Tue, 15 Dec 2009 00:00:12 +0000
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <94bdd2610912141458m52da21ear4970506a37214e6@mail.gmail.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD04D81D51@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<94bdd2610912141458m52da21ear4970506a37214e6@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD04D9042D@TK5EX14MBXC118.redmond.corp.microsoft.com>

Tarek wrote:
> 
> (I didn't digg on how Jython organizes things yet, any hint would be
> appreciated)

The installation directory looks like it's organized just like CPython
but I have no clue how user directories would/should be arranged.

> 
> >
> > Also if the purpose of this is for platform specific build directories
> > it might be interesting to have multiple return values. ?For example in
> > IronPython the minimal thing we'd want I think is a "cli" directory for
> > .NET assemblies. ?But there could also be native extensions which are
> > platform specific so we'd want "cli-x86" and "cli-x64" depending upon
> > the platform. ?Jython might want the same thing as they add ctypes
> > support.
> 
> So like, having an architecture marker, that defaults to the current ?
> 
>    get_platform(architecture=platform.architecture)
> 

How would you know what other architectures would be valid to pass in 
here?  Returning a list would let the implementation say that it knows
a certain set of architectural binaries are valid.



From dinov at microsoft.com  Tue Dec 15 01:11:26 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Tue, 15 Dec 2009 00:11:26 +0000
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <loom.20091215T001328-630@post.gmane.org>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD04D81D51@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<loom.20091215T001328-630@post.gmane.org>
Message-ID: <1A472770E042064698CB5ADC83A12ACD04D90462@TK5EX14MBXC118.redmond.corp.microsoft.com>

Antoine wrote:
> Dino Viehland <dinov <at> microsoft.com> writes:
> >
> > > * get_platform():  Return a string that identifies the current
> > > platform. (this one is used by site.py for example)
> >
> > I wonder if this would make more sense a built-in.  Ultimately it seems
> > like the interpreter implementation knows best about what aspects of
> > it's underlying platform would require different libraries.
> 
> I don't think it makes sense to make a builtin of such a little used,
> non-performance critical API.
> If we want to factor out all implementation-specific things, we could add a
> module dedicated to that (e.g. "_interpreter") and have other modules (os,
> platform, sysconfig...) draw from that.

Putting this in an _interpreter module is fine with me (or even putting
it somewhere in sys works - e.g. there was a sys.implementation discussion
not too long ago).  The important thing is that the interpreter
implementation really is the one that understands what binaries they
would be compatible with it regardless of how often it gets used and
how it performs.

If it's not a built-in then I think we'd be in a world where either every
implementation needs to patch this file in their distribution or contribute
a change back to support their implementation and that just seems ugly. And
it's already a very large function even w/o IronPython, Jython, PyPy and
Unladen Swallow support.


From ssteinerx at gmail.com  Tue Dec 15 01:16:23 2009
From: ssteinerx at gmail.com (ssteinerX@gmail.com)
Date: Mon, 14 Dec 2009 19:16:23 -0500
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <loom.20091214T203706-854@post.gmane.org>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<b654cd2e0912141104l345a8064j58fdcb294dcfb80c@mail.gmail.com>
	<4B268DEC.8030501@voidspace.org.uk>
	<loom.20091214T203706-854@post.gmane.org>
Message-ID: <35352AE5-878D-4074-B684-729EE8BB27C9@gmail.com>


On Dec 14, 2009, at 2:37 PM, Antoine Pitrou wrote:

> Michael Foord <fuzzyman <at> voidspace.org.uk> writes:
>> 
>> I also use -v for verbose in a few scripts (including options to 
>> unittest when run with python -m). I've seen -V as a common abbreviation 
>> for --version (I've just used this with Mono for example).
> 
> +1 for letting -v mean "--verbose". This is a really common wish.

+1, -v == --verbose

S


From brett at python.org  Tue Dec 15 01:17:50 2009
From: brett at python.org (Brett Cannon)
Date: Mon, 14 Dec 2009 16:17:50 -0800
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <loom.20091214T213355-735@post.gmane.org>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com> 
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com> 
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com> 
	<24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com> 
	<d11dcfba0912141200k1045d1b0w322de2753ab35ca4@mail.gmail.com> 
	<loom.20091214T213355-735@post.gmane.org>
Message-ID: <bbaeab100912141617x25d7049bqd299f83c97428fc1@mail.gmail.com>

On Mon, Dec 14, 2009 at 12:35, Antoine Pitrou <solipsis at pitrou.net> wrote:

> Steven Bethard <steven.bethard <at> gmail.com> writes:
> >
> > Please read the PEP if you haven't, particularly the "Why isn't the
> > functionality just being added to optparse?" section. I don't believe
> > it is sensible to re-implement all of optparse. What Ian Bicking is
> > proposing, I believe, is simpler -- adding a few aliases here and
> > there so that you don't have to rename so many things when you're
> > upgrading from optparse to argparse.
>
> Although I am of the people who think working modules shouldn't be
> deprecated, I
> also don't think adding compatibility aliases is a good idea. They only
> make the
> APIs more bloated and maintenance more tedious. Let's keep the new APIs
> clean of
> any unnecessary baggage.
>

Ditto from me. If people want a compatible module it can be made available
on PyPI for those who want it.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091214/66c1a0c2/attachment.htm>

From benjamin at python.org  Tue Dec 15 01:21:32 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Mon, 14 Dec 2009 18:21:32 -0600
Subject: [Python-Dev] Microsoft contributor agreement received?
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD04D8F72D@TK5EX14MBXC118.redmond.corp.microsoft.com>
References: <1A472770E042064698CB5ADC83A12ACD04D8F72D@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <1afaf6160912141621p17282b88vc7cab4aa975791b1@mail.gmail.com>

2009/12/14 Dino Viehland <dinov at microsoft.com>:
> I?m not sure the best place to verify this so I?m starting here.

psf at python.org is better.


-- 
Regards,
Benjamin

From ssteinerx at gmail.com  Tue Dec 15 01:24:21 2009
From: ssteinerx at gmail.com (ssteinerX@gmail.com)
Date: Mon, 14 Dec 2009 19:24:21 -0500
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <d11dcfba0912141155n5ce794b9n4fc60c9606778281@mail.gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<b654cd2e0912141104l345a8064j58fdcb294dcfb80c@mail.gmail.com>
	<4B268DEC.8030501@voidspace.org.uk>
	<24ea26600912141135o7dd98f10ka5537fb23472cd1d@mail.gmail.com>
	<d11dcfba0912141155n5ce794b9n4fc60c9606778281@mail.gmail.com>
Message-ID: <D0DCE21A-9C10-47F6-9C27-57BFF904E3FB@gmail.com>


On Dec 14, 2009, at 2:55 PM, Steven Bethard wrote:

> On Mon, Dec 14, 2009 at 11:35 AM, Olemis Lang <olemis at gmail.com> wrote:
>> On Mon, Dec 14, 2009 at 2:11 PM, Michael Foord
>>> On 14/12/2009 19:04, Ian Bicking wrote:
>>>> Another thing I just noticed is that argparse using -v for version
>>>> where optparse does not (it only adds --version); most of my scripts
>>>> that use -v to mean --verbose, causing problems.  Since this is a poll
>>>> question on the argparse site I assume this is an outstanding question
>>> 
>>> I also use -v for verbose in a few scripts (including options to unittest
>>> when run with python -m). I've seen -V as a common abbreviation for
>>> --version (I've just used this with Mono for example).
>> 
>> Many Unix commands accept these switches too . AFAICR there was an
>> standard (well ...) set of command line options for Unix systems
>> (can't find a link :-/ )

How about this one:

http://www.shelldorado.com/goodcoding/cmdargs.html#flagnames

S


From ssteinerx at gmail.com  Tue Dec 15 01:25:32 2009
From: ssteinerx at gmail.com (ssteinerX@gmail.com)
Date: Mon, 14 Dec 2009 19:25:32 -0500
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <d11dcfba0912141155n5ce794b9n4fc60c9606778281@mail.gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<b654cd2e0912141104l345a8064j58fdcb294dcfb80c@mail.gmail.com>
	<4B268DEC.8030501@voidspace.org.uk>
	<24ea26600912141135o7dd98f10ka5537fb23472cd1d@mail.gmail.com>
	<d11dcfba0912141155n5ce794b9n4fc60c9606778281@mail.gmail.com>
Message-ID: <D97D5E57-46C8-44D0-88FC-8D454F9599E0@gmail.com>


On Dec 14, 2009, at 2:55 PM, Steven Bethard wrote:

> But yes, it's a poll right now on the argparse website
> (http://code.google.com/p/argparse/) and if you feel strongly about
> it, please add your vote there (rather than here).

I don't even understand what the poll question is asking.

S


From kmtracey at gmail.com  Tue Dec 15 01:28:08 2009
From: kmtracey at gmail.com (Karen Tracey)
Date: Mon, 14 Dec 2009 19:28:08 -0500
Subject: [Python-Dev] Issue 3745 backwards incompatibility
Message-ID: <af3536270912141628q147b7bb8we5d3b11554bef213@mail.gmail.com>

In testing some existing code with the 2.7 alpha release, I've run into:

    TypeError: Unicode-objects must be encoded before hashing

when the existing code tries to pass unicode objects to hashlib.sha1 and
hashlib.md5.  This is, I believe, due to changes made for issue 3745:

http://bugs.python.org/issue3745

The issue states the need to reject unencoded strings based on the fact that
one backend implementation (openssl) refused to accept them while another
(_sha256) assumed a utf-8 encoding.  The thing is, I cannot observe any such
difference using Python 2.5 or 2.6.  Instead of what is shown in the ticket
(which was done on a Python 3, I believe) I see, when I adjust the demo test
to use Python 2 syntax for "unencoded strings":

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import _hashlib
>>> _hashlib.openssl_sha256(u"\xff")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\xff' in position
0: ordinal not in range(128)
>>> import _sha256
>>> _sha256.sha256(u'\xff')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\xff' in position
0: ordinal not in range(128)
>>>

(Sample from Windows because that's the only place I can get import _sha256
to work.  The Ubuntu Linux I tried behaves the same way as above for the
_hashlib version, while it doesn't appear to have _sha256 as an option.)

So from what I can see the behavior wasn't inconsistent from
backend-to-backend in Python 2 but rather fell in line with what I'm
familiar with: if you pass unicode to some code that only wants bytes, the
unicode object will get encoded to a bytestring using the system default
encoding. No problems if the data can in fact always be encoded using that
encoding, the error above if the data can't be encoded. Changing these
functions to now require the caller to do the encoding explicitly ahead of
time strikes me as introducing an inconsistency. Plus it introduces a
backwards incompatibility in Python 2.7.  Is this really necessary?

Karen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091214/fb269268/attachment.htm>

From ssteinerx at gmail.com  Tue Dec 15 01:34:09 2009
From: ssteinerx at gmail.com (ssteinerX@gmail.com)
Date: Mon, 14 Dec 2009 19:34:09 -0500
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <loom.20091214T213355-735@post.gmane.org>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com>
	<d11dcfba0912141200k1045d1b0w322de2753ab35ca4@mail.gmail.com>
	<loom.20091214T213355-735@post.gmane.org>
Message-ID: <56CF2170-397D-4E90-A3F6-90ADB2FA5C74@gmail.com>


On Dec 14, 2009, at 3:35 PM, Antoine Pitrou wrote:

> Steven Bethard <steven.bethard <at> gmail.com> writes:
>> 
>> Please read the PEP if you haven't, particularly the "Why isn't the
>> functionality just being added to optparse?" section. I don't believe
>> it is sensible to re-implement all of optparse. What Ian Bicking is
>> proposing, I believe, is simpler -- adding a few aliases here and
>> there so that you don't have to rename so many things when you're
>> upgrading from optparse to argparse.
> 
> Although I am of the people who think working modules shouldn't be deprecated, I
> also don't think adding compatibility aliases is a good idea. They only make the
> APIs more bloated and maintenance more tedious. Let's keep the new APIs clean of
> any unnecessary baggage.

Agreed.  If you want to make an "adapter" to do things like convert 'int' to int, then call the new API then fine, but don't start crufting up a new API to make it 'easier' to convert.  

All crufting it up does is make it _less_ clear how to use the new API by bring along things that don't belong in it.

S


From ianb at colorstudy.com  Tue Dec 15 02:00:09 2009
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon, 14 Dec 2009 19:00:09 -0600
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <56CF2170-397D-4E90-A3F6-90ADB2FA5C74@gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com> 
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com> 
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com> 
	<24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com> 
	<d11dcfba0912141200k1045d1b0w322de2753ab35ca4@mail.gmail.com> 
	<loom.20091214T213355-735@post.gmane.org>
	<56CF2170-397D-4E90-A3F6-90ADB2FA5C74@gmail.com>
Message-ID: <b654cd2e0912141700j5d4f0643yc54383ee72caff5c@mail.gmail.com>

On Mon, Dec 14, 2009 at 6:34 PM, ssteinerX at gmail.com
<ssteinerx at gmail.com> wrote:
>> Although I am of the people who think working modules shouldn't be deprecated, I
>> also don't think adding compatibility aliases is a good idea. They only make the
>> APIs more bloated and maintenance more tedious. Let's keep the new APIs clean of
>> any unnecessary baggage.
>
> Agreed. ?If you want to make an "adapter" to do things like convert 'int' to int, then call the new API then fine, but don't start crufting up a new API to make it 'easier' to convert.
>
> All crufting it up does is make it _less_ clear how to use the new API by bring along things that don't belong in it.

The "new" API is almost exactly like the old optparse API.  It's not
like it's some shining jewel of perfection that would be tainted by
somehow being similar to optparse when it's almost exactly like
optparse already.

If it wasn't like optparse, then fine, whatever; but it *is* like
optparse, so these differences feel unnecessary.  Converting 'int' to
int internally in argparse is hardly difficult or unclear.

If argparse doesn't do this, then I think at least it should give good
error messages for all cases where these optparse-isms remain.  For
instance, now if you include %prog in your usage you get: ValueError:
unsupported format character 'p' (0x70) at index 1 -- that's simply a
bad error message.  Giving a proper error message takes about as much
code as making %prog work.  I don't feel strongly that one is better
than the other, but at least one of those should be done.


-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker

From steven.bethard at gmail.com  Tue Dec 15 02:54:33 2009
From: steven.bethard at gmail.com (Steven Bethard)
Date: Mon, 14 Dec 2009 17:54:33 -0800
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <35352AE5-878D-4074-B684-729EE8BB27C9@gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<b654cd2e0912141104l345a8064j58fdcb294dcfb80c@mail.gmail.com>
	<4B268DEC.8030501@voidspace.org.uk>
	<loom.20091214T203706-854@post.gmane.org>
	<35352AE5-878D-4074-B684-729EE8BB27C9@gmail.com>
Message-ID: <d11dcfba0912141754s5a39d5b6lf4144d16c1bc057a@mail.gmail.com>

On Mon, Dec 14, 2009 at 4:16 PM, ssteinerX at gmail.com
<ssteinerx at gmail.com> wrote:
>
> On Dec 14, 2009, at 2:37 PM, Antoine Pitrou wrote:
>
>> Michael Foord <fuzzyman <at> voidspace.org.uk> writes:
>>>
>>> I also use -v for verbose in a few scripts (including options to
>>> unittest when run with python -m). I've seen -V as a common abbreviation
>>> for --version (I've just used this with Mono for example).
>>
>> +1 for letting -v mean "--verbose". This is a really common wish.
>
> +1, -v == --verbose

Because people are continuing this discussion, I'll say again that
argparse already supports this:

>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('-v', '--verbose', action='store_true')
>>> parser.parse_args(['-v'])
Namespace(verbose=True)

If you want to also have a -V/--version argument, you can do that too:

>>> parser.add_argument('-V', '--version', action='version', version='3.5')
>>> parser.parse_args(['-V'])
3.5

And now back to our regularly scheduled discussion of actual PEP issues. ;-)

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
        --- The Hiphopopotamus

From brett at python.org  Tue Dec 15 04:11:16 2009
From: brett at python.org (Brett Cannon)
Date: Mon, 14 Dec 2009 19:11:16 -0800
Subject: [Python-Dev] Microsoft contributor agreement received?
In-Reply-To: <1afaf6160912141621p17282b88vc7cab4aa975791b1@mail.gmail.com>
References: <1A472770E042064698CB5ADC83A12ACD04D8F72D@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<1afaf6160912141621p17282b88vc7cab4aa975791b1@mail.gmail.com>
Message-ID: <bbaeab100912141911i4478c4d4kff9140f85bbaee1c@mail.gmail.com>

On Mon, Dec 14, 2009 at 16:21, Benjamin Peterson <benjamin at python.org>wrote:

> 2009/12/14 Dino Viehland <dinov at microsoft.com>:
> > I?m not sure the best place to verify this so I?m starting here.
>
> psf at python.org is better.
>
>
The board has confirmed with Dino that we got the agreement.

-Brett



>
> --
> Regards,
> Benjamin
> _______________________________________________
> 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: <http://mail.python.org/pipermail/python-dev/attachments/20091214/80d9556f/attachment.htm>

From david.lyon at preisshare.net  Tue Dec 15 04:07:45 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 14 Dec 2009 22:07:45 -0500
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
Message-ID: <0a500cc770721944b33036da1cb5b3f3@preisshare.net>


Hi Tarek,

Is there anything in this proposal for windows developers ?

Just that I can't see anything that would help us...

For me, the terminology isn't anything a windows developer could
really understand. It presumes that the developer understands the
python implementation. A developer might not understand all those
details and might not be interested to learn.

I accept that the terminology is good on linux.. but it's near
meaningless on windows - for me - anyway.

David

On Sat, 12 Dec 2009 21:02:13 +0100, Tarek Ziad? <ziade.tarek at gmail.com>
wrote:
> Hello,
> 
> A while ago I've proposed to refactor the APIs that provides access to
> the installation paths and configuration variables at runtime into a
> single module called "sysconfig", and make it easier for all
> implementations to work with them.
> 
> I've started a branch and worked on it, and I'd like to ask here for
> some feedback. And in particular from Jython and IronPython people
> because they would probably need to work in that file for their
> implementation and/or propose things to add. My understanding is that
> we have people like Phillip (Jenvey), Michael F., Frank W. in this
> list so they can comment directly and I don't need to cross-post this
> mail elsewhere.
> 
> == Installation schemes ==
> 
> First, the module contains the installation schemes for each platform
> CPython uses.
> An install scheme is a mapping where the key is the "code" name for a
> directory, and
> the value the path of that directory, with some $variable that can be
> expanded.
> 
> Install schemes are stored in a private mapping, where the keys are
> usually the value of os.name,
> and the value, the mapping I've mentionned earlier.
> 
> So, for example, the paths for win32 are:
> 
> _INSTALL_SCHEMES = {
>   ...
>   'nt': {
>         'stdlib': '$base/Lib',
>         'platstdlib': '$base/Lib',
>         'purelib': '$base/Lib/site-packages',
>         'platlib': '$base/Lib/site-packages',
>         'include': '$base/include',
>         'platinclude': '$base/include',
>         'scripts': '$base/Scripts',
>         'data'   : '$base',
>         },
>   ...
> }
> 
> where each key corresponds to a directory that contains some Python
files:
> 
> - stdlib : root of the standard library
> - platstdlib: root of platform-specific elements of the standard library
> - purelib: the site-packages directory for pure python modules
> - platlib: the site-packages directory for platform-specific modules
> - include: the include dir
> - platinclude: the include dir for platform-specific files
> - scripts: the directory where scripts are added
> - data: the directory where data file are added
> 
> All these directory are read and used by:
> - distutils when a package is installed, so the install command can
> dispatch files in the right place
> - site.py, when Python is initialized
> 
> IOW, any part of the stdlib can use these paths to locate and work
> with Python files.
> 
> The public APIs are:
> 
> * get_path_names() : returns a list of the path names ("stdlib",
> "platstdlib", etc.)
> 
> * get_paths(scheme, vars)  : Returns a mapping containing an install
> scheme.
>    - "scheme" is the name of the scheme, if not provided will get the
> default scheme of the current platform
>    - vars is an optonal mapping that can provide values for the
> various $variables. Notice that they all have
>       default values, for example $base == sys.prefix.
> 
>     for example: get_paths('nt')
> 
> * get_path(name, scheme, vars): Returns one path corresponding to the
> scheme.
> 
>   for example : get_paths('stdlib', 'nt')
> 
> Those API are generic, but maybe we could add specific APIs like:
> 
> * get_stdlib_path('nt')
> 
> These API are basically a refactoring of what already exist in
> distutils/command/install.py
> 
> == Configuration variables ==
> 
> distutils.sysconfig currently provides some APIs to read values from
> files like Makefile and pyconfig.h.
> 
> These API have been placed in the global sysconfig module:
> 
> * get_config_vars(): return a dictionary of all configuration
> variables relevant for the current platform.
> 
> * get_config_var(name): Return the value of a single variable
> 
> * get_platform():  Return a string that identifies the current
> platform. (this one is used by site.py for example)
> 
> * get_python_version() : return the short python version
> (sys.version[:3]) -- this one could probably go away but is useful
> because that's the marker used by Python in some paths.
> 
> == code, status, next steps ==
> 
> The code of the module can be viewed here, it's a revamp of
> distutils.sysconfig:
> 
>
http://svn.python.org/view/*checkout*/python/branches/tarek_sysconfig/Lib/sysconfig.py?content-type=text%2Fplain
> 
> I've refactored distutils/ and site.py so they work with this new
> module, and added deprecation warnings in distutils.sysconfig.
> 
> All tests pass in the branch, but note that the code is still using
> the .h and Makefile files. This will probably be removed later in
> favor of a static _sysconfig.py file generated when Python is built,
> containing the variables sysconfig reads. I'll do this second step
> after I get some feedback on the proposal.
> 
> Regards
> Tarek

From skippy.hammond at gmail.com  Tue Dec 15 04:40:56 2009
From: skippy.hammond at gmail.com (Mark Hammond)
Date: Tue, 15 Dec 2009 14:40:56 +1100
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <0a500cc770721944b33036da1cb5b3f3@preisshare.net>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<0a500cc770721944b33036da1cb5b3f3@preisshare.net>
Message-ID: <4B270548.2090600@gmail.com>

On 15/12/2009 2:07 PM, David Lyon wrote:
>
> Hi Tarek,
>
> Is there anything in this proposal for windows developers ?
>
> Just that I can't see anything that would help us...

So I understand - help doing what?

> For me, the terminology isn't anything a windows developer could
> really understand. It presumes that the developer understands the
> python implementation. A developer might not understand all those
> details and might not be interested to learn.

That seems true for all operating systems, not just Windows.  The vast 
majority of Python programmers will probably never need to use this 
feature, but those who do will need to understand enough of the python 
implementation to make sense of the values returned regardless of the OS.

> I accept that the terminology is good on linux.. but it's near
> meaningless on windows - for me - anyway.

I think it is fine.  If you are really looking for properties specific 
to the operating system (eg, the location of the start menu, desktop, 
appdata folders etc) I don't think they belong in this PEP; they are a 
property of the OS install/version, not of the specific Python 
install/version.

Cheers,

Mark

From david.lyon at preisshare.net  Tue Dec 15 04:42:19 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 14 Dec 2009 22:42:19 -0500
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <4B270548.2090600@gmail.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<0a500cc770721944b33036da1cb5b3f3@preisshare.net>
	<4B270548.2090600@gmail.com>
Message-ID: <e8b797fbaaa6f22cdc43ca843a3a9f83@preisshare.net>

On Tue, 15 Dec 2009 14:40:56 +1100, Mark Hammond <skippy.hammond at gmail.com>
wrote:

> I think it is fine.  If you are really looking for properties specific 
> to the operating system (eg, the location of the start menu, desktop, 
> appdata folders etc) 

But under windows, an application developer might (as in probably
would) like to install an application in \Program Files\someapp
rather than hidden in the bowels of the python interpretor.

They might like their data in "Application Data", which is where
support people get trained to look for application data. Not down
in \pythonX.Y\ ...

> I don't think they belong in this PEP; they are a 
> property of the OS install/version, not of the specific Python 
> install/version.

Yes - exactly. My point.

The operating system says that programs should be installed into
"Program Files" and data into "Application Data". Why can not
python respect the operating system directions for well behaved
apps?

David





From david.lyon at preisshare.net  Tue Dec 15 05:01:44 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 14 Dec 2009 23:01:44 -0500
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <94bdd2610912141458m52da21ear4970506a37214e6@mail.gmail.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD04D81D51@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<94bdd2610912141458m52da21ear4970506a37214e6@mail.gmail.com>
Message-ID: <0b0157f10a34b9ab058ccd3f71679e3a@preisshare.net>

On Mon, 14 Dec 2009 23:58:08 +0100, Tarek Ziad? <ziade.tarek at gmail.com>
wrote:
> Yes that's one point someone raised (can't recall who) and the idea was
to
> have a separate top directory for user dirs, that would start with the
name
> of the implementation:
> 
> so for Windows:
> 
> ~/Python/Python26/..
> ~/IronPython/../
> ~/Jython/../

I follow your reasoning. But application developers (and traditional
windows developers) have an upside-down view of that.

They might think that python is just the language interpreter, and
that it should just stay 'out-of-the-way'.

For example, mercurial and many python based apps include the python
as a sub-app to their own. Just neccessary to run the application.

That is the way it is for commercial windows apps. We want the
python interpretor installed, and then we want our apps (that
we get paid money for) to sit at the top.

Not the other way round, sitting beneath the language interpreter.

This is pretty much the way it has been for windows for close on
15 years now.

Regards

David




From mhammond at skippinet.com.au  Tue Dec 15 05:05:18 2009
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 15 Dec 2009 15:05:18 +1100
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <e8b797fbaaa6f22cdc43ca843a3a9f83@preisshare.net>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<0a500cc770721944b33036da1cb5b3f3@preisshare.net>
	<4B270548.2090600@gmail.com>
	<e8b797fbaaa6f22cdc43ca843a3a9f83@preisshare.net>
Message-ID: <4B270AFE.1060505@skippinet.com.au>

On 15/12/2009 2:42 PM, David Lyon wrote:
> On Tue, 15 Dec 2009 14:40:56 +1100, Mark Hammond<skippy.hammond at gmail.com>
> wrote:
>
>> I think it is fine.  If you are really looking for properties specific
>> to the operating system (eg, the location of the start menu, desktop,
>> appdata folders etc)
>
> But under windows, an application developer might (as in probably
> would) like to install an application in \Program Files\someapp
> rather than hidden in the bowels of the python interpretor.

I agree - but in that case you are talking about an application built 
with Python - that is a different set of requirements.  But regardless 
of where Python itself lives the returned values will be correct; they 
will not reflect the operating system preference for various other 
folders, but will correctly return the paths they are documented as 
returning.

IOW, this isn't designed for applications which happen to be written in 
Python.  There might be a case for such a module to be created, but this 
PEP doesn't attempt to solve that particular problem.

> They might like their data in "Application Data", which is where
> support people get trained to look for application data. Not down
> in \pythonX.Y\ ...

Nothing is stopping them from doing that - but this PEP isn't intended 
to provide that information.

>> I don't think they belong in this PEP; they are a
>> property of the OS install/version, not of the specific Python
>> install/version.
>
> Yes - exactly. My point.
>
> The operating system says that programs should be installed into
> "Program Files" and data into "Application Data". Why can not
> python respect the operating system directions for well behaved
> apps?

It does - many applications written in Python exist which do exactly 
that.  If a user really wants to install Python itself under "\Program 
Files", sysconfig should correctly reflect that.  Python doesn't care 
where it is installed, or even when it is (sensibly) bundled with an app 
which is designed to be "stand-alone".

You are after operating system properties - I understand your need to 
know those paths (and there are already reasonable Windows specific ways 
to get them), but sysconfig isn't trying to solve that for you and I 
agree it should not attempt to.

Mark

From ben+python at benfinney.id.au  Tue Dec 15 05:12:57 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 15 Dec 2009 15:12:57 +1100
Subject: [Python-Dev] First draft of "sysconfig"
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<0a500cc770721944b33036da1cb5b3f3@preisshare.net>
	<4B270548.2090600@gmail.com>
	<e8b797fbaaa6f22cdc43ca843a3a9f83@preisshare.net>
Message-ID: <87zl5k3meu.fsf@benfinney.id.au>

David Lyon <david.lyon at preisshare.net> writes:

> On Tue, 15 Dec 2009 14:40:56 +1100, Mark Hammond <skippy.hammond at gmail.com>
> wrote:
>
> > I think it is fine. If you are really looking for properties
> > specific to the operating system (eg, the location of the start
> > menu, desktop, appdata folders etc)
>
> But under windows, an application developer might (as in probably
> would) like to install an application in \Program Files\someapp rather
> than hidden in the bowels of the python interpretor.
>
> They might like their data in "Application Data", which is where
> support people get trained to look for application data. Not down in
> \pythonX.Y\ ...

Similarly, GNU operating system distributions usually have documentation
separate from programs, separate from configuration files, separate from
static data, separate from mutable data.

> > I don't think they belong in this PEP; they are a property of the OS
> > install/version, not of the specific Python install/version.

I think the ?sysconfig? specification should allow for *extension*,
without needing a modified specification each time a new distinct
location is requested.

That is, those developers and packagers who don't need a gamut of system
locations can stick to a minimal set, while those who need many can use
them, and those who need many can extend the set compatibly.

-- 
 \       ?If you make people think they're thinking, they'll love you; |
  `\     but if you really make them think, they'll hate you.? ?Donald |
_o__)                                             Robert Perry Marquis |
Ben Finney


From david.lyon at preisshare.net  Tue Dec 15 05:09:33 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 14 Dec 2009 23:09:33 -0500
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <4B270AFE.1060505@skippinet.com.au>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<0a500cc770721944b33036da1cb5b3f3@preisshare.net>
	<4B270548.2090600@gmail.com>
	<e8b797fbaaa6f22cdc43ca843a3a9f83@preisshare.net>
	<4B270AFE.1060505@skippinet.com.au>
Message-ID: <30a87fe1344a9a8c6aa0e25ee099bb43@preisshare.net>

On Tue, 15 Dec 2009 15:05:18 +1100, Mark Hammond
<mhammond at skippinet.com.au>
wrote:
>> But under windows, an application developer might (as in probably
>> would) like to install an application in \Program Files\someapp
>> rather than hidden in the bowels of the python interpretor.
> 
> I agree - but in that case you are talking about an application built 
> with Python - that is a different set of requirements.  

Building an application with python.. that's right. Of course. Why not?

> IOW, this isn't designed for applications which happen to be written in 
> Python.  There might be a case for such a module to be created, but this 
> PEP doesn't attempt to solve that particular problem.

But programmers might want to write an application with python. It
doesn't seem like such an edge-case thing to do.

>> They might like their data in "Application Data", which is where
>> support people get trained to look for application data. Not down
>> in \pythonX.Y\ ...
> 
> Nothing is stopping them from doing that - but this PEP isn't intended 
> to provide that information.

Distutils is stopping them.

> It does - many applications written in Python exist which do exactly 
> that.  

Yes. And they don't use any of the built in facilities, under windows.

> If a user really wants to install Python itself under "\Program 
> Files", sysconfig should correctly reflect that.  Python doesn't care 
> where it is installed, or even when it is (sensibly) bundled with an app 
> which is designed to be "stand-alone".

No debate about that.

> You are after operating system properties - I understand your need to 
> know those paths (and there are already reasonable Windows specific ways 
> to get them), but sysconfig isn't trying to solve that for you and I 
> agree it should not attempt to.

So under windows, then, what is it trying to solve? Thats what I am
asking.

David




From mhammond at skippinet.com.au  Tue Dec 15 05:24:36 2009
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 15 Dec 2009 15:24:36 +1100
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <30a87fe1344a9a8c6aa0e25ee099bb43@preisshare.net>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<0a500cc770721944b33036da1cb5b3f3@preisshare.net>
	<4B270548.2090600@gmail.com>
	<e8b797fbaaa6f22cdc43ca843a3a9f83@preisshare.net>
	<4B270AFE.1060505@skippinet.com.au>
	<30a87fe1344a9a8c6aa0e25ee099bb43@preisshare.net>
Message-ID: <4B270F84.5030802@skippinet.com.au>

On 15/12/2009 3:09 PM, David Lyon wrote:
> On Tue, 15 Dec 2009 15:05:18 +1100, Mark Hammond
> <mhammond at skippinet.com.au>
> wrote:
>>> But under windows, an application developer might (as in probably
>>> would) like to install an application in \Program Files\someapp
>>> rather than hidden in the bowels of the python interpretor.
>>
>> I agree - but in that case you are talking about an application built
>> with Python - that is a different set of requirements.
>
> Building an application with python.. that's right. Of course. Why not?

I'm missing your point - many applications exist written in Python.

>> IOW, this isn't designed for applications which happen to be written in
>> Python.  There might be a case for such a module to be created, but this
>> PEP doesn't attempt to solve that particular problem.
>
> But programmers might want to write an application with python. It
> doesn't seem like such an edge-case thing to do.

They can, and they have.  So again your point is lost on me.

>>> They might like their data in "Application Data", which is where
>>> support people get trained to look for application data. Not down
>>> in \pythonX.Y\ ...
>>
>> Nothing is stopping them from doing that - but this PEP isn't intended
>> to provide that information.
>
> Distutils is stopping them.

I don't agree with that and I can present many applications as evidence. 
  You yourself mentioned mercurial and it looks for mercurial.ini in the 
user's appdata directory.

Regardless, this discussion isn't about distutils.

>> It does - many applications written in Python exist which do exactly
>> that.
>
> Yes. And they don't use any of the built in facilities, under windows.

To continue the mercurial example - mercurial will not use sysconfig to 
determine where to look for mercurial.ini on *any* operating system. 
sysconfig is not about solving that particular problem.

> So under windows, then, what is it trying to solve? Thats what I am
> asking.

The same thing it is trying to solve for non-Windows users - various 
threads here have articulated this well.  You needn't feel bad about not 
having such use-cases yourself - that simply means sysconfig isn't 
targetted at you - it isn't targetted at application developers on any 
operating system.

Cheers,

Mark

From david.lyon at preisshare.net  Tue Dec 15 05:39:02 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 14 Dec 2009 23:39:02 -0500
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <4B270F84.5030802@skippinet.com.au>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<0a500cc770721944b33036da1cb5b3f3@preisshare.net>
	<4B270548.2090600@gmail.com>
	<e8b797fbaaa6f22cdc43ca843a3a9f83@preisshare.net>
	<4B270AFE.1060505@skippinet.com.au>
	<30a87fe1344a9a8c6aa0e25ee099bb43@preisshare.net>
	<4B270F84.5030802@skippinet.com.au>
Message-ID: <822785ca33912a9c6656ef6d36ae0be9@preisshare.net>

On Tue, 15 Dec 2009 15:24:36 +1100, Mark Hammond
<mhammond at skippinet.com.au>
wrote:
>>>> But under windows, an application developer might (as in probably
>>>> would) like to install an application in \Program Files\someapp
>>>> rather than hidden in the bowels of the python interpretor.
> ...
> I'm missing your point ....

The point is that if somebody writes an application in C, they
will generally speaking not want (under say linux) for that
application to live in the C compiler directory.

Same goes for many other languages.

The point is not controversial in other languages. And it
shouldn't be here either.

>> Distutils is stopping them.
> 
> I don't agree with that and I can present many applications as evidence.

Please do - if you wish. 

>   You yourself mentioned mercurial and it looks for mercurial.ini in the 
> user's appdata directory.

Sure. There's growing support within the python interpretor for things
like that. But Mercurial uses an external installer. Like NSIS, to
overcome the deficiencies that I am pointing out.

> .. it isn't targetted at application developers on any operating system.

I see.

I get it now. Thanks. 

David


From ncoghlan at gmail.com  Tue Dec 15 10:32:55 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Dec 2009 19:32:55 +1000
Subject: [Python-Dev] Request commit privileges for Stefan Krah
In-Reply-To: <5c6f2a5d0912141317o2535f224q3315d7a522ef1924@mail.gmail.com>
References: <5c6f2a5d0912141138w55242a4br6dee22c574894557@mail.gmail.com>	<loom.20091214T211902-41@post.gmane.org>
	<5c6f2a5d0912141317o2535f224q3315d7a522ef1924@mail.gmail.com>
Message-ID: <4B2757C7.9030803@gmail.com>

Mark Dickinson wrote:
> Sure;  I guess that would work too, especially if there's a preference
> for hg over
> svn.  It might be nice to have the commit history in the official
> repository, though.

Using an SVN branch also means the checkins can be reviewed as they go
by on python-checkins. I'll at least keep a casual eye on this branch if
that happens, but I wouldn't go out of my way to follow it on a hg branch.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From floris.bruynooghe at gmail.com  Tue Dec 15 10:32:55 2009
From: floris.bruynooghe at gmail.com (Floris Bruynooghe)
Date: Tue, 15 Dec 2009 09:32:55 +0000
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <822785ca33912a9c6656ef6d36ae0be9@preisshare.net>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<0a500cc770721944b33036da1cb5b3f3@preisshare.net>
	<4B270548.2090600@gmail.com>
	<e8b797fbaaa6f22cdc43ca843a3a9f83@preisshare.net>
	<4B270AFE.1060505@skippinet.com.au>
	<30a87fe1344a9a8c6aa0e25ee099bb43@preisshare.net>
	<4B270F84.5030802@skippinet.com.au>
	<822785ca33912a9c6656ef6d36ae0be9@preisshare.net>
Message-ID: <20091215093255.GA13198@laurie.devork>

On Mon, Dec 14, 2009 at 11:39:02PM -0500, David Lyon wrote:
> On Tue, 15 Dec 2009 15:24:36 +1100, Mark Hammond
> <mhammond at skippinet.com.au>
> wrote:
> >>>> But under windows, an application developer might (as in probably
> >>>> would) like to install an application in \Program Files\someapp
> >>>> rather than hidden in the bowels of the python interpretor.
> > ...
> > I'm missing your point ....
> 
> The point is that if somebody writes an application in C, they
> will generally speaking not want (under say linux) for that
> application to live in the C compiler directory.
> 
> Same goes for many other languages.
> 
> The point is not controversial in other languages. And it
> shouldn't be here either.

If I write a shared library under C I am expected to install it under
one of the default locations if I don't want to require people to have
to tweak things before they can use it.  I see no difference with
python modules or packages.  Any private modules or packages used by
an application built using python don't have to be on the sys.path by
default (in fact I would encourage them not to be).


> >> Distutils is stopping them.

Distutils isn't perfect but solves the need of installing public
modules and packages quite well.


Regards
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

From solipsis at pitrou.net  Tue Dec 15 10:34:27 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 15 Dec 2009 09:34:27 +0000 (UTC)
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<b654cd2e0912141104l345a8064j58fdcb294dcfb80c@mail.gmail.com>
	<4B268DEC.8030501@voidspace.org.uk>
	<loom.20091214T203706-854@post.gmane.org>
	<35352AE5-878D-4074-B684-729EE8BB27C9@gmail.com>
	<d11dcfba0912141754s5a39d5b6lf4144d16c1bc057a@mail.gmail.com>
Message-ID: <loom.20091215T103311-280@post.gmane.org>

Steven Bethard <steven.bethard <at> gmail.com> writes:
> 
> Because people are continuing this discussion, I'll say again that
> argparse already supports this:

Well I think the point is that if there is a default, the default should be
sensible and not run against expectations.
It would probably be fine not to have a default at all, too.

Regards

Antoine.



From ziade.tarek at gmail.com  Tue Dec 15 10:41:58 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 15 Dec 2009 10:41:58 +0100
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD04D9042D@TK5EX14MBXC118.redmond.corp.microsoft.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD04D81D51@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<94bdd2610912141458m52da21ear4970506a37214e6@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD04D9042D@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <94bdd2610912150141i158deb54j603eba56f781402e@mail.gmail.com>

On Tue, Dec 15, 2009 at 1:00 AM, Dino Viehland <dinov at microsoft.com> wrote:
[..]
> How would you know what other architectures would be valid to pass in
> here? ?Returning a list would let the implementation say that it knows
> a certain set of architectural binaries are valid.

How would you use it when a list is returned ? Can you provide a few
examples where
the code wants to know the default architecture for the current platform ? etc.

Tarek

From ziade.tarek at gmail.com  Tue Dec 15 10:46:47 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 15 Dec 2009 10:46:47 +0100
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <87zl5k3meu.fsf@benfinney.id.au>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<0a500cc770721944b33036da1cb5b3f3@preisshare.net>
	<4B270548.2090600@gmail.com>
	<e8b797fbaaa6f22cdc43ca843a3a9f83@preisshare.net>
	<87zl5k3meu.fsf@benfinney.id.au>
Message-ID: <94bdd2610912150146i7ecea732i69eed492b700026b@mail.gmail.com>

On Tue, Dec 15, 2009 at 5:12 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
[..]
>
>> > I don't think they belong in this PEP; they are a property of the OS
>> > install/version, not of the specific Python install/version.
>
> I think the ?sysconfig? specification should allow for *extension*,
> without needing a modified specification each time a new distinct
> location is requested.
>
> That is, those developers and packagers who don't need a gamut of system
> locations can stick to a minimal set, while those who need many can use
> them, and those who need many can extend the set compatibly.

That's part of the idea, get_path() is a generic API that would allow
any implementation
to add extra paths if needed. The keys I have provided are the
existing keys we have
in distutils and some extra keys that removes all the custo code that
was building
paths using os.path.join here and there in the stdlib.

Now I didn't add an API to allow dynamic insertion of new paths
because I don't see a use case
for that : if a packager wants to work with an extra path, she can
work at the project level
by providing custom distutils commands to do the job.

Unless you have another use case in mind ?

Tarek

From mal at egenix.com  Tue Dec 15 12:23:12 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 15 Dec 2009 12:23:12 +0100
Subject: [Python-Dev] Issue 3745 backwards incompatibility
In-Reply-To: <af3536270912141628q147b7bb8we5d3b11554bef213@mail.gmail.com>
References: <af3536270912141628q147b7bb8we5d3b11554bef213@mail.gmail.com>
Message-ID: <4B2771A0.8040309@egenix.com>

Karen Tracey wrote:
> In testing some existing code with the 2.7 alpha release, I've run into:
> 
>     TypeError: Unicode-objects must be encoded before hashing
> 
> when the existing code tries to pass unicode objects to hashlib.sha1 and
> hashlib.md5.  This is, I believe, due to changes made for issue 3745:
> 
> http://bugs.python.org/issue3745
> 
> The issue states the need to reject unencoded strings based on the fact that
> one backend implementation (openssl) refused to accept them while another
> (_sha256) assumed a utf-8 encoding.  The thing is, I cannot observe any such
> difference using Python 2.5 or 2.6.  Instead of what is shown in the ticket
> (which was done on a Python 3, I believe) I see, when I adjust the demo test
> to use Python 2 syntax for "unencoded strings":

I think this was a misunderstanding during the issue 3745 processing:
the patch should not have been backported to trunk at all.

For Python 3.x, the change was correct. For 2.x, a -3 warning
would have been a better fit.

Note that the non-OpenSSL SHA et al. modules have never defaulted to
encoding to UTF-8 in Python 2.x. Python 2.x uses ASCII as default
encoding. Only Python 3.x uses UTF-8 as default encoding.

I've added a note to the issue and reopened it.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 15 2009)
>>> 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 fuzzyman at voidspace.org.uk  Tue Dec 15 12:29:56 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 15 Dec 2009 11:29:56 +0000
Subject: [Python-Dev] Issue 3745 backwards incompatibility
In-Reply-To: <4B2771A0.8040309@egenix.com>
References: <af3536270912141628q147b7bb8we5d3b11554bef213@mail.gmail.com>
	<4B2771A0.8040309@egenix.com>
Message-ID: <4B277334.3010302@voidspace.org.uk>

On 15/12/2009 11:23, M.-A. Lemburg wrote:
> Karen Tracey wrote:
>    
>> In testing some existing code with the 2.7 alpha release, I've run into:
>>
>>      TypeError: Unicode-objects must be encoded before hashing
>>
>> when the existing code tries to pass unicode objects to hashlib.sha1 and
>> hashlib.md5.  This is, I believe, due to changes made for issue 3745:
>>
>> http://bugs.python.org/issue3745
>>
>> The issue states the need to reject unencoded strings based on the fact that
>> one backend implementation (openssl) refused to accept them while another
>> (_sha256) assumed a utf-8 encoding.  The thing is, I cannot observe any such
>> difference using Python 2.5 or 2.6.  Instead of what is shown in the ticket
>> (which was done on a Python 3, I believe) I see, when I adjust the demo test
>> to use Python 2 syntax for "unencoded strings":
>>      
> I think this was a misunderstanding during the issue 3745 processing:
> the patch should not have been backported to trunk at all.
>
> For Python 3.x, the change was correct. For 2.x, a -3 warning
> would have been a better fit.
>
> Note that the non-OpenSSL SHA et al. modules have never defaulted to
> encoding to UTF-8 in Python 2.x. Python 2.x uses ASCII as default
> encoding. Only Python 3.x uses UTF-8 as default encoding.
>    

Doesn't Python 3 use the *platform* encoding as the default (which 
happens to be UTF-8 on sensible systems but is something truly horrible 
like CP1250 on Windows)? (So *assuming* a default encoding of UTF-8 is 
still incorrect on Python 3 if we are being consistent with other IO 
behaviour.)

All the best,

Michael

> I've added a note to the issue and reopened it.
>
>    


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog



From mal at egenix.com  Tue Dec 15 12:40:41 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 15 Dec 2009 12:40:41 +0100
Subject: [Python-Dev] Issue 3745 backwards incompatibility
In-Reply-To: <4B277334.3010302@voidspace.org.uk>
References: <af3536270912141628q147b7bb8we5d3b11554bef213@mail.gmail.com>	<4B2771A0.8040309@egenix.com>
	<4B277334.3010302@voidspace.org.uk>
Message-ID: <4B2775B9.1080301@egenix.com>

Michael Foord wrote:
> On 15/12/2009 11:23, M.-A. Lemburg wrote:
>> Karen Tracey wrote:
>>   
>>> In testing some existing code with the 2.7 alpha release, I've run into:
>>>
>>>      TypeError: Unicode-objects must be encoded before hashing
>>>
>>> when the existing code tries to pass unicode objects to hashlib.sha1 and
>>> hashlib.md5.  This is, I believe, due to changes made for issue 3745:
>>>
>>> http://bugs.python.org/issue3745
>>>
>>> The issue states the need to reject unencoded strings based on the
>>> fact that
>>> one backend implementation (openssl) refused to accept them while
>>> another
>>> (_sha256) assumed a utf-8 encoding.  The thing is, I cannot observe
>>> any such
>>> difference using Python 2.5 or 2.6.  Instead of what is shown in the
>>> ticket
>>> (which was done on a Python 3, I believe) I see, when I adjust the
>>> demo test
>>> to use Python 2 syntax for "unencoded strings":
>>>      
>> I think this was a misunderstanding during the issue 3745 processing:
>> the patch should not have been backported to trunk at all.
>>
>> For Python 3.x, the change was correct. For 2.x, a -3 warning
>> would have been a better fit.
>>
>> Note that the non-OpenSSL SHA et al. modules have never defaulted to
>> encoding to UTF-8 in Python 2.x. Python 2.x uses ASCII as default
>> encoding. Only Python 3.x uses UTF-8 as default encoding.
>>    
> 
> Doesn't Python 3 use the *platform* encoding as the default (which
> happens to be UTF-8 on sensible systems but is something truly horrible
> like CP1250 on Windows)? (So *assuming* a default encoding of UTF-8 is
> still incorrect on Python 3 if we are being consistent with other IO
> behaviour.)

Internally, it uses UTF-8 as default encoding, ie. when implicitly
converting unicode to bytes, e.g. as a result of using "s#" parser
markers.

Externally, Python tries to find the right encoding(s) for the given
platform and then uses these in the IO layer (e.g. sys.stdin.encoding)
and for OS interfacing (sys.getfilesystemencoding()).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 15 2009)
>>> 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 ndbecker2 at gmail.com  Tue Dec 15 13:33:56 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 15 Dec 2009 07:33:56 -0500
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com>
	<d11dcfba0912141200k1045d1b0w322de2753ab35ca4@mail.gmail.com>
	<loom.20091214T213355-735@post.gmane.org>
	<56CF2170-397D-4E90-A3F6-90ADB2FA5C74@gmail.com>
	<b654cd2e0912141700j5d4f0643yc54383ee72caff5c@mail.gmail.com>
Message-ID: <hg7vnj$7oj$1@ger.gmane.org>

Ian Bicking wrote:

> On Mon, Dec 14, 2009 at 6:34 PM, ssteinerX at gmail.com
> <ssteinerx at gmail.com> wrote:
>>> Although I am of the people who think working modules shouldn't be
>>> deprecated, I also don't think adding compatibility aliases is a good
>>> idea. They only make the APIs more bloated and maintenance more tedious.
>>> Let's keep the new APIs clean of any unnecessary baggage.
>>
>> Agreed.  If you want to make an "adapter" to do things like convert 'int'
>> to int, then call the new API then fine, but don't start crufting up a
>> new API to make it 'easier' to convert.
>>
>> All crufting it up does is make it _less_ clear how to use the new API by
>> bring along things that don't belong in it.
> 
> The "new" API is almost exactly like the old optparse API.  It's not
> like it's some shining jewel of perfection that would be tainted by
> somehow being similar to optparse when it's almost exactly like
> optparse already.
> 
> If it wasn't like optparse, then fine, whatever; but it *is* like
> optparse, so these differences feel unnecessary.  Converting 'int' to
> int internally in argparse is hardly difficult or unclear.
> 
> If argparse doesn't do this, then I think at least it should give good
> error messages for all cases where these optparse-isms remain.  For
> instance, now if you include %prog in your usage you get: ValueError:
> unsupported format character 'p' (0x70) at index 1 -- that's simply a
> bad error message.  Giving a proper error message takes about as much
> code as making %prog work.  I don't feel strongly that one is better
> than the other, but at least one of those should be done.
> 
> 

I agree (and I've used both for quite a long time).  argparse has an api 
that is almost compatible with optparse in many common cases, but just 
renamed some things.


From olemis at gmail.com  Tue Dec 15 17:46:44 2009
From: olemis at gmail.com (Olemis Lang)
Date: Tue, 15 Dec 2009 11:46:44 -0500
Subject: [Python-Dev] Command line options for features in stdlib WAS:
	Pronouncement on PEP 389: argparse?
Message-ID: <24ea26600912150846o1cbb06dsf7f350c23e004ceb@mail.gmail.com>

/me starting a new thread because this goes beyond argparse itself

On Tue, Dec 15, 2009 at 4:34 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Steven Bethard <steven.bethard <at> gmail.com> writes:
>>
>> Because people are continuing this discussion, I'll say again that
>> argparse already supports this:
>
> Well I think the point is that if there is a default, the default should be
> sensible and not run against expectations.

+1

> It would probably be fine not to have a default at all, too.

-1

I really think that it's good to expect the same (similar) behavior
when the same options is accepted by multiple commands. In the end
that's a decision of the people implementing the concrete command line
tool, but it is nice to rely on something like : ?if you forgot, or
don't remember or don't know about it then the std decision is
performed?

Now that you mention all this , I follow up with a comment that is
more about -v switch . Most of the time I realize that command line
apps have logging capabilities and should also allow different
verbosity levels (e.g. -q, -s, -v, --noisy) . The good thing is that
this always can be done the same way (i.e. using log levels defined in
logging module ) . The not so good news is that (in practice) coders
have to do it over and over every time they create a new command line
app, and users might need to remember those switches if the author
used different names . My suggestion is that it would be nice to
identify std switches and add support for configuring the cmd-line
parser and logger instance OOTB

{{{
#!python
import argparse
import logging

if __name__ == ?__main__?:
    # create the parser
    parser = argparse.ArgumentParser(description=?XXX?)
    # add the arguments
    ...
    # add args for verbosity level
    logging.add_args(parser)
    # parse the command line
    args = parser.parse_args()
    # configure logging --
    # probably omitted if an option handles this
    logging.fileConfig(*cfg_args)
    # setup the logger instance
    logging.argparseConfig(getLogger('xxx'), args)
}}}

The same reasoning could probably be extended to other modules in
stdlib (e.g. default encoding, testing, ...). It's probably a good
idea to define a set of (std) command line args for std features
(preferently without conflicting with existing standards ;o) and
provide shortcuts to ease configuration process when building command
line tools

PS: This thread might also be related to the previous one about
logging configuration using dicts

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Automated init.  -
http://bitbucket.org/osimons/trac-rpc-mq/changeset/e122336d1eb2/

From steven.bethard at gmail.com  Tue Dec 15 18:14:32 2009
From: steven.bethard at gmail.com (Steven Bethard)
Date: Tue, 15 Dec 2009 09:14:32 -0800
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <hg7vnj$7oj$1@ger.gmane.org>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com>
	<d11dcfba0912141200k1045d1b0w322de2753ab35ca4@mail.gmail.com>
	<loom.20091214T213355-735@post.gmane.org>
	<56CF2170-397D-4E90-A3F6-90ADB2FA5C74@gmail.com>
	<b654cd2e0912141700j5d4f0643yc54383ee72caff5c@mail.gmail.com>
	<hg7vnj$7oj$1@ger.gmane.org>
Message-ID: <d11dcfba0912150914g2f03ed09g75d4b4ef87e6e7e8@mail.gmail.com>

On Tue, Dec 15, 2009 at 4:33 AM, Neal Becker <ndbecker2 at gmail.com> wrote:
> Ian Bicking wrote:
>> If argparse doesn't do this, then I think at least it should give good
>> error messages for all cases where these optparse-isms remain. ?For
>> instance, now if you include %prog in your usage you get: ValueError:
>> unsupported format character 'p' (0x70) at index 1 -- that's simply a
>> bad error message. ?Giving a proper error message takes about as much
>> code as making %prog work. ?I don't feel strongly that one is better
>> than the other, but at least one of those should be done.
>
> I agree (and I've used both for quite a long time). ?argparse has an api
> that is almost compatible with optparse in many common cases, but just
> renamed some things.

I can definitely improve some of the error messages for people coming
from optparse. I've created an issue for this, with the ``type='int'``
and "%prog" problems in there:

http://code.google.com/p/argparse/issues/detail?id=51

If you have other things that you know you'd like better exceptions
for, please add to that issue and I'll take care of it.

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
        --- The Hiphopopotamus

From dinov at microsoft.com  Tue Dec 15 18:59:52 2009
From: dinov at microsoft.com (Dino Viehland)
Date: Tue, 15 Dec 2009 17:59:52 +0000
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <94bdd2610912150141i158deb54j603eba56f781402e@mail.gmail.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD04D81D51@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<94bdd2610912141458m52da21ear4970506a37214e6@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD04D9042D@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<94bdd2610912150141i158deb54j603eba56f781402e@mail.gmail.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD04D9722D@TK5EX14MBXC118.redmond.corp.microsoft.com>

Tarek wrote:
> How would you use it when a list is returned ? Can you provide a few
> examples where
> the code wants to know the default architecture for the current platform ?
> etc.

The consumer could enumerate over it and then do whatever they were doing
w/ the platform multiple times.  If an earlier one succeeds at what
they're attempting to do then they're done.  If there's no "success", lets
say they're appending something to sys.path, then they'd do it for all
elements in the sequence.

It's not an absolute requirement or anything like that - it just jumped
out at me because IronPython and Jython do have multiple platforms
which could be relevant at one time.


From mal at egenix.com  Tue Dec 15 22:05:05 2009
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 15 Dec 2009 22:05:05 +0100
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <94bdd2610912141412s22f04dc6i94b713ade0d8b90a@mail.gmail.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>	<4B260AF2.3000802@egenix.com>
	<94bdd2610912141412s22f04dc6i94b713ade0d8b90a@mail.gmail.com>
Message-ID: <4B27FA01.80903@egenix.com>

Tarek Ziad? wrote:
> On Mon, Dec 14, 2009 at 10:52 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> [..]
>>> I've refactored distutils/ and site.py so they work with this new
>>> module, and added deprecation warnings in distutils.sysconfig.
>>
>> I think we really need to do something about these kinds of
>> deprecations.
>>
>> IMHO, there is no need to deprecate an entry point if the code
>> has just moved to some other location in the stdlib.
>>
>> A simple note in the documentation and the NEWS file should be
>> enough to get programmers to use the new location for code that
>> doesn't have to work with older Python versions.
> 
> There are both cases in fact: some APIs have just moved, and some have
> changed. So I guess I could keep a deprecation warning only for the
> latter.

Sounds like a plan.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 15 2009)
>>> 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 david.lyon at preisshare.net  Wed Dec 16 01:22:41 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Tue, 15 Dec 2009 19:22:41 -0500
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <20091215093255.GA13198@laurie.devork>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<0a500cc770721944b33036da1cb5b3f3@preisshare.net>
	<4B270548.2090600@gmail.com>
	<e8b797fbaaa6f22cdc43ca843a3a9f83@preisshare.net>
	<4B270AFE.1060505@skippinet.com.au>
	<30a87fe1344a9a8c6aa0e25ee099bb43@preisshare.net>
	<4B270F84.5030802@skippinet.com.au>
	<822785ca33912a9c6656ef6d36ae0be9@preisshare.net>
	<20091215093255.GA13198@laurie.devork>
Message-ID: <db03dda0ae6182a9a309b70fe79339e5@preisshare.net>

On Tue, 15 Dec 2009 09:32:55 +0000, Floris Bruynooghe
<floris.bruynooghe at gmail.com> wrote:

> If I write a shared library under C I am expected to install it under
> one of the default locations if I don't want to require people to have
> to tweak things before they can use it.  I see no difference with
> python modules or packages.  Any private modules or packages used by
> an application built using python don't have to be on the sys.path by
> default (in fact I would encourage them not to be).

Hi Floris.

Well Mark Hammond summed up for me - I'm satisfied with his answer.

You're talking about modules and packages and I agree with you.

I guess I was asking about was extending the set to of things
that could easily be dealt with by python from just modules/packages
to modules/packages + applications.

What do I mean by an application?, well it's one or two steps up from
the simple as 'helloworld.py'. There's lots of machines in the
company, and lots of different apps. Not unlike a scientific
area where there is lots of specialised equipment and each
machine has slightly different requirements as to its function.

Installing python is painless. That's all good.

Installing all the python-packages has a learning curve and isn't
very streamlined. In the end, it can be made to work.

Installing the application (helloworld.py for the want of a better
name), well, there isn't much in python to help there. 

I was thinking that perphaps sysconfig could help me get my
helloworld.py application into a \Program Files\hello world
directory and everything would be rosy.

But not yet. So I will wait.

> Distutils isn't perfect but solves the need of installing public
> modules and packages quite well.

If you say so - but compared to what ? CPAN? :-)

Have a nice day

David



From ncoghlan at gmail.com  Wed Dec 16 12:21:01 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 16 Dec 2009 21:21:01 +1000
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <db03dda0ae6182a9a309b70fe79339e5@preisshare.net>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>	<0a500cc770721944b33036da1cb5b3f3@preisshare.net>	<4B270548.2090600@gmail.com>	<e8b797fbaaa6f22cdc43ca843a3a9f83@preisshare.net>	<4B270AFE.1060505@skippinet.com.au>	<30a87fe1344a9a8c6aa0e25ee099bb43@preisshare.net>	<4B270F84.5030802@skippinet.com.au>	<822785ca33912a9c6656ef6d36ae0be9@preisshare.net>	<20091215093255.GA13198@laurie.devork>
	<db03dda0ae6182a9a309b70fe79339e5@preisshare.net>
Message-ID: <4B28C29D.6020400@gmail.com>

David Lyon wrote:
> I was thinking that perphaps sysconfig could help me get my
> helloworld.py application into a \Program Files\hello world
> directory and everything would be rosy.
> 
> But not yet. So I will wait.

No, we mostly leave that to the py2exe/py2app + native installer
developers of the world. There are a *lot* of thorny issues in getting
installers fully in accordance with OS developer guidelines, which is
why we tend to shy away from it.

That said, we did add the zip archive execution capability so that
complex Python applications can be more easily executed without needing
to install them at all.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From david.lyon at preisshare.net  Thu Dec 17 03:10:48 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 16 Dec 2009 21:10:48 -0500
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <4B28C29D.6020400@gmail.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>	<0a500cc770721944b33036da1cb5b3f3@preisshare.net>	<4B270548.2090600@gmail.com>	<e8b797fbaaa6f22cdc43ca843a3a9f83@preisshare.net>	<4B270AFE.1060505@skippinet.com.au>	<30a87fe1344a9a8c6aa0e25ee099bb43@preisshare.net>	<4B270F84.5030802@skippinet.com.au>	<822785ca33912a9c6656ef6d36ae0be9@preisshare.net>	<20091215093255.GA13198@laurie.devork>
	<db03dda0ae6182a9a309b70fe79339e5@preisshare.net>
	<4B28C29D.6020400@gmail.com>
Message-ID: <22b6fd677f9891bde50c8108bc1c4177@preisshare.net>

On Wed, 16 Dec 2009 21:21:01 +1000, Nick Coghlan <ncoghlan at gmail.com>
wrote:

> .. we mostly leave that to the py2exe/py2app + native installer
> developers of the world. There are a *lot* of thorny issues in getting
> installers fully in accordance with OS developer guidelines, which is
> why we tend to shy away from it.

And that is fair enough. In the commercial world, once the python
gets compiled, you're mostly talking about some application where
the source code needs protection. The bar is raised - to match
the available budgets.

However, I would like to point out a category of applications
that live in source code form. Inside scientific or commercial
organisations. These are apps that are never compiled - and 
just run in interpreted mode. Maybe they're on workstations,
or maybe they're on web servers. It doesn't matter that much.

The point is that the python Configurations exist over many 
machines.

What I'd like to suggest is that python apps are becoming more
network centric. To the point where it might at some time in the
future it might well become a 'python-core' issue.

I'm not suggesting writing a new SCM because so many already
exist. And in python too - haha - how great is that.

All that I'm doing is suggesting that the python of the future
and the stdlib of the future will include celery or superpy
or the mercurial or bzr interfaces, and it will be really
easy to roll out the 'helloworld.py' app/web-app out to 
the desktop machines or django server or cluster or cloud 
of machines wherever they actually are. 

The machines will just have 'python' installed, and then from 
there everything will pretty easily take place (apps/packages
get pushed to remote machines). 

I'm not star-gazing, because all these things are already
needed and already being done to some degree in some
organisations. There's already the libraries on pypi for
most of this anyway.

The practical advantages of some of us going in this direction 
is that it might be possible for us open sourcers to attract
the attention of our commercial sponsors attention. Because
they're always interested in getting new toys and utilising
their resources in the most efficient way. 

If we do the above, incorporate tested packages from pypi, it's
possible that the glow of CPAN might be tarnished somewhat.

David






From stephen at xemacs.org  Thu Dec 17 04:18:00 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 17 Dec 2009 12:18:00 +0900
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <22b6fd677f9891bde50c8108bc1c4177@preisshare.net>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<0a500cc770721944b33036da1cb5b3f3@preisshare.net>
	<4B270548.2090600@gmail.com>
	<e8b797fbaaa6f22cdc43ca843a3a9f83@preisshare.net>
	<4B270AFE.1060505@skippinet.com.au>
	<30a87fe1344a9a8c6aa0e25ee099bb43@preisshare.net>
	<4B270F84.5030802@skippinet.com.au>
	<822785ca33912a9c6656ef6d36ae0be9@preisshare.net>
	<20091215093255.GA13198@laurie.devork>
	<db03dda0ae6182a9a309b70fe79339e5@preisshare.net>
	<4B28C29D.6020400@gmail.com>
	<22b6fd677f9891bde50c8108bc1c4177@preisshare.net>
Message-ID: <87hbrq5lw7.fsf@uwakimon.sk.tsukuba.ac.jp>

David Lyon writes:

 > I'm not star-gazing, because all these things are already
 > needed and already being done to some degree in some
 > organisations. There's already the libraries on pypi for
 > most of this anyway.

Sure.  But in a volunteer project, it's beg, buy, or build.  Begging
has not worked, and it's not because people don't understand what
you're saying.  Nobody is saying that want you want is stupid or
impossible, either.  It's just that they have created those libraries
you mention, they have built PyPI, they have written distutils and
setuptools and others.  *These work well enough* ... except for you,
apparently.  I have no problem with that, and you're welcome to beg.

But IMO at this point you're coming close to crossing the line from
begging to whining.  There clearly is no interest in going down the
road you propose.  Post a bounty or build it yourself (you were pretty
much done with something last time around, weren't you?), and either
way use the usual channels (eg, PyPI) to distribute the product and
accumulate user interest and support for future attempts at logrolling
to get it into the stdlib.

From david.lyon at preisshare.net  Thu Dec 17 05:01:42 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 16 Dec 2009 23:01:42 -0500
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <87hbrq5lw7.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<0a500cc770721944b33036da1cb5b3f3@preisshare.net>
	<4B270548.2090600@gmail.com>
	<e8b797fbaaa6f22cdc43ca843a3a9f83@preisshare.net>
	<4B270AFE.1060505@skippinet.com.au>
	<30a87fe1344a9a8c6aa0e25ee099bb43@preisshare.net>
	<4B270F84.5030802@skippinet.com.au>
	<822785ca33912a9c6656ef6d36ae0be9@preisshare.net>
	<20091215093255.GA13198@laurie.devork>
	<db03dda0ae6182a9a309b70fe79339e5@preisshare.net>
	<4B28C29D.6020400@gmail.com>
	<22b6fd677f9891bde50c8108bc1c4177@preisshare.net>
	<87hbrq5lw7.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <d62b9ee9ac3371eca7fa08f28c94e44f@preisshare.net>

On Thu, 17 Dec 2009 12:18:00 +0900, "Stephen J. Turnbull"
<stephen at xemacs.org> wrote:
>  > .. because all these things are already
>  > needed and already being done to some degree in some
>  > organisations. There's already the libraries on pypi for
>  > most of this anyway.
> 
> ...
> There clearly is no interest in going down the
> road you propose.  

Hmm.. well.. projects like buildout, superpy and celery
suggest that people are already working and thinking this 
way. Lots of companies use clusters of python computers
and these needs will only increase over time.

If it's only +1 from one person to make python more
network centric with sysconfig in 2010, then so be it.

Have a nice day.

David


From ziade.tarek at gmail.com  Thu Dec 17 10:55:52 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 17 Dec 2009 10:55:52 +0100
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD04D9722D@TK5EX14MBXC118.redmond.corp.microsoft.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD04D81D51@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<94bdd2610912141458m52da21ear4970506a37214e6@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD04D9042D@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<94bdd2610912150141i158deb54j603eba56f781402e@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD04D9722D@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <94bdd2610912170155p3e983c6dqb8a862d6908bd623@mail.gmail.com>

On Tue, Dec 15, 2009 at 6:59 PM, Dino Viehland <dinov at microsoft.com> wrote:
> Tarek wrote:
>> How would you use it when a list is returned ? Can you provide a few
>> examples where
>> the code wants to know the default architecture for the current platform ?
>> etc.
>
> The consumer could enumerate over it and then do whatever they were doing
> w/ the platform multiple times. ?If an earlier one succeeds at what
> they're attempting to do then they're done. ?If there's no "success", lets
> say they're appending something to sys.path, then they'd do it for all
> elements in the sequence.

get_platform is currently used 1/ by Distutils' build command to
define the default platform name
to build from (and there's an option to override it : --plat-name), 2/
by site.py to add the build dir of Python in case we are running from
it.

For 1/, build allows cross-platform building only if the user is under
windows, otherwise
it'll throw an error.  IOW, this api is used to know what is the
*current* platform, even if there are some (tiny) ways to work for
"other" platforms.  2/ was meant to be dropped at some point (see
http://bugs.python.org/issue586680) and very CPython specific I guess.

I am not sure, but in Jython/IronPython, do you guys have a "default"
platform ?
if so, returning that default in get_platform() would work.

> It's not an absolute requirement or anything like that - it just jumped
> out at me because IronPython and Jython do have multiple platforms
> which could be relevant at one time.

Sure, and that's why I have asked feedback from IrontPython/Jython people,
Thanks for that.

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From status at bugs.python.org  Fri Dec 18 18:07:20 2009
From: status at bugs.python.org (Python tracker)
Date: Fri, 18 Dec 2009 18:07:20 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20091218170720.094C3785A2@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (12/11/09 - 12/18/09)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 2552 open (+44) / 16811 closed (+18) / 19363 total (+62)

Open issues with patches:  1020

Average duration of open issues: 692 days.
Median duration of open issues: 449 days.

Open Issues Breakdown
   open  2517 (+43)
pending    34 ( +1)

Issues Created Or Reopened (65)
_______________________________

_sha256 et al. encode to UTF-8 by default                        12/15/09
       http://bugs.python.org/issue3745    reopened lemburg                       
       26backport                                                              

GZipFile.readline too slow                                       12/14/09
       http://bugs.python.org/issue7471    reopened pitrou                        
       patch                                                                   

os.lchmod is not present                                         12/12/09
       http://bugs.python.org/issue7479    reopened georg.brandl                  
                                                                               

trite documentation issue.                                       12/11/09
       http://bugs.python.org/issue7480    created  LambertDW                     
                                                                               

Failing to start a thread leaves "zombie" thread in "initial" st 12/11/09
       http://bugs.python.org/issue7481    created  schof                         
                                                                               

Improve ZeroDivisionError message for float and complex object   12/11/09
       http://bugs.python.org/issue7482    created  ezio.melotti                  
       patch, patch, needs review                                              

str.format behaviour changed from Python 2.6                     12/12/09
CLOSED http://bugs.python.org/issue7483    created  falsetru                      
                                                                               

smtplib: verify breaks with Postfix servers                      12/12/09
       http://bugs.python.org/issue7484    created  mpg                           
       easy                                                                    

Error in FAQ entry '4.25   Why doesn't Python have a "with" stat 12/12/09
       http://bugs.python.org/issue7485    created  eric.smith                    
                                                                               

doc: Built-in Functions, exec statement is obsolete              12/12/09
CLOSED http://bugs.python.org/issue7486    created  flox                          
       patch                                                                   

doc: Code is not always colored                                  12/12/09
       http://bugs.python.org/issue7487    created  flox                          
                                                                               

Mac/README continues to refer to 2.6, not 3                      12/13/09
CLOSED http://bugs.python.org/issue7488    created  MLModel                       
                                                                               

OS X binary installer for 3.1.1 missing from http://www.python.o 12/13/09
CLOSED http://bugs.python.org/issue7489    created  MLModel                       
                                                                               

IGNORE_EXCEPTION_DETAIL should ignore the module name            12/13/09
       http://bugs.python.org/issue7490    created  lregebro                      
       patch                                                                   

metaclass __cmp__ is ignored                                     12/13/09
CLOSED http://bugs.python.org/issue7491    created  exarkun                       
                                                                               

doc: cPickle is really gone                                      12/13/09
CLOSED http://bugs.python.org/issue7492    created  flox                          
       patch                                                                   

doc: patch for py3k/Doc/faq/design.rst                           12/13/09
       http://bugs.python.org/issue7493    created  flox                          
       patch                                                                   

_lsprof (cProfile): Profiler.clear() keeps references to detroye 12/13/09
       http://bugs.python.org/issue7494    created  haypo                         
       patch                                                                   

doc: patch for py3k/Doc/faq/programming.rst                      12/13/09
       http://bugs.python.org/issue7495    created  flox                          
       patch                                                                   

python does not  work in command prompt                          12/13/09
CLOSED http://bugs.python.org/issue7496    created  memol_jpn                     
                                                                               

configure test for posix_semaphore capability leaves semaphore b 12/17/09
       http://bugs.python.org/issue7497    reopened mark.dickinson                
       easy                                                                    

test_multiprocessing test_rapid_restart fails if port 9999 alrea 12/13/09
       http://bugs.python.org/issue7498    created  r.david.murray                
       patch, buildbot                                                         

doc: patch for py3k/Doc/faq/library.rst                          12/13/09
       http://bugs.python.org/issue7499    created  flox                          
       patch                                                                   

doc: add warnings for FAQ which may not be accurate              12/13/09
       http://bugs.python.org/issue7500    created  flox                          
       patch                                                                   

python -m unittest path_to_suite_function errors                 12/13/09
       http://bugs.python.org/issue7501    created  rbcollins                     
                                                                               

All DocTestCase instances compare and hash equal to each other   12/14/09
       http://bugs.python.org/issue7502    created  exarkun                       
                                                                               

multiprocessing AuthenticationError "digest sent was rejected" w 12/14/09
       http://bugs.python.org/issue7503    created  peterhunt                     
                                                                               

Same name cookies                                                12/14/09
       http://bugs.python.org/issue7504    created  chch                          
       patch                                                                   

ctypes not converting None to Null in 64-bit system              12/14/09
       http://bugs.python.org/issue7505    created  wenkat_s                      
                                                                               

multiprocessing.managers.BaseManager.__reduce__ references BaseM 12/14/09
       http://bugs.python.org/issue7506    created  peterhunt                     
       easy                                                                    

pipes.quote does not correctly escape !                          12/14/09
       http://bugs.python.org/issue7507    created  bgertzfield                   
                                                                               

Update 'file object' doc                                         12/15/09
       http://bugs.python.org/issue7508    created  tjreedy                       
                                                                               

AttributeError: MSVCCompiler instance has no attribute '_MSVCCom 12/15/09
CLOSED http://bugs.python.org/issue7509    created  srid                          
                                                                               

AttributeError: MSVCCompiler instance has no attribute '_MSVCCom 12/15/09
CLOSED http://bugs.python.org/issue7510    created  srid                          
                                                                               

msvc9compiler.py: ValueError: [u'path']                          12/15/09
       http://bugs.python.org/issue7511    created  srid                          
       patch                                                                   

shutil.copystat may fail EOPNOTSUPP                              12/15/09
       http://bugs.python.org/issue7512    created  kcwu                          
       patch                                                                   

many source files contaminated with form feed (\f) characters    12/15/09
CLOSED http://bugs.python.org/issue7513    created  ivank                         
                                                                               

doc: documentation for "sys.flags" is obsolete.                  12/15/09
       http://bugs.python.org/issue7514    created  flox                          
       patch                                                                   

Lib/test/regrtest.py -ulib2to3 yield "Invalid -u option"         12/15/09
CLOSED http://bugs.python.org/issue7515    created  flox                          
                                                                               

Flag "-3" is silently ignored when running "regrtest.py -j2"     12/15/09
       http://bugs.python.org/issue7516    created  flox                          
       patch                                                                   

freeze.py not ported to python3                                  12/15/09
       http://bugs.python.org/issue7517    created  patrickkidd                   
                                                                               

Some functions in pymath.c should be moved elsewhere.            12/15/09
       http://bugs.python.org/issue7518    created  mark.dickinson                
                                                                               

CompileParser can't read files with BOM markers                  12/15/09
       http://bugs.python.org/issue7519    created  grego87                       
                                                                               

Incorrect handling of nested calss                               12/15/09
CLOSED http://bugs.python.org/issue7520    created  cesarizu                      
                                                                               

PyEval_GetRestricted should be removed from C API reference      12/16/09
       http://bugs.python.org/issue7521    created  jmillikin                     
                                                                               

random.choice should accept a set as input                       12/16/09
CLOSED http://bugs.python.org/issue7522    created  lleeoo                        
                                                                               

add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module              12/16/09
       http://bugs.python.org/issue7523    created  lekma                         
       patch                                                                   

Freeze bug with xml.dom                                          12/16/09
CLOSED http://bugs.python.org/issue7524    created  Gnep                          
                                                                               

Yield example doesn't work as is explained in the documentation  12/16/09
       http://bugs.python.org/issue7525    created  xiscu                         
                                                                               

tkinter menubutton underline behaviour varies between tkinter *  12/16/09
       http://bugs.python.org/issue7526    created  kurtforrester                 
                                                                               

Standard Library documentation fails to mention that string.Form 12/16/09
       http://bugs.python.org/issue7527    created  forest_atq                    
                                                                               

Provide PyLong_AsLongAndOverflow compatibility to Python 2.x     12/17/09
       http://bugs.python.org/issue7528    created  casevh                        
       patch                                                                   

StreamHandler does not live in logging.Handlers                  12/17/09
       http://bugs.python.org/issue7529    created  cjw296                        
                                                                               

doc of multiprocessing.managers is wrong (server_forever)        12/17/09
       http://bugs.python.org/issue7530    created  schwarz                       
                                                                               

datetime.timedelta doc has incorrect output                      12/17/09
CLOSED http://bugs.python.org/issue7531    created  huxoll                        
                                                                               

Extended slicing with classic class behaves strangely            12/17/09
       http://bugs.python.org/issue7532    created  flox                          
       patch                                                                   

unable to install pycurl in 2.6.4                                12/17/09
CLOSED http://bugs.python.org/issue7533    created  iamraprap                     
                                                                               

float('nan')**2 != nan. float('nan')**2 error 33 on windows      12/17/09
       http://bugs.python.org/issue7534    created  mdonolo                       
                                                                               

logging: Filters on Loggers can't actually filter messages on lo 12/17/09
CLOSED http://bugs.python.org/issue7535    created  leorochael                    
       patch                                                                   

float('inf')**2 != inf                                           12/17/09
CLOSED http://bugs.python.org/issue7536    created  mdonolo                       
                                                                               

test_format fails with -j combined with -v                       12/18/09
       http://bugs.python.org/issue7537    created  jgsack                        
       patch                                                                   

HP-UX 11.11 GCC build fails to build modules                     12/18/09
       http://bugs.python.org/issue7538    created  rtarnell                      
                                                                               

unicode exceptions terminate pdb.pm() loop                       12/18/09
       http://bugs.python.org/issue7539    created  mgedmin                       
                                                                               

urllib2 request does not update content length after new add_dat 12/18/09
       http://bugs.python.org/issue7540    created  till                          
                                                                               

python-config --ldflags doesn't pick up libpython2.5.a           12/18/09
       http://bugs.python.org/issue7541    created  robince                       
                                                                               



Issues Now Closed (42)
______________________

py3k os.popen result is not iterable, patch attached              838 days
       http://bugs.python.org/issue1087    pitrou                        
       patch                                                                   

Extension module build fails for MinGW: missing vcvarsall.bat     598 days
       http://bugs.python.org/issue2698    cmcqueen1975                  
                                                                               

reject unicode in zlib                                            352 days
       http://bugs.python.org/issue4757    flox                          
       patch                                                                   

2to3 with a pipe on non-ASCII script                              323 days
       http://bugs.python.org/issue5093    benjamin.peterson             
       patch                                                                   

Overzealous deprecation of BaseException.message                  248 days
       http://bugs.python.org/issue5716    ezio.melotti                  
                                                                               

IMAP4_SSL spin because of SSLSocket.suppress_ragged_eofs          220 days
       http://bugs.python.org/issue5949    r.david.murray                
       patch                                                                   

Cumulative patcc:h to http and xmlrpc                             185 days
       http://bugs.python.org/issue6267    r.david.murray                
                                                                               

test_urllib2_localnet sporadic failures closing socket            167 days
       http://bugs.python.org/issue6381    r.david.murray                
                                                                               

test_socketserver fails on trunk in test_ForkingTCPServer         167 days
       http://bugs.python.org/issue6382    r.david.murray                
       patch                                                                   

Can't import xmlrpclib, DocXMLRPCServer and SimpleXMLRPCServer w  150 days
       http://bugs.python.org/issue6499    r.david.murray                
                                                                               

Add "path" to the xmrlpc dispatcher method                        133 days
       http://bugs.python.org/issue6654    krisvale                      
                                                                               

Interpreter hangs up while trying to decode invalid utf32 stream   91 days
       http://bugs.python.org/issue6922    jgsack                        
       patch                                                                   

bz2file deadlock                                                   51 days
       http://bugs.python.org/issue7205    jgsack                        
       patch                                                                   

str(datetime_obj) doesn't include microseconds if their value is   31 days
       http://bugs.python.org/issue7342    ezio.melotti                  
       patch                                                                   

StringIO.StringIO.readline(-1)  returns the wrong result compare   25 days
       http://bugs.python.org/issue7348    benjamin.peterson             
                                                                               

StringIO.StringIO, io.BytesIO, and io.StringIO accept None in pl   25 days
       http://bugs.python.org/issue7349    benjamin.peterson             
                                                                               

tarfile doesn't detect disk full error on extraction               24 days
       http://bugs.python.org/issue7357    lars.gustaebel                
                                                                               

sqlite3: some OperationalError exceptions should be ProgrammingE   23 days
       http://bugs.python.org/issue7394    ghaering                      
       patch                                                                   

regrtest single: iterator not subscriptable                        20 days
       http://bugs.python.org/issue7396    r.david.murray                
       patch                                                                   

urllib2 (and urllib) should raise error for incomplete response    10 days
       http://bugs.python.org/issue7445    orsenthil                     
                                                                               

Segmentation fault with tuple + gc.collect()                        3 days
       http://bugs.python.org/issue7466    pitrou                        
       patch                                                                   

kqueue timers don't work properly                                   0 days
       http://bugs.python.org/issue7477    hasan                         
                                                                               

str.format behaviour changed from Python 2.6                        0 days
       http://bugs.python.org/issue7483    eric.smith                    
                                                                               

doc: Built-in Functions, exec statement is obsolete                 0 days
       http://bugs.python.org/issue7486    benjamin.peterson             
       patch                                                                   

Mac/README continues to refer to 2.6, not 3                         1 days
       http://bugs.python.org/issue7488    brett.cannon                  
                                                                               

OS X binary installer for 3.1.1 missing from http://www.python.o    0 days
       http://bugs.python.org/issue7489    loewis                        
                                                                               

metaclass __cmp__ is ignored                                        2 days
       http://bugs.python.org/issue7491    benjamin.peterson             
                                                                               

doc: cPickle is really gone                                         0 days
       http://bugs.python.org/issue7492    benjamin.peterson             
       patch                                                                   

python does not  work in command prompt                             0 days
       http://bugs.python.org/issue7496    r.david.murray                
                                                                               

AttributeError: MSVCCompiler instance has no attribute '_MSVCCom    0 days
       http://bugs.python.org/issue7509    srid                          
                                                                               

AttributeError: MSVCCompiler instance has no attribute '_MSVCCom    0 days
       http://bugs.python.org/issue7510    loewis                        
                                                                               

many source files contaminated with form feed (\f) characters       0 days
       http://bugs.python.org/issue7513    amaury.forgeotdarc            
                                                                               

Lib/test/regrtest.py -ulib2to3 yield "Invalid -u option"            0 days
       http://bugs.python.org/issue7515    benjamin.peterson             
                                                                               

Incorrect handling of nested calss                                  0 days
       http://bugs.python.org/issue7520    r.david.murray                
                                                                               

random.choice should accept a set as input                          2 days
       http://bugs.python.org/issue7522    lleeoo                        
                                                                               

Freeze bug with xml.dom                                             0 days
       http://bugs.python.org/issue7524    loewis                        
                                                                               

datetime.timedelta doc has incorrect output                         0 days
       http://bugs.python.org/issue7531    mark.dickinson                
                                                                               

unable to install pycurl in 2.6.4                                   0 days
       http://bugs.python.org/issue7533    brett.cannon                  
                                                                               

logging: Filters on Loggers can't actually filter messages on lo    1 days
       http://bugs.python.org/issue7535    vinay.sajip                   
       patch                                                                   

float('inf')**2 != inf                                              0 days
       http://bugs.python.org/issue7536    mark.dickinson                
                                                                               

gensuitemodule.processfile fails                                 1761 days
       http://bugs.python.org/issue1123727 ronaldoussoren                
                                                                               

Misleading exception from unicode.__contains__                   1007 days
       http://bugs.python.org/issue1680159 r.david.murray                
       patch                                                                   



Top Issues Most Discussed (10)
______________________________

 20 signals not always delivered to main thread, since other thread  688 days
open    http://bugs.python.org/issue1975   

 13 GZipFile.readline too slow                                         4 days
open    http://bugs.python.org/issue7471   

 13 unicode(exception) and str(exception) should return the same me  207 days
open    http://bugs.python.org/issue6108   

  9 binascii module, crazy error messages, unexpected behavior       354 days
open    http://bugs.python.org/issue4770   

  8 sysconfig variable LINKFORSHARED has wrong value for MacOS X fr  487 days
open    http://bugs.python.org/issue3588   

  7 Add gamma function, error functions and other C99 math.h functi  521 days
open    http://bugs.python.org/issue3366   

  6 msvc9compiler.py: ValueError: [u'path']                            3 days
open    http://bugs.python.org/issue7511   

  6 os.lchmod is not present                                           6 days
open    http://bugs.python.org/issue7479   

  6 codecs missing: base64 bz2 hex zlib ...                            7 days
open    http://bugs.python.org/issue7475   

  6 reject unicode in zlib                                           352 days
closed  http://bugs.python.org/issue4757   




From julien at danjou.info  Sat Dec 19 00:25:20 2009
From: julien at danjou.info (Julien Danjou)
Date: Sat, 19 Dec 2009 00:25:20 +0100
Subject: [Python-Dev] [issue1644818] Allow importing built-in submodules
In-Reply-To: <4B2C0EB2.3070301@v.loewis.de>
References: <1261177671.82.0.512970732536.issue1644818@psf.upfronthosting.co.za>
	<4B2C0EB2.3070301@v.loewis.de>
Message-ID: <20091218232520.GA14008@keller.adm.naquadah.org>

At 1261178549 time_t, Martin v. L?wis wrote:
> > Is there to chance to see this *bug* fixed someday?
> 
> Please ask on python-dev. I may be willing to revive my five-for-one offer.

Not sure I really understand, but I can ask gain here:
will that patch, which seems correct finally merged and get this bug
closed?

Cheers,
-- 
Julien Danjou
// ? <julien at danjou.info>   http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
// Trust no one.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091219/fdaf145b/attachment.pgp>

From ncoghlan at gmail.com  Sat Dec 19 00:52:38 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 19 Dec 2009 09:52:38 +1000
Subject: [Python-Dev] [issue1644818] Allow importing built-in submodules
In-Reply-To: <20091218232520.GA14008@keller.adm.naquadah.org>
References: <1261177671.82.0.512970732536.issue1644818@psf.upfronthosting.co.za>	<4B2C0EB2.3070301@v.loewis.de>
	<20091218232520.GA14008@keller.adm.naquadah.org>
Message-ID: <4B2C15C6.9050402@gmail.com>

Julien Danjou wrote:
> At 1261178549 time_t, Martin v. L?wis wrote:
>>> Is there to chance to see this *bug* fixed someday?
>> Please ask on python-dev. I may be willing to revive my five-for-one offer.
> 
> Not sure I really understand, but I can ask gain here:
> will that patch, which seems correct finally merged and get this bug
> closed?
>

Seems like a fair enough idea - I'll have a look at it in the next week
or two.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From ziade.tarek at gmail.com  Sat Dec 19 01:07:43 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Sat, 19 Dec 2009 01:07:43 +0100
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <94bdd2610912130356r5e6d973ft2e5a414b08afa106@mail.gmail.com>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
	<4B20B4D1.10502@gmail.com>
	<94bdd2610912100519n43614c84n63c37794ec8f5d7b@mail.gmail.com>
	<loom.20091210T145433-494@post.gmane.org>
	<a08e5f80912100610l48312c5do5b85c7a07376a5d1@mail.gmail.com>
	<4B221DA8.5060509@gmail.com>
	<94bdd2610912130356r5e6d973ft2e5a414b08afa106@mail.gmail.com>
Message-ID: <94bdd2610912181607l6527f77ft90d618237c98aa93@mail.gmail.com>

On Sun, Dec 13, 2009 at 12:56 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
[..]
>
> Furthermore, I've seen some patterns in those 5% that can be worked
> out so I'll probably be able to lower it to 3%

Done:

Total Packages  :  8690
Already Match   :  7645.0 (87.97%)
Have Suggestion :  768.0 (8.84%)
No Suggestion   :  277.0 (3.19%)

I guess I'll just wait for the PEP to be rejected or accepted now :)

Regards,
Tarek

From martin at v.loewis.de  Sat Dec 19 01:16:46 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 19 Dec 2009 01:16:46 +0100
Subject: [Python-Dev] [issue1644818] Allow importing built-in submodules
In-Reply-To: <20091218232520.GA14008@keller.adm.naquadah.org>
References: <1261177671.82.0.512970732536.issue1644818@psf.upfronthosting.co.za>	<4B2C0EB2.3070301@v.loewis.de>
	<20091218232520.GA14008@keller.adm.naquadah.org>
Message-ID: <4B2C1B6E.9040208@v.loewis.de>

Julien Danjou wrote:
> At 1261178549 time_t, Martin v. L?wis wrote:
>>> Is there to chance to see this *bug* fixed someday?
>> Please ask on python-dev. I may be willing to revive my five-for-one offer.
> 
> Not sure I really understand, but I can ask gain here:
> will that patch, which seems correct finally merged and get this bug
> closed?

Only if some committer finds time for it, which is *really* scarce.
If you want to push that issue, I promise to review it after you have
reviewed five other patches.

Regards,
Martin

From martin at v.loewis.de  Sat Dec 19 12:08:31 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sat, 19 Dec 2009 12:08:31 +0100
Subject: [Python-Dev] [issue1644818] Allow importing built-in submodules
In-Reply-To: <20091219102917.GB14008@keller.adm.naquadah.org>
References: <1261177671.82.0.512970732536.issue1644818@psf.upfronthosting.co.za>
	<4B2C0EB2.3070301@v.loewis.de>
	<20091218232520.GA14008@keller.adm.naquadah.org>
	<4B2C1B6E.9040208@v.loewis.de>
	<20091219102917.GB14008@keller.adm.naquadah.org>
Message-ID: <4B2CB42F.4010803@v.loewis.de>

> But in my current position and with "I-do-software-developement-too",
> you are just pissing me off for not fixing a bug in your program with a 10
> lines long patch written by someone else 3 years ago.

Unfortunately, it is not obvious to me that the patch is correct, so I
couldn't check it in as-is. The review would probably take an hour or
two.

> Something that should take 5 minutes, probably the time we both lost by
> writing our respective emails. Or give commit access, I'll do it for
> you.

Thanks, no. One possible side effect of the five reviews might be that
we could build trust in the reviewer not just to check in everything,
but apply careful review before.

Regards,
Martin

From julien at danjou.info  Sat Dec 19 11:29:17 2009
From: julien at danjou.info (Julien Danjou)
Date: Sat, 19 Dec 2009 11:29:17 +0100
Subject: [Python-Dev] [issue1644818] Allow importing built-in submodules
In-Reply-To: <4B2C1B6E.9040208@v.loewis.de>
References: <1261177671.82.0.512970732536.issue1644818@psf.upfronthosting.co.za>
	<4B2C0EB2.3070301@v.loewis.de>
	<20091218232520.GA14008@keller.adm.naquadah.org>
	<4B2C1B6E.9040208@v.loewis.de>
Message-ID: <20091219102917.GB14008@keller.adm.naquadah.org>

At 1261181806 time_t, "Martin v. L?wis" wrote:
> Only if some committer finds time for it, which is *really* scarce.
> If you want to push that issue, I promise to review it after you have
> reviewed five other patches.

Well, that's disapointing. I work on several other free software
projects, and my time is really scarce too.

I understand blackmailing me to close a bug can be seen as a nice game.
Honestly, if I had more time to get involve in that area, I'll
take it as a game and would do it with pleasure.

But in my current position and with "I-do-software-developement-too",
you are just pissing me off for not fixing a bug in your program with a 10
lines long patch written by someone else 3 years ago.

Something that should take 5 minutes, probably the time we both lost by
writing our respective emails. Or give commit access, I'll do it for
you.

Anyway, thanks.

Cheers,
-- 
Julien Danjou
// ? <julien at danjou.info>   http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
// This is the end of my signature.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091219/5f542366/attachment.pgp>

From rdmurray at bitdance.com  Sat Dec 19 17:59:58 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 19 Dec 2009 11:59:58 -0500
Subject: [Python-Dev] Renewal of the 1-for-5 offer (was: [issue1644818]
	Allow importing built-in submodules)
In-Reply-To: <4B2C1B6E.9040208@v.loewis.de>
References: <1261177671.82.0.512970732536.issue1644818@psf.upfronthosting.co.za>
	<4B2C0EB2.3070301@v.loewis.de>
	<20091218232520.GA14008@keller.adm.naquadah.org>
	<4B2C1B6E.9040208@v.loewis.de>
Message-ID: <20091219165959.4CD921FA62B@kimball.webabinitio.net>

On Sat, 19 Dec 2009 01:16:46 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <martin at v.loewis.de> wrote:
> Only if some committer finds time for it, which is *really* scarce.
> If you want to push that issue, I promise to review it after you have
> reviewed five other patches.

As a general note, I'm willing to make the same deal.  Anyone who has a
patch they are championing, if you will review some other patches for
us, I'll see if I can get the patch you are interested in committed.
We have a lot of patches in the tracker that only the submitter has
looked at/tested, or which lack tests or doc updates, and so they just
sit there...

(By the way, Julian, if you had done a review of the patch in question
(tested it, etc, and reported your results) progress on the bug might
have just started happening.  This is how it often works; although
there's no guarantee of course.)

I'd also like to point out that IMO the idea behind the one-for-five offer
is to leverage the "I have an itch to scratch" energy to the benefit of
all and, just as important (and as Martin already pointed out), perhaps
set some new people on the path to becoming committers.

--
R. David Murray                                      www.bitdance.com
Business Process Automation - Network/Server Management - Routers/Firewalls

From glyph at twistedmatrix.com  Sat Dec 19 23:56:19 2009
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Sat, 19 Dec 2009 17:56:19 -0500
Subject: [Python-Dev] [issue1644818] Allow importing built-in submodules
In-Reply-To: <20091219102917.GB14008@keller.adm.naquadah.org>
References: <1261177671.82.0.512970732536.issue1644818@psf.upfronthosting.co.za>
	<4B2C0EB2.3070301@v.loewis.de>
	<20091218232520.GA14008@keller.adm.naquadah.org>
	<4B2C1B6E.9040208@v.loewis.de>
	<20091219102917.GB14008@keller.adm.naquadah.org>
Message-ID: <246ECF71-C062-47A2-BC69-EC9E0352745D@twistedmatrix.com>


On Dec 19, 2009, at 5:29 AM, Julien Danjou wrote:

> Well, that's disapointing. I work on several other free software
> projects, and my time is really scarce too.
> 
> I understand blackmailing me to close a bug can be seen as a nice game.
> Honestly, if I had more time to get involve in that area, I'll
> take it as a game and would do it with pleasure.
> 
> But in my current position and with "I-do-software-developement-too",
> you are just pissing me off for not fixing a bug in your program with a 10
> lines long patch written by someone else 3 years ago.
> 
> Something that should take 5 minutes, probably the time we both lost by
> writing our respective emails. Or give commit access, I'll do it for
> you.

I think you're missing the point here.  This one particular patch is 10 lines long, but the problem is that there are thousands of patches in the Python tracker, many of which are buggy or incorrect, all of which need to be reviewed.  All of which *are* being reviewed, as people have time.  Nothing is particularly special about your patch.

In other words, Martin is asking you to review only 5 patches, but you're asking him to review tens of thousands.  I think the 5-for-1 deal is a great idea, because it takes peoples' impatience and turns it into a resource to deal with other peoples' impatience :).



From ncoghlan at gmail.com  Sun Dec 20 00:42:37 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 20 Dec 2009 09:42:37 +1000
Subject: [Python-Dev] [issue1644818] Allow importing built-in submodules
In-Reply-To: <4B2CB42F.4010803@v.loewis.de>
References: <1261177671.82.0.512970732536.issue1644818@psf.upfronthosting.co.za>	<4B2C0EB2.3070301@v.loewis.de>	<20091218232520.GA14008@keller.adm.naquadah.org>	<4B2C1B6E.9040208@v.loewis.de>	<20091219102917.GB14008@keller.adm.naquadah.org>
	<4B2CB42F.4010803@v.loewis.de>
Message-ID: <4B2D64ED.7060505@gmail.com>

Martin v. L?wis wrote:
>> But in my current position and with "I-do-software-developement-too",
>> you are just pissing me off for not fixing a bug in your program with a 10
>> lines long patch written by someone else 3 years ago.
> 
> Unfortunately, it is not obvious to me that the patch is correct, so I
> couldn't check it in as-is. The review would probably take an hour or
> two.

I definitely plan on spending a lot more than 5 minutes on it - in
particular, I want to see if I can find a way to avoid adding
yet-more-test-code to the main binary. (Probably not, given the nature
of the feature we're trying to test in this case, but I'm still going to
try).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From casevh at gmail.com  Sun Dec 20 01:38:45 2009
From: casevh at gmail.com (Case Vanhorsen)
Date: Sat, 19 Dec 2009 16:38:45 -0800
Subject: [Python-Dev] Providing support files to assist 3.x extension authors
Message-ID: <99e0b9530912191638u757d2ce5mdf15394482cc19c0@mail.gmail.com>

Hello,

When I ported gmpy (Python to GMP multiple precision library) to
Python 3.x, I began to use PyLong_AsLongAndOverflow frequently. I
found the code to slightly faster and cleaner than using PyLong_AsLong
and checking for overflow. I looked at making PyLong_AsLongAndOverflow
available to Python 2.x. http://bugs.python.org/issue7528 includes a
patch that adds PyLong_AsLongAndOverflow to Python 2.7.

I also included a file (py3intcompat.c) that can be included with an
extension's source code and provides PyLong_AsLongAndOverflow to
earlier versions of Python 2.x. In the bug report, I suggested that
py3intcompat.c could be included in the Misc directory and be made
available to extension authors. This follows the precedent of
pymemcompat.h. But there may be more "compatibility" files that could
benefit extension authors. Mark Dickinson suggested that I bring the
topic on python-dev.

Several questions come to mind:

1) Is it reasonable to provide backward compatibility files (either as
.h or .c) to provide support to new API calls to extension authors?

2) If yes, should they be included with the Python source or
distributed as a separate entity? (2to3 and/or 3to2 projects, a Wiki
page)

3) If not, and extension authors can create their own compatibility
files, are there any specific attribution or copyright messages that
must be included? (I assuming the compatibility was done by extracting
the code for the new API and tweaking it to run on older versions of
Python.)

Thanks in advance for your attention,

Case Van Horsen

From ncoghlan at gmail.com  Sun Dec 20 03:37:18 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 20 Dec 2009 12:37:18 +1000
Subject: [Python-Dev] Providing support files to assist 3.x extension
 authors
In-Reply-To: <99e0b9530912191638u757d2ce5mdf15394482cc19c0@mail.gmail.com>
References: <99e0b9530912191638u757d2ce5mdf15394482cc19c0@mail.gmail.com>
Message-ID: <4B2D8DDE.8070409@gmail.com>

Case Vanhorsen wrote:
> Hello,
> 
> When I ported gmpy (Python to GMP multiple precision library) to
> Python 3.x, I began to use PyLong_AsLongAndOverflow frequently. I
> found the code to slightly faster and cleaner than using PyLong_AsLong
> and checking for overflow. I looked at making PyLong_AsLongAndOverflow
> available to Python 2.x. http://bugs.python.org/issue7528 includes a
> patch that adds PyLong_AsLongAndOverflow to Python 2.7.
> 
> I also included a file (py3intcompat.c) that can be included with an
> extension's source code and provides PyLong_AsLongAndOverflow to
> earlier versions of Python 2.x. In the bug report, I suggested that
> py3intcompat.c could be included in the Misc directory and be made
> available to extension authors. This follows the precedent of
> pymemcompat.h. But there may be more "compatibility" files that could
> benefit extension authors. Mark Dickinson suggested that I bring the
> topic on python-dev.
> 
> Several questions come to mind:
> 
> 1) Is it reasonable to provide backward compatibility files (either as
> .h or .c) to provide support to new API calls to extension authors?

As a minor terminology nit, I'd call these "forward compatibility" files
- they're backports of Py3k interfaces to 2.x to make it easier to write
modules that will compile with both 2.x and 3.x.

> 2) If yes, should they be included with the Python source or
> distributed as a separate entity? (2to3 and/or 3to2 projects, a Wiki
> page)

That depends - if we're only targeting 2.7, then including the
compatibility files directly in the Python source would be fine. But for
a solution to be usable with extensions intended for use with 2.6 (or
even 2.5) it would be necessary to distribute the forward compatibility
files separately.

> 3) If not, and extension authors can create their own compatibility
> files, are there any specific attribution or copyright messages that
> must be included? (I assuming the compatibility was done by extracting
> the code for the new API and tweaking it to run on older versions of
> Python.)

For code extracted from the Python source, the PSF licenses would still
apply.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From martin at v.loewis.de  Sun Dec 20 09:49:13 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 20 Dec 2009 09:49:13 +0100
Subject: [Python-Dev] Providing support files to assist 3.x extension
 authors
In-Reply-To: <99e0b9530912191638u757d2ce5mdf15394482cc19c0@mail.gmail.com>
References: <99e0b9530912191638u757d2ce5mdf15394482cc19c0@mail.gmail.com>
Message-ID: <4B2DE509.3020302@v.loewis.de>

> Several questions come to mind:
> 
> 1) Is it reasonable to provide backward compatibility files (either as
> .h or .c) to provide support to new API calls to extension authors?

I'm skeptical. In my experience, each extension has different needs, and
will also use different strategies to provide compatibility. So
publishing one way as the "official" approach might be difficult. In one
case, the proposed approach for compatibility actually led to incorrect
code (by ignoring exceptions when extracting a long), so we would need
to be fairly careful what compatibility layers we can bless as official.

> 2) If yes, should they be included with the Python source or
> distributed as a separate entity? (2to3 and/or 3to2 projects, a Wiki
> page)

In the way you propose it (i.e. as forward compatibility files) I fail
to see the point of including them with Python 2.7. Extension authors
likely want to support versions of Python before that, which now cannot
be changed. So those authors would still have to include the file
on their own.

So a file distributed in Include of 2.7 actually hurts, as it would
conflict with the copy included in packages.

> 3) If not, and extension authors can create their own compatibility
> files, are there any specific attribution or copyright messages that
> must be included? 

If you write a compatibility file from scratch, without copying existing
code, you don't need to worry at all. If you do copy parts of Python,
you must follow the license, in particular clause 2.

Regards,
Martin

From theller at ctypes.org  Mon Dec 21 08:56:14 2009
From: theller at ctypes.org (Thomas Heller)
Date: Mon, 21 Dec 2009 08:56:14 +0100
Subject: [Python-Dev] x86 osx 5 buildbot slave
Message-ID: <hgn9mt$7fi$1@ger.gmane.org>

I have to shutdown the x86 osx 5 buildbot slave permanently, because
the machine is getting a new role.  Martin, please remove it from
the configuration.

-- 
Thanks,
Thomas


From casevh at gmail.com  Mon Dec 21 15:18:29 2009
From: casevh at gmail.com (Case Vanhorsen)
Date: Mon, 21 Dec 2009 06:18:29 -0800
Subject: [Python-Dev] Providing support files to assist 3.x extension
	authors
In-Reply-To: <4B2DE509.3020302@v.loewis.de>
References: <99e0b9530912191638u757d2ce5mdf15394482cc19c0@mail.gmail.com>
	<4B2DE509.3020302@v.loewis.de>
Message-ID: <99e0b9530912210618i496115e1g8f6076b8230603de@mail.gmail.com>

On Sun, Dec 20, 2009 at 12:49 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> Several questions come to mind:
>>
>> 1) Is it reasonable to provide backward compatibility files (either as
>> .h or .c) to provide support to new API calls to extension authors?
>
> I'm skeptical. In my experience, each extension has different needs, and
> will also use different strategies to provide compatibility. So
> publishing one way as the "official" approach might be difficult. In one
> case, the proposed approach for compatibility actually led to incorrect
> code (by ignoring exceptions when extracting a long), so we would need
> to be fairly careful what compatibility layers we can bless as official.
>
>> 2) If yes, should they be included with the Python source or
>> distributed as a separate entity? (2to3 and/or 3to2 projects, a Wiki
>> page)
>
> In the way you propose it (i.e. as forward compatibility files) I fail
> to see the point of including them with Python 2.7. Extension authors
> likely want to support versions of Python before that, which now cannot
> be changed. So those authors would still have to include the file
> on their own.
>
> So a file distributed in Include of 2.7 actually hurts, as it would
> conflict with the copy included in packages.
>
>> 3) If not, and extension authors can create their own compatibility
>> files, are there any specific attribution or copyright messages that
>> must be included?
>
> If you write a compatibility file from scratch, without copying existing
> code, you don't need to worry at all. If you do copy parts of Python,
> you must follow the license, in particular clause 2.
>
> Regards,
> Martin
>

Thanks for comments. I will just maintain my own version.

Case

From dickinsm at gmail.com  Mon Dec 21 16:02:24 2009
From: dickinsm at gmail.com (Mark Dickinson)
Date: Mon, 21 Dec 2009 15:02:24 +0000
Subject: [Python-Dev] Disallow float arguments where an integer is expected
	in Python 2.7.
Message-ID: <5c6f2a5d0912210702u4e20f1b1oa72104b4bb88059d@mail.gmail.com>

In Python 2.7, PyArg_ParseTuple and friends currently accept a float
argument where an integer is expected, but produce a
DeprecationWarning in this case.  This can be seen in various places
in Python proper:

>>> itertools.combinations(range(5), 2.0)
__main__:1: DeprecationWarning: integer argument expected, got float
<itertools.combinations object at 0x10059f638>

Are there any objections to turning this DeprecationWarning into a
TypeError for Python 2.7?  The behaviour has been deprecated since
Python 2.3, it's gone in 3.x, and having it produce an error in 2.7
might slightly reduce the number of surprises involved in porting from
2.x to 3.x.  There's a patch at http://bugs.python.org/issue5080

There's one fly in the ointment:  the deprecation warning is produced
for all integer codes except for one---the 'L' code.  The patch adds a
deprecation warning for this code.

Mark

From brett at python.org  Mon Dec 21 18:03:10 2009
From: brett at python.org (Brett Cannon)
Date: Mon, 21 Dec 2009 09:03:10 -0800
Subject: [Python-Dev] Disallow float arguments where an integer is
	expected in Python 2.7.
In-Reply-To: <5c6f2a5d0912210702u4e20f1b1oa72104b4bb88059d@mail.gmail.com>
References: <5c6f2a5d0912210702u4e20f1b1oa72104b4bb88059d@mail.gmail.com>
Message-ID: <bbaeab100912210903g3dbf99f1vedce3d4d407ae61c@mail.gmail.com>

On Mon, Dec 21, 2009 at 07:02, Mark Dickinson <dickinsm at gmail.com> wrote:

> In Python 2.7, PyArg_ParseTuple and friends currently accept a float
> argument where an integer is expected, but produce a
> DeprecationWarning in this case.  This can be seen in various places
> in Python proper:
>
> >>> itertools.combinations(range(5), 2.0)
> __main__:1: DeprecationWarning: integer argument expected, got float
> <itertools.combinations object at 0x10059f638>
>
> Are there any objections to turning this DeprecationWarning into a
> TypeError for Python 2.7?  The behaviour has been deprecated since
> Python 2.3, it's gone in 3.x, and having it produce an error in 2.7
> might slightly reduce the number of surprises involved in porting from
> 2.x to 3.x.  There's a patch at http://bugs.python.org/issue5080
>
>
I'm +0

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091221/1b196767/attachment.htm>

From martin at v.loewis.de  Tue Dec 22 00:58:24 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Tue, 22 Dec 2009 00:58:24 +0100
Subject: [Python-Dev] x86 osx 5 buildbot slave
In-Reply-To: <hgn9mt$7fi$1@ger.gmane.org>
References: <hgn9mt$7fi$1@ger.gmane.org>
Message-ID: <4B300BA0.5070406@v.loewis.de>

Thomas Heller wrote:
> I have to shutdown the x86 osx 5 buildbot slave permanently, because
> the machine is getting a new role.  Martin, please remove it from
> the configuration.

Thanks for the notice; I have now removed it from the list.

Regards,
Martin

From ziade.tarek at gmail.com  Tue Dec 22 01:25:15 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 22 Dec 2009 01:25:15 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
Message-ID: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>

Hi,

On behalf of the Distutils-SIG, I would like to propose to addition of
PEP 345 (once and *if* PEP 386 is accepted).

It's the metadata v1.2: http://www.python.org/dev/peps/pep-0345/

PEP 345 was initiated a while ago by Richard Jones, and reworked since
then together with PEP 386, at Pycon last year and in Distutils-SIG.

The major enhancements are:

- being able to express dependencies on other *distributions* names,
rather than packages names or modules names. This
  enhancement comes from Setuptools and has been used successfully for
years by the community.

- being able to express some fields which values are specific to some
platforms. For example, being able to define "pywin32"
  as a dependency *only* on win32. This enhancement will allow any
tool to query PyPI and to get the metadata for a particular
  execution context, without having to download, build, or install the
project itself.

- being able to provide a list of browsable URLs for the project, like
a bug tracker, a repository etc,  in addition to the home url.
  This will allow UIs like PyPI to display a list of URLs for a
project. A side-effect will be that a project maintainer will be able
to drive its
  end users to the right places when they need to find detailed
documentation or provide some feedback. This enhancement
  was driven by the discussions about the rating/comment system at
PyPI on catalog-sig.

We believe that having PEP 386 and PEP 345 accepted will be a major
improvement for the Python packaging eco-system. The next PEP in the
series we are working on is PEP 376.

As a side note, I would really like to see them (hopefully) accepted
before the first beta of Python 2.7 so we can add these features in
2.7/3.2 and start to work on third-party tools (Distribute, Pip, a
standalone version of Distutils for 2.6/2.5, etc..) to get ready to
support them by the time 2.7 final is out.

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From ncoghlan at gmail.com  Tue Dec 22 02:17:10 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 22 Dec 2009 11:17:10 +1000
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
Message-ID: <4B301E16.1090106@gmail.com>

Tarek Ziad? wrote:
> Hi,
> 
> On behalf of the Distutils-SIG, I would like to propose to addition of
> PEP 345 (once and *if* PEP 386 is accepted).

+1 for integrating all the good work the catalog-sig folks have been doing.

Some comments on PEP 345 specifically though:

The deprecation of the existing Requires/Provides/Obsoletes fields
should be more prominent - tucked away below the examples, I missed
these notices on the first read through (I only noticed that they
actually had been formally deprecated when I got to the summary of
differences at the end). I suggest placing the deprecation notice
immediately after the relevant field headers.

There also needs to be an explanation in the PEP as to whether or not it
is legal to use both Requires and Requires-Dist (etc) in the same
PKG-INFO file. (i.e. what is the use case for allowing the old fields to
be used in a metadata v1.2 PKG-INFO file? Should PEP 345 aware packaging
tools just ignore the old fields, while v1.1 tools ignore the new ones?
Or should new tools attempt to handle both?)

The various lines about there being no standards or canonical
definitions for particular fields also seem to run counter to the spirit
of the detailed guidelines in the description of each field (which imply
that some standards have already been adopted by convention). Perhaps
these comments could be softened to say that although the metadata
specification formally allows arbitrary strings in these fields, the
descriptions are recommended guidelines for creating field entries that
automated tools will handle correctly?

Finally, as a general formatting request - some blank space between the
end of the previous example and the header for the next field
description would make the field descriptions much easier to read.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From tseaver at palladion.com  Wed Dec 23 03:31:10 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Tue, 22 Dec 2009 21:31:10 -0500
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <4B301E16.1090106@gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B301E16.1090106@gmail.com>
Message-ID: <hgrvdf$ddp$1@ger.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nick Coghlan wrote:
> Tarek Ziad? wrote:
>> Hi,
>>
>> On behalf of the Distutils-SIG, I would like to propose to addition of
>> PEP 345 (once and *if* PEP 386 is accepted).
> 
> +1 for integrating all the good work the catalog-sig folks have been doing.
> 
> Some comments on PEP 345 specifically though:
> 
> The deprecation of the existing Requires/Provides/Obsoletes fields
> should be more prominent - tucked away below the examples, I missed
> these notices on the first read through (I only noticed that they
> actually had been formally deprecated when I got to the summary of
> differences at the end). I suggest placing the deprecation notice
> immediately after the relevant field headers.

Good point.  I thought I had done so in the initial editing pass.

> There also needs to be an explanation in the PEP as to whether or not it
> is legal to use both Requires and Requires-Dist (etc) in the same
> PKG-INFO file. (i.e. what is the use case for allowing the old fields to
> be used in a metadata v1.2 PKG-INFO file? Should PEP 345 aware packaging
> tools just ignore the old fields, while v1.1 tools ignore the new ones?
> Or should new tools attempt to handle both?)

No tools that I know of currently use 'Requires' / 'Provides' /
'Obsoletes' at all:  their contents have never been informative enough
to allow for useful automation.  For completeness sake, we can document
that tools should ignore any 'Requires', 'Provides', or 'Obsoletes'
fields when any of the '-Dist' versions are present.

> The various lines about there being no standards or canonical
> definitions for particular fields also seem to run counter to the spirit
> of the detailed guidelines in the description of each field (which imply
> that some standards have already been adopted by convention). Perhaps
> these comments could be softened to say that although the metadata
> specification formally allows arbitrary strings in these fields, the
> descriptions are recommended guidelines for creating field entries that
> automated tools will handle correctly?

That language is left over from PEP 314, which introduced those
"advisory" fields.  The expectation of PEP 345 is that developers who
want their packages to be easily consumable by automated tools will
avoid the deprecated fields and use the more usefully-specifiied new ones.

> Finally, as a general formatting request - some blank space between the
> end of the previous example and the header for the next field
> description would make the field descriptions much easier to read.

Hmm, I thought we were following stock ReST formats:  perhaps the CSS
should be adjusted to give a larger leading space to headings?



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksxgOgACgkQ+gerLs4ltQ5VdgCgqAFmJ89DbKLw/5YFsasuU6tp
HUYAoK+ek+86Xsq3oVYspEk95OkFaJjv
=nWJT
-----END PGP SIGNATURE-----


From ziade.tarek at gmail.com  Wed Dec 23 11:18:27 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 23 Dec 2009 11:18:27 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <hgrvdf$ddp$1@ger.gmane.org>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B301E16.1090106@gmail.com> <hgrvdf$ddp$1@ger.gmane.org>
Message-ID: <94bdd2610912230218p37ec36f1t1b11f209bc7940e3@mail.gmail.com>

On Wed, Dec 23, 2009 at 3:31 AM, Tres Seaver <tseaver at palladion.com> wrote:
[..]
>>
>> The deprecation of the existing Requires/Provides/Obsoletes fields
>> should be more prominent - tucked away below the examples, I missed
>> these notices on the first read through (I only noticed that they
>> actually had been formally deprecated when I got to the summary of
>> differences at the end). I suggest placing the deprecation notice
>> immediately after the relevant field headers.
>
> Good point. ?I thought I had done so in the initial editing pass.

I've done it yesterday.

>
>> There also needs to be an explanation in the PEP as to whether or not it
>> is legal to use both Requires and Requires-Dist (etc) in the same
>> PKG-INFO file. (i.e. what is the use case for allowing the old fields to
>> be used in a metadata v1.2 PKG-INFO file? Should PEP 345 aware packaging
>> tools just ignore the old fields, while v1.1 tools ignore the new ones?
>> Or should new tools attempt to handle both?)
>
> No tools that I know of currently use 'Requires' / 'Provides' /
> 'Obsoletes' at all: ?their contents have never been informative enough
> to allow for useful automation. ?For completeness sake, we can document
> that tools should ignore any 'Requires', 'Provides', or 'Obsoletes'
> fields when any of the '-Dist' versions are present.

Although some (a small number) distributions use these, so one way to
handle it is
to do a little bit like what was done when 1.1 came out:

if a "1.2" field is found and no "1.1" field is found:
    metadata 1.2 is used
if a "1.1" field is found and no "1.2" field is found:
    metadata 1.1 is used + a warning is displayed
if a "1.1" field is found and a "1.2" field is found:
    a warning is displayed and 1.2 is used, 1.1 fields are ignored
if no 1.1 field or 1.2 fields are found:
    metadata 1.2 is used

>> The various lines about there being no standards or canonical
>> definitions for particular fields also seem to run counter to the spirit
>> of the detailed guidelines in the description of each field (which imply
>> that some standards have already been adopted by convention). Perhaps
>> these comments could be softened to say that although the metadata
>> specification formally allows arbitrary strings in these fields, the
>> descriptions are recommended guidelines for creating field entries that
>> automated tools will handle correctly?
>
> That language is left over from PEP 314, which introduced those
> "advisory" fields. ?The expectation of PEP 345 is that developers who
> want their packages to be easily consumable by automated tools will
> avoid the deprecated fields and use the more usefully-specifiied new ones.
>

Notice that I now provide in 2.7/3.2 a way to read *and* write
PKG-INFO from an API:

http://docs.python.org/dev/distutils/examples.html#reading-the-metadata

meaning that whatever fields a developer use, this API will let the installers
and other automated tool gets the metadata.

It might be a good thing to inform about that API in the PEP I guess,

>> Finally, as a general formatting request - some blank space between the
>> end of the previous example and the header for the next field
>> description would make the field descriptions much easier to read.
>
> Hmm, I thought we were following stock ReST formats: ?perhaps the CSS
> should be adjusted to give a larger leading space to headings?

I've changed the layout yesterday, so its easier to read.

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Wed Dec 23 11:21:30 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 23 Dec 2009 11:21:30 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <94bdd2610912230218p37ec36f1t1b11f209bc7940e3@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B301E16.1090106@gmail.com> <hgrvdf$ddp$1@ger.gmane.org>
	<94bdd2610912230218p37ec36f1t1b11f209bc7940e3@mail.gmail.com>
Message-ID: <94bdd2610912230221p1d383728pf48157c5456a8e8@mail.gmail.com>

On Wed, Dec 23, 2009 at 11:18 AM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
[..]
>
> if a "1.2" field is found and no "1.1" field is found:
> ? ?metadata 1.2 is used
> if a "1.1" field is found and no "1.2" field is found:
> ? ?metadata 1.1 is used + a warning is displayed
> if a "1.1" field is found and a "1.2" field is found:
> ? ?a warning is displayed and 1.2 is used, 1.1 fields are ignored
> if no 1.1 field or 1.2 fields are found:
> ? ?metadata 1.2 is used

That would be internal to Distutils btw. tools should consume PKG-INFO
using the DistributionMetadata reader, looking for the various attributes.

"requires", etc. would be kept, most of the time set to "None", then removed
at the next Python version.

From martin at v.loewis.de  Wed Dec 23 15:30:44 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 23 Dec 2009 15:30:44 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <4B301E16.1090106@gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B301E16.1090106@gmail.com>
Message-ID: <4B322994.4040007@v.loewis.de>

> The deprecation of the existing Requires/Provides/Obsoletes fields
> should be more prominent - tucked away below the examples, I missed
> these notices on the first read through (I only noticed that they
> actually had been formally deprecated when I got to the summary of
> differences at the end). I suggest placing the deprecation notice
> immediately after the relevant field headers.

I would go beyond deprecation, and propose to remove them altogether.

In the metadata format, there is no point in deprecating something.
If you have a valid use for these fields, use version 1.1.

> There also needs to be an explanation in the PEP as to whether or not it
> is legal to use both Requires and Requires-Dist (etc) in the same
> PKG-INFO file. (i.e. what is the use case for allowing the old fields to
> be used in a metadata v1.2 PKG-INFO file? Should PEP 345 aware packaging
> tools just ignore the old fields, while v1.1 tools ignore the new ones?
> Or should new tools attempt to handle both?)

I think that depends much on the tool. Distutils will just write it into
the metadata. PyPI will just store it in the database (and create new
columns for the new fields), and render them to the user.
The only issue would be with tools that actually do resolve
dependencies.

I believe that, for the old fields, no such tools actually exist. I may
be wrong, in which case authors of such tools should speak up when the
PEP proposes removal (or propose re-introduction in v1.3 of the format).

Regards,
Martin

From fwierzbicki at gmail.com  Wed Dec 23 16:00:57 2009
From: fwierzbicki at gmail.com (Frank Wierzbicki)
Date: Wed, 23 Dec 2009 10:00:57 -0500
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <94bdd2610912141458m52da21ear4970506a37214e6@mail.gmail.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD04D81D51@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<94bdd2610912141458m52da21ear4970506a37214e6@mail.gmail.com>
Message-ID: <4dab5f760912230700l38a597f7l855bb2304025d6d5@mail.gmail.com>

On Mon, Dec 14, 2009 at 5:58 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> and for Linux and al, I am not sure but maybe a prefix for
> Jython/etc.. could be used
> for all paths.
>
> ~/.locale/lib/python/2.6/site-packages/...
> ~/.locale/jython/lib/python/2.6/site-packages/...
>
> (I didn't digg on how Jython organizes things yet, any hint would be
> appreciated)
Jython does not yet support user site-packages, but I think the above
looks like a fine structure for us when we get to implementing it.

-Frank

From glyph at twistedmatrix.com  Wed Dec 23 17:00:50 2009
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Wed, 23 Dec 2009 11:00:50 -0500
Subject: [Python-Dev] First draft of "sysconfig"
In-Reply-To: <4dab5f760912230700l38a597f7l855bb2304025d6d5@mail.gmail.com>
References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com>
	<1A472770E042064698CB5ADC83A12ACD04D81D51@TK5EX14MBXC118.redmond.corp.microsoft.com>
	<94bdd2610912141458m52da21ear4970506a37214e6@mail.gmail.com>
	<4dab5f760912230700l38a597f7l855bb2304025d6d5@mail.gmail.com>
Message-ID: <F2594678-D242-410D-975F-AABEE2EBB87B@twistedmatrix.com>


On Dec 23, 2009, at 10:00 AM, Frank Wierzbicki wrote:

> On Mon, Dec 14, 2009 at 5:58 PM, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> and for Linux and al, I am not sure but maybe a prefix for
>> Jython/etc.. could be used
>> for all paths.
>> 
>> ~/.locale/lib/python/2.6/site-packages/...
>> ~/.locale/jython/lib/python/2.6/site-packages/...
>> 
>> (I didn't digg on how Jython organizes things yet, any hint would be
>> appreciated)
> Jython does not yet support user site-packages, but I think the above
> looks like a fine structure for us when we get to implementing it.

Two minor points:

1. It's "~/.local", not "~/.locale" ;-)

2. I think it would be a better idea to do "~/.local/lib/jython/2.6/site-packages".

The idea with ~/.local is that it's a mirror of the directory structure convention in /, /usr/, /opt/ or /usr/local/.  In other words it's got "bin", "lib", "share", "etc", etc..  ~/.local/jython/lib suggests that the parallel scripts directory would be ~/.local/jython/bin, which means I need 2 entries on my $PATH instead of one, which means yet more setup for people who use both Python and Jython per-user installation.


From ziade.tarek at gmail.com  Wed Dec 23 17:59:34 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 23 Dec 2009 17:59:34 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <4B322994.4040007@v.loewis.de>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B301E16.1090106@gmail.com> <4B322994.4040007@v.loewis.de>
Message-ID: <94bdd2610912230859r44b45e9v775069df4fab683d@mail.gmail.com>

2009/12/23 "Martin v. L?wis" <martin at v.loewis.de>:
>> The deprecation of the existing Requires/Provides/Obsoletes fields
>> should be more prominent - tucked away below the examples, I missed
>> these notices on the first read through (I only noticed that they
>> actually had been formally deprecated when I got to the summary of
>> differences at the end). I suggest placing the deprecation notice
>> immediately after the relevant field headers.
>
> I would go beyond deprecation, and propose to remove them altogether.
>
> In the metadata format, there is no point in deprecating something.
> If you have a valid use for these fields, use version 1.1.

I think we want something stronger than that since they were not really used by
the community and removed and replaced by something better. Using them
should raise a warning so developers abandon them, so it would be
"don't use 1.1 anymore"

PEP 314 (PEP 345 predecessor) was implemented in a very particular manner:

If you do use options like 'requires' in Distutils' setup.py, your
package ends up with a PKG-INFO Metadata v1.1. Otherwise it stays
v1.0.

In other words, v1.0 was not really superseded by v1.1. The latter was
just an alternative
version and the current Distutils can produce both depending on the
options you use in
your setup.py.

Once 1.2 is defined, we could deprecate the options that are
corresponding to 1.1 at Distutils' level and make Distutils only
produces metadata v1.2 PKG-INFO files (even if the options used by the
developer could be written in a valid 1.0 format).

This will be clearer I think.

So, I am +1 for removing deprecated fields from PEP 345 and work on
the deprecation
issues at the code level in Distutils. Meaning Distutils'
DistributionMetadata class will provide a way to read 1.0/1.1/1.2 but
will only write 1.2 starting at 2.7/3.2,
If a deprecated option is used, Distutils will produce a 1.1 with a warning.
If a deprecated option is used together with a new option, like
Require and Require-Dist,
it will raise an error.

Regards,
Tarek

From martin at v.loewis.de  Wed Dec 23 19:07:12 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 23 Dec 2009 19:07:12 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <94bdd2610912230859r44b45e9v775069df4fab683d@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	
	<4B301E16.1090106@gmail.com> <4B322994.4040007@v.loewis.de>
	<94bdd2610912230859r44b45e9v775069df4fab683d@mail.gmail.com>
Message-ID: <4B325C50.6040902@v.loewis.de>

> I think we want something stronger than that since they were not really used by
> the community and removed and replaced by something better. Using them
> should raise a warning so developers abandon them, so it would be
> "don't use 1.1 anymore"

I think you are mixing the distutils implementation (and parameters
to the setup function) with PEP 345. This PEP *only* describes a
data format. As such, it is not capable of raising exceptions.

Whether you deprecate parameters to the setup function is an entirely
different issue. Alternatives are removing them entirely, ignoring them,
deprecating them, and conditionally accepting them (on the condition
that they don't get mixed with parameters that are meant for 1.2
of the metadata).

> PEP 314 (PEP 345 predecessor) was implemented in a very particular manner:

PEP 314 was implemented multiple times - not only in distutils, but also
in PyPI (for example).

> If you do use options like 'requires' in Distutils' setup.py, your
> package ends up with a PKG-INFO Metadata v1.1. Otherwise it stays
> v1.0.

Please do keep distutils out of PEP 345. The remaining occurrences
(such as what the "interpret_marker" function does) should be removed.

> In other words, v1.0 was not really superseded by v1.1. The latter was
> just an alternative version and the current Distutils can produce 
> both depending on the options you use in your setup.py.

That is all well, and should probably be extended into the
implementation of PEP 345 in distutils. However, what specifically
distutils does is really not the subject here.

> Once 1.2 is defined, we could deprecate the options that are
> corresponding to 1.1 at Distutils' level and make Distutils only
> produces metadata v1.2 PKG-INFO files (even if the options used by the
> developer could be written in a valid 1.0 format).
> 
> This will be clearer I think.

It would be also incompatible with existing consumers that expect
a Python package to have an earlier version of the metadata.
Dropping 1.0 may be fine though - but again, this is out of scope
here.

Regards,
Martin

From ziade.tarek at gmail.com  Wed Dec 23 20:07:30 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 23 Dec 2009 20:07:30 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <4B325C50.6040902@v.loewis.de>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B301E16.1090106@gmail.com> <4B322994.4040007@v.loewis.de>
	<94bdd2610912230859r44b45e9v775069df4fab683d@mail.gmail.com>
	<4B325C50.6040902@v.loewis.de>
Message-ID: <94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>

2009/12/23 "Martin v. L?wis" <martin at v.loewis.de>:
>> I think we want something stronger than that since they were not really used by
>> the community and removed and replaced by something better. Using them
>> should raise a warning so developers abandon them, so it would be
>> "don't use 1.1 anymore"
>
> I think you are mixing the distutils implementation (and parameters
> to the setup function) with PEP 345. This PEP *only* describes a
> data format. As such, it is not capable of raising exceptions.

I am just describing the needs and the end user PoV with the reference
implementation that happens to be used by *all* tools out there.

So that will happen in the code of course, but we need the PEP to state clearly
wether metadata 1.0 and 1.1 should be dropped by implementations or not.

>> PEP 314 (PEP 345 predecessor) was implemented in a very particular manner:
>
> PEP 314 was implemented multiple times - not only in distutils, but also
> in PyPI (for example).

PyPI doesn't produce PKG-INFO files AFAIK, it just consumes them, no ?

I am referring to the implementation in Distutils that produces 1.0
*or* 1.1 PKG-INFO files.

>
>> If you do use options like 'requires' in Distutils' setup.py, your
>> package ends up with a PKG-INFO Metadata v1.1. Otherwise it stays
>> v1.0.
>
> Please do keep distutils out of PEP 345. The remaining occurrences
> (such as what the "interpret_marker" function does) should be removed.

That's the reference implementation of a PEP 345 reader/writer that
happens to be in the stdlin. For what reason should we remove it from
the PEP ?

[..]
>
>> Once 1.2 is defined, we could deprecate the options that are
>> corresponding to 1.1 at Distutils' level and make Distutils only
>> produces metadata v1.2 PKG-INFO files (even if the options used by the
>> developer could be written in a valid 1.0 format).
>>
>> This will be clearer I think.
>
> It would be also incompatible with existing consumers that expect
> a Python package to have an earlier version of the metadata.
> Dropping 1.0 may be fine though - but again, this is out of scope
> here.

I don't understand why you are saying this is out of scope. Shouldn't we
state clearly in the PEP that 1.0 and 1.1 should not be used in the future ?

Regards
Tarek
-- 
Tarek Ziad? | http://ziade.org

From martin at v.loewis.de  Wed Dec 23 21:06:15 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Wed, 23 Dec 2009 21:06:15 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	
	<4B301E16.1090106@gmail.com> <4B322994.4040007@v.loewis.de>	
	<94bdd2610912230859r44b45e9v775069df4fab683d@mail.gmail.com>	
	<4B325C50.6040902@v.loewis.de>
	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>
Message-ID: <4B327837.30306@v.loewis.de>

> So that will happen in the code of course, but we need the PEP to state clearly
> wether metadata 1.0 and 1.1 should be dropped by implementations or not.

Ok. We should recommend that implementations support these versions
indefinitely. I see no point in dropping them.

But then, this is really up to the implementations.

>>> PEP 314 (PEP 345 predecessor) was implemented in a very particular manner:
>> PEP 314 was implemented multiple times - not only in distutils, but also
>> in PyPI (for example).
> 
> PyPI doesn't produce PKG-INFO files AFAIK, it just consumes them, no ?

Correct - but that's also an implementation of the PEP.

> I am referring to the implementation in Distutils that produces 1.0
> *or* 1.1 PKG-INFO files.

But it works both ways. Applications that consume then need to decide
what versions they want to consume.

>> Please do keep distutils out of PEP 345. The remaining occurrences
>> (such as what the "interpret_marker" function does) should be removed.
> 
> That's the reference implementation of a PEP 345 reader/writer that
> happens to be in the stdlin. For what reason should we remove it from
> the PEP ?

Because there shouldn't be a reference implementation. If we have
both a spec and an a reference implementation, then we need to define
what happens in case they conflict. If the reference implementation
is right, implementers of the PEP would *also* need to study the
reference implementation to find out what conforming behaviour is.

This is bad; the PEP should be the only definition of the metadata
format.

>>> This will be clearer I think.
>> It would be also incompatible with existing consumers that expect
>> a Python package to have an earlier version of the metadata.
>> Dropping 1.0 may be fine though - but again, this is out of scope
>> here.
> 
> I don't understand why you are saying this is out of scope. Shouldn't we
> state clearly in the PEP that 1.0 and 1.1 should not be used in the future ?

In terms of conformance, what would that mean? If I implement 1.0 (in
addition to also implementing 1.2), would I then be non-conforming
(because the PEP says I should not support 1.0)? For PyPI, that would
be fairly bad, as it will need to support earlier versions for many
years to come (at a minimum, 10 years).

Regards,
Martin

From david.lyon at preisshare.net  Thu Dec 24 01:22:00 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 23 Dec 2009 19:22:00 -0500
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B301E16.1090106@gmail.com> <4B322994.4040007@v.loewis.de>
	<94bdd2610912230859r44b45e9v775069df4fab683d@mail.gmail.com>
	<4B325C50.6040902@v.loewis.de>
	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>
Message-ID: <75d5dd69b850e9bd793b43618327e655@preisshare.net>


Martin,

As an application developer, I really stand with Tarek here.

On Wed, 23 Dec 2009 20:07:30 +0100, Tarek Ziad? <ziade.tarek at gmail.com>
wrote:
> 2009/12/23 "Martin v. L?wis" <martin at v.loewis.de>:
>>> I think we want something stronger than that since they were not really
>>> used by
>>> the community and removed and replaced by something better. Using them
>>> should raise a warning so developers abandon them, so it would be
>>> "don't use 1.1 anymore"

Yes. But that is a software warning message to be implemented within
the installation software. The important thing is what is in the
metadata.

> I am just describing the needs and the end user PoV with the reference
> implementation that happens to be used by *all* tools out there.

That's good. That's what we need right now.

> So that will happen in the code of course, but we need the PEP to state
> clearly
> wether metadata 1.0 and 1.1 should be dropped by implementations or not.

+1

>> It would be also incompatible with existing consumers that expect
>> a Python package to have an earlier version of the metadata.
>> Dropping 1.0 may be fine though - but again, this is out of scope
>> here.

That's a software implementation issue. Not a metadata issue.

> I don't understand why you are saying this is out of scope. Shouldn't we
> state clearly in the PEP that 1.0 and 1.1 should not be used in the
future

I agree with you Tarek.

Whilst we can suggest that the implementation be done in certain ways. The
PEP in it's current form seems good enough an I am hoping it will go
through soon.

Three more years of deliberation and niggling on this PEP will have more
of an adverse affect than a positive effect. It was started in 2005 and
that
seems like a long time to hold things up. There's always time for a 1.3
version in two years time if there is an unstoppable problem here - but
I can't see any.

As an application developer, I have to side with Tarek. Lets get this
finalised.

Thank you

David






From stephen at xemacs.org  Thu Dec 24 02:31:09 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 24 Dec 2009 10:31:09 +0900
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <75d5dd69b850e9bd793b43618327e655@preisshare.net>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B301E16.1090106@gmail.com> <4B322994.4040007@v.loewis.de>
	<94bdd2610912230859r44b45e9v775069df4fab683d@mail.gmail.com>
	<4B325C50.6040902@v.loewis.de>
	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>
	<75d5dd69b850e9bd793b43618327e655@preisshare.net>
Message-ID: <871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>

David Lyon writes:

 > > I am just describing the needs and the end user PoV with the reference
 > > implementation that happens to be used by *all* tools out there.
 > 
 > That's good. That's what we need right now.

Martin's point is that the PEP process doesn't *have* "reference"
implementations.  It has *sample* implementations.  It may be useful
to refer to a sample implementation as an example, but the PEP must
*define* the behaviors without such references, and compare the
behavior of the sample to the defined behavior.  And references to
internal details like function names is inappropriate in most cases; I
assume that is Martin's point here.

 > > So that will happen in the code of course, but we need the PEP to
 > > state clearly wether metadata 1.0 and 1.1 should be dropped by
 > > implementations or not.
 > 
 > +1

You can state what you want.  What implementations do is another
matter.  An implementation with lots of state like PyPI is not likely
to change quickly.  As a matter of user relations (including but not
limited to developers like you), Python doesn't want to deprecate
practices that are expensive to change too soon.  (That's not my
opinion about what is appropriate, that is my assessment of the
historical policy of Python, which I don't think will change.)


From david.lyon at preisshare.net  Thu Dec 24 02:40:47 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Wed, 23 Dec 2009 20:40:47 -0500
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B301E16.1090106@gmail.com> <4B322994.4040007@v.loewis.de>
	<94bdd2610912230859r44b45e9v775069df4fab683d@mail.gmail.com>
	<4B325C50.6040902@v.loewis.de>
	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>
	<75d5dd69b850e9bd793b43618327e655@preisshare.net>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <e626d66af534e03f22749f3dd4a6ff73@preisshare.net>

On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull"
<stephen at xemacs.org> wrote:

> Martin's point is that the PEP process doesn't *have* "reference"
> implementations.  It has *sample* implementations.  It may be useful
> to refer to a sample implementation as an example..

Fair enough. But otoh, asking for sample implementations on this
type of project can skew the PEP towards a particular implementation
or product.

A definition for metadata should be something quite abstract and self
contained. So imo I am happier where it is currently. 

> What implementations do is another matter.  

Right. We all agree on that.

> An implementation with lots of state like PyPI is not likely
> to change quickly.  As a matter of user relations (including but not
> limited to developers like you), Python doesn't want to deprecate
> practices that are expensive to change too soon.  (That's not my
> opinion about what is appropriate, that is my assessment of the
> historical policy of Python, which I don't think will change.)

Well I would need more convincing that it is better to do one PEP
every 4-5 years as a user relations exercise than one PEP every
year or two years.

Whilst I agree that the core language is really great and the
rate of progress can happily slow. It would be nice to see
the rate of progress of other areas, such as the metadata side,
increase a little.

That wouldn't break policy

David



From martin at v.loewis.de  Thu Dec 24 10:24:10 2009
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Thu, 24 Dec 2009 10:24:10 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <75d5dd69b850e9bd793b43618327e655@preisshare.net>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<4B301E16.1090106@gmail.com>
	<4B322994.4040007@v.loewis.de>	<94bdd2610912230859r44b45e9v775069df4fab683d@mail.gmail.com>	<4B325C50.6040902@v.loewis.de>	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>
	<75d5dd69b850e9bd793b43618327e655@preisshare.net>
Message-ID: <4B33333A.1060806@v.loewis.de>

> As an application developer, I really stand with Tarek here.

Not sure what specific point of Tarek you are supporting, though.

>>>> I think we want something stronger than that since they were not really
>>>> used by
>>>> the community and removed and replaced by something better. Using them
>>>> should raise a warning so developers abandon them, so it would be
>>>> "don't use 1.1 anymore"
> 
> Yes. But that is a software warning message to be implemented within
> the installation software. The important thing is what is in the
> metadata.

That's my point, not Tarek's, though (the text you quote and that you
seem to object to is from Tarek).

>> I am just describing the needs and the end user PoV with the reference
>> implementation that happens to be used by *all* tools out there.
> 
> That's good. That's what we need right now.

Why then bother with describing the data format, when you *really* want
people to use the API? Shouldn't you then define the API instead, and
leave the format as an implementation detail?

I'm fine with having a sample implementation that tools *may* use,
but it should be possible to implement the PEP without the sample
implementation (and indeed, PyPI may not use that sample implementation,
as it has already implemented most of the PEP, to support earlier
versions).

>> So that will happen in the code of course, but we need the PEP to state
>> clearly
>> wether metadata 1.0 and 1.1 should be dropped by implementations or not.
> 
> +1
> 
>>> It would be also incompatible with existing consumers that expect
>>> a Python package to have an earlier version of the metadata.
>>> Dropping 1.0 may be fine though - but again, this is out of scope
>>> here.
> 
> That's a software implementation issue. Not a metadata issue.

Above you say that the PEP should specify whether to keep or drop 1.0
and 1.1, and now you say that whether dropping 1.0 is not a metadata
issue (and, presumably, out of scope of the PEP)???

Regards,
Martin

From martin at v.loewis.de  Thu Dec 24 10:26:55 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 24 Dec 2009 10:26:55 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<4B301E16.1090106@gmail.com>
	<4B322994.4040007@v.loewis.de>	<94bdd2610912230859r44b45e9v775069df4fab683d@mail.gmail.com>	<4B325C50.6040902@v.loewis.de>	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>	<75d5dd69b850e9bd793b43618327e655@preisshare.net>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
Message-ID: <4B3333DF.40705@v.loewis.de>

David Lyon wrote:
> On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull"
> <stephen at xemacs.org> wrote:
> 
>> Martin's point is that the PEP process doesn't *have* "reference"
>> implementations.  It has *sample* implementations.  It may be useful
>> to refer to a sample implementation as an example..
> 
> Fair enough. But otoh, asking for sample implementations on this
> type of project can skew the PEP towards a particular implementation
> or product.

Nobody is "asking" for sample implementations. Instead, I'm asking that
what Tarek calls a "reference implementation" should be called a
"sample implementation" instead. I'm asking for that precisely to avoid
a skew towards a particular implementation.

Regards,
Martin

From ziade.tarek at gmail.com  Thu Dec 24 10:45:12 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 24 Dec 2009 10:45:12 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <4B327837.30306@v.loewis.de>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B301E16.1090106@gmail.com> <4B322994.4040007@v.loewis.de>
	<94bdd2610912230859r44b45e9v775069df4fab683d@mail.gmail.com>
	<4B325C50.6040902@v.loewis.de>
	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>
	<4B327837.30306@v.loewis.de>
Message-ID: <94bdd2610912240145u738783b3kad825d62bc09d92b@mail.gmail.com>

2009/12/23 "Martin v. L?wis" <martin at v.loewis.de>:
>> So that will happen in the code of course, but we need the PEP to state clearly
>> wether metadata 1.0 and 1.1 should be dropped by implementations or not.
>
> Ok. We should recommend that implementations support these versions
> indefinitely. I see no point in dropping them.
>
> But then, this is really up to the implementations.

OK, that's fine with me. So I'll remove references to deprecated
fields in PEP 345, which will
just describes 1.2, and I will also remove the fact that it was marked
as the replacer of PEP 314 in
the header.

[..]
>> PyPI doesn't produce PKG-INFO files AFAIK, it just consumes them, no ?
>
> Correct - but that's also an implementation of the PEP.
>
>> I am referring to the implementation in Distutils that produces 1.0
>> *or* 1.1 PKG-INFO files.
>
> But it works both ways. Applications that consume then need to decide
> what versions they want to consume.

They know it because it is marked in the file in the first line. e.g.
a reader has
to be able to read all versions. IOW they are not the ones that decide what
metadata version a distribution contains.


>>> Please do keep distutils out of PEP 345. The remaining occurrences
>>> (such as what the "interpret_marker" function does) should be removed.
>>
>> That's the reference implementation of a PEP 345 reader/writer that
>> happens to be in the stdlin. For what reason should we remove it from
>> the PEP ?
>
> Because there shouldn't be a reference implementation. If we have
> both a spec and an a reference implementation, then we need to define
> what happens in case they conflict. If the reference implementation
> is right, implementers of the PEP would *also* need to study the
> reference implementation to find out what conforming behaviour is.
>
> This is bad; the PEP should be the only definition of the metadata
> format.

Ok, I'll remove that part.


Regards
Tarek
-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Thu Dec 24 10:52:22 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Thu, 24 Dec 2009 10:52:22 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <4B3333DF.40705@v.loewis.de>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B301E16.1090106@gmail.com> <4B322994.4040007@v.loewis.de>
	<94bdd2610912230859r44b45e9v775069df4fab683d@mail.gmail.com>
	<4B325C50.6040902@v.loewis.de>
	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>
	<75d5dd69b850e9bd793b43618327e655@preisshare.net>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
Message-ID: <94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>

On Thu, Dec 24, 2009 at 10:26 AM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> David Lyon wrote:
>> On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull"
>> <stephen at xemacs.org> wrote:
>>
>>> Martin's point is that the PEP process doesn't *have* "reference"
>>> implementations. ?It has *sample* implementations. ?It may be useful
>>> to refer to a sample implementation as an example..
>>
>> Fair enough. But otoh, asking for sample implementations on this
>> type of project can skew the PEP towards a particular implementation
>> or product.
>
> Nobody is "asking" for sample implementations. Instead, I'm asking that
> what Tarek calls a "reference implementation" should be called a
> "sample implementation" instead. I'm asking for that precisely to avoid
> a skew towards a particular implementation.

I'll remove it and push it in Distutils documentation, then might just
provide a link in the PEP References.

Tarek

From martin at v.loewis.de  Thu Dec 24 11:23:05 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Thu, 24 Dec 2009 11:23:05 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<4B301E16.1090106@gmail.com>
	<4B322994.4040007@v.loewis.de>	<94bdd2610912230859r44b45e9v775069df4fab683d@mail.gmail.com>	<4B325C50.6040902@v.loewis.de>	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>	<75d5dd69b850e9bd793b43618327e655@preisshare.net>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
Message-ID: <4B334109.2060708@v.loewis.de>

> I'll remove it and push it in Distutils documentation, then might just
> provide a link in the PEP References.

That sounds fine to me.

Regards,
Martin

From ncoghlan at gmail.com  Fri Dec 25 08:33:34 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 25 Dec 2009 17:33:34 +1000
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <4B334109.2060708@v.loewis.de>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<4B301E16.1090106@gmail.com>	<4B322994.4040007@v.loewis.de>	<94bdd2610912230859r44b45e9v775069df4fab683d@mail.gmail.com>	<4B325C50.6040902@v.loewis.de>	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>	<75d5dd69b850e9bd793b43618327e655@preisshare.net>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de>
Message-ID: <4B346ACE.2030400@gmail.com>

Martin v. L?wis wrote:
>> I'll remove it and push it in Distutils documentation, then might just
>> provide a link in the PEP References.
> 
> That sounds fine to me.

That would address my questions as well - someone looking for a guide on
how they should deal with different versions of the metadata on the
production and consumption side can look at how distutils deals with it,
leaving the PEP as a pure spec for the metadata format without distutils
API details mixed in.

(where it makes sense in explaining the use cases for the different
fields, I'm fine with referencing distutils API details though)

Cheers,
Nick.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From status at bugs.python.org  Fri Dec 25 18:07:17 2009
From: status at bugs.python.org (Python tracker)
Date: Fri, 25 Dec 2009 18:07:17 +0100 (CET)
Subject: [Python-Dev] Summary of Python tracker Issues
Message-ID: <20091225170717.074EB7865D@psf.upfronthosting.co.za>


ACTIVITY SUMMARY (12/18/09 - 12/25/09)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 2540 open (+18) / 16858 closed (+17) / 19398 total (+35)

Open issues with patches:  1019

Average duration of open issues: 701 days.
Median duration of open issues: 458 days.

Open Issues Breakdown
   open  2506 (+18)
pending    33 ( +0)

Issues Created Or Reopened (37)
_______________________________

doc: patch for Doc/faq/design.rst                                12/19/09
CLOSED http://bugs.python.org/issue7493    reopened flox                          
       patch                                                                   

doc: patch for Doc/faq/programming.rst                           12/19/09
CLOSED http://bugs.python.org/issue7495    reopened flox                          
       patch                                                                   

segfault on cPickle.loads("0.")                                  12/18/09
CLOSED http://bugs.python.org/issue7542    created  afoglia                       
                                                                               

RFE: introduce "enum Py_Opcode"                                  12/18/09
CLOSED http://bugs.python.org/issue7543    created  dmalcolm                      
       patch                                                                   

Fatal error on thread creation in low memory condition           12/19/09
       http://bugs.python.org/issue7544    created  haypo                         
                                                                               

IO buffering behaviour not properly documented                   12/19/09
CLOSED http://bugs.python.org/issue7545    created  pakal                         
       patch                                                                   

msvc9compiler.py: add .asm extension                             12/19/09
       http://bugs.python.org/issue7546    created  skrah                         
       patch                                                                   

test_timeout should skip, not fail, when the remote host is not  12/19/09
       http://bugs.python.org/issue7547    created  pitrou                        
                                                                               

If a generator raises TypeError when being unpacked, an unrelate 12/19/09
       http://bugs.python.org/issue7548    created  eggy                          
                                                                               

2.6.4 Win32 linked to debug DLLs?                                12/20/09
CLOSED http://bugs.python.org/issue7549    created  jw113                         
                                                                               

PyLong_As* methods should not call nb_int.                       12/20/09
CLOSED http://bugs.python.org/issue7550    created  mark.dickinson                
                                                                               

SystemError/MemoryError/OverflowErrors on encode() a	unicode str 12/20/09
CLOSED http://bugs.python.org/issue7551    created  ajung                         
                                                                               

uploading fails on long passwords                                12/20/09
CLOSED http://bugs.python.org/issue7552    created  magcius                       
       patch                                                                   

test_long_future is faulty                                       12/20/09
CLOSED http://bugs.python.org/issue7553    reopened flox                          
       patch                                                                   

Some tests in test_cmath use rAssertAlmostEqual incorrectly      12/20/09
CLOSED http://bugs.python.org/issue7554    reopened mark.dickinson                
       patch                                                                   

Wrong return value of isinstance() function                      12/21/09
CLOSED http://bugs.python.org/issue7555    created  leospidian                    
                                                                               

msvc9compiler.py: TypeError: can't use a string pattern on a byt 12/21/09
CLOSED http://bugs.python.org/issue7556    created  srid                          
       patch                                                                   

Imprecise description for the file.read() method                 12/21/09
CLOSED http://bugs.python.org/issue7557    created  jlp                           
                                                                               

Python 3.1.1 installer botches upgrade when installation is not  12/21/09
CLOSED http://bugs.python.org/issue7558    created  nagle                         
                                                                               

TestLoader.loadTestsFromName swallows import errors              12/21/09
       http://bugs.python.org/issue7559    created  rbcollins                     
       easy                                                                    

Various filename-taking posix methods don't like bytes / buffer  12/22/09
CLOSED http://bugs.python.org/issue7560    created  sh                            
       patch                                                                   

PyByteArray_AS_STRING used unsafely                              12/22/09
       http://bugs.python.org/issue7561    created  sh                            
       patch                                                                   

Custom order for the subcommands of build                        12/22/09
       http://bugs.python.org/issue7562    created  ciantic                       
                                                                               

yield in except clause causes exception context to be lost       12/22/09
       http://bugs.python.org/issue7563    created  ronniemaor                    
                                                                               

test_ioctl fails sometimes                                       12/22/09
       http://bugs.python.org/issue7564    created  flox                          
                                                                               

Increasing resource.RLIMIT_NOFILE has no effect                  12/23/09
       http://bugs.python.org/issue7565    created  george.king                   
                                                                               

Add ntpath.sameopenfile support for Windows                      12/23/09
       http://bugs.python.org/issue7566    created  jaraco                        
                                                                               

Messed up terminal after calling curses.initscr() twice.         12/23/09
       http://bugs.python.org/issue7567    created  yury                          
                                                                               

Spelling error in imaplib module docs                            12/23/09
CLOSED http://bugs.python.org/issue7568    created  mikeputnam                    
                                                                               

ctypes doc improvement: c_char_p                                 12/23/09
       http://bugs.python.org/issue7569    created  Nikratio                      
                                                                               

Error in urllib2 example                                         12/23/09
CLOSED http://bugs.python.org/issue7570    created  dieresys                      
       patch                                                                   

Change 'name' of Process - assertion failure if Unicode          12/24/09
CLOSED http://bugs.python.org/issue7571    created  frankmillman                  
                                                                               

Strabge issue : cursor.commit() with sqlite                      12/24/09
       http://bugs.python.org/issue7572    created  lakshmipathi                  
                                                                               

Python build issue on Ubuntu 9.10                                12/24/09
       http://bugs.python.org/issue7573    created  instigate_team                
                                                                               

PyUnicode_FromFormat broken and not documented for 2.x           12/24/09
       http://bugs.python.org/issue7574    created  ronaldoussoren                
                                                                               

tes_math fails Mac OS X 10.4 due to OverflowError in test_mtestf 12/24/09
       http://bugs.python.org/issue7575    created  slmnhq                        
       patch                                                                   

Avoid warnings in PyModuleDef_HEAD_INIT                          12/25/09
       http://bugs.python.org/issue7576    created  ronaldoussoren                
       patch, patch, needs review                                              



Issues Now Closed (51)
______________________

Extension module build fails for MinGW: missing vcvarsall.bat     607 days
       http://bugs.python.org/issue2698    cmcqueen1975                  
                                                                               

python version incorrectly reported in crash reports on Mac OS X  527 days
       http://bugs.python.org/issue3363    ronaldoussoren                
       easy                                                                    

sysconfig variable LINKFORSHARED has wrong value for MacOS X fra  487 days
       http://bugs.python.org/issue3588    tarek                         
       easy                                                                    

Do not embed manifest files in *.pyd when compiling with	MSVC     433 days
       http://bugs.python.org/issue4120    srid                          
       patch                                                                   

at runtime, distutils uses buildtime files                        394 days
       http://bugs.python.org/issue4359    a.badger                      
                                                                               

Deepcopy of functools.partial gives wierd exception               394 days
       http://bugs.python.org/issue4380    flox                          
                                                                               

A selection of spelling errors and typos throughout source        302 days
       http://bugs.python.org/issue5341    Merwok                        
       patch                                                                   

unicode(exception) and str(exception) should return the same mes  213 days
       http://bugs.python.org/issue6108    ezio.melotti                  
       patch                                                                   

use different mechanism for pythonw on osx                        112 days
       http://bugs.python.org/issue6834    ronaldoussoren                
       easy                                                                    

urllib2 cannot handle https with proxy requiring auth              45 days
       http://bugs.python.org/issue7291    orsenthil                     
       patch                                                                   

"python -m doctest" results in FAIL: Doctest: __main__.DebugRunn   28 days
       http://bugs.python.org/issue7376    r.david.murray                
       patch                                                                   

uuid.UUID.bytes gives a bytearray() instead of bytes               26 days
       http://bugs.python.org/issue7380    georg.brandl                  
       patch                                                                   

Documentation: capitalizations of the word 'python' needed when    26 days
       http://bugs.python.org/issue7388    ezio.melotti                  
       easy                                                                    

cPickle test failure on release26-maint branch                     24 days
       http://bugs.python.org/issue7392    ezio.melotti                  
       26backport                                                              

open builtin has no signature in docstring                         22 days
       http://bugs.python.org/issue7417    georg.brandl                  
       patch                                                                   

os.lchmod is not present                                            7 days
       http://bugs.python.org/issue7479    georg.brandl                  
                                                                               

trite documentation issue.                                          8 days
       http://bugs.python.org/issue7480    georg.brandl                  
                                                                               

Error in FAQ entry '4.25   Why doesn't Python have a "with" stat    8 days
       http://bugs.python.org/issue7485    georg.brandl                  
                                                                               

doc: patch for Doc/faq/design.rst                                   1 days
       http://bugs.python.org/issue7493    georg.brandl                  
       patch                                                                   

doc: patch for Doc/faq/programming.rst                              1 days
       http://bugs.python.org/issue7495    georg.brandl                  
       patch                                                                   

configure test for posix_semaphore capability leaves semaphore b    4 days
       http://bugs.python.org/issue7497    mark.dickinson                
       easy                                                                    

doc: patch for py3k/Doc/faq/library.rst                             6 days
       http://bugs.python.org/issue7499    georg.brandl                  
       patch                                                                   

doc: add warnings for FAQ which may not be accurate                 6 days
       http://bugs.python.org/issue7500    georg.brandl                  
       patch                                                                   

Update 'file object' doc                                            5 days
       http://bugs.python.org/issue7508    pitrou                        
                                                                               

doc: documentation for "sys.flags" is obsolete.                     9 days
       http://bugs.python.org/issue7514    ezio.melotti                  
       patch                                                                   

Some functions in pymath.c should be moved elsewhere.               6 days
       http://bugs.python.org/issue7518    mark.dickinson                
                                                                               

PyEval_GetRestricted should be removed from C API reference         4 days
       http://bugs.python.org/issue7521    georg.brandl                  
                                                                               

Yield example doesn't work as is explained in the documentation     3 days
       http://bugs.python.org/issue7525    georg.brandl                  
                                                                               

tkinter menubutton underline behaviour varies between tkinter *     8 days
       http://bugs.python.org/issue7526    gpolo                         
                                                                               

Standard Library documentation fails to mention that string.Form    3 days
       http://bugs.python.org/issue7527    georg.brandl                  
                                                                               

Provide PyLong_AsLongAndOverflow compatibility to Python 2.x        4 days
       http://bugs.python.org/issue7528    mark.dickinson                
       patch                                                                   

StreamHandler does not live in logging.Handlers                     2 days
       http://bugs.python.org/issue7529    georg.brandl                  
                                                                               

python-config --ldflags doesn't pick up libpython2.5.a              6 days
       http://bugs.python.org/issue7541    ronaldoussoren                
                                                                               

segfault on cPickle.loads("0.")                                     0 days
       http://bugs.python.org/issue7542    eric.smith                    
                                                                               

RFE: introduce "enum Py_Opcode"                                     1 days
       http://bugs.python.org/issue7543    pitrou                        
       patch                                                                   

IO buffering behaviour not properly documented                      0 days
       http://bugs.python.org/issue7545    pitrou                        
       patch                                                                   

2.6.4 Win32 linked to debug DLLs?                                   0 days
       http://bugs.python.org/issue7549    jw113                         
                                                                               

PyLong_As* methods should not call nb_int.                          1 days
       http://bugs.python.org/issue7550    mark.dickinson                
                                                                               

SystemError/MemoryError/OverflowErrors on encode() a	unicode str    1 days
       http://bugs.python.org/issue7551    lemburg                       
                                                                               

uploading fails on long passwords                                   0 days
       http://bugs.python.org/issue7552    tarek                         
       patch                                                                   

test_long_future is faulty                                          1 days
       http://bugs.python.org/issue7553    mark.dickinson                
       patch                                                                   

Some tests in test_cmath use rAssertAlmostEqual incorrectly         0 days
       http://bugs.python.org/issue7554    mark.dickinson                
       patch                                                                   

Wrong return value of isinstance() function                         0 days
       http://bugs.python.org/issue7555    mark.dickinson                
                                                                               

msvc9compiler.py: TypeError: can't use a string pattern on a byt    0 days
       http://bugs.python.org/issue7556    tarek                         
       patch                                                                   

Imprecise description for the file.read() method                    0 days
       http://bugs.python.org/issue7557    georg.brandl                  
                                                                               

Python 3.1.1 installer botches upgrade when installation is not     0 days
       http://bugs.python.org/issue7558    loewis                        
                                                                               

Various filename-taking posix methods don't like bytes / buffer     0 days
       http://bugs.python.org/issue7560    sh                            
       patch                                                                   

Spelling error in imaplib module docs                               1 days
       http://bugs.python.org/issue7568    mark.dickinson                
                                                                               

Error in urllib2 example                                            0 days
       http://bugs.python.org/issue7570    orsenthil                     
       patch                                                                   

Change 'name' of Process - assertion failure if Unicode             0 days
       http://bugs.python.org/issue7571    benjamin.peterson             
                                                                               

chown broken on 64bit                                             903 days
       http://bugs.python.org/issue1747858 gregory.p.smith               
       64bit                                                                   



Top Issues Most Discussed (10)
______________________________

 15 PyByteArray_AS_STRING used unsafely                                3 days
open    http://bugs.python.org/issue7561   

 14 Implement fastsearch algorithm for rfind/rindex                   17 days
open    http://bugs.python.org/issue7462   

  9 C/API - Document exceptions                                       84 days
open    http://bugs.python.org/issue7033   

  8 msvc9compiler.py: TypeError: can't use a string pattern on a by    0 days
closed  http://bugs.python.org/issue7556   

  7 float('nan')**2 != nan. float('nan')**2 error 33 on windows        8 days
open    http://bugs.python.org/issue7534   

  7 unicode(exception) and str(exception) should return the same me  213 days
closed  http://bugs.python.org/issue6108   

  6 tes_math fails Mac OS X 10.4 due to OverflowError in test_mtest    1 days
open    http://bugs.python.org/issue7575   

  6 TestLoader.loadTestsFromName swallows import errors                4 days
open    http://bugs.python.org/issue7559   

  6 IO buffering behaviour not properly documented                     0 days
closed  http://bugs.python.org/issue7545   

  6 Provide PyLong_AsLongAndOverflow compatibility to Python 2.x       4 days
closed  http://bugs.python.org/issue7528   




From techtonik at gmail.com  Sun Dec 27 18:51:54 2009
From: techtonik at gmail.com (anatoly techtonik)
Date: Sun, 27 Dec 2009 19:51:54 +0200
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <d11dcfba0912141437h66ee8fa8he8c9c2287b7dbdd3@mail.gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com>
	<d11dcfba0912141200k1045d1b0w322de2753ab35ca4@mail.gmail.com>
	<4B26A41F.5020009@gmail.com>
	<24ea26600912141310w77d07c42hc244f9ecc1642b9f@mail.gmail.com>
	<d11dcfba0912141437h66ee8fa8he8c9c2287b7dbdd3@mail.gmail.com>
Message-ID: <d34314100912270951x4fd96e67mde5ec0a72b26374f@mail.gmail.com>

On Tue, Dec 15, 2009 at 12:37 AM, Steven Bethard
<steven.bethard at gmail.com> wrote:
>
> If you're only concerned about 2.X, then yes, optparse will *never* be
> removed from 2.X. There will be a deprecation note in the 2.X
> documentation but deprecation warnings will only be issued when the -3
> flag is specified. Please see the "Deprecation of optparse" section of
> the PEP:
>
> http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse

I do not think that optparse should be deprecated at. It is good at
what it does and its limitations make its starting point less
confusing for people with different backgrounds that Python.

Compare:
http://docs.python.org/library/optparse.html
http://argparse.googlecode.com/svn/tags/r101/doc/index.html

argparse should be recommended as advanced and more featured variant
of optparse - that goes without saying, but forcing people to switch
and annoying them with deprecation messages brings only headache. Just
like optparse is better getopt, the latter could also be useful for
people coming from other languages and porting their libraries to
Python.

I would better concentrate on real code examples how argparse solves
problems and would really want to see
http://www.python.org/dev/peps/pep-0389/#out-of-scope-various-feature-requests
implemented until argparse enters phase where backward incompatible
changes in API are impossible.

I would prefer to see PEP 389 as a document describing proposed
solutions to argument parsing problems rather than petition to replace
one library with another. So, it should display common argument
parsing scenarios (use cases) with examples that are also useful
recipes for documentation. I guess more than 90% people here doesn't
have time to read argparse methods descriptions to see what they could
be useful for.

-- 
anatoly t.

From steven.bethard at gmail.com  Sun Dec 27 19:00:23 2009
From: steven.bethard at gmail.com (Steven Bethard)
Date: Sun, 27 Dec 2009 10:00:23 -0800
Subject: [Python-Dev] Pronouncement on PEP 389: argparse?
In-Reply-To: <d34314100912270951x4fd96e67mde5ec0a72b26374f@mail.gmail.com>
References: <d11dcfba0912141004u6728deb1nc596c5afd1480e27@mail.gmail.com>
	<b654cd2e0912141022n1a9afc7fr19bf243ba7b11359@mail.gmail.com>
	<d11dcfba0912141043r1e63a397g20374bc927d7f135@mail.gmail.com>
	<24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com>
	<d11dcfba0912141200k1045d1b0w322de2753ab35ca4@mail.gmail.com>
	<4B26A41F.5020009@gmail.com>
	<24ea26600912141310w77d07c42hc244f9ecc1642b9f@mail.gmail.com>
	<d11dcfba0912141437h66ee8fa8he8c9c2287b7dbdd3@mail.gmail.com>
	<d34314100912270951x4fd96e67mde5ec0a72b26374f@mail.gmail.com>
Message-ID: <d11dcfba0912271000i4e9fc7f9u38ee373b8e1029b0@mail.gmail.com>

On Sun, Dec 27, 2009 at 9:51 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> On Tue, Dec 15, 2009 at 12:37 AM, Steven Bethard
> <steven.bethard at gmail.com> wrote:
>>
>> If you're only concerned about 2.X, then yes, optparse will *never* be
>> removed from 2.X. There will be a deprecation note in the 2.X
>> documentation but deprecation warnings will only be issued when the -3
>> flag is specified. Please see the "Deprecation of optparse" section of
>> the PEP:
>>
>> http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse
>
> I do not think that optparse should be deprecated at. It is good at
> what it does and its limitations make its starting point less
> confusing for people with different backgrounds that Python.
>
> Compare:
> http://docs.python.org/library/optparse.html
> http://argparse.googlecode.com/svn/tags/r101/doc/index.html

This sounds like a request for a documentation change. Because you can
write almost identical code with argparse to that in the optparse
intro. If you just replace "optparse" with "argparse", "OptionParser"
with "ArgumentParser", and "(options, args)" with "args", the code
will work exactly the same. (Actually, better because the usage
message will be better.)

If you have specific suggestions on how you'd like the documentation
updated, please file a feature request in the argparse bug tracker:
http://code.google.com/p/argparse/issues

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
        --- The Hiphopopotamus

From ziade.tarek at gmail.com  Mon Dec 28 01:01:44 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 28 Dec 2009 01:01:44 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <4B346ACE.2030400@gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B325C50.6040902@v.loewis.de>
	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>
	<75d5dd69b850e9bd793b43618327e655@preisshare.net>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
Message-ID: <94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>

On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Martin v. L?wis wrote:
>>> I'll remove it and push it in Distutils documentation, then might just
>>> provide a link in the PEP References.
>>
>> That sounds fine to me.
>
> That would address my questions as well - someone looking for a guide on
> how they should deal with different versions of the metadata on the
> production and consumption side can look at how distutils deals with it,
> leaving the PEP as a pure spec for the metadata format without distutils
> API details mixed in.
>
> (where it makes sense in explaining the use cases for the different
> fields, I'm fine with referencing distutils API details though)

I've updated the PEP accordingly, and also made some changes after the
discussions
we had with Martin on Distutils-SIG on how versions are defined.

FYI we have introduced a range operator, so one may define a range of versions.
This is useful for instance to write:

  Requires-Python: ~=2.5

Which means: requires any version of Python 2.5.x. This operator is
the default operator,
meaning that you can also write:

  Requires-Python: 2.5


Regards
Tarek

From david.lyon at preisshare.net  Mon Dec 28 01:15:49 2009
From: david.lyon at preisshare.net (david.lyon at preisshare.net)
Date: Mon, 28 Dec 2009 11:15:49 +1100 (EST)
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B325C50.6040902@v.loewis.de>
	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>
	<75d5dd69b850e9bd793b43618327e655@preisshare.net>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
Message-ID: <4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>

> On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Martin v. L?wis wrote:
> FYI we have introduced a range operator, so one may define a range of
> versions.
> This is useful for instance to write:
>
>   Requires-Python: ~=2.5
>
> Which means: requires any version of Python 2.5.x. This operator is
> the default operator,
> meaning that you can also write:
>
>   Requires-Python: 2.5

I don't like the ~ at all sorry. The ~ operator is thoroughly confusing.

No application developer will quickly figure out what a tilde means. Maybe
it means 'roughly', but it requires too much thought and is ambiguous. 2.5
is not roughly 2.5.2. It is the same exactly.

Before we had : Requires-Python: 2.5, 2.6

That made much more sense. It was simple and unambiguous, and is relevant
to typical packaging scenarios.

I hope we can go back to the original proposal.

:-)

David




From ziade.tarek at gmail.com  Mon Dec 28 01:37:09 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 28 Dec 2009 01:37:09 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<75d5dd69b850e9bd793b43618327e655@preisshare.net>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
Message-ID: <94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>

On Mon, Dec 28, 2009 at 1:15 AM,  <david.lyon at preisshare.net> wrote:
>> On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> Martin v. L?wis wrote:
>> FYI we have introduced a range operator, so one may define a range of
>> versions.
>> This is useful for instance to write:
>>
>> ? Requires-Python: ~=2.5
>>
>> Which means: requires any version of Python 2.5.x. This operator is
>> the default operator,
>> meaning that you can also write:
>>
>> ? Requires-Python: 2.5
>
> I don't like the ~ at all sorry. The ~ operator is thoroughly confusing.
>
> No application developer will quickly figure out what a tilde means. Maybe
> it means 'roughly', but it requires too much thought and is ambiguous. 2.5
> is not roughly 2.5.2. It is the same exactly.

As discussed in Distutils-SIG, 2.5 is not strictly equal to 2.5.2.
That's exactly why we introduced
the range operator. So one may make a clear distinction between
"2.5.x" and "2.5".

Developers will be able to omit the ~= operator, so they can describe
a MAJOR or
MAJOR.MINOR version and have the whole range included.

>
> Before we had : Requires-Python: 2.5, 2.6
>
> That made much more sense. It was simple and unambiguous, and is relevant
> to typical packaging scenarios.

This was ambiguous because it was unclear, as MvL stated,  if "2.5"
was just "2.5.0" or included
versions like "2.5.1" or "2.5.2". The "==" operator is now a strict
equal operator.

In the current proposal, "Requires-Python: 2.5, 2.6"  is equivalent to
"Requires-Python: ~=2.5, ~=2.6",
which means "Requires Python 2.5.x or Python 2.6.x".

So I guess the meaning you were putting behind "Requires-Python: 2.5,
2.6" remains unchanged.

> I hope we can go back to the original proposal.

This new operator removes the ambiguity the original proposal had,
without making it more
complex for common use cases. So if you dislike it, you will need to
propose something
else that also fixes the ambiguity we had.

Regards,
Tarek

From sridharr at activestate.com  Mon Dec 28 01:41:29 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Sun, 27 Dec 2009 16:41:29 -0800
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<4B325C50.6040902@v.loewis.de>	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>	<75d5dd69b850e9bd793b43618327e655@preisshare.net>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>
	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
Message-ID: <4B37FEB9.1010205@activestate.com>

On 12/27/2009 4:15 PM, david.lyon at preisshare.net wrote:
>> On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan<ncoghlan at gmail.com>  wrote:
>>> >>  Martin v. L?wis wrote:
>> >  FYI we have introduced a range operator, so one may define a range of
>> >  versions.
>> >  This is useful for instance to write:
>> >
>> >     Requires-Python: ~=2.5
>> >
>> >  Which means: requires any version of Python 2.5.x. This operator is
>> >  the default operator,
>> >  meaning that you can also write:
>> >
>> >     Requires-Python: 2.5
> I don't like the ~ at all sorry. The ~ operator is thoroughly confusing.
>
> No application developer will quickly figure out what a tilde means. Maybe
> it means 'roughly', but it requires too much thought and is ambiguous. 2.5
> is not roughly 2.5.2. It is the same exactly.

Tarek,

I am a bit confused at the current proposal combined with the newly 
introduced range operator.

Would "Requires-Python: <=2.5" include 2.5.4 or not?

Also, "Requires-Python: 3" would include all 3.X versions, correct?

-srid

From solipsis at pitrou.net  Mon Dec 28 01:48:33 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 28 Dec 2009 00:48:33 +0000 (UTC)
Subject: [Python-Dev]
	=?utf-8?q?Proposing_PEP_345_=3A_Metadata_for_Python_?=
	=?utf-8?q?Software=09Packages_1=2E2?=
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<75d5dd69b850e9bd793b43618327e655@preisshare.net>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>
Message-ID: <loom.20091228T014312-369@post.gmane.org>

Tarek Ziad? <ziade.tarek <at> gmail.com> writes:
> 
> This was ambiguous because it was unclear, as MvL stated,  if "2.5"
> was just "2.5.0" or included
> versions like "2.5.1" or "2.5.2".

How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5
itself? (ditto for "2.5.N" matching only 2.5.N for N >= 1)

This "~=" operator looks murkier than it needs to be IMO.

Regards

Antoine.



From ziade.tarek at gmail.com  Mon Dec 28 01:52:57 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 28 Dec 2009 01:52:57 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <4B37FEB9.1010205@activestate.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
Message-ID: <94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>

On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar
<sridharr at activestate.com> wrote:
[..]
>
> Tarek,
>
> I am a bit confused at the current proposal combined with the newly
> introduced range operator.
>
> Would "Requires-Python: <=2.5" include 2.5.4 or not?

<=2.5 means any version that is inferior or equal to 2.5.0 so 2.5.4
doesn't match

>
> Also, "Requires-Python: 3" would include all 3.X versions, correct?

Correct, because, "Requires-Python: 3" is equivalent to "Requires-Python: ~= 3"
which is equivalent to "Requires-Python: 3.x.x"


>
> -srid
>



-- 
Tarek Ziad? | http://ziade.org

From martin at v.loewis.de  Mon Dec 28 02:02:05 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 28 Dec 2009 02:02:05 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B325C50.6040902@v.loewis.de>
	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>
	<75d5dd69b850e9bd793b43618327e655@preisshare.net>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
Message-ID: <4B38038D.8050307@v.loewis.de>

> No application developer will quickly figure out what a tilde means. Maybe
> it means 'roughly', but it requires too much thought and is ambiguous. 2.5
> is not roughly 2.5.2. It is the same exactly.
> 
> Before we had : Requires-Python: 2.5, 2.6
> 
> That made much more sense. It was simple and unambiguous, and is relevant
> to typical packaging scenarios.

Unfortunately, it is fairly ambiguous, and makes no sense. It means
"requires Python 2.5 *AND* requires Python 2.6", which is a requirement
that no single version can meet.

Regards,
Martin



From ziade.tarek at gmail.com  Mon Dec 28 02:02:37 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 28 Dec 2009 02:02:37 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <loom.20091228T014312-369@post.gmane.org>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>
	<loom.20091228T014312-369@post.gmane.org>
Message-ID: <94bdd2610912271702k662621ecve996eb7f9ff181fd@mail.gmail.com>

On Mon, Dec 28, 2009 at 1:48 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Tarek Ziad? <ziade.tarek <at> gmail.com> writes:
>>
>> This was ambiguous because it was unclear, as MvL stated, ?if "2.5"
>> was just "2.5.0" or included
>> versions like "2.5.1" or "2.5.2".
>
> How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5
> itself? (ditto for "2.5.N" matching only 2.5.N for N >= 1)
>
> This "~=" operator looks murkier than it needs to be IMO.

An implicit range operator is simpler indeed, and achieves the same goal.

Meaning that "<=2.5" for example, will be translated to "<=2.5.x" as well.

Regards,
Tarek

From ben+python at benfinney.id.au  Mon Dec 28 02:10:27 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Mon, 28 Dec 2009 12:10:27 +1100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B325C50.6040902@v.loewis.de>
	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>
	<75d5dd69b850e9bd793b43618327e655@preisshare.net>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
Message-ID: <87k4w76gzg.fsf@benfinney.id.au>

Tarek Ziad? <ziade.tarek at gmail.com> writes:

> FYI we have introduced a range operator, so one may define a range of
> versions. This is useful for instance to write:
>
>   Requires-Python: ~=2.5
>
> Which means: requires any version of Python 2.5.x.

-1 on that syntax. It's an extra operator, with a non-obvious meaning;
the meaning should be as clear as feasible even to those who have not
read the specification. The existing operators ?>?, ?>=?, ?<? ?<=? are
standard and more obvious.

That is, the existing operators:

    Requires-Python: >=2.5, <2.6

explicitly specify the range in your example.

-- 
 \           ?Value your freedom or you will lose it, teaches history. |
  `\     ?Don't bother us with politics,? respond those who don't want |
_o__)                               to learn.? ?Richard Stallman, 2002 |
Ben Finney


From martin at v.loewis.de  Mon Dec 28 02:11:31 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 28 Dec 2009 02:11:31 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <94bdd2610912271702k662621ecve996eb7f9ff181fd@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>
	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>	<loom.20091228T014312-369@post.gmane.org>
	<94bdd2610912271702k662621ecve996eb7f9ff181fd@mail.gmail.com>
Message-ID: <4B3805C3.8040702@v.loewis.de>

Tarek Ziad? wrote:
> On Mon, Dec 28, 2009 at 1:48 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> Tarek Ziad? <ziade.tarek <at> gmail.com> writes:
>>> This was ambiguous because it was unclear, as MvL stated,  if "2.5"
>>> was just "2.5.0" or included
>>> versions like "2.5.1" or "2.5.2".
>> How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5
>> itself? (ditto for "2.5.N" matching only 2.5.N for N >= 1)
>>
>> This "~=" operator looks murkier than it needs to be IMO.
> 
> An implicit range operator is simpler indeed, and achieves the same goal.
> 
> Meaning that "<=2.5" for example, will be translated to "<=2.5.x" as well.

So that "2.5.4<=2.5", "2.5<=2.5.2", but not "2.5.4<=2.5.2" (i.e. A<=B,
B<=C, but not A<=C)?

I find that strange.

Regards,
Martin

From ben+python at benfinney.id.au  Mon Dec 28 02:17:22 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Mon, 28 Dec 2009 12:17:22 +1100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
Message-ID: <87fx6v6gnx.fsf@benfinney.id.au>

Tarek Ziad? <ziade.tarek at gmail.com> writes:

> On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar
> <sridharr at activestate.com> wrote:
> > Also, "Requires-Python: 3" would include all 3.X versions, correct?
>
> Correct, because, "Requires-Python: 3" is equivalent to
> "Requires-Python: ~= 3" which is equivalent to "Requires-Python:
> 3.x.x"

This is totally counter to conventional comparisons, and is an excellent
example of why the equivalence of ?3? to ?>=3, <4? is a bad idea.

Instead, the default should be ?==?. That is, ?Requires-Python: 3?
should be equivalent to ?Requires-Python: ==3?; and only ?3? or ?3.0? or
?3.0.0? etc. will match. I maintain that is what most people will expect
on seeing that syntax.

If a less strict range is desired, the existing comparison operators
?>?, ?>=?, ?<?, ?<=? are sufficient, more obvious, and more explicit. In
other words, to get the meaning you desire above, the existing operators
can be used: ?Requires-Python: >=3, <4?.

-- 
 \      ?Not using Microsoft products is like being a non-smoker 40 or |
  `\     50 years ago: You can choose not to smoke, yourself, but it's |
_o__)               hard to avoid second-hand smoke.? ?Michael Tiemann |
Ben Finney


From python at mrabarnett.plus.com  Mon Dec 28 02:21:07 2009
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 28 Dec 2009 01:21:07 +0000
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>
	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
Message-ID: <4B380803.6020607@mrabarnett.plus.com>

Tarek Ziad? wrote:
> On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar
> <sridharr at activestate.com> wrote:
> [..]
>> Tarek,
>>
>> I am a bit confused at the current proposal combined with the newly
>> introduced range operator.
>>
>> Would "Requires-Python: <=2.5" include 2.5.4 or not?
> 
> <=2.5 means any version that is inferior or equal to 2.5.0 so 2.5.4
> doesn't match
> 
>> Also, "Requires-Python: 3" would include all 3.X versions, correct?
> 
> Correct, because, "Requires-Python: 3" is equivalent to "Requires-Python: ~= 3"
> which is equivalent to "Requires-Python: 3.x.x"
> 
To me it's non-intuitive that "<=2.5" means <=2.5.0 but "2.5" means 
2.5.x; it's not consistent, explicit is better than implicit, etc.

I'd prefer it if omission means "don't care", so "2" means 2.x.y and
"2.5" means 2.5.x.

From arfrever.fta at gmail.com  Mon Dec 28 02:28:09 2009
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 28 Dec 2009 02:28:09 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <87fx6v6gnx.fsf@benfinney.id.au>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
Message-ID: <200912280228.14851.Arfrever.FTA@gmail.com>

2009-12-28 02:17:22 Ben Finney napisa?(a):
> Tarek Ziad? <ziade.tarek at gmail.com> writes:
> 
> > On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar
> > <sridharr at activestate.com> wrote:
> > > Also, "Requires-Python: 3" would include all 3.X versions, correct?
> >
> > Correct, because, "Requires-Python: 3" is equivalent to
> > "Requires-Python: ~= 3" which is equivalent to "Requires-Python:
> > 3.x.x"
> 
> This is totally counter to conventional comparisons, and is an excellent
> example of why the equivalence of ?3? to ?>=3, <4? is a bad idea.
> 
> Instead, the default should be ?==?. That is, ?Requires-Python: 3?
> should be equivalent to ?Requires-Python: ==3?; and only ?3? or ?3.0? or
> ?3.0.0? etc. will match. I maintain that is what most people will expect
> on seeing that syntax.
> 
> If a less strict range is desired, the existing comparison operators
> ?>?, ?>=?, ?<?, ?<=? are sufficient, more obvious, and more explicit. In
> other words, to get the meaning you desire above, the existing operators
> can be used: ?Requires-Python: >=3, <4?.

IMHO 'Requires-Python: 3*' (or '3.*') would be better than 'Requires-Python: >=3, <4'.

-- 
Arfrever Frehtes Taifersar Arahesis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091228/2024849c/attachment.pgp>

From python at mrabarnett.plus.com  Mon Dec 28 02:28:01 2009
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 28 Dec 2009 01:28:01 +0000
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <87fx6v6gnx.fsf@benfinney.id.au>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>
	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<4B37FEB9.1010205@activestate.com>	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
Message-ID: <4B3809A1.7060709@mrabarnett.plus.com>

Ben Finney wrote:
> Tarek Ziad? <ziade.tarek at gmail.com> writes:
> 
>> On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar
>> <sridharr at activestate.com> wrote:
>>> Also, "Requires-Python: 3" would include all 3.X versions, correct?
>> Correct, because, "Requires-Python: 3" is equivalent to
>> "Requires-Python: ~= 3" which is equivalent to "Requires-Python:
>> 3.x.x"
> 
> This is totally counter to conventional comparisons, and is an excellent
> example of why the equivalence of ?3? to ?>=3, <4? is a bad idea.
> 
> Instead, the default should be ?==?. That is, ?Requires-Python: 3?
> should be equivalent to ?Requires-Python: ==3?; and only ?3? or ?3.0? or
> ?3.0.0? etc. will match. I maintain that is what most people will expect
> on seeing that syntax.
> 
> If a less strict range is desired, the existing comparison operators
> ?>?, ?>=?, ?<?, ?<=? are sufficient, more obvious, and more explicit. In
> other words, to get the meaning you desire above, the existing operators
> can be used: ?Requires-Python: >=3, <4?.
> 
Perhaps there should be a new range operator:

     Requires-Python: 3 ~ 4

Half-open, of course.

From fdrake at acm.org  Mon Dec 28 02:34:31 2009
From: fdrake at acm.org (Fred Drake)
Date: Sun, 27 Dec 2009 20:34:31 -0500
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <200912280228.14851.Arfrever.FTA@gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com> 
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com> 
	<87fx6v6gnx.fsf@benfinney.id.au>
	<200912280228.14851.Arfrever.FTA@gmail.com>
Message-ID: <9cee7ab80912271734o3f5df567w9e20d1f3b63a4ad8@mail.gmail.com>

On Sun, Dec 27, 2009 at 8:28 PM, Arfrever Frehtes Taifersar Arahesis
<arfrever.fta at gmail.com> wrote:
> 'Requires-Python: 3*' (or '3.*') would be better than 'Requires-Python: >=3, <4'.

Maybe.

MRAB wrote:
> Requires-Python: 3 ~ 4

Ugh.  -1


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller

From ssteinerx at gmail.com  Mon Dec 28 03:20:56 2009
From: ssteinerx at gmail.com (ssteinerX@gmail.com)
Date: Sun, 27 Dec 2009 21:20:56 -0500
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <94bdd2610912271702k662621ecve996eb7f9ff181fd@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>
	<loom.20091228T014312-369@post.gmane.org>
	<94bdd2610912271702k662621ecve996eb7f9ff181fd@mail.gmail.com>
Message-ID: <3BE235C6-A1EB-4668-A107-40914F4ACF4D@gmail.com>


On Dec 27, 2009, at 8:02 PM, Tarek Ziad? wrote:

> On Mon, Dec 28, 2009 at 1:48 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> Tarek Ziad? <ziade.tarek <at> gmail.com> writes:
>>> 
>>> This was ambiguous because it was unclear, as MvL stated,  if "2.5"
>>> was just "2.5.0" or included
>>> versions like "2.5.1" or "2.5.2".
>> 
>> How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5
>> itself? (ditto for "2.5.N" matching only 2.5.N for N >= 1)
>> 
>> This "~=" operator looks murkier than it needs to be IMO.
> 
> An implicit range operator is simpler indeed, and achieves the same goal.
> 
> Meaning that "<=2.5" for example, will be translated to "<=2.5.x" as well.

It seems to me that all this version range talk relates pretty directly to PEP 386.

The Python version numbers themselves are the simplest type of "Normalized Version"s, and since comparisons of "NormalizedVersion"s are defined in PEP 386, and that's really all we're talking about here, shouldn't this really just follow and reference that document?

Sure we might like some sugar to make expressing ranges simpler, but shouldn't the explicit meanings of any rules be stated in terms of Normalized Version comparisons?

S


From sridharr at activestate.com  Mon Dec 28 02:39:08 2009
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Sun, 27 Dec 2009 17:39:08 -0800
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <4B380803.6020607@mrabarnett.plus.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<4B37FEB9.1010205@activestate.com>	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<4B380803.6020607@mrabarnett.plus.com>
Message-ID: <4B380C3C.1060501@activestate.com>

On 12/27/2009 5:21 PM, MRAB wrote:
> Tarek Ziad? wrote:
>> On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar
>> <sridharr at activestate.com> wrote:
>> [..]
>>> Tarek,
>>>
>>> I am a bit confused at the current proposal combined with the newly
>>> introduced range operator.
>>>
>>> Would "Requires-Python: <=2.5" include 2.5.4 or not?
>>
>> <=2.5 means any version that is inferior or equal to 2.5.0 so 2.5.4
>> doesn't match
>>
>>> Also, "Requires-Python: 3" would include all 3.X versions, correct?
>>
>> Correct, because, "Requires-Python: 3" is equivalent to
>> "Requires-Python: ~= 3"
>> which is equivalent to "Requires-Python: 3.x.x"
>>
> To me it's non-intuitive that "<=2.5" means <=2.5.0 but "2.5" means
> 2.5.x; it's not consistent, explicit is better than implicit, etc.

Yes. When we talk about Python-2.5 (as in, for instance, "this script 
requires Python 2.5 to run"), we are referring to 2.5.x, and not just 2.5.0.

> I'd prefer it if omission means "don't care", so "2" means 2.x.y and
> "2.5" means 2.5.x.

+1.

On 12/27/2009 4:37 PM, Tarek Ziad? wrote:
 > As discussed in Distutils-SIG, 2.5 is not strictly equal to 2.5.2.
 > That's exactly why we introduced
 > the range operator. So one may make a clear distinction between
 > "2.5.x" and "2.5".

Perhaps if "2.5" was instead considered to be a *range* of possible 
versions (2.5.0, ... 2.5.4), then this ambiguity wouldn't have arisen in 
first place?

Technically (Include/patchlevel.h), it is "2.5.0", not "2.5".

-srid

From python at mrabarnett.plus.com  Mon Dec 28 03:03:08 2009
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 28 Dec 2009 02:03:08 +0000
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <4B38038D.8050307@v.loewis.de>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<4B325C50.6040902@v.loewis.de>	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>	<75d5dd69b850e9bd793b43618327e655@preisshare.net>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>
	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B38038D.8050307@v.loewis.de>
Message-ID: <4B3811DC.8040500@mrabarnett.plus.com>

Martin v. L?wis wrote:
>> No application developer will quickly figure out what a tilde means. Maybe
>> it means 'roughly', but it requires too much thought and is ambiguous. 2.5
>> is not roughly 2.5.2. It is the same exactly.
>>
>> Before we had : Requires-Python: 2.5, 2.6
>>
>> That made much more sense. It was simple and unambiguous, and is relevant
>> to typical packaging scenarios.
> 
> Unfortunately, it is fairly ambiguous, and makes no sense. It means
> "requires Python 2.5 *AND* requires Python 2.6", which is a requirement
> that no single version can meet.
> 
Does that mean we should add "or"?

     Requires-Python: 2.5 or 2.6

Should we also use "and" instead of ","?

     Requires-Python: >= 2.5 and < 2.6

From python at mrabarnett.plus.com  Mon Dec 28 03:03:05 2009
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 28 Dec 2009 02:03:05 +0000
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <200912280228.14851.Arfrever.FTA@gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>	<87fx6v6gnx.fsf@benfinney.id.au>
	<200912280228.14851.Arfrever.FTA@gmail.com>
Message-ID: <4B3811D9.5010604@mrabarnett.plus.com>

Arfrever Frehtes Taifersar Arahesis wrote:
> 2009-12-28 02:17:22 Ben Finney napisa?(a):
>> Tarek Ziad? <ziade.tarek at gmail.com> writes:
>>
>>> On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar
>>> <sridharr at activestate.com> wrote:
>>>> Also, "Requires-Python: 3" would include all 3.X versions, correct?
>>> Correct, because, "Requires-Python: 3" is equivalent to
>>> "Requires-Python: ~= 3" which is equivalent to "Requires-Python:
>>> 3.x.x"
>> This is totally counter to conventional comparisons, and is an excellent
>> example of why the equivalence of ?3? to ?>=3, <4? is a bad idea.
>>
>> Instead, the default should be ?==?. That is, ?Requires-Python: 3?
>> should be equivalent to ?Requires-Python: ==3?; and only ?3? or ?3.0? or
>> ?3.0.0? etc. will match. I maintain that is what most people will expect
>> on seeing that syntax.
>>
>> If a less strict range is desired, the existing comparison operators
>> ?>?, ?>=?, ?<?, ?<=? are sufficient, more obvious, and more explicit. In
>> other words, to get the meaning you desire above, the existing operators
>> can be used: ?Requires-Python: >=3, <4?.
> 
> IMHO 'Requires-Python: 3*' (or '3.*') would be better than 'Requires-Python: >=3, <4'.
> 
'3.*' would be the better of the two.

From stephen at xemacs.org  Mon Dec 28 04:17:55 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 28 Dec 2009 12:17:55 +0900
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python
	Software	Packages 1.2
In-Reply-To: <87fx6v6gnx.fsf@benfinney.id.au>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
Message-ID: <87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>

Ben Finney writes:

 > Instead, the default should be `=='. That is, `Requires-Python: 3'
 > should be equivalent to `Requires-Python: ==3'; and only "3" or "3.0" or
 > "3.0.0" etc. will match. I maintain that is what most people will expect
 > on seeing that syntax.

I really don't think your assessment that a majority agrees with you
is warranted.  The demand for backward compatibility is so strong that
(wearing my maintainer hat, in other projects) I actually assume that
in compatibility claims a bare version number like 3 means >= 3.0.0 to
my listeners, unless explicitly qualified.

Therefore, I think there should be no default.  "Explicit is better
than implicit."

And IMO the choice of "~=" or "=~" for the range match should be
avoided, since that looks like the regexp search operator in Perl, and
there "~= 3" would match "3", "3.0.4", and "2.3.5".  The next obvious
interpretation is "fuzzy match", but that doesn't have an obvious,
more specific meaning.  The usual comparson operators do have pretty
obvious interpretations, and are not hard to use.

From david.lyon at preisshare.net  Mon Dec 28 05:07:04 2009
From: david.lyon at preisshare.net (david.lyon at preisshare.net)
Date: Mon, 28 Dec 2009 15:07:04 +1100 (EST)
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <4B38038D.8050307@v.loewis.de>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B325C50.6040902@v.loewis.de>
	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>
	<75d5dd69b850e9bd793b43618327e655@preisshare.net>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B38038D.8050307@v.loewis.de>
Message-ID: <2525.115.128.29.13.1261973224.squirrel@syd-srv02.ezyreg.com>

>> No application developer will quickly figure out what a tilde means.
>> Maybe
>> it means 'roughly', but it requires too much thought and is ambiguous.
>> 2.5
>> is not roughly 2.5.2. It is the same exactly.
>>
>> Before we had : Requires-Python: 2.5, 2.6
>>
>> That made much more sense. It was simple and unambiguous, and is
>> relevant
>> to typical packaging scenarios.
>
> Unfortunately, it is fairly ambiguous, and makes no sense. It means
> "requires Python 2.5 *AND* requires Python 2.6", which is a requirement
> that no single version can meet.

No, it means a library requires either python 2.5 *OR* python 2.6 to be
installed properly.

If not, the implication is that the user will be prompted to install anyway.

David



From david.lyon at preisshare.net  Mon Dec 28 05:23:44 2009
From: david.lyon at preisshare.net (david.lyon at preisshare.net)
Date: Mon, 28 Dec 2009 15:23:44 +1100 (EST)
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <87fx6v6gnx.fsf@benfinney.id.au>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
Message-ID: <4595.115.128.29.13.1261974224.squirrel@syd-srv02.ezyreg.com>

> Instead, the default should be ???==???. That is, ???Requires-Python: 3???
> should be equivalent to ???Requires-Python: ==3???; and only ???3??? or
> ???3.0??? or
> ???3.0.0??? etc. will match. I maintain that is what most people will
> expect
> on seeing that syntax.
>
> If a less strict range is desired, the existing comparison operators
> ???>???, ???>=???, ???<???, ???<=??? are sufficient, more obvious, and
> more explicit. In
> other words, to get the meaning you desire above, the existing operators
> can be used: ???Requires-Python: >=3, <4???.

Yes,

so that:

  Requires-Python: 1,2,3

means python versions 1,2 or 3.

  Requires-Python: 3

means requires python 3 only. Any version of 3

Whereas:

  Requires-Python: 3.0, 3.1

means only 3.0 and 3.1

  Requires-Python: 2.3, 2.4, 2.5, 2.6

That means, those particular versions.

A user can still try to install on other versions. But
they would get a warning and would do so at their own
risk.

There's no need for extra operator characters as far
as I can see. The comma method proposed originally
seemed to do everything.

David





From greg at krypto.org  Mon Dec 28 05:32:03 2009
From: greg at krypto.org (Gregory P. Smith)
Date: Sun, 27 Dec 2009 20:32:03 -0800
Subject: [Python-Dev] Disallow float arguments where an integer is
	expected in Python 2.7.
In-Reply-To: <5c6f2a5d0912210702u4e20f1b1oa72104b4bb88059d@mail.gmail.com>
References: <5c6f2a5d0912210702u4e20f1b1oa72104b4bb88059d@mail.gmail.com>
Message-ID: <52dc1c820912272032t17a80a9bu73b00edb63387d6f@mail.gmail.com>

On Mon, Dec 21, 2009 at 7:02 AM, Mark Dickinson <dickinsm at gmail.com> wrote:
> In Python 2.7, PyArg_ParseTuple and friends currently accept a float
> argument where an integer is expected, but produce a
> DeprecationWarning in this case. ?This can be seen in various places
> in Python proper:
>
>>>> itertools.combinations(range(5), 2.0)
> __main__:1: DeprecationWarning: integer argument expected, got float
> <itertools.combinations object at 0x10059f638>
>
> Are there any objections to turning this DeprecationWarning into a
> TypeError for Python 2.7? ?The behaviour has been deprecated since
> Python 2.3, it's gone in 3.x, and having it produce an error in 2.7
> might slightly reduce the number of surprises involved in porting from
> 2.x to 3.x. ?There's a patch at http://bugs.python.org/issue5080
>
> There's one fly in the ointment: ?the deprecation warning is produced
> for all integer codes except for one---the 'L' code. ?The patch adds a
> deprecation warning for this code.
>
> Mark

+0.5 from me assuming that warning has been present by default in
python 2.5 and 2.6.  (the fly prevents me from giving it a full +1 as
it effectively means some APIs have never issued the warning at all).
No hard feelings if the 'L' forces us to back off and not do this.  At
least its fixed in 3.x.

From tjreedy at udel.edu  Mon Dec 28 05:37:06 2009
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 27 Dec 2009 23:37:06 -0500
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <loom.20091228T014312-369@post.gmane.org>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<75d5dd69b850e9bd793b43618327e655@preisshare.net>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>
	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>
	<loom.20091228T014312-369@post.gmane.org>
Message-ID: <hh9cle$hmb$1@ger.gmane.org>

On 12/27/2009 7:48 PM, Antoine Pitrou wrote:
> Tarek Ziad?<ziade.tarek<at>  gmail.com>  writes:
>>
>> This was ambiguous because it was unclear, as MvL stated,  if "2.5"
>> was just "2.5.0" or included
>> versions like "2.5.1" or "2.5.2".
>
> How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5
> itself? (ditto for "2.5.N" matching only 2.5.N for N>= 1)

If the first x.y release were called x.y.0, (does not sys.version 
include 0?) then x.y would unambiguously mean the series.

> This "~=" operator looks murkier than it needs to be IMO.

Agreed, though not likely to affect me too much.

Terry Jan Reedy



From david.lyon at preisshare.net  Mon Dec 28 05:41:41 2009
From: david.lyon at preisshare.net (david.lyon at preisshare.net)
Date: Mon, 28 Dec 2009 15:41:41 +1100 (EST)
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <94bdd2610912271702k662621ecve996eb7f9ff181fd@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>
	<loom.20091228T014312-369@post.gmane.org>
	<94bdd2610912271702k662621ecve996eb7f9ff181fd@mail.gmail.com>
Message-ID: <2883.115.128.29.13.1261975301.squirrel@syd-srv02.ezyreg.com>

>> Tarek Ziad? <ziade.tarek <at> gmail.com> writes:
> An implicit range operator is simpler indeed, and achieves the same goal.
>
> Meaning that "<=2.5" for example, will be translated to "<=2.5.x" as well.

With respect, it's not a very common use case for a developer to
say that package needs a python interpretor 'older' than 2.5.

There comes a point where you can just not expect a python
interpretor, say 1.3, to not work with your package. So they
wouldn't say that. I don't think.

Nor would they say it going forward. So ">=2.5" might be too
bold a claim for them to make. As they might not have
tested on the 'latest-and-greatest' interpretor. That
would imply that they know it works on all 3 series interpretors.

imho, all that they would know, is that they're using python
(for example) 2.4 or 2.5 (pick a python version) and they
know it works pretty well.

It's then up to the user if they want to use it on any other
version.

That's why I don't think we need the '=' '>=' operator
characters to represent typical use cases.

If there's any use-case, that I have missed. Do let me
know.

David



From tseaver at palladion.com  Mon Dec 28 06:16:43 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 28 Dec 2009 00:16:43 -0500
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <hh9cle$hmb$1@ger.gmane.org>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<75d5dd69b850e9bd793b43618327e655@preisshare.net>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>	<loom.20091228T014312-369@post.gmane.org>
	<hh9cle$hmb$1@ger.gmane.org>
Message-ID: <hh9evr$lh0$1@ger.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Terry Reedy wrote:
> On 12/27/2009 7:48 PM, Antoine Pitrou wrote:
>> Tarek Ziad?<ziade.tarek<at>  gmail.com>  writes:
>>> This was ambiguous because it was unclear, as MvL stated,  if "2.5"
>>> was just "2.5.0" or included
>>> versions like "2.5.1" or "2.5.2".
>> How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5
>> itself? (ditto for "2.5.N" matching only 2.5.N for N>= 1)
> 
> If the first x.y release were called x.y.0, (does not sys.version 
> include 0?) then x.y would unambiguously mean the series.

This syntax is not just for the 'Requires-Python:' field, but also for
the 'Requires-Dist:' and 'Obsoletes-Dist:' fields:  not all third-party
packages call the first release of a given series .0.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAks4PzUACgkQ+gerLs4ltQ551gCgyVNvpJayTWGiCNbg4NKw4p/y
uG8An1u90cHfKVaUqIAkUlZSI92g6PxL
=7h2c
-----END PGP SIGNATURE-----


From stephen at xemacs.org  Mon Dec 28 06:28:08 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 28 Dec 2009 14:28:08 +0900
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <2525.115.128.29.13.1261973224.squirrel@syd-srv02.ezyreg.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B325C50.6040902@v.loewis.de>
	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>
	<75d5dd69b850e9bd793b43618327e655@preisshare.net>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B38038D.8050307@v.loewis.de>
	<2525.115.128.29.13.1261973224.squirrel@syd-srv02.ezyreg.com>
Message-ID: <87bphjpt07.fsf@uwakimon.sk.tsukuba.ac.jp>

david.lyon at preisshare.net writes:

 > >> Before we had : Requires-Python: 2.5, 2.6
 > >>
 > >> That made much more sense. It was simple and unambiguous, and is
 > >> relevant to typical packaging scenarios.
 > >
 > > Unfortunately, it is fairly ambiguous, and makes no sense. It means
 > > "requires Python 2.5 *AND* requires Python 2.6", which is a requirement
 > > that no single version can meet.
 > 
 > No, it means a library requires either python 2.5 *OR* python 2.6 to be
 > installed properly.

If Martin and the SIG disagree on the interpretation (and I see
Martin's point: in ">=2.5, <2.6" the comma is a conjunction, not a
disjunction), that's too much ambiguity for me.

-1



From tseaver at palladion.com  Mon Dec 28 06:20:12 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 28 Dec 2009 00:20:12 -0500
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>
	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
Message-ID: <hh9f6c$lh0$2@ger.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tarek Ziad? wrote:
> On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar
> <sridharr at activestate.com> wrote:
> [..]
>> Tarek,
>>
>> I am a bit confused at the current proposal combined with the newly
>> introduced range operator.
>>
>> Would "Requires-Python: <=2.5" include 2.5.4 or not?
> 
> <=2.5 means any version that is inferior or equal to 2.5.0 so 2.5.4
> doesn't match
> 
>> Also, "Requires-Python: 3" would include all 3.X versions, correct?
> 
> Correct, because, "Requires-Python: 3" is equivalent to "Requires-Python: ~= 3"
> which is equivalent to "Requires-Python: 3.x.x"
> 

Point of order:  what is the point of sending the discussion off to the
distutils SIG if we are just going to bikeshed it (again!) here.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAks4QAwACgkQ+gerLs4ltQ5LJACfY9ijtkw/Bsyg2xXp93xNtbhy
QAUAnRBZWSMk+izGDEjVkHVLpu418gfR
=vM/V
-----END PGP SIGNATURE-----


From regebro at gmail.com  Mon Dec 28 07:39:31 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 28 Dec 2009 07:39:31 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <hh9cle$hmb$1@ger.gmane.org>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>
	<loom.20091228T014312-369@post.gmane.org> <hh9cle$hmb$1@ger.gmane.org>
Message-ID: <319e029f0912272239g593053c9x12b5cd73513d35aa@mail.gmail.com>

On Mon, Dec 28, 2009 at 05:37, Terry Reedy <tjreedy at udel.edu> wrote:
> If the first x.y release were called x.y.0, (does not sys.version include
> 0?) then x.y would unambiguously mean the series.

Yeah, well, although sys.version includes the zero, nothing else does.
The first releases are called 2.5, which is ambiguous. Both Python and
Plone leaves out the zero in the version name. IMO that's a bug. But
that's now how it is.

However, there are two ways of writing versions that are completely
unambiguous and which every programmer will immediately understand:

    2.5.0
and
    2.5.*

Done.


The comma is problematic. If you want to specify 2.5 or 2.6, it would
be natural to write:

     Requires-Python: 2.5.*, 2.6.*

Which clearly has the comma meaning "or". But it would also make sense to write:

     Requires-Python: >= 2.5.2, < 3.0.0

Where it is an "and". But trying to leave commas out leaves us with
the slightly weird syntax of

     Requires-Python: >= 2.5.2 and < 3.0.0 or >= 3.1.*

And then it's the question of in what order that should be
interpreted. And what would

     Requires-Python: >= 3.1.* or >= 2.5.2 and < 3.0.0

mean? And would

     Requires-Python: >= 2.5.2 or >= 3.1.* and  < 3.0.0

Be legal an mean anything?

My conclusion: This is a place where the normal computer logic syntax
makes so sense, it's either too restrictive, or too flexible. We need
something  custom, where we can specify pairs of two versions, min and
max and have several pairs. Also, the min version can always be
included and the max version excluded. You need to write things like:
>= 2.5.2 and < 3.0.0. You never need to write <= 2.5.7, because you
can always write < 2.5.8 instead.

Now, this "starting from and then up until but not including" is
something that is quite common in Python. Namely when slicing. It
works exactly like that. [3:9] means from 3 and up until but not
including 9. Hence, a clear and unambiguous and extremely Pythonic way
of specifying a version range is: [2.5.2:3.0.0]. No <= or commas
anywhere. We can also specify a list of ranges by having semicolons
between them. The grammar ends up something like this:

versionrequirements ::= 'Requires-Python: ' specificationlist
specificationlist   ::= specification (; specification)*
specification       ::= version | "[" [version] ":" [version] "]"
version             ::= lc_number "." (lc_number | "*") "." [lc_number | "*"]

With examples being:

     Requires-Python: [2.5.2:3.0.0]; [3.1.*:]

Or on several rows:

     Requires-Python: [2.5.2:3.0.0];
                     [3.1.2:];
                     [3.2.*]


Now, if <=>== etc is deemed necessary, we could use something like this:

versionrequirements ::= 'Requires-Python: ' specificationlist
specificationlist   ::= specification (; specification)*
specification       ::= version | minimum | maximum | miniumum " " maximum
minimum             ::= ('>' | '>=') version
maximum             ::= ('<' | '<=') version
version             ::= lc_number "." (lc_number | "*") "." [lc_number | "*"]

That would mean something like the following:

     Requires-Python: >= 2.5.2 < 3.0.0; >= 3.1*

or more clearer if it's split up in lines:

     Requires-Python: >= 2.5.2 < 3.0.0;
                     >= 3.1*

The following would be illegal:

     Requires-Python: >= 2.5.2 > 3.0.0
     Requires-Python: <= 2.5.2 < 3.0.0
     Requires-Python: <= 2.5.2 < 3.0.0 > 3.1*

No commas or ands or ors anywhere. But I like the first syntax better.

From stephen at xemacs.org  Mon Dec 28 07:59:59 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 28 Dec 2009 15:59:59 +0900
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <2883.115.128.29.13.1261975301.squirrel@syd-srv02.ezyreg.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>
	<loom.20091228T014312-369@post.gmane.org>
	<94bdd2610912271702k662621ecve996eb7f9ff181fd@mail.gmail.com>
	<2883.115.128.29.13.1261975301.squirrel@syd-srv02.ezyreg.com>
Message-ID: <87aax3por4.fsf@uwakimon.sk.tsukuba.ac.jp>

david.lyon at preisshare.net writes:

 > With respect, it's not a very common use case for a developer to
 > say that package needs a python interpretor 'older' than 2.5.

Of course it is.  I don't claim it is the majority of cases out there,
but stable versions of many of the packages I use will specify an
older python (Mailman and Zope both specify a range of Pythons, rarely
including the most recent release, and Bazaar, although it tries to
keep up with Python releases, tends to recommend being conservative,
sticking to release (n-1) for the first few months into release n.)

And in fact this case is often more the important one.  Packages that
depend on having a *recent* version of python will often crash
quickly, before doing permanent damage, when an undefined syntax,
function, or method is invoked, while packages that depend on a quirk
in behavior of an older version will typically silently corrupt data.

 > imho, all that they would know, is that they're using python
 > (for example) 2.4 or 2.5 (pick a python version) and they
 > know it works pretty well.

If they want to specify a Python version that works, they may as well
bundle it, and many do.  But even in that case the user may want to
know about the dependency.

BTW, *all* of the Python applications I really care about make a point
of specifying a range of versions they work with (or bundle a
particular version).  So in fact many developers do know what versions
work or fail, and often why (and they sometimes even provide
workarounds/patches for adventurers who want to use a Python outside
of the recommended range).

 > It's then up to the user if they want to use it on any other
 > version.

This is often an undesirable posture.  From the user's point of view,
the system version of Python may have passed various local tests and
therefore be strongly preferred (for example, requiring far less time
for approval from the security team).  This is especially true for
mail or web applications and other applications that must run in a
very hostile environment.  Many developers do want to provide this
kind of information to such users.

I think you should rethink your position on how valid your personal
intuitions are for generalization.  You are certainly representative
of a certain important segment of developers, but I don't think you
have a good sense of the very broad class of requirements that other
developers are bringing to the table.

From solipsis at pitrou.net  Mon Dec 28 08:02:46 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 28 Dec 2009 08:02:46 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <87aax3por4.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>
	<loom.20091228T014312-369@post.gmane.org>
	<94bdd2610912271702k662621ecve996eb7f9ff181fd@mail.gmail.com>
	<2883.115.128.29.13.1261975301.squirrel@syd-srv02.ezyreg.com>
	<87aax3por4.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <1261983766.3346.3.camel@localhost>


> And in fact this case is often more the important one.  Packages that
> depend on having a *recent* version of python will often crash
> quickly, before doing permanent damage, when an undefined syntax,
> function, or method is invoked, while packages that depend on a quirk
> in behavior of an older version will typically silently corrupt data.

How can they know that they depend on "a quirk in behaviour of an older
version" if a newer version hasn't been released? This sounds bogus.

Besides, not letting me install their app/library on a newer Python just
because they are not /sure/ it will work is IMO an active nuisance. The
user should be treated as an adult.



From david.lyon at preisshare.net  Mon Dec 28 08:44:22 2009
From: david.lyon at preisshare.net (david.lyon at preisshare.net)
Date: Mon, 28 Dec 2009 18:44:22 +1100 (EST)
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <87aax3por4.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>
	<loom.20091228T014312-369@post.gmane.org>
	<94bdd2610912271702k662621ecve996eb7f9ff181fd@mail.gmail.com>
	<2883.115.128.29.13.1261975301.squirrel@syd-srv02.ezyreg.com>
	<87aax3por4.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <1217.115.128.49.23.1261986262.squirrel@syd-srv02.ezyreg.com>

> david.lyon at preisshare.net writes:
>
>  > With respect, it's not a very common use case for a developer to
>  > say that package needs a python interpretor 'older' than 2.5.
>
> Of course it is.  I don't claim it is the majority of cases out there,
> but stable versions of many of the packages I use will specify an
> older python (Mailman and Zope both specify a range of Pythons, rarely
> including the most recent release, and Bazaar, although it tries to
> keep up with Python releases, tends to recommend being conservative,
> sticking to release (n-1) for the first few months into release n.)
>
> And in fact this case is often more the important one.  Packages that
> depend on having a *recent* version of python will often crash
> quickly, before doing permanent damage, when an undefined syntax,
> function, or method is invoked, while packages that depend on a quirk
> in behavior of an older version will typically silently corrupt data.
>
>  > imho, all that they would know, is that they're using python
>  > (for example) 2.4 or 2.5 (pick a python version) and they
>  > know it works pretty well.
>
> If they want to specify a Python version that works, they may as well
> bundle it, and many do.  But even in that case the user may want to
> know about the dependency.
>
> BTW, *all* of the Python applications I really care about make a point
> of specifying a range of versions they work with (or bundle a
> particular version).  So in fact many developers do know what versions
> work or fail, and often why (and they sometimes even provide
> workarounds/patches for adventurers who want to use a Python outside
> of the recommended range).
>
>  > It's then up to the user if they want to use it on any other
>  > version.
>
> This is often an undesirable posture.  From the user's point of view,
> the system version of Python may have passed various local tests and
> therefore be strongly preferred (for example, requiring far less time
> for approval from the security team).  This is especially true for
> mail or web applications and other applications that must run in a
> very hostile environment.  Many developers do want to provide this
> kind of information to such users.
>
> I think you should rethink your position on how valid your personal
> intuitions are for generalization.  You are certainly representative
> of a certain important segment of developers, but I don't think you
> have a good sense of the very broad class of requirements that other
> developers are bringing to the table.
>



From david.lyon at preisshare.net  Mon Dec 28 08:55:02 2009
From: david.lyon at preisshare.net (david.lyon at preisshare.net)
Date: Mon, 28 Dec 2009 18:55:02 +1100 (EST)
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <87aax3por4.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>
	<loom.20091228T014312-369@post.gmane.org>
	<94bdd2610912271702k662621ecve996eb7f9ff181fd@mail.gmail.com>
	<2883.115.128.29.13.1261975301.squirrel@syd-srv02.ezyreg.com>
	<87aax3por4.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <1423.115.128.16.226.1261986902.squirrel@syd-srv02.ezyreg.com>

Hi Stephen,

> BTW, *all* of the Python applications I really care about make a point
> of specifying a range of versions they work with (or bundle a
> particular version).

Yes, well that was my point exactly.

If opinion is against commas, then we can take them out.

That would give us something like:

  Requires-python: 2.5 2.6 2.7 3

That would specify a bundle of versions.

Processing that only requires the string split() function.

If we were to adds Lens suggestion of the range indicator
that would simplify things even more.

  Requires-python: 2.5:2.7 3

That would specify everything between 2.5 and 2.7 and then
everything in the 3 series.

This would make it very simple.

David



From ziade.tarek at gmail.com  Mon Dec 28 09:45:21 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 28 Dec 2009 09:45:21 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <319e029f0912272239g593053c9x12b5cd73513d35aa@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>
	<loom.20091228T014312-369@post.gmane.org> <hh9cle$hmb$1@ger.gmane.org>
	<319e029f0912272239g593053c9x12b5cd73513d35aa@mail.gmail.com>
Message-ID: <94bdd2610912280045u13e03d01q4f2c7ab8dd9fb5dc@mail.gmail.com>

On Mon, Dec 28, 2009 at 7:39 AM, Lennart Regebro <regebro at gmail.com> wrote:
> On Mon, Dec 28, 2009 at 05:37, Terry Reedy <tjreedy at udel.edu> wrote:
>> If the first x.y release were called x.y.0, (does not sys.version include
>> 0?) then x.y would unambiguously mean the series.
>
> Yeah, well, although sys.version includes the zero, nothing else does.
> The first releases are called 2.5, which is ambiguous. Both Python and
> Plone leaves out the zero in the version name. IMO that's a bug. But
> that's now how it is.

Yes but in PEP 386 semantics, 2.5 will be equivalent to 2.5.0, so it
doesn't matter
if a software doesn't use the .0


Tarek

-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Mon Dec 28 10:05:55 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 28 Dec 2009 10:05:55 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <hh9f6c$lh0$2@ger.gmane.org>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<hh9f6c$lh0$2@ger.gmane.org>
Message-ID: <94bdd2610912280105s9dac69w7719effe795ecf8f@mail.gmail.com>

On Mon, Dec 28, 2009 at 6:20 AM, Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tarek Ziad? wrote:
>> On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar
>> <sridharr at activestate.com> wrote:
>> [..]
>>> Tarek,
>>>
>>> I am a bit confused at the current proposal combined with the newly
>>> introduced range operator.
>>>
>>> Would "Requires-Python: <=2.5" include 2.5.4 or not?
>>
>> <=2.5 means any version that is inferior or equal to 2.5.0 so 2.5.4
>> doesn't match
>>
>>> Also, "Requires-Python: 3" would include all 3.X versions, correct?
>>
>> Correct, because, "Requires-Python: 3" is equivalent to "Requires-Python: ~= 3"
>> which is equivalent to "Requires-Python: 3.x.x"
>>
>
> Point of order: ?what is the point of sending the discussion off to the
> distutils SIG if we are just going to bikeshed it (again!) here.

What happened is that Martin came late in the discussions in
Distutils-SIG after I've forwarded the final
mail in Catalog-SIG and after I did send it here (the mail where I
said "Here's the mail I'll send to python-dev for PEP 345, if anyone
sees a problem or something to add")

I agree that the comma and syntax discussions are bikeshedding.
Although I don't think the range discussion is bikeshedding, and so
far we made some progress on clarifying how range versions are
compared in that PEP through Martin's points and this thread. It's
quite important IMHO to clarify it.

So, if no one object, I propose to continue this thread about the way
range should be compared, to see if we meet a consensus quite soon. If
not, I guess we can go back to distutils-SIG and invite people over
there, as we did for other topics.

Regards,
Tarek

-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Mon Dec 28 10:11:32 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 28 Dec 2009 10:11:32 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <hh9evr$lh0$1@ger.gmane.org>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>
	<loom.20091228T014312-369@post.gmane.org> <hh9cle$hmb$1@ger.gmane.org>
	<hh9evr$lh0$1@ger.gmane.org>
Message-ID: <94bdd2610912280111r30881557wc2539ed371814d54@mail.gmail.com>

On Mon, Dec 28, 2009 at 6:16 AM, Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Terry Reedy wrote:
>> On 12/27/2009 7:48 PM, Antoine Pitrou wrote:
>>> Tarek Ziad?<ziade.tarek<at> ?gmail.com> ?writes:
>>>> This was ambiguous because it was unclear, as MvL stated, ?if "2.5"
>>>> was just "2.5.0" or included
>>>> versions like "2.5.1" or "2.5.2".
>>> How about having "2.5" match all 2.5.x versions, and "2.5.0" match only 2.5
>>> itself? (ditto for "2.5.N" matching only 2.5.N for N>= 1)
>>
>> If the first x.y release were called x.y.0, (does not sys.version
>> include 0?) then x.y would unambiguously mean the series.
>
> This syntax is not just for the 'Requires-Python:' field, but also for
> the 'Requires-Dist:' and 'Obsoletes-Dist:' fields: ?not all third-party
> packages call the first release of a given series .0.

They do start with "2.5" *or* "2.5.0" for their first release of the
2.5 series. And both are equal for PEP 386. IOW "2.5 == 2.5.0",
always.

So it doesn't really matter if some projects don't use the terminal 0
here. Antoine's proposal still works.


Tarek

From ziade.tarek at gmail.com  Mon Dec 28 10:14:55 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 28 Dec 2009 10:14:55 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <4B3811DC.8040500@mrabarnett.plus.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B38038D.8050307@v.loewis.de> <4B3811DC.8040500@mrabarnett.plus.com>
Message-ID: <94bdd2610912280114n13e1ee66g6e0ad47d8f8e3da9@mail.gmail.com>

On Mon, Dec 28, 2009 at 3:03 AM, MRAB <python at mrabarnett.plus.com> wrote:
> Martin v. L?wis wrote:
>>>
>>> No application developer will quickly figure out what a tilde means.
>>> Maybe
>>> it means 'roughly', but it requires too much thought and is ambiguous.
>>> 2.5
>>> is not roughly 2.5.2. It is the same exactly.
>>>
>>> Before we had : Requires-Python: 2.5, 2.6
>>>
>>> That made much more sense. It was simple and unambiguous, and is relevant
>>> to typical packaging scenarios.
>>
>> Unfortunately, it is fairly ambiguous, and makes no sense. It means
>> "requires Python 2.5 *AND* requires Python 2.6", which is a requirement
>> that no single version can meet.
>>
> Does that mean we should add "or"?
>
> ? ?Requires-Python: 2.5 or 2.6
>
> Should we also use "and" instead of ","?
>
> ? ?Requires-Python: >= 2.5 and < 2.6

This was discussed aready in Ditsutils-SIG : *and* is enough to
express everything, so for the sake of simplicity,
the comma means *and* all the time, as Mentioned in
http://www.python.org/dev/peps/pep-0345/#version-specifiers


Regards
Tarek

From martin at v.loewis.de  Mon Dec 28 10:15:40 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 28 Dec 2009 10:15:40 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <2525.115.128.29.13.1261973224.squirrel@syd-srv02.ezyreg.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B325C50.6040902@v.loewis.de>
	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>
	<75d5dd69b850e9bd793b43618327e655@preisshare.net>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B38038D.8050307@v.loewis.de>
	<2525.115.128.29.13.1261973224.squirrel@syd-srv02.ezyreg.com>
Message-ID: <4B38773C.9040309@v.loewis.de>

david.lyon at preisshare.net wrote:
>>> No application developer will quickly figure out what a tilde means.
>>> Maybe
>>> it means 'roughly', but it requires too much thought and is ambiguous.
>>> 2.5
>>> is not roughly 2.5.2. It is the same exactly.
>>>
>>> Before we had : Requires-Python: 2.5, 2.6
>>>
>>> That made much more sense. It was simple and unambiguous, and is
>>> relevant
>>> to typical packaging scenarios.
>> Unfortunately, it is fairly ambiguous, and makes no sense. It means
>> "requires Python 2.5 *AND* requires Python 2.6", which is a requirement
>> that no single version can meet.
> 
> No, it means a library requires either python 2.5 *OR* python 2.6 to be
> installed properly.

Well, the PEP says that the comma means "and", see

http://www.python.org/dev/peps/pep-0345/#version-specifiers

If the comma would mean "or", then what would ">1.0, !=1.3.4, <2.0"
mean?

above 1.0 OR unequal to 1.3.4 OR below 2.0

That would mean that *any* version would match that spec, and
then the spec would be meaningless. If that's not clear, ask
whether 4.0 would match: yes, it would, because it's >1.0. What
about 0.9: yes, it's <2.0.

Regards,
Martin


From stephen at xemacs.org  Mon Dec 28 10:34:23 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 28 Dec 2009 18:34:23 +0900
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <1261983766.3346.3.camel@localhost>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>
	<loom.20091228T014312-369@post.gmane.org>
	<94bdd2610912271702k662621ecve996eb7f9ff181fd@mail.gmail.com>
	<2883.115.128.29.13.1261975301.squirrel@syd-srv02.ezyreg.com>
	<87aax3por4.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1261983766.3346.3.camel@localhost>
Message-ID: <878wcnphls.fsf@uwakimon.sk.tsukuba.ac.jp>

Antoine Pitrou writes:
 > 
 > > And in fact this case is often more the important one.  Packages that
 > > depend on having a *recent* version of python will often crash
 > > quickly, before doing permanent damage, when an undefined syntax,
 > > function, or method is invoked, while packages that depend on a quirk
 > > in behavior of an older version will typically silently corrupt data.
 > 
 > How can they know that they depend on "a quirk in behaviour of an older
 > version" if a newer version hasn't been released? This sounds bogus.

Of course a newer version has been released.  Who said it hasn't been?
Eg, the discussion of <=2.5.  Hasn't 2.6 been released?  Or am I
hallucinating?

The point is that some packages depend on >=2.5, and others depend on
<=2.5.  I see no reason to deprecate the "<=" notation.

From ziade.tarek at gmail.com  Mon Dec 28 10:25:13 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 28 Dec 2009 10:25:13 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>

On Mon, Dec 28, 2009 at 4:17 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Ben Finney writes:
>
> ?> Instead, the default should be `=='. That is, `Requires-Python: 3'
> ?> should be equivalent to `Requires-Python: ==3'; and only "3" or "3.0" or
> ?> "3.0.0" etc. will match. I maintain that is what most people will expect
> ?> on seeing that syntax.
>
> I really don't think your assessment that a majority agrees with you
> is warranted. ?The demand for backward compatibility is so strong that
> (wearing my maintainer hat, in other projects) I actually assume that
> in compatibility claims a bare version number like 3 means >= 3.0.0 to
> my listeners, unless explicitly qualified.
>
> Therefore, I think there should be no default. ?"Explicit is better
> than implicit."

I am with Stephen here: If I read "Requires-Python: 3" outloud, it's
equivalent to,
"my project uses Python 3", and in python-dev, like anywhere else, it includes
all versions of Python 3, unless a specific, explicit version is provided.


>
> And IMO the choice of "~=" or "=~" for the range match should be
> avoided, since that looks like the regexp search operator in Perl, and
> there "~= 3" would match "3", "3.0.4", and "2.3.5". ?The next obvious
> interpretation is "fuzzy match", but that doesn't have an obvious,
> more specific meaning. ?The usual comparson operators do have pretty
> obvious interpretations, and are not hard to use.

I think Antoine's proposal is good (using the range when "2.5" is
used, and using 2.5.0 when explicitely
needed), and fixes Martin's concerns.

So I would be in favor of removing ~= and using Antoine's rule;

Regards
Tarek

From ben+python at benfinney.id.au  Mon Dec 28 10:23:04 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Mon, 28 Dec 2009 20:23:04 +1100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<hh9f6c$lh0$2@ger.gmane.org>
	<94bdd2610912280105s9dac69w7719effe795ecf8f@mail.gmail.com>
Message-ID: <877hs75u6f.fsf@benfinney.id.au>

Tarek Ziad? <ziade.tarek at gmail.com> writes:

> What happened is that Martin came late in the discussions in
> Distutils-SIG after I've forwarded the final mail in Catalog-SIG and
> after I did send it here (the mail where I said "Here's the mail I'll
> send to python-dev for PEP 345, if anyone sees a problem or something
> to add")

I was under the impression that previous art was being followed in the
area of specifying dependencies. That previous art being the many
existing dependency systems, which use obvious comparison operators (the
?>? ?>=? ?<? ?<=?) and no range operators or implicit ranges.

> So, if no one object, I propose to continue this thread about the way
> range should be compared, to see if we meet a consensus quite soon. If
> not, I guess we can go back to distutils-SIG and invite people over
> there, as we did for other topics.

Please, keep the operators simple and obvious, drawing on the existing
conventions in other systems, so there's no need to have bike-shedding
discussions over new syntax.

-- 
 \         ?Science is a way of trying not to fool yourself. The first |
  `\     principle is that you must not fool yourself, and you are the |
_o__)               easiest person to fool.? ?Richard P. Feynman, 1964 |
Ben Finney


From martin at v.loewis.de  Mon Dec 28 10:31:58 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 28 Dec 2009 10:31:58 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <4B3811DC.8040500@mrabarnett.plus.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<4B325C50.6040902@v.loewis.de>	<94bdd2610912231107p6fbfe13ei7ef2e77a00dc14fe@mail.gmail.com>	<75d5dd69b850e9bd793b43618327e655@preisshare.net>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<4B38038D.8050307@v.loewis.de>
	<4B3811DC.8040500@mrabarnett.plus.com>
Message-ID: <4B387B0E.7080607@v.loewis.de>


> Does that mean we should add "or"?
> 
>     Requires-Python: 2.5 or 2.6

It would be redundant to have it, since you can also write

Requires-Python: >=2.5, <2.7

> Should we also use "and" instead of ","?
> 
>     Requires-Python: >= 2.5 and < 2.6

Perhaps. I think the Linux packaging formats uniformly use the comma.

Regards,
Martin

From martin at v.loewis.de  Mon Dec 28 10:37:03 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 28 Dec 2009 10:37:03 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <3BE235C6-A1EB-4668-A107-40914F4ACF4D@gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>
	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>	<loom.20091228T014312-369@post.gmane.org>	<94bdd2610912271702k662621ecve996eb7f9ff181fd@mail.gmail.com>
	<3BE235C6-A1EB-4668-A107-40914F4ACF4D@gmail.com>
Message-ID: <4B387C3F.3050609@v.loewis.de>

> It seems to me that all this version range talk relates pretty
> directly to PEP 386.
> 
> The Python version numbers themselves are the simplest type of
> "Normalized Version"s, and since comparisons of "NormalizedVersion"s
> are defined in PEP 386, and that's really all we're talking about
> here, shouldn't this really just follow and reference that document?

That's for the ordering operators (<, <=, >, >=).

Tarek absolutely wants a shortcut way of specifying a range, and
such a mechanism is not discusses in PEP 386 (other than the
conventional >=min,<max, which is not shortcut enough).

> Sure we might like some sugar to make expressing ranges simpler, but
> shouldn't the explicit meanings of any rules be stated in terms of
> Normalized Version comparisons?

That turns out to be tricky. I agree that the PEP doesn't currently
specify it properly (at least, it now says something that Tarek
said he didn't want). However, try coming up with wording that
says "~=A means >=A and < 'words to describe the proper upper bound'".

Regards,
Martin

From ziade.tarek at gmail.com  Mon Dec 28 10:39:37 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 28 Dec 2009 10:39:37 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <877hs75u6f.fsf@benfinney.id.au>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<hh9f6c$lh0$2@ger.gmane.org>
	<94bdd2610912280105s9dac69w7719effe795ecf8f@mail.gmail.com>
	<877hs75u6f.fsf@benfinney.id.au>
Message-ID: <94bdd2610912280139r5c654510icbd883b84a426c98@mail.gmail.com>

On Mon, Dec 28, 2009 at 10:23 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
[..]
>> So, if no one object, I propose to continue this thread about the way
>> range should be compared, to see if we meet a consensus quite soon. If
>> not, I guess we can go back to distutils-SIG and invite people over
>> there, as we did for other topics.
>
> Please, keep the operators simple and obvious, drawing on the existing
> conventions in other systems, so there's no need to have bike-shedding
> discussions over new syntax.

I don't think the operators themselves are the real issue. We've added
the ~= operator to address the range isue, but it seems now
over-complex for what we really need:

The real issue I believe, is to clarify what "2.5" means in the
context of defining dependencies and equivalent fields in PEP 345.

"2.5" means either "2.5.x", either "2.5.0". And it seems to me that in
the common usage, it means "2.5.x".
If we agree on this, then Antoine's proposal seems like the natural solution.

Regards,
Tarek

-- 
Tarek Ziad? | http://ziade.org

From martin at v.loewis.de  Mon Dec 28 10:42:20 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 28 Dec 2009 10:42:20 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python	Software
 Packages 1.2
In-Reply-To: <87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>
	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<4B37FEB9.1010205@activestate.com>	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4B387D7C.7090105@v.loewis.de>

> And IMO the choice of "~=" or "=~" for the range match should be
> avoided, since that looks like the regexp search operator in Perl, and
> there "~= 3" would match "3", "3.0.4", and "2.3.5".  The next obvious
> interpretation is "fuzzy match", but that doesn't have an obvious,
> more specific meaning.  The usual comparson operators do have pretty
> obvious interpretations, and are not hard to use.

On distutils-sig, a vocal fraction seems to think otherwise. From my
short interaction there, I now think that comparison operators are
indeed hard to use, and that the concept of a half-open interval,
and how you can use relational operators involving the endpoints
to denote it, is (apparently) *quite* advanced. More specifically,
people fail to notice that saying "X.Y or X.Y+1" still specifies
an interval. Being confronted with ">=X.Y, <X.Y+2", they quickly
agree that it's equivalent.

Regards,
Martin

From martin at v.loewis.de  Mon Dec 28 10:49:06 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 28 Dec 2009 10:49:06 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <hh9f6c$lh0$2@ger.gmane.org>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<4B37FEB9.1010205@activestate.com>	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<hh9f6c$lh0$2@ger.gmane.org>
Message-ID: <4B387F12.2010203@v.loewis.de>

> Point of order:  what is the point of sending the discussion off to the
> distutils SIG if we are just going to bikeshed it (again!) here.

Bike-shedding it here is indeed inappropriate. If the PEP had listed all
possible arguments that can come up in this discussion, and the
corresponding counter arguments, then the discussion should be over.

Alas, it seems that the PEP still has open issues, which may mean that
distutils-sig didn't finish its work, or that the more general public
has different concerns.

Wrt. the ~= operator that is now under discussion: I proposed it on
distutils-sig, Tarek (eventually) agree, nobody else commented. Now
python-dev people neither like the syntax, nor the semantics. Saying
that distutils-sig has discussed that aspect would be incorrect,
though.

Regards,
Martin

From martin at v.loewis.de  Mon Dec 28 10:54:16 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 28 Dec 2009 10:54:16 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>
	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<4B37FEB9.1010205@activestate.com>	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>	<87fx6v6gnx.fsf@benfinney.id.au>	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>
Message-ID: <4B388048.5090208@v.loewis.de>

> I think Antoine's proposal is good (using the range when "2.5" is
> used, and using 2.5.0 when explicitely
> needed), and fixes Martin's concerns.
> 
> So I would be in favor of removing ~= and using Antoine's rule;

So specifying 2.5 would be a short-hand for *what*?

Regards,
Martin

From ziade.tarek at gmail.com  Mon Dec 28 11:10:20 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 28 Dec 2009 11:10:20 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <4B388048.5090208@v.loewis.de>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>
	<4B388048.5090208@v.loewis.de>
Message-ID: <94bdd2610912280210y638b4fffi1970af59b2d1bacf@mail.gmail.com>

2009/12/28 "Martin v. L?wis" <martin at v.loewis.de>:
>> I think Antoine's proposal is good (using the range when "2.5" is
>> used, and using 2.5.0 when explicitely
>> needed), and fixes Martin's concerns.
>>
>> So I would be in favor of removing ~= and using Antoine's rule;
>
> So specifying 2.5 would be a short-hand for *what*?

2.5 would be a shorthand for 2.5.x. So, equivalent to : >=2.5.0, < 2.6.0

2.5.0 would be the notation required to describe this specific micro version.

For third-party projects, the same rule would apply.

The only particular point is about projects that don't use the .0
micro notation for the first version of a series.
In that case, "2.5" will still mean ">=2.5, < 2.6.0"

IOW, if someone needs a full MAJOR.MINOR.MICRO comparison, he will
have to explicitely
tell if by providing a detailed version, even if he needs to fill it
with some ".0"s

This will of course be applicable only for PEP 386-compatible
versions. So for "Requires-Externals", the
range might not apply (as I stated in the PEP)

Some examples:

Requires-Dist: zope.interface (3.1)      ==> any versions that starts
with 3.1, not including post- or pre- releases
Requires-Dist: zope.interface (3.1.0)   ==> only 3.1.0
Requires-Python: 3                              ==> Python 3 (no
matter wich one)
Requires-Python: >=2.6,<3                  ==> Any version of Python
2.6.x or 2.7.x (and 2.8.x if it exists one day)
Requires-Python: 2.6.2                         ==> only Python 2.6.2



Regards
Tarek

From regebro at gmail.com  Mon Dec 28 11:21:05 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 28 Dec 2009 11:21:05 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>
Message-ID: <319e029f0912280221w3d288177oe69bc7a872376a9a@mail.gmail.com>

Another penny dropped when it comes to version specs.

Should 2.5 mean 2.5.0 only, or 2.5.*. Well... why would you ever need
to specify 2.5.0 only. That's a nonsense specification.

"My project requires Python 2.5.0, but doesn't work with 2.5.1". Huh!?
Well, then fix it, goofball. :)

2.5 can mean 2.5.* without any problems. And 3 should mean 3.*.*.


New suggested spec:

versionrequirements ::= 'Requires-Python: ' specificationlist
specificationlist   ::= specification (; specification)*
specification       ::= version | "[" [version] ":" [version] "]"
version             ::= lc_number ["." lc_number [ "." lc_number ] ]

With examples being:

    Requires-Python: [2.5.2:3]; [3.1:]

Or on several rows:

    Requires-Python: [2.5.2:3];
                    [3.1.2];
                    [3.2:]


Meaning 2.5.2 or later, but not Python 3. *or*
Python 3.1.2. *or*
Python 3.2 or later.

Or if slicing syntax is not wanted:

versionrequirements ::= 'Requires-Python: ' specificationlist
specificationlist   ::= specification (; specification)*
specification       ::= version | minimum | maximum | miniumum " " maximum
minimum             ::= ('>' | '>=') version
maximum             ::= ('<' | '<=') version
version             ::= lc_number ["." lc_number [ "." lc_number ] ]

That would mean something like the following:

    Requires-Python: >= 2.5.2 < 3; >= 3.1

or more clearer if it's split up in lines:

    Requires-Python: >= 2.5.2 < 3;
                    >= 3.1

The following would be illegal:

    Requires-Python: >= 2.5.2 > 3
    Requires-Python: <= 2.5.2 < 3
    Requires-Python: <= 2.5.2 < 3 > 3.1

From david.lyon at preisshare.net  Mon Dec 28 11:27:27 2009
From: david.lyon at preisshare.net (david.lyon at preisshare.net)
Date: Mon, 28 Dec 2009 21:27:27 +1100 (EST)
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <319e029f0912280221w3d288177oe69bc7a872376a9a@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>
	<319e029f0912280221w3d288177oe69bc7a872376a9a@mail.gmail.com>
Message-ID: <3009.115.128.5.50.1261996047.squirrel@syd-srv02.ezyreg.com>


Hi Len,

> Another penny dropped when it comes to version specs.

Pennies are good. They build value.

> With examples being:
>
>     Requires-Python: [2.5.2:3]; [3.1:]

What about going even more simple...

Requires-Python: 2.5..3 3.1..

If we use double-dots to replace colons, the ..
will translate to 'to'.

So taking your example more closely might be:

Requires-Python: [2.5]..[2.7]; [3.1]..

David







From ziade.tarek at gmail.com  Mon Dec 28 11:40:08 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 28 Dec 2009 11:40:08 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <319e029f0912280221w3d288177oe69bc7a872376a9a@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>
	<319e029f0912280221w3d288177oe69bc7a872376a9a@mail.gmail.com>
Message-ID: <94bdd2610912280240x498fde8dib989ce8c17e29293@mail.gmail.com>

On Mon, Dec 28, 2009 at 11:21 AM, Lennart Regebro <regebro at gmail.com> wrote:
> Another penny dropped when it comes to version specs.
>
> Should 2.5 mean 2.5.0 only, or 2.5.*. Well... why would you ever need
> to specify 2.5.0 only. That's a nonsense specification.
>
> "My project requires Python 2.5.0, but doesn't work with 2.5.1". Huh!?
> Well, then fix it, goofball. :)
>
> 2.5 can mean 2.5.* without any problems. And 3 should mean 3.*.*.

I am not sure why you are proposing a new syntax, if you agree that
2.5 should mean 2.5.*

The syntax we have specified in the PEP already works with your
examples, and is way less complex that your proposals I think.


Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From martin at v.loewis.de  Mon Dec 28 11:42:50 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 28 Dec 2009 11:42:50 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <94bdd2610912280210y638b4fffi1970af59b2d1bacf@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	
	<4B346ACE.2030400@gmail.com>	
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	
	<4B37FEB9.1010205@activestate.com>	
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>	
	<87fx6v6gnx.fsf@benfinney.id.au>	
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>	
	<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>	
	<4B388048.5090208@v.loewis.de>
	<94bdd2610912280210y638b4fffi1970af59b2d1bacf@mail.gmail.com>
Message-ID: <4B388BAA.50500@v.loewis.de>

>> So specifying 2.5 would be a short-hand for *what*?
> 
> 2.5 would be a shorthand for 2.5.x. So, equivalent to : >=2.5.0, < 2.6.0

Ok, so it's not a shorthand for a single operator anymore, but for a
more complex term. Fine with me.

> 2.5.0 would be the notation required to describe this specific micro version.

I think it would be a shorthand for >=2.5.0, <2.5.1, right?

Or are you saying that specifying a version is sometimes a shorthand for
a range, and sometimes a shorthand for the == operator (i.e. one exact
version)?

> Requires-Dist: zope.interface (3.1)      ==> any versions that starts
> with 3.1, not including post- or pre- releases
> Requires-Dist: zope.interface (3.1.0)   ==> only 3.1.0

No, it should be: any version that starts with 3.1.0, not including
post- or pre-releases

> Requires-Python: 3                              ==> Python 3 (no
> matter wich one)

Almost: excluding pre- and post-releases.

> Requires-Python: >=2.6,<3                  ==> Any version of Python
> 2.6.x or 2.7.x (and 2.8.x if it exists one day)

This time, including pre- and post-releases, right?

> Requires-Python: 2.6.2                         ==> only Python 2.6.2

No: >=2.6.2, <2.6.3 (of course, the only Python release in that range
was 2.6.2, since there was no 2.6.2.1).

Regards,
Martin


From martin at v.loewis.de  Mon Dec 28 11:54:50 2009
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Mon, 28 Dec 2009 11:54:50 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <319e029f0912280221w3d288177oe69bc7a872376a9a@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<4B334109.2060708@v.loewis.de>
	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<4B37FEB9.1010205@activestate.com>	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>	<87fx6v6gnx.fsf@benfinney.id.au>	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>	<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>
	<319e029f0912280221w3d288177oe69bc7a872376a9a@mail.gmail.com>
Message-ID: <4B388E7A.40108@v.loewis.de>

> Another penny dropped when it comes to version specs.
> 
> Should 2.5 mean 2.5.0 only, or 2.5.*. Well... why would you ever need
> to specify 2.5.0 only. That's a nonsense specification.
> 
> "My project requires Python 2.5.0, but doesn't work with 2.5.1". Huh!?
> Well, then fix it, goofball. :)

This == operator is fairly common in Debian. For example, the apache2
package installed on my system specifies

Package: apache2
Version: 2.2.14-4
Depends: apache2-mpm-worker (= 2.2.14-4) | apache2-mpm-prefork (=
2.2.14-4) | apache2-mpm-event (= 2.2.14-4) | apache2-mpm-itk (=
2.2.14-4), apache2.2-common (= 2.2.14-4)

So they specify that the packages they need have *exactly* to come
from the same build. Otherwise, slight binary incompatibilities
may break the thing - and there is no point in risking that.

For Python, applications should probably be more tolerant wrt.
versioning. However, some people do want to lock dependencies
to a specific version, for better reproducability.

> The following would be illegal:
> 
>     Requires-Python: >= 2.5.2 > 3
>     Requires-Python: <= 2.5.2 < 3
>     Requires-Python: <= 2.5.2 < 3 > 3.1

-1. I would prefer if there is only a single syntax for specifying
version dependencies, independent of what metadata field they
appear in.

Regards,
Martin

From regebro at gmail.com  Mon Dec 28 11:57:57 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 28 Dec 2009 11:57:57 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <3009.115.128.5.50.1261996047.squirrel@syd-srv02.ezyreg.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>
	<319e029f0912280221w3d288177oe69bc7a872376a9a@mail.gmail.com>
	<3009.115.128.5.50.1261996047.squirrel@syd-srv02.ezyreg.com>
Message-ID: <319e029f0912280257y3c440a75o5f01aa6687fca05b@mail.gmail.com>

On Mon, Dec 28, 2009 at 11:27,  <david.lyon at preisshare.net> wrote:
> What about going even more simple...
>
> Requires-Python: 2.5..3 3.1..

Doh! Of course. Works for me. In fact, the dots could be dashes as well.

Requires-Python: 2.5-3 3.1-

Commas, spaces, semicolons, whatever. We could allow:

Requires-Python: 2.5-3 3.1-
Requires-Python: 2.5-3,3.1-
Requires-Python: 2.5-3;3.1-
Requires-Python: 2.5..3, 3.1..

To be equivalent.

That syntax covers all reasonable usecases, as far as I can see, and is clear.

Requires-Python: 2.5.2-3 ,3.1.2, 3.2-

2.5.2 and up to, but not including, 3.0.0.
*or*
3.1.2
*or*
3.2.0 or later.

-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python-incompatibility.googlecode.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Mon Dec 28 11:58:00 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 28 Dec 2009 11:58:00 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <4B388BAA.50500@v.loewis.de>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>
	<4B388048.5090208@v.loewis.de>
	<94bdd2610912280210y638b4fffi1970af59b2d1bacf@mail.gmail.com>
	<4B388BAA.50500@v.loewis.de>
Message-ID: <94bdd2610912280258i1265c85bj36a0f7783785dd1a@mail.gmail.com>

2009/12/28 "Martin v. L?wis" <martin at v.loewis.de>:
[..]
>> 2.5.0 would be the notation required to describe this specific micro version.
>
> I think it would be a shorthand for >=2.5.0, <2.5.1, right?
>
> Or are you saying that specifying a version is sometimes a shorthand for
> a range, and sometimes a shorthand for the == operator (i.e. one exact
> version)?

2.5.0 being a shorthand for >=2.5.0, <2.5.1 is fine with me.


[..]
>> Requires-Dist: zope.interface (3.1.0) ? ==> only 3.1.0
>
> No, it should be: any version that starts with 3.1.0, not including
> post- or pre-releases

In practice it means the same if we don't consider going further that
the micro version (as I did in my head when providing the examples),
but in theory you are right, so that's fine with me.


>> Requires-Python: 3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?==> Python 3 (no matter wich one)
>
> Almost: excluding pre- and post-releases.

Indeed.

>
>> Requires-Python: >=2.6,<3 ? ? ? ? ? ? ? ? ?==> Any version of Python 2.6.x or 2.7.x (and 2.8.x if it exists one day)
>
> This time, including pre- and post-releases, right?

Which pre- and post-releases exactly in this case ? if you mean 2.6
post- releases, 2.7 and 2.8 pre- and post- releases : yes, they would
be included in that range. 3 post-releases are excluded in that case.

As a side not: as we said earlier in Distutils-SIG, dealing with
specific pre- and -post releases would be a very particular
case ppl would have to deal with manually if they are to be founded at
the edge of a range.

e.g. "<3" doesn't mean Python 3 pre-releases are included.


>> Requires-Python: 2.6.2 ? ? ? ? ? ? ? ? ? ? ? ? ==> only Python 2.6.2
>
> No: >=2.6.2, <2.6.3 (of course, the only Python release in that range
> was 2.6.2, since there was no 2.6.2.1).

Sure.  If we agree on all of this, I'll add all these examples in the
PEP to make it crystal-clear.


Regards
Tarek

From regebro at gmail.com  Mon Dec 28 12:02:05 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 28 Dec 2009 12:02:05 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <4B388E7A.40108@v.loewis.de>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>
	<319e029f0912280221w3d288177oe69bc7a872376a9a@mail.gmail.com>
	<4B388E7A.40108@v.loewis.de>
Message-ID: <319e029f0912280302yf41e6d4r5f2db0fc2b3339bd@mail.gmail.com>

On Mon, Dec 28, 2009 at 11:54, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> This == operator is fairly common in Debian. For example, the apache2
> package installed on my system specifies

Oh, absolutely, but that's when you specify interdependencies between
packages. Nobody makes a Python package for generic use and say "you
should only use this with Python 2.5.0 and nothing else". Specifying
zope.interfaces 1.2.3 for zope.component 1.2.3 makes a lot of sense,
but specifying only Python 2.5.0?


> -1. I would prefer if there is only a single syntax for specifying
> version dependencies, independent of what metadata field they
> appear in.

That is admittedly a good argument.
-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python-incompatibility.googlecode.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Mon Dec 28 12:02:15 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 28 Dec 2009 12:02:15 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <319e029f0912280257y3c440a75o5f01aa6687fca05b@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>
	<319e029f0912280221w3d288177oe69bc7a872376a9a@mail.gmail.com>
	<3009.115.128.5.50.1261996047.squirrel@syd-srv02.ezyreg.com>
	<319e029f0912280257y3c440a75o5f01aa6687fca05b@mail.gmail.com>
Message-ID: <94bdd2610912280302j22e2666bt9b791df5f3fea32@mail.gmail.com>

On Mon, Dec 28, 2009 at 11:57 AM, Lennart Regebro <regebro at gmail.com> wrote:
> On Mon, Dec 28, 2009 at 11:27, ?<david.lyon at preisshare.net> wrote:
>> What about going even more simple...
>>
>> Requires-Python: 2.5..3 3.1..
>
> Doh! Of course. Works for me. In fact, the dots could be dashes as well.
>
> Requires-Python: 2.5-3 3.1-
>
> Commas, spaces, semicolons, whatever. We could allow:
>
> Requires-Python: 2.5-3 3.1-
> Requires-Python: 2.5-3,3.1-
> Requires-Python: 2.5-3;3.1-
> Requires-Python: 2.5..3, 3.1..

-1. This looks like typos the developer made on his versions definitions.
And if not, is subject to errors by forgetting dashes or dots.

Regards,
Tarek

-- 
Tarek Ziad? | http://ziade.org

From scott+python-dev at scottdial.com  Mon Dec 28 12:02:50 2009
From: scott+python-dev at scottdial.com (Scott Dial)
Date: Mon, 28 Dec 2009 06:02:50 -0500
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <4B388BAA.50500@v.loewis.de>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>		<4B346ACE.2030400@gmail.com>		<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>		<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>		<4B37FEB9.1010205@activestate.com>		<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>		<87fx6v6gnx.fsf@benfinney.id.au>		<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>		<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>		<4B388048.5090208@v.loewis.de>	<94bdd2610912280210y638b4fffi1970af59b2d1bacf@mail.gmail.com>
	<4B388BAA.50500@v.loewis.de>
Message-ID: <4B38905A.8030603@scottdial.com>

On 12/28/2009 5:42 AM, Martin v. L?wis wrote:
>>> So specifying 2.5 would be a short-hand for *what*?
>>
>> 2.5 would be a shorthand for 2.5.x. So, equivalent to : >=2.5.0, < 2.6.0
> 
> Ok, so it's not a shorthand for a single operator anymore, but for a
> more complex term. Fine with me.
> 
>> 2.5.0 would be the notation required to describe this specific micro version.
> 
> I think it would be a shorthand for >=2.5.0, <2.5.1, right?

Actually, the logical extension is that 2.5.0 is shorthand for
>=2.5.0.0, <2.5.1.0, I believe.

PEP 386 versions can have an indefinite number of extradecimal versions.

Pedantically,
-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu

From regebro at gmail.com  Mon Dec 28 12:04:03 2009
From: regebro at gmail.com (Lennart Regebro)
Date: Mon, 28 Dec 2009 12:04:03 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <94bdd2610912280302j22e2666bt9b791df5f3fea32@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>
	<319e029f0912280221w3d288177oe69bc7a872376a9a@mail.gmail.com>
	<3009.115.128.5.50.1261996047.squirrel@syd-srv02.ezyreg.com>
	<319e029f0912280257y3c440a75o5f01aa6687fca05b@mail.gmail.com>
	<94bdd2610912280302j22e2666bt9b791df5f3fea32@mail.gmail.com>
Message-ID: <319e029f0912280304r5023b849r7238939dc9812af0@mail.gmail.com>

On Mon, Dec 28, 2009 at 12:02, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
> -1. This looks like typos the developer made on his versions definitions.

Nah.

> And if not, is subject to errors by forgetting dashes or dots.

Eh, yeah but that goes for ANY syntax.

Having the same syntax as for package specifications does make sense, though.
(So we should clearly change that one too, eh?)

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64

From ziade.tarek at gmail.com  Mon Dec 28 12:08:10 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 28 Dec 2009 12:08:10 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <319e029f0912280304r5023b849r7238939dc9812af0@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>
	<319e029f0912280221w3d288177oe69bc7a872376a9a@mail.gmail.com>
	<3009.115.128.5.50.1261996047.squirrel@syd-srv02.ezyreg.com>
	<319e029f0912280257y3c440a75o5f01aa6687fca05b@mail.gmail.com>
	<94bdd2610912280302j22e2666bt9b791df5f3fea32@mail.gmail.com>
	<319e029f0912280304r5023b849r7238939dc9812af0@mail.gmail.com>
Message-ID: <94bdd2610912280308w5f7d5bc2l2c66790916198d18@mail.gmail.com>

On Mon, Dec 28, 2009 at 12:04 PM, Lennart Regebro <regebro at gmail.com> wrote:
> On Mon, Dec 28, 2009 at 12:02, Tarek Ziad? <ziade.tarek at gmail.com> wrote:
>> -1. This looks like typos the developer made on his versions definitions.
>
> Nah.
>
>> And if not, is subject to errors by forgetting dashes or dots.
>
> Eh, yeah but that goes for ANY syntax.
>
> Having the same syntax as for package specifications does make sense, though.
> (So we should clearly change that one too, eh?)

I don't think we need to change the syntax in fact. The current one,
with simple operators covers the needs as far as I see.

What was fuzzy is the meaning of version strings like "2.5".

Once it's clarified (and it seems we have a better definition already
since a few mails), I think the current syntax works naturally with
ranges.

Regards
Tarek

-- 
Tarek Ziad? | http://ziade.org

From ziade.tarek at gmail.com  Mon Dec 28 12:18:59 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Mon, 28 Dec 2009 12:18:59 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <319e029f0912280302yf41e6d4r5f2db0fc2b3339bd@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>
	<319e029f0912280221w3d288177oe69bc7a872376a9a@mail.gmail.com>
	<4B388E7A.40108@v.loewis.de>
	<319e029f0912280302yf41e6d4r5f2db0fc2b3339bd@mail.gmail.com>
Message-ID: <94bdd2610912280318m4047fa4ake11c5c215001de00@mail.gmail.com>

On Mon, Dec 28, 2009 at 12:02 PM, Lennart Regebro <regebro at gmail.com> wrote:
> On Mon, Dec 28, 2009 at 11:54, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> This == operator is fairly common in Debian. For example, the apache2
>> package installed on my system specifies
>
> Oh, absolutely, but that's when you specify interdependencies between
> packages. Nobody makes a Python package for generic use and say "you
> should only use this with Python 2.5.0 and nothing else".
> Specifying
> zope.interfaces 1.2.3 for zope.component 1.2.3 makes a lot of sense,
> but specifying only Python 2.5.0?

It's quite improbable but it could technically happen. For example,
let's say I create a third-party project that provides a specific
workaround for a bug that was founded in Python 2.5.0 but fixed in
Python 2.5.1.

IOW defining how versions work should be a set of explicit rules that
shouldn't rely on assumptions made on their usage in some specific
projects, but rather provides something that covers all needs.

Regards,
Tarek

From ben+python at benfinney.id.au  Mon Dec 28 12:45:20 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Mon, 28 Dec 2009 22:45:20 +1100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>
	<319e029f0912280221w3d288177oe69bc7a872376a9a@mail.gmail.com>
	<4B388E7A.40108@v.loewis.de>
	<319e029f0912280302yf41e6d4r5f2db0fc2b3339bd@mail.gmail.com>
Message-ID: <873a2v5nlb.fsf@benfinney.id.au>

Lennart Regebro <regebro at gmail.com> writes:

> On Mon, Dec 28, 2009 at 11:54, "Martin v. L?wis" <martin at v.loewis.de> wrote:
> > This == operator is fairly common in Debian. For example, the
> > apache2 package installed on my system specifies
>
> Oh, absolutely, but that's when you specify interdependencies between
> packages. Nobody makes a Python package for generic use and say "you
> should only use this with Python 2.5.0 and nothing else". Specifying
> zope.interfaces 1.2.3 for zope.component 1.2.3 makes a lot of sense,
> but specifying only Python 2.5.0?

I'm operating from the principle that there should not be a special
syntax that only applies to dependency on the version of Python.

The same syntax used for specifying any dependency on any package should
also be sufficient for specifying a dependency on Python itself. That
being so, the cost in complexity of having a special dependency syntax
just for the version of Python should weigh strongly against introducing
one.

-- 
 \       ?First things first, but not necessarily in that order.? ?The |
  `\                                              Doctor, _Doctor Who_ |
_o__)                                                                  |
Ben Finney


From solipsis at pitrou.net  Mon Dec 28 16:37:05 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 28 Dec 2009 16:37:05 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <878wcnphls.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>
	<loom.20091228T014312-369@post.gmane.org>
	<94bdd2610912271702k662621ecve996eb7f9ff181fd@mail.gmail.com>
	<2883.115.128.29.13.1261975301.squirrel@syd-srv02.ezyreg.com>
	<87aax3por4.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1261983766.3346.3.camel@localhost>
	<878wcnphls.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <1262014626.3366.1.camel@localhost>


>  > How can they know that they depend on "a quirk in behaviour of an older
>  > version" if a newer version hasn't been released? This sounds bogus.
> 
> Of course a newer version has been released.  Who said it hasn't been?
> Eg, the discussion of <=2.5.  Hasn't 2.6 been released?  Or am I
> hallucinating?

So, what you are saying is that software X specifies that it is
compatible with "2.5 or later" as long as 2.6 hasn't been released, but
when 2.6 is released it switches to "2.5 but not 2.6"?

> The point is that some packages depend on >=2.5, and others depend on
> <=2.5.  I see no reason to deprecate the "<=" notation.

That's not really what we are talking IIUC. We are talking about
behaviour of "2.5" vs. "2.5.0".



From stephen at xemacs.org  Mon Dec 28 18:16:22 2009
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 29 Dec 2009 02:16:22 +0900
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <1262014626.3366.1.camel@localhost>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<94bdd2610912271637m7b3df609m780622f74ee5daa@mail.gmail.com>
	<loom.20091228T014312-369@post.gmane.org>
	<94bdd2610912271702k662621ecve996eb7f9ff181fd@mail.gmail.com>
	<2883.115.128.29.13.1261975301.squirrel@syd-srv02.ezyreg.com>
	<87aax3por4.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1261983766.3346.3.camel@localhost>
	<878wcnphls.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1262014626.3366.1.camel@localhost>
Message-ID: <87637row7t.fsf@uwakimon.sk.tsukuba.ac.jp>

Antoine Pitrou writes:
 > 
 > >  > How can they know that they depend on "a quirk in behaviour of an older
 > >  > version" if a newer version hasn't been released? This sounds bogus.
 > > 
 > > Of course a newer version has been released.  Who said it hasn't been?
 > > Eg, the discussion of <=2.5.  Hasn't 2.6 been released?  Or am I
 > > hallucinating?
 > 
 > So, what you are saying is that software X specifies that it is
 > compatible with "2.5 or later" as long as 2.6 hasn't been released, but
 > when 2.6 is released it switches to "2.5 but not 2.6"?

No, I'm not.

Let's drop it, as Tarek seems disposed to dismiss the bikeshedding
(including this subthread) anyway, which is TheRightThing.


From p.f.moore at gmail.com  Mon Dec 28 19:08:50 2009
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 28 Dec 2009 18:08:50 +0000
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <4B387B0E.7080607@v.loewis.de>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B38038D.8050307@v.loewis.de> <4B3811DC.8040500@mrabarnett.plus.com>
	<4B387B0E.7080607@v.loewis.de>
Message-ID: <79990c6b0912281008t26f5ee1ew57429f617d949853@mail.gmail.com>

2009/12/28 "Martin v. L?wis" <martin at v.loewis.de>:
>
>> Does that mean we should add "or"?
>>
>> ? ? Requires-Python: 2.5 or 2.6
>
> It would be redundant to have it, since you can also write
>
> Requires-Python: >=2.5, <2.7
>
>> Should we also use "and" instead of ","?
>>
>> ? ? Requires-Python: >= 2.5 and < 2.6
>
> Perhaps. I think the Linux packaging formats uniformly use the comma.

(I'm picking a somewhat random message to reply to here - in general,
I agree with the sentiments expressed in Martin's mail).

It seems to me that there's too much of an attempt to invent "do what
I mean" semantics, which is complicating the whole issue here. Python
prefers "explicit is better than implicit" over the Perl "do what I
mean". I don't see why that should be any less the case here.

It seems to me that everything people might want to express can be
covered with the existing operators, plus comma meaning "and". Maybe
some people find "2.5, 2.6" more obvious than ">= 2.5, < 2.7" - but
satisfying them at the cost of introducing complexity and ambiguity
into the syntax seems to me to be a serious mistake.

Paul.

From tseaver at palladion.com  Mon Dec 28 21:26:41 2009
From: tseaver at palladion.com (Tres Seaver)
Date: Mon, 28 Dec 2009 15:26:41 -0500
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <94bdd2610912280210y638b4fffi1970af59b2d1bacf@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<4B37FEB9.1010205@activestate.com>	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>	<87fx6v6gnx.fsf@benfinney.id.au>	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>	<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>	<4B388048.5090208@v.loewis.de>
	<94bdd2610912280210y638b4fffi1970af59b2d1bacf@mail.gmail.com>
Message-ID: <hhb4a1$212$1@ger.gmane.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tarek Ziad? wrote:
> 2009/12/28 "Martin v. L?wis" <martin at v.loewis.de>:
>>> I think Antoine's proposal is good (using the range when "2.5" is
>>> used, and using 2.5.0 when explicitely
>>> needed), and fixes Martin's concerns.
>>>
>>> So I would be in favor of removing ~= and using Antoine's rule;
>> So specifying 2.5 would be a short-hand for *what*?
> 
> 2.5 would be a shorthand for 2.5.x. So, equivalent to : >=2.5.0, < 2.6.0
> 
> 2.5.0 would be the notation required to describe this specific micro version.
> 
> For third-party projects, the same rule would apply.
> 
> The only particular point is about projects that don't use the .0
> micro notation for the first version of a series.
> In that case, "2.5" will still mean ">=2.5, < 2.6.0"
> 
> IOW, if someone needs a full MAJOR.MINOR.MICRO comparison, he will
> have to explicitely
> tell if by providing a detailed version, even if he needs to fill it
> with some ".0"s
> 
> This will of course be applicable only for PEP 386-compatible
> versions. So for "Requires-Externals", the
> range might not apply (as I stated in the PEP)
> 
> Some examples:
> 
> Requires-Dist: zope.interface (3.1)      ==> any versions that starts
> with 3.1, not including post- or pre- releases
> Requires-Dist: zope.interface (3.1.0)   ==> only 3.1.0

For completeness, isn't this really "any versino which starts with
3.1.0, not including post- or pre- releases"?  That particular pacakge
doesn't use more than a third version component, but there are packages
in the wild which use four.

> Requires-Python: 3                              ==> Python 3 (no
> matter wich one)
> Requires-Python: >=2.6,<3                  ==> Any version of Python
> 2.6.x or 2.7.x (and 2.8.x if it exists one day)
> Requires-Python: 2.6.2                         ==> only Python 2.6.2

Here, the issue is only theoretical:  Python dosn't issue "fourth dot"
releases.



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAks5FHwACgkQ+gerLs4ltQ7LcQCfQPav5l4/lrVrNVUHZuMw6hX/
Rk0An0lBGQ26OOXhO8238EuD/7rGxHUo
=Zd6y
-----END PGP SIGNATURE-----


From david.lyon at preisshare.net  Mon Dec 28 23:57:57 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 28 Dec 2009 17:57:57 -0500
Subject: [Python-Dev]
 =?utf-8?q?Proposing_PEP_345_=3A_Metadata_for_Python?=
 =?utf-8?q?=09Software_Packages_1=2E2?=
In-Reply-To: <4B387D7C.7090105@v.loewis.de>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>
	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<4B37FEB9.1010205@activestate.com>	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4B387D7C.7090105@v.loewis.de>
Message-ID: <a0a0b9f6f637249b1e3cf3db7eec0860@preisshare.net>

On Mon, 28 Dec 2009 10:42:20 +0100, "Martin v. L?wis" <martin at v.loewis.de>
wrote:
> On distutils-sig, a vocal fraction seems to think otherwise. From my
> short interaction there, I now think that comparison operators are
> indeed hard to use, and that the concept of a half-open interval,
> and how you can use relational operators involving the endpoints
> to denote it, is (apparently) *quite* advanced. 

Absolutely. 

>From Len and my interactions, I will wrap up and make one addition
to the set. I'm adding one last proposition.

  > Requires-Python: 3

Requires a particular python version.

  > Requires-Python: 2.5:2.7

Specifies a range of python versions.

  > Requires-Python: 2.4+

Specifies anything above a particular python version.

(No need to ask me about a less than operator. I think
 a packager would feel more comfortable with using the
 range operator than a 'less-than' operator. There just
 comes a point where people don't bother with old 
 interpreter versions)

That wraps it up for the vocal faction...

Happy new year

David


From fuzzyman at voidspace.org.uk  Tue Dec 29 00:07:32 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 28 Dec 2009 23:07:32 +0000
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <a0a0b9f6f637249b1e3cf3db7eec0860@preisshare.net>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<4B37FEB9.1010205@activestate.com>	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>	<87fx6v6gnx.fsf@benfinney.id.au>	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>	<4B387D7C.7090105@v.loewis.de>
	<a0a0b9f6f637249b1e3cf3db7eec0860@preisshare.net>
Message-ID: <4B393A34.4040301@voidspace.org.uk>

On 28/12/2009 22:57, David Lyon wrote:
> On Mon, 28 Dec 2009 10:42:20 +0100, "Martin v. L?wis"<martin at v.loewis.de>
> wrote:
>    
>> On distutils-sig, a vocal fraction seems to think otherwise. From my
>> short interaction there, I now think that comparison operators are
>> indeed hard to use, and that the concept of a half-open interval,
>> and how you can use relational operators involving the endpoints
>> to denote it, is (apparently) *quite* advanced.
>>      
> Absolutely.
>
> > From Len and my interactions, I will wrap up and make one addition
> to the set. I'm adding one last proposition.
>
>    >  Requires-Python: 3
>
> Requires a particular python version.
>
>    >  Requires-Python: 2.5:2.7
>
> Specifies a range of python versions.
>    
So this would work for Python 2.7 but *not* 2.7.1? Or does 2.7 
implicitly mean a range of all Python 2.7 versions?

If not how do we specify up to the last version of 2.6 (which may not 
yet be released) but *not* 2.7?

     2.5:2.6.9 ?

Michael


>    >  Requires-Python: 2.4+
>
> Specifies anything above a particular python version.
>
> (No need to ask me about a less than operator. I think
>   a packager would feel more comfortable with using the
>   range operator than a 'less-than' operator. There just
>   comes a point where people don't bother with old
>   interpreter versions)
>
> That wraps it up for the vocal faction...
>
> Happy new year
>
> David
>
> _______________________________________________
> 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.ironpythoninaction.com/
http://www.voidspace.org.uk/blog



From david.lyon at preisshare.net  Tue Dec 29 00:09:54 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 28 Dec 2009 18:09:54 -0500
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <4B393A34.4040301@voidspace.org.uk>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<4B37FEB9.1010205@activestate.com>	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>	<87fx6v6gnx.fsf@benfinney.id.au>	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>	<4B387D7C.7090105@v.loewis.de>
	<a0a0b9f6f637249b1e3cf3db7eec0860@preisshare.net>
	<4B393A34.4040301@voidspace.org.uk>
Message-ID: <a8274a039b69ba93adcf30b3519473cd@preisshare.net>

On Mon, 28 Dec 2009 23:07:32 +0000, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
>>    >  Requires-Python: 2.5:2.7
>>
>> Specifies a range of python versions.
>>    
> So this would work for Python 2.7 but *not* 2.7.1? Or does 2.7 
> implicitly mean a range of all Python 2.7 versions?

Yes. 2.7 would mean all 2.7 versions. As 2.7.1 is a 2.7 release.

> If not how do we specify up to the last version of 2.6 (which may not 
> yet be released) but *not* 2.7?
>
>      2.5:2.6.9 ?

No. As you might never know what the last release may ever be as
they keep on coming.

So like this:

  >  Requires-Python: 2.5:2.6

That will catch all 2.6 unreleased versions (security fixes et la)
and not 2.7

David


From solipsis at pitrou.net  Tue Dec 29 00:21:54 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 28 Dec 2009 23:21:54 +0000 (UTC)
Subject: [Python-Dev]
	=?utf-8?q?Proposing_PEP_345_=3A_Metadata_for_Python?=
	=?utf-8?q?=09Software_Packages_1=2E2?=
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>
	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<4B37FEB9.1010205@activestate.com>	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4B387D7C.7090105@v.loewis.de>
	<a0a0b9f6f637249b1e3cf3db7eec0860@preisshare.net>
Message-ID: <loom.20091229T001929-372@post.gmane.org>

David Lyon <david.lyon <at> preisshare.net> writes:
> 
> Requires a particular python version.
> 
>   > Requires-Python: 2.5:2.7

Why not drop ranges as well as operators and simply use commas?
The above would be rewritten as:

Requires-Python: 2.5, 2.6, 2.7

This would prevent the ambiguity on the inclusive or exclusive nature of the
upper bound of the range.

You might argue that if you want to include 8 versions of Python this makes the
notation slightly longer, but who tests their package with 8 different versions
of Python?
(and if you don't test exhaustively, just use the "2.5+" notation)

Regards

Antoine.



From python at mrabarnett.plus.com  Tue Dec 29 00:48:20 2009
From: python at mrabarnett.plus.com (MRAB)
Date: Mon, 28 Dec 2009 23:48:20 +0000
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <loom.20091229T001929-372@post.gmane.org>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<4B37FEB9.1010205@activestate.com>	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>	<87fx6v6gnx.fsf@benfinney.id.au>	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>	<4B387D7C.7090105@v.loewis.de>	<a0a0b9f6f637249b1e3cf3db7eec0860@preisshare.net>
	<loom.20091229T001929-372@post.gmane.org>
Message-ID: <4B3943C4.2090003@mrabarnett.plus.com>

Antoine Pitrou wrote:
> David Lyon <david.lyon <at> preisshare.net> writes:
>> Requires a particular python version.
>>
>>   > Requires-Python: 2.5:2.7
> 
> Why not drop ranges as well as operators and simply use commas?
> The above would be rewritten as:
> 
> Requires-Python: 2.5, 2.6, 2.7
> 
> This would prevent the ambiguity on the inclusive or exclusive nature of the
> upper bound of the range.
> 
That would mean that commas mean "and" for some entries but "or" for
others.

> You might argue that if you want to include 8 versions of Python this makes the
> notation slightly longer, but who tests their package with 8 different versions
> of Python?
> (and if you don't test exhaustively, just use the "2.5+" notation)
> 
Wouldn't "2.5+" include "3"? How often would that be used, considering
the differences between Python 2.x and Python 3.x?

From rdmurray at bitdance.com  Tue Dec 29 00:55:17 2009
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 28 Dec 2009 18:55:17 -0500
Subject: [Python-Dev]
	=?utf-8?q?Proposing_PEP_345_=3A_Metadata_for_Python?=
	=?utf-8?q?=09Software_Packages_1=2E2?=
In-Reply-To: <loom.20091229T001929-372@post.gmane.org>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4B387D7C.7090105@v.loewis.de>
	<a0a0b9f6f637249b1e3cf3db7eec0860@preisshare.net>
	<loom.20091229T001929-372@post.gmane.org>
Message-ID: <20091228235517.1C6C51FB73E@kimball.webabinitio.net>

On Mon, 28 Dec 2009 23:21:54 +0000, Antoine Pitrou <solipsis at pitrou.net> wrote:
> David Lyon <david.lyon <at> preisshare.net> writes:
> > 
> > Requires a particular python version.
> > 
> >   > Requires-Python: 2.5:2.7
> 
> Why not drop ranges as well as operators and simply use commas?
> The above would be rewritten as:
> 
> Requires-Python: 2.5, 2.6, 2.7
> 
> This would prevent the ambiguity on the inclusive or exclusive nature of the
> upper bound of the range.

What about specifying that the package works only with, say, 2.6.2 or
earlier (because of some problem introduced by 2.6.3)?  That could get
pretty darn verbose.  (Also remember we aren't just talking about the
syntax for Python versions, but versions for any package).

I do think it is also a valid argument that, from what I've heard here,
most extant (linux at least) packaging systems use the >=, etc, operators,
so I think talking about changing the proposed syntax radically is
probably misplaced.

--
R. David Murray                                      www.bitdance.com
Business Process Automation - Network/Server Management - Routers/Firewalls

From solipsis at pitrou.net  Tue Dec 29 01:05:05 2009
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 29 Dec 2009 00:05:05 +0000 (UTC)
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4B387D7C.7090105@v.loewis.de>
	<a0a0b9f6f637249b1e3cf3db7eec0860@preisshare.net>
	<loom.20091229T001929-372@post.gmane.org>
	<4B3943C4.2090003@mrabarnett.plus.com>
Message-ID: <hhbh3h$4mq$1@ger.gmane.org>


R. David Murray <rdmurray <at> bitdance.com> writes:
> 
> > Why not drop ranges as well as operators and simply use commas?
> > The above would be rewritten as:
> > 
> > Requires-Python: 2.5, 2.6, 2.7
> > 
> > This would prevent the ambiguity on the inclusive or exclusive nature 
of the
> > upper bound of the range.
> 
> What about specifying that the package works only with, say, 2.6.2 or
> earlier (because of some problem introduced by 2.6.3)?  That could get
> pretty darn verbose.  (Also remember we aren't just talking about the
> syntax for Python versions, but versions for any package).

Ok, you're right. Let's drop my proposal then.

Regards

Antoine.



From david.lyon at preisshare.net  Tue Dec 29 01:17:37 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 28 Dec 2009 19:17:37 -0500
Subject: [Python-Dev]
 =?utf-8?q?Proposing_PEP_345_=3A_Metadata_for_Python?=
 =?utf-8?q?=09Software_Packages_1=2E2?=
In-Reply-To: <loom.20091229T001929-372@post.gmane.org>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>
	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<4B37FEB9.1010205@activestate.com>	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4B387D7C.7090105@v.loewis.de>
	<a0a0b9f6f637249b1e3cf3db7eec0860@preisshare.net>
	<loom.20091229T001929-372@post.gmane.org>
Message-ID: <4c5f058f7af37a281c587896f6136cdb@preisshare.net>

On Mon, 28 Dec 2009 23:21:54 +0000 (UTC), Antoine Pitrou
<solipsis at pitrou.net> wrote:

>>   > Requires-Python: 2.5:2.7
> 
> Why not drop ranges as well as operators and simply use commas?
> The above would be rewritten as:
> 
> Requires-Python: 2.5, 2.6, 2.7

Firstly, I find your notation proposition to be entirely workable
and rational.

Len threw in the range notation as a kind of novel idea, but the
more I use it, the more that I think it is applicable in this
use case. Packages and the interpretor version is about ranges.

The choice (for the packager) comes down to either one particular
python version (2, 2.x, or 3, or 3.x), or a range of python
versions, or a set.

There's no reason that I can see why we could not have both,
that is a set and a range as Len has suggested.

Whether the delineation is with commas or spaces is, to me,
is minor. 

> You might argue that if you want to include 8 versions 
> of Python this makes the notation slightly longer, but 
> who tests their package with 8 different versions
> of Python?

You're right. The set notation is more obtuse.

But with your notation, I hope there would be no problem. For instance:

> Requires-Python: 2, 3

To me that would cover all 8 versions.

As for the testing thing, well that's the cpan debate.. another thread.

> (and if you don't test exhaustively, just use the "2.5+" notation)

Exactly.

David


From david.lyon at preisshare.net  Tue Dec 29 01:35:23 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 28 Dec 2009 19:35:23 -0500
Subject: [Python-Dev]
 =?utf-8?q?Proposing_PEP_345_=3A_Metadata_for_Python?=
 =?utf-8?q?=09Software_Packages_1=2E2?=
In-Reply-To: <20091228235517.1C6C51FB73E@kimball.webabinitio.net>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4B387D7C.7090105@v.loewis.de>
	<a0a0b9f6f637249b1e3cf3db7eec0860@preisshare.net>
	<loom.20091229T001929-372@post.gmane.org>
	<20091228235517.1C6C51FB73E@kimball.webabinitio.net>
Message-ID: <485962b382c592d08bf2a021dfd824f0@preisshare.net>

On Mon, 28 Dec 2009 18:55:17 -0500, "R. David Murray"
<rdmurray at bitdance.com> wrote:
> What about specifying that the package works only with, say, 2.6.2 or
> earlier (because of some problem introduced by 2.6.3)?  That could get
> pretty darn verbose.  (Also remember we aren't just talking about the
> syntax for Python versions, but versions for any package).

That's why the range operator could be good.

  > Requires-python: 2.4:2.6.2

> I do think it is also a valid argument that, from what I've heard here,
> most extant (linux at least) packaging systems use the >=, etc,
operators,
> so I think talking about changing the proposed syntax radically is
> probably misplaced.

The counter argument for 'cloning' the linux packaging system is
that most of the representations come from a C perspective. Because
of the fact that Linux is predominantly a C product.

Since Python isn't C, and doesn't come from C, then one could
argue that using short-hand or high level notation is more
in keeping with the character of python. 

So the arguments against the >= == operators come from the desire
to keep what looks like C code, *out-of* python packaging.

I fully sympathise that some have the desire simply to clone
what's already out there. Why make new art when there's a
lot of old art already..

The price of doing that is we lose the specific short-handed
high-level nature of python. Which is what we were attracted
to in the first place.

David







From ben+python at benfinney.id.au  Tue Dec 29 02:00:50 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 29 Dec 2009 12:00:50 +1100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python	Software
	Packages 1.2
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4B387D7C.7090105@v.loewis.de>
	<a0a0b9f6f637249b1e3cf3db7eec0860@preisshare.net>
	<loom.20091229T001929-372@post.gmane.org>
	<20091228235517.1C6C51FB73E@kimball.webabinitio.net>
	<485962b382c592d08bf2a021dfd824f0@preisshare.net>
Message-ID: <87my124mrh.fsf@benfinney.id.au>

David Lyon <david.lyon at preisshare.net> writes:

> The counter argument for 'cloning' the linux packaging system is that
> most of the representations come from a C perspective. Because of the
> fact that Linux is predominantly a C product.
>
> Since Python isn't C, and doesn't come from C, then one could argue
> that using short-hand or high level notation is more in keeping with
> the character of python.

Even if that were true (and it's not at all clear that ?Python does not
come from C?), that's a classic ?not invented here? (NIH) argument. NIH
is widely regarded as a very poor reason to reject something that works.

The dependency declarations are *not* Python language syntax, and there
is no need to consider Python language syntax in defining them.

-- 
 \          ?When we talk to God, we're praying. When God talks to us, |
  `\         we're schizophrenic.? ?Jane Wagner, via Lily Tomlin, 1985 |
_o__)                                                                  |
Ben Finney


From ziade.tarek at gmail.com  Tue Dec 29 02:12:23 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 29 Dec 2009 02:12:23 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <hhb4a1$212$1@ger.gmane.org>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<94bdd2610912280125w12835743y9a5a1c31c7825e44@mail.gmail.com>
	<4B388048.5090208@v.loewis.de>
	<94bdd2610912280210y638b4fffi1970af59b2d1bacf@mail.gmail.com>
	<hhb4a1$212$1@ger.gmane.org>
Message-ID: <94bdd2610912281712m758267aawbe0ac3c1112995f4@mail.gmail.com>

On Mon, Dec 28, 2009 at 9:26 PM, Tres Seaver <tseaver at palladion.com> wrote:
[..]
>> Requires-Dist: zope.interface (3.1.0) ? ==> only 3.1.0
>
> For completeness, isn't this really "any versino which starts with
> 3.1.0, not including post- or pre- releases"? ?That particular pacakge
> doesn't use more than a third version component, but there are packages
> in the wild which use four.

[..]
>> Requires-Python: 2.6.2 ? ? ? ? ? ? ? ? ? ? ? ? ==> only Python 2.6.2
>
> Here, the issue is only theoretical: ?Python dosn't issue "fourth dot"
> releases.

Both points are right. I'll remove from the PEP the range operator and provide
a definition for 2.5 vs 2.5.x vs 2.5.0, as well as all these examples,
corrected.

From ssteinerx at gmail.com  Tue Dec 29 02:17:52 2009
From: ssteinerx at gmail.com (ssteinerX@gmail.com)
Date: Mon, 28 Dec 2009 20:17:52 -0500
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python	Software
	Packages 1.2
In-Reply-To: <87my124mrh.fsf@benfinney.id.au>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4B387D7C.7090105@v.loewis.de>
	<a0a0b9f6f637249b1e3cf3db7eec0860@preisshare.net>
	<loom.20091229T001929-372@post.gmane.org>
	<20091228235517.1C6C51FB73E@kimball.webabinitio.net>
	<485962b382c592d08bf2a021dfd824f0@preisshare.net>
	<87my124mrh.fsf@benfinney.id.au>
Message-ID: <34C9794F-920E-46D4-A45E-7D2360E16899@gmail.com>


On Dec 28, 2009, at 8:00 PM, Ben Finney wrote:

> The dependency declarations are *not* Python language syntax, and there
> is no need to consider Python language syntax in defining them.

Agreed.  

We're also not going to be writing an operating system with them; just simple version range statement.

I think that the range expression:

	2.5:2.7

is easy to read, immediately understandable, and expresses everything that needs to be said.

Yes, it needs to be stated that the ends are inclusive, but after that, it's pretty obvious what it means at a glance

Steve



From larry at hastings.org  Tue Dec 29 02:26:15 2009
From: larry at hastings.org (Larry Hastings)
Date: Mon, 28 Dec 2009 17:26:15 -0800
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
 Packages 1.2
In-Reply-To: <a8274a039b69ba93adcf30b3519473cd@preisshare.net>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>	<4B3333DF.40705@v.loewis.de>	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>	<4B334109.2060708@v.loewis.de>	<4B346ACE.2030400@gmail.com>	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>	<4B37FEB9.1010205@activestate.com>	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>	<87fx6v6gnx.fsf@benfinney.id.au>	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>	<4B387D7C.7090105@v.loewis.de>	<a0a0b9f6f637249b1e3cf3db7eec0860@preisshare.net>	<4B393A34.4040301@voidspace.org.uk>
	<a8274a039b69ba93adcf30b3519473cd@preisshare.net>
Message-ID: <4B395AB7.9050700@hastings.org>

David Lyon wrote:
> On Mon, 28 Dec 2009 23:07:32 +0000, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
>   
>>>    >  Requires-Python: 2.5:2.7
>>>
>>> Specifies a range of python versions.   
>>>       
>> So this would work for Python 2.7 but *not* 2.7.1? Or does 2.7 
>> implicitly mean a range of all Python 2.7 versions?
>>     
>
> Yes. 2.7 would mean all 2.7 versions. As 2.7.1 is a 2.7 release. 

I suggest that this follow the Python syntax for ranges, where the end 
is non-inclusive.  So "2.5:2.7" would mean "greater than or equal to 
2.5, and less than 2.7".  Which suggests that "2.5:" could be equivalent 
to "2.5+", as well as allowing ":3" to mean "any version less than 3.0".

Cheers,


/larry/

From ziade.tarek at gmail.com  Tue Dec 29 02:35:05 2009
From: ziade.tarek at gmail.com (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 29 Dec 2009 02:35:05 +0100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <34C9794F-920E-46D4-A45E-7D2360E16899@gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4B387D7C.7090105@v.loewis.de>
	<a0a0b9f6f637249b1e3cf3db7eec0860@preisshare.net>
	<loom.20091229T001929-372@post.gmane.org>
	<20091228235517.1C6C51FB73E@kimball.webabinitio.net>
	<485962b382c592d08bf2a021dfd824f0@preisshare.net>
	<87my124mrh.fsf@benfinney.id.au>
	<34C9794F-920E-46D4-A45E-7D2360E16899@gmail.com>
Message-ID: <94bdd2610912281735x3a89a6efu5460d3de00427906@mail.gmail.com>

On Tue, Dec 29, 2009 at 2:17 AM, ssteinerX at gmail.com
<ssteinerx at gmail.com> wrote:
>
> On Dec 28, 2009, at 8:00 PM, Ben Finney wrote:
>
>> The dependency declarations are *not* Python language syntax, and there
>> is no need to consider Python language syntax in defining them.
>
> Agreed.
>
> We're also not going to be writing an operating system with them; just simple version range statement.
>
> I think that the range expression:
>
> ? ? ? ?2.5:2.7
>
> is easy to read, immediately understandable, and expresses everything that needs to be said.
>
> Yes, it needs to be stated that the ends are inclusive, but after that, it's pretty obvious what it means at a glance

The syntax as it is already defined in the PEP can be used to define
what we need. The part that was unclear was about the meaning of
"2.5". e.g.: 2.5.0 or 2.5.x..

It became obvious in the thread that it means 2.5.x. (e.g. a range) so
there's no need to introduce any range operator, wether it's "~=" or a
new notation with ":".

IOW, since the syntax already present in the PEP is sufficient for our
needs (besides ~=) , and as long as the precise definition of "version
string" is provided,  I consider that further discussion about the
syntax itself is more or less bikeshedding.

I am now rewriting the relevant section of the PEP with the examples
we discussed in this thread, but the operators should stay the same as
they were initially: "<", ">", "<=", ">=", "==" and "!=".

Regards
Tarek

From ssteinerx at gmail.com  Tue Dec 29 02:45:46 2009
From: ssteinerx at gmail.com (ssteinerX@gmail.com)
Date: Mon, 28 Dec 2009 20:45:46 -0500
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
In-Reply-To: <94bdd2610912281735x3a89a6efu5460d3de00427906@mail.gmail.com>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4B387D7C.7090105@v.loewis.de>
	<a0a0b9f6f637249b1e3cf3db7eec0860@preisshare.net>
	<loom.20091229T001929-372@post.gmane.org>
	<20091228235517.1C6C51FB73E@kimball.webabinitio.net>
	<485962b382c592d08bf2a021dfd824f0@preisshare.net>
	<87my124mrh.fsf@benfinney.id.au>
	<34C9794F-920E-46D4-A45E-7D2360E16899@gmail.com>
	<94bdd2610912281735x3a89a6efu5460d3de00427906@mail.gmail.com>
Message-ID: <E788E362-7B79-4D7A-8F22-B699DAD79A25@gmail.com>


On Dec 28, 2009, at 8:35 PM, Tarek Ziad? wrote:

> On Tue, Dec 29, 2009 at 2:17 AM, ssteinerX at gmail.com
> <ssteinerx at gmail.com> wrote:
>> 
>> On Dec 28, 2009, at 8:00 PM, Ben Finney wrote:
>> 
>>> The dependency declarations are *not* Python language syntax, and there
>>> is no need to consider Python language syntax in defining them.
>> 
>> Agreed.
>> 
>> We're also not going to be writing an operating system with them; just simple version range statement.
>> 
>> I think that the range expression:
>> 
>>        2.5:2.7
>> 
>> is easy to read, immediately understandable, and expresses everything that needs to be said.
>> 
>> Yes, it needs to be stated that the ends are inclusive, but after that, it's pretty obvious what it means at a glance
> 
> The syntax as it is already defined in the PEP can be used to define
> what we need. The part that was unclear was about the meaning of
> "2.5". e.g.: 2.5.0 or 2.5.x..
> 
> It became obvious in the thread that it means 2.5.x. (e.g. a range) so
> there's no need to introduce any range operator, wether it's "~=" or a
> new notation with ":".
> 
> IOW, since the syntax already present in the PEP is sufficient for our
> needs (besides ~=) , and as long as the precise definition of "version
> string" is provided,  I consider that further discussion about the
> syntax itself is more or less bikeshedding.
> 
> I am now rewriting the relevant section of the PEP with the examples
> we discussed in this thread, but the operators should stay the same as
> they were initially: "<", ">", "<=", ">=", "==" and "!=".

Fine by me.  

My original contention was that we should be referencing that document as it already defined everything we needed and that any syntactic sugar be defined in those terms.

The ":" syntactic sugar appeals to me but is, as you say, not necessary.

S


From ben+python at benfinney.id.au  Tue Dec 29 03:07:36 2009
From: ben+python at benfinney.id.au (Ben Finney)
Date: Tue, 29 Dec 2009 13:07:36 +1100
Subject: [Python-Dev] Proposing PEP 345 : Metadata for Python Software
	Packages 1.2
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4B387D7C.7090105@v.loewis.de>
	<a0a0b9f6f637249b1e3cf3db7eec0860@preisshare.net>
	<loom.20091229T001929-372@post.gmane.org>
	<20091228235517.1C6C51FB73E@kimball.webabinitio.net>
	<485962b382c592d08bf2a021dfd824f0@preisshare.net>
	<87my124mrh.fsf@benfinney.id.au>
	<34C9794F-920E-46D4-A45E-7D2360E16899@gmail.com>
	<94bdd2610912281735x3a89a6efu5460d3de00427906@mail.gmail.com>
Message-ID: <87eime4jo7.fsf@benfinney.id.au>

Tarek Ziad? <ziade.tarek at gmail.com> writes:

> I am now rewriting the relevant section of the PEP with the examples
> we discussed in this thread, but the operators should stay the same as
> they were initially: "<", ">", "<=", ">=", "==" and "!=".

Thank you, this is the clear and simple path and keeps the dependency
declarations in line with existing conventions.

-- 
 \           ?Let others praise ancient times; I am glad I was born in |
  `\                                      these.? ?Ovid (43 BCE?18 CE) |
_o__)                                                                  |
Ben Finney


From david.lyon at preisshare.net  Tue Dec 29 03:52:03 2009
From: david.lyon at preisshare.net (David Lyon)
Date: Mon, 28 Dec 2009 21:52:03 -0500
Subject: [Python-Dev]
 =?utf-8?q?Proposing_PEP_345_=3A_Metadata_for_Python?=
 =?utf-8?q?=09Software_Packages_1=2E2?=
In-Reply-To: <87my124mrh.fsf@benfinney.id.au>
References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com>
	<871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp>
	<e626d66af534e03f22749f3dd4a6ff73@preisshare.net>
	<4B3333DF.40705@v.loewis.de>
	<94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com>
	<4B334109.2060708@v.loewis.de> <4B346ACE.2030400@gmail.com>
	<94bdd2610912271601h69b081adsc871c849d1e2e1cc@mail.gmail.com>
	<4203.115.128.50.49.1261959349.squirrel@syd-srv02.ezyreg.com>
	<4B37FEB9.1010205@activestate.com>
	<94bdd2610912271652n325bd3ecl9e3ea6beeb4b8725@mail.gmail.com>
	<87fx6v6gnx.fsf@benfinney.id.au>
	<87eimfpz18.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4B387D7C.7090105@v.loewis.de>
	<a0a0b9f6f637249b1e3cf3db7eec0860@preisshare.net>
	<loom.20091229T001929-372@post.gmane.org>
	<20091228235517.1C6C51FB73E@kimball.webabinitio.net>
	<485962b382c592d08bf2a021dfd824f0@preisshare.net>
	<87my124mrh.fsf@benfinney.id.au>
Message-ID: <11a6db1be4a8799e1a7a37d3573baa71@preisshare.net>

On Tue, 29 Dec 2009 12:00:50 +1100, Ben Finney <ben+python at benfinney.id.au>
wrote:

> The dependency declarations are *not* Python language syntax, and there
> is no need to consider Python language syntax in defining them.

Well I don't know how you can say that if it is python developers
to which all this effort is targeted.

David


From chris at simplistix.co.uk  Tue Dec 29 15:11:14 2009
From: chris at simplistix.co.uk (Chris Withers)
Date: Tue, 29 Dec 2009 14:11:14 +0000
Subject: [Python-Dev] Proposing PEP 386 for addition
In-Reply-To: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com>
Message-ID: <4B3A0E02.7090904@simplistix.co.uk>

Tarek Ziad? wrote:
> On behalf of the Distutils-SIG, I would like to propose PEP 386 for
> inclusion in the sdtlib, and have a final discussion here on
> Python-dev.
> 
> http://www.python.org/dev/peps/pep-0386

This is excellent. Thankyou for doing this, I hope we can get it 
accepted and implemented as soon as possible :-)

Chris


From van.lindberg at gmail.com  Tue Dec 29 18:18:24 2009
From: van.lindberg at gmail.com (VanL)
Date: Tue, 29 Dec 2009 11:18:24 -0600
Subject: [Python-Dev] PyCon Early Bird is Ending Soon!
Message-ID: <hhddkp$hgv$4@ger.gmane.org>

Do you have a year-end hole in your training budget? Or will the
improved economy let you finally attend a work conference? Come to sunny
and warm Atlanta in February for PyCon 2010. Early bird registration
ends on January 6.

Register: https://us.pycon.org/2010/register/

See the talks: http://us.pycon.org/2010/conference/talks/
Get trained at a tutorial:  http://us.pycon.org/2010/tutorials/

Also see the five (or more!) talks that people can't miss at PyCon:

PyOraGeek: PyCon pre-favorites
<http://catherinedevlin.blogspot.com/2009/11/pycon-pre-favorites.html>

Pyright: PyCon pre-favorites, the Carl T. edition:
<http://pyright.blogspot.com/2009/11/pycon-2010-pre-favorites-carl-t-edition.html>

Aftermarket Pipes: Five Pycon 2010 Talks I Need to See:
<http://apipes.blogspot.com/2009/12/five-pycon-2010-talks-i-need-to-see.html>

Jessenoller.com: PyCon 2010: Talks I want to see:
<http://jessenoller.com/2009/12/06/pycon-2010-talks-i-want-to-see-keynotes-registration-open/>

The Third Bit: Five PyCon Talks I Want To See:
<http://pyre.third-bit.com/blog/archives/3364.html>

See you at PyCon!

Register: https://us.pycon.org/2010/register/


From benjamin at python.org  Wed Dec 30 21:04:31 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Wed, 30 Dec 2009 14:04:31 -0600
Subject: [Python-Dev] Question over splitting unittest into a package
In-Reply-To: <d80792120912300606m545d1d32x78d8c8cffc4cc762@mail.gmail.com>
References: <d80792120912300606m545d1d32x78d8c8cffc4cc762@mail.gmail.com>
Message-ID: <1afaf6160912301204p247e77c4r2271c4f37114ba4@mail.gmail.com>

2009/12/30 Martin (gzlist) <gzlist at googlemail.com>:
> Hi Benjamin,

Hi!

>
> In rev 74094 of Python, you split the unittest module up, could you
> point me at any bug entries or discussion over this revision so I can
> catch up?

This was mostly a discussion on IRC between Michael Foord and myself.

>
> As a side-effect you seem to have changed the method of marking a
> module as not worth including in a traceback to be no longer
> extensible.
>
> Before:
> <http://svn.python.org/view/python/trunk/Lib/unittest.py?view=markup&pathrev=74094>
>
> A global was set at the top of the module:
>
> ? ?__unittest = 1
>
> Which is then checked for when constructing traceback output:
>
> ? ?def _is_relevant_tb_level(self, tb):
> ? ? ? ?return '__unittest' in tb.tb_frame.f_globals
>
> After:
> <http://svn.python.org/view/python/trunk/Lib/unittest/__init__.py?revision=74095&view=markup>
>
> ? ?def _is_relevant_tb_level(self, tb):
> ? ? ? ?globs = tb.tb_frame.f_globals
> ? ? ? ?is_relevant = ?'__name__' in globs and \
> ? ? ? ? ? ?globs["__name__"].startswith("unittest")
> ? ? ? ?del globs
> ? ? ? ?return is_relevant
>
> Only packages actually named "unittest" can be excluded.
>
> What is now the prefered method of marking a module as test-internal?
> Overriding the leading-underscore _is_relevant_tb_level method? How
> can this be done cooperatively by different packages?

When I made that change, I didn't know that the __unittest "hack" was
being used elsewhere outside of unittest, so I felt fine replacing it
with another. While I still consider it an implementation detail, I
would be ok with exposing an "official" API for this. Perhaps
__unittest_ignore_traceback?


> I would have CCed a mailinglist with this question but don't like
> getting yelled at for posting on the wrong one, please feel free to do
> so with your reply if you feel it's appropriate (the CCing, not the
> yelling).

python-dev is perfect for this discussion.


-- 
Regards,
Benjamin

From olemis at gmail.com  Wed Dec 30 21:33:43 2009
From: olemis at gmail.com (Olemis Lang)
Date: Wed, 30 Dec 2009 15:33:43 -0500
Subject: [Python-Dev] Question over splitting unittest into a package
In-Reply-To: <1afaf6160912301204p247e77c4r2271c4f37114ba4@mail.gmail.com>
References: <d80792120912300606m545d1d32x78d8c8cffc4cc762@mail.gmail.com>
	<1afaf6160912301204p247e77c4r2271c4f37114ba4@mail.gmail.com>
Message-ID: <24ea26600912301233pe13ffb6if7af37fedf21c619@mail.gmail.com>

On Wed, Dec 30, 2009 at 3:04 PM, Benjamin Peterson <benjamin at python.org> wrote:
> 2009/12/30 Martin (gzlist) <gzlist at googlemail.com>:
>> Hi Benjamin,
>
> Hi!
>
>> In rev 74094 of Python, you split the unittest module up,

+1

>> could you
>> point me at any bug entries or discussion over this revision so I can
>> catch up?
>
> This was mostly a discussion on IRC between Michael Foord and myself.
>

... and there was a previous thread about that some time ago here in python-dev
;o)

>>
>> ? ?def _is_relevant_tb_level(self, tb):
>> ? ? ? ?return '__unittest' in tb.tb_frame.f_globals
>>
>> After:
>> <http://svn.python.org/view/python/trunk/Lib/unittest/__init__.py?revision=74095&view=markup>
>>
>> ? ?def _is_relevant_tb_level(self, tb):
>> ? ? ? ?globs = tb.tb_frame.f_globals
>> ? ? ? ?is_relevant = ?'__name__' in globs and \
>> ? ? ? ? ? ?globs["__name__"].startswith("unittest")
>> ? ? ? ?del globs
>> ? ? ? ?return is_relevant
>>

Had not seen this ... Hmmm ...
-1

>> Only packages actually named "unittest" can be excluded.
>>
>> What is now the prefered method of marking a module as test-internal?
>> Overriding the leading-underscore _is_relevant_tb_level method? How
>> can this be done cooperatively by different packages?
>
> When I made that change, I didn't know that the __unittest "hack" was
> being used elsewhere outside of unittest, so I felt fine replacing it
> with another. While I still consider it an implementation detail, I
> would be ok with exposing an "official" API for this. Perhaps
> __unittest_ignore_traceback?
>

Hmmm ... One of the issues I didn't notice ...

IMO +1 for leaving it as it was before (i.e. __unittest) because :

  - the double underscore should mean (CMIIW) that it's an implementation detail
  - not few libs use that name already ;o)

+0.5 for adding `__unittest_ignore_traceback` or something shorter
(e.g. `__unittest_ignore`) too ...

+1 for documenting that ?hack?

PS: `assertRaises` context managers are great !!! BTW
;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Assessment of unittest 2.7 API : new features and opinions  -
http://feedproxy.google.com/~r/simelo-en/~3/cVOgG8NIBFY/assessment-of-unittest-27-api-new.html

From benjamin at python.org  Thu Dec 31 00:20:35 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Wed, 30 Dec 2009 17:20:35 -0600
Subject: [Python-Dev] Question over splitting unittest into a package
In-Reply-To: <24ea26600912301233pe13ffb6if7af37fedf21c619@mail.gmail.com>
References: <d80792120912300606m545d1d32x78d8c8cffc4cc762@mail.gmail.com>
	<1afaf6160912301204p247e77c4r2271c4f37114ba4@mail.gmail.com>
	<24ea26600912301233pe13ffb6if7af37fedf21c619@mail.gmail.com>
Message-ID: <1afaf6160912301520o6a81e4b1o10f931043976159d@mail.gmail.com>

2009/12/30 Olemis Lang <olemis at gmail.com>:
> Hmmm ... One of the issues I didn't notice ...
>
> IMO +1 for leaving it as it was before (i.e. __unittest) because :
>
> ?- the double underscore should mean (CMIIW) that it's an implementation detail
> ?- not few libs use that name already ;o)
>
> +0.5 for adding `__unittest_ignore_traceback` or something shorter
> (e.g. `__unittest_ignore`) too ...
>
> +1 for documenting that ?hack?

Someone should probably file a tracker request about this.


-- 
Regards,
Benjamin

From g.brandl at gmx.net  Thu Dec 31 00:39:29 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 31 Dec 2009 00:39:29 +0100
Subject: [Python-Dev] Rough 3.2 release schedule
Message-ID: <hhgobs$d5b$1@ger.gmane.org>

... is in PEP 392.  Nothing much to see, except that the final date is
December 11, 2010.

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.


From fuzzyman at voidspace.org.uk  Thu Dec 31 00:48:23 2009
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 30 Dec 2009 23:48:23 +0000
Subject: [Python-Dev] Rough 3.2 release schedule
In-Reply-To: <hhgobs$d5b$1@ger.gmane.org>
References: <hhgobs$d5b$1@ger.gmane.org>
Message-ID: <4B3BE6C7.8060301@voidspace.org.uk>

On 30/12/2009 23:39, Georg Brandl wrote:
> ... is in PEP 392.  Nothing much to see, except that the final date is
> December 11, 2010.
>
> Georg
>
>    
The PEP index incorrectly lists PEP 375 as being the Python 3.2 release 
schedule PEP:

     http://python.org/dev/peps/

Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog



From benjamin at python.org  Thu Dec 31 00:53:50 2009
From: benjamin at python.org (Benjamin Peterson)
Date: Wed, 30 Dec 2009 17:53:50 -0600
Subject: [Python-Dev] Rough 3.2 release schedule
In-Reply-To: <4B3BE6C7.8060301@voidspace.org.uk>
References: <hhgobs$d5b$1@ger.gmane.org> <4B3BE6C7.8060301@voidspace.org.uk>
Message-ID: <1afaf6160912301553v674a0419gb45070627807cc1e@mail.gmail.com>

2009/12/30 Michael Foord <fuzzyman at voidspace.org.uk>:
> On 30/12/2009 23:39, Georg Brandl wrote:
>>
>> ... is in PEP 392. ?Nothing much to see, except that the final date is
>> December 11, 2010.
>>
>> Georg
>>
>>
>
> The PEP index incorrectly lists PEP 375 as being the Python 3.2 release
> schedule PEP:

Fixed.



-- 
Regards,
Benjamin

From ncoghlan at gmail.com  Thu Dec 31 02:21:50 2009
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 31 Dec 2009 11:21:50 +1000
Subject: [Python-Dev] Question over splitting unittest into a package
In-Reply-To: <24ea26600912301233pe13ffb6if7af37fedf21c619@mail.gmail.com>
References: <d80792120912300606m545d1d32x78d8c8cffc4cc762@mail.gmail.com>	<1afaf6160912301204p247e77c4r2271c4f37114ba4@mail.gmail.com>
	<24ea26600912301233pe13ffb6if7af37fedf21c619@mail.gmail.com>
Message-ID: <4B3BFCAE.2050706@gmail.com>

Olemis Lang wrote:
> PS: `assertRaises` context managers are great !!! BTW
> ;o)

The detailed comparison methods added for 2.7 are really nice too. It's
great getting error messages that tell me what I broke rather than "you
broke it!" :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

From g.brandl at gmx.net  Thu Dec 31 09:24:16 2009
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 31 Dec 2009 09:24:16 +0100
Subject: [Python-Dev] Rough 3.2 release schedule
In-Reply-To: <4B3BE6C7.8060301@voidspace.org.uk>
References: <hhgobs$d5b$1@ger.gmane.org> <4B3BE6C7.8060301@voidspace.org.uk>
Message-ID: <hhhn3s$8mn$1@ger.gmane.org>

Am 31.12.2009 00:48, schrieb Michael Foord:
> On 30/12/2009 23:39, Georg Brandl wrote:
>> ... is in PEP 392.  Nothing much to see, except that the final date is
>> December 11, 2010.
>>
>> Georg
>>
>>    
> The PEP index incorrectly lists PEP 375 as being the Python 3.2 release 
> schedule PEP:
> 
>      http://python.org/dev/peps/

Argh.  I added a check to the pep0 generator so that this mismatch is
caught and complained about when generating PEP 0.

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.


From gzlist at googlemail.com  Thu Dec 31 16:30:12 2009
From: gzlist at googlemail.com (Martin (gzlist))
Date: Thu, 31 Dec 2009 15:30:12 +0000
Subject: [Python-Dev] Question over splitting unittest into a package
In-Reply-To: <1afaf6160912301204p247e77c4r2271c4f37114ba4@mail.gmail.com>
References: <d80792120912300606m545d1d32x78d8c8cffc4cc762@mail.gmail.com>
	<1afaf6160912301204p247e77c4r2271c4f37114ba4@mail.gmail.com>
Message-ID: <d80792120912310730u1676991eu6ea7e6d78a09821f@mail.gmail.com>

Thanks for the quick response.

On 30/12/2009, Benjamin Peterson <benjamin at python.org> wrote:
>
> When I made that change, I didn't know that the __unittest "hack" was
> being used elsewhere outside of unittest, so I felt fine replacing it
> with another. While I still consider it an implementation detail, I
> would be ok with exposing an "official" API for this. Perhaps
> __unittest_ignore_traceback?

Well, bazaar has had the trick for a couple of years, and googling
around now turns up some other projects using it or thinking about it:
<http://github.com/gfxmonk/mocktest/commit/b5e94f7ee06ab627cea2c9cf90d0aeb63ee5a698>
<http://bitbucket.org/uche/amara/changeset/eeaf69f48271/>
<http://twistedmatrix.com/trac/ticket/4127>

I get the impression Robert doesn't like it much though, and seemed to
have wanted something more targeted in the past as well:
<http://bugs.python.org/issue1705520>

Reinstating the old implementation (with the same name) would mean
that existing code would keep working with Python 2.7 but maybe a
discussion could start about a new, less hacky, way of doing the same
thing. May not be worthwhile making life more complicated though,
there aren't *that* many unittest-extending projects.

Martin