On Fri, Apr 29, 2011 at 4:26 PM, Eli Bendersky wrote:
>>> On Thu, Apr 28, 2011 at 04:20:06PM +0200, Éric Araujo wrote:
>> The kind of race condition which can happen here is if an attacker
>> creates "targetpath" between os.path.exists and os.unlink. Whether it
>> is an exploitable flaw would need
Ben Finney wrote:
Steven D'Aprano writes:
Robert Kern wrote:
On 4/28/11 8:44 PM, Steven D'Aprano wrote:
The real question should be, why does Python treat all NANs as
signalling NANs instead of quiet NANs? I don't believe this helps
anyone.
Actually, Python treats all NaNs as quiet NaNs and
On Thu, Apr 28, 2011 at 11:10 PM, Stefan Behnel wrote:
> M.-A. Lemburg, 28.04.2011 22:23:
>>
>> Stefan Behnel wrote:
>>>
>>> DasIch, 28.04.2011 20:55:
the CPython
benchmarks have an extensive set of microbenchmarks in the pybench
package
>>>
>>> Try not to care too much about p
On Fri, Apr 29, 2011 at 3:28 PM, Steven D'Aprano wrote:
> Robert Kern wrote:
>> Actually, Python treats all NaNs as quiet NaNs and never signalling NaNs.
>
> Sorry, did I get that backwards? I thought it was signalling NANs that cause
> a signal (in Python terms, an exception)?
>
> If I do x = 0.0
Steven D'Aprano writes:
> Robert Kern wrote:
> > On 4/28/11 8:44 PM, Steven D'Aprano wrote:
> >> The real question should be, why does Python treat all NANs as
> >> signalling NANs instead of quiet NANs? I don't believe this helps
> >> anyone.
> >
> > Actually, Python treats all NaNs as quiet NaN
>> On Thu, Apr 28, 2011 at 04:20:06PM +0200, Éric Araujo wrote:
>> > > if hasattr(os, "symlink") and hasattr(os, "link"):
>> > > # For systems that support symbolic and hard links.
>> > > if tarinfo.issym():
>> > > + if os.path.exists(targetpath):
>
Robert Kern wrote:
On 4/28/11 8:44 PM, Steven D'Aprano wrote:
Greg Ewing wrote:
Taking a step back from all this, why does Python allow
NaNs to arise from computations *at all*?
The real question should be, why does Python treat all NANs as
signalling NANs
instead of quiet NANs? I don't bel
Steven D'Aprano writes:
> (I grant that Alexander is an exception -- I understand that he does do
> a lot of numeric work, and does come across NANs, and still doesn't like
> them one bit.)
I don't think I'd want anybody who *likes* NaNs to have a commit bit
at python.org.
__
Tarek Ziadé writes:
> On Thu, Apr 28, 2011 at 5:26 PM, Barry Warsaw wrote:
> > BTW, I think it always helps to have a really good assert message, and/or a
> > leading comment to explain *why* that condition can't possibly happen.
>
> why bother, it can't happen ;)
Except before breakfast,
On 4/28/11 8:44 PM, Steven D'Aprano wrote:
Greg Ewing wrote:
Taking a step back from all this, why does Python allow
NaNs to arise from computations *at all*?
The real question should be, why does Python treat all NANs as signalling NANs
instead of quiet NANs? I don't believe this helps anyone
Greg Ewing wrote:
Taking a step back from all this, why does Python allow
NaNs to arise from computations *at all*?
The real question should be, why does Python treat all NANs as
signalling NANs instead of quiet NANs? I don't believe this helps anyone.
+Inf and -Inf are arguably useful elem
Nick Coghlan wrote:
1. IEEE754 is a value-based system, with a finite number of distinct
NaN payloads
2. Python is an object-based system. In addition to their payload, NaN
objects are further distinguished by their identity (infinite in
theory, in practice limited by available memory).
I argu
On Fri, Apr 29, 2011 at 11:11 AM, Ben Finney wrote:
> Would it make sense for ‘NaN’ to be another instance of ‘NoneType’?
This is fine IHMO as I (personally) find myself doing things like:
if x is None:
...
cheers
James
--
-- James Mills
--
-- "Problems are solved by method"
_
Taking a step back from all this, why does Python allow
NaNs to arise from computations *at all*?
+Inf and -Inf are arguably useful elements of the algebra,
yet Python insists on raising an exception for 1.0./0.0
instead of returning an infinity.
Why do this but not raise an exception for any op
Terry Reedy writes:
> On 4/28/2011 4:40 AM, Mark Shannon wrote:
> > NaN does not have to be a float or a Decimal.
> > Perhaps it should have its own class.
>
> Like None
Would it make sense for ‘NaN’ to be another instance of ‘NoneType’?
--
\ “I am too firm in my consciousness of the mar
Nick Coghlan wrote:
I hadn't really thought about it that way before this discussion - it
is the identity checking behaviour of the builtin containers that lets
us sensibly handle cases like sets of NumPy arrays.
Except that it doesn't:
>>> from numpy import array
>>> a1 = array([1,2])
>>> a2
On 4/28/11 6:13 PM, Guido van Rossum wrote:
On Thu, Apr 28, 2011 at 4:04 PM, Nick Coghlan wrote:
On Fri, Apr 29, 2011 at 8:55 AM, Guido van Rossum wrote:
Sorry, we'll have to make an exception for those of course. This will
somewhat complicate the interpretation of well-behaved, because those
Terry Reedy wrote:
I think the committee goofed -- badly. Statisticians used missing value
indicators long before the committee existed. They has no problem
thinking that the indicator, as an object, equaled itself. So one could
write (and I often did through the 1980s) the equivalent of
for
On Thu, Apr 28, 2011 at 5:24 PM, Glenn Linderman wrote:
> Would it be reasonable to implement 3 types of containers:
That's something for python-ideas. Occasionally containers that use
custom comparisons come in handy (e.g. case-insensitive dicts).
--
--Guido van Rossum (python.org/~guido)
On 4/28/2011 4:40 PM, Nick Coghlan wrote:
Hmm, true. And things like count() and index() would still be
thoroughly broken for sequences. OK, so scratch that idea - there's
simply no sane way to handle such objects without using an
identity-based container that ignores equality definitions altoget
On Thu, Apr 28, 2011 at 7:47 PM, Guido van Rossum wrote:
> On Thu, Apr 28, 2011 at 4:40 PM, Nick Coghlan wrote:
>> Pondering the NaN problem further, I think we can relatively easily
>> argue that reflexive behaviour at the object level fits within the
>> scope of IEEE754.
>
> Now we're talking.
On Thu, Apr 28, 2011 at 4:40 PM, Nick Coghlan wrote:
> Pondering the NaN problem further, I think we can relatively easily
> argue that reflexive behaviour at the object level fits within the
> scope of IEEE754.
Now we're talking. :-)
> 1. IEEE754 is a value-based system, with a finite number of
On Fri, Apr 29, 2011 at 9:13 AM, Guido van Rossum wrote:
>> I hadn't really thought about it that way before this discussion - it
>> is the identity checking behaviour of the builtin containers that lets
>> us sensibly handle cases like sets of NumPy arrays.
>
> But do they? For non-empty arrays,
On Thu, Apr 28, 2011 at 4:04 PM, Nick Coghlan wrote:
> On Fri, Apr 29, 2011 at 8:55 AM, Guido van Rossum wrote:
>> Sorry, we'll have to make an exception for those of course. This will
>> somewhat complicate the interpretation of well-behaved, because those
>> are *not* well-behaved as far as con
On Fri, Apr 29, 2011 at 2:55 AM, Guido van Rossum wrote:
> Raymond strongly believes that containers must be allowed to use the
> modified definition, I believe purely for performance reasons.
> (Without this rule, a list or tuple could not even cut short being
> compared to *itself*.) It seems yo
2011/4/28 Raymond Hettinger :
> It might be nice if there were a pragma or module variable to selectively
> enable asserts for a given test module so that -O would turn-off asserts in
> the production code but leave them on in a test_suite.
from __future__ import perfect_code_so_no_asserts
:)
On Fri, Apr 29, 2011 at 8:55 AM, Guido van Rossum wrote:
> Sorry, we'll have to make an exception for those of course. This will
> somewhat complicate the interpretation of well-behaved, because those
> are *not* well-behaved as far as containers go (both dict key lookup
> and list membership are
On Thu, Apr 28, 2011 at 3:22 PM, Robert Kern wrote:
> On 4/28/11 11:55 AM, Guido van Rossum wrote:
>
>> On Thu, Apr 28, 2011 at 8:52 AM, Robert Kern
>> wrote:
>>>
>>> Smaller, certainly. But now it's a trilemma. :-)
>>>
>>> 1. Have just np.float64 and np.complex128 scalars follow the Python float
On Fri, Apr 29, 2011 at 5:51 AM, Raymond Hettinger
wrote:
> * x = obj implies x == obj # assignment really works
While I agree with your point of view regarding the status quo as a
useful, practical compromise, I need to call out that particular
example:
>>> nan = float('nan')
>>> x = nan
>>>
On Apr 28, 2011, at 3:07 PM, Guido van Rossum wrote:
> On Thu, Apr 28, 2011 at 2:53 PM, Raymond Hettinger
> wrote:
>>
>> On Apr 28, 2011, at 1:27 PM, Holger Krekel wrote:
>>
>>> On Thu, Apr 28, 2011 at 6:59 PM, Guido van Rossum wrote:
On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé
On 4/28/11 11:55 AM, Guido van Rossum wrote:
On Thu, Apr 28, 2011 at 8:52 AM, Robert Kern wrote:
Smaller, certainly. But now it's a trilemma. :-)
1. Have just np.float64 and np.complex128 scalars follow the Python float
semantics since they subclass Python float and complex, respectively.
2.
On Thu, Apr 28, 2011 at 2:53 PM, Raymond Hettinger
wrote:
>
> On Apr 28, 2011, at 1:27 PM, Holger Krekel wrote:
>
>> On Thu, Apr 28, 2011 at 6:59 PM, Guido van Rossum wrote:
>>> On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé wrote:
In my opinion assert should be avoided completely anywhere e
On Apr 28, 2011, at 1:27 PM, Holger Krekel wrote:
> On Thu, Apr 28, 2011 at 6:59 PM, Guido van Rossum wrote:
>> On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé wrote:
>>> In my opinion assert should be avoided completely anywhere else than
>>> in the tests. If this is a wrong statement, please le
On Thu, Apr 28, 2011 at 1:48 PM, Terry Reedy wrote:
> On 4/28/2011 12:55 PM, Guido van Rossum wrote:
>
>> *If* my proposal gets accepted, there will be a blanket rule that no
>> matter how exotic an type's __eq__ is defined, self.__eq__(self)
>> (i.e., __eq__ called with the same *object* argument
M.-A. Lemburg, 28.04.2011 22:23:
Stefan Behnel wrote:
DasIch, 28.04.2011 20:55:
the CPython
benchmarks have an extensive set of microbenchmarks in the pybench
package
Try not to care too much about pybench. There is some value in it, but
some of its microbenchmarks are also tied to CPython's
On 4/28/11 3:27 PM, Holger Krekel wrote:
On Thu, Apr 28, 2011 at 6:59 PM, Guido van Rossum wrote:
On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé wrote:
In my opinion assert should be avoided completely anywhere else than
in the tests. If this is a wrong statement, please let me know why :)
I
On 4/28/2011 11:22 AM, s...@pobox.com wrote:
Barry> I would agree. Use asserts for "this can't possibly happen
Barry> " conditions.
Without looking, I suspect that's probably what the author thought he was
doing.
You wish: to repeat the example from threading:
def __init__(se
On 4/28/2011 12:55 PM, Guido van Rossum wrote:
*If* my proposal gets accepted, there will be a blanket rule that no
matter how exotic an type's __eq__ is defined, self.__eq__(self)
(i.e., __eq__ called with the same *object* argument) must return True
if the type's __eq__ is to be considered wel
On Thu, Apr 28, 2011 at 6:59 PM, Guido van Rossum wrote:
> On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé wrote:
>> In my opinion assert should be avoided completely anywhere else than
>> in the tests. If this is a wrong statement, please let me know why :)
>
> I would turn that around. The assert
Stefan Behnel wrote:
> DasIch, 28.04.2011 20:55:
>> the CPython
>> benchmarks have an extensive set of microbenchmarks in the pybench
>> package
>
> Try not to care too much about pybench. There is some value in it, but
> some of its microbenchmarks are also tied to CPython's interpreter
> behavio
On Thu, Apr 28, 2011 at 9:51 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
> Personally, I think the status quo is fine
> and that practicality is beating purity.
>
+1
>
> Raymond
>
cheers
lvh
___
Python-Dev mailing list
Python-Dev@pyth
On 4/28/2011 4:40 AM, Mark Shannon wrote:
NaN is *not* a number (the clue is in the name).
The problem is that the committee itself did not believe or stay
consistent with that. In the text of the draft, they apparently refer to
Nan as an indefinite, unspecified *number*. Sort of like a rand
ISTM there is no right or wrong answer.
There is just a question of what is most useful.
AFAICT, the code for dictionaries (and therefore the code for sets)
has always had identity-implies-equality logic. It makes dicts
blindingly fast for common cases. It also confers some nice
properties like
DasIch, 28.04.2011 20:55:
the CPython
benchmarks have an extensive set of microbenchmarks in the pybench
package
Try not to care too much about pybench. There is some value in it, but some
of its microbenchmarks are also tied to CPython's interpreter behaviour.
For example, the benchmarks for
On 4/28/2011 6:11 AM, Nick Coghlan wrote:
On Thu, Apr 28, 2011 at 6:30 PM, Alexander Belopolsky
wrote:
On Thu, Apr 28, 2011 at 3:57 AM, Nick Coghlan wrote:
..
It is an interesting question of what "sane invariants" are. Why you
consider the invariants that you listed essential while say
if
Éric Araujo wrote:
> Hi,
>
> > But what I would like to know, is if is there any reason why XML-RPC can't
> > optionally work over TLS/SSL using Python's ssl module. I'll create a
> > ticket, and send a patch, but I was wondering if it was a reason why this
> > was not implemented.
>
> I think
Hello,
As announced in my GSoC proposal I'd like to announce which benchmarks
I'll use for the benchmark suite I will work on this summer.
As of now there are two benchmark suites (that I know of) which
receive some sort of attention, those are the ones developed as part
of the PyPy project[1] whi
On 28/04/2011 18:26, Steven D'Aprano wrote:
Rob Cliffe wrote:
To me the idea of non-reflexive equality (an object not being equal
to itself) is abhorrent. Nothing is more likely to put off new
Python users if they happen to run into it.
I believe that's a gross exaggeration. In any case, th
On Thu, Apr 28, 2011 at 1:25 PM, Steven D'Aprano wrote:
..
> But it's perfectly fine to do this:
>
sum(a)
> nan
>
This use case reminded me Kahan's
"""
Were there no way to get rid of NaNs, they would be as useless as
Indefinites on CRAYs; as soon as one were encountered, computation
would
On Apr 28, 2011, at 12:59 PM, Guido van Rossum wrote:
> On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé wrote:
>> In my opinion assert should be avoided completely anywhere else than
>> in the tests. If this is a wrong statement, please let me know why :)
>
> I would turn that around. The assert
Steven D'Aprano wrote:
I know thousands of words have been spilled on this, including many by
myself, but I really believe this discussion is mostly bike-shedding.
Hmmm... on reflection, I think I may have been a bit unfair. In
particular, I don't mean any slight on any of the people who hav
Guido van Rossum wrote:
*If* my proposal gets accepted, there will be a blanket rule that no
matter how exotic an type's __eq__ is defined, self.__eq__(self)
(i.e., __eq__ called with the same *object* argument) must return True
if the type's __eq__ is to be considered well-behaved; and Python
c
Rob Cliffe wrote:
To me the idea of non-reflexive equality (an object not being equal to
itself) is abhorrent. Nothing is more likely to put off new Python
users if they happen to run into it.
I believe that's a gross exaggeration. In any case, that's just your
opinion, and Python is hardly
Alexander Belopolsky wrote:
With the status quo in Python, it may only make sense to store NaNs in
array.array, but not in a list.
That's a bit extreme. It only gets you into trouble if you reason like this:
>>> a = b = [1, 2, 3, float('nan')]
>>> if a == b:
... for x,y in zip(a,b):
...
On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé wrote:
> In my opinion assert should be avoided completely anywhere else than
> in the tests. If this is a wrong statement, please let me know why :)
I would turn that around. The assert statement should not be used in
unit tests; unit tests should us
[This is a mega-reply, combining responses to several messages in this
thread. I may be repeating myself a bit, but I think I am being
consistent. :-)]
On Wed, Apr 27, 2011 at 10:12 PM, Nick Coghlan wrote:
> On Thu, Apr 28, 2011 at 2:54 PM, Guido van Rossum wrote:
>>> Well, I didn't say that. I
Mark Shannon wrote:
Steven D'Aprano wrote:
Mark Shannon wrote:
Related to the discussion on "Not a Number" can I point out a few
things that have not be explicitly addressed so far.
The IEEE standard is about hardware and bit patterns, rather than
types and values so may not be entirely appr
On 28/04/2011 15:58, Steven D'Aprano wrote:
Fundamentally, the problem is that some containers bypass equality
tests for identity tests. There may be good reasons for that shortcut,
but it leads to problems with *any* object that does not define
equality to be reflexive, not just NANs.
I say y
Steven D'Aprano wrote:
Mark Shannon wrote:
Related to the discussion on "Not a Number" can I point out a few things
that have not be explicitly addressed so far.
The IEEE standard is about hardware and bit patterns, rather than types
and values so may not be entirely appropriate for high-leve
On 4/28/11 12:37 AM, Alexander Belopolsky wrote:
On Thu, Apr 28, 2011 at 12:33 AM, Robert Kern wrote:
On 2011-04-27 23:24 , Guido van Rossum wrote:
..
So do new masks get created when the outcome of an elementwise
operation is a NaN?
No.
Yes.
from MA import array
print array([0])/array(
On 4/27/11 11:54 PM, Guido van Rossum wrote:
On Wed, Apr 27, 2011 at 9:25 PM, Robert Kern wrote:
On 2011-04-27 23:01 , Guido van Rossum wrote:
And I wouldn't want to change that. It sounds like NumPy wouldn't be
much affected if we were to change this (which I'm not saying we
would).
Well, I
On Thu, Apr 28, 2011 at 5:26 PM, Barry Warsaw wrote:
> On Apr 28, 2011, at 10:22 AM, s...@pobox.com wrote:
>
>> Barry> I would agree. Use asserts for "this can't possibly happen
>> Barry> " conditions.
>>
>>Without looking, I suspect that's probably what the author thought he was
>>doing.
>
On Thu, Apr 28, 2011 at 4:44 PM, Senthil Kumaran wrote:
> On Thu, Apr 28, 2011 at 04:20:06PM +0200, Éric Araujo wrote:
>> > if hasattr(os, "symlink") and hasattr(os, "link"):
>> > # For systems that support symbolic and hard links.
>> > if tarinfo.issym():
>> > +
On Thu, 28 Apr 2011 22:44:50 +0800
Senthil Kumaran wrote:
> On Thu, Apr 28, 2011 at 04:20:06PM +0200, Éric Araujo wrote:
> > > if hasattr(os, "symlink") and hasattr(os, "link"):
> > > # For systems that support symbolic and hard links.
> > > if tarinfo.issym():
>
On Apr 28, 2011, at 11:04 AM, Fred Drake wrote:
>On Thu, Apr 28, 2011 at 10:37 AM, Barry Warsaw wrote:
>> I would agree. Use asserts for "this can't possibly happen "
>> conditions.
>
>Maybe we should rename "assert" to "wink", just to be clear on the usage. :-)
Off to python-ideas for you!
On Apr 28, 2011, at 10:22 AM, s...@pobox.com wrote:
>Barry> I would agree. Use asserts for "this can't possibly happen
>Barry> " conditions.
>
>Without looking, I suspect that's probably what the author thought he was
>doing.
BTW, I think it always helps to have a really good assert mess
Barry> I would agree. Use asserts for "this can't possibly happen
Barry> " conditions.
Without looking, I suspect that's probably what the author thought he was
doing.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
On Thu, Apr 28, 2011 at 10:37 AM, Barry Warsaw wrote:
> I would agree. Use asserts for "this can't possibly happen "
> conditions.
Maybe we should rename "assert" to "wink", just to be clear on the usage. :-)
-Fred
--
Fred L. Drake, Jr.
"Give me the luxuries of life and I will willing
Mark Shannon wrote:
Related to the discussion on "Not a Number" can I point out a few things
that have not be explicitly addressed so far.
The IEEE standard is about hardware and bit patterns, rather than types
and values so may not be entirely appropriate for high-level language
like Python.
On Thu, Apr 28, 2011 at 04:20:06PM +0200, Éric Araujo wrote:
> > if hasattr(os, "symlink") and hasattr(os, "link"):
> > # For systems that support symbolic and hard links.
> > if tarinfo.issym():
> > +if os.path.exists(targetpath):
> > +
On Apr 28, 2011, at 04:34 AM, Terry Reedy wrote:
>On 4/28/2011 3:54 AM, Tarek Ziadé wrote:
>> Hello
>>
>> I removed some assert calls in distutils some time ago because the
>> package was not behaving correctly when people were using Python with
>> the --optimize flag. In other words, assert becam
Hi,
> http://hg.python.org/cpython/rev/5185e1d91f3d
> user:Vinay Sajip
> summary:
> Refined time test in test_logging.
> +ZERO = datetime.timedelta(0)
> +
> +class UTC(datetime.tzinfo):
> +def utcoffset(self, dt):
> +return ZERO
> +
> +dst = utcoffset
> +
> +def tzn
Hi,
> http://hg.python.org/cpython/rev/57c076ab4bbd
> user:Łukasz Langa
> --- a/Lib/test/test_cfgparser.py
> +++ b/Lib/test/test_cfgparser.py
> @@ -20,10 +20,16 @@
> def values(self):
> return [i[1] for i in self.items()]
>
> -def iteritems(self): return iter(self.ite
Hi,
I’m still educating myself about concurrency and race conditions, so I
hope my naïve question won’t be just a waste of time. Here it is:
> http://hg.python.org/cpython/rev/0c8bc3a0130a
> user:Senthil Kumaran
> summary:
> Fix closes issue10761: tarfile.extractall failure when sym
Hi,
>> I'm at the point where to appreciably increase coverage, I'd need to write
>> some
>> test servers to exercise client code in SocketHandler, DatagramHandler and
>> HTTPHandler.
>>
>> I notice there are no utility classes in test.support to help with this kind
>> of
>> thing - would there
Hi,
> But what I would like to know, is if is there any reason why XML-RPC can't
> optionally work over TLS/SSL using Python's ssl module. I'll create a
> ticket, and send a patch, but I was wondering if it was a reason why this
> was not implemented.
I think there’s no deeper reason than nobody
I am not a specialist in this area (although I call myself a
mathematician). But they say that sometimes the outsider sees most of
the game, or more likely that sometimes the idiot's point of view is useful.
To me the idea of non-reflexive equality (an object not being equal to
itself) is abh
On Thu, 28 Apr 2011 09:54:23 +0200
Tarek Ziadé wrote:
>
> I have seen some other places where thing would simply break with -O.
>
> Am I right thinking we should do a pass on those and remove them or
> turn them into exception that are triggered with -O as well ?
Agreed. Argument checking shoul
2011/4/27 Vinay Sajip :
> I've been recently trying to improve the test coverage for the logging
> package,
> and have got to a not unreasonable point:
>
> logging/__init__.py 99% (96%)
> logging/config.py 89% (85%)
> logging/handlers.py 60% (54%)
>
> where the figures in parentheses include branc
On Thu, Apr 28, 2011 at 12:27 PM, Michael Foord
wrote:
> On 28/04/2011 09:34, Terry Reedy wrote:
>>
>> On 4/28/2011 3:54 AM, Tarek Ziadé wrote:
>>>
>>> Hello
>>>
>>> I removed some assert calls in distutils some time ago because the
>>> package was not behaving correctly when people were using Pyt
On Thu, 28 Apr 2011 07:23:43 + (UTC)
Vinay Sajip wrote:
> Nick Coghlan gmail.com> writes:
>
> > If you poke around in the test directory a bit, you may find there is
> > already some code along these lines in other tests (e.g. I'm pretty
> > sure the urllib tests already fire up a local ser
On Thu, 28 Apr 2011 07:23:43 + (UTC)
Vinay Sajip wrote:
> Nick Coghlan gmail.com> writes:
>
> > If you poke around in the test directory a bit, you may find there is
> > already some code along these lines in other tests (e.g. I'm pretty
> > sure the urllib tests already fire up a local ser
On Thu, Apr 28, 2011 at 7:17 PM, Greg Ewing wrote:
> Mark Shannon wrote:
>
>> NaN does not have to be a float or a Decimal.
>> Perhaps it should have its own class.
>
> Perhaps, but that wouldn't solve anything on its own. If
> this new class compares reflexively, then it still violates
> IEE754.
On 28/04/2011 09:34, Terry Reedy wrote:
On 4/28/2011 3:54 AM, Tarek Ziadé wrote:
Hello
I removed some assert calls in distutils some time ago because the
package was not behaving correctly when people were using Python with
the --optimize flag. In other words, assert became a full part of the
c
On Thu, Apr 28, 2011 at 7:10 PM, Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> Because this assertion is an assertion about the behaviour of
>> comparisons that violates IEEE754, while the assertions I list are all
>> assertions about the behaviour of containers that can be made true
>> *regardless
On Thu, Apr 28, 2011 at 6:30 PM, Alexander Belopolsky
wrote:
> On Thu, Apr 28, 2011 at 3:57 AM, Nick Coghlan wrote:
> ..
>>> It is an interesting question of what "sane invariants" are. Why you
>>> consider the invariants that you listed essential while say
>>>
>>> if c1 == c2:
>>> assert all(
Mark Shannon wrote:
NaN does not have to be a float or a Decimal.
Perhaps it should have its own class.
Perhaps, but that wouldn't solve anything on its own. If
this new class compares reflexively, then it still violates
IEE754. Conversely, existing NaNs could be made to compare
reflexively wi
Nick Coghlan wrote:
Because this assertion is an assertion about the behaviour of
comparisons that violates IEEE754, while the assertions I list are all
assertions about the behaviour of containers that can be made true
*regardless* of IEEE754 by checking identity explicitly.
Aren't you making
Related to the discussion on "Not a Number" can I point out a few things
that have not be explicitly addressed so far.
The IEEE standard is about hardware and bit patterns, rather than types
and values so may not be entirely appropriate for high-level language
like Python.
NaN is *not* a numb
On 4/28/2011 12:32 AM, Nick Coghlan wrote:
On Thu, Apr 28, 2011 at 5:27 PM, Glenn Linderman wrote:
Without having read the original articulations by Raymond or any discussions
of the pros and cons,
In my first post to this thread, I pointed out the bug tracker item
(http://bugs.python.org/iss
On 4/28/2011 3:54 AM, Tarek Ziadé wrote:
Hello
I removed some assert calls in distutils some time ago because the
package was not behaving correctly when people were using Python with
the --optimize flag. In other words, assert became a full part of the
code logic and removing them via -O was ch
On Thu, Apr 28, 2011 at 3:57 AM, Nick Coghlan wrote:
..
>> It is an interesting question of what "sane invariants" are. Why you
>> consider the invariants that you listed essential while say
>>
>> if c1 == c2:
>> assert all(x == y for x,y in zip(c1, c2))
>>
>> optional?
>
> Because this asserti
On 04/28/2011 04:31 AM, Stephen J. Turnbull wrote:
Are you saying you would expect that
nan = float('nan')
a = [1, ..., 499, nan, 501, ..., 999]# meta-ellipsis, not Ellipsis
a == a
False
??
I would expect l1 == l2, where l1 and l2 are both lists, to be
semantically equivalent to len
On Thu, Apr 28, 2011 at 5:30 PM, Alexander Belopolsky
wrote:
> On Thu, Apr 28, 2011 at 2:54 AM, Nick Coghlan wrote:
> ..
>> No, as Raymond has articulated a number of times over the years, it's
>> a property of the equivalence relation that is needed in order to
>> present sane invariants to user
Hello
I removed some assert calls in distutils some time ago because the
package was not behaving correctly when people were using Python with
the --optimize flag. In other words, assert became a full part of the
code logic and removing them via -O was changing the behavior.
In my opinion assert
On Thu, Apr 28, 2011 at 5:27 PM, Glenn Linderman wrote:
> Without having read the original articulations by Raymond or any discussions
> of the pros and cons,
In my first post to this thread, I pointed out the bug tracker item
(http://bugs.python.org/issue4296) that included the discussion of
re
On Thu, Apr 28, 2011 at 2:54 AM, Nick Coghlan wrote:
..
> No, as Raymond has articulated a number of times over the years, it's
> a property of the equivalence relation that is needed in order to
> present sane invariants to users of the container. I included in the
> bug report the critical invar
On 4/27/2011 11:54 PM, Nick Coghlan wrote:
On Thu, Apr 28, 2011 at 4:20 PM, Glenn Linderman wrote:
In that bug, Nick, you mention that reflexive equality is something that
container classes rely on in their implementation. Such reliance seems to
me to be a bug, or an inappropriate optimization
Nick Coghlan gmail.com> writes:
> If you poke around in the test directory a bit, you may find there is
> already some code along these lines in other tests (e.g. I'm pretty
> sure the urllib tests already fire up a local server). Starting down
> the path of standardisation of that test functiona
99 matches
Mail list logo
