Python-ideas September 2007

python-ideas@python.org

26 participants
22 discussions

by Greg Ewing

I've been thinking about some ideas for reducing the amount of refcount adjustment that needs to be done, with a view to making GIL removal easier. 1) Permanent objects In a typical Python program there are many objects that are created at the beginning and exist for the life of the program -- classes, functions, literals, etc. Refcounting these is a waste of effort, since they're never going to go away. So perhaps there could be a way of marking such objects as "permanent" or "immortal". Any refcount operation on a permanent object would be a no-op, so no locking would be needed. This would also have the benefit of eliminating any need to write to the object's memory at all when it's only being read. 2) Objects owned by a thread Python code creates and destroys temporary objects at a high rate -- stack frames, argument tuples, intermediate results, etc. If the code is executed by a thread, those objects are rarely if ever seen outside of that thread. It would be beneficial if refcount operations on such objects could be carried out by the thread that created them without locking. To achieve this, two extra fields could be added to the object header: an "owning thread id" and a "local reference count". (The existing refcount field will be called the "global reference count" in what follows.) An object created by a thread has its owning thread id set to that thread. When adjusting an object's refcount, if the current thread is the object's owning thread, the local refcount is updated without locking. If the object has no owning thread, or belongs to a different thread, the object is locked and the global refcount is updated. The object is considered garbage only when both refcounts drop to zero. Thus, after a decref, both refcounts would need to be checked to see if they are zero. When decrementing the local refcount and it reaches zero, the global refcount can be checked without locking, since a zero will never be written to it until it truly has zero non-local references remaining. I suspect that these two strategies together would eliminate a very large proportion of refcount-related activities requiring locking, perhaps to the point where those remaining are infrequent enough to make GIL removal practical. -- Greg

13 years

Enhance reload

by Joseph Maurer

Ok, my idea of a temporary "replace" attribute wrapped around a reload-like function is not a good idea for Python given that things can be dynamically added to modules at any time. --------------------------------------- Here is my original high level design: The way I implemented this feature in Slick-C is with indirection. In Python terms, this means that a separate data structure that isn't reference counted holds the method/function object data. The method/function object is changed to just contain a pointer to it. The data structure which holds all method/function data should probably be a non-reference counted dictionary. When a function is deleted, it's name remains in the dictionary but the entry needs to be changed to indicate that it is "null/invalid". When a deleted function is called, an exception should be raised. Adding a function/method means replacing the data in the dictionary. This type of implementation is simple. There's an insignificant amount of overhead on a function/method call (i.e. instead of "func->data" you have "func=*pfunc;if ( func->isInvalid() ) throw exception; else func->data" ). Technically this algorithm leaks memory since deleted functions/methods are never removed. My response is who cares. When the interpreter cleanup everything function is called, you simple deallocate everything in the dictionary. --------------------------------- Instead of a temporary "replace" attribute wrapped into a reload-like call, how about giving modules a user settable "replace" attribute. At any time, the user can set/reset this attribute. This would specify how the user wanted functions/methods processed. Always added or always replaced. The "replace" attribute would likely need to be pass through to function objects, class objects, and method objects. For the macro language scenarios, I would just mark every module that got loaded with this attribute. The proposed implementation I have given is intended to by very "file" oriented (which maps to a Python module). Would this work in the current code base? I'm assuming the following: When a function is added/executed, the module structure is accessible. When a class is added (i.e. class myclass), the module structure is accessible. When a method is added/executed, at least the class structure is accessible? I hope you see where I'm going here. The executed "class myclass" code which defines a new class can copy the module "replace" attribute. the executed "def myfunction" code which defines a new method can copy the class "replace" attribute. The function/method object structure could remain the same except for the addition of a new function/method pointer member. The additional code for a function call would look like this: // Did this function get defined in "replace" mode? if ( func->doReplace() ) { // For this one, use the indirect pointer and not the other member data. func= func->pfunc; if ( !func->isValid() ) { throw exception. // Python exeception, not C++ exception return here... } } // Now do what we used to do Given the OO nature of Python, a separate function/method type for a replacable function/method could be defined but I suspect it isn't worth the effort. The above psuedo code is very efficient "doReplace" would probably be just a boolean/int member. The "isValid" called would be efficient as well. One thing my proposed implementation does not cover is adding new data members to a class. I think it is acceptable for this not to be handled. Please shot this down this high level implementation if it won't work in the current code base. Also, what does everyone think about the idea of some sort of "replace" attribute for the module? How should it get set? "import module; module.replace=1". I'm probably showing a little lack of knowledge here. Teach me and I'll get it. ____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/

