[issue29218] distutils: Remove unused install_misc class
Greg Ward added the comment: LGTM, after a cursory glance at the code history. Been a lng time since I understood this stuff deeply, though! -- ___ Python tracker <http://bugs.python.org/issue29218> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28702] Confusing error message when None used in expressions, eg. "'NoneType' object has no attribute 'foo'"
Greg Ward added the comment: > Is it worth changing about 800 places in CPython code? Not counting > third-party code. Definitely not. My aim is not to fix every possible reference to "instance of 'NoneType'", just the handful of cases that are most frequently encountered, especially if we think they are likely to be confusing to beginners. That's why I've only modified getting and setting attributes so far; I wanted to see what the cost/benefit is like. Renaming 'NoneType' to 'None' sounds like a much easier approach, if it works. But then saying "instance of" + tp_name comes out weird. "Instance of NoneType" is confusing if technically accurate; "instance of None" is both confusing and technically inaccurate. H. Still mulling. -- ___ Python tracker <http://bugs.python.org/issue28702> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28702] Confusing error message when None used in expressions, eg. "'NoneType' object has no attribute 'foo'"
Greg Ward added the comment: Based on a brief conversation with Brett Cannon at PyCon Canada the other day. Thanks for the idea, Brett! -- nosy: +brett.cannon ___ Python tracker <http://bugs.python.org/issue28702> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28702] Confusing error message when None used in expressions, eg. "'NoneType' object has no attribute 'foo'"
New submission from Greg Ward:
Python's error message when you let None accidentally sneak into an expression
where it doesn't belong could be better. The canonical example is attribute
lookup:
>>> a = None
>>> a.foo
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'NoneType' object has no attribute 'foo'
This assumes that the programmer knows there is only one object of type
NoneType, and it is None. That's a lot to assume of a beginner, whether they
are coming from another programming language ("null has a type? that's crazy
talk!") or are completely new to programming ("null? none? nil? wat...??").
There are plenty of other places this use of NoneType in error messages comes
up:
>>> a + 1
Traceback (most recent call last):
File "", line 1, in
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'
>>> 1 + a
Traceback (most recent call last):
File "", line 1, in
TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'
>>> len(a)
Traceback (most recent call last):
File "", line 1, in
TypeError: object of type 'NoneType' has no len()
>>> a < 1
Traceback (most recent call last):
File "", line 1, in
TypeError: '<' not supported between instances of 'NoneType' and 'int'
I think we can do better than this. For example, here is an proposed
improvement to user experience for getting and setting attributes on None:
>>> a.foo
Traceback (most recent call last):
File "", line 1, in
AttributeError: attempt to access attribute 'foo' of None, but None has no
attributes
>>> a.foo = 42
Traceback (most recent call last):
File "", line 1, in
AttributeError: attempt to set attribute 'foo' on None, but None is read-only
Let the bikeshedding commence. I have a working patch, but need to write tests.
Will upload it here when that is done.
--
assignee: gward
components: Interpreter Core
messages: 280884
nosy: gward
priority: normal
severity: normal
status: open
title: Confusing error message when None used in expressions, eg. "'NoneType'
object has no attribute 'foo'"
type: enhancement
versions: Python 3.6
___
Python tracker
<http://bugs.python.org/issue28702>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28700] test_dbm failure: KeyError: b'0' (intermittent in 3.5, reliable in 3.6)
Changes by Greg Ward : -- title: test_dbm failure: KeyError: b'0' (regression in 3.6) -> test_dbm failure: KeyError: b'0' (intermittent in 3.5, reliable in 3.6) ___ Python tracker <http://bugs.python.org/issue28700> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28700] test_dbm failure: KeyError: b'0' (regression in 3.6)
Greg Ward added the comment: As suggested in http://bugs.python.org/issue14120, I installed libgdbm-dev, re-configured, and re-compiled. That fixes the problem. IMHO that's not good enough: if we're missing a dependency, then either configuring or building should fail. It's nice that the test failure is now rock-solid reliable rather than intermittent, but it's still a test failure due to missing dependency. Yuck. -- ___ Python tracker <http://bugs.python.org/issue28700> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28700] test_dbm failure: KeyError: b'0' (regression in 3.6)
Greg Ward added the comment: Forgot to mention: I'm running: No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 16.04.1 LTS Release:16.04 Codename: xenial with $ dpkg-query -W | grep dbm libgdbm3:amd64 1.8.3-13.1 -- ___ Python tracker <http://bugs.python.org/issue28700> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28700] test_dbm failure: KeyError: b'0' (regression in 3.6)
New submission from Greg Ward:
test_dbm.py fails reliably for me in 3.6, but in 3.5 it passes ~80% of the
time. The failure in both cases is KeyError: b'0', which has come up previously
in http://bugs.python.org/issue20094 and http://bugs.python.org/issue14120.
But since we've switched from 20% failure rate to 100% failure rate, I figured
something must have changed. I used "hg bisect" to track it down to a recent
commit:
changeset: 103360:0bd618fe0639
user:Victor Stinner
date:Wed Sep 07 17:40:12 2016 -0700
summary: Implement compact dict
Here is how it fails:
$ ./python -m test -v test_dbm
== CPython 3.6.0a4+ (default:0bd618fe0639, Nov 15 2016, 14:07:07) [GCC 5.4.0
20160609]
== Linux-4.4.0-47-generic-x86_64-with-debian-stretch-sid little-endian
== hash algorithm: siphash24 64bit
== /home/data/src/cpython/3.6/build/test_python_10093
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0,
dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0,
verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
Run tests sequentially
0:00:00 [1/1] test_dbm
test_keys (test.test_dbm.WhichDBTestCase) ... ok
test_whichdb (test.test_dbm.WhichDBTestCase) ... ok
test_whichdb_ndbm (test.test_dbm.WhichDBTestCase) ... BDB0004 fop_read_meta:
@test_10093_tmp_ndbm.db: unexpected file type or format
ok
test_anydbm_access (test.test_dbm.TestCase-dbm.ndbm) ... ok
test_anydbm_creation (test.test_dbm.TestCase-dbm.ndbm) ... ERROR
BDB3028 @test_10093_tmp.db: unable to flush: No such file or directory
test_anydbm_creation_n_file_exists_with_invalid_contents
(test.test_dbm.TestCase-dbm.ndbm) ... ok
test_anydbm_keys (test.test_dbm.TestCase-dbm.ndbm) ... ok
test_anydbm_modification (test.test_dbm.TestCase-dbm.ndbm) ... ERROR
BDB3028 @test_10093_tmp.db: unable to flush: No such file or directory
test_anydbm_not_existing (test.test_dbm.TestCase-dbm.ndbm) ... ok
test_anydbm_read (test.test_dbm.TestCase-dbm.ndbm) ... ERROR
test_error (test.test_dbm.TestCase-dbm.ndbm) ... ok
test_anydbm_access (test.test_dbm.TestCase-dbm.dumb) ... ok
test_anydbm_creation (test.test_dbm.TestCase-dbm.dumb) ... ok
test_anydbm_creation_n_file_exists_with_invalid_contents
(test.test_dbm.TestCase-dbm.dumb) ... ok
test_anydbm_keys (test.test_dbm.TestCase-dbm.dumb) ... ok
test_anydbm_modification (test.test_dbm.TestCase-dbm.dumb) ... ok
test_anydbm_not_existing (test.test_dbm.TestCase-dbm.dumb) ... ok
test_anydbm_read (test.test_dbm.TestCase-dbm.dumb) ... ok
test_error (test.test_dbm.TestCase-dbm.dumb) ... ok
==
ERROR: test_anydbm_creation (test.test_dbm.TestCase-dbm.ndbm)
--
Traceback (most recent call last):
File "/home/data/src/cpython/3.6/Lib/test/test_dbm.py", line 73, in
test_anydbm_creation
self.read_helper(f)
File "/home/data/src/cpython/3.6/Lib/test/test_dbm.py", line 114, in
read_helper
self.assertEqual(self._dict[key], f[key.encode("ascii")])
KeyError: b'0'
==
ERROR: test_anydbm_modification (test.test_dbm.TestCase-dbm.ndbm)
--
Traceback (most recent call last):
File "/home/data/src/cpython/3.6/Lib/test/test_dbm.py", line 88, in
test_anydbm_modification
self.read_helper(f)
File "/home/data/src/cpython/3.6/Lib/test/test_dbm.py", line 114, in
read_helper
self.assertEqual(self._dict[key], f[key.encode("ascii")])
KeyError: b'0'
==
ERROR: test_anydbm_read (test.test_dbm.TestCase-dbm.ndbm)
--
Traceback (most recent call last):
File "/home/data/src/cpython/3.6/Lib/test/test_dbm.py", line 94, in
test_anydbm_read
self.read_helper(f)
File "/home/data/src/cpython/3.6/Lib/test/test_dbm.py", line 114, in
read_helper
self.assertEqual(self._dict[key], f[key.encode("ascii")])
KeyError: b'0'
--
Ran 19 tests in 0.052s
FAILED (errors=3)
test test_dbm failed
test_dbm failed
1 test failed:
test_dbm
Total duration: 77 ms
Tests result: FAILURE
--
components: Tests
messages: 280877
nosy: gward
priority: normal
severity: normal
status: open
title: test_dbm failure: KeyError: b'0' (regression in 3.6)
type: behavior
versions: Python 3.6
___
Python tracker
<http://bugs.python.org/issue28700>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Handle bytes comparisons in difflib.Differ
Changes by Greg Ward : -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue17445> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Handle bytes comparisons in difflib.Differ
Greg Ward added the comment: Just uploaded https://bugs.python.org/file39083/fa4c6160c518.diff. Pretty sure I've addressed all of @berker.peksag's review comments: thanks for that! I also fixed a number of subtle bugs in the tests. Pro tip: when asserting that something raises TypeError, inspect the exception message. There are many many ways that Python code can raise TypeError *other than* the condition you thought you were testing for. ;-) I'm happy with this patch now unless anyone else spots problems. @durin42: have you been trying this patch with your Mercurial-on-Python-3.5 patches? This would be a good time to re-update your difflib.py. -- ___ Python tracker <http://bugs.python.org/issue17445> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Handle bytes comparisons in difflib.Differ
Changes by Greg Ward : Added file: http://bugs.python.org/file39083/fa4c6160c518.diff ___ Python tracker <http://bugs.python.org/issue17445> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Handle bytes comparisons in difflib.Differ
Greg Ward added the comment: OK I've revived my patch and rebased on latest trunk. http://hg.gerg.ca/cpython/rev/13161c1d9c5f Comments welcome. I'll push this in a couple of days if nobody objects. -- ___ Python tracker <http://bugs.python.org/issue17445> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2931] optparse: various problems with unicode and gettext
Greg Ward added the comment: > I've turned ash's test program into a bunch of test cases against > Python 3.5 trunk. Is it worth committing them? Yeah, probably. Review comments... +try: +self.parser.error(RUSSIAN_TEXT) +except InterceptedError: +pass Why not self.assertRaises()? Also, when I run the test on its own, it prints ''' Usage: regrtest.py [options] regrtest.py: error: Русский текст --unknown ''' to stderr. Probably need to fiddle with sys.stderr to fix that. Blech. Finally: +try: +import optparse +old_gettext = optparse._ +optparse._ = dummy_gettext + +try: +OptionParser().parse_args(["--unknown"]) +except SystemExit: +pass +finally: +optparse._ = old_gettext This is a lot easier with mock. -- ___ Python tracker <http://bugs.python.org/issue2931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21775] shutil.copytree() crashes copying to VFAT on Linux: AttributeError: 'PermissionError' object has no attribute 'winerror'
Greg Ward added the comment: > I'll commit on branch 3.4 and merge to default. Whoops, never mind. Looks like I don't have push permission to hg.python.org after all. It's been 8 years since my last commit, so I shouldn't complain. So... can someone with commit privs please hg pull -r 3a1fc6452340 http://hg.gerg.ca/cpython then merge to trunk and push? Thanks! -- ___ Python tracker <http://bugs.python.org/issue21775> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21775] shutil.copytree() crashes copying to VFAT on Linux: AttributeError: 'PermissionError' object has no attribute 'winerror'
Greg Ward added the comment:
> Would it be possible to write a unit test, maybe using unittest.mock to
> mock most parts?
Good idea! Turns out this was quite straightforward. The test patch is:
--- a/Lib/test/test_shutil.py
+++ b/Lib/test/test_shutil.py
@@ -1,6 +1,7 @@
# Copyright (C) 2003 Python Software Foundation
import unittest
+import unittest.mock
import shutil
import tempfile
import sys
@@ -758,6 +759,20 @@
self.assertEqual(os.stat(restrictive_subdir).st_mode,
os.stat(restrictive_subdir_dst).st_mode)
+@unittest.mock.patch('os.chmod')
+def test_copytree_winerror(self, mock_patch):
+# When copying to VFAT, copystat() raises OSError. On Windows, the
+# exception object has a meaningful 'winerror' attribute, but not
+# on other operating systems. Do not assume 'winerror' is set.
+src_dir = tempfile.mkdtemp()
+dst_dir = os.path.join(tempfile.mkdtemp(), 'destination')
+self.addCleanup(shutil.rmtree, src_dir)
+self.addCleanup(shutil.rmtree, os.path.dirname(dst_dir))
+
+mock_patch.side_effect = PermissionError('ka-boom')
+with self.assertRaises(shutil.Error):
+shutil.copytree(src_dir, dst_dir)
+
@unittest.skipIf(os.name == 'nt', 'temporarily disabled on Windows')
@unittest.skipUnless(hasattr(os, 'link'), 'requires os.link')
def test_dont_copy_file_onto_link_to_itself(self):
When run without the bug fix, this reproduces my original failure nicely:
$ ./python Lib/test/test_shutil.py
ss.sE..s..s..
==
ERROR: test_copytree_winerror (__main__.TestShutil)
--
Traceback (most recent call last):
File "/data/src/cpython/3.4/Lib/shutil.py", line 337, in copytree
copystat(src, dst)
File "/data/src/cpython/3.4/Lib/shutil.py", line 191, in copystat
lookup("chmod")(dst, mode, follow_symlinks=follow)
File "/data/src/cpython/3.4/Lib/unittest/mock.py", line 896, in __call__
return _mock_self._mock_call(*args, **kwargs)
File "/data/src/cpython/3.4/Lib/unittest/mock.py", line 952, in _mock_call
raise effect
PermissionError: ka-boom
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/data/src/cpython/3.4/Lib/unittest/mock.py", line 1136, in patched
return func(*args, **keywargs)
File "Lib/test/test_shutil.py", line 774, in test_copytree_winerror
shutil.copytree(src_dir, dst_dir)
File "/data/src/cpython/3.4/Lib/shutil.py", line 340, in copytree
if why.winerror is None:
AttributeError: 'PermissionError' object has no attribute 'winerror'
--
Ran 89 tests in 0.095s
FAILED (errors=1, skipped=5)
Excellent! No need for root privs, and the bug is quite obvious.
Apply my getattr() fix, and the test passes.
I'll commit on branch 3.4 and merge to default.
--
___
Python tracker
<http://bugs.python.org/issue21775>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21775] shutil.copytree() crashes copying to VFAT on Linux: AttributeError: 'PermissionError' object has no attribute 'winerror'
Greg Ward added the comment: Bad news: because reproducing this requires sudo (to mount an arbitrary filesystem), I'm not sure it's possible/desirable to add test code for it. Good news: the fix is trivial, and it passes my manual test. Here's a patch: --- a/Lib/shutil.py +++ b/Lib/shutil.py @@ -336,7 +336,7 @@ copystat(src, dst) except OSError as why: # Copying file access times may fail on Windows -if why.winerror is None: +if getattr(why, 'winerror', None) is None: errors.append((src, dst, str(why))) if errors: raise Error(errors) Running test suite now to make sure this doesn't break anything else... -- ___ Python tracker <http://bugs.python.org/issue21775> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21775] shutil.copytree() crashes copying to VFAT on Linux: AttributeError: 'PermissionError' object has no attribute 'winerror'
Greg Ward added the comment: In 3.3 and earlier, copytree() crashes roughly as described in issue1545, with shutil.Error that wraps the underlying "Operation not permitted" error from trying to chmod() something in a VFAT filesystem. Since this appears to accurately reflect what's coming from the kernel, I don't *think* this is a bug. Only the AttributeError, which is new in 3.4, is clearly a bug. -- keywords: +3.4regression ___ Python tracker <http://bugs.python.org/issue21775> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21775] shutil.copytree() crashes copying to VFAT on Linux: AttributeError: 'PermissionError' object has no attribute 'winerror'
New submission from Greg Ward:
When using shutil.copytree() on Linux to copy to a VFAT filesystem, it crashes
like this:
Traceback (most recent call last):
File "/data/src/cpython/3.4/Lib/shutil.py", line 336, in copytree
copystat(src, dst)
File "/data/src/cpython/3.4/Lib/shutil.py", line 190, in copystat
lookup("chmod")(dst, mode, follow_symlinks=follow)
PermissionError: [Errno 1] Operation not permitted: '/mnt/example_nt'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "copytree-crash.py", line 14, in
shutil.copytree('PC/example_nt', '/mnt/example_nt')
File "/data/src/cpython/3.4/Lib/shutil.py", line 339, in copytree
if why.winerror is None:
AttributeError: 'PermissionError' object has no attribute 'winerror'
I am *not* complaining about the PermissionError. That has been issue1545.
Rather, I'm complaining about the crash that happens while attempting to handle
the PermissionError.
Reproducing this is fairly easy, although it requires root privilege.
1. dd if=/dev/zero of=dummy bs=1024 count=1024
2. mkfs.vfat -v dummy
3. sudo mount -o loop /tmp/dummy /mnt
Then create the reproduction script in the root of Python's source dir:
cat > copytree-crash.py <
<http://bugs.python.org/issue21775>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19536] MatchObject should offer __getitem__()
Greg Ward added the comment: >>> import this [...] There should be one-- and preferably only one --obvious way to do it. -- nosy: +gward ___ Python tracker <http://bugs.python.org/issue19536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Handle bytes comparisons in difflib.Differ
Greg Ward added the comment: > I recommend the following: replace the simple test in the attached > bytes_diff.py with > Greg's unittest-based tests and adjust the __name__ == '__main__' incantation > accordingly. Latest patch, following Terry's suggestion: http://hg.gerg.ca/cpython/rev/6718d54cf9eb Pro: - does not touch unified_diff() or context_diff(), just adds a new function - no question that this is a new feature, so no debate about what branch to commit on - forces caller to know exactly what they are dealing with, strings or bytes Con: - not a bug fix, so 3.3 users won't get it ... but they can just copy the implementation of diff_bytes() (or, as Terry suggests, it could live on PyPI) - has explicit isinstance() checks (for a good reason: see the comments) - also has more Pythonic "raise TypeError if s.decode raised AttributeError", which is friendlier to duck typing but inconsistent with the isinstance() checks used elsewhere in the patch Overall I'm fairly happy with this. Not too thrilled with the explicit type checks; suggestions welcome. Regarding Terry's suggestion of putting diff_bytes() on PyPI: meh. If the only project that needs this is Mercurial, that would be pointless. Mercurial doesn't have PyPI dependencies, and that is unlikely to change. This might be one of those rare cases where copying the code is easier than depending on it. -- assignee: -> gward ___ Python tracker <http://bugs.python.org/issue17445> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Handle bytes comparisons in difflib.Differ
Greg Ward added the comment: Thanks for the review, Terry! Here is a revised patch, now on trunk: http://hg.gerg.ca/cpython/rev/6dedcdbe7cd5 I believe I have addressed all of your concerns. Note also that the tests now highlight some dubious behaviour. Further feedback is welcome! I'm happy to rebase onto 3.3 if folks generally agree it's safe. (It seems fine to me; IMHO being unable to handle bytes is a regression relative to Python 2.) -- ___ Python tracker <http://bugs.python.org/issue17445> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Handle bytes comparisons in difflib.Differ
Greg Ward added the comment: Take 3: http://hg.gerg.ca/cpython/rev/78bdb10551ee - uses surrogateescape as suggested by Antoine - seems to work -- ___ Python tracker <http://bugs.python.org/issue17445> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Return the type you accept
Greg Ward added the comment:
OK I now have two competing patches. Both are disgusting, but in different ways.
1) http://hg.gerg.ca/cpython/rev/fcf3d27f20d9
- factor out all the string constants
- always concatenate, do not .format()
2) http://hg.gerg.ca/cpython/rev/cebefce2cfd4
- copy {unified,context}_diff() to {unified,context}_diff_bytes()
- this is a future maintenance headache, guaranteed!
Feedback welcome. If anyone can see a way to unify these two approaches, or a
third way that sucks less, I'm all ears.
--
hgrepos: +179
___
Python tracker
<http://bugs.python.org/issue17445>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Return the type you accept
Greg Ward added the comment: Replying to Terry Reedy: > So a dual string/bytes function would not be completely trivial. Correct. I have one working, but it makes my eyes bleed. I fail ashamed to have written it. > Greg, can you convert bytes to strings, or strings to bytes Nope. Here is the hypothetical use case: I have a text file written in Polish encoded in ISO-8859-1 committed to a Mercurial repository. (Or saved in a filesystem somewhere: doesn't really matter, except that Mercurial repositories are immutable, long-term, and *must* *not* *lose* *data*.) Then I decide I should play nicely with the rest of the world and transcode to UTF-8, so commit a new rev in UTF-8. Years later, I need to look at the diff between those two old revisions. Rev 1 is a pile of ISO-8859-2 bytes, and rev 2 is a pile of UTF-8 bytes. The output of diff looks like - blah blah [iso-8859-2 bytes] blah + blah blah [utf-8 bytes] blah Note this: the output of diff has some lines that are iso-8859-2 bytes and some that are utf-8 bytes. *There is no single encoding* that applies. Note also that diff output must contain the exact original bytes, so that it can be consumed by patch. Diffs are read both by humans and by machines. > Otherwise, I think it might be better to write a new function > 'unified_diff_bytes' that did exactly what you want than to try to > make unified_diff accept sequences of bytes. Good idea. That might be much less revolting than what I have now. I'll give it a shot. -- ___ Python tracker <http://bugs.python.org/issue17445> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Return the type you accept
Greg Ward added the comment: The original reproduction I posted was incorrect -- it makes difflib look worse than it should. (I passed strings rather than lists of strings.) Here is a more accurate version: >>> import difflib >>> a = [b'hello'] >>> b = [b'hello!'] >>> '\n'.join(line for line in difflib.unified_diff(a, b)) Traceback (most recent call last): File "", line 1, in File "", line 1, in File "/home/greg/src/cpython/3.3/Lib/difflib.py", line 1223, in unified_diff yield '-' + line TypeError: Can't convert 'bytes' object to str implicitly So it still crashes, but the exception makes it pretty clear what the problem is. -- ___ Python tracker <http://bugs.python.org/issue17445> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Return the type you accept
Greg Ward added the comment: The particular use case that triggered this: Mercurial's test suite. It runs "hg blah blah" and compares the output against known good output. But Mercurial's output is just bytes, because pretty much everything in a Mercurial repo is just bytes (file data of course, but also filenames and even changeset metadata like usernames). So attempting to run the Mercurial test suite under 3.x immediately fails hard. The boiled-down essence of the bug is this: >>> import difflib >>> a = b"hello world" >>> b = b"goodbye world" >>> [line for line in difflib.unified_diff(a, b)] Traceback (most recent call last): File "", line 1, in File "", line 1, in File "/home/greg/src/cpython/3.2/Lib/difflib.py", line 1224, in unified_diff yield '-' + line TypeError: Can't convert 'int' object to str implicitly -- nosy: +durin42, gward ___ Python tracker <http://bugs.python.org/issue17445> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15510] textwrap.wrap('') returns empty list
Greg Ward added the comment: Random comments from original author of textwrap.py, in case anyone cares at this point... * This is a pretty obscure edge case, and I admit that it never occurred to me when writing the code. (If it had, I would have tested it!) * One can debate endlessly about whether this is a bug or not -- witness the recent discussion on this bug. Meh. Not interesting. IMHO it's better described as undefined behaviour. If you want it defined, write tests to enforce the status quo and improve the docs. * If there is a consensus to change the current behaviour, IMHO it should NOT be done on 2.7. Even if the new behaviour is better by some definition, it's still a behaviour change that could bite someone. Those changes should happen when you make a major upgrade (3.2 to 3.3, say), not when you make a bug fix upgrade (2.7.3 to 2.7.4). IOW: keep it on trunk. Or default, whatever we're calling it these days. ;-) -- ___ Python tracker <http://bugs.python.org/issue15510> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6454] Add "example" keyword argument to optparse constructor
Greg Ward added the comment: > I understood Greg’s reply to mean that there was no need for an examples > keyword if simple paragraph splitting was added. Right, but optparse has been superseded by argparse. So my opinion is even less important than it was before 2.7. -- ___ Python tracker <http://bugs.python.org/issue6454> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2236] Distutils' mkpath implementation ignoring the "mode" parameter
Greg Ward added the comment: I'm unassigning this since I no longer know how to commit changes to Python. Sorry, I just haven't kept track over the years, I don't follow python-dev anymore, and I could not find documentation explaining where I should commit what sort of changes. -- assignee: gward -> tarek ___ Python tracker <http://bugs.python.org/issue2236> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2236] Distutils' mkpath implementation ignoring the "mode" parameter
Greg Ward added the comment: > Is it too late for 2.7? I have no idea. It does look as though someone has written unit tests for distutils, so the patch needs a test change too. Henrique? -- stage: -> unit test needed ___ Python tracker <http://bugs.python.org/issue2236> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1859] textwrap doesn't linebreak on "\n"
Greg Ward added the comment: > Greg, any comment on this issue? Yes, two: 1) textwrap does not handle paragraphs or paragraph breaks in any way. That was a deliberate limitation to keep the code from getting any hairier. People have complained about this in the past, and I have studiously ignored such complaints. The standard answer is that you should break your text into paragraphs and then feed those paragraphs individually to a TextWrapper. But this does not look like that old complaint. 2) Test, test, test. In case you hadn't already noticed, this is a hairy piece of code. It's also a poster child for unit testing. Any change should IMHO be accompanied by lots of new tests. No wait, make that *three* comments: 3) I agree with tlynn that the example in msg95469 looks *awfully* fishy. But I don't remember enough of the details to say what's likely to be broken. That's probably your first test case right there. -- ___ Python tracker <http://bugs.python.org/issue1859> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6454] Add "example" keyword argument to optparse constructor
Greg Ward added the comment: > but I feel there is a better and more general > solution - just provide some minimal formatting for description: treat > empty line as paragraph separator. Then I would be able to add example > or anything else to the description formatting it as necessary Agreed. I have also been bitten by optparse munging paragraphs together in the description, and it's annoying. I *think* we could get away with two simple rules: * blank lines separate paragraphs * indented lines don't get wrapped Obviously no one wants to reinvent reStructuredText, but I think that should do the trick. If that works, I think the suggested 'examples' arg becomes unnecessary. -- ___ Python tracker <http://bugs.python.org/issue6454> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5555] optparse: clarify option concatenation in docs
Changes by Greg Ward : -- title: optparse -> optparse: clarify option concatenation in docs ___ Python tracker <http://bugs.python.org/issue> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5555] optparse
Greg Ward added the comment: > This is an edited-down excerpt form the optparse documentation from: > > http://docs.python.org/library/optparse.html > > "... the traditional Unix syntax is a hyphen (“-“) followed by a > single letter [...] Some other option syntaxes that the world has seen include: >* a hyphen followed by a few letters, e.g. "-pf" [...] Note that the second "[...]" expands to "(this is *not* the same as multiple options merged into a single argument)". Which means: 1) optparse *does* implement the traditional Unix option-munging that has been around since at least the mid-1980s 2) the proposed statement "optparse has chosen to implement a subset of the GNU coding standard's command line interface guidelines, allowing for both long and short options, but not the POSIX-style concatenation of short options." is false Offhand, I don't see a way for the documentation to be any clearer. Maybe an example of "-a" and "-b" munged to "-ab"? -- ___ Python tracker <http://bugs.python.org/issue> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1704474] optparse tests fail under Jython
Changes by Greg Ward : -- components: +Library (Lib) -Tests title: test_optparse.py mod. for jython -> optparse tests fail under Jython ___ Python tracker <http://bugs.python.org/issue1704474> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1704474] test_optparse.py mod. for jython
Greg Ward added the comment: I just took a look at the original patch uploaded by drtimcouper. IMHO it would be cleaner and simpler to modify optparse.py so that it behaves as consistently as possible under Jython and CPython. For example, optparse should catch the ValueError raised when a user supplies a bad integer input and raise a new exception with a consistent error message. That sort of thing. drtimcouper: if you're still out there and reading this, would you mind submitting a new patch? -- ___ Python tracker <http://bugs.python.org/issue1704474> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
