Hi Stephen,
> BTW, *all* of the Python applications I really care about make a point
> of specifying a range of versions they work with (or bundle a
> particular version).
Yes, well that was my point exactly.
If opinion is against commas, then we can take them out.
That would give us something
On Mon, Dec 28, 2009 at 7:39 AM, Lennart Regebro wrote:
> On Mon, Dec 28, 2009 at 05:37, Terry Reedy wrote:
>> If the first x.y release were called x.y.0, (does not sys.version include
>> 0?) then x.y would unambiguously mean the series.
>
> Yeah, well, although sys.version includes the zero, not
On Mon, Dec 28, 2009 at 6:20 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Tarek Ziadé wrote:
>> On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar
>> wrote:
>> [..]
>>> Tarek,
>>>
>>> I am a bit confused at the current proposal combined with the newly
>>> introduc
On Mon, Dec 28, 2009 at 6:16 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Terry Reedy wrote:
>> On 12/27/2009 7:48 PM, Antoine Pitrou wrote:
>>> Tarek Ziadé gmail.com> writes:
This was ambiguous because it was unclear, as MvL stated, if "2.5"
was just "
On Mon, Dec 28, 2009 at 3:03 AM, MRAB wrote:
> Martin v. Löwis wrote:
>>>
>>> No application developer will quickly figure out what a tilde means.
>>> Maybe
>>> it means 'roughly', but it requires too much thought and is ambiguous.
>>> 2.5
>>> is not roughly 2.5.2. It is the same exactly.
>>>
>>>
david.l...@preisshare.net wrote:
>>> No application developer will quickly figure out what a tilde means.
>>> Maybe
>>> it means 'roughly', but it requires too much thought and is ambiguous.
>>> 2.5
>>> is not roughly 2.5.2. It is the same exactly.
>>>
>>> Before we had : Requires-Python: 2.5, 2.6
Antoine Pitrou writes:
>
> > And in fact this case is often more the important one. Packages that
> > depend on having a *recent* version of python will often crash
> > quickly, before doing permanent damage, when an undefined syntax,
> > function, or method is invoked, while packages that d
On Mon, Dec 28, 2009 at 4:17 AM, Stephen J. Turnbull wrote:
> Ben Finney writes:
>
> > Instead, the default should be `=='. That is, `Requires-Python: 3'
> > should be equivalent to `Requires-Python: ==3'; and only "3" or "3.0" or
> > "3.0.0" etc. will match. I maintain that is what most people
Tarek Ziadé writes:
> What happened is that Martin came late in the discussions in
> Distutils-SIG after I've forwarded the final mail in Catalog-SIG and
> after I did send it here (the mail where I said "Here's the mail I'll
> send to python-dev for PEP 345, if anyone sees a problem or something
> Does that mean we should add "or"?
>
> Requires-Python: 2.5 or 2.6
It would be redundant to have it, since you can also write
Requires-Python: >=2.5, <2.7
> Should we also use "and" instead of ","?
>
> Requires-Python: >= 2.5 and < 2.6
Perhaps. I think the Linux packaging formats u
> 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
> he
On Mon, Dec 28, 2009 at 10:23 AM, Ben Finney wrote:
[..]
>> So, if no one object, I propose to continue this thread about the way
>> range should be compared, to see if we meet a consensus quite soon. If
>> not, I guess we can go back to distutils-SIG and invite people over
>> there, as we did for
> 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 me
> Point of order: what is the point of sending the discussion off to the
> distutils SIG if we are just going to bikeshed it (again!) here.
Bike-shedding it here is indeed inappropriate. If the PEP had listed all
possible arguments that can come up in this discussion, and the
corresponding counte
> I think Antoine's proposal is good (using the range when "2.5" is
> used, and using 2.5.0 when explicitely
> needed), and fixes Martin's concerns.
>
> So I would be in favor of removing ~= and using Antoine's rule;
So specifying 2.5 would be a short-hand for *what*?
Regards,
Martin
___
2009/12/28 "Martin v. Löwis" :
>> I think Antoine's proposal is good (using the range when "2.5" is
>> used, and using 2.5.0 when explicitely
>> needed), and fixes Martin's concerns.
>>
>> So I would be in favor of removing ~= and using Antoine's rule;
>
> So specifying 2.5 would be a short-hand fo
Another penny dropped when it comes to version specs.
Should 2.5 mean 2.5.0 only, or 2.5.*. Well... why would you ever need
to specify 2.5.0 only. That's a nonsense specification.
"My project requires Python 2.5.0, but doesn't work with 2.5.1". Huh!?
Well, then fix it, goofball. :)
2.5 can mean
Hi Len,
> Another penny dropped when it comes to version specs.
Pennies are good. They build value.
> With examples being:
>
> Requires-Python: [2.5.2:3]; [3.1:]
What about going even more simple...
Requires-Python: 2.5..3 3.1..
If we use double-dots to replace colons, the ..
will transl
On Mon, Dec 28, 2009 at 11:21 AM, Lennart Regebro wrote:
> Another penny dropped when it comes to version specs.
>
> Should 2.5 mean 2.5.0 only, or 2.5.*. Well... why would you ever need
> to specify 2.5.0 only. That's a nonsense specification.
>
> "My project requires Python 2.5.0, but doesn't wo
>> So specifying 2.5 would be a short-hand for *what*?
>
> 2.5 would be a shorthand for 2.5.x. So, equivalent to : >=2.5.0, < 2.6.0
Ok, so it's not a shorthand for a single operator anymore, but for a
more complex term. Fine with me.
> 2.5.0 would be the notation required to describe this specif
> Another penny dropped when it comes to version specs.
>
> Should 2.5 mean 2.5.0 only, or 2.5.*. Well... why would you ever need
> to specify 2.5.0 only. That's a nonsense specification.
>
> "My project requires Python 2.5.0, but doesn't work with 2.5.1". Huh!?
> Well, then fix it, goofball. :)
On Mon, Dec 28, 2009 at 11:27, wrote:
> What about going even more simple...
>
> Requires-Python: 2.5..3 3.1..
Doh! Of course. Works for me. In fact, the dots could be dashes as well.
Requires-Python: 2.5-3 3.1-
Commas, spaces, semicolons, whatever. We could allow:
Requires-Python: 2.5-3 3.1-
2009/12/28 "Martin v. Löwis" :
[..]
>> 2.5.0 would be the notation required to describe this specific micro version.
>
> I think it would be a shorthand for >=2.5.0, <2.5.1, right?
>
> Or are you saying that specifying a version is sometimes a shorthand for
> a range, and sometimes a shorthand for
On Mon, Dec 28, 2009 at 11:54, "Martin v. Löwis" wrote:
> This == operator is fairly common in Debian. For example, the apache2
> package installed on my system specifies
Oh, absolutely, but that's when you specify interdependencies between
packages. Nobody makes a Python package for generic use
On Mon, Dec 28, 2009 at 11:57 AM, Lennart Regebro wrote:
> On Mon, Dec 28, 2009 at 11:27, wrote:
>> What about going even more simple...
>>
>> Requires-Python: 2.5..3 3.1..
>
> Doh! Of course. Works for me. In fact, the dots could be dashes as well.
>
> Requires-Python: 2.5-3 3.1-
>
> Commas, sp
On 12/28/2009 5:42 AM, Martin v. Löwis wrote:
>>> So specifying 2.5 would be a short-hand for *what*?
>>
>> 2.5 would be a shorthand for 2.5.x. So, equivalent to : >=2.5.0, < 2.6.0
>
> Ok, so it's not a shorthand for a single operator anymore, but for a
> more complex term. Fine with me.
>
>> 2.5
On Mon, Dec 28, 2009 at 12:02, Tarek Ziadé wrote:
> -1. This looks like typos the developer made on his versions definitions.
Nah.
> And if not, is subject to errors by forgetting dashes or dots.
Eh, yeah but that goes for ANY syntax.
Having the same syntax as for package specifications does m
On Mon, Dec 28, 2009 at 12:04 PM, Lennart Regebro wrote:
> On Mon, Dec 28, 2009 at 12:02, Tarek Ziadé wrote:
>> -1. This looks like typos the developer made on his versions definitions.
>
> Nah.
>
>> And if not, is subject to errors by forgetting dashes or dots.
>
> Eh, yeah but that goes for ANY
On Mon, Dec 28, 2009 at 12:02 PM, Lennart Regebro wrote:
> On Mon, Dec 28, 2009 at 11:54, "Martin v. Löwis" wrote:
>> This == operator is fairly common in Debian. For example, the apache2
>> package installed on my system specifies
>
> Oh, absolutely, but that's when you specify interdependencies
Lennart Regebro writes:
> On Mon, Dec 28, 2009 at 11:54, "Martin v. Löwis" wrote:
> > This == operator is fairly common in Debian. For example, the
> > apache2 package installed on my system specifies
>
> Oh, absolutely, but that's when you specify interdependencies between
> packages. Nobody ma
> > How can they know that they depend on "a quirk in behaviour of an older
> > version" if a newer version hasn't been released? This sounds bogus.
>
> Of course a newer version has been released. Who said it hasn't been?
> Eg, the discussion of <=2.5. Hasn't 2.6 been released? Or am I
> ha
Antoine Pitrou writes:
>
> > > How can they know that they depend on "a quirk in behaviour of an older
> > > version" if a newer version hasn't been released? This sounds bogus.
> >
> > Of course a newer version has been released. Who said it hasn't been?
> > Eg, the discussion of <=2.5.
2009/12/28 "Martin v. Löwis" :
>
>> Does that mean we should add "or"?
>>
>> Requires-Python: 2.5 or 2.6
>
> It would be redundant to have it, since you can also write
>
> Requires-Python: >=2.5, <2.7
>
>> Should we also use "and" instead of ","?
>>
>> Requires-Python: >= 2.5 and < 2.6
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tarek Ziadé wrote:
> 2009/12/28 "Martin v. Löwis" :
>>> I think Antoine's proposal is good (using the range when "2.5" is
>>> used, and using 2.5.0 when explicitely
>>> needed), and fixes Martin's concerns.
>>>
>>> So I would be in favor of removing ~=
On Mon, 28 Dec 2009 10:42:20 +0100, "Martin v. Löwis"
wrote:
> On distutils-sig, a vocal fraction seems to think otherwise. From my
> short interaction there, I now think that comparison operators are
> indeed hard to use, and that the concept of a half-open interval,
> and how you can use relatio
On 28/12/2009 22:57, David Lyon wrote:
On Mon, 28 Dec 2009 10:42:20 +0100, "Martin v. Löwis"
wrote:
On distutils-sig, a vocal fraction seems to think otherwise. From my
short interaction there, I now think that comparison operators are
indeed hard to use, and that the concept of a half-open
On Mon, 28 Dec 2009 23:07:32 +, Michael Foord
wrote:
>>> Requires-Python: 2.5:2.7
>>
>> Specifies a range of python versions.
>>
> So this would work for Python 2.7 but *not* 2.7.1? Or does 2.7
> implicitly mean a range of all Python 2.7 versions?
Yes. 2.7 would mean all 2.7 version
David Lyon preisshare.net> writes:
>
> Requires a particular python version.
>
> > Requires-Python: 2.5:2.7
Why not drop ranges as well as operators and simply use commas?
The above would be rewritten as:
Requires-Python: 2.5, 2.6, 2.7
This would prevent the ambiguity on the inclusive or ex
Antoine Pitrou wrote:
David Lyon preisshare.net> writes:
Requires a particular python version.
> Requires-Python: 2.5:2.7
Why not drop ranges as well as operators and simply use commas?
The above would be rewritten as:
Requires-Python: 2.5, 2.6, 2.7
This would prevent the ambiguity on th
On Mon, 28 Dec 2009 23:21:54 +, Antoine Pitrou wrote:
> David Lyon preisshare.net> writes:
> >
> > Requires a particular python version.
> >
> > > Requires-Python: 2.5:2.7
>
> Why not drop ranges as well as operators and simply use commas?
> The above would be rewritten as:
>
> Requires
R. David Murray bitdance.com> writes:
>
> > Why not drop ranges as well as operators and simply use commas?
> > The above would be rewritten as:
> >
> > Requires-Python: 2.5, 2.6, 2.7
> >
> > This would prevent the ambiguity on the inclusive or exclusive nature
of the
> > upper bound of the r
On Mon, 28 Dec 2009 23:21:54 + (UTC), Antoine Pitrou
wrote:
>> > Requires-Python: 2.5:2.7
>
> Why not drop ranges as well as operators and simply use commas?
> The above would be rewritten as:
>
> Requires-Python: 2.5, 2.6, 2.7
Firstly, I find your notation proposition to be entirely wor
On Mon, 28 Dec 2009 18:55:17 -0500, "R. David Murray"
wrote:
> What about specifying that the package works only with, say, 2.6.2 or
> earlier (because of some problem introduced by 2.6.3)? That could get
> pretty darn verbose. (Also remember we aren't just talking about the
> syntax for Python
David Lyon writes:
> The counter argument for 'cloning' the linux packaging system is that
> most of the representations come from a C perspective. Because of the
> fact that Linux is predominantly a C product.
>
> Since Python isn't C, and doesn't come from C, then one could argue
> that using s
On Mon, Dec 28, 2009 at 9:26 PM, Tres Seaver wrote:
[..]
>> Requires-Dist: zope.interface (3.1.0) ==> only 3.1.0
>
> For completeness, isn't this really "any versino which starts with
> 3.1.0, not including post- or pre- releases"? That particular pacakge
> doesn't use more than a third version
On Dec 28, 2009, at 8:00 PM, Ben Finney wrote:
> The dependency declarations are *not* Python language syntax, and there
> is no need to consider Python language syntax in defining them.
Agreed.
We're also not going to be writing an operating system with them; just simple
version range state
David Lyon wrote:
On Mon, 28 Dec 2009 23:07:32 +, Michael Foord
wrote:
> Requires-Python: 2.5:2.7
Specifies a range of python versions.
So this would work for Python 2.7 but *not* 2.7.1? Or does 2.7
implicitly mean a range of all Python 2.7 versions?
Yes. 2.7 would
On Tue, Dec 29, 2009 at 2:17 AM, sstein...@gmail.com
wrote:
>
> On Dec 28, 2009, at 8:00 PM, Ben Finney wrote:
>
>> The dependency declarations are *not* Python language syntax, and there
>> is no need to consider Python language syntax in defining them.
>
> Agreed.
>
> We're also not going to be
On Dec 28, 2009, at 8:35 PM, Tarek Ziadé wrote:
> On Tue, Dec 29, 2009 at 2:17 AM, sstein...@gmail.com
> wrote:
>>
>> On Dec 28, 2009, at 8:00 PM, Ben Finney wrote:
>>
>>> The dependency declarations are *not* Python language syntax, and there
>>> is no need to consider Python language syntax
Tarek Ziadé writes:
> I am now rewriting the relevant section of the PEP with the examples
> we discussed in this thread, but the operators should stay the same as
> they were initially: "<", ">", "<=", ">=", "==" and "!=".
Thank you, this is the clear and simple path and keeps the dependency
de
On Tue, 29 Dec 2009 12:00:50 +1100, Ben Finney
wrote:
> The dependency declarations are *not* Python language syntax, and there
> is no need to consider Python language syntax in defining them.
Well I don't know how you can say that if it is python developers
to which all this effort is targeted
51 matches
Mail list logo
