[issue3955] maybe doctest doesn't understand unicode_literals?

[Matthis Thorade]

Matthis Thorade added the comment:

I found this bug when trying to write a doctest that passes on Python 3.5 and 
Python 2.7.9.

The following adapted example passes on Python2, but fails on Python3:

# -*- coding: utf-8 -*-
from __future__ import unicode_literals
def f():
"""
>>> f()
u'xyz'
"""
return "xyz"

if __name__ == "__main__":
import doctest
doctest.testmod()

I think a nice solution could be to add a new directive so that I can use the 
following

def myUnic():
"""
This is a small demo that just returns a string.
>>> myUnic()
u'abc' # doctest: +ALLOW_UNICODE
"""
return 'abc'


I asked the same question here:
http://stackoverflow.com/questions/42158733/unicode-literals-and-doctest-in-python-2-7-and-python-3-5

--
nosy: +Matthis Thorade

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3955] maybe doctest doesn't understand unicode_literals?

[Georg Brandl]

Georg Brandl  added the comment:

Yeah, I don't really remember now what my point was.

--
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3955] maybe doctest doesn't understand unicode_literals?

[R. David Murray]

R. David Murray  added the comment:

I fail to see the problem here.  If the module has 'from __future__ import 
unicode_literals", then the docstring output clauses would need to be changed 
to reflect the fact that the input literals are now unicode.  What am I missing?

--
assignee: tim_one -> 
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3955] maybe doctest doesn't understand unicode_literals?

[Christoph Burgmer]

Christoph Burgmer  added the comment:

JFTR: To yield the results of my last comment, you need to apply the
patch posted in http://bugs.python.org/issue1293741

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3955] maybe doctest doesn't understand unicode_literals?

[Christoph Burgmer]

Christoph Burgmer  added the comment:

This problem seems more severe as the appended test case shows.

That gives me:

Expected:
u'ī'
Got:
u'\u012b'

Both literals are the same.

Unicode literals in doc strings are not treated as other escaped
characters: 

>>> repr(r'\n')
"'n'"
>>> repr('\n')
"'\\n'"

but:

>>> repr(ur'\u012b')
"u'\\u012b'"
>>> repr(u'\u012b')
"u'\\u012b'"

So there is no work around in the docstring's reference itself.

I file this here, even though the problems are not strictly equal. I do
believe though that there is or should be a common solution to these
issues. Both results need to be interpreted on a more abstract scale.

--
Added file: http://bugs.python.org/file14406/test.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3955] maybe doctest doesn't understand unicode_literals?

[Christoph Burgmer]

Christoph Burgmer  added the comment:

OutputChecker.check_output() seems to be responsible for comparing
'example.want' and 'got' literals and this is obviously done literally.
So as "u'1'" is different to "'1'" this is reflected in the result.
This gets more complicated with literals like "[u'1', u'2']" I believe.
So, eval() could be used for testing for equality:

>>> repr(['1', '2']) == repr([u'1', u'2'])
False

but

>>> eval(repr(['1', '2'])) == eval(repr([u'1', u'2']))
True

doctests are already compiled and executed, but evaluating the doctest
code's result is probably a security issue, so a method doing the
invers of repr() could be used, that only works on variables; something
like Pickle, but without its own protocol.

--
nosy: +christoph

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3955] maybe doctest doesn't understand unicode_literals?

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

It certainly isn't a feature. I don't immediately see how to fix it,
though. unicode_literals doesn't change the repr() of unicode objects
(it obviously can't, since that change would not be module-local).

Let's try to get a comment from Uncle Timmy...

--
assignee:  -> tim_one
nosy: +georg.brandl, tim_one

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3955] maybe doctest doesn't understand unicode_literals?

[Mark Summerfield]

New submission from Mark Summerfield <[EMAIL PROTECTED]>:

# This program works fine with Python 2.5 and 2.6:
def f():
"""
>>> f()
'xyz'
"""
return "xyz"

if __name__ == "__main__":
import doctest
doctest.testmod()


But if you put the statement "from __future__ import unicode_literals"
at the start then it fails:
File "/tmp/test.py", line 5, in __main__.f
Failed example:
f()
Expected:
'xyz'
Got:
u'xyz'

I don't know if it is a bug or a feature but I didn't see any mention of
it in the bugs or docs so thought I'd mention it.

--
components: Library (Lib)
messages: 73710
nosy: mark
severity: normal
status: open
title: maybe doctest doesn't understand unicode_literals?
type: behavior
versions: Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com