python-dev Summary for 2003-05-16 through 2003-05-31
This is a summary of traffic on the python-dev mailing list from May 16, 2003 through May 31, 2003. It is intended to inform the wider Python community of on-going developments on the list and to have an archived summary of each thread started on the list. To comment on anything mentioned here, just post to email@example.com or comp.lang.python with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join python-dev!
This is the eighteenth summary written by Brett Cannon (has his own room with a door for the first time in over 22 years).
All summaries are archived at http://www.python.org/dev/summary/ .
Please note that this summary is written using reStructuredText which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; its simple and is accepted for PEP markup. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils as-is unless it is from the original text file.
The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when wanting to look up any documentation on something mentioned here. To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ .
Sorry about the delay for this summary. I was visiting my mother and that puts me out of my hacking groove. I also had a roommate move out which means I got to move into his room. And on top of all of that I just decided where I am going to go for grad school in computer science ( Cal Poly San Luis Obispo ). Life just likes to dump everything on you at once, huh?
Python 2.2.3 has gone out the door!
Jim Fulton updated the tutorial for creating new C types to use new-style classes. This led to the question of what the right way was for dealing with garbage collection. In terms of the tp_dealloc slot, having it call obj->ob_type->tp_free is best since that works the best when the type is subclassed.
This also led to a discussion about the magic of PyType_Ready and whether it should do more. This wonderful function fills in tp_alloc and tp_free if tp_base and tp_bases are empty (they are set appropriately for PyBaseObject which is the C version of object). What was changed was that now the function does the right thing if the object should be checked for cycles based on settings in tp_flags.
Paul Moore was worried about the loss of the tutorial for classic types. The response was that as long as they don't mess with there code it will continue to work, but if they decide to change something they should probably update. Michael Hudson's Misc/pymemcompat.h file is also helpful since it allows you to use 2.3's memory API but macro-replaces the call with the proper code all the way back to 1.5.2 . It was suggested adding a Misc/pyapipcompat.h for PyAPI_FUNC, PyAPI_DATA, and PyMODINIT_FUNC.
For the last summary I asked for the help of python-dev to find out the exact algorithm used to do attribute lookup for new-style classes (I don't care about classic classes since they are sooo 2.1 =). A bunch of people jumped in and made suggestions, but I am going to steal the explanation from Raymond Hettinger's explanation of descriptors which can be found at http://users.rcn.com/python/download/Descriptor.htm . =)
The attribute lookup order gives "data descriptors priority over instance variables, instance variables priority over non-data descriptors, and assigns lowest priority to __getattr__ if provided." This is all is done by object.__getattribute__ . If you define your own __getattribute__ none of this is done unless you explicitly call object's implementation. You have to worry about calling a descriptor's __get__ method yourself if you decide not to call object.__getattribute__ .
Raymond's descriptor essay/explanation/(group of words put together in attempt to make a coherent idea which he does) explains the difference between a data descriptor and non-data descriptor, but instead of make you wait I will just tell you. A data descriptor defines both a __get__ and __set__ method while a non-data descriptor defines only __get__. This makes sense when you think about non-data-descriptors such as functions. You have no need to assign to a function so not having a __set__ in no way harms the usage of a function plus it negates the need for any special flag or anything to define the difference between data and non-data descriptors.
What started off as Jeffrey Robert's introducing himself ended up becoming a short howto on how to get involved on python-dev. It was suggested to work on pyPy (although that is not exactly python-dev but is still cool and you could learn a lot about Python on a more abstract level =). Multiple people suggested working on bugs and patches. I specifically suggested looking at patches in development to learn what they were doing to the code's semantics. Mention of the AST branch and working on that was also brought up.
Terrence Way then introduced himself and mentioned he had written a PEP about programming with contracts. It led to, in the end, Guido saying that he wanted to wait and let more implementations get out there and be weeded out before he started pronouncing on PEPs on the subject.