[Python-Dev] Ph.D. dissertation ideas?

Brett Cannon brett at python.org
Mon Jan 16 05:54:44 CET 2006


On 1/15/06, Dennis Allison <allison at shasta.stanford.edu> wrote:
> On Thu, 12 Jan 2006, Brett Cannon wrote:
>
> > It is time once again in my educational career to come to python-dev
> > for help for major project ideas.  This time, though, it is for my
> > Ph.D. dissertation (and thus can have larger scope than my masters
> > thesis) but there are funding restrictions (and thus only certain
> > areas I have possible funding for).
> >
> > First off, there are two areas where I have possible funding: XML
> > integration into programming languages and game scripting support (I
> > have a third, AOP for anything, but  I don't think AOP is a good match
> > for Python and thus not considering it for Python work).  The XML
> > integration I have no direct ideas since I don't use XML.  There is
> > the possibility of doing something like the LINQ project
> > (http://msdn.microsoft.com/netframework/future/linq/default.aspx?pull=/library/en-us/dndotnet/html/linqprojectovw.asp)
> > or something, but I don't know how useful that could be.  It would
> > have to be just as generic, though, as the LINQ project in terms of
> > working with intefaces to be Pythonic so it might turn out to be more
> > about language support for querying data.
> >
> > For the game scripting, trying out the active objects for Python is a
> > possibility (or something else that would help with concurrency).
> > Since that could allow for agent objects to be more concurrent it can
> > be argued that it would help with game scripting.  I don't have any
> > other ideas for the area of game scripting support.
>
> Brett--
>
> Financial considerations aside, neither of the ideas you mention see ready
> to be a dissertation topic.  I'd encourge you to look to other topics.
>

I'm open to other topics and in no way settled or locked into anything
mentioned so far.  Just need to be able to feed myself.  =)

> You might research interpreter structures for languages like Python which
> do not use a global interpreter lock (GIL).  There's been discussion about
> this from time to time on this list, even some suggestions as to what
> might be done.  Given the trend toward multi-core processors, Python would
> benefit if all processors did not need to block on the GIL. Guido told me
> once that someone had build a Python interpreter with multiple locks, but
> that the peformance was not very good and that the interpreter was
> fragile.  This is, of course, a hard problem.
>

It was Greg Stein who worked on it while at Microsoft.  He didn't
start to approach breaking even until two processors (if I remember
correctly).  None of the code was ever released.

This could fit under the concurrency or gaming funding if there is
some way to make threading just work better for Python.  So it's a
possibility.

> In 1974, Dijkstra wrote a fascinating paper on self-stabalizing
> algorithms; since that time a considerable literature has grown up.
>
> Managing a Python system these days is a management problem when the
> standard system is extended with libraries from many different sources,
> each with different release schedules, dependencies, compatibilities, and
> documentation.  Automating the management of Python and its libraries
> might make a good dissertation topic, particualarly if there is some
> advice giving system that helps find an appropriate library for a
> particular problem.
>

Possibilty.  Does tie into my lab's area of focus.

> Testing, optimization, refactopring tools, etc.
>

All possible general areas.

> Dave Altel, following others, suggested in a provacatively title talks--
>

Was there more to this line?  Seems like the email was cut off.

Thanks Dennis (and everyone, for that matter) for the continued help
and support!

-Brett


More information about the Python-Dev mailing list