[Python-Dev] PATCH: Fast globals/builtins lookups for 2.6
I've posted a patch here:
http://bugs.python.org/issue1518
for 2.6a0 that speeds up LOAD_GLOBAL to where it's just barely slower
than LOAD_FAST for both globals and builtins. It started life here, in
Python-ideas:
http://mail.python.org/pipermail/python-ideas/2007-November/001212.html
The idea is to cache pointers to dictionary entries rather than
dictionary values as is usually suggested for speeding up globals. In my
original approach, every dictionary would keep a list of observers
that it would notify when an entry pointer became invalid. However, the
surgery on PyDictObject became too invasive, to the point where the new
code was affecting performance of unrelated code paths. (It was probably
caching issues.) It also made some (very rare) operations on builtins
and globals very, very slow.
The new approach tags each PyDictObject with a version: a 64-bit value
that is incremented for every operation that invalidates at least one
entry pointer. (Those are inserting set, delete, pop, clear and resize.
Non-inserting set and get are unaffected.) In this approach, changes to
PyDictObject are uninvasive and do not affect performance in any
measurable way (as far as I can tell).
Every function has a PyFastGlobalsObject, which keeps entry pointers for
everything in co_names and tracks its dicts' versions so it can update
the pointers when one might have become invalid. LOAD_GLOBALS uses the
PyFastGlobalsObject to get globals and builtins by name index rather
than by string key.
With the patch, Python behaves differently in these two ways (as far as
I can tell):
1. As before, a __builtins__ ({'None': None}) is created for frames
whose globals do not have one. Unlike before, it's added to the globals
dict rather than just kept internally. This made implementation easier -
I don't think it's a big deal (but I might be wrong).
2. A change of __builtins__ (its value, not its contents) always appears
at the beginning of a stack frame. (Before, changing __builtins__ in a
module would be undetectable if function calls were kept within that
module.) This is likely of little importance.
I'd love to see it included. I have donned my asbestos underwear and my
best chain mail shirt and I'm begging for comments.
Neil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing the new and types modules
[EMAIL PROTECTED] wrote: Sorry if this is a dumb question, but are there actually good reasons to remove types? Mainly because it is an unrelated grab bag of types that could be put in more topical locations - what they're for is more interesting than the mere fact that they happen to be types. As it turns out, the cleanup for Py3k (removing the members which are merely aliases for existing names) has already cut it down to only a few types which are closely related to the interpreter core. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Greg Ewing wrote: __uberglobal__ Since Python 3.0 supports all unicode chars I vote for __überglobal__. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Memory benchmarking?
Hi all, is there a good, or standard memory benchmarking system for Python? pybench doesn't return significantly different results when Python 2.6 is compiled with pymalloc and without pymalloc. Thinking on it, I'm not too surprised -- pybench probably benchmarks a lot of stuff -- but some guidance on how/whether to benchmark different memory allocation schemes would be welcome. thanks, --titus refs: http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=105colspec=ID%20Status%20Summary http://evanjones.ca/memoryallocator/ http://www.advogato.org/person/wingo/diary/225.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Statsvn output for /python/branches/py3k
Brett Cannon wrote: On Nov 28, 2007 3:25 PM, Joseph Armbruster [EMAIL PROTECTED] wrote: All, I was looking at statsvn today at work and gave it a test-run on a repo there. I wondered what it would look like for python3k. And... here are the results: http://www.joevial.com/statsvn/ Interesting. Unfortunately no one gets credit for ripping out code. =( And svnmerge committers get lots of LoC credits. Thomas's 58k line commit in September must have taken a while :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Christian Heimes wrote: Greg Ewing wrote: __uberglobal__ Since Python 3.0 supports all unicode chars I vote for __überglobal__. Make it untypeable to most Americans so as to discourage use? If that's what we're going for, I suggest the somewhat more self-documenting and less impossible __the_dictionary_where_all_the_builtins_are_now__. Seriously, though, I really liked __universal__. It's part of a theme: local global universal, and it communicates itself well. __root__ and its ilk don't bring anything concrete to mind, just abstract trees. I don't think of namespaces as trees when I'm coding a function - they're more like layers or overlays at that level. So, a +0.01 from me (after weighting for lurkerhood) for __universal__. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Given that the *effect* of __builtins__ is to make the contents of the __builtin__ module implicitly available in every module's global namespace, why not call it __implicit__? I really don't like all of these __root__ inspired names, because __builtin__ isn't the root of any Python hierarchy that I know of. import sys import __builtin__ __builtin__.sys Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'module' object has no attribute 'sys' The builtin namespace doesn't know anything about other modules, the current module's global namespace, the current function's local variables, or much of anything really. To me, the concept of root in a computing sense implies a node from which you can reach every other node - from the root of the filesystem you can get to every other directory, as the root user you can access any other account, etc. To those that like these names, what do you consider __root__ to be the root of? Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Memory benchmarking?
On 2007-11-29 11:52, Titus Brown wrote: Hi all, is there a good, or standard memory benchmarking system for Python? pybench doesn't return significantly different results when Python 2.6 is compiled with pymalloc and without pymalloc. Thinking on it, I'm not too surprised -- pybench probably benchmarks a lot of stuff -- but some guidance on how/whether to benchmark different memory allocation schemes would be welcome. pybench focuses on runtime performance, not memory usage. It's way of creating and deleting objects is also highly non-standard when compared to typical use of Python in real life applications. It's also rather difficult to benchmark memory allocation, since most implementations work with some sort of pre-allocation, buffer pools or free lists. If you want to use a similar approach as pybench does, ie. benchmark small parts of the interpreter instead of generating some grand total, then you'd probably have to do this by spawning a separate process per test. refs: http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=105colspec=ID%20Status%20Summary http://evanjones.ca/memoryallocator/ http://www.advogato.org/person/wingo/diary/225.html -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 29 2007) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Neil Toronto wrote: Since Python 3.0 supports all unicode chars I vote for __überglobal__. Make it untypeable to most Americans so as to discourage use? If that's what we're going for, I suggest the somewhat more self-documenting and less impossible __the_dictionary_where_all_the_builtins_are_now__. :) OK, let's get serious again. Seriously, though, I really liked __universal__. It's part of a theme: local global universal, and it communicates itself well. __root__ and its ilk don't bring anything concrete to mind, just abstract trees. I don't think of namespaces as trees when I'm coding a function - they're more like layers or overlays at that level. You are making a very good point! Thank you, you have added a new perspective to the discussion. :) I tend to agree that local, nonlocal, global and the-other-thingie are more like the layers of an onion than a tree. It makes sense to me. The name lookup starts at the local level and goes all the way out until it reaches the universal level. Or does it go in until it reaches the core of the onion? It's a matter of perspective. __universal__ or __core__ ? Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Nov 28, 2007 4:20 PM, Christian Heimes [EMAIL PROTECTED] wrote: What name do you prefer? I'm +1 with Raymond on __root__ but I'm still open for better suggestions. Perhaps __basic__? Fredrik ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
This is an interesting thread, here is my 1c :-) Unless one is feeling chronologically challenged, it is always the __last__ layer looked in as Christian Heimes described, so maybe __lastns__ or __latter__, or even __zns__. Perhaps __final__ or __finalns__ sounds too similar to finally:. How about __inbuilt__ :-? I don't like __finish__, __close__, __terminal__, __integral__ too ambiguous. Poll summary so far (but without vote tally, and sorry if I missed any), including the ones above. Rejected: __builtin__ GvR I want to keep both concepts __session__ GvR too many unrelated meanings __python__ GvR But ... *everything* becomes a Python thingie. Humorous: __guts__ __pythongastric__ __the_dictionary_where_all_the_builtins_are_now__ __telescope__ __uberglobal__ With and without umlaut __zns__ Cryptic / confusing: __close__ __final__ __finalns__ __finish__ __global__ __inbuilt__ __integral__ __rootns__ __terminal__ The others: __basic__ __builtin_namespace__ __core__ __default_root__ __fixtures__ __implicit__ __inject_builtins__ __lang__ __last__ __lastns__ __latter__ __outer__ __py__ __pythoncore__ __pythonroot__ __root__ This one is popular but has beed described as too short __root_dict__ __rootdict__ __root_globals__ __rootnames__ __root_namespace__ __syswide__ __top__ __universal__ +0.2 from me I hope this helps to have them all in one list. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Nick Coghlan wrote: Function locals, module globals and program universals would make more sense to me - outer layers have a broader scope than inner layers. __universal__ rhymes with the other __*al__ names, too. I'm shifting my vote from __root__ to __universal__. All hail the Aussies! :) Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Thu, 29 Nov 2007, Graham Horler wrote: Perhaps someone here can draw some inspiration from __monty__ python's flying __circus__. It would be nice to have a name with a pythonic __ground__. Unfortunately that show is not my __staple__ entertainment, and although I have a __general__ idea what the show's about, it needs a __canonic__ understanding of its __founding__ __elements__ in order to be used for __primary__ ideas. For my part, I like __universal__. I was going to suggest __cosmological__ to leave space in case we need to put something between __global__ and (what is now called) __builtin__, but then I remembered the Galaxy Song, and thought of __galactic__ for that eventuality. I wonder how much you could sell the naming rights for? i.e. call it __[name of sponsor]__. Python's pretty popular, such advertising should be worth something PS: I actually do like __universal__. The rest may be somewhat addled. Isaac Morland CSCF Web Guru DC 2554C, x36650WWW Software Specialist ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Are we scraping the __bottom__ of the English language __barrel__? Perhaps someone here can draw some inspiration from __monty__ python's flying __circus__. It would be nice to have a name with a pythonic __ground__. Unfortunately that show is not my __staple__ entertainment, and although I have a __general__ idea what the show's about, it needs a __canonic__ understanding of its __founding__ __elements__ in order to be used for __primary__ ideas. Sorry, went mad for a few seconds there. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Statsvn output for /python/branches/py3k
Nick Coghlan wrote: And svnmerge committers get lots of LoC credits. Thomas's 58k line commit in September must have taken a while :) Exactly! Most of my LoC credits must either come from svnmerge or my work on PCBuild9. Visual Studio's project xml files contain a *lot* of space and meaningless lines. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssl module integration with asyncore
On 29 Nov, 06:00, Bill Janssen [EMAIL PROTECTED] wrote: I think it's simpler to let the SSL module do it, even though it comes at the expense of blocking the thread till the handshake is complete. That's essentially what happens already. The question is whether the SSL setup code is allowed to block the non-blocking socket till the SSL handshake is complete. No, the SSL code should NOT be allowed to block anything in any case, even though the handshake is still not completed, in which case just retry it at a later time. Meanwhile the application must be able to do other things, like read or write from other sockets. If the handshake would complete in 1 second that would mean that the application won't do anything else until that operation is finished, holding up the entire loop. That means you would block other clients connected at that time (e.g. applications serving more than 1 client at time), transfers in progress and so on... That would be only reasonable when using threads or multiple processes but not in an asynchronous environment. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Thu, Nov 29, 2007 at 10:27:37AM -0500, Barry Warsaw wrote: Perhaps someone here can draw some inspiration from __monty__ python's flying __circus__. It would be nice to have a name with a pythonic __ground__. Clearly then, it should be called __bruce__. No, __spam__! __Oleg__Stressed__by__undersores__'ly yours. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 29, 2007, at 8:47 AM, Graham Horler wrote: Perhaps someone here can draw some inspiration from __monty__ python's flying __circus__. It would be nice to have a name with a pythonic __ground__. Clearly then, it should be called __bruce__. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR07aaXEjvBPtnXfVAQLlawQApbUkTl9BHm31evewnpn8OCqpz5RM4k6N f4wfJ2HIZgDrFVkQLnBvWKp1t4b+HD+VGYHWxZgAjJ6+CFCFklkhOvxuDoyphuVu bJLxUMrkra9PyM4Mrs6O8lc+z0YyqW/gGyEqtkXu/YVDK8bcEtVo6vQg9cjbtfSj a7TLnkoBdUk= =tKo/ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
At 11:16 PM 11/29/2007 +1000, Nick Coghlan wrote: Function locals, module globals and program universals would make more sense to me - outer layers have a broader scope than inner layers. +1 for __universal__ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssl module integration with asyncore
No, the SSL code should NOT be allowed to block anything in any case, even though the handshake is still not completed, in which case just retry it at a later time. That's why there's do_handshake_on_connect in the first place. I'm just talking about what the SSL module should do if you don't use it when you call wrap_socket(). If you do use it, driving the handshake to completion is up to your code, and you can use select, poll, and/or handle_read_event() or handle_write_event() as you see fit. I think we're talking past each other here. Using asyncore (as you know) is not simple; I believe I've outlined how to use it successfully and properly with the SSL module. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PATCH: Fast globals/builtins lookups for 2.6
Cool! Can't wait to get my hands on it. How does it affect pystone?
What happens if the globals are not a real dict but an instance of
another collections.MutableMapping (virtual or real) subclass?
We've worked hard (well, some folks have) to enable this. It would be
a show-stopper if this broke (or changed semantics or became
significantly slower).
--Guido
On Nov 29, 2007 2:26 AM, Neil Toronto [EMAIL PROTECTED] wrote:
I've posted a patch here:
http://bugs.python.org/issue1518
for 2.6a0 that speeds up LOAD_GLOBAL to where it's just barely slower
than LOAD_FAST for both globals and builtins. It started life here, in
Python-ideas:
http://mail.python.org/pipermail/python-ideas/2007-November/001212.html
The idea is to cache pointers to dictionary entries rather than
dictionary values as is usually suggested for speeding up globals. In my
original approach, every dictionary would keep a list of observers
that it would notify when an entry pointer became invalid. However, the
surgery on PyDictObject became too invasive, to the point where the new
code was affecting performance of unrelated code paths. (It was probably
caching issues.) It also made some (very rare) operations on builtins
and globals very, very slow.
The new approach tags each PyDictObject with a version: a 64-bit value
that is incremented for every operation that invalidates at least one
entry pointer. (Those are inserting set, delete, pop, clear and resize.
Non-inserting set and get are unaffected.) In this approach, changes to
PyDictObject are uninvasive and do not affect performance in any
measurable way (as far as I can tell).
Every function has a PyFastGlobalsObject, which keeps entry pointers for
everything in co_names and tracks its dicts' versions so it can update
the pointers when one might have become invalid. LOAD_GLOBALS uses the
PyFastGlobalsObject to get globals and builtins by name index rather
than by string key.
With the patch, Python behaves differently in these two ways (as far as
I can tell):
1. As before, a __builtins__ ({'None': None}) is created for frames
whose globals do not have one. Unlike before, it's added to the globals
dict rather than just kept internally. This made implementation easier -
I don't think it's a big deal (but I might be wrong).
2. A change of __builtins__ (its value, not its contents) always appears
at the beginning of a stack frame. (Before, changing __builtins__ in a
module would be undetectable if function calls were kept within that
module.) This is likely of little importance.
I'd love to see it included. I have donned my asbestos underwear and my
best chain mail shirt and I'm begging for comments.
Neil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
I nearly choked on my coffee when I read the naming rights suggestion. :-) Then I started leaning towards __universal__. But then I thought, what if we renamed the __builtin__ module instead to builtins, and left __builtins__ alone? In Python 0.1, __builtin__ *was* called builtin, and I think the reason for renaming it wasn't particularly well thought-out; as a *module*, I'm not sure that it really needs to have such a special name (I don't think it's more special than sys, anyway). There's no motivation in the checkin comment that renamed it (r3527). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PATCH: Fast globals/builtins lookups for 2.6
On Nov 29, 2007 1:07 PM, Neil Toronto [EMAIL PROTECTED] wrote: Guido van Rossum wrote: Cool! Can't wait to get my hands on it. How does it affect pystone? Pystone likes it, according to my tests and Chris's. On his machine, if I'm reading these stones right, it takes about 7% off the run time on average. On mine it takes off 4%. Hm. On my Linux box, in the trunk: Before the patch: Pystone(1.1) time for 5 passes = 1.16 This machine benchmarks at 43103.4 pystones/second After the patch: Pystone(1.1) time for 5 passes = 1.14 This machine benchmarks at 43859.6 pystones/second That's only about 1.75% faster. But pystone is a lousy benchmark. What happens if the globals are not a real dict but an instance of another collections.MutableMapping (virtual or real) subclass? Globals has to be a real dict or a subclass, because otherwise PyFastGlobalsObject won't be able to point directly at its entries. This doesn't change anything, since globals had to be a real dict or subclass before. We've worked hard (well, some folks have) to enable this. It would be a show-stopper if this broke (or changed semantics or became significantly slower). Besides what I outlined about __builtins__ (which should be an arbitrary implementation detail), everything is exactly the same. The details of fast globals are completely transparent to everything but PyDictObject (in which they're nearly insignificant) and PyFastGlobalsObject. In other words, every other bit of code in the interpreter can happily do whatever the heck it wants with globals and builtins without having to worry about messing anything up. Since it's nearly transparent to the interpreter core, Python-the-language shouldn't see any differences at all. But then, I know less about the rest of the core than just about everybody else here, so I may just be talking out of my rear. :) My apologies. I though I remembered we changed exec() and eval() to accept a totally arbitrary mapping for globals() -- but that's not the case, it must be a dict subclass. Pystone and my microbenchmarks look good, but we don't know yet about Pybench. On my tests, it's nearly the same, with small variations in individual tests. On Chris's, there are large variations that appear (to me) to be random. Pybench does almost nothing with globals, though - the numbers on that really only need to stay put. The only pybench tests that matter would be the ones checking dict performance. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
The next step up from global would be __galactic__. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Nick Coghlan wrote: why not call it __implicit__? But isn't __explicit__ better than __implicit__? :-) I tend to agree about __root__, though -- it just doesn't seem quite right somehow. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Fri, Nov 30, 2007 at 11:22:03AM +1300, Greg Ewing wrote: The next step up from global would be __galactic__. Let me skip __universe[al]__ and go directly to The Ultimate Questions: Is there __life__ after __death__? Does __Deity__ exist? What attributes, properties and keys has __He__ got? Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Another idea: __ubiquitous__ -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
__the_dictionary_where_all_the_builtins_are_now__ __the_entry_formerly_known_as_builtins__ -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [poll] New name for __builtins__
2007/11/29, Greg Ewing [EMAIL PROTECTED]: __ubiquitous__ Uh! Great! +1 -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Nov 29, 2007 3:12 PM, Terry Reedy [EMAIL PROTECTED] wrote: Guido van Rossum [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | But then I thought, what if we renamed the __builtin__ module instead | to builtins, and left __builtins__ alone? | | In Python 0.1, __builtin__ *was* called builtin, and I think the | reason for renaming it wasn't particularly well thought-out; as a | *module*, I'm not sure that it really needs to have such a special | name (I don't think it's more special than sys, anyway). There's no | motivation in the checkin comment that renamed it (r3527). +1 for plain 'builtins' or whatever for the name of the module. I believe it would have been less confusing to me learning Python, (and still today ;-) if it had been this way 10 years ago. Right. It was this way 15 years ago. :-) The rationale for special __xxx__ names (identifiers) is to avoid namespace clashes. So they are only needed for namespace names bound to objects, including string objects representing definition names. Since '__builtin__' is merely a string object bound to '__name__' (I presume) in the module itself and to '__builtins__' in all others, a string that did not imitate a reserved identifier would be clearer, at least to me. Right again. Similarly, by the way, the main module might justifiably be '__name__'ed 'main' rather than '__main__' since whatever string is bound to '__name__' is *not* in the module namespace. if __name__ == 'main' is a bit easier to type and to me a bit clearer. The only problem would be if someone put the incantation into a non-main module named 'main.py', but the same is true today of '__main__.py'. And I would consider either a buggy practice. Not quite. main.py is a valid regular module name and shouldn't be endowed with special powers. But __main__.py would be a reserved module name, like __init__.py, and could reasonably be expected to have extra semantics. These are the only two builtin strings I can think of that have the form of special names, even though they are not actually identifiers. I'm not sure I follow. A module name is an identifier too. (This is how it's used by import.) If so, they are the only two 'special names' that *must* be quoted as strings, while binding names (identifiers) usually are not. If both were changed, then 'special names' would simply be 'internal namespace names used by the implementation'. I think this would make it easier for beginners to keep separate the notions of 'identifier' and 'string'. I think you're looking at this from the wrong angle. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
On Nov 29, 2007 11:54 AM, Guido van Rossum [EMAIL PROTECTED] wrote: But then I thought, what if we renamed the __builtin__ module instead to builtins, and left __builtins__ alone? Hmm. __builtins__ is a magic hook, but __builtin__-the-module isn't the thing it hooks, exactly, not the way __import__ hooks import or __iter__ hooks iter(). Really the __builtin__ module *implements* the __builtins__ hook protocol. It would be cool to have a name for __builtin__ the module that suggests that. I suggest sys.builtins. The builtins module feels both central enough and magical enough to belong in sys. And a lot of other stuff in sys has the same it's fun but slightly crazy to tweak this knob vibe. And, for sandboxers, mysandbox.builtins seems like a nice parallel to sys.builtins, with sys serving the bonus role of suggesting unrestricted access. -j ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PATCH: Fast globals/builtins lookups for 2.6
Guido van Rossum wrote: Hm. On my Linux box, in the trunk: Before the patch: Pystone(1.1) time for 5 passes = 1.16 This machine benchmarks at 43103.4 pystones/second After the patch: Pystone(1.1) time for 5 passes = 1.14 This machine benchmarks at 43859.6 pystones/second That's only about 1.75% faster. But pystone is a lousy benchmark. I'm not aware of any benchmark that isn't. :) Can you humor me and change the PY_LONG_LONG to Py_ssize_t in both PyDictObject and PyFastGlobalsObject and see if that helps? It does on one of my test machines. Speaking of which, here's a question for everybody. I was wondering whether 64 bits is necessary. It takes an hour of concerted effort - nothing but module.d = 1; del module.d for an hour straight - to overflow a 32-bit version number. Is anybody going to actually get close to doing that in a global namespace? I don't think a malicious user could exploit it. The most they could do is segfault by doing exactly 2**32 entry-invalidating operations and then one get or set. They've got better things to do if they're running code on your machine. FWIW - and I wouldn't bother with this if I weren't mucking about with dict internals - with a 32-bit version number, I've verified that gcc emits only one extra instruction in dict functions that increment it. It's two for a 64-bit number. The version test in LOAD_GLOBAL does take a bit more time with 64 bits, though. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