13 years, 10 months

Enhance reload

by Joseph Maurer

Greg Ewin wrote: > What you suggest sounds like it ought to be possible, > at first sight, since Python function objects are already > containers with a reference to another object that > holds the function's code. > The problem will be figuring out *when* you're redefining > a function, because the process of loading a module is a > very dynamic one in Python. Defining functions and classes > is done by executing code, not by statically analysing > declarations as a C compiler does. My implementation is definitely a high level scetch. Greg, The kind of issues you are bringing up is exactly the kind of thing I'm looking for. If there are more, lets see them. Would temporarily marking the module with "replace" work? I would think that when the function is defined, it has access to the module (because it is adding to its dictionary) and it could check for the "replace" attribute. I'm assuming a certain sequence of execution here since the "replace" attribute would have to removed after the function/method code was executed/loaded. Anyone who knows that this isn't the case, please shoot this down. Another post I read proposed a Reclass feature that only worked for classes. Given the macro language scenario, you definitely need functions too. ____________________________________________________________________________________ Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV. http://tv.yahoo.com/

13 years, 10 months

Enhance reload

by Joseph Maurer

I'm still new to the technical abilities of Python so help me if I misunderstand the current capabilities. I'd like to see the reload feature of Python enhanced so it can replace the methods for existing class instances, references to methods, and references to functions. Here's the scenario. Let's say you want to use Python as a macro language. Currently, you can bind a Python function to a key or menu (better do it by name and not reference). That's what most apps need. However, an advanced app like SlickEdit would have classes instances for modeless dialogs (including tool windows) and other data structures. There are also callbacks which would preferably need to be references to functions or methods. With the current implementation you would have to close and reopen dialogs. In other cases, you would need to exit SlickEdit and restart. While there always will be cases where this is necessary, I can tell you from experience that this is a great feature to have since Slick-C does this. I suspect that there are other scenarios that users would like this capability for. Java and C# support something like this to a limited extent when you are debugging. This capability could be a reload option. Their could be cases where one might want the existing instances to use the old implementation. You wouldn't need this to be an option for me. There will always be cases where you have to restart because you made too many changes. ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting

13 years, 10 months

Enhance reload

by Joseph Maurer

I'm glad to hear it isn't a matter of whether it was useful or not. The way I implemented this feature in Slick-C is with indirection. In Python terms, this means that a separate data structure that isn't reference counted holds the method/function object data. The method/function object is changed to just contain a pointer to it. The data structure which holds all method/function data should probably be a non-reference counted dictionary. When a function is deleted, it's name remains in the dictionary but the entry needs to be changed to indicate that it is "null/invalid". When a deleted function is called, an exception should be raised. Adding a function/method means replacing the data in the dictionary. This type of implementation is simple. There's an insignificant amount of overhead on a function/method call (i.e. instead of "func->data" you have "func=*pfunc;if ( func->isInvalid() ) throw exception; else func->data" ). Technically this algorithm leaks memory since deleted functions/methods are never removed. My response is who cares. When the interpreter cleanup everything function is called, you simple deallocate everything in the hash table. Does anyone know what level of effort would be needed for something like this? Is my proposed implementation a good one for Python? ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC

13 years, 10 months

Removing the del statement

by George Sakkis

