Re: [Python-Dev] Pronouncement on PEP 389: argparse?
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. ___ 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] Pronouncement on PEP 389: argparse?
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 ___ 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 345 : Metadata for Python Software Packages 1.2
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 ___ 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 345 : Metadata for Python Software Packages 1.2
> 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 ___ 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 345 : Metadata for Python Software Packages 1.2
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 ___ 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 345 : Metadata for Python Software Packages 1.2
On 12/27/2009 4:15 PM, david.l...@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 ___ 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 345 : Metadata for Python Software Packages 1.2
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. ___ 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 345 : Metadata for Python Software Packages 1.2
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 ___ 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 345 : Metadata for Python Software Packages 1.2
> 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 ___ 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 345 : Metadata for Python Software Packages 1.2
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 ___ 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 345 : Metadata for Python Software Packages 1.2
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 ‘>’, ‘>=’, ‘<’ ‘<=’ are standard and more obvious. That is, the existing operators: Requires-Python: >=2.5, <2.6 explicitly specify the range in your example. -- \ “Value your freedom or you will lose it, teaches history. | `\ “Don't bother us with politics,” respond those who don't want | _o__) to learn.” —Richard Stallman, 2002 | Ben Finney ___ 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 345 : Metadata for Python Software Packages 1.2
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 ___ 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 345 : Metadata for Python Software Packages 1.2
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 ‘>’, ‘>=’, ‘<’, ‘<=’ are sufficient, more obvious, and more explicit. In other words, to get the meaning you desire above, the existing operators can be used: ‘Requires-Python: >=3, <4’. -- \ “Not using Microsoft products is like being a non-smoker 40 or | `\ 50 years ago: You can choose not to smoke, yourself, but it's | _o__) hard to avoid second-hand smoke.” —Michael Tiemann | Ben Finney ___ 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 345 : Metadata for Python Software Packages 1.2
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. ___ 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 345 : Metadata for Python Software Packages 1.2
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 > ‘>’, ‘>=’, ‘<’, ‘<=’ are sufficient, more obvious, and more explicit. In > other words, to get the meaning you desire above, the existing operators > can be used: ‘Requires-Python: >=3, <4’. IMHO 'Requires-Python: 3*' (or '3.*') would be better than 'Requires-Python: >=3, <4'. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part. ___ 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 345 : Metadata for Python Software Packages 1.2
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 ‘>’, ‘>=’, ‘<’, ‘<=’ are sufficient, more obvious, and more explicit. In other words, to get the meaning you desire above, the existing operators can be used: ‘Requires-Python: >=3, <4’. Perhaps there should be a new range operator: Requires-Python: 3 ~ 4 Half-open, of course. ___ 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 345 : Metadata for Python Software Packages 1.2
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 ___ 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 345 : Metadata for Python Software Packages 1.2
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 ___ 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 345 : Metadata for Python Software Packages 1.2
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 ___ 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 345 : Metadata for Python Software Packages 1.2
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 ___ 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 345 : Metadata for Python Software Packages 1.2
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 ‘>’, ‘>=’, ‘<’, ‘<=’ are sufficient, more obvious, and more explicit. In other words, to get the meaning you desire above, the existing operators can be used: ‘Requires-Python: >=3, <4’. IMHO 'Requires-Python: 3*' (or '3.*') would be better than 'Requires-Python: >=3, <4'. '3.*' would be the better of the two. ___ 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 345 : Metadata for Python Software Packages 1.2
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. ___ 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 345 : Metadata for Python Software Packages 1.2
>> 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 ___ 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 345 : Metadata for Python Software Packages 1.2
> Instead, the default should be â==â. That is, âRequires-Python: 3â > should be equivalent to âRequires-Python: ==3â; and only â3â or > â3.0â or > â3.0.0â etc. will match. I maintain that is what most people will > expect > on seeing that syntax. > > If a less strict range is desired, the existing comparison operators > â>â, â>=â, â<â, â<=â are sufficient, more obvious, and > more explicit. In > other words, to get the meaning you desire above, the existing operators > can be used: âRequires-Python: >=3, <4â. Yes, so that: Requires-Python: 1,2,3 means python versions 1,2 or 3. Requires-Python: 3 means requires python 3 only. Any version of 3 Whereas: Requires-Python: 3.0, 3.1 means only 3.0 and 3.1 Requires-Python: 2.3, 2.4, 2.5, 2.6 That means, those particular versions. A user can still try to install on other versions. But they would get a warning and would do so at their own risk. There's no need for extra operator characters as far as I can see. The comma method proposed originally seemed to do everything. David ___ 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] Disallow float arguments where an integer is expected in Python 2.7.
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. ___ 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 345 : Metadata for Python Software Packages 1.2
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 ___ 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 345 : Metadata for Python Software Packages 1.2
>> 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 ___ 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 345 : Metadata for Python Software Packages 1.2
-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 tsea...@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- ___ 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 345 : Metadata for Python Software Packages 1.2
david.l...@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 ___ 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 345 : Metadata for Python Software Packages 1.2
-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 tsea...@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- ___ 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 345 : Metadata for Python Software Packages 1.2
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.
___
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 345 : Metadata for Python Software Packages 1.2
david.l...@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. ___ 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 345 : Metadata for Python Software Packages 1.2
> 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. ___ 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 345 : Metadata for Python Software Packages 1.2
> david.l...@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. > ___ 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
