With python2.5 (and 2.6) cvs.get_dialect('excel') returns a Dialect class object in contrast to python 2.4 where an instance of csv.excel is returned, the former having only read only attributes.

% python2.4
Python 2.4.1 (#3, Jul 28 2005, 22:08:40) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> d = csv.get_dialect("excel")
>>> d
<csv.excel instance at 0x3ae058>

% python
Python 2.6a0 (trunk:54264M, Mar 10 2007, 15:19:48) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> d = csv.get_dialect("excel")
>>> d
<_csv.Dialect object at 0x137fac0>

I took a brief look at the code.  get_dialect is imported from the underlying _csv.c extension module and didn't change between 2.4 and 2.5.  There is a new static function, _call_dialect, though.  It is called from several places, most notably from csv_register_dialect.  The code in 2.4 that it replaces seems much different to me than the code in the body of _call_dialect.  I suspect there was some sort of regression there.

Assigning to Andrew since he's the primary author of the code as well as the author of this particular change.

Dialects were made immutable, because they can potentially represent the configuration of a running state machine (the reader), and the dialects are potentially shared.

If you want to change a registered dialect, I suggest you do something like:

   csv.register_dialect('excel', csv.get_dialect('excel'), delimiter='\t')

This changes the dialect for new users, but doesn't disrupt the state of already running readers.

I should also mention that if you simply wanted a reader of a variant of the "excel" dialect, the simplest way to achieve that is:

   r=csv.reader(f, dialect='excel', delimiter='\t')

Would it have made sense to save the class when registering then
return a new instance from get_dialect()?  I believe the current
scheme instantiates the dialect being registered, then returns that
object anytime get_dialect is called.  That would have allowed the
user to modify the returned dialect to their heart's content without
messing up the registered dialect.

At the very least I think this change needs to be documented.

The user already has a number of entirely satisfactory ways to "modify" the dialect - the module is implemented as it is to keep the code simple and obvious (from a maintenance point of view). 

As far as I'm concerned the old behaviour was undocumented and accidental. I don't mind if you want to document the new behaviour, but I'm afraid I don't have time to do it at the moment.

Grabbing this.  I'll try to come up with some wording about the change.

I changed the documentation for 2.5 and 2.6 to reflect the change in 
semantics.  r58840 and r58841.  Have a look and let me know if that looks 
reasonable.

Seems okay to me. I had a quick look at the examples section, and it 
shows a use like the one I mention, but I wonder if the section on 
dialects should quote the specific examples I mention?

Just a doc change after all...