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 literal"><span class="pre">.post345</span></tt> marker. +before a <tt class="docutils literal"><span class="pre">.post456</span></tt> marker. Technical question: I don't know what notation this versioning schema was trying for, especially in regards to what the +'s mean: N.N[.N]+[abc]N[.N]+[.postN+][.devN+] Am I missing something here? You could maybe explain what the pluses mean in the PEP, and why some are inside the [] and others are outside. Or a regular expression version like this might be more specific. N.N(.N)?([abc]N(.N)?)?(.postN)?(.devN)? Or an linux help version like this may be more readible. N.N[.N][{abc}N[.N]][.postN][.devN] Cheers, Michael Mysinger (longtime python-dev lurker)
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
Floris Bruynooghe
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
On Thu, Dec 10, 2009 at 05:41:01AM +0000, Michael Mysinger wrote:
Floris Bruynooghe
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
On Thu, Dec 10, 2009 at 10:44 AM, Floris Bruynooghe
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
participants (3)
-
Floris Bruynooghe -
Michael Mysinger -
Tarek Ziadé