Summary: rejection of 'dynamic attribute' syntax
Guido van Rossum wrote:
This seems to be the overwhelming feedback at this point, so I'm withdrawing my support for the proposal. I hope that Ben can write up a PEP and mark it rejected, to summarize the discussion; it's been a useful lesson.
The feedback is clear, yes. The "new syntax seems like overkill" camp has become dominant, and I certainly think these are very valid arguments. Gentle support remains scattered here and there, but the consensus has emerged. I will summarise all this into the PEP and mark it as rejected. Still, the discussion was useful, I thought. Thanks for the interest. To respond, for the record, to some of the specific points recently raised: glyph@divmod.com:
I really, really wish that every feature proposal for Python had to meet some burden of proof [...]. I suspect this would kill 90% of "hey wouldn't this syntax be neat" proposals on day zero [...]
This is what I understood the initial posting to python-ideas to be about. If the feedback from there had been "that's a stupid idea", then that would have been the end of it. I think it's a good thing that there's the python-ideas mechanism for speculative suggestions. I like the "attrview" or "attrs" wrapper idea, with the example given by Larry Hastings:
setattr(self, method_name, getattr(self.metadata, method_name)) [...] would be: attrview(self)[method_name] = attrview(self.metadata)[method_name]
As others point out, it's very clean, captures the intended uses well, and has the great advantage of having easily-added backwards compatibility. I might start using it :-) If the people who suggested and refined this were to put it in a PEP, I'd be in favour. Guido van Rossum wrote:
I missed discussion of the source of the 1%. Does it slow down pystone or other benchmarks by 1%? That would be really odd, since I can't imagine that the code path changes in any way for code that doesn't use the feature. Is it that the ceval main loop slows down by having two more cases?
That seems to be it, yes. I tested this by leaving the grammar, compilation, and AST changes in, and conditionally compiling just the three extra cases in the ceval main loop. Measurements were noisy though, as Josiah Carlson has also experienced:
I've found variations of up to 3% in benchark times that seemed to be based on whether I was drinking juice or eating a scone while working.
I'm afraid I can't remember what I was eating or drinking at the time I did my tests. (Thanks also for the kind words regarding my summaries etc. Having caused all the fuss in the first place I felt obliged to try to make myself a bit useful :-) Ben.
Ben North wrote: [...]
Guido van Rossum wrote:
I missed discussion of the source of the 1%. Does it slow down pystone or other benchmarks by 1%? That would be really odd, since I can't imagine that the code path changes in any way for code that doesn't use the feature. Is it that the ceval main loop slows down by having two more cases?
That seems to be it, yes. I tested this by leaving the grammar, compilation, and AST changes in, and conditionally compiling just the three extra cases in the ceval main loop. Measurements were noisy though, as Josiah Carlson has also experienced:
I've found variations of up to 3% in benchark times that seemed to be based on whether I was drinking juice or eating a scone while working.
I'm afraid I can't remember what I was eating or drinking at the time I did my tests.
A further data point is that modern machines seem to give timing variabilities due to CPU temperature variations even if you always eat exactly the same thing. One of the interesting facts to emerge from the Need for Speed sprint last year is that architectural complexities at many levels make it extremely difficult nowadays to build a repeatable benchmark of any kind.
(Thanks also for the kind words regarding my summaries etc. Having caused all the fuss in the first place I felt obliged to try to make myself a bit useful :-)
Your management of the discussion process has indeed been exemplary. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007
Steve Holden schrieb:
Ben North wrote: [...]
Guido van Rossum wrote:
I missed discussion of the source of the 1%. Does it slow down pystone or other benchmarks by 1%? That would be really odd, since I can't imagine that the code path changes in any way for code that doesn't use the feature. Is it that the ceval main loop slows down by having two more cases?
That seems to be it, yes. I tested this by leaving the grammar, compilation, and AST changes in, and conditionally compiling just the three extra cases in the ceval main loop. Measurements were noisy though, as Josiah Carlson has also experienced:
I've found variations of up to 3% in benchark times that seemed to be based on whether I was drinking juice or eating a scone while working.
I'm afraid I can't remember what I was eating or drinking at the time I did my tests.
A further data point is that modern machines seem to give timing variabilities due to CPU temperature variations even if you always eat exactly the same thing.
One of the interesting facts to emerge from the Need for Speed sprint last year is that architectural complexities at many levels make it extremely difficult nowadays to build a repeatable benchmark of any kind.
My personal experience using a dual core machine (on WinXP) is that timing results become much more reproducible. Thomas
Greg Ewing wrote:
Steve Holden wrote:
A further data point is that modern machines seem to give timing variabilities due to CPU temperature variations even if you always eat exactly the same thing.
Oh, great. Now we're going to have to run our benchmarks in a temperature-controlled oven...
... with the fan running at constant speed :) -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007
On Thursday 15 February 2007 21:48, Steve Holden wrote:
Greg Ewing wrote:
Steve Holden wrote:
A further data point is that modern machines seem to give timing variabilities due to CPU temperature variations even if you always eat exactly the same thing.
Oh, great. Now we're going to have to run our benchmarks in a temperature-controlled oven...
... with the fan running at constant speed :)
Unless the fans are perfectly balanced, small changes in gravity are going to affect the rate at which they spin. So I guess the position of the moon will affect it :-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 15, 2007, at 6:27 AM, Anthony Baxter wrote:
On Thursday 15 February 2007 21:48, Steve Holden wrote:
Greg Ewing wrote:
Steve Holden wrote:
A further data point is that modern machines seem to give timing variabilities due to CPU temperature variations even if you always eat exactly the same thing.
Oh, great. Now we're going to have to run our benchmarks in a temperature-controlled oven...
... with the fan running at constant speed :)
Unless the fans are perfectly balanced, small changes in gravity are going to affect the rate at which they spin. So I guess the position of the moon will affect it :-)
Except on Tuesdays. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRdRKcXEjvBPtnXfVAQJUNAP/ebCrt2RV2pmKTElHUyzWIWxPFCqIiIuF FDkiSx4x/ZZtOcdXlJHOA6lBWjuPAxe1jxE9BVpNy/6qCtky+mpnM5nXqIeAlQUk XByguxKmsxF4HWSlk6GJ4hZWbZqsMdFiw8WZttCihQJwmr58rDMTUKRHss2IPOhL egl76Tg1gE4= =OTwQ -----END PGP SIGNATURE-----
Barry Warsaw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 15, 2007, at 6:27 AM, Anthony Baxter wrote:
On Thursday 15 February 2007 21:48, Steve Holden wrote:
Greg Ewing wrote:
Steve Holden wrote:
A further data point is that modern machines seem to give timing variabilities due to CPU temperature variations even if you always eat exactly the same thing.
Oh, great. Now we're going to have to run our benchmarks in a temperature-controlled oven...
... with the fan running at constant speed :)
Unless the fans are perfectly balanced, small changes in gravity are going to affect the rate at which they spin. So I guess the position of the moon will affect it :-)
Except on Tuesdays. [off-list, because "this is getting silly" ...]
Anthony's antipodean antecedents (alliteration, all right?) remind me we will also have to factor Coriolis effects in. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007
Steve Holden wrote:
Barry Warsaw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 15, 2007, at 6:27 AM, Anthony Baxter wrote:
Greg Ewing wrote:
Steve Holden wrote:
A further data point is that modern machines seem to give timing variabilities due to CPU temperature variations even if you always eat exactly the same thing. Oh, great. Now we're going to have to run our benchmarks in a temperature-controlled oven... ... with the fan running at constant speed :) Unless the fans are perfectly balanced, small changes in gravity are going to affect the rate at which they spin. So I guess the
On Thursday 15 February 2007 21:48, Steve Holden wrote: position of the moon will affect it :-) Except on Tuesdays. [off-list, because "this is getting silly" ...] Apparently the "off-list" part was a desire that didn't become reality. Sorry, I'll shut up now.
regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007
Anthony Baxter wrote:
Unless the fans are perfectly balanced, small changes in gravity are going to affect the rate at which they spin. So I guess the position of the moon will affect it :-)
A standard gravitational field could also be important to eliminate relativistic effects. So we need to standardise latitude/longitude/altitude, time of year and phase of moon. Better check atmospheric pressure and humidity, too, just to be on the safe side. -- Greg
participants (6)
-
Anthony Baxter -
Barry Warsaw -
Ben North -
Greg Ewing -
Steve Holden -
Thomas Heller