Steve D'Aprano wrote:
> Is there a way to log when the garbage collector finds and collects a
> reference cycle?
>
> I don't care about objects claimed by the reference counter, I only care
> about cycles.
I don't know, and I don't think so. Would a structure like
a --- b --- c
| | |
d
On Thu, Jun 25, 2015 at 12:49 PM, Eric Edmond wrote:
> Hi,
>
> I have been writing a C++ extension for Python recently, and am currently
> fixing the reference counting throughout the extension. As I am very new to
> this topic, my question may have a simple answer, but I was unable to find
> any
On 06/03/2014 00:35, Steven D'Aprano wrote:
On Thu, 06 Mar 2014 08:26:22 +1100, Chris Angelico wrote:
On Thu, Mar 6, 2014 at 8:14 AM, Marko Rauhamaa wrote:
When I talk about an object's memory address, I'm not referring to what
might be revealed by gdb, for example. That is, I'm not talking a
On Wed, 05 Mar 2014 22:23:46 +0200, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> There is no metaphysical implication from Python's "is" operator. If
>> the operator had precisely the same behaviour, but was called "same",
>> as in:
>>
>> a same b
>> => returns True if a and b are the same obje
On 6/03/2014 10:52 AM, Marko Rauhamaa wrote:
I was just saying talking about id() as a memory address isn't all that
bad. It's a bit like rolling down your power windows or turning up the
volume, when there's nothing to roll or turn. There's no risk of getting
your program wrong.
Unless you're
Marko Rauhamaa writes:
> Ben Finney :
>
> > Then this does not count as a leaky abstraction. All you're saying is
> > that the ‘id(foo)’ result is a representation of the object identity,
> > which is entirely at the level of the abstraction. Nothing is leaked.
>
> I wasn't making a point about a
Ben Finney :
> Marko Rauhamaa writes:
>> When I talk about an object's memory address, I'm not referring to
>> what might be revealed by gdb, for example. That is, I'm not talking
>> about the process's virtual address space, nor am I talking about the
>> physical address on the address bus. I ca
On Thu, Mar 6, 2014 at 11:35 AM, Steven D'Aprano
wrote:
> On Thu, 06 Mar 2014 08:26:22 +1100, Chris Angelico wrote:
>
>> Where's the complaints about circularity now? You're saying "But of
>> course id() returns the address, as long as we define the address as
>> 'whatever id() returns'.". Unimpea
On Thu, 06 Mar 2014 08:26:22 +1100, Chris Angelico wrote:
> On Thu, Mar 6, 2014 at 8:14 AM, Marko Rauhamaa wrote:
>> When I talk about an object's memory address, I'm not referring to what
>> might be revealed by gdb, for example. That is, I'm not talking about
>> the process's virtual address sp
On 3/5/2014 3:46 PM, Marko Rauhamaa wrote:
Grant Edwards :
Wrong. If the two objects are not the same, then they will have
different ID values. If the ID values are the same, then you've only
got one object.
Ok, that circularity again.
Every deductive system starts with some undefined terms
Chris Angelico :
> On Thu, Mar 6, 2014 at 8:14 AM, Marko Rauhamaa wrote:
>> When I talk about an object's memory address, I'm not referring to
>> what might be revealed by gdb, for example. That is, I'm not talking
>> about the process's virtual address space, nor am I talking about the
>> physic
On 05/03/2014 21:33, Tim Chase wrote:
On 2014-03-05 23:14, Marko Rauhamaa wrote:
When I talk about an object's memory address, I'm not referring to
what might be revealed by gdb, for example. That is, I'm not
talking about the process's virtual address space, nor am I talking
about the physical
Marko Rauhamaa writes:
> Ben Finney :
>
> > A reference-compliant implementation can contradict your inference (by
> > returning an object identity that is *not* the object's memory
> > address). Any code you've written based on that false inference will
> > break.
> >
> > The fault will be yours
On 05/03/2014 20:46, Marko Rauhamaa wrote:
I think the discussion spawned from the problem of teaching programming
students the right idea of values and objects. A teacher would like to
bring in advanced concepts last, but Python seems to force you to get
them at the very beginning.
Nonsense,
On 2014-03-05 23:14, Marko Rauhamaa wrote:
> When I talk about an object's memory address, I'm not referring to
> what might be revealed by gdb, for example. That is, I'm not
> talking about the process's virtual address space, nor am I talking
> about the physical address on the address bus. I can
On Thu, Mar 6, 2014 at 8:14 AM, Marko Rauhamaa wrote:
> When I talk about an object's memory address, I'm not referring to what
> might be revealed by gdb, for example. That is, I'm not talking about
> the process's virtual address space, nor am I talking about the physical
> address on the addres
Ben Finney :
> A reference-compliant implementation can contradict your inference (by
> returning an object identity that is *not* the object's memory
> address). Any code you've written based on that false inference will
> break.
>
> The fault will be yours, for inferring an assertion that isn't
Marko Rauhamaa writes:
> Grant Edwards :
>
> > Wrong. If the two objects are not the same, then they will have
> > different ID values. If the ID values are the same, then you've only
> > got one object.
>
> Ok, that circularity again.
Yes, it's circular. In an abstract system like a programming
Marko Rauhamaa writes:
> Say I implement Python. Say I returned a random number for id(), how
> would that violate the language spec?
You could do that, certainly. So long as that randomly-chosen integer
was always the same for every object, and never the same for any other
concurrently-existing
Marko Rauhamaa writes:
> Steven D'Aprano :
> > Both the Jython and CPython id() functions are compliant with the
> > language definition. The Jython id() function is better, because it
> > doesn't encourage people to mistakenly and foolishly imagine that
> > id() equals address.
>
> I agree with
Grant Edwards :
> Wrong. If the two objects are not the same, then they will have
> different ID values. If the ID values are the same, then you've only
> got one object.
Ok, that circularity again.
Say I implement Python. Say I returned a random number for id(), how
would that violate the langu
Steven D'Aprano :
> The id() function in Python is not defined as returning the address of
> the object.
It might as well. If I said id() returns the address of the object in
the Python VM's virtual address space, you couldn't call my bluff.
Say id() returned the intantiation sequence number. I
On 2014-03-05, Marko Rauhamaa wrote:
> Set theory obeys the so-called extensionality principle: if two
> objects are indistinguishable in every way, they are one and the same
> object. Fermions in particle physics are the same way: if two
> fermions' quantum states coincide, they are one and the
Steven D'Aprano :
> There is no metaphysical implication from Python's "is" operator. If the
> operator had precisely the same behaviour, but was called "same", as in:
>
> a same b
> => returns True if a and b are the same object
> => returns False if a and b are not the same object
>
> would you
Rustom Mody writes:
> On Wednesday, March 5, 2014 11:50:46 AM UTC+5:30, Ben Finney wrote:
> > So, what machine represenatation is leaked?
>
> > I'll re-iterate that "memory location of the object" isn't a valid
> > response. There is no necessary relation between the memory location of
> > the ob
On Tue, 04 Mar 2014 22:03:36 -0800, Rustom Mody wrote:
> On Wednesday, March 5, 2014 10:36:37 AM UTC+5:30, Steven D'Aprano wrote:
>> On Tue, 04 Mar 2014 19:36:38 -0800, Rustom Mody wrote:
>
>> > Python's 'is' leaks
>> > the machine abstraction. 'id' does it legitimately (somewhat), 'is'
>> > does
On Tue, 04 Mar 2014 21:47:21 -0800, Rustom Mody wrote:
> On Wednesday, March 5, 2014 10:36:37 AM UTC+5:30, Steven D'Aprano wrote:
>> On Tue, 04 Mar 2014 19:36:38 -0800, Rustom Mody wrote:
>
>> > Python's 'is' leaks
>> > the machine abstraction. 'id' does it legitimately (somewhat), 'is'
>> > does
On 2014-03-05 09:40, Rustom Mody wrote:
> Every object has an identity, a type and a value. An object's
> identity never changes once it has been created; you may think of
> it as the object's address in memory. The 'is' operator compares
> the identity of two objects; the id() function returns an
On Wednesday, March 5, 2014 11:50:46 AM UTC+5:30, Ben Finney wrote:
> Rustom Mody writes:
> > That python is a hll means that machine reprs are intended to be abstracted
> > away. 'is' fails to do that -- proof of that being the discrepancy between
> > is and ==
> That's your proof? That is a non
On 2014-03-05 17:26, Ben Finney wrote:
> > "Jython is an imitation of Cpython and does a good job but not
> > quite as in the case of 'id'"
>
> Wrong. Jython and CPython both adhere to the guarantees of object
> identity. Both implementations follow the language reference, and
> neither implemen
Op 04-03-14 16:25, Chris Angelico schreef:
> On Wed, Mar 5, 2014 at 2:19 AM, Jerry Hill wrote:
>> Out of curiosity, do you think we should be doing truth checking with
>> 'is'? True and False are singletons, and it seems to me that the
>> justification for idenity versus equality should be just
On Wed, Mar 5, 2014 at 11:35 PM, Mark Lawrence wrote:
>> if the_list is None:
>>
>>
>> Marko
>>
>
> Really great thinking, test the name the_list, which strangely enough tells
> me that this beast is a list, in the same way that THIS_IS_A_CONSTANT is a
> constant, to see if it's None. Congrat
On 05/03/2014 06:23, Marko Rauhamaa wrote:
Rustom Mody :
* ... which summarizes my objection in this thread: Python's 'is'
leaks the machine abstraction. 'id' does it legitimately (somewhat),
'is' does it illegitimately
I agree that the Python data model can be exceedingly challenging to a
be
On 05/03/2014 06:28, alex23 wrote:
On 5/03/2014 4:10 PM, Rustom Mody wrote:
A python programmer who needs/wants to think of same/is in this sense
should probably be using C or assembly
Any programmer who is obsessing about some idea of philosophical purity
should probably not be using Python.
On 05/03/2014 06:10, Rustom Mody wrote:
On Wednesday, March 5, 2014 11:31:04 AM UTC+5:30, alex23 wrote:
On 5/03/2014 3:47 PM, Rustom Mody wrote:
That python is a hll means that machine reprs are intended to be abstracted
away. 'is' fails to do that -- proof of that being the discrepancy between
Rustom Mody writes:
> All I am saying is that 'is' should have (be!) a name that is not
> philosophically grandiloquent bullshit but rather a name that more
> accurately conveys 'machine-representation-equivalence'
You haven't made either case.
How is the simple abstraction of object identity c
On Wednesday, March 5, 2014 11:53:21 AM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :
> > * ... which summarizes my objection in this thread: Python's 'is'
> > leaks the machine abstraction. 'id' does it legitimately (somewhat),
> > 'is' does it illegitimately
> I agree that the Python data mod
On Wed, Mar 5, 2014 at 5:03 PM, Rustom Mody wrote:
> I can say "'id' is just 'machine-id' is just address at some low level"
And I can say that "id" returns a list of digits, but that doesn't
make either statement true.
The id() function returns a number which (a) never changes for any
given obj
Rustom Mody writes:
> I can say "'id' is just 'machine-id' is just address at some low
> level"
You could say that, but it's wrong. The only thing promised by “object
identity” is that each object has it, and that it is different from the
identity of every other object concurrently existing.
“M
On 5/03/2014 4:10 PM, Rustom Mody wrote:
A python programmer who needs/wants to think of same/is in this sense
should probably be using C or assembly
Any programmer who is obsessing about some idea of philosophical purity
should probably not be using Python.
--
https://mail.python.org/mailma
Rustom Mody writes:
> A python programmer who needs/wants to think of same/is in this sense
> should probably be using C or assembly
Please back up that bald assertion. How does the usefulness of the
“object identity” abstraction oblige the programmer to not use Python?
--
\ “Software pa
Rustom Mody :
> * ... which summarizes my objection in this thread: Python's 'is'
> leaks the machine abstraction. 'id' does it legitimately (somewhat),
> 'is' does it illegitimately
I agree that the Python data model can be exceedingly challenging to a
beginner. However, I wouldn't throw the bab
Rustom Mody writes:
> That python is a hll means that machine reprs are intended to be abstracted
> away. 'is' fails to do that -- proof of that being the discrepancy between
> is and ==
That's your proof? That is a non sequitur. Those two operators are
*designed to be* different, to compare dif
On Wednesday, March 5, 2014 11:31:04 AM UTC+5:30, alex23 wrote:
> On 5/03/2014 3:47 PM, Rustom Mody wrote:
> > That python is a hll means that machine reprs are intended to be abstracted
> > away. 'is' fails to do that -- proof of that being the discrepancy between
> > is and ==
> The "discrepancy
On 5/03/2014 3:47 PM, Rustom Mody wrote:
That python is a hll means that machine reprs are intended to be abstracted
away. 'is' fails to do that -- proof of that being the discrepancy between
is and ==
The "discrepancy" is because _they're fundamentally different_:
>>> a = b = [1,2]
>>
On Wednesday, March 5, 2014 10:36:37 AM UTC+5:30, Steven D'Aprano wrote:
> On Tue, 04 Mar 2014 19:36:38 -0800, Rustom Mody wrote:
> > Python's 'is' leaks
> > the machine abstraction. 'id' does it legitimately (somewhat), 'is' does
> > it illegitimately
> Can you elaborate on why id() is legitima
On Wednesday, March 5, 2014 10:36:37 AM UTC+5:30, Steven D'Aprano wrote:
> On Tue, 04 Mar 2014 19:36:38 -0800, Rustom Mody wrote:
> > Python's 'is' leaks
> > the machine abstraction. 'id' does it legitimately (somewhat), 'is' does
> > it illegitimately
> and then later in another post:
> > "is"
On Tue, 04 Mar 2014 19:36:38 -0800, Rustom Mody wrote:
> Python's 'is' leaks
> the machine abstraction. 'id' does it legitimately (somewhat), 'is' does
> it illegitimately
and then later in another post:
> "is" in python leaks machine representations
> into the otherwise clean HLL abstraction in
On Wednesday, March 5, 2014 10:02:16 AM UTC+5:30, Ben Finney wrote:
> Rustom Mody writes:
> > * ... which summarizes my objection in this thread:
> Your long post references many things. Which is the "which" to which you
> refer? What is it you're referring to that summarises your position?
Text
On Wednesday, March 5, 2014 9:38:58 AM UTC+5:30, Ian wrote:
> On Tue, Mar 4, 2014 at 8:36 PM, Rustom Mody wrote:
> > * ... which summarizes my objection in this thread: Python's 'is' leaks the
> > machine abstraction. 'id' does it legitimately (somewhat),
> > 'is' does it illegitimately
> Well, si
Rustom Mody writes:
> * ... which summarizes my objection in this thread:
Your long post references many things. Which is the “which” to which you
refer? What is it you're referring to that summarises your position?
> Python's 'is' leaks the machine abstraction.
No, it does not. The ‘is’ opera
On Tue, Mar 4, 2014 at 8:36 PM, Rustom Mody wrote:
> * ... which summarizes my objection in this thread: Python's 'is' leaks the
> machine abstraction. 'id' does it legitimately (somewhat),
> 'is' does it illegitimately
Well, since "if x == None" is buggy as a test for sentinel values,
that means
On Wednesday, March 5, 2014 7:39:17 AM UTC+5:30, Roy Smith wrote:
> "Rhodri James" wrote:
> > wrote:
> > > Code should look like its intent. Warping it around performance is
> > > hardly ever worthwhile.
> > That depends. In Python, I'd agree with you; if I'm worrying about
> > performance in P
In article ,
"Rhodri James" wrote:
> On Tue, 04 Mar 2014 05:24:03 -, Chris Angelico
> wrote:
>
> > Code should look like its intent. Warping it around performance is
> > hardly ever worthwhile.
>
> That depends. In Python, I'd agree with you; if I'm worrying about
> performance in Py
On Tue, 04 Mar 2014 05:24:03 -, Chris Angelico
wrote:
Code should look like its intent. Warping it around performance is
hardly ever worthwhile.
That depends. In Python, I'd agree with you; if I'm worrying about
performance in Python, I'm worrying at the level of the algorithms I'm
On Tue, 04 Mar 2014 11:48:46 -, Steven D'Aprano
wrote:
On Tue, 04 Mar 2014 11:10:34 +, Alister wrote:
Definition of insanity
Doing the same thing over and over again & expecting different results
*rolls dice*
As any gamer will tell you, dice are not random number generators. T
On Wed, Mar 5, 2014 at 8:53 AM, Alexander Blinne wrote:
> Am 04.03.2014 15:06, schrieb Chris Angelico:
>> https://github.com/Rosuav/ExceptExpr/blob/master/find_except_expr.py
>
> I have always found it quite nice that the python parser is so easy to
> use from within python itself.
Yes. Until I p
Am 04.03.2014 15:06, schrieb Chris Angelico:
> https://github.com/Rosuav/ExceptExpr/blob/master/find_except_expr.py
I have always found it quite nice that the python parser is so easy to
use from within python itself.
> Run across the Python stdlib, that tells me there are 4040 uses of
> is/is no
On 2014-03-04 16:02, Chris Angelico wrote:
On Wed, Mar 5, 2014 at 2:42 AM, Steven D'Aprano
wrote:
# I never know when to stop
if bool(flag) is True is True is True is True is True is True: ...
The banana problem.
Speaking of which:
The 'right' way to peel a banana
http://www.telegraph.co.u
On Tuesday, March 4, 2014 8:49:22 PM UTC+5:30, Jerry Hill wrote:
> On Mon, Mar 3, 2014 at 11:52 PM, Steven D'Aprano wrote:
> > If your intention is to treat None as a singleton sentinel, not as a
> > value, then you ought to use "is" to signal that intention, rather than
> > using == even if you kn
In article ,
Chris Angelico wrote:
> On Wed, Mar 5, 2014 at 2:42 AM, Steven D'Aprano
> wrote:
> > # I never know when to stop
> > if bool(flag) is True is True is True is True is True is True: ...
>
> The banana problem.
>
> ChrisA
You can refactor that as:
eval(" is ".join(itertools.chain(
On Wed, Mar 5, 2014 at 2:42 AM, Steven D'Aprano
wrote:
> # I never know when to stop
> if bool(flag) is True is True is True is True is True is True: ...
The banana problem.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
On Tue, 04 Mar 2014 10:19:22 -0500, Jerry Hill wrote:
> On Mon, Mar 3, 2014 at 11:52 PM, Steven D'Aprano
> wrote:
>> If your intention is to treat None as a singleton sentinel, not as a
>> value, then you ought to use "is" to signal that intention, rather than
>> using == even if you know that th
On Wed, Mar 5, 2014 at 2:19 AM, Jerry Hill wrote:
> Out of curiosity, do you think we should be doing truth checking with
> 'is'? True and False are singletons, and it seems to me that the
> justification for idenity versus equality should be just as strong
> there, but I don't think I've ever se
On Mon, Mar 3, 2014 at 11:52 PM, Steven D'Aprano wrote:
> If your intention is to treat None as a singleton sentinel, not as a
> value, then you ought to use "is" to signal that intention, rather than
> using == even if you know that there won't be any false positives.
In all of the years I've be
On Tue, Mar 4, 2014 at 11:55 PM, Alexander Blinne wrote:
> Am 03.03.2014 19:48, schrieb Terry Reedy:
>> The 'is' operator has three uses, two intended and one not. In
>> production code, 'is' tests that an object *is* a particular singular
>> object, such as None or a sentinel instance of class ob
Am 03.03.2014 19:48, schrieb Terry Reedy:
> The 'is' operator has three uses, two intended and one not. In
> production code, 'is' tests that an object *is* a particular singular
> object, such as None or a sentinel instance of class object.
Just a bit of statistics on this one from a recent small
On Tue, 04 Mar 2014 11:10:34 +, Alister wrote:
> Definition of insanity
>
> Doing the same thing over and over again & expecting different results
*rolls dice*
:-)
--
Steven D'Aprano
http://import-that.dreamwidth.org/
--
https://mail.python.org/mailman/listinfo/python-list
On Tue, 04 Mar 2014 09:18:57 +1100, Ben Finney wrote:
> Marko Rauhamaa writes:
>
>> Mark Lawrence :
>>
>> > I'd just like to know why people are so obsessed with identities,
>> > I've never thought to use them in 10+ years of writing Python. Do I
>> > use the KISS principle too often?
>>
>> Cal
On Tue, Mar 4, 2014 at 3:52 PM, Steven D'Aprano wrote:
> This is why, unless performance is *really* critical, one should normally
> write x*2 when multiplying x by 2 rather than x >> 1. (And in Python, the
> overhead means that there is no real performance benefit to using bit
> shifts instead of
On Tue, 04 Mar 2014 00:22:55 +0200, Marko Rauhamaa wrote:
> Jerry Hill :
>
>> except for the fact that there has been 20 years of custom saying that
>> comparing to None with equality is wrong.
>
> "if foo == None" is not wrong in any manner. It's just that if you are
> comfortable with the "is"
On Mon, 03 Mar 2014 18:02:04 -0500, Roy Smith wrote:
> In article ,
> Ben Finney wrote:
>
>> That's right. Python provides this singleton and then recommends you
>> compare with ‘is’, precisely to protect against pathological cases like
>> a “return True when compared for equality with None” da
On Mon, 03 Mar 2014 17:02:14 -0500, Jerry Hill wrote:
> On Mon, Mar 3, 2014 at 4:51 PM, Tim Chase
> wrote:
>> There are a couple use-cases I've encountered where "is" matters:
>>
>> 1) the most popular:
>>
>> if foo is None:
>> do_stuff()
>
> I know this is the one that always comes up, bu
On Mon, 03 Mar 2014 13:48:39 -0500, Terry Reedy wrote:
> On 3/3/2014 4:42 AM, ast wrote:
>
>> Consider following code:
>>
> A=7
> B=7
> A is B
>
> The 'is' operator has three uses, two intended and one not. In
> production code, 'is' tests that an object *is* a particular singular
>
On Tue, Mar 4, 2014 at 10:02 AM, Roy Smith wrote:
> In article ,
> Ben Finney wrote:
>
>> That's right. Python provides this singleton and then recommends you
>> compare with ‘is’, precisely to protect against pathological cases like
>> a “return True when compared for equality with None” data t
In article ,
Ben Finney wrote:
> That's right. Python provides this singleton and then recommends you
> compare with âisâ, precisely to protect against pathological cases like
> a âreturn True when compared for equality with Noneâ data type.
Going off on a tangent, I've often wished Pyt
On Tue, Mar 4, 2014 at 9:22 AM, Marko Rauhamaa wrote:
> You generally use "==" if more than one object could be equal. If you
> know there's only one object of the kind, you convey that knowledge by
> the use of "is" even when functionally, it doesn't matter.
It's even simpler than that.
You use
Marko Rauhamaa writes:
> Jerry Hill :
>
> > except for the fact that there has been 20 years of custom saying that
> > comparing to None with equality is wrong.
>
> "if foo == None" is not wrong in any manner.
Marko, please don't keep asserting falsehoods. It's already been pointed
out in this f
Jerry Hill :
> except for the fact that there has been 20 years of custom saying that
> comparing to None with equality is wrong.
"if foo == None" is not wrong in any manner. It's just that if you are
comfortable with the "is" operator and its semantics, "if foo is None"
is slightly more natural.
Marko Rauhamaa writes:
> Mark Lawrence :
>
> > I'd just like to know why people are so obsessed with identities, I've
> > never thought to use them in 10+ years of writing Python. Do I use the
> > KISS principle too often?
>
> Calmly choosing the right tool for the job is not an obsession.
Pers
Jerry Hill writes:
> if foo == None:
> do_stuff()
>
> The only time it would give you a different result from the "is"
> version is if foo was bound to an object that returned True when
> compared with None.
That's right. Python provides this singleton and then recommends you
compare with ‘i
Mark Lawrence :
> I'd just like to know why people are so obsessed with identities, I've
> never thought to use them in 10+ years of writing Python. Do I use the
> KISS principle too often?
Calmly choosing the right tool for the job is not an obsession.
Marko
--
https://mail.python.org/mailma
On Mon, Mar 3, 2014 at 4:51 PM, Tim Chase wrote:
> There are a couple use-cases I've encountered where "is" matters:
>
> 1) the most popular:
>
> if foo is None:
> do_stuff()
I know this is the one that always comes up, but honestly, I feel like
"is" doesn't matter here. That code would be
On 2014-03-03 21:35, Mark Lawrence wrote:
> I'd just like to know why people are so obsessed with identities,
> I've never thought to use them in 10+ years of writing Python. Do
> I use the KISS principle too often?
There are a couple use-cases I've encountered where "is" matters:
1) the most po
On 03/03/2014 21:10, Ben Finney wrote:
Rustom Mody writes:
Short answer: Avoid using 'is'.
This is bad advice in a Python forum.
The ‘is’ operator is commonly used in Python, so please don't advise
against it in an unqualified “short answer”.
Long answer:
http://www.beyondwilber.ca/heali
Tim Chase writes:
> On 2014-03-04 08:10, Ben Finney wrote:
> > Short answer: Use ‘use’ any time you need to compare object
> > identity. You usually do not need to compare object identity.
Damn it, a snappy response marred by a typo.
> I think there use something wrong with that sentence...unle
On 2014-03-04 08:10, Ben Finney wrote:
> > Long answer:
> > http://www.beyondwilber.ca/healing-thinking/non-identity-korzybski.html
>
> Interesting, but mostly a distraction for the querent here.
>
> Short answer: Use ‘use’ any time you need to compare object
> identity. You usually do not need
Rustom Mody writes:
> Short answer: Avoid using 'is'.
This is bad advice in a Python forum.
The ‘is’ operator is commonly used in Python, so please don't advise
against it in an unqualified “short answer”.
> Long answer:
> http://www.beyondwilber.ca/healing-thinking/non-identity-korzybski.ht
On 3/3/2014 4:42 AM, ast wrote:
Consider following code:
A=7
B=7
A is B
The 'is' operator has three uses, two intended and one not. In
production code, 'is' tests that an object *is* a particular singular
object, such as None or a sentinel instance of class object. In test
code, 'is' can
On Monday, March 3, 2014 3:12:30 PM UTC+5:30, ast wrote:
> hello
> Consider following code:
> >>> A=7
> >>> B=7
> >>> A is B
> True
> I understand that there is a single object 7 somewhere in memory and
> both variables A and B point toward this object 7
> now do the same with a list:
> >>> l1
On 2014-03-03, ast wrote:
> hello
>
> Consider following code:
>
A=7
B=7
A is B
> True
>
> I understand that there is a single object 7 somewhere in memory
Maybe, maybe not. Integer are immutable, so that's allowed but not
required. In CPython, that's true for small integers, but
On Monday, March 3, 2014 3:42:30 AM UTC-6, ast wrote:
> Consider following code:
>
> >>> A=7
> >>> B=7
> >>> A is B
> True
The names A and B are both bound to the same object (7).
You will discover that this is True for all small ints less
than 257; on CPython3.3.4. I just checked it. :)
I
Amit Dev wrote:
> The object is not garbage collected, since there appears to be a cycle
> (between method m2 and A). I would expect this to behave the same as
> having another method "def m2(self): self.m1()", but unfortunately its
> not.
> In above case m2 seems to be in a.__dict__ which is cau
Amit Dev wrote:
> Simple question. If I have the following code:
>
> class A:
> def __init__(self, s):
> self.s = s
> self.m2 = m1
>
> def m1(self):
> pass
>
> if __name__ == '__main__':
> a = A("ads")
> a.m1()
> a = None
>
> The object is not garbag
On 09/12/2010 20:23, Eric Frederich wrote:
I am attempting to automate the building of binding for a 3rd party library.
The functions I'm wrapping all return an integer of whether they
failed and output are passed as pointers.
There can be multiple return values.
So the code that I generate has a
On Sat, 09 Oct 2010 21:00:45 -0700, chad wrote:
> Maybe I'm being a bit dense, but how something like
>
> [cdal...@localhost oakland]$ python
> Python 2.6.2 (r262:71600, May 3 2009, 17:04:44) [GCC 4.1.1 20061011
> (Red Hat 4.1.1-30)] on linux2 Type "help", "copyright", "credits" or
> "license" f
chad writes:
> Maybe I'm being a bit dense, but how something like
>
> [cdal...@localhost oakland]$ python
> Python 2.6.2 (r262:71600, May 3 2009, 17:04:44)
> [GCC 4.1.1 20061011 (Red Hat 4.1.1-30)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> spam
> T
On Oct 9, 5:52 pm, Steven D'Aprano wrote:
> On Sat, 09 Oct 2010 12:44:29 -0700, chad wrote:
> > Given the following...
>
> > [cdal...@localhost oakland]$ python
> > Python 2.6.2 (r262:71600, May 3 2009, 17:04:44) [GCC 4.1.1 20061011
> > (Red Hat 4.1.1-30)] on linux2 Type "help", "copyright", "cre
On Sat, 09 Oct 2010 12:44:29 -0700, chad wrote:
> Given the following...
>
> [cdal...@localhost oakland]$ python
> Python 2.6.2 (r262:71600, May 3 2009, 17:04:44) [GCC 4.1.1 20061011
> (Red Hat 4.1.1-30)] on linux2 Type "help", "copyright", "credits" or
> "license" for more information.
cla
chad writes:
> >>> print one
> <__main__.foo instance at 0xb7f3a2ec>
> >>> print two
> <__main__.foo instance at 0xb7f3a16c>
> >>> one.x
> 1
>
>
> Is 'one' a reference or a name space?
Yes.
It's a reference to an instance of the ‘foo’ type.
That instance is also a namespace; in other words, it
1 - 100 of 178 matches
Mail list logo
