Re: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
On Thu, Dec 10, 2009 at 05:41:01AM +, 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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
On Thu, Dec 10, 2009 at 7:24 AM, sstein...@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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
On Wed, Dec 9, 2009 at 5:53 AM, Michael Mysinger wrote: > More English language fixes: I have just applied them. Thanks. Tarek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
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? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unittest/doctest formatting differences in 2.7a1?
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
