Re: [Python-Dev] Proposing PEP 386 for addition
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 ___ 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 Sun, Dec 13, 2009 at 12:56 PM, Tarek Ziadé ziade.ta...@gmail.com wrote: [..] Furthermore, I've seen some patterns in those 5% that can be worked out so I'll probably be able to lower it to 3% Done: Total Packages : 8690 Already Match : 7645.0 (87.97%) Have Suggestion : 768.0 (8.84%) No Suggestion : 277.0 (3.19%) I guess I'll just wait for the PEP to be rejected or accepted now :) Regards, Tarek ___ 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é ziade.ta...@gmail.com writes: I've started to add another section in the PEP to summarize this discussion but then I realized that we are already giving the answer in the PEP in the Requisites and current status I made it clearer though, by adding an extra sentence with an example. Thank you. Requesite #2 : 2. most projects need special meaning versions for pre-releases (such as I don't think “most projects need” is supported by evidence. Fortunately, for the argument in the PEP, you don't need “most projects need” to be true; you only need “a significant number of projects”. It could be a small minority, but if it is a significantly large minority that still justifies addressing the need. So, change this to “a significant number of projects need” and I think it's a fair statement. Let me know if you think this is enough and addresses your concern, Thank you for working to make this a good PEP. -- \ Moriarty: “Forty thousand million billion dollars? That money | `\must be worth a fortune!” —The Goon Show, _The Sale of | _o__) Manhattan_ | Ben Finney ___ 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 Sun, Dec 13, 2009 at 9:53 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: Tarek Ziadé ziade.ta...@gmail.com writes: I've started to add another section in the PEP to summarize this discussion but then I realized that we are already giving the answer in the PEP in the Requisites and current status I made it clearer though, by adding an extra sentence with an example. Thank you. Requesite #2 : 2. most projects need special meaning versions for pre-releases (such as I don't think “most projects need” is supported by evidence. Fortunately, for the argument in the PEP, you don't need “most projects need” to be true; you only need “a significant number of projects”. It could be a small minority, but if it is a significantly large minority that still justifies addressing the need. So, change this to “a significant number of projects need” and I think it's a fair statement. Let me know if you think this is enough and addresses your concern, Thank you for working to make this a good PEP. Done. Thanks for your help. Tarek ___ 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 11:23 AM, Nick Coghlan ncogh...@gmail.com wrote: [..] Eric's suggestion of NormalizedVersion sounds best to me - it exactly describes the intended role of the class. Done. Steve Steiner added a nice functional test that tries the scheme on *all* pypi versions: MacZiade:distutilsver tarek$ nosetests -s . Loading saved pypi data... Results: Total Packages : 8654 Already Match : 7604.0 (87.87%) Have Suggestion : 624.0 (7.21%) No Suggestion : 426.0 (4.92%) .. -- Ran 6 tests in 0.463s OK IOW, the current scheme works as-is for 88% of the packages, and is able to transform 7% of the remainings. The 5% that are not workable are mostly packages with versions like : (extracts) - .01 - 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 ___ 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 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 ___ 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
Darren Dale wrote: On Thu, Dec 10, 2009 at 8:54 AM, Antoine Pitrou solip...@pitrou.net wrote: Tarek Ziadé ziade.tarek at gmail.com writes: Do you have a better suggestion ? I was thinking about StandardVersion but Standard doesn't really express what we want to achieve here I think, I think StandardVersion is fine. I prefer StandardVersion as well. Rational (according to websters.com): Eric's suggestion of NormalizedVersion sounds best to me - it exactly describes the intended role of the class. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 386 for addition
On Fri, Dec 11, 2009 at 6:15 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: [..] No, the PEP document itself should either contain the questions and answers, or contain a link to the discussion along with a brief summary of what it was about and a explicit statement of its outcome. Ok then, I'll add a section summarizing the history of the discussions in that case. Regards Tarek ___ 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 11:23 AM, Nick Coghlan ncogh...@gmail.com wrote: Darren Dale wrote: On Thu, Dec 10, 2009 at 8:54 AM, Antoine Pitrou solip...@pitrou.net wrote: Tarek Ziadé ziade.tarek at gmail.com writes: Do you have a better suggestion ? I was thinking about StandardVersion but Standard doesn't really express what we want to achieve here I think, I think StandardVersion is fine. I prefer StandardVersion as well. Rational (according to websters.com): Eric's suggestion of NormalizedVersion sounds best to me - it exactly describes the intended role of the class. Ok, NormalizedVersion is fine with me, I'll change the doc + code accordingly Regards Tarek ___ 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 floris.bruynooghe at gmail.com writes:
On Tue, Dec 08, 2009 at 08:53:18PM -0800, Michael Mysinger wrote:
I don't know what notation this versioning schema was trying for,
especially
in regards to what the +'s mean:
N.N[.N]+[abc]N[.N]+[.postN+][.devN+]
The full regex (stripped from named groups) is the rather unreadable:
\d+\.\d+(\.\d+)*([abc]?\d+(\.\d+)*)?((\.post\d+)?(\.dev\d+)?)?
The ()? around the combination of post and dev is not needed. I also think
[abc]? should just be [abc], as one letter is required to proceed the digit in
that case, and the full regular expression does help to distinguish exactly
which of those two is required by the PEP.
You are right
If your regular expression with my modifications above is right,
then using the substitions 'N for \d+', '{} for []', '[] for ()?'
and '+ for *' leaves:
N.N[.N]+[{abc}N[.N]+][.postN][.devN]
Notice that the last two +'s are gone, and overall I think this is more
consistent psuedo-code.
That's quite readable and more consistent then the original
pseudo-code, I like it.
Regards
Floris
--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
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 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 dsdal...@gmail.com: Those aren't new proposals, though, they already exist in distutils. I see. Thanks for clarifying –– maybe the PEP should better explain this. \malthe ___ 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 cyber...@yahoo.com 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 mbo...@gmail.com wrote: 2009/12/10 Darren Dale dsdal...@gmail.com: Those aren't new proposals, though, they already exist in distutils. I see. Thanks for clarifying –– maybe the PEP should better explain this. It is already pretty clear: Distutils currently provides a StrictVersion and a LooseVersion class that can be used to manage versions. Darren ___ 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 mbo...@gmail.com wrote: [..] Great work, Tarek. I think you've managed to establish a good body of knowledge on this and the proposal seems sound. Thanks :) That said, I think the terms ``LooseVersion`` and ``StrictVersion`` are less than optimal. Really, what's meant is ``LexicalVersion`` and ``ChronologicalVersion`` (or ``NumberedVersion``). It's not about strictness or looseness. I've added a note explaining that these exists since years in Distutils, for clarity. Also, the word rational is not familiar to me in the context of versions; is this term known outside of this proposal? I couldn't find any reference to it. Do you have a better suggestion ? I was thinking about StandardVersion but Standard doesn't really express what we want to achieve here I think, Regards, Tarek ___ 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
floris.bruynoo...@gmail.com wrote:
[..]
N.N[.N]+[{abc}N[.N]+][.postN][.devN]
Notice that the last two +'s are gone, and overall I think this is more
consistent psuedo-code.
That's quite readable and more consistent then the original
pseudo-code, I like it.
Thanks, I have applied it. I have also added the full regular
expression in the PEP so things are clearer.
Regards,
Tarek
___
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é ziade.tarek at gmail.com writes: Do you have a better suggestion ? I was thinking about StandardVersion but Standard doesn't really express what we want to achieve here I think, I think StandardVersion is fine. ___ 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 solip...@pitrou.net wrote: Tarek Ziadé ziade.tarek at gmail.com writes: Do you have a better suggestion ? I was thinking about StandardVersion but Standard doesn't really express what we want to achieve here I think, I think StandardVersion is fine. I prefer StandardVersion as well. Rational (according to websters.com): 1. agreeable to reason; reasonable; sensible: a rational plan for economic development. 2. having or exercising reason, sound judgment, or good sense: a calm and rational negotiator. Standard (according to websters.com): 1. something considered by an authority or by general consent as a basis of comparison; an approved model. 2. an object that is regarded as the usual or most common size or form of its kind 3. a rule or principle that is used as a basis for judgment Darren ___ 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é ziade.ta...@gmail.com writes: I believe that the current situation is as close to consensus as we will get on distutils-sig, and in the interests of avoiding months of further discussion which won't take things any further, I propose to allow final comments from python-dev and then look for a final decision. I don't see any information in the PEP for alternate proposals that were made during its drafting. It's customary to explain what alternative proposals have been advanced, and give the PEP champion's explanation of why they weren't chosen. This is, of course, in the interests of forestalling further repetition of those same discussions. -- \ “My business is to teach my aspirations to conform themselves | `\ to fact, not to try and make facts harmonise with my | _o__) aspirations.“ —Thomas Henry Huxley, 1860-09-23 | Ben Finney ___ 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 ben+pyt...@benfinney.id.au wrote: Tarek Ziadé ziade.ta...@gmail.com writes: I believe that the current situation is as close to consensus as we will get on distutils-sig, and in the interests of avoiding months of further discussion which won't take things any further, I propose to allow final comments from python-dev and then look for a final decision. I don't see any information in the PEP for alternate proposals that were made during its drafting. It's customary to explain what alternative proposals have been advanced, and give the PEP champion's explanation of why they weren't chosen. Since most discussions at the end were about the precise syntax of the versions schema, (using - instead of .) I don't see the point of adding in the PEP text itself the list of those proposals, and why each one of them was not kept. Now by alternate if you mean a proposal that is completely different from what is in the PEP, I don't recall that we had any viable alternative proposals in the discussions. By viable I mean something that provides what we need : a schema that allows us to compare final versions, but also development, pre and post-release versions. This is, of course, in the interests of forestalling further repetition of those same discussions. Right, I see what you mean, and I was indeed expecting that some people were going to ask things that we already talked about at Distutils-SIG. My intent if this happens, is to provide very concise answers here, that correspond to a summary of what has been said, and if required with some links to some relevant mails at Distutils-SIG. IOW, the process should be fairly short here (unless we find out we are missing a big point somehow in the PEP), so if you do think about something that should be talked about (e.g. if you think the PEP is not right for any particular reason), please let's discuss it. Regards Tarek ___ 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?= ziade.ta...@gmail.com wrote: On Fri, Dec 11, 2009 at 1:14 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: I don't see any information in the PEP for alternate proposals that were made during its drafting. It's customary to explain what alternative proposals have been advanced, and give the PEP champion's explanation of why they weren't chosen. [...] This is, of course, in the interests of forestalling further repetition of those same discussions. Right, I see what you mean, and I was indeed expecting that some people were going to ask things that we already talked about at Distutils-SIG. My intent if this happens, is to provide very concise answers here, that correspond to a summary of what has been said, and if required with some links to some relevant mails at Distutils-SIG. IMO, if you have to answer here, then it should go into the PEP as Ben suggests. If I recall correctly, such summaries in PEPs often link to the relevant discussion threads. --David ___ 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é ziade.ta...@gmail.com writes: Now by alternate if you mean a proposal that is completely different from what is in the PEP, I don't recall that we had any viable alternative proposals in the discussions. By viable I mean something that provides what we need : a schema that allows us to compare final versions, but also development, pre and post-release versions. Yes, I'm referring to the discussion that were had over “why do we want special keywords that mess with the default alphanumerical ordering of version string components?” discussion. That needs to be addressed in the PEP, since it's germane to the explanation for the PEP's existence. This is, of course, in the interests of forestalling further repetition of those same discussions. Right, I see what you mean, and I was indeed expecting that some people were going to ask things that we already talked about at Distutils-SIG. My intent if this happens, is to provide very concise answers here, No, the PEP document itself should either contain the questions and answers, or contain a link to the discussion along with a brief summary of what it was about and a explicit statement of its outcome. -- \ “I think there is a world market for maybe five computers.” | `\ —Thomas Watson, chairman of IBM, 1943 | _o__) | Ben Finney ___ 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
More English language fixes:
-In Python there are no real restriction yet on how a project should
+In Python there are no real restrictions yet on how a project should
-Furthermore, this will make OS packagers work easier when repackaging standards
-compliant distributions, as of now it can be difficult to decide how two
+Furthermore, this will make OS packagers' work easier when repackaging
standards
+compliant distributions, because as of now it can be difficult to decide how
two
-to support many or all existing versioning schemas.
+to support all or even most of existing versioning schemas.
-reasons and we cannot expect that to change. +reasons
that we cannot expect to change.
-version schemas and is a preferable alternative than supporting
+version schemas and is a preferable alternative to supporting
-there should be possible to express more than one versioning level
+it should be possible to express more than one versioning level
-The problem with this is that while it allows expressing requisite any
-nesting level it doesn't allow to express special meaning versions
-(pre and post-releases as well as development versions), as expressed in +The
problem with this is that while it allows expressing any
+nesting level it doesn't allow giving special meaning to versions
+(pre- and post-releases as well as development versions) as expressed in
-Also, notice that Distutils version classes are not really used in the
+Also, note that Distutils version classes are not really used in the
-which does not enforce any rule for the version, but
+which does not enforce any rules for the version, but
-Setuptools function is quite spread because it's used by tools
+Setuptools function is quite widespread because it's used by tools
-post-releases -- which apparently is used by a number of projects
+post-releases -- which apparently are used by a number of projects
This one is particularly critical to your intended meaning as I read it:
-before a tt class=docutils literalspan class=pre.post345/span/tt
marker.
+before a tt class=docutils literalspan class=pre.post456/span/tt
marker.
Technical question:
I don't know what notation this versioning schema was trying for, especially in
regards to what the +'s mean:
N.N[.N]+[abc]N[.N]+[.postN+][.devN+]
Am I missing something here? You could maybe explain what the pluses mean in
the PEP, and why some are inside the [] and others are outside.
Or a regular expression version like this might be more specific.
N.N(.N)?([abc]N(.N)?)?(.postN)?(.devN)?
Or an linux help version like this may be more readible.
N.N[.N][{abc}N[.N]][.postN][.devN]
Cheers,
Michael Mysinger
(longtime python-dev lurker)
___
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 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 ___ 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
Floris Bruynooghe floris.bruynooghe at gmail.com writes:
On Tue, Dec 08, 2009 at 08:53:18PM -0800, Michael Mysinger wrote:
I don't know what notation this versioning schema was trying for, especially
in regards to what the +'s mean:
N.N[.N]+[abc]N[.N]+[.postN+][.devN+]
The full regex (stripped from named groups) is the rather unreadable:
\d+\.\d+(\.\d+)*([abc]?\d+(\.\d+)*)?((\.post\d+)?(\.dev\d+)?)?
The ()? around the combination of post and dev is not needed. I also think
[abc]? should just be [abc], as one letter is required to proceed the digit in
that case, and the full regular expression does help to distinguish exactly
which of those two is required by the PEP.
So the '+' in the pseudo notation above roughly means one or more
with the brackets meaning zero or one so plus and brackets combined
result into zero or more. But even then it's might be missing
square brackets around the whole of [abc]N[.N]+.
What is confusing about the +'s is that they are not consistent. If your regular
expression with my modifications above is right, then using the substitions 'N
for \d+', '{} for []', '[] for ()?' and '+ for *' leaves:
N.N[.N]+[{abc}N[.N]+][.postN][.devN]
Notice that the last two +'s are gone, and overall I think this is more
consistent psuedo-code.
Note that the meaning of the contents of the brackets changes too
(abc is a choice, .postN+ is the recursive notation) so it'll
probably never work exactly. So maybe the PEP should also include the
full regex for exactness.
Regards
Floris
Yes, it probably should have the full regex for absolute clarity, and it can
still have some type of psuedo-code for easier reading, but inconsistent
psuedo-code just adds confusion instead of simplification.
Cheers,
Michael
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Proposing PEP 386 for addition
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 | オープンソースはすごい! | 开源传万世，因有你参与 ___ 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: 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... ___ 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
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. ___ 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 Tue, Dec 8, 2009 at 8:45 PM, Terry Reedy tjre...@udel.edu wrote: Tarek Ziadé wrote: Hello, On behalf of the Distutils-SIG, I would like to propose PEP 386 for inclusion in the sdtlib, and have a final discussion here on Python-dev. http://www.python.org/dev/peps/pep-0386 Some English copy editor comments: and it will optionally allow to use that field I believe you mean and it will optionally allow use of that field requires zope.interface, as long as its version is superior to 3.5.0. requires zope.interface with a version greater than 3.5.0. It is not in the scope of this PEP to come with an universal versioning schema,intended to support... I believe you mean It is not in the scope of this PEP to provide a universal versioning schema intended to support... Applied, thank you ___ 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
