Rustom Mody wrote:
On Friday, March 6, 2015 at 10:13:55 PM UTC+5:30, Steven D'Aprano wrote:
Rustom Mody wrote:
On Friday, March 6, 2015 at 3:57:12 AM UTC+5:30, rand...@fastmail.us
wrote:
It's been brought up on Stack Overflow that the in operator (on
tuples, and by my testing on dict
On Saturday, March 7, 2015 at 5:04:02 AM UTC+5:30, Steven D'Aprano wrote:
Rustom Mody wrote:
On Friday, March 6, 2015 at 10:13:55 PM UTC+5:30, Steven D'Aprano wrote:
Rustom Mody wrote:
On Friday, March 6, 2015 at 3:57:12 AM UTC+5:30, rand...@fastmail.us
wrote:
It's been brought
On Friday, March 6, 2015 at 3:57:12 AM UTC+5:30, rand...@fastmail.us wrote:
It's been brought up on Stack Overflow that the in operator (on
tuples, and by my testing on dict and list, as well as dict lookup) uses
object identity as a shortcut, and returns true immediately if the
object being
On 2015-03-06, Chris Angelico ros...@gmail.com wrote:
On Fri, Mar 6, 2015 at 8:50 PM, Rustom Mody rustompm...@gmail.com wrote:
In a language like python with decent exceptions we do not need nans.
Not so. I could perhaps accept that we don't need signalling NaNs, as
they can be replaced with
Rustom Mody wrote:
On Friday, March 6, 2015 at 3:57:12 AM UTC+5:30, rand...@fastmail.us
wrote:
It's been brought up on Stack Overflow that the in operator (on
tuples, and by my testing on dict and list, as well as dict lookup) uses
object identity as a shortcut, and returns true immediately
random...@fastmail.us wrote:
On Thu, Mar 5, 2015, at 22:49, Chris Angelico wrote:
I'm not sure it's just an optimization. Compare this post from
python-dev, where Nick Coghlan discusses the same topic:
https://mail.python.org/pipermail/python-dev/2014-July/135476.html
If it is a bug for
On Friday, March 6, 2015 at 10:13:55 PM UTC+5:30, Steven D'Aprano wrote:
Rustom Mody wrote:
On Friday, March 6, 2015 at 3:57:12 AM UTC+5:30, rand...@fastmail.us
wrote:
It's been brought up on Stack Overflow that the in operator (on
tuples, and by my testing on dict and list, as well as
Rustom Mody wrote:
On Friday, March 6, 2015 at 3:31:58 PM UTC+5:30, Chris Angelico wrote:
On Fri, Mar 6, 2015 at 8:50 PM, Rustom Mody wrote:
In a language like python with decent exceptions we do not need nans.
Not so. I could perhaps accept that we don't need signalling NaNs, as
they
On Sat, Mar 7, 2015 at 4:04 AM, Rustom Mody rustompm...@gmail.com wrote:
You dont grok your theory of computation very well do you?
def foo(x): return x + x
def bar(x): return x + x
def baz(x): return 2*x
One can imagine an implementation where
id(foo) == id(bar)
[I am assuming that id is
On Fri, Mar 6, 2015 at 8:50 PM, Rustom Mody rustompm...@gmail.com wrote:
In a language like python with decent exceptions we do not need nans.
Not so. I could perhaps accept that we don't need signalling NaNs, as
they can be replaced with exceptions, but quiet NaNs are by definition
_not_
On Friday, March 6, 2015 at 3:31:58 PM UTC+5:30, Chris Angelico wrote:
On Fri, Mar 6, 2015 at 8:50 PM, Rustom Mody wrote:
In a language like python with decent exceptions we do not need nans.
Not so. I could perhaps accept that we don't need signalling NaNs, as
they can be replaced with
On 03/06/2015 10:04 AM, Rustom Mody wrote:
On Friday, March 6, 2015 at 10:29:19 PM UTC+5:30, Steven D'Aprano wrote:
def inverse(x):
return 1.0/x
There's an exception there, waiting to bite. If I include inverse() in some
complex calculation:
def function(x, y):
return
On Friday, March 6, 2015 at 10:29:19 PM UTC+5:30, Steven D'Aprano wrote:
Rustom Mody wrote:
On Friday, March 6, 2015 at 3:31:58 PM UTC+5:30, Chris Angelico wrote:
On Fri, Mar 6, 2015 at 8:50 PM, Rustom Mody wrote:
In a language like python with decent exceptions we do not need nans.
On Friday, March 6, 2015 at 10:48:07 PM UTC+5:30, Chris Angelico wrote:
On Sat, Mar 7, 2015 at 4:04 AM, Rustom Mody wrote:
You dont grok your theory of computation very well do you?
def foo(x): return x + x
def bar(x): return x + x
def baz(x): return 2*x
One can imagine an
It's been brought up on Stack Overflow that the in operator (on
tuples, and by my testing on dict and list, as well as dict lookup) uses
object identity as a shortcut, and returns true immediately if the
object being tested *is* an element of the container. However, the
contains operation does not
On Fri, Mar 6, 2015 at 10:27 AM, sohcahto...@gmail.com wrote:
Do you have an example of where `a is b` but `a != b` in Python? `None ==
None` is True.
Check out the subject line.
nan = float(nan)
nan is nan # obviously
True
nan != nan # IEEE 754 mandates
True
ChrisA
--
On Fri, Mar 6, 2015 at 10:11 AM, sohcahto...@gmail.com wrote:
I would argue that if `a is b` then it is obvious that `a == b`
This is not true for float(nan), though. The question is, is your
above statement a valid optimization for the 'in' operator, or not?
And no, it isn't, because it's not
sohcahto...@gmail.com writes:
I would argue that if `a is b` then it is obvious that `a == b`
It may be obvious, but it's not necessarily true. Some commonly-used
values – for example, an “null” – are not equal to themselves, by
definition.
It is fine to define such a type in Python, because
sohcahto...@gmail.com writes:
On Thursday, March 5, 2015 at 3:20:16 PM UTC-8, Ben Finney wrote:
It is fine to define such a type in Python, because 'is' does not
necessarily imply '=='.
Do you have an example of where `a is b` but `a != b` in Python?
Maybe I misunderstand your question,
Nothing about nans is 'correct'. They are a CS invention
On 3/5/2015 5:26 PM, random...@fastmail.us wrote:
It's been brought up on Stack Overflow that the in operator (on
tuples, and by my testing on dict and list, as well as dict lookup) uses
object identity as a shortcut, and returns true
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
Since reflexivity is *almost* universal, and using object identity
permits very substantial optimizations, the core developers agreed
that built-in contain types may assume that `x is y` implies `x == y`.
Users of NANs and other
On Thursday, March 5, 2015 at 2:27:12 PM UTC-8, rand...@fastmail.us wrote:
It's been brought up on Stack Overflow that the in operator (on
tuples, and by my testing on dict and list, as well as dict lookup) uses
object identity as a shortcut, and returns true immediately if the
object being
On Thursday, March 5, 2015 at 3:20:16 PM UTC-8, Ben Finney wrote:
sohcahto...@gmail.com writes:
I would argue that if `a is b` then it is obvious that `a == b`
It may be obvious, but it's not necessarily true. Some commonly-used
values - for example, an null - are not equal to themselves,
Ethan Furman et...@stoneleaf.us writes:
On 03/05/2015 06:55 PM, Ben Finney wrote:
class NullType(object):
A type whose value never equals any other.
This type's values will behave correctly when tested for
membership in a collection::
random...@fastmail.us wrote:
It's been brought up on Stack Overflow that the in operator (on
tuples, and by my testing on dict and list, as well as dict lookup) uses
object identity as a shortcut, and returns true immediately if the
object being tested *is* an element of the container.
On 03/05/2015 06:55 PM, Ben Finney wrote:
class NullType(object):
A type whose value never equals any other.
This type's values will behave correctly when tested for
membership in a collection::
foo = NullType()
bar
On 03/05/2015 07:26 PM, Ben Finney wrote:
Ethan Furman et...@stoneleaf.us writes:
On 03/05/2015 06:55 PM, Ben Finney wrote:
class NullType(object):
A type whose value never equals any other.
This type's values will behave correctly when tested for
On Fri, Mar 6, 2015 at 2:26 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Isn't the point at issue that the Python interpreter *may* optimise by
assuming ‘is implies equality’, so the ‘in’ operator can fail if that
assumption is false?
I thought the problem was that types with custom
On Thu, Mar 5, 2015, at 22:49, Chris Angelico wrote:
I'm not sure it's just an optimization. Compare this post from
python-dev, where Nick Coghlan discusses the same topic:
https://mail.python.org/pipermail/python-dev/2014-July/135476.html
If it is a bug for NaN to infect containers'
On 06/03/2015 04:37, random...@fastmail.us wrote:
On Thu, Mar 5, 2015, at 22:49, Chris Angelico wrote:
I'm not sure it's just an optimization. Compare this post from
python-dev, where Nick Coghlan discusses the same topic:
https://mail.python.org/pipermail/python-dev/2014-July/135476.html
If
30 matches
Mail list logo
