This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author kevinbhendricks
Recipients kevinbhendricks
Date 2014-10-03.17:36:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1412357790.8.0.103142585174.issue22549@psf.upfronthosting.co.za>
In-reply-to
Content
Hi,

I am working on porting my ebook code from Python 2.7 to work with both Python 2.7 and Python 3.4 and have found the following inconsistency I think is a bug ...

KevinsiMac:~ kbhend$ python3
Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 00:54:21) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

>>> o = '123456789'

>>> o[-3]
'7'

>>> type(o[-3])
<class 'str'>

>>> type(o)
<class 'str'>

the above is what I expected but under python 3 for bytes you get the following instead:

>>> o = b'123456789'

>>> o[-3]
55

>>> type(o[-3])
<class 'int'>

>>> type(o)
<class 'bytes'>
 


When I compare this to Python 2.7 for both bytestrings and unicode I see the expected behaviour. 

Python 2.7.7 (v2.7.7:f89216059edf, May 31 2014, 12:53:48) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.


>>> o = '123456789'

>>> o[-3]
'7'

>>> type(o[-3])
<type 'str'>

>>> type(o)
<type 'str'>


>>> o = u'123456789'

>>> o[-3]
u'7'

>>> type(o[-3])
<type 'unicode'>

>>> type(o)
<type 'unicode'>


I would consider this a bug as it makes it much harder to write python code that works on both python 2.7 and python 3.4
History
Date User Action Args
2014-10-03 17:36:30kevinbhendrickssetrecipients: + kevinbhendricks
2014-10-03 17:36:30kevinbhendrickssetmessageid: <1412357790.8.0.103142585174.issue22549@psf.upfronthosting.co.za>
2014-10-03 17:36:30kevinbhendrickslinkissue22549 messages
2014-10-03 17:36:30kevinbhendrickscreate