is None or == None ?
in [Python]
|
Prev: 2to3 on Mac - unknown encoding: mbcs
Next: safely returning objects from a Process to the parent through aQueue()
From: Rami Chowdhury on 6 Nov 2009 15:19 On Fri, 06 Nov 2009 11:50:33 -0800, Alf P. Steinbach <alfps(a)start.no> wrote: > * Rami Chowdhury: >> On Fri, 06 Nov 2009 09:28:08 -0800, Alf P. Steinbach <alfps(a)start.no> >> wrote: >> >>> * Rami Chowdhury: >>>> On Fri, 06 Nov 2009 08:54:53 -0800, Alf P. Steinbach <alfps(a)start.no> >>>> wrote: >>>> >>>>> But wow. That's pretty hare-brained: dynamic allocation for every >>>>> stored value outside the cache range, needless extra indirection for >>>>> every operation. >>>>> >>>> Perhaps I'm not understanding this thread at all but how is dynamic >>>> allocation hare-brained, and what's the 'needless extra indirection'? >>> >>> Dynamic allocation isn't hare-brained, but doing it for every stored >>> integer value outside a very small range is, because dynamic >>> allocation is (relatively speaking, in the context of integer >>> operations) very costly even with a (relatively speaking, in the >>> context of general dynamic allocation) very efficient small-objects >>> allocator - here talking order(s) of magnitude. >> Well, sure, it may seem that way. But how large a cache would you want >> to preallocate? I can't see the average Python program needing to use >> the integers from -10000 to 10000, for instance. In my (admittedly >> limited) experience Python programs typically deal with rather more >> complex objects than plain integers. > > Uhm, you've misunderstood or failed to understand something basic, but > what? Oh, I see, you were referring to a tagging scheme as an alternative. Sorry for the misunderstanding. > > Well it's an out-of-context quote, but t'was about creating the value > object that a variable contains a pointer to with the current CPython > implementation. > Again, perhaps I'm just misunderstanding what you're saying, but as I understand it, in CPython if you're looking for the value of a PyIntObject, that's stored right there in the structure, so no value object needs to be created... -- Rami Chowdhury "Never attribute to malice that which can be attributed to stupidity" -- Hanlon's Razor 408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
From: Alf P. Steinbach on 6 Nov 2009 15:49 * Mel: > Alf P. Steinbach wrote: >> Note that the object implementation's complexity doesn't have to affect to >> any other code since it's trivial to provide abstract accessors (even >> macros), i.e., this isn't part of a trade-off except if the original >> developer(s) had limited >> resources -- and if so then it wasn't a trade-off at the language design >> level but a trade-off of getting things done then and there. > > But remember what got us in here: your belief (which followed from your > assumptions) that computing `is` required testing the object types. Yes, I couldn't believe what I've now been hearing. Uh, reading. :-) > You > might optimize out the "extra indirection" to get an object's value, but > you'd need the "extra indirection" anyway to find out what type it was > before you could use it. No, that type checking is limited (it just checks whether the type is special cased), doesn't involve indirection, and is there anyway except for 'is'. It can be moved around but it's there, or something more costly is there. 'is' is about the only operation you /can/ do without checking the type, but I don't see the point in optimizing 'is' at cost of all other operations on basic types. Cheers & hth., - Alf
From: Carl Banks on 6 Nov 2009 15:53 On Nov 6, 11:41 am, "Alf P. Steinbach" <al...(a)start.no> wrote: > Note that the object implementation's complexity doesn't have to affect to any > other code since it's trivial to provide abstract accessors (even macros), i.e., > this isn't part of a trade-off except if the original developer(s) had limited > resources -- and if so then it wasn't a trade-off at the language design level > but a trade-off of getting things done then and there. I totally disagree with this; it would be like squaring the implementation complexity. It is far from "trivial" as you claim. Even if it were just a matter of accessor macros (and it isn't) they don't write themselves, especially when you focused on speed, so that's a non-trivial complexity increase already. But you besides writing code you now have reading code (which is now cluttered with all kinds of ugly accessor macros, as if the Python API wasn't ugly enough), debugging code, maintaining code, understanding semantics and nuances, handling all the extra corner cases. To say it's trivial is absurd. > > C# made a > > different trade-off, choosing a more complex implementation, a > > language with two starkly different object semantic behaviors, so as > > to allow better performance. > > Don't know about the implementation of C#, but whatever it is, if it's bad in > some respect then that has nothing to do with Python. C# is a prototypical example of a language that does what you were suggesting (also it draws upon frameworks like COM, which you mentioned) so it is a basis of comparison of the benefits versus drawbacks of the two approaches. Carl Banks
From: Stefan Behnel on 7 Nov 2009 02:20 mk, 06.11.2009 15:32: > Stefan Behnel wrote: >> class Test(object): >> def __eq__(self, other): >> return other == None >> >> print Test() == None, Test() is None > > Err, I don't want to sound daft, but what is wrong in this example? It > should work as expected: > > >>> class Test(object): > ... def __eq__(self, other): > ... return other == None > ... > >>> Test() is None > False > >>> Test() == None > True Yes, and it shows you that things can compare equal to None without being None. > Or perhaps your example was supposed to show that I should test for > identity with None, not for value with None? Instead of "value" you mean "equality" here, I suppose. While there are certain rare use cases where evaluating non-None objects as equal to None makes sense, in normal use, you almost always want to know if a value is exactly None, not just something that happens to return True when calculating its equality to None, be it because of a programmer's concious consideration or buggy implementation. Stefan
From: Steven D'Aprano on 7 Nov 2009 10:05
On Fri, 06 Nov 2009 16:51:18 +0100, Marco Mariani wrote: > Using "x is y" with integers > makes no sense and has no guaranteed behaviour AFAIK Of course it makes sense. `x is y` means *exactly the same thing* for ints as it does with any other object: it tests for object identity. That's all it does, and it does it perfectly. Python makes no promise whether x = 3; y = 3 will use the same object for both x and y or not. That's an implementation detail. That's not a problem with `is`, it is a problem with developers who make unjustified assumptions. -- Steven |