[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