[Python-bugs-list] [ python-Bugs-786314 ] Wrong class name after using import cStringIO as StringIO

SourceForge.net noreply at sourceforge.net
Mon Aug 11 07:18:34 EDT 2003


Bugs item #786314, was opened at 2003-08-10 11:21
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786314&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Stefan Schwarzer (sschwarzer)
>Assigned to: Skip Montanaro (montanaro)
Summary: Wrong class name after using  import cStringIO as StringIO

Initial Comment:
Try this:

Python 2.3 (#1, Aug  6 2003, 21:21:10) 
[GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5
Type "help", "copyright", "credits" or "license" for
more information.
>>> import cStringIO as StringIO
>>> obj = StringIO.StringIO()
>>> obj.spam
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'cStringIO.StringO' object has no
attribute 'spam'
>>> 

Note that the module/class name in the error message
misses an "I". In a unit test of one of my programs I got

AttributeError: 'cStringIO.StringI' object has no
attribute 'mode'

Here, the trailing "O" is missing instead of the "I".

Compare this with

Python 2.3 (#1, Aug  6 2003, 21:21:10) 
[GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5
Type "help", "copyright", "credits" or "license" for
more information.
>>> import StringIO as cStringIO
>>> obj = cStringIO.StringIO()
>>> obj.spam
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: StringIO instance has no attribute 'spam'

Surprisingly, the class name has all letters, but the
module name isn't there, and the single quotation marks
are missing.

The bug isn't a bad problem, but perhaps it manifests
in other places where it causes more harm.

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

>Comment By: Skip Montanaro (montanaro)
Date: 2003-08-11 08:18

Message:
Logged In: YES 
user_id=44345

I changed the tp_name for both StringI and StringO in v. 2.43.
While the names exposed are technically correct, it's only going
continue to be a mild confusion.  I think the people 
intimately familiar with the source should be able to figure
things out.

(Ignore 2.42.)


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

Comment By: Stefan Schwarzer (sschwarzer)
Date: 2003-08-11 07:00

Message:
Logged In: YES 
user_id=383516

I thought the bug would be related to some wrong string
length calculation. If  the reason is really obvious from
the C-Code, as you describe, I can live with it. It's just a
bit confusing.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-08-11 02:54

Message:
Logged In: YES 
user_id=357491

For the first issue, the use of StringO in Modules/cStringIO.c is 
mentioned in three places; the naming of the type, and twice in 
the docs for the code for the type.  This is because the way it is 
implemented the modules uses two different types; 
cStringIO.StringO and cStringIO.StringI (the latter which seems to 
mostly be used for iterators).  You just happen to be running into 
the implementation exposing itself.

I honestly don't know if it should be changed.  Since the StringO 
type seems to handle both input and output it would seem 
reasonable to change the type name.  What do other people think?

As for the second example. only the class name is showing up 
without the module name because StringIO is written in Python 
and thus does not have its name specified in a string as the 
cStringIO types do.  The quotation marks are missing because the 
exception is not printing out a string like with the cStringIO 
instance; it is getting the name through inference.

So the only thing to think of changing is the name of the 
cStringIO.StringO to "cStringIO.StringIO".  The problem is that in 
the code there are structs named IOobject, Oobject, and Iobject.  
Guess which one StringO derives from?  So changing the name 
might cause some confusion in the source code if it is not read 
carefully.  So I am -0 on changing it.  Anyone else have a 
comment?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786314&group_id=5470



More information about the Python-bugs-list mailing list