Thursday June 6th

SIG Working Groups

Documentation

Michael McLay

Documentation Strings
- Should docstrings be different?
- Guido: Must be string objects as defined by the C code
- Proposal: What about something like a URL that points to the file with the docstrings
- Guido: I'm OK with that
- Maybe they could be put in the pyc file at the end in a place after the code object.
- Closure: We need to have some better metrics on importing before we can agree on the best solution.
- Robin: I will organize some research into this on the documentation SIG
- Guido: Maybe the format that Harri's OO Browser format should be the 'viewing' format that we should standardize on?
- Response: Not all my users are going to be willing to live with the overhead of emacs for viewing documentation. A simpler model would be better.
- Proposal: maybe we could use Daniel Larsson's gendoc ?
- Jim Hugunin: I just ran out and did a test on a large .py file (500 classes - 2 megabytes) with a 1 to 10 ratio of code to docstrings (worst case scenario). The first time you import the module, it takes 4 seconds to load with the docstrings included and 2 seconds without. The second time you import it (the only test that really matters... loading the pyc file), the difference is much less: .3 seconds with and .2 seconds without.
- Conclusion: Overhead of docstrings is *not* an issue. Docstrings are good!
- Closure: Let's still put gendoc tool in the contrib area of the ftp sight.
- gendoc in a way is better than docco since it deals with pure imports (extension modules are then included). docco operates on source.
- Proposal: Maybe gendoc and docco need to have a common intermediate format so output formatter modules could be shared.
- Who is going to do this work?
- Jim Fulton: I want to be able to extract more information from builtin types without instantiating it.... make them more like classes. Wants builtins to smell more like classes.
- Guido: I agree that would be a good thing.
- Guido: I still want to reinforce the notion that the first line of a docstring should be a consise description of the method, followed by a blank line, and then the rest of the contents of the docstring.

Programming Environment

Fred Drake

How about Graphical Development Tools?
We should use a cross platform GUI... Tk is it.
Robyn: I'm concerned about the footprint of Tk
Roger: I don't think the memory problems in Tk are a perminant problem. Both Tk and Tkinter have leaks but these should be fixable in the long term.
Greg: I want native look-and-feel for my users, they are too easily confused.
Guido: Tk on the MAC and Windows is *not* a motif "program". It's buttons and scrollbars that just don't happen to be native look-and-feel... they are not that different!
Roger: The Tk folks have promised native look-and-feel eventually
Jim: We've heard all this before... let's assign this conversation to a 'macro' so we can replay it for the benifit of those who've not heard it before... Lets call it Macro 57 :-)
Fred: I'm going to try and implement a Tkinter based GUI class browser in my spare time.
OO Browsers storage format is ascii... which is a good starting point for the persistance so the tools can interoperate.

GUI

Jim Ahlstrom

Macro 57

Developer's Future Enhancements

Lee Busby's wish list
- replace interfaces to I/O and memory manager with function pointers. This is so one can redirect standard I/O or use a different memory manager more easily. Lee said he would implement this.
- Dave: This would be very useful for parallel machines
- Provide conditional code to catch SIGFPE. Basis and Yorick can provide example code. Lee will do this too :-)
- Make -u command line option to unbuffer stdout, stdin, stderr. Also allow the user to force prompts on, even if stdin, stdout are pipes. We need this to run Python batch jobs also with rsh. Lee will do.
- More and better documentation for Python API extensions.
Creation of a new SIG: ORB SIG
- Establish some kind of standard binding for CORBA from Python
- Would like to submit to OMG
- Instead of generating stubs like ILU, instead you use a repository to hold this information.
- Hopefully Bill Janseen (Xerox PARC - ILU) could participate in this SIG in order to advise on the parts of CORBA that intersect ILU functionality... so they could be implemented in a complimentary way, Bill where are you?
- Volunteer to chair? Jim will administer list, David Arnold will chair
Don Beaudry Hack - MESS (Presented by: Guido van Rossum)
- Allows an extension C module to provide subclassable types:
```
class MySpecial(BaseSpecial):
	clvar = 42
	def math(self, arg): print arg
        
```
- if...
```
 type(BaseSpecial) 
```
  ...is callable, it will be invoked like:
```
	t = type(BaseSpecial)
	t("MySpecial", (BaseSpecial,), dict)
        
```
- ...where...
```
 dict = {'clvar':42, 'math':} 
```
- Layered on the first base class
- Return value of call is stored as:
```
 MySpecial 
```
- extension can do whatever it wants
- Don's MESS uses this
- See David Ascher's home page (from Python contrib page) and David has a pointer to Don's MESS
Jim Fulton - Meta Type Proposal
- A method of providing information about a type much like you can with classes
- New type: Metatype
- This work is a subset of MESS functionality.
- Jim is going to release his work as sort of a lightweight MESS
- Jim's goal: Weither you use my Metatype, or Don's MESS I want to provide a consistant interface for interrogating types. Propose a uniform protocol for interfacing with types system extensions.
- Jim's Metatype is a callable type
- Meta Protocol
  - Interesting Meta information about classes...
    - class name, parent class name(s), attributes (including methods)
    - Is this the appropriate interface for types?
    - Guido and Jim will continue this conversation off-line...
Jim Fulton: Can we get modules to have a getattr and setattr attributes?
Guido: Putting that hook in the module, it doesn't get it right for globals. To get it right it needs to be in the dictionary.
assign a function to getitem and setitem for a dictionary.
Jim: I can't setattr for __doc__ on instances
Guido: Send me the patch, and I'll put it in 1.4
Jim: In order to turn on Packages, you need to import ni then call ni.ni(). Ni should install itself once you import it.
Guido: This is fixed in 1.4, just import ni installs ni the first time you import it.
Jim: When you import a package, and it has an __init__ module, then the objects that it defines are not visible to other modules in the package without the __init__ install the objects in each module.
Jim: I would like to be able to import a package and treat it's objects like package.object.
Guido: It's not sufficient to make the package scope as the same as the module scope.
Guido: I prefer to think about packages as a collection of modules. There is no package object.
Jim: There was a thread some months ago about a desire for automating memory managment for modules. Something that matches your inrefs and decrefs.
Purify helps find these leaks at runtime.
Jim: A possible solution is to add an attribute to the type object that contains a list of all the objects that are instances of it.
Guido: You would also need a doubly linked list of all your types that contain all the references.
Who will do this?
Jim agreed to write this up and publish it on our web pages.
Proposal: Last workshop someone wished for += and -= Has anything been done with this?
Guido: No, but it can be done... There are some issues of unexpected results when mixing lists and tuples... for example.
Greg Stein will be working on some form of statement coverage tool, possibly with a graphical interface. Hopefully in the next couple of months.

PSA Discussion

Q: Should we have the meetings every six months?
Greg: Six months seems good.
Maybe we should shift to Spring/Fall instead of Summer/Winter
Maybe we should have a early-fall (October) one somewhere other than Reston so that we can have a Reston workshop in the Spring (April).
Maybe we can hook up with a USENIX or ACM to help organize.
Maybe this fall's OOPSLA conference in San Jose can piggy-back a one day Python day or something...
It's been good, it's been real... See you next time :-)