I guess this has very few to zero chances of being considered, even for Python 3, but this being python-ideas I guess it's ok to bring it up. IMO the del statement is one of the relatively few constructs that stick out like a sore thumb. For one thing, it is overloaded to mean three different things: 1) del x: Remove x from the current namespace 2) del x[i]: Equivalent to x.__delitem__(i) 3) del x.a: Equivalent to x.__delattr__('a') and delattr(x,'a') Here I am mostly arguing for removing the last two; the first could also be removed if/when Python gets block namespaces, but it is orthogonal to the others. I don't see the point of complicating the lexer and the grammar with an extra keyword and statement for something that is typically handled by a method (my preference), or at least a generic (bulitin) function like len(). The last case is especially superfluous given that there is both a special method and a generic builtin (delattr) that does the same thing. Neither item nor attribute deletion are so pervasive to be granted special treatment at the language level. I wonder if this was considered and rejected in the Py3K discussions; PEP 3099 doesn't mention anything about it. George

13 years, 10 months

Exploration PEP : Concurrency for moderately massive (4 to 32 cores) multi-core architectures

by Clark Maurer

Hello, I've been following this discussion. My thoughts mostly reiterate what has already been said. There's no way to get rid of the GIL without significantly effecting single threaded performance. IMO getting rid of the GIL would require writing a mark-and-sweep algorithm. To improve performance you can do incremental (threaded) marking and detect page faults so that modified pages can be rescanned for references. The Boehm garbage collector does this (I think) but Python would need something much more custom. This type of garbage collector is VERY hard to write. Worse yet, the current implementation of Python would need a lot of rewriting. FYI: I tried using the Boehm collector in SlickEdit and it leaked memory like crazy. I never figured out why but I suspect it had to do with it treating everything in memory as a potential pointer. Ruby's mark-and sweep garbage collector illustrates the loss in single threaded performance and since it does its own thread scheduling, the thread performance is bad too. As Python stands right now, its performance is excellent for single threading, the implementation is simple, it works well for the typical Python user, and using processes at least gives a work around. I like to be a perfectionist as much as the next guy but the pay back doesn't warrant the level of effort. Where's the easy button when you need oneJ I thought you Python enthusiasts (especially Guido) might enjoy the article I just posted on the SlickEdit blog. I'm the CTO and founder of SlickEdit. I hate saying that because I'm a very humble guy but I thought you would want to know. The article is called "Comparing Python to Perl and Ruby", go to http://blog.slickedit.com/. I limited the article to a simple grammar comparison because I wanted to keep the article short. Hope you enjoy it. Guido, I have another article written which talks about Python as well but I have not yet posted it. If you give me an email address, I will send it to you to look over before I post it. Don't give me your email address here. Instead write to support(a)slickedit.com and let them know that I requested your email address. Cheers Clark

13 years, 10 months

Re: [Python-ideas] Calling a function of a list without accumulating results

by Terry Jones

Hi Arnaud | If you want to do it like this, why not do it explicitly: | | def exhaust(iterable): | for i in iterable: pass | | Then you can write: | | exhaust(f(x) for x in mylist) Thanks - that's nice. It also gives me the generality I wanted, which was the ability to use the full LC/genexp "for..." syntax, which I should have emphasized more, including in the subject of the thread. Terry

13 years, 10 months

Re: [Python-ideas] Calling a function of a list without accumulating results

by Terry Jones

Hi Greg | The way things are, there is only one coding style for when you don't want | the results. You're suggesting the addition of another one. That *would* be | un-Pythonic. But the same remark could be made about using a list and writing explicit loops to accumulate results, and the later addition of list comprehensions. Wasn't that un-Pythonic for the same reason? Terry

13 years, 10 months

Calling a function of a list without accumulating results

by Terry Jones

What's the most compact way to repeatedly call a function on a list without accumulating the results? While I can accumulate results via a = [f(x) for x in mylist] or with a generator, there doesn't seem to be a way to do this without accumulating the results. I guess I need to either use the above and ignore the result, or use for x in mylist: f(x) I run into this need quite frequently. If I write [f(x) for x in mylist] with no assignment, will Python notice that I don't want the accumulated results and silently toss them for me? A possible syntax change would be to allow the unadorned f(x) for x in mylist And raise an error if someone tries to assign to this. Terry

13 years, 10 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Python-ideas September 2007