[Python-Dev] python-dev Summary for 2004-09-16 through 2004-09-30 [draft]

Brett C bac at OCF.Berkeley.EDU
Thu Oct 14 07:20:28 CEST 2004


So we were all rather quiet in the last half of September.  The whole summary 
fits on two sheets of 8.5x11 (normally it is over 10 and I have hit over 20 
when I was summarizing *everything*).

Going to send this out no earlier than Friday night so send in corrections by then.

----------------------------------

=====================
Summary Announcements
=====================
Wow.  This must have been the easiest summary I have ever done.  Why can't they 
all be like this?  I didn't even skip that much!

=========
Summaries
=========
------------------------------------------
Assume nothing when mutability is possible
------------------------------------------
Tim Peters discovered a new way to create an infinite list thanks to generator 
expressions.  But what really came out of this whole discussion came about when 
someone else came up with an example that exposed a bug in list.extend().

The first thing was that "you can't assume anything about a mutable object 
after potentially calling back into Python."  Basically you can't assume the 
state of any mutable object was not changed if you execute Python code from C. 
  While it might seem handy to store state while in a loop for instance, you 
can't count on things not change by the time you get control back so you just 
have to do it the hard way and get state all over again.

Second was that you need to be careful when dealing with iterators.  If you 
mutate an iterator while iterating you don't have a guarantee it won't explode 
in your face.  Unless you explicitly support it, document it, and take care to 
protect against it then just don't assume you can mutate an iterator while 
using it.

Contributing threads:
   - `A cute new way to get an infinite loop <>`__
   - `More data points <>`__

----------------------------
The less licenses the better
----------------------------
The idea of copying some code from OpenSSH_ for better pty handling was 
proposed.  This was frowned upon since that becomes one more legal issue to 
keep track of.  Minimizing the licenses that Python must keep track of and make 
sure to comply with, no matter how friendly, is a good thing.

.. _OpenSSH: http://www.openssh.com/

Contributing threads:
   - `using openssh's pty code <>`__

------------------------------------------------------------------------
Trying to deal with the exception hierarchy and a backwards-friendly way
-------------------------------------------------------------------------
Nick Coghlan came up with the idea of having a tuple that contained all of the 
exceptions you normally would not want to catch in a blanket 'except' 
statement; KeyboardInterrupt, MemoryError, SystemExit, etc.).  This tuple was 
proposed to live in sys.special_exceptions with the intended usage of::

  try:
    pass # stuff...
  except sys.special_exceptions:
    raise # exceptions that you would not want to catch should keep propogating 
up the call chain
  except:
    pass # if you reach here the exception should not be a *huge* deal

Obviously the best solution is to just clean up the exception hierarchy, but 
that breaks backwards-compatibility.  But this idea seemed to lose steam.

Contributing threads:
   - `Proposing a sys.special_exceptions tuple <>`__


===============
Skipped Threads
===============

- Decimal, copyright and license
- Planning to drop gzip compression for future releases.
- built on beer?
- Noam's open regex requests
- Socket/Asyncore bug needs attention
- open('/dev/null').read() -> MemoryError
- Finding the module from PyTypeObject?
- Odd compile errors for bad genexps
- Running a module as a script


More information about the Python-Dev mailing list