In article 7xvckq4c2j@ruckus.brouhaha.com,
Paul Rubin no.email@nospam.invalid wrote:
Kiuhnm kiuhnm03.4t.yahoo.it 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
On 4/28/2012 16:18, Adam Skutt wrote:
On Apr 28, 7:26 am, Kiuhnmkiuhnm03.4t.yahoo.it wrote:
On 4/27/2012 19:15, Adam Skutt wrote:
On Apr 27, 11:01 am, Kiuhnmkiuhnm03.4t.yahoo.itwrote:
The abstraction is this:
- There are primitives and objects.
- Primitives are not objects. The converse
On 4/28/2012 4:47 AM, Kiuhnm wrote:
On 4/27/2012 17:39, Adam Skutt wrote:
On Apr 27, 8:07 am, Kiuhnmkiuhnm03.4t.yahoo.it 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
On 4/27/2012 19:15, Adam Skutt wrote:
On Apr 27, 11:01 am, Kiuhnmkiuhnm03.4t.yahoo.it wrote:
On 4/27/2012 1:57, Adam Skutt wrote:
On Apr 26, 6:34 pm, Kiuhnmkiuhnm03.4t.yahoo.itwrote:
If you
understand that your 'a' is not really an object but a reference to it,
everything becomes clear
On Sat, Apr 28, 2012 at 9:26 PM, Kiuhnm
kiuhnm03.4t.yahoo...@mail.python.org 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
On 4/27/2012 17:39, Adam Skutt wrote:
On Apr 27, 8:07 am, Kiuhnmkiuhnm03.4t.yahoo.it 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 28, 7:26 am, Kiuhnm kiuhnm03.4t.yahoo.it wrote:
On 4/27/2012 19:15, Adam Skutt wrote:
On Apr 27, 11:01 am, Kiuhnmkiuhnm03.4t.yahoo.it wrote:
The abstraction is this:
- There are primitives and objects.
- Primitives are not objects. The converse is also true.
- Primitives can
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
that ID,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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 Apr 26, 10:56 pm, OKB (not okblacke)
brennospamb...@nobrenspambarn.net 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,
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
On 4/27/12 12:07 AM, Paul Rubin wrote:
Nobodynob...@nowhere.com 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
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/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
On Fri, Apr 27, 2012 at 10:07 PM, Kiuhnm
kiuhnm03.4t.yahoo...@mail.python.org 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
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
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, we're talking of
On 4/27/2012 1:57, Adam Skutt wrote:
On Apr 26, 6:34 pm, Kiuhnmkiuhnm03.4t.yahoo.it wrote:
On 4/26/2012 20:54, Adam Skutt wrote:
On Apr 26, 12:02 pm, Kiuhnmkiuhnm03.4t.yahoo.itwrote:
On 4/26/2012 16:00, Adam Skutt wrote:
On Apr 26, 9:37 am, Kiuhnmkiuhnm03.4t.yahoo.it wrote:
The
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 Apr 27, 8:07 am, Kiuhnm kiuhnm03.4t.yahoo.it 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
On Fri, Apr 27, 2012 at 9:39 AM, Adam Skutt ask...@gmail.com wrote:
On Apr 27, 8:07 am, Kiuhnm kiuhnm03.4t.yahoo.it 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
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 gave
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:
On Apr 26, 5:10 am, Steven D'Aprano steve
+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(a) ==
On Thu, 26 Apr 2012 04:42:36 -0700, Adam Skutt wrote:
On Apr 26, 5:10 am, Steven D'Aprano steve
+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 is
On Apr 27, 11:01 am, Kiuhnm kiuhnm03.4t.yahoo.it wrote:
On 4/27/2012 1:57, Adam Skutt wrote:
On Apr 26, 6:34 pm, Kiuhnmkiuhnm03.4t.yahoo.it 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
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, 12:56 pm, Steven D'Aprano steve
+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 at least the object's lifecycle, for a
programmer. If you
On Sat, Apr 28, 2012 at 3:33 AM, Adam Skutt ask...@gmail.com 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,
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 Apr 27, 1:12 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Thu, 26 Apr 2012 04:42:36 -0700, Adam Skutt wrote:
On Apr 26, 5:10 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
Solution to *what problem*?
This confusion that many people have over
On Fri, Apr 27, 2012 at 11:33 AM, Adam Skutt ask...@gmail.com wrote:
On Apr 27, 12:56 pm, Steven D'Aprano steve
+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
On Apr 27, 1:06 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Thu, 26 Apr 2012 04:42:36 -0700, Adam Skutt wrote:
On Apr 26, 5:10 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
But I was actually referring to something more fundamental than that.
The
On Fri, Apr 27, 2012 at 11:38 AM, Chris Angelico ros...@gmail.com wrote:
On Sat, Apr 28, 2012 at 3:33 AM, Adam Skutt ask...@gmail.com 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
On Sat, Apr 28, 2012 at 3:51 AM, Adam Skutt ask...@gmail.com 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
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 result is better?
D.
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 one could
On Apr 27, 2:40 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info 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
On Thu, Apr 26, 2012 at 3:48 PM, John Nagle na...@animats.com 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
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 like 'sameobj'
On Wed, 25 Apr 2012 20:50:21 -0700, Adam Skutt wrote:
On Apr 25, 8:01 pm, Steven D'Aprano steve
+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 Apr 26, 5:10 am, Steven D'Aprano steve
+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 steve
+comp.lang.pyt...@pearwood.info wrote:
On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt wrote:
Though, maybe it's
On Apr 26, 1:48 am, John Nagle na...@animats.com 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
On Thu, Apr 26, 2012 at 9:42 PM, Adam Skutt ask...@gmail.com 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
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
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
On Thu, Apr 26, 2012 at 10:12 PM, Robert Kern robert.k...@gmail.com 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
On 26 April 2012 12:42, Adam Skutt ask...@gmail.com wrote:
On Apr 26, 5:10 am, Steven D'Aprano steve
+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 steve
+comp.lang.pyt...@pearwood.info wrote:
On Wed, 25 Apr
On 4/26/2012 13:45, Adam Skutt wrote:
On Apr 26, 1:48 am, John Naglena...@animats.com 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
On Apr 26, 4:42 pm, Adam Skutt ask...@gmail.com 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
On Apr 26, 9:37 am, Kiuhnm kiuhnm03.4t.yahoo.it wrote:
On 4/26/2012 13:45, Adam Skutt wrote:
On Apr 26, 1:48 am, John Naglena...@animats.com 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
On Fri, Apr 27, 2012 at 12:00 AM, Adam Skutt ask...@gmail.com 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.
On Apr 26, 10:18 am, rusi rustompm...@gmail.com wrote:
On Apr 26, 4:42 pm, Adam Skutt ask...@gmail.com 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
On 4/26/2012 16:00, Adam Skutt wrote:
On Apr 26, 9:37 am, Kiuhnmkiuhnm03.4t.yahoo.it wrote:
On 4/26/2012 13:45, Adam Skutt wrote:
On Apr 26, 1:48 am, John Naglena...@animats.comwrote:
On 4/25/2012 5:01 PM, Steven D'Aprano wrote:
On Wed, 25 Apr 2012 13:49:24 -0700, Adam Skutt
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
On Thu, Apr 26, 2012 at 3:10 AM, Steven D'Aprano
steve+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(a) == id(b) is *indirect*: The only child of John's
On Apr 26, 7:44 pm, Adam Skutt ask...@gmail.com wrote:
On Apr 26, 10:18 am, rusi rustompm...@gmail.com wrote:
On Apr 26, 4:42 pm, Adam Skutt ask...@gmail.com 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 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
On 4/26/2012 4:45 AM, Adam Skutt wrote:
On Apr 26, 1:48 am, John Naglena...@animats.com 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
On Apr 26, 12:02 pm, Kiuhnm kiuhnm03.4t.yahoo.it wrote:
On 4/26/2012 16:00, Adam Skutt wrote:
On Apr 26, 9:37 am, Kiuhnmkiuhnm03.4t.yahoo.it wrote:
On 4/26/2012 13:45, Adam Skutt wrote:
On Apr 26, 1:48 am, John Naglena...@animats.comwrote:
This assumes that everything is,
On Apr 26, 1:34 pm, rusi rustompm...@gmail.com wrote:
On Apr 26, 7:44 pm, Adam Skutt ask...@gmail.com wrote:
On Apr 26, 10:18 am, rusi rustompm...@gmail.com wrote:
On Apr 26, 4:42 pm, Adam Skutt ask...@gmail.com wrote:
In a mathematical sense, you're saying that given f(x) = x+2, using
On Apr 26, 2:31 pm, John Nagle na...@animats.com wrote:
On 4/26/2012 4:45 AM, Adam Skutt wrote:
On Apr 26, 1:48 am, John Naglena...@animats.com 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
On Thu, Apr 26, 2012 at 1:34 PM, Adam Skutt ask...@gmail.com 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.
On Fri, Apr 27, 2012 at 7:39 AM, Ian Kelly ian.g.ke...@gmail.com 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
On Thu, Apr 26, 2012 at 3:51 PM, Chris Angelico ros...@gmail.com wrote:
On Fri, Apr 27, 2012 at 7:39 AM, Ian Kelly ian.g.ke...@gmail.com 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
On Fri, Apr 27, 2012 at 8:04 AM, Ian Kelly ian.g.ke...@gmail.com 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
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 most
On 4/26/2012 20:54, Adam Skutt wrote:
On Apr 26, 12:02 pm, Kiuhnmkiuhnm03.4t.yahoo.it wrote:
On 4/26/2012 16:00, Adam Skutt wrote:
On Apr 26, 9:37 am, Kiuhnmkiuhnm03.4t.yahoo.it wrote:
On 4/26/2012 13:45, Adam Skutt wrote:
On Apr 26, 1:48 am, John Naglena...@animats.com wrote:
Nobody nob...@nowhere.com 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
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
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
On Apr 26, 6:34 pm, Kiuhnm kiuhnm03.4t.yahoo.it wrote:
On 4/26/2012 20:54, Adam Skutt wrote:
On Apr 26, 12:02 pm, Kiuhnmkiuhnm03.4t.yahoo.it wrote:
On 4/26/2012 16:00, Adam Skutt wrote:
On Apr 26, 9:37 am, Kiuhnmkiuhnm03.4t.yahoo.it wrote:
The fact that you think that that's differing
On Thu, Apr 26, 2012 at 12:05 PM, Evan Driscoll drisc...@cs.wisc.edu 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 Thu, Apr 26, 2012 at 5:39 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Thu, Apr 26, 2012 at 1:34 PM, Adam Skutt ask...@gmail.com 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
On Apr 26, 7:33 pm, Steven D'Aprano steve
+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 had better support for pure functions.
They would be
Adam Skutt ask...@gmail.com 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
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
On Thu, 26 Apr 2012 17:16:10 -0700, Adam Skutt wrote:
On Apr 26, 7:33 pm, Steven D'Aprano steve
+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
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
comparison
On Thu, Apr 26, 2012 at 7:33 PM, Steven D'Aprano
steve+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 had better support for pure functions.
They
On Fri, Apr 27, 2012 at 12:47 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Thu, 26 Apr 2012 17:16:10 -0700, Adam Skutt wrote:
On Apr 26, 7:33 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Thu, 26 Apr 2012 12:22:55 -0700, Adam Skutt wrote:
I often
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
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 commutative
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 same as
On Thu, Apr 26, 2012 at 3:27 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
On Apr 25, 10:38 am, Nobody nob...@nowhere.com 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
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 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
In article 4f9833ff$0$29965$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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')
On Apr 25, 8:01 pm, Steven D'Aprano steve
+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
connotations of the term; I like 'sameobj' personally, for
On Thu, Apr 26, 2012 at 1:50 PM, Adam Skutt ask...@gmail.com wrote:
On Apr 25, 8:01 pm, Steven D'Aprano steve
+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
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
On Apr 23, 9:34 am, Steven D'Aprano steve
+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 if they are not. This
is literally the simplest operator in Python.
Circular definition: In
Am 24.04.2012 08:02 schrieb rusi:
On Apr 23, 9:34 am, Steven D'Apranosteve
+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 if they are not. This
is literally the simplest operator in
On 4/24/2012 8:02, rusi wrote:
On Apr 23, 9:34 am, Steven D'Apranosteve
+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 if they are not. This
is literally the simplest operator in
On Apr 24, 4:06 pm, Thomas Rachel nutznetz-0c1b6768-bfa9-48d5-
a470-7603bd3aa...@spamschutz.glglgl.de wrote:
Am 24.04.2012 08:02 schrieb rusi:
On Apr 23, 9:34 am, Steven D'Apranosteve
+comp.lang.pyt...@pearwood.info wrote:
is is never ill-defined. is always, without exception, returns
On 4/24/2012 15:25, rusi wrote:
On Apr 24, 4:06 pm, Thomas Rachelnutznetz-0c1b6768-bfa9-48d5-
a470-7603bd3aa...@spamschutz.glglgl.de wrote:
Am 24.04.2012 08:02 schrieb rusi:
On Apr 23, 9:34 am, Steven D'Apranosteve
+comp.lang.pyt...@pearwood.infowrote:
is is never ill-defined. is
Am 21.04.2012 14:51, schrieb gst:
Hi,
I played (python3.2) a bit on that and :
case 1) Ok to me (right hand side is a tuple, whose elements are evaluated
one per one and have same effect as your explanation (first [] is destroyed
right before the second one is created) :
x, y =
On 4/22/2012 9:34 PM, Steven D'Aprano wrote:
On Sun, 22 Apr 2012 12:43:36 -0700, John Nagle wrote:
On 4/20/2012 9:34 PM, john.tant...@gmail.com wrote:
On Friday, April 20, 2012 12:34:46 PM UTC-7, Rotwang wrote:
I believe it says somewhere in the Python docs that it's undefined and
On 4/22/2012 21:43, John Nagle wrote:
On 4/20/2012 9:34 PM, john.tant...@gmail.com wrote:
On Friday, April 20, 2012 12:34:46 PM UTC-7, Rotwang wrote:
I believe it says somewhere in the Python docs that it's undefined and
implementation-dependent whether two identical expressions have the same
1 - 100 of 154 matches
Mail list logo
