Path: csiph.com!usenet.pasdenom.info!news.albasani.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!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.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'explicitly': 0.04; 'memory.': 0.05; 'alignment': 0.07; 'item.': 0.07; 'objects,': 0.07; 'reason,': 0.07; 'python': 0.09; '32-bit': 0.09; 'counting': 0.09; 'dummy;': 0.09; 'garbage': 0.09; 'likewise': 0.09; 'slices': 0.09; 'subject:()': 0.09; 'tuple': 0.09; 'typedef': 0.09; '3.3.': 0.16; 'oct': 0.16; 'py_ssize_t': 0.16; 'subject:array': 0.16; 'mon,': 0.16; 'wrote:': 0.17; 'bytes': 0.17; 'odd': 0.17; 'pointer': 0.17; 'object.': 0.22; 'struct': 0.22; 'tuples': 0.22; 'references': 0.23; 'this:': 0.23; "i've": 0.23; 'header': 0.24; 'header:In-Reply-To:1': 0.25; 'looks': 0.26; 'message- id:@mail.gmail.com': 0.27; 'chris': 0.28; 'objects': 0.29; 'words': 0.29; 'source': 0.29; "i'm": 0.29; 'received:209.85.215.46': 0.30; 'figure': 0.30; 'code': 0.31; 'implement': 0.32; 'getting': 0.33; 'certain': 0.33; 'to:addr :python-list': 0.33; 'received:google.com': 0.34; 'list': 0.35; 'otherwise.': 0.35; 'stores': 0.35; 'expected': 0.35; 'pm,': 0.35; 'received:209.85': 0.35; 'there': 0.35; 'but': 0.36; 'be.': 0.36; 'uses': 0.37; 'why': 0.37; 'rather': 0.37; 'received:209': 0.37; 'subject:: ': 0.38; 'object': 0.38; 'some': 0.38; 'to:addr:python.org': 0.39; 'header:Received:5': 0.40; 'note:': 0.64; 'union': 0.66; 'special': 0.73; 'grow': 0.74; 'to:name:python': 0.84; 'imagine': 0.96 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=AuwR0SuSiR4SugYTqNnX1D1dLwkHXr5CWIUdRvb6oog=; b=lQSmWwrV4n81qT2zrgBn/W5cDavqzbXhMIRrsIH88/glJngkmtceo3ZHx43tbMobr4 0KeRi1oX/rGT8ytkGBauknxms9gXYXu5nff6fganNYD7WVdDAREmMNUushOWjeuPI6ZU wkgde6amX2safOYbOUBqtIA+Bekz1Ss/MD2vHVeUtlb5AMN+dXoR60+j8y4XBA8wiVqu mxZwP43zgGgzKotgiZ10i7aYjmoNXsngQ/Xw/24eynQqIHTV45S/opsSK/N4NQjTOh9Y hTXY+e7cFYwi5KFTOmVbPipu+1HQw4PSQzmzSdI1NEWqn6nUv0kdcolgluAOYLaOqTjB deZg== MIME-Version: 1.0 In-Reply-To: References: <6998a955-7b34-4f4f-b8d6-62d1028f7561@googlegroups.com> <4c024364-84df-403b-8b9e-4a4c8f06121c@googlegroups.com> <508e6649$0$29967$c3e8da3$5496439d@news.astraweb.com> <508E1BC9.3000308@r3dsolutions.com> <508EC428.5080808@r3dsolutions.com> From: Ian Kelly Date: Tue, 30 Oct 2012 01:21:46 -0600 Subject: Re: Negative array indicies and slice() To: Python Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 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: 30 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1351581739 news.xs4all.nl 6901 [2001:888:2000:d::a6]:52141 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:32473 On Mon, Oct 29, 2012 at 7:49 PM, Chris Kaynor wrote: > NOTE: The above is taken from reading the source code for Python 2.6. > For some odd reason, I am getting that an empty tuple consists of 6 > pointer-sized objects (48 bytes on x64), rather than the expected 3 > pointer-sized (24 bytes on x64). Slices are showing up as the expected > 5 pointer-sized (40 bytes on x64), and tuples grow at the expected 1 > pointer (8 bytes on x64) per item. I imagine I am missing something, > but cannot figure out what that would be. I'm likewise seeing 4 extra words in tuples in 32-bit Python 3.3. What I've found is that for tuples and other collection objects, the garbage collector tacks on an extra header before the object in memory. That header looks like this: typedef union _gc_head { struct { union _gc_head *gc_next; union _gc_head *gc_prev; Py_ssize_t gc_refs; } gc; long double dummy; /* force worst-case alignment */ } PyGC_Head; gc_next and gc_prev implement a doubly-linked list that the garbage collector uses to explicitly track this object. gc_refs is used for counting references during a garbage collection and stores the GC state of the object otherwise. I'm not entirely certain why collection objects get this special treatment, but there you have it.