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" 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" 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" 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 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: On Tue, Dec 1, 2009 at 11:24 AM, Mark Dickinson wrote: > On Tue, Dec 1, 2009 at 4:17 PM, James Y Knight 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: 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: 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: <5c6f2a5d0912010922j465ded2q7769326d87d4981b@mail.gmail.com> On Tue, Dec 1, 2009 at 4:47 PM, Alexander Belopolsky wrote: >> On Tue, Dec 1, 2009 at 4:17 PM, James Y Knight 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> <5c6f2a5d0912010922j465ded2q7769326d87d4981b@mail.gmail.com> Message-ID: <5c6f2a5d0912010925m23f8e270k180147d3fb37df47@mail.gmail.com> On Tue, Dec 1, 2009 at 5:22 PM, Mark Dickinson 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: References: Message-ID: 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 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: References: 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: 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: 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: References: 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 "", line 1, in 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: Eric Smith 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: References: <4B179EC2.9040705@trueblade.com> Message-ID: <5c6f2a5d0912030355g51dacfbfjf94e44fdd446217e@mail.gmail.com> On Thu, Dec 3, 2009 at 11:33 AM, Antoine Pitrou wrote: > Eric Smith 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> <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: <4B0FDDB3.9010605@cheimes.de> Message-ID: 2009/11/27 Christian Heimes > 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 >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 ? has no member named ?Const? > > Python/ast.c:343: error: ?union ? 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: 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: ===== [?] +
  • Content is restricted to Python packages and related information only.
    • +
  • Any content uploaded to PyPI is provided on a non-confidential basis.
    • +
  • 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.
    • +
  • 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 : > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: 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" 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: 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: 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: 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: References: Message-ID: On Fri, Dec 4, 2009 at 17:20, Antoine Pitrou 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: 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: References: Message-ID: <4B1A1E89.6040305@gmail.com> Brett Cannon wrote: > > > On Fri, Dec 4, 2009 at 17:20, Antoine Pitrou > 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 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: > 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, 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 : > 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: On Sat, Dec 5, 2009 at 10:55, Scott Dial > 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: 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 "", line 1, in 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: 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 "", line 1, in > 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: 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: <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: 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: Kristj?n Valur J?nsson 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: 2009/12/8 Maciej Fijalkowski > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <930F189C8A437347B80DF2C156F7EC7F09906751C4@exchis.ccp.ad.local> <4B1E5A06.5020802@avl.com> <930F189C8A437347B80DF2C156F7EC7F0990675263@exchis.ccp.ad.local> <693bc9ab0912080658g24903721s5692132cdaca065@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 > 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: 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: References: <930F189C8A437347B80DF2C156F7EC7F09906751C4@exchis.ccp.ad.local> 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 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: 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: References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com> 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: In article <94bdd2610912080916s2dbb79d0ub8a77295bba9266e at mail.gmail.com>, Tarek Ziad? 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> <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: References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com> Message-ID: <94bdd2610912081513tdc5471m5d883e77e1a92163@mail.gmail.com> On Tue, Dec 8, 2009 at 8:45 PM, 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." > > "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: 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: 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 .post345 marker. +before a .post456 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> <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> <930F189C8A437347B80DF2C156F7EC7F09906752B7@exchis.ccp.ad.local> Message-ID: Kristj?n Valur J?nsson 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 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: 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 : > 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: 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 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. "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 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 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 wrote: > On Wed, Dec 9, 2009 at 11:29 AM, Benjamin Peterson 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 wrote: > On Wed, Dec 9, 2009 at 11:34 AM, Michael Foord > 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 {{{ 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 wrote: > On Wed, Dec 9, 2009 at 17:43, Fred Drake wrote: >> On Wed, Dec 9, 2009 at 11:29 AM, Benjamin Peterson 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: On Wed, Dec 9, 2009 at 11:23 AM, Lennart Regebro 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: 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: References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com> <1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com> <9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com> <319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com> Message-ID: <319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com> On Wed, Dec 9, 2009 at 18:45, Ian Bicking 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 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 >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 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 >> 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 wrote: > You remember which one? Sorry, that was several months back. -Fred -- Fred L. Drake, Jr. "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: 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: References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com> <1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com> <9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com> <319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com> Message-ID: <24ea26600912091040y75f7f60cnee2bd0a8509b26b3@mail.gmail.com> On Wed, Dec 9, 2009 at 12:45 PM, Ian Bicking wrote: > On Wed, Dec 9, 2009 at 11:23 AM, Lennart Regebro 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() ? ... else : ... throw_an_exception() # +python>=2.7 ... ? }}} 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> <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> <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> <319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com> Message-ID: <79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com> 2009/12/9 Lennart Regebro : > On Wed, Dec 9, 2009 at 18:45, Ian Bicking 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> <319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com> <79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com> Message-ID: On Wed, Dec 9, 2009 at 5:47 PM, Paul Moore wrote: > 2009/12/9 Lennart Regebro : >> On Wed, Dec 9, 2009 at 18:45, Ian Bicking 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: Floris Bruynooghe 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> <319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com> <79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com> Message-ID: <319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com> On Thu, Dec 10, 2009 at 00:47, Paul Moore 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 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: References: <772583.98842.qm@web55501.mail.re4.yahoo.com> <20091209122136.GA19650@laurie.devork> Message-ID: <20091210094435.GA23831@laurie.devork> On Thu, Dec 10, 2009 at 05:41:01AM +0000, Michael Mysinger wrote: > Floris Bruynooghe 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: 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: References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com> <4B20B4D1.10502@gmail.com> Message-ID: On Thu, Dec 10, 2009 at 7:24 AM, 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: References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com> <4B20B4D1.10502@gmail.com> Message-ID: 2009/12/10 Darren Dale : > 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 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: References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com> <4B20B4D1.10502@gmail.com> Message-ID: On Thu, Dec 10, 2009 at 7:43 AM, Malthe Borch wrote: > 2009/12/10 Darren Dale : >> 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 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> <20091210094435.GA23831@laurie.devork> Message-ID: <94bdd2610912100520s6e2c6222ua890ce09cea2e79d@mail.gmail.com> On Thu, Dec 10, 2009 at 10:44 AM, Floris Bruynooghe 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: Tarek Ziad? 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: References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com> <4B20B4D1.10502@gmail.com> <94bdd2610912100519n43614c84n63c37794ec8f5d7b@mail.gmail.com> Message-ID: On Thu, Dec 10, 2009 at 8:54 AM, Antoine Pitrou wrote: > Tarek Ziad? 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> <319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com> <79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com> <319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com> Message-ID: Lennart Regebro wrote: > On Thu, Dec 10, 2009 at 00:47, Paul Moore 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 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> <319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com> <79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com> <319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com> Message-ID: <79990c6b0912101150i6e680784w40b202886678c862@mail.gmail.com> 2009/12/10 Lennart Regebro : > On Thu, Dec 10, 2009 at 00:47, Paul Moore 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: References: <319e029f0912090827r3b92a846o797ea02100263793@mail.gmail.com> <1afaf6160912090829i476f54fv39940405af6e1ad1@mail.gmail.com> <9cee7ab80912090843m79945c0aiac83f9745019ead1@mail.gmail.com> <319e029f0912090923y3ed92544y9c3b821fd1a752b3@mail.gmail.com> <319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com> <79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com> <319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com> Message-ID: <319e029f0912101219q7f1c730ai7fe12b41f3914bed@mail.gmail.com> On Thu, Dec 10, 2009 at 20:25, Terry Reedy 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> <319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com> <79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com> <319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com> <319e029f0912101219q7f1c730ai7fe12b41f3914bed@mail.gmail.com> Message-ID: <1afaf6160912101224i36562613r1462f432d6ae88ed@mail.gmail.com> 2009/12/10 Lennart Regebro : > On Thu, Dec 10, 2009 at 20:25, Terry Reedy 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? 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> <319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com> <79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com> <319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com> <319e029f0912101219q7f1c730ai7fe12b41f3914bed@mail.gmail.com> <1afaf6160912101224i36562613r1462f432d6ae88ed@mail.gmail.com> Message-ID: <319e029f0912101631p4e00e006kb26aaba90bf53cdc@mail.gmail.com> On Thu, Dec 10, 2009 at 21:24, Benjamin Peterson wrote: > 2009/12/10 Lennart Regebro : >> On Thu, Dec 10, 2009 at 20:25, Terry Reedy 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 wrote: > Tarek Ziad? 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?= wrote: > On Fri, Dec 11, 2009 at 1:14 AM, Ben Finney 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? 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: References: <94bdd2610912080916s2dbb79d0ub8a77295bba9266e@mail.gmail.com> <4B20B4D1.10502@gmail.com> <94bdd2610912100519n43614c84n63c37794ec8f5d7b@mail.gmail.com> Message-ID: <4B221DA8.5060509@gmail.com> Darren Dale wrote: > On Thu, Dec 10, 2009 at 8:54 AM, Antoine Pitrou wrote: >> Tarek Ziad? 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> <319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com> <79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com> <319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com> <319e029f0912101219q7f1c730ai7fe12b41f3914bed@mail.gmail.com> <1afaf6160912101224i36562613r1462f432d6ae88ed@mail.gmail.com> Message-ID: <4B221F15.70904@gmail.com> Benjamin Peterson wrote: > 2009/12/10 Lennart Regebro : >> On Thu, Dec 10, 2009 at 20:25, Terry Reedy 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 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> <4B221DA8.5060509@gmail.com> Message-ID: <94bdd2610912110241y5a023f09m639ad57637b6f8e0@mail.gmail.com> On Fri, Dec 11, 2009 at 11:23 AM, Nick Coghlan wrote: > Darren Dale wrote: >> On Thu, Dec 10, 2009 at 8:54 AM, Antoine Pitrou wrote: >>> Tarek Ziad? 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(, {1: set([1])}) Popping and updating in two steps: defaultdict(, {1: set([1])}) ************ After initialization: defaultdict(, {1: set([1])}) Popping and updating in one step: defaultdict(, {}) 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: 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(, {1: set([1])}) > Popping and updating in two steps: defaultdict(, {1: set([1])}) > ************ > After initialization: defaultdict(, {1: set([1])}) > Popping and updating in one step: defaultdict(, {}) > > > 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(, {1: set([1])}) >> Popping and updating in two steps: defaultdict(, {1: set([1])}) >> ************ >> After initialization: defaultdict(, {1: set([1])}) >> Popping and updating in one step: defaultdict(, {}) >> >> >> 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> <319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com> <79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com> <319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com> <319e029f0912101219q7f1c730ai7fe12b41f3914bed@mail.gmail.com> <1afaf6160912101224i36562613r1462f432d6ae88ed@mail.gmail.com> Message-ID: <319e029f0912111232kb31e3e9j9e2ac42472db7c41@mail.gmail.com> On Thu, Dec 10, 2009 at 21:24, Benjamin Peterson wrote: > > 2009/12/10 Lennart Regebro : > > On Thu, Dec 10, 2009 at 20:25, Terry Reedy 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 >>> 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, 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 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(, {1: set([1])}) >>> Popping and updating in two steps: defaultdict(, {1: >>> set([1])}) >>> ************ >>> After initialization: defaultdict(, {1: set([1])}) >>> Popping and updating in one step: defaultdict(, {}) >>> >>> >>> 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> <319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com> <79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com> <319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com> <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 wrote: >> 2009/12/10 Lennart Regebro : >>> On Thu, Dec 10, 2009 at 20:25, Terry Reedy 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 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: () (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 = (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, 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 "", 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: 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" writes: > Syntax Error: EOL while scanning single-quoted string. [?] > Isn't this a bug? It has a report but is not a bug . -- \ ?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: On Sat, Dec 12, 2009 at 12:02, Tarek Ziad? 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: 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: References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com> Message-ID: <94bdd2610912121413g5783d634p9b2b65a98fe50f67@mail.gmail.com> On Sat, Dec 12, 2009 at 10:35 PM, Brett Cannon 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> <94bdd2610912121413g5783d634p9b2b65a98fe50f67@mail.gmail.com> Message-ID: On Sat, Dec 12, 2009 at 14:13, Tarek Ziad? wrote: > On Sat, Dec 12, 2009 at 10:35 PM, Brett Cannon 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: 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: References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com> <94bdd2610912121413g5783d634p9b2b65a98fe50f67@mail.gmail.com> Message-ID: <94bdd2610912121425v59ff7982q930e072909d0de00@mail.gmail.com> On Sat, Dec 12, 2009 at 11:18 PM, Brett Cannon 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> <94bdd2610912121413g5783d634p9b2b65a98fe50f67@mail.gmail.com> Message-ID: <4B242F6C.5050609@trueblade.com> Tarek Ziad? wrote: > On Sat, Dec 12, 2009 at 10:35 PM, Brett Cannon 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: References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com> <94bdd2610912121413g5783d634p9b2b65a98fe50f67@mail.gmail.com> <4B242F6C.5050609@trueblade.com> Message-ID: That's what I meant. [From my phone] On Dec 12, 2009 4:32 PM, "Eric Smith" 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: 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> <319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com> <79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com> <319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com> <319e029f0912101219q7f1c730ai7fe12b41f3914bed@mail.gmail.com> <1afaf6160912101224i36562613r1462f432d6ae88ed@mail.gmail.com> <319e029f0912111232kb31e3e9j9e2ac42472db7c41@mail.gmail.com> Message-ID: <1afaf6160912121700l7950617cmcbc3dce19dbcb742@mail.gmail.com> 2009/12/11 Lennart Regebro : > 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? 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> <319e029f0912090956n7ad5cd59y2759a1536e9fb9f8@mail.gmail.com> <79990c6b0912091547n3d9e25e5q5d77033fa9efaedd@mail.gmail.com> <319e029f0912100032n434086cdld78a707fb10a4ca5@mail.gmail.com> <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 wrote: > Tarek Ziad? 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> <4B221DA8.5060509@gmail.com> Message-ID: <94bdd2610912130356r5e6d973ft2e5a414b08afa106@mail.gmail.com> On Fri, Dec 11, 2009 at 11:23 AM, Nick Coghlan 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: 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: References: Message-ID: On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard 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: References: Message-ID: On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking wrote: > On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard > 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: References: Message-ID: On Mon, Dec 14, 2009 at 12:43 PM, Steven Bethard wrote: > On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking wrote: >> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard >> 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: References: 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: References: Message-ID: <24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com> On Mon, Dec 14, 2009 at 1:43 PM, Steven Bethard wrote: > On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking wrote: >> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard >> 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: References: Message-ID: <8c7f10c60912141135v58a99f9dp6f2bb0e84ffd5c3a@mail.gmail.com> 2009/12/14 Ian Bicking : > 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: <4B268DEC.8030501@voidspace.org.uk> Message-ID: <24ea26600912141135o7dd98f10ka5537fb23472cd1d@mail.gmail.com> On Mon, Dec 14, 2009 at 2:11 PM, Michael Foord 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: <4B268DEC.8030501@voidspace.org.uk> Message-ID: Michael Foord 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: References: Message-ID: On 12/14/2009 1:43 PM, Steven Bethard wrote: > On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking wrote: >> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard >> 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: <4B268DEC.8030501@voidspace.org.uk> <24ea26600912141135o7dd98f10ka5537fb23472cd1d@mail.gmail.com> Message-ID: On Mon, Dec 14, 2009 at 11:35 AM, Olemis Lang 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: <24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com> Message-ID: On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang 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: References: <24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com> Message-ID: <24ea26600912141220l5cd6c001o20bcd7538cfd05c7@mail.gmail.com> On Mon, Dec 14, 2009 at 3:00 PM, Steven Bethard wrote: > On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang 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: References: <4B268DEC.8030501@voidspace.org.uk> Message-ID: <4B269E31.6060408@gmail.com> Antoine Pitrou wrote: > Michael Foord 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: Hello, Mark Dickinson 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: <24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com> Message-ID: Steven Bethard 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: References: <24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com> Message-ID: <4B26A41F.5020009@gmail.com> Steven Bethard wrote: > On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang 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 wrote: > It follows the standard left-to-right evaluation order within an expression: > > () > > (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 = > (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: <24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com> <4B26A41F.5020009@gmail.com> Message-ID: <24ea26600912141310w77d07c42hc244f9ecc1642b9f@mail.gmail.com> On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan wrote: > Steven Bethard wrote: >> On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang 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: References: <5c6f2a5d0912141138w55242a4br6dee22c574894557@mail.gmail.com> Message-ID: <5c6f2a5d0912141317o2535f224q3315d7a522ef1924@mail.gmail.com> On Mon, Dec 14, 2009 at 8:20 PM, Antoine Pitrou wrote: > Mark Dickinson 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: 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 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: <24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com> <4B26A41F.5020009@gmail.com> <24ea26600912141310w77d07c42hc244f9ecc1642b9f@mail.gmail.com> Message-ID: On Mon, Dec 14, 2009 at 1:10 PM, Olemis Lang wrote: > On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan wrote: >>> On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang 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: Message-ID: <87hbrt41nb.fsf@benfinney.id.au> Ian Bicking 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 : [..] > 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: Dino Viehland 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: References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com> <1A472770E042064698CB5ADC83A12ACD04D81D51@TK5EX14MBXC118.redmond.corp.microsoft.com> Message-ID: <1A472770E042064698CB5ADC83A12ACD04D90462@TK5EX14MBXC118.redmond.corp.microsoft.com> Antoine wrote: > Dino Viehland 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: References: <4B268DEC.8030501@voidspace.org.uk> Message-ID: <35352AE5-878D-4074-B684-729EE8BB27C9@gmail.com> On Dec 14, 2009, at 2:37 PM, Antoine Pitrou wrote: > Michael Foord 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: References: <24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com> Message-ID: On Mon, Dec 14, 2009 at 12:35, Antoine Pitrou wrote: > Steven Bethard 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: 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 : > 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: References: <4B268DEC.8030501@voidspace.org.uk> <24ea26600912141135o7dd98f10ka5537fb23472cd1d@mail.gmail.com> Message-ID: On Dec 14, 2009, at 2:55 PM, Steven Bethard wrote: > On Mon, Dec 14, 2009 at 11:35 AM, Olemis Lang 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: References: <4B268DEC.8030501@voidspace.org.uk> <24ea26600912141135o7dd98f10ka5537fb23472cd1d@mail.gmail.com> Message-ID: 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: 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 "", line 1, in 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 "", line 1, in 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: 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: References: <24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com> Message-ID: <56CF2170-397D-4E90-A3F6-90ADB2FA5C74@gmail.com> On Dec 14, 2009, at 3:35 PM, Antoine Pitrou wrote: > Steven Bethard 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: <24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com> <56CF2170-397D-4E90-A3F6-90ADB2FA5C74@gmail.com> Message-ID: On Mon, Dec 14, 2009 at 6:34 PM, 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: <4B268DEC.8030501@voidspace.org.uk> <35352AE5-878D-4074-B684-729EE8BB27C9@gmail.com> Message-ID: On Mon, Dec 14, 2009 at 4:16 PM, ssteinerX at gmail.com wrote: > > On Dec 14, 2009, at 2:37 PM, Antoine Pitrou wrote: > >> Michael Foord 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: On Mon, Dec 14, 2009 at 16:21, Benjamin Peterson wrote: > 2009/12/14 Dino Viehland : > > 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: 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? 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: On Tue, 15 Dec 2009 14:40:56 +1100, Mark Hammond 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? 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: References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com> <0a500cc770721944b33036da1cb5b3f3@preisshare.net> <4B270548.2090600@gmail.com> 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 > 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> Message-ID: <87zl5k3meu.fsf@benfinney.id.au> David Lyon writes: > On Tue, 15 Dec 2009 14:40:56 +1100, Mark Hammond > 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> <4B270AFE.1060505@skippinet.com.au> Message-ID: <30a87fe1344a9a8c6aa0e25ee099bb43@preisshare.net> On Tue, 15 Dec 2009 15:05:18 +1100, Mark Hammond 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> <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 > > 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> <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 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> <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> <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 > > 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: <4B268DEC.8030501@voidspace.org.uk> <35352AE5-878D-4074-B684-729EE8BB27C9@gmail.com> Message-ID: Steven Bethard 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 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> <87zl5k3meu.fsf@benfinney.id.au> Message-ID: <94bdd2610912150146i7ecea732i69eed492b700026b@mail.gmail.com> On Tue, Dec 15, 2009 at 5:12 AM, Ben Finney 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: References: 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: <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: <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: <24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com> <56CF2170-397D-4E90-A3F6-90ADB2FA5C74@gmail.com> Message-ID: Ian Bicking wrote: > On Mon, Dec 14, 2009 at 6:34 PM, 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 wrote: > Steven Bethard 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: References: <24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com> <56CF2170-397D-4E90-A3F6-90ADB2FA5C74@gmail.com> Message-ID: On Tue, Dec 15, 2009 at 4:33 AM, Neal Becker 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 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> <4B270AFE.1060505@skippinet.com.au> <30a87fe1344a9a8c6aa0e25ee099bb43@preisshare.net> <4B270F84.5030802@skippinet.com.au> <822785ca33912a9c6656ef6d36ae0be9@preisshare.net> <20091215093255.GA13198@laurie.devork> Message-ID: On Tue, 15 Dec 2009 09:32:55 +0000, Floris Bruynooghe 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: References: <94bdd2610912121202l48d39325q6f4cdcd73f972d5c@mail.gmail.com> <0a500cc770721944b33036da1cb5b3f3@preisshare.net> <4B270548.2090600@gmail.com> <4B270AFE.1060505@skippinet.com.au> <30a87fe1344a9a8c6aa0e25ee099bb43@preisshare.net> <4B270F84.5030802@skippinet.com.au> <822785ca33912a9c6656ef6d36ae0be9@preisshare.net> <20091215093255.GA13198@laurie.devork> 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> <4B270AFE.1060505@skippinet.com.au> <30a87fe1344a9a8c6aa0e25ee099bb43@preisshare.net> <4B270F84.5030802@skippinet.com.au> <822785ca33912a9c6656ef6d36ae0be9@preisshare.net> <20091215093255.GA13198@laurie.devork> <4B28C29D.6020400@gmail.com> Message-ID: <22b6fd677f9891bde50c8108bc1c4177@preisshare.net> On Wed, 16 Dec 2009 21:21:01 +1000, Nick Coghlan 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> <4B270AFE.1060505@skippinet.com.au> <30a87fe1344a9a8c6aa0e25ee099bb43@preisshare.net> <4B270F84.5030802@skippinet.com.au> <822785ca33912a9c6656ef6d36ae0be9@preisshare.net> <20091215093255.GA13198@laurie.devork> <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> <4B270AFE.1060505@skippinet.com.au> <30a87fe1344a9a8c6aa0e25ee099bb43@preisshare.net> <4B270F84.5030802@skippinet.com.au> <822785ca33912a9c6656ef6d36ae0be9@preisshare.net> <20091215093255.GA13198@laurie.devork> <4B28C29D.6020400@gmail.com> <22b6fd677f9891bde50c8108bc1c4177@preisshare.net> <87hbrq5lw7.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On Thu, 17 Dec 2009 12:18:00 +0900, "Stephen J. Turnbull" 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 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 // ? 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: 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> <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? 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 // ? 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: 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?= 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: 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" 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 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: On Mon, Dec 21, 2009 at 07:02, Mark Dickinson 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 > > > 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: 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: References: 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: -----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: References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com> <4B301E16.1090106@gmail.com> Message-ID: <94bdd2610912230218p37ec36f1t1b11f209bc7940e3@mail.gmail.com> On Wed, Dec 23, 2009 at 3:31 AM, Tres Seaver 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> <94bdd2610912230218p37ec36f1t1b11f209bc7940e3@mail.gmail.com> Message-ID: <94bdd2610912230221p1d383728pf48157c5456a8e8@mail.gmail.com> On Wed, Dec 23, 2009 at 11:18 AM, Tarek Ziad? 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? 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: On Dec 23, 2009, at 10:00 AM, Frank Wierzbicki wrote: > On Mon, Dec 14, 2009 at 5:58 PM, Tarek Ziad? 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" : >> 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" : >> 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? wrote: > 2009/12/23 "Martin v. L?wis" : >>> 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: On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull" 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: 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: <4B3333DF.40705@v.loewis.de> David Lyon wrote: > On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull" > 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" : >> 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> <4B3333DF.40705@v.loewis.de> Message-ID: <94bdd2610912240152r6131ec9ay2ada83f66aa17b35@mail.gmail.com> On Thu, Dec 24, 2009 at 10:26 AM, "Martin v. L?wis" wrote: > David Lyon wrote: >> On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull" >> 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> <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> <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: References: <24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com> <4B26A41F.5020009@gmail.com> <24ea26600912141310w77d07c42hc244f9ecc1642b9f@mail.gmail.com> Message-ID: On Tue, Dec 15, 2009 at 12:37 AM, Steven Bethard 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: References: <24ea26600912141112i31a9eba7j7d06837456508094@mail.gmail.com> <4B26A41F.5020009@gmail.com> <24ea26600912141310w77d07c42hc244f9ecc1642b9f@mail.gmail.com> Message-ID: On Sun, Dec 27, 2009 at 9:51 AM, anatoly techtonik wrote: > On Tue, Dec 15, 2009 at 12:37 AM, Steven Bethard > 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> <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 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> <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 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> <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, wrote: >> On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan 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> <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 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> <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: Tarek Ziad? 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> <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 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> <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: 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> Message-ID: <94bdd2610912271702k662621ecve996eb7f9ff181fd@mail.gmail.com> On Mon, Dec 28, 2009 at 1:48 AM, Antoine Pitrou wrote: > Tarek Ziad? 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> <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? 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 ?>?, ?>=?, ?=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> <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> <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 wrote: >> Tarek Ziad? 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> <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? writes: > On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar > 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 ?>?, ?>=?, ?=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> <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 > 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? writes: > > > On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar > > 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 > ?>?, ?>=?, ? 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: 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> <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? writes: > >> On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar >> 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 > ?>?, ?>=?, ? 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 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. "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> <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> <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 wrote: >> Tarek Ziad? 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> <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 >> 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> <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? writes: >> >>> On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar >>> 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 >> ?>?, ?>=?, ?> 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> <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> <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> <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 > ???>???, ???>=???, ??? 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 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 > > > 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: References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com> <75d5dd69b850e9bd793b43618327e655@preisshare.net> <871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp> <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: On 12/27/2009 7:48 PM, Antoine Pitrou wrote: > Tarek Ziad? 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> <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> <94bdd2610912271702k662621ecve996eb7f9ff181fd@mail.gmail.com> Message-ID: <2883.115.128.29.13.1261975301.squirrel@syd-srv02.ezyreg.com> >> Tarek Ziad? 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: References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com> <75d5dd69b850e9bd793b43618327e655@preisshare.net> <871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp> <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: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Terry Reedy wrote: > On 12/27/2009 7:48 PM, Antoine Pitrou wrote: >> Tarek Ziad? 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> <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> <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: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziad? wrote: > On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar > 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: 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> Message-ID: <319e029f0912272239g593053c9x12b5cd73513d35aa@mail.gmail.com> On Mon, Dec 28, 2009 at 05:37, Terry Reedy 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> <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> <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> <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> <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> <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> <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> <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> <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> <319e029f0912272239g593053c9x12b5cd73513d35aa@mail.gmail.com> Message-ID: <94bdd2610912280045u13e03d01q4f2c7ab8dd9fb5dc@mail.gmail.com> On Mon, Dec 28, 2009 at 7:39 AM, Lennart Regebro wrote: > On Mon, Dec 28, 2009 at 05:37, Terry Reedy 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: 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> Message-ID: <94bdd2610912280105s9dac69w7719effe795ecf8f@mail.gmail.com> On Mon, Dec 28, 2009 at 6:20 AM, Tres Seaver wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tarek Ziad? wrote: >> On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar >> 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: 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> Message-ID: <94bdd2610912280111r30881557wc2539ed371814d54@mail.gmail.com> On Mon, Dec 28, 2009 at 6:16 AM, Tres Seaver wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Terry Reedy wrote: >> On 12/27/2009 7:48 PM, Antoine Pitrou wrote: >>> Tarek Ziad? ?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> <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 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> <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> <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> <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 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> <94bdd2610912280105s9dac69w7719effe795ecf8f@mail.gmail.com> Message-ID: <877hs75u6f.fsf@benfinney.id.au> Tarek Ziad? 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 ?>? ?>=? ? 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> <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> <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> <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, 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> <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 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> <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, References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com> <871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp> <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: <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" : >> 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 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, 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" : [..] >> 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" 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 wrote: > On Mon, Dec 28, 2009 at 11:27, ? 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? 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 wrote: > On Mon, Dec 28, 2009 at 12:02, Tarek Ziad? 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 wrote: > On Mon, Dec 28, 2009 at 11:54, "Martin v. L?wis" 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 writes: > On Mon, Dec 28, 2009 at 11:54, "Martin v. L?wis" 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> <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> <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> <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> <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" : > >> 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: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziad? wrote: > 2009/12/28 "Martin v. L?wis" : >>> 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> <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: On Mon, 28 Dec 2009 10:42:20 +0100, "Martin v. L?wis" 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: References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com> <871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp> <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: <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" > 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> <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> <4B393A34.4040301@voidspace.org.uk> Message-ID: On Mon, 28 Dec 2009 23:07:32 +0000, Michael Foord 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> <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: David Lyon 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: References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com> <871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp> <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: <4B3943C4.2090003@mrabarnett.plus.com> Antoine Pitrou wrote: > David Lyon 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: References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com> <871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp> <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: <20091228235517.1C6C51FB73E@kimball.webabinitio.net> On Mon, 28 Dec 2009 23:21:54 +0000, Antoine Pitrou wrote: > David Lyon 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> <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> <4B3943C4.2090003@mrabarnett.plus.com> Message-ID: R. David Murray 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: References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com> <871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp> <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: <4c5f058f7af37a281c587896f6136cdb@preisshare.net> On Mon, 28 Dec 2009 23:21:54 +0000 (UTC), Antoine Pitrou 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> <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> <20091228235517.1C6C51FB73E@kimball.webabinitio.net> Message-ID: <485962b382c592d08bf2a021dfd824f0@preisshare.net> On Mon, 28 Dec 2009 18:55:17 -0500, "R. David Murray" 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> <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> <20091228235517.1C6C51FB73E@kimball.webabinitio.net> <485962b382c592d08bf2a021dfd824f0@preisshare.net> Message-ID: <87my124mrh.fsf@benfinney.id.au> David Lyon 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: 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> Message-ID: <94bdd2610912281712m758267aawbe0ac3c1112995f4@mail.gmail.com> On Mon, Dec 28, 2009 at 9:26 PM, Tres Seaver 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> <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> <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: References: <94bdd2610912211625k6a52dc19ue7dd7cad1e4f655c@mail.gmail.com> <871vilqhsy.fsf@uwakimon.sk.tsukuba.ac.jp> <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> <4B393A34.4040301@voidspace.org.uk> Message-ID: <4B395AB7.9050700@hastings.org> David Lyon wrote: > On Mon, 28 Dec 2009 23:07:32 +0000, Michael Foord > 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> <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 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> <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: On Dec 28, 2009, at 8:35 PM, Tarek Ziad? wrote: > On Tue, Dec 29, 2009 at 2:17 AM, 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> <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? 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> <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> <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 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: 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 Pyright: PyCon pre-favorites, the Carl T. edition: Aftermarket Pipes: Five Pycon 2010 Talks I Need to See: Jessenoller.com: PyCon 2010: Talks I want to see: The Third Bit: Five PyCon Talks I Want To See: 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: References: Message-ID: <1afaf6160912301204p247e77c4r2271c4f37114ba4@mail.gmail.com> 2009/12/30 Martin (gzlist) : > 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: > > > 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: > > > ? ?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: <1afaf6160912301204p247e77c4r2271c4f37114ba4@mail.gmail.com> Message-ID: <24ea26600912301233pe13ffb6if7af37fedf21c619@mail.gmail.com> On Wed, Dec 30, 2009 at 3:04 PM, Benjamin Peterson wrote: > 2009/12/30 Martin (gzlist) : >> 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: >> >> >> ? ?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: <1afaf6160912301204p247e77c4r2271c4f37114ba4@mail.gmail.com> <24ea26600912301233pe13ffb6if7af37fedf21c619@mail.gmail.com> Message-ID: <1afaf6160912301520o6a81e4b1o10f931043976159d@mail.gmail.com> 2009/12/30 Olemis Lang : > 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: ... 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: References: 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: <4B3BE6C7.8060301@voidspace.org.uk> Message-ID: <1afaf6160912301553v674a0419gb45070627807cc1e@mail.gmail.com> 2009/12/30 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: 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: <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: <4B3BE6C7.8060301@voidspace.org.uk> Message-ID: 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: <1afaf6160912301204p247e77c4r2271c4f37114ba4@mail.gmail.com> Message-ID: Thanks for the quick response. On 30/12/2009, Benjamin Peterson 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: I get the impression Robert doesn't like it much though, and seemed to have wanted something more targeted in the past as well: 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