[issue21343] os.path.relpath returns inconsistent types
New submission from Matt Bachmann: I noticed an issue passing in unicode to os.path.relpath. Specifically that in some cases when passing in unicode I would get back unicode and others I would get back a string. Below I demonstrate the issue. I also attached a patch. Is this an issue or am I misunderstanding something. Is the patch reasonable? Totally willing to improve and i'll admit I cannot test the ntpath version. Python 2.7.6 (default, Apr 9 2014, 11:48:52) [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.38)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.path.relpath(u'.', u'.') '.' >>> os.path.relpath(u'.', u'../') u'bachmann' -- components: Library (Lib) files: reldir.patch keywords: patch messages: 217119 nosy: Matt.Bachmann priority: normal severity: normal status: open title: os.path.relpath returns inconsistent types type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file35019/reldir.patch ___ Python tracker <http://bugs.python.org/issue21343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21343] os.path.relpath returns inconsistent types
Matt Bachmann added the comment: Can you help me understand why not? If I give it two unicode strings it sometimes gives me back a unicode and sometimes gives me back a string. In python3 this does what I expect. In python27 I now have to check the type I get back because I cannot be sure what type I will be getting back. -- ___ Python tracker <http://bugs.python.org/issue21343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21343] os.path.relpath returns inconsistent types
Matt Bachmann added the comment: There is a difference! '.' is a bytes string and u'.' is a unicode one! I found this problem because I work on a project that supports both python2 and python3. In python3 I pass in unicode I get back unicode. In python2.7 I pass in unicode and I get back a bytes string. We need to ensure that all data in the system is unicode. Under 2.7 I get unicode sometimes and bytes other times so I need to do this ugly check root_rel_path = os.path.relpath(self._cwd, self._root) if isinstance(root_rel_path, six.binary_type): root_rel_path = root_rel_path.decode() in order to ensure that my string is once again of the correct type. -- ___ Python tracker <http://bugs.python.org/issue21343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21343] os.path.relpath returns inconsistent types
Matt Bachmann added the comment: Perhaps this is the bug I should be filing but here is why this comes up for me. I get different output from this function if I pass in two types. On my machine: os.path.relpath(u'test_srcl.txt', u'.') returns u'test_src.txt' os.path.relpath(u'test_srcl.txt', '.') returns u'../../Users/bachmann/Code/diff-cover/diff_cover/tests/fixtures/test_src.txt' I make a couple calls to this function, if the first call gives me back a byte string and I pass it to the second call I get the incorrect result. So I need to decode. If the function always gave back the same type as I gave it I would not have this issue. -- ___ Python tracker <http://bugs.python.org/issue21343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21343] os.path.relpath returns inconsistent types
Matt Bachmann added the comment: Looking into the project im working on I discovered why relpath was acting strangely. It is because the project mocks get_cwd but not get_cwdu. Your request helped me track that down :-) So that is not an issue. However, the issue described in the original ticket definitely happens in a clean python shell. I still think it is bad that the method sometimes returns str and sometimes returns unicode, but I see your point that ultimately the byte strings that do come out of here coerce into unicode cleanly. Thanks for working though this with me. -- ___ Python tracker <http://bugs.python.org/issue21343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21883] relpath: Provide better errors when mixing bytes and strings
New submission from Matt Bachmann:
Howdy!
I encountered this error when accidently passing in mixed types to reldir
>>> import os
>>> os.path.relpath('/Users/bachmann', b'.')
Traceback (most recent call last):
File "", line 1, in
File
"/usr/local/Cellar/python3/3.4.1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/posixpath.py",
line 451, in relpath
start_list = [x for x in abspath(start).split(sep) if x]
TypeError: Type str doesn't support the buffer API
When this mistake is done in join we get a helpful error message.
I simply borrowed this logic and put in in relpath. Is this useful?
--
components: Library (Lib)
messages: 221939
nosy: Matt.Bachmann
priority: normal
severity: normal
status: open
title: relpath: Provide better errors when mixing bytes and strings
type: enhancement
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue21883>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21883] relpath: Provide better errors when mixing bytes and strings
Changes by Matt Bachmann : -- keywords: +patch Added file: http://bugs.python.org/file35805/error_message.patch ___ Python tracker <http://bugs.python.org/issue21883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21883] relpath: Provide better errors when mixing bytes and strings
Changes by Matt Bachmann : Removed file: http://bugs.python.org/file35805/error_message.patch ___ Python tracker <http://bugs.python.org/issue21883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21883] relpath: Provide better errors when mixing bytes and strings
Matt Bachmann added the comment: Includes change and tests. The test is similar so I just broke out the logic -- Added file: http://bugs.python.org/file35806/error_message.patch ___ Python tracker <http://bugs.python.org/issue21883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17451] Test to splitdoc in pydoc.py
New submission from Matt Bachmann: Found a line in splitdoc that was not being exercised. I added a test for it. -- components: Library (Lib) files: splitdoc_description_test.patch keywords: patch messages: 184427 nosy: Matt.Bachmann priority: normal severity: normal status: open title: Test to splitdoc in pydoc.py type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file29437/splitdoc_description_test.patch ___ Python tracker <http://bugs.python.org/issue17451> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17451] Test to splitdoc in pydoc.py
Changes by Matt Bachmann : Added file: http://bugs.python.org/file29444/acks.patch ___ Python tracker <http://bugs.python.org/issue17451> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17451] Test to splitdoc in pydoc.py
Matt Bachmann added the comment: This has the test in the wrong place and I am actively expanding it. I will reopen later today. -- resolution: -> rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue17451> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17464] Improve Test Coverage Of Pydoc
Changes by Matt Bachmann : -- components: +Tests type: -> enhancement ___ Python tracker <http://bugs.python.org/issue17464> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17464] Improve Test Coverage Of Pydoc
New submission from Matt Bachmann: Adds some test coverage to pydoc. -- files: pydoctests.patch keywords: patch messages: 184486 nosy: Matt.Bachmann priority: normal severity: normal status: open title: Improve Test Coverage Of Pydoc versions: Python 3.5 Added file: http://bugs.python.org/file29448/pydoctests.patch ___ Python tracker <http://bugs.python.org/issue17464> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17464] Improve Test Coverage Of Pydoc
Matt Bachmann added the comment: Sure thing, ill make the improvements and upload a new patch. Thanks! -- ___ Python tracker <http://bugs.python.org/issue17464> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17464] Improve Test Coverage Of Pydoc
Matt Bachmann added the comment: --Changes assertequals to assertequal --Removes maxdiff as it should not really be there in the first place --Creates an explicit testdir, and cleans it up --Last patch did not actually apply cleanly... I reverted and applied this one and this seems to work -- Added file: http://bugs.python.org/file29452/pydoc_tests_v2.patch ___ Python tracker <http://bugs.python.org/issue17464> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17464] Improve Test Coverage Of Pydoc
Matt Bachmann added the comment: Thanks for the feedback :-D Changes: Utilize test.support.temp_cwd() Removed imports that this made unnecessary Awesome trick! Cut line length down. Don't worry about nitpicking. Anything to get this to be as good as possible. I added an explanation to the test class explaining why test_getting_all_methods_from_class does not appear. I also agree this is fragile. I have an idea for how to fix this and will upload it as a separate patch (in this thread) because I am not sure what people will think. -- Added file: http://bugs.python.org/file29470/pydoc_tests_v3.patch ___ Python tracker <http://bugs.python.org/issue17464> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17464] Improve Test Coverage Of Pydoc
Matt Bachmann added the comment: Eh, sorry... I tried to do a less fragile way of generating the configuration dict. Tried a few things but it very quickly got messy and even worse started to smell like testing the method with... the method being tested. I am open to ideas though. -- ___ Python tracker <http://bugs.python.org/issue17464> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17476] Pydoc allmethods does not return all methods
New submission from Matt Bachmann: Somewhere between python 2.7 and now the definition of a method changed causing this helper method in pydoc to break. This was discovered in http://bugs.python.org/issue17464 by r.david.murray when he found it curious that a test I wrote was passing. I had assumed the implemented behavior was correct. Attached is a patch that ads in an updated version of that test with a fix to the bug. The method updated is only used in that one place as is indicated as private. So it only gets in classes. I went ahead and updated the param to reflect this. -- components: Library (Lib) files: pydoc_tests_v3.patch keywords: patch messages: 184590 nosy: Matt.Bachmann, r.david.murray priority: normal severity: normal status: open title: Pydoc allmethods does not return all methods versions: Python 3.5 Added file: http://bugs.python.org/file29472/pydoc_tests_v3.patch ___ Python tracker <http://bugs.python.org/issue17476> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17476] Pydoc allmethods does not return all methods
Changes by Matt Bachmann : Removed file: http://bugs.python.org/file29472/pydoc_tests_v3.patch ___ Python tracker <http://bugs.python.org/issue17476> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17476] Pydoc allmethods does not return all methods
Matt Bachmann added the comment: Yes! Sorry. -- Added file: http://bugs.python.org/file29474/fix_is_some_method.patch ___ Python tracker <http://bugs.python.org/issue17476> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23263] Python 3 gives misleading errors when validating unicode identifiers
New submission from Matt Bachmann: PEP 3131 changed the definition of valid identifiers to match this pattern * . Currently if you have an invalid character in an identifier you get this error ☺ = 4 SyntaxError: invalid character in identifier This is fine in most cases. But in some cases the problem is not the character is invalid so much as the character may not be used to START the identifier. One example of this is the "combining grave accent" which is an XID_CONTINUE character but not an XID_START So ̀e is an invalid identifier but è is a valid identifier. So the ̀ character is not invalid in all cases. The attached patch attempts to clarify this by providing a different error when the start character is invalid. >>> ̀e = 4 File "", line 1 ̀e = 4 ^ SyntaxError: invalid start character in identifier However, if the character is simply not allowed (as it is neither an XID_START or an XID_CONTINUE character) the original error is used. >>> ☺smile = 4 File "", line 1 ☺smile = 4 ^ SyntaxError: invalid character in identifier -- components: Unicode files: clarify_unicode_identifier_errors.patch keywords: patch messages: 234222 nosy: Matt.Bachmann, ezio.melotti, haypo priority: normal severity: normal status: open title: Python 3 gives misleading errors when validating unicode identifiers type: enhancement versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file37755/clarify_unicode_identifier_errors.patch ___ Python tracker <http://bugs.python.org/issue23263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23263] Python 3 gives misleading errors when validating unicode identifiers
Matt Bachmann added the comment: Alrighty. I'll investigate and see if I can cut down the code some. If I can't significantly I'll let the issue die quietly. I agree that it's a pretty nitpick ticket. I noticed it while doing some research into unicode and made the patch when I saw how languages like swift handle this case. Thanks for looking at it though! -- ___ Python tracker <http://bugs.python.org/issue23263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
