On 26 February 2013 03:22, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Feb 26, 2013 at 11:06 AM, Donald Stufft donald.stu...@gmail.com
wrote:
!=1.3 allowing 1.3.1 makes sense to me. 1.3 is equivalent to 1.3.0,
1.3.1 !=
1.3.0.
Nope, the PEP explicitly disclaims the historical
On Tuesday, February 26, 2013 at 7:08 AM, Michael Foord wrote:
On 26 February 2013 03:22, Nick Coghlan ncogh...@gmail.com
(mailto:ncogh...@gmail.com) wrote:
On Tue, Feb 26, 2013 at 11:06 AM, Donald Stufft donald.stu...@gmail.com
(mailto:donald.stu...@gmail.com) wrote:
!=1.3 allowing
On Tue, Feb 26, 2013 at 10:08 PM, Michael Foord fuzzy...@gmail.com wrote:
The current tools are strict with regards to equality - and in dependency
pinning I would see it as *surprising* that specifying ==1.3 installs some
version that isn't precisely 1.3. Having == mean approximately-equal,
On Tuesday, February 26, 2013 at 8:17 AM, Nick Coghlan wrote:
I *don't* like the idea of (== 1.3) and (== 1.3.0) being equivalent
when (1.3) and (1.3.0) are substantially different, though. Instead,
I'll reinstate a variant of the commentary from PEP 386 that pointed
out the value of always
On Tue, Feb 26, 2013 at 8:17 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Feb 26, 2013 at 10:08 PM, Michael Foord fuzzy...@gmail.com
wrote:
The current tools are strict with regards to equality - and in dependency
pinning I would see it as *surprising* that specifying ==1.3 installs
On Tue, Feb 26, 2013 at 5:23 AM, Donald Stufft donald.stu...@gmail.com wrote:
On Tuesday, February 26, 2013 at 8:17 AM, Nick Coghlan wrote:
I *don't* like the idea of (== 1.3) and (== 1.3.0) being equivalent
when (1.3) and (1.3.0) are substantially different, though. Instead,
I'll reinstate a
On Tue, Feb 26, 2013 at 11:23 PM, Donald Stufft donald.stu...@gmail.com wrote:
On Tuesday, February 26, 2013 at 8:17 AM, Nick Coghlan wrote:
I *don't* like the idea of (== 1.3) and (== 1.3.0) being equivalent
when (1.3) and (1.3.0) are substantially different, though. Instead,
I'll reinstate
On Tuesday, February 26, 2013 at 10:10 AM, Nick Coghlan wrote:
Remember, part of the goals of both PEP 386 and PEP 426 is to tighten
up cases where setuptools is considered too permissive, because it's
guessing in the face of ambiguity. Trailing zeroes should be
considered implied when
On Tue, Feb 26, 2013 at 11:01 AM, Donald Stufft donald.stu...@gmail.comwrote:
On Tuesday, February 26, 2013 at 10:10 AM, Nick Coghlan wrote:
Remember, part of the goals of both PEP 386 and PEP 426 is to tighten
up cases where setuptools is considered too permissive, because it's
guessing in
On Tuesday, February 26, 2013 at 11:07 AM, Daniel Holth wrote:
On Tue, Feb 26, 2013 at 11:01 AM, Donald Stufft donald.stu...@gmail.com
(mailto:donald.stu...@gmail.com) wrote:
On Tuesday, February 26, 2013 at 10:10 AM, Nick Coghlan wrote:
Remember, part of the goals of both PEP 386 and PEP
On Wed, Feb 27, 2013 at 2:07 AM, Daniel Holth dho...@gmail.com wrote:
With prefix equals would the following evaluate to true?
1.4 == 1 == 1.3.1
I guess that's the other advantage of the wildcard notation - it makes
it very clear something special is going on :)
For the .0 expansion, I like
On Tue, Feb 26, 2013 at 8:01 AM, Donald Stufft donald.stu...@gmail.com wrote:
On Tuesday, February 26, 2013 at 10:10 AM, Nick Coghlan wrote:
Remember, part of the goals of both PEP 386 and PEP 426 is to tighten
up cases where setuptools is considered too permissive, because it's
guessing in
On Tue, Feb 26, 2013 at 2:53 PM, Chris Jerdonek
chris.jerdo...@gmail.com wrote:
On Tue, Feb 26, 2013 at 8:01 AM, Donald Stufft donald.stu...@gmail.com
wrote:
On Tuesday, February 26, 2013 at 10:10 AM, Nick Coghlan wrote:
Remember, part of the goals of both PEP 386 and PEP 426 is to tighten
On Tuesday, February 26, 2013 at 2:53 PM, Chris Jerdonek wrote:
On Tue, Feb 26, 2013 at 8:01 AM, Donald Stufft donald.stu...@gmail.com
(mailto:donald.stu...@gmail.com) wrote:
On Tuesday, February 26, 2013 at 10:10 AM, Nick Coghlan wrote:
Remember, part of the goals of both PEP 386 and
On Tuesday, February 26, 2013 at 2:53 PM, Chris Jerdonek wrote:
On Tue, Feb 26, 2013 at 8:01 AM, Donald Stufft donald.stu...@gmail.com
(mailto:donald.stu...@gmail.com) wrote:
On Tuesday, February 26, 2013 at 10:10 AM, Nick Coghlan wrote:
Remember, part of the goals of both PEP 386 and
On Tue, Feb 26, 2013 at 2:08 PM, Donald Stufft donald.stu...@gmail.com wrote:
In [45]: l = [x for x in releases if any([y for y in x[1].split(.) if
y.startswith(0) and y.isdigit() and not y.endswith(0)])]
In [46]: len(l)
Out[46]: 1162
Note this doesn't check if they have confusing versions,
On Tuesday, February 26, 2013 at 7:06 PM, Chris Jerdonek wrote:
On Tue, Feb 26, 2013 at 2:08 PM, Donald Stufft donald.stu...@gmail.com
(mailto:donald.stu...@gmail.com) wrote:
In [45]: l = [x for x in releases if any([y for y in x[1].split(.) if
y.startswith(0) and y.isdigit() and not
On 02/23/2013 08:08 PM, Nick Coghlan wrote:
On Sun, Feb 24, 2013 at 4:43 AM, Daniel Holth dho...@gmail.com wrote:
There simply must be a way to spell equals that means equals. It will be
used when that so-called security release broke my application that
integrates said library in a way that
We have a potential solution from node which is to allow limited globs in
version matches 1.0.*
On Feb 25, 2013 3:04 PM, Carl Meyer c...@oddbird.net wrote:
On 02/23/2013 08:08 PM, Nick Coghlan wrote:
On Sun, Feb 24, 2013 at 4:43 AM, Daniel Holth dho...@gmail.com wrote:
There simply must be a
I realised globbing won't work easily, due to alpha/beta/release candidates
missing the preceding dot, so 1.1.1.* wouldn't match versions like 1.1.1c1,
while leaving the dot out would mean 1.1.1* matching versions like 1.1.11
(it also means the old PEP 345 default behaviour and the current ==
On Saturday, February 23, 2013 at 10:08 PM, Nick Coghlan wrote:
The core problem with making == strict is that it either makes !=
useless by allowing (!=1.3) to match 1.3.1, or it breaks the
invariant that != is the logical inverse of ==, by having both
(==1.3) and (!=1.3) reject 1.3.1. I
On Tue, Feb 26, 2013 at 11:06 AM, Donald Stufft donald.stu...@gmail.com wrote:
!=1.3 allowing 1.3.1 makes sense to me. 1.3 is equivalent to 1.3.0, 1.3.1 !=
1.3.0.
Nope, the PEP explicitly disclaims the historical equivalence between
1.3 and 1.3.0. It has to, because they're very different when
On Sat, Feb 23, 2013 at 10:23 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Feb 24, 2013 at 12:57 AM, Vinay Sajip vinay_sa...@yahoo.co.uk
wrote:
Nick Coghlan ncoghlan at gmail.com writes:
Daniel is a fan of this syntax, but I think it is inferior to the
implied approach, so don't
Requirements specifiers have never been valid Python syntax; note the
unquoted version strings. Environment markers are different
and do not compare distribution versions.
Sorry, you're right - I was conflating the two.
Regards,
Vinay Sajip
___
On Sun, Feb 24, 2013 at 4:43 AM, Daniel Holth dho...@gmail.com wrote:
There simply must be a way to spell equals that means equals. It will be
used when that so-called security release broke my application that
integrates said library in a way that doesn't even expose the flaw.
Plone depends
25 matches
Mail list logo
