Python-ideas May 2016

python-ideas@python.org

89 participants
43 discussions

Object grabbing
by Robert van Geel 02 May '16

02 May '16

First of all I'm new to this. I tried figuring out if some inquiry like mine below already was posted but I couldn't find it, frankly partly because I don't know what to look for, I'm not sure if there's a name for this idea. I'm not convinced my idea below is solid so apologies if it's naïve but I figured to post it anyway. It has to do with the possibility to fold typical opcodes pairs by introducing a language construct. The idea is to be able to write this code: myobject.a myobject.b myobject.c() myobject.d = 1 like this: using myobject: .a .b .c() .d = 1 The first version would lead to these instructions: LOAD_FAST 0 (self) LOAD_ATTR 0 (a) POP_TOP LOAD_FAST 0 (self) LOAD_ATTR 1 (b) POP_TOP LOAD_FAST 0 (self) LOAD_ATTR 2 (c) CALL_FUNCTION 0 POP_TOP LOAD_CONST 1 (1) LOAD_FAST 0 (self) STORE_ATTR 3 (d) LOAD_CONST 0 (None) the using keyword would grab an internal handle to the object, leading to the ability to reduce the number of opcodes by introducing folded ones: PUSH_HANDLE 0 (myobject) LOAD_HATTR 0 (a) POP_TOP LOAD_HATTR 1 (b) POP_TOP LOAD_HATTR 1 (b) CALL_FUNCTION 0 (c) POP_TOP LOAD_CONST 1 (1) STORE_HATTR 3 (d) POP_HANDLE LOAD_CONST 0 (None) The rationale behind is that both typographically for the programmer this is more elegant than typing the variable name over and again. For the internals of Python it would reduce the number of handled opcodes at the cost of a number of new opcodes: PUSH_HANDLE => pushes object to 'direct handle stack' LOAD_HATTR = LOAD_FAST + LOAD_ATTR STORE_HATTR = LOAD_FAST + STORE_ATTR POP_HANDLE => pops object to 'direct handle stack' Since these pairs are quite numerous this could lead to a speed gain for code that uses a lot of "self." or "object." invocations. Shoot me. Robert

21 48

Re: [Python-ideas] Object grabbing
by Greg Ewing 02 May '16

02 May '16

Joshua Morton wrote: > would something like replacing all attribute access with a > > try: > x > except NameError: > namespace.x # or something like this > > work, or are you saying that since 'namespace' wouldn't be in slots > either, this would fail? I meant that Namespace can't be an ordinary Python object that works without cooperation from the compiler. If the compiler is allowed to recognise the use of Namespace and generate different code, anything is possible. -- Greg

4 3

Object grabbing (was: Re: Python-ideas Digest, Vol 114, Issue 5)
by Robert van Geel 02 May '16

02 May '16

I'm receiving digests and seem to not have each individual mail, so here's a digested response: One side of this that's not discussed is the possible optimization. I can imagine if you've got a lot of objectproperty write and -reads this could actually make certain use cases a lot faster such as this one, saving 6 opcodes: def __init__(self, left, top, width, height, content): self.left = left self.top = top self.width = width self.height = height self.content = content.upper() self.decideColors() self.draw() versus: def __init__(self, left, top, width, height, content): with self: .left = left .top = top .width = width .height = height .content = content.upper() .decideColors() .draw() The suggestion that you could accomplish this with a (peephole) optimizer does not seem quite correct to me: x = myobject.b() ... z = myobject.c() does not necessarily have a consistent pointer to myobject although it would require some acrobatics to change them in a way that can not be seen by an optimizer. You can think about exec() or even another thread intervening into a generator function, not something I would do but who knows. The advantage of the construct is that the .dotted variable is guaranteed to point to the same physical object in memory with an increased reference count during the statement and a decrease happening at dedent. Django would break when the 'using' keyword would be used for that, but the choice of keyword is arbitrary. Maybe an extended use of the 'with' word would be elegant, when the object would not have an __enter__ and/or __exit__ function it could still run for the purpose of this mechanism. The disadvantage is that you could not use the with construct for this purpose only without also triggering the __enter__ function. On 5/2/2016 2:49 PM, python-ideas-request(a)python.org wrote: > [cut] > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 2 May 2016 14:12:28 +0200 > From: Jo?o Santos <jmcs(a)jsantos.eu> > To: Robert van Geel <robert(a)bign.nl> > Cc: python-ideas(a)python.org, "Franklin? Lee" > <leewangzhong+python(a)gmail.com> > Subject: Re: [Python-ideas] Object grabbing > Message-ID: > <CAH_XWH3vSfvYZit3SYdJ6K==B3iQiY58CbfTpga=shav_EaDzw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > That is matter of experience, I already lost too many hours of my life > looking for weird bugs caused by misspellings and missing commas, and I > don't even work with people new to python. > On 2 May 2016 14:04, "Robert van Geel" <robert(a)bign.nl> wrote: > > ------------------------------ Message: 4 Date: Mon, 2 May 2016 > 13:48:17 +0100 From: SW <walker_s(a)hotmail.co.uk> To: > python-ideas(a)python.org Subject: Re: [Python-ideas] Object grabbing > Message-ID: <BLU436-SMTP21412FBE1145250B8A38DE8B8790(a)phx.gbl> > Content-Type: text/plain; charset="utf-8" On 02/05/16 13:20, Koos > Zevenhoven wrote: >> On Mon, May 2, 2016 at 2:48 PM, Jo?o Santos <jmcs(a)jsantos.eu> wrote: >>> I think the ".d = 1" statement feels like a bug waiting to happen. It's very >>> easy to miss a dot. >>> >> I suppose that's a valid concern, especially regarding assignments, >> because the code typically would still run. But in the beginning of >> the line, it is usually quite easy to see if there's a dot or not, >> assuming a fixed-width font and proper indenting. > It may be easy to see if there's a dot or not, but it may not be easy to > tell whether there /should/ be a dot when there isn't. > > e.g. > <snip> > .configuration = {'yes': 'no'} > vs > <snip> > configuration = {'yes': 'no'} > > When you might have later in the code something that assigns to a > variable with the same name, and/or operates on that variable I think > it'd become more difficult to determine. > > Thanks, > S > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > https://mail.python.org/mailman/listinfo/python-ideas > > > ------------------------------ > > End of Python-ideas Digest, Vol 114, Issue 5 > ********************************************

4 5

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Python-ideas May 2016