In article <7xvckq4c2j@ruckus.brouhaha.com>,
Paul Rubin wrote:
>Kiuhnm writes:
>> I can't think of a single case where 'is' is ill-defined.
>
>If I can't predict the output of
>
>print (20+30 is 30+20) # check whether addition is commutative
>print (20*30 is 30*20) # check whether
On 4/28/2012 4:47 AM, Kiuhnm wrote:
On 4/27/2012 17:39, Adam Skutt wrote:
On Apr 27, 8:07 am, Kiuhnm wrote:
Useful... maybe, conceptually sound... no.
Conceptually, NaN is the class of all elements which are not numbers,
therefore NaN = NaN.
NaN isn't really the class of all elements which ar
On 4/28/2012 16:18, Adam Skutt wrote:
On Apr 28, 7:26 am, Kiuhnm wrote:
On 4/27/2012 19:15, Adam Skutt wrote:
On Apr 27, 11:01 am, Kiuhnmwrote:
The abstraction is this:
- There are primitives and objects.
- Primitives are not objects. The converse is also true.
- Primitives can become obj
Adam Skutt wrote:
>> You can't treat id() as an address. Did you miss my post when I
>> demonstrated that Jython returns IDs generated on demand, starting
>> from 1? In general, there is *no way even in principle* to go from
>> a Python ID to the memory location (address) of the object with
>> tha
On Apr 28, 7:26 am, Kiuhnm wrote:
> On 4/27/2012 19:15, Adam Skutt wrote:
> > On Apr 27, 11:01 am, Kiuhnm wrote:
> >> The abstraction is this:
> >> - There are primitives and objects.
> >> - Primitives are not objects. The converse is also true.
> >> - Primitives can become objects (boxing).
> >>
On 4/27/2012 17:39, Adam Skutt wrote:
On Apr 27, 8:07 am, Kiuhnm wrote:
Useful... maybe, conceptually sound... no.
Conceptually, NaN is the class of all elements which are not numbers,
therefore NaN = NaN.
NaN isn't really the class of all elements which aren't numbers. NaN
is the result of
On Sat, Apr 28, 2012 at 9:26 PM, Kiuhnm
wrote:
> Your problem is that you think that copy semantics requires real copying. I
> really don't see any technical difficulty in virtualizing the all thing.
"Copy semantics" without "real copying" is an optimization that a
program should never need to be
On 4/27/2012 19:15, Adam Skutt wrote:
On Apr 27, 11:01 am, Kiuhnm wrote:
On 4/27/2012 1:57, Adam Skutt wrote:
On Apr 26, 6:34 pm, Kiuhnmwrote:
If you
understand that your 'a' is not really an object but a reference to it,
everything becomes clear and you see that '==' always do the same
On Apr 27, 2:40 pm, Steven D'Aprano wrote:
> On Fri, 27 Apr 2012 10:33:34 -0700, Adam Skutt wrote:
> >> Why should the caller care whether they are dealing with a singleton
> >> object or an unspecified number of Borg objects all sharing state? A
> >> clever interpreter could make many Borg instan
On Fri, 27 Apr 2012 10:33:34 -0700, Adam Skutt wrote:
>> Why should the caller care whether they are dealing with a singleton
>> object or an unspecified number of Borg objects all sharing state? A
>> clever interpreter could make many Borg instances appear to be a
>> singleton. A really clever on
> > I have spent some time searching for a bug in my code, it was due to
> > different work of "is" with () and []:
> () is ()
> > True
> [] is []
> > False
> >
> > (Python 2.7.2+ (default, Oct 4 2011, 20:03:08)
> > [GCC 4.6.1] )
> >
> > Is this what it should be or maybe yielding unifie
On Sat, Apr 28, 2012 at 3:51 AM, Adam Skutt wrote:
> Yes, there is a way. You add a function deref() to the language. In
> CPython, that simply treats the passed value as a memory address and
> treats it as an object, perhaps with an optional check. In Jython,
> it'd access a global table of nu
On Fri, Apr 27, 2012 at 11:38 AM, Chris Angelico wrote:
> On Sat, Apr 28, 2012 at 3:33 AM, Adam Skutt wrote:
>> I think you misunderstood me. Define a Borg class where somehow
>> identity is the same for all instances. Inherit from that class and
>> add per-instance members. Now, identity can'
On Apr 27, 1:06 pm, Steven D'Aprano wrote:
> On Thu, 26 Apr 2012 04:42:36 -0700, Adam Skutt wrote:
> > On Apr 26, 5:10 am, Steven D'Aprano > +comp.lang.pyt...@pearwood.info> wrote:
> >> But I was actually referring to something more fundamental than that.
> >> The statement "a is b" is a *direct*
On Fri, Apr 27, 2012 at 11:33 AM, Adam Skutt wrote:
> On Apr 27, 12:56 pm, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> On Thu, 26 Apr 2012 04:42:36 -0700, Adam Skutt wrote:
>> > You're going to have to explain the value of an "ID" that's not 1:1 with
>> > an object's identity, for
On Apr 27, 1:12 pm, Steven D'Aprano wrote:
> On Thu, 26 Apr 2012 04:42:36 -0700, Adam Skutt wrote:
> > On Apr 26, 5:10 am, Steven D'Aprano > +comp.lang.pyt...@pearwood.info> wrote:
> >> Solution to *what problem*?
>
> > This confusion that many people have over what 'is' does, including
> > yours
On Fri, 27 Apr 2012 10:15:32 -0700, Adam Skutt wrote:
> If I write a program in Python that treats variables as if they were
> values, it will be incorrect.
I'm sorry, it is unclear to me what distinction you are making between
variables and values. Can you give simple examples of both incorrect
On Sat, Apr 28, 2012 at 3:33 AM, Adam Skutt wrote:
> I think you misunderstood me. Define a Borg class where somehow
> identity is the same for all instances. Inherit from that class and
> add per-instance members. Now, identity can't be the same for all
> instances. As a result, you've just v
On Apr 27, 12:56 pm, Steven D'Aprano wrote:
> On Thu, 26 Apr 2012 04:42:36 -0700, Adam Skutt wrote:
> > You're going to have to explain the value of an "ID" that's not 1:1 with
> > an object's identity, for at least the object's lifecycle, for a
> > programmer. If you can't come up with a useful
Steven, your posts are leaking out of their respective thread(s). Is
this intentional?
~Temia
--
When on earth, do as the earthlings do.
--
http://mail.python.org/mailman/listinfo/python-list
On Apr 27, 11:01 am, Kiuhnm wrote:
> On 4/27/2012 1:57, Adam Skutt wrote:
> > On Apr 26, 6:34 pm, Kiuhnm wrote:
> >>> If you
> >> understand that your 'a' is not really an object but a reference to it,
> >> everything becomes clear and you see that '==' always do the same thing.
>
> > Yes, object
On Thu, 26 Apr 2012 04:42:36 -0700, Adam Skutt wrote:
> On Apr 26, 5:10 am, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> Solution to *what problem*?
>>
> This confusion that many people have over what 'is' does, including
> yourself.
I have no confusion over what "is" does. The "i
On Thu, 26 Apr 2012 04:42:36 -0700, Adam Skutt wrote:
> On Apr 26, 5:10 am, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> But I was actually referring to something more fundamental than that.
>> The statement "a is b" is a *direct* statement of identity. "John is my
>> father." "id(
Adam Skutt wrote:
[ ... ]
> In the real world, if we were doing the math with pen and paper, we'd
> stop as soon as we hit such an error. Equality is simply not defined
> for the operations that can produce NaN, because we don't know to
> perform those computations. So no, it doesn't conceptually
On Thu, 26 Apr 2012 04:42:36 -0700, Adam Skutt wrote:
> You're going to have to explain the value of an "ID" that's not 1:1 with
> an object's identity, for at least the object's lifecycle, for a
> programmer. If you can't come up with a useful case, then you haven't
> said anything of merit.
I
On Fri, Apr 27, 2012 at 9:39 AM, Adam Skutt wrote:
> On Apr 27, 8:07 am, Kiuhnm wrote:
>> Useful... maybe, conceptually sound... no.
>> Conceptually, NaN is the class of all elements which are not numbers,
>> therefore NaN = NaN.
>
> NaN isn't really the class of all elements which aren't numbers
On Apr 27, 8:07 am, Kiuhnm wrote:
> Useful... maybe, conceptually sound... no.
> Conceptually, NaN is the class of all elements which are not numbers,
> therefore NaN = NaN.
NaN isn't really the class of all elements which aren't numbers. NaN
is the result of a few specific IEEE 754 operations t
On 4/27/2012 16:07, Steven D'Aprano wrote:
On Fri, 27 Apr 2012 14:17:48 +0200, Kiuhnm wrote:
Define your terms: what do you mean by "equal"?
a and b are equal iff
Nope. What I meant is that we can talk of equality whenever...
a = a
a = b => b = a
a = b and b = c => a = c
If some of this
On 4/27/2012 1:57, Adam Skutt wrote:
On Apr 26, 6:34 pm, Kiuhnm wrote:
On 4/26/2012 20:54, Adam Skutt wrote:
On Apr 26, 12:02 pm, Kiuhnmwrote:
On 4/26/2012 16:00, Adam Skutt wrote:
On Apr 26, 9:37 am, Kiuhnm wrote:
The fact that you think that that's "differing behaviour" is what ma
On Fri, 27 Apr 2012 14:17:48 +0200, Kiuhnm wrote:
>>> Define your terms: what do you mean by "equal"?
>>
>> a and b are equal iff
>
> Nope. What I meant is that we can talk of equality whenever...
>
>> a = a
>> a = b => b = a
>> a = b and b = c => a = c
>> If some of this properties are violated
On 4/27/2012 14:07, Kiuhnm wrote:
On 4/27/2012 13:09, Steven D'Aprano wrote:
On Thu, 26 Apr 2012 18:02:31 +0200, Kiuhnm wrote:
On 4/26/2012 16:00, Adam Skutt wrote:
C# and Python do have a misfeature: '==' is identity comparison only if
operator== / __eq__ is not overloaded. Identity comparis
On Fri, Apr 27, 2012 at 10:07 PM, Kiuhnm
wrote:
> Conceptually, NaN is the class of all elements which are not numbers,
> therefore NaN = NaN. The conceptually correct way would be to check for
> 'NaN' explicitly.
Conceptually, "single-digit-numbers" is the class of all elements
which are integer
On 4/27/2012 13:09, Steven D'Aprano wrote:
On Thu, 26 Apr 2012 18:02:31 +0200, Kiuhnm wrote:
On 4/26/2012 16:00, Adam Skutt wrote:
C# and Python do have a misfeature: '==' is identity comparison only if
operator== / __eq__ is not overloaded. Identity comparison and value
comparison are disjoi
On Thu, 26 Apr 2012 11:31:39 -0700, John Nagle wrote:
> I would suggest that "is" raise ValueError for the ambiguous cases.
> If both operands are immutable, "is" should raise ValueError. That's the
> case where the internal representation of immutables shows through.
You've already made this
On 4/27/12 12:07 AM, Paul Rubin wrote:
Nobody writes:
All practical languages have some implementation-defined behaviour, often
far more problematic than Python's.
The usual reason for accepting implementation-defined behavior is to
enable low-level efficiency hacks written for specific machi
On Thu, 26 Apr 2012 18:02:31 +0200, Kiuhnm wrote:
> On 4/26/2012 16:00, Adam Skutt wrote:
>> C# and Python do have a misfeature: '==' is identity comparison only if
>> operator== / __eq__ is not overloaded. Identity comparison and value
>> comparison are disjoint operations, so it's entirely inap
On Apr 26, 10:56 pm, "OKB (not okblacke)"
wrote:
> Adam Skutt wrote:
> > If I write a function that does a value comparison, then it should
> > do value comparison on _every type that can be passed to it_,
> > regardless of whether the type is a primitive or an object, whether
> > it has value or
Steven D'Aprano writes:
> I'm seeing code generated by the Haskell GHC compiler being 2-4 times
> slower than code from the C gcc compiler, and on average using 2-3 times
> as much memory (and as much as 7 times).
Alioth isn't such a great comparison, because on the one hand you get
very carefu
On Fri, Apr 27, 2012 at 12:47 PM, Steven D'Aprano
wrote:
> On Thu, 26 Apr 2012 17:16:10 -0700, Adam Skutt wrote:
>
>> On Apr 26, 7:33 pm, Steven D'Aprano > +comp.lang.pyt...@pearwood.info> wrote:
>>> On Thu, 26 Apr 2012 12:22:55 -0700, Adam Skutt wrote:
>>> > I often wonder what the world would be
On Thu, Apr 26, 2012 at 7:33 PM, Steven D'Aprano
wrote:
> On Thu, 26 Apr 2012 12:22:55 -0700, Adam Skutt wrote:
>
>> I often wonder what the world would be like if Python, C#, and Java
>> embraced value types more, and had better support for pure functions.
>
> They would be slower, require more m
Adam Skutt wrote:
> If I write a function that does a value comparison, then it should
> do value comparison on _every type that can be passed to it_,
> regardless of whether the type is a primitive or an object, whether
> it has value or reference semantics, and regardless of how value
> compari
On Thu, 26 Apr 2012 17:16:10 -0700, Adam Skutt wrote:
> On Apr 26, 7:33 pm, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> On Thu, 26 Apr 2012 12:22:55 -0700, Adam Skutt wrote:
>> > I often wonder what the world would be like if Python, C#, and Java
>> > embraced value types more, and
On 27/04/2012 00:57, Adam Skutt wrote:
...And Saint Adam Skutt raised the hand grenade up on high, saying, "O
LORD, bless this Thy hand grenade that with it Thou mayest blow Thine Id
to tiny bits, in Thy mercy." And the LORD did grin and the people did
feast upon the lambs and sloths and carp
Adam Skutt writes:
>> harder to use, and far, far less popular.
> Alas, these two are probably true.
Haskell is kind of abstruse and has a notoriously steep learning curve,
as it's mostly meant as a research testbed and as a playground for
language geeks. ML/OCaml is by all accounts much easier,
On Apr 26, 7:33 pm, Steven D'Aprano wrote:
> On Thu, 26 Apr 2012 12:22:55 -0700, Adam Skutt wrote:
> > I often wonder what the world would be like if Python, C#, and Java
> > embraced value types more, and had better support for pure functions.
>
> They would be slower, require more memory,
Funny
On Thu, Apr 26, 2012 at 5:39 PM, Ian Kelly wrote:
> On Thu, Apr 26, 2012 at 1:34 PM, Adam Skutt wrote:
>> What I think you want is what I said above: ValueError raised when
>> either operand is a /temporary/ object. Really, it should probably be
>> a parse-time error, since you could (and should
On Thu, Apr 26, 2012 at 12:05 PM, Evan Driscoll wrote:
> This thread has already beaten a dead horse enough that the horse came back
> as a zombie and was re-killed, but I couldn't help but respond to this part:
>
>
> On 01/-10/-28163 01:59 PM, Adam Skutt wrote:
>>
>> Code that relies on the ident
On Apr 26, 6:34 pm, Kiuhnm wrote:
> On 4/26/2012 20:54, Adam Skutt wrote:
> > On Apr 26, 12:02 pm, Kiuhnm wrote:
> >> On 4/26/2012 16:00, Adam Skutt wrote:
> >>> On Apr 26, 9:37 am, Kiuhnm wrote:
> >> The fact that you think that that's "differing behaviour" is what makes
> >> it a misfeature.
On 20/04/2012 20:10, dmitrey wrote:
I have spent some time searching for a bug in my code, it was due to
different work of "is" with () and []:
() is ()
True
[] is []
False
(Python 2.7.2+ (default, Oct 4 2011, 20:03:08)
[GCC 4.6.1] )
Is this what it should be or maybe yielding unified resu
On Thu, 26 Apr 2012 12:22:55 -0700, Adam Skutt wrote:
> I often wonder what the world would be like if Python, C#, and Java
> embraced value types more, and had better support for pure functions.
They would be slower, require more memory, harder to use, and far, far
less popular. Some other lang
Nobody writes:
> All practical languages have some implementation-defined behaviour, often
> far more problematic than Python's.
The usual reason for accepting implementation-defined behavior is to
enable low-level efficiency hacks written for specific machines. C and
C++ are used for that sort
On 4/26/2012 20:54, Adam Skutt wrote:
On Apr 26, 12:02 pm, Kiuhnm wrote:
On 4/26/2012 16:00, Adam Skutt wrote:
On Apr 26, 9:37 am, Kiuhnm wrote:
On 4/26/2012 13:45, Adam Skutt wrote:
On Apr 26, 1:48 am, John Nagle wrote:
This assumes that everything is, internally, an object.
On Thu, 26 Apr 2012 11:31:39 -0700, John Nagle wrote:
> I would suggest that "is" raise ValueError for the ambiguous cases.
> If both operands are immutable, "is" should raise ValueError. That's the
> case where the internal representation of immutables shows through.
This breaks one of the m
On Fri, Apr 27, 2012 at 8:04 AM, Ian Kelly wrote:
> You can't check ref counts at parse time.
I know, and it'd be impossible to recognize at parse time for any but
the most trivial cases (since names can always be rebound). The
detection of temporaries can only be done at run time.
ChrisA
--
ht
On Thu, Apr 26, 2012 at 3:51 PM, Chris Angelico wrote:
> On Fri, Apr 27, 2012 at 7:39 AM, Ian Kelly wrote:
>> I'm not sure precisely what you mean by "temporary object", so I am
>> taking it to mean an object that is referenced only by the VM stack
>> (or something equivalent for other implementa
On Fri, Apr 27, 2012 at 7:39 AM, Ian Kelly wrote:
> I'm not sure precisely what you mean by "temporary object", so I am
> taking it to mean an object that is referenced only by the VM stack
> (or something equivalent for other implementations).
>
> In that case: no, you can't. Take "f() is g()",
On Thu, Apr 26, 2012 at 1:34 PM, Adam Skutt wrote:
> What I think you want is what I said above: ValueError raised when
> either operand is a /temporary/ object. Really, it should probably be
> a parse-time error, since you could (and should) make the
> determination at parse time.
I'm not sure
On Apr 26, 2:31 pm, John Nagle wrote:
> On 4/26/2012 4:45 AM, Adam Skutt wrote:
> > On Apr 26, 1:48 am, John Nagle wrote:
> >> On 4/25/2012 5:01 PM, Steven D'Aprano wrote:
>
> >>> On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
>
> Though, maybe it's better to use a different keyword t
On Apr 26, 1:34 pm, rusi wrote:
> On Apr 26, 7:44 pm, Adam Skutt wrote:
> > On Apr 26, 10:18 am, rusi wrote:
>
> > > On Apr 26, 4:42 pm, Adam Skutt wrote:
>
> > > > In a mathematical sense, you're saying that given f(x) = x+2, using
> > > > f(x) is somehow more "direct" (whatever the hell that
On Apr 26, 12:02 pm, Kiuhnm wrote:
> On 4/26/2012 16:00, Adam Skutt wrote:
> > On Apr 26, 9:37 am, Kiuhnm wrote:
> >> On 4/26/2012 13:45, Adam Skutt wrote:
>
> >>> On Apr 26, 1:48 am, John Naglewrote:
> This assumes that everything is, internally, an object. In
> CPython,
>
On 4/26/2012 4:45 AM, Adam Skutt wrote:
On Apr 26, 1:48 am, John Nagle wrote:
On 4/25/2012 5:01 PM, Steven D'Aprano wrote:
On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
Though, maybe it's better to use a different keyword than 'is' though,
due to the plain English
connotations of t
On 4/26/2012 1:48 AM, John Nagle wrote:
This assumes that everything is, internally, an object. In CPython,
that's the case, because Python is a naive interpreter and everything,
including numbers, is "boxed". That's not true of PyPy or Shed Skin.
So does "is" have to force the creation of a te
On Apr 26, 7:44 pm, Adam Skutt wrote:
> On Apr 26, 10:18 am, rusi wrote:
>
> > On Apr 26, 4:42 pm, Adam Skutt wrote:
>
> > > In a mathematical sense, you're saying that given f(x) = x+2, using
> > > f(x) is somehow more "direct" (whatever the hell that even means) than
> > > using 'x+2'. That's
On Thu, Apr 26, 2012 at 3:10 AM, Steven D'Aprano
wrote:
> But I was actually referring to something more fundamental than that. The
> statement "a is b" is a *direct* statement of identity. "John is my
> father." "id(a) == id(b)" is *indirect*: "The only child of John's
> grandfather is the parent
This thread has already beaten a dead horse enough that the horse came
back as a zombie and was re-killed, but I couldn't help but respond to
this part:
On 01/-10/-28163 01:59 PM, Adam Skutt wrote:
Code that relies on the identity of a temporary object is generally
incorrect. This is why C++
On 4/26/2012 16:00, Adam Skutt wrote:
On Apr 26, 9:37 am, Kiuhnm wrote:
On 4/26/2012 13:45, Adam Skutt wrote:
On Apr 26, 1:48 am, John Naglewrote:
On 4/25/2012 5:01 PM, Steven D'Aprano wrote:
On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
Though, maybe it's better to
On Apr 26, 10:18 am, rusi wrote:
> On Apr 26, 4:42 pm, Adam Skutt wrote:
>
>
>
> > In a mathematical sense, you're saying that given f(x) = x+2, using
> > f(x) is somehow more "direct" (whatever the hell that even means) than
> > using 'x+2'. That's just not true. We freely and openly interchan
On Fri, Apr 27, 2012 at 12:00 AM, Adam Skutt wrote:
> C# and Python do have a misfeature: '==' is identity comparison only
> if operator== / __eq__ is not overloaded. Identity comparison and
> value comparison are disjoint operations, so it's entirely
> inappropriate to combine them.
So what sho
On Apr 26, 9:37 am, Kiuhnm wrote:
> On 4/26/2012 13:45, Adam Skutt wrote:
>
>
>
>
>
>
>
>
>
> > On Apr 26, 1:48 am, John Nagle wrote:
> >> On 4/25/2012 5:01 PM, Steven D'Aprano wrote:
>
> >>> On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
>
> Though, maybe it's better to use a differe
On Apr 26, 4:42 pm, Adam Skutt wrote:
>
> In a mathematical sense, you're saying that given f(x) = x+2, using
> f(x) is somehow more "direct" (whatever the hell that even means) than
> using 'x+2'. That's just not true. We freely and openly interchange
> them all the time doing mathematics. Pro
On 4/26/2012 13:45, Adam Skutt wrote:
On Apr 26, 1:48 am, John Nagle wrote:
On 4/25/2012 5:01 PM, Steven D'Aprano wrote:
On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
Though, maybe it's better to use a different keyword than 'is' though,
due to the plain English
connotations of the
On 26 April 2012 12:42, Adam Skutt wrote:
> On Apr 26, 5:10 am, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> On Wed, 25 Apr 2012 20:50:21 -0700, Adam Skutt wrote:
>> > On Apr 25, 8:01 pm, Steven D'Aprano > > +comp.lang.pyt...@pearwood.info> wrote:
>> >> On Wed, 25 Apr 2012 13:49:24
On Thu, Apr 26, 2012 at 10:12 PM, Robert Kern wrote:
> Yes. Win64 has 64-bit pointers and 32-bit C longs (and thus 32-bit Python
> ints).
>
> It returns a Python long.
Ah, that solves that one. Definite improvement in Python 3 with the
merging of the two types, though. Machine integers are simply
On 4/26/2012 2:01, Steven D'Aprano wrote:
On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
Though, maybe it's better to use a different keyword than 'is' though,
due to the plain English
connotations of the term; I like 'sameobj' personally, for whatever
little it matters. Really, I think
On 4/26/12 12:56 PM, Chris Angelico wrote:
Side point: In Python 2, id() returns an int, not a long. Is it
possible to be running Python on a 64-bit machine with a 32-bit int
type?
Yes. Win64 has 64-bit pointers and 32-bit C longs (and thus 32-bit Python ints).
And if so, what does CPython d
On Thu, Apr 26, 2012 at 9:42 PM, Adam Skutt wrote:
> Would you call the result of casting a C pointer to an int an
> address? If so, you must call the result of id() an address as well--
> you can't dereference either of them. If not, then you need to
> provide an alternate name for the result o
On Apr 26, 1:48 am, John Nagle wrote:
> On 4/25/2012 5:01 PM, Steven D'Aprano wrote:
>
> > On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
>
> >> Though, maybe it's better to use a different keyword than 'is' though,
> >> due to the plain English
> >> connotations of the term; I like 'sameob
On Apr 26, 5:10 am, Steven D'Aprano wrote:
> On Wed, 25 Apr 2012 20:50:21 -0700, Adam Skutt wrote:
> > On Apr 25, 8:01 pm, Steven D'Aprano > +comp.lang.pyt...@pearwood.info> wrote:
> >> On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
> >> > Though, maybe it's better to use a different keywo
On Wed, 25 Apr 2012 20:50:21 -0700, Adam Skutt wrote:
> On Apr 25, 8:01 pm, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
>> > Though, maybe it's better to use a different keyword than 'is'
>> > though, due to the plain English
>>
On Wed, 25 Apr 2012 22:48:33 -0700, John Nagle wrote:
> On 4/25/2012 5:01 PM, Steven D'Aprano wrote:
>> On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
>>
>>> Though, maybe it's better to use a different keyword than 'is' though,
>>> due to the plain English
>>> connotations of the term; I l
On Thu, Apr 26, 2012 at 3:48 PM, John Nagle wrote:
> This assumes that everything is, internally, an object. In CPython,
> that's the case, because Python is a naive interpreter and everything,
> including numbers, is "boxed". That's not true of PyPy or Shed Skin.
> So does "is" have to force
On 4/25/2012 5:01 PM, Steven D'Aprano wrote:
On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
Though, maybe it's better to use a different keyword than 'is' though,
due to the plain English
connotations of the term; I like 'sameobj' personally, for whatever
little it matters. Really, I th
On Thu, Apr 26, 2012 at 1:50 PM, Adam Skutt wrote:
> On Apr 25, 8:01 pm, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> 2) The "is" operator always has the exact same semantics and cannot be
>> overridden. The id() function can be monkey-patched.
>
> I can't see how that's useful at a
On Apr 25, 8:01 pm, Steven D'Aprano wrote:
> On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
> > Though, maybe it's better to use a different keyword than 'is' though,
> > due to the plain English
> > connotations of the term; I like 'sameobj' personally, for whatever
> > little it matters.
In article <4f9833ff$0$29965$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> On Wed, 25 Apr 2012 13:42:31 +0200, Thomas Rachel wrote:
>
> > Two objects can be equal (=) without being identical (â¡), but not the
> > other way.
>
>
> >>> x = float('nan')
> >>> y = x
> >>> x is y
On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
> Though, maybe it's better to use a different keyword than 'is' though,
> due to the plain English
> connotations of the term; I like 'sameobj' personally, for whatever
> little it matters. Really, I think taking away the 'is' operator
> alto
On 4/25/2012 4:49 PM, Adam Skutt wrote:
Identity and equality are distinct concepts in programming languages.
There's nothing that can be done about that, and no particularly good
reason to force certain language behaviors because some "programmers"
have difficulty with the distinction.
Though,
On Apr 25, 10:38 am, Nobody wrote:
> On Mon, 23 Apr 2012 10:01:24 -0700, Paul Rubin wrote:
> >> I can't think of a single case where 'is' is ill-defined.
>
> > If I can't predict the output of
>
> > print (20+30 is 30+20) # check whether addition is commutative print
> > (20*30 is 30*20)
On Thu, Apr 26, 2012 at 3:27 AM, Steven D'Aprano
wrote:
> By the way, in mathematics, ≡ normally means "is equivalent to", which is
> not quite the same as "identical to".
That's perhaps because, in mathematics, nobody would even think of
asking if this 4 is the same as that 4. What sort of quest
On Wed, 25 Apr 2012 13:42:31 +0200, Thomas Rachel wrote:
> Two objects can be equal (=) without being identical (≡), but not the
> other way.
>>> x = float('nan')
>>> y = x
>>> x is y
True
>>> x == y
False
By the way, in mathematics, ≡ normally means "is equivalent to", which is
not quite the
On Mon, 23 Apr 2012 10:01:24 -0700, Paul Rubin wrote:
>> I can't think of a single case where 'is' is ill-defined.
>
> If I can't predict the output of
>
> print (20+30 is 30+20) # check whether addition is commutative print
> (20*30 is 30*20) # check whether multiplication is commutat
Am 24.04.2012 15:25 schrieb rusi:
Identity, sameness, equality and the verb to be are all about the same
concept(s) and their definitions are *intrinsically* circular; see
http://plato.stanford.edu/entries/identity/#2
Mybe in real life language. In programming and mathematics there are
severa
On 4/24/2012 15:25, rusi wrote:
On Apr 24, 4:06 pm, Thomas Rachel wrote:
Am 24.04.2012 08:02 schrieb rusi:
On Apr 23, 9:34 am, Steven D'Apranowrote:
"is" is never ill-defined. "is" always, without exception, returns True
if the two operands are the same object, and False if they are no
On Apr 24, 4:06 pm, Thomas Rachel wrote:
> Am 24.04.2012 08:02 schrieb rusi:
>
> > On Apr 23, 9:34 am, Steven D'Aprano > +comp.lang.pyt...@pearwood.info> wrote:
>
> >> "is" is never ill-defined. "is" always, without exception, returns True
> >> if the two operands are the same object, and False i
On 4/24/2012 8:02, rusi wrote:
On Apr 23, 9:34 am, Steven D'Aprano wrote:
"is" is never ill-defined. "is" always, without exception, returns True
if the two operands are the same object, and False if they are not. This
is literally the simplest operator in Python.
Circular definition: In cas
Am 24.04.2012 08:02 schrieb rusi:
On Apr 23, 9:34 am, Steven D'Aprano wrote:
"is" is never ill-defined. "is" always, without exception, returns True
if the two operands are the same object, and False if they are not. This
is literally the simplest operator in Python.
Circular definition: In
On Apr 23, 9:34 am, Steven D'Aprano wrote:
> "is" is never ill-defined. "is" always, without exception, returns True
> if the two operands are the same object, and False if they are not. This
> is literally the simplest operator in Python.
Circular definition: In case you did not notice, 'is' an
On Tue, Apr 24, 2012 at 12:12 AM, Terry Reedy wrote:
>> and you're trying to dodge around that. :/
>
> In a previous post you chided Stephen for an ad hominem comment. Above you
> make two. Both are false.
I accused you of not answering the question or shifting goalposts.
This is an attack agains
On 4/23/2012 4:37 PM, Devin Jeanpierre wrote:
However, you appear to be trying to shift the goalposts. Either "1 is
1" is always True, or always False, or sometimes one or the other. If
I'm mistaken and it so happens that numeric constants are guaranteed
somewhere to always be cached, then repla
On Mon, Apr 23, 2012 at 11:03 PM, Tim Delaney
wrote:
> My claim is that doing this automatically for all integers and/or strings
> could lead to prohibitively-expensive performance characteristics, and done
> wrong to prohibitively-expensive memory characteristics.
OK. I agree, and I'm not in fav
1 - 100 of 154 matches
Mail list logo
