Mailman 3 February 2008 - Python-ideas

Ideas towards GIL removal
by Greg Ewing 18 Jul '08

18 Jul '08

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

8 19

adopt an enum type for the standard library?
by Mark Summerfield 12 Apr '08

12 Apr '08

AFAIK if you want enumerations you must either create your own, or use a third party module, or use namedtuple: Files = collections.namedtuple("Files", "minimum maximum")(1, 200) ... x = Files.minimum Using: MINIMUM, MAXIMUM = 1, 200 is often inconvenient, since you might have several different ones. Of course you could do: MIN_FILES = 1 MIN_DIRS = 0 Personally, I like enums and consider them to be a fundamental, but I don't like the above approaches. There is an enum module in PyPI http://pypi.python.org/pypi/enum/ and there are several versions in the Python Cookbook. Wouldn't one of these be worth adopting for the standard library? -- Mark Summerfield, Qtrac Ltd., www.qtrac.eu

10 14

simpler super() syntax
by Arne Babenhauserheide 22 Feb '08

22 Feb '08

Hi, I just spent some time figuring out how and why super needs to be called with *args and **kwds in any class, when I use multiple inheritance (or when some subclass wants to use it), and I got the impression, that simply every class should take *args and **kwds and that super should be called inside the init of every class. Would it make sense to make the init of any class take *args and **kwds implicitely? With that, arguments and keywords would always be passed on (the behaviour we need as soon as we use any multiple inheritance) and the code would look cleaner (I think). At the moment the code for a class with MI looks like this: class Blah(Blubb): def __init__(*args, **kwds) super(Blah, self).__init__(*args, **kwds) with implicit *args and **kwds, it would look like this: class Blah(Blubb): def __init__() super(Blah, self).__init__() And by calling super, I implicitely say, that i want to pass on any leftover args or kwds which (to my knowledge) I must do anyway, since else I am in danger of getting MI bugs. What do you think? Best wishes, Arne -- Unpolitisch sein Heißt politisch sein Ohne es zu merken. - Arne Babenhauserheide ( http://draketo.de ) -- Weblog: http://blog.draketo.de -- Mein öffentlicher Schlüssel (PGP/GnuPG): http://draketo.de/inhalt/ich/pubkey.txt

3 2

exit as a statement
by BJörn Lindqvist 20 Feb '08

20 Feb '08

An idea I have thought about for a while and it makes sense to me... $ python Python 2.4.2 (#1, Oct 13 2006, 17:17:08) [GCC 4.1.0 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> exit 'Use Ctrl-D (i.e. EOF) to exit.' Argh! Do what I mean, stupid Python! And it is Ctrl+Z on Windows, not Ctrl-D. So exit could be a statement that does the same thing that sys.exit() does currently. Bare "exit" to terminate with return code 0, and "exit X" to terminate with return code X. -- mvh Björn

7 8

Idea for the mapping API
by Raymond Hettinger 10 Feb '08

10 Feb '08

Perhaps, the dict() constructor should accept any object with a __dict__ method. The principle is that almost any object that has key and value pairs (named tuples for example) should be readily convertable to and from a dictionary. The current, non-uniform alternative is for the object to provide an asdict() method and for the user to call it directly. Raymond

5 5

Re: [Python-ideas] [Web-SIG] Merge Cookie and cookielib?
by Adam Atlas 05 Feb '08

05 Feb '08

(This is from a discussion taking place on Web-SIG, but this isn't web- related, so I'm sending it to python-ideas.) On 5 Feb 2008, at 18:21, Brett Cannon wrote: > My current idea is the new names cookie.client and cookie.server for > Cookie and cookielib, respectively. While this goes against the goal > of making the new names easier to work with, Cookie has to be renamed > because of its PEP 8 violation. And having cookie and cookielib in the > stdlib will not help with differentiating between the two. Has anyone proposed dropping the -lib suffix on *all* modules that currently use it? It annoys me. It seems arbitrary and redundant. I suppose there must be some historical reason for that, but I can't imagine it would still be very relevant.

3 3

Namespaces are one honking great idea -- let's do more of those!
by Ralf W. Grosse-Kunstleve 02 Feb '08

02 Feb '08

This is regarding the transition to Python 3, and the confusion caused by using the same executable name for two incompatible interpreters. The consequences of this struck me today when I saw this message appear on an important bulletin board for the field I'm working in: http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0802&L=ccp4bb&T=0&F=&S=&P=… This posting is from a heavy-weight in the field (lookup his name with Google or better The Web of Science). Basically he's suggesting to forget about Python because it is an unreliable environment. There is also this reply calling the original posting "alarmist": http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0802&L=ccp4bb&T=0&F=&S=&P=… And this one making fun of the whole thing: http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0802&L=ccp4bb&T=0&F=&S=&P=… I interpret these messages as early signs of an imminent decade of confusion. Therefore my plea: PLEASE GIVE THE PYTHON 3 EXECUTABLE A DIFFERENT NAME AND THE SCRIPTS A DIFFERENT EXTENSION. It will be a terrible political setback otherwise. Many people don't *want* to understand even if they could. Mixing up two incompatible interpreters under one name will give them plenty of ammunition for cheap jokes and for defending their not-invented-here-or-before-I-was-16 attitude. Ralf P.S.: My wife is from Hungary. It seems all men in Hungary have to have one of exactly three names: Andras, Laszlo, or Balazs. I never know whom she's talking about...

5 4

Python-ideas February 2008