Path: csiph.com!usenet.pasdenom.info!dedibox.gegeweb.org!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!usenet-fr.net!nerim.net!novso.com!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.001 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'python,': 0.02; 'explicitly': 0.04; 'subject:Python': 0.05; 'variable,': 0.07; 'python': 0.09; 'explanation': 0.09; 'identifier': 0.09; 'naturally': 0.09; 'pointers': 0.09; 'unnamed': 0.09; 'aug': 0.13; 'sat,': 0.15; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'heap': 0.16; 'identifiers': 0.16; 'pyobject': 0.16; 'subject:Objects': 0.16; 'tracebacks': 0.16; 'variable.': 0.16; "where's": 0.16; 'wrote:': 0.17; 'pointer': 0.17; 'memory': 0.18; '(or': 0.18; 'trying': 0.21; 'received:209.85.214.174': 0.21; 'name;': 0.22; 'work,': 0.22; 'work.': 0.23; 'machine': 0.24; 'header:In-Reply-To:1': 0.25; 'leave': 0.26; 'c++': 0.27; 'message-id:@mail.gmail.com': 0.27; "doesn't": 0.28; 'about.': 0.29; "d'aprano": 0.29; 'steven': 0.29; 'objects': 0.29; 'class': 0.29; 'addresses': 0.32; 'aside': 0.32; 'not.': 0.32; 'could': 0.32; 'to:addr:python-list': 0.33; 'received:google.com': 0.34; 'needed': 0.35; 'whatever': 0.35; 'same.': 0.35; 'doing': 0.35; 'pm,': 0.35; 'received:209.85': 0.35; 'there': 0.35; 'really': 0.36; 'but': 0.36; 'data.': 0.36; 'does': 0.37; 'two': 0.37; 'virtual': 0.37; 'received:209': 0.37; 'data': 0.37; 'subject:: ': 0.38; 'talk': 0.38; 'to:addr:python.org': 0.39; 'received:209.85.214': 0.39; 'where': 0.40; 'header:Received:5': 0.40; 'places': 0.61; 'different': 0.63; 'managing': 0.64; 'levels': 0.66; 'talking': 0.66; 'fact,': 0.69; 'benefit': 0.70; 'suited': 0.71; 'confusing': 0.84; 'typically,': 0.84; 'hand,': 0.97 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7gnf6y8AIE29SqiOhMYnHukD27/FGbvLsOFB+etltpM=; b=z5El6Z+7X2X1kNNLcbDCikq8KOXkPdWgNTQ++Rwb3k9qVROBcqcqARk6NGxszk6sZF 3HUQPDi2pzwHzzSunTMPMaeu+yeD5u2xmU5m34+ZpjB1GJTKxX/BipUMZW86QuRnFxNk ZHItucZ3al9qz9DRsQwmvtqqecxghbtlYsUd6SccReTIM9kVhvaKanEY/mH1wWT1W4ji fXUoliK9z+S51pQBkU6J7H4CdM0IreRYo9KZuast634meskXsviNEq8xkwGgd/A+099j xxV/J1A5bXFzJ5tciTZiTrC4jYCPEGEbAdsMrA1P3NfKuaMcQLRebg9KUrcxxr8g7mF3 l6bA== MIME-Version: 1.0 In-Reply-To: <503840c5$0$6574$c3e8da3$5496439d@news.astraweb.com> References: <18409992-1e28-4721-8e64-60c69668da4e@googlegroups.com> <87d32i1ntc.fsf@benfinney.id.au> <5035d3e4$0$1645$c3e8da3$76491128@news.astraweb.com> <50366ec8$0$6574$c3e8da3$5496439d@news.astraweb.com> <503840c5$0$6574$c3e8da3$5496439d@news.astraweb.com> Date: Sat, 25 Aug 2012 16:34:50 +1000 Subject: Re: Objects in Python From: Chris Angelico To: python-list@python.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 36 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1345876494 news.xs4all.nl 6979 [2001:888:2000:d::a6]:43813 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:27852 On Sat, Aug 25, 2012 at 1:04 PM, Steven D'Aprano wrote: > You're confusing two different levels of explanation here. On the one > hand, you're talking about C semantics, where you are explicitly > responsible for managing unnamed data via indirection (pointers). > Typically, the *pointers* get given names, the data does not. > > On the other hand, you talk about Python, where you have no access at all > to the pointers and memory addresses. You manage the data you actually > care about by giving them names, and then leave it up to the Python > virtual machine to transparently manage whatever indirection is needed to > make it work. > ... > * in C, I care about identifiers ("names") in order to explicitly manage > addresses and pointers as a means to reach the data I actually care about; > > * in Python, I care about identifiers in order to reach the data I > actually care about. Yet the two are almost the same. Python objects don't have names, they just have their own data. (Leaving aside functions, which have their names as data for the benefit of tracebacks and such.) A C pointer has a name; a Python identifier has (or is, if you like) a name. They're very different in how you use them only because C doesn't naturally work with everything on the heap and pointers everywhere. In fact, when I was interfacing Python and C, there were a few places where I actually handed objects to Python and kept manipulating them, simply because the Python data model suited what I was trying to do; but what I was doing was using PyObject *some_object as though it were a Python variable. I even did up a trivial C++ class that encapsulated the INCREF/DECREF work, so my LocalPyObject really could be treated as a local variable, Python-style. Where's the difference? ChrisA