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
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 befo
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
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.
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
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
+++
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.or
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 neces
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 h
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
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/issue1
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
Changes by Greg Ward :
--
title: optparse -> optparse: clarify option concatenation in docs
___
Python tracker
<http://bugs.python.org/issue>
___
___
Py
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
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/issue29
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
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
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
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
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/issue17
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&#
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
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
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 priv
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:
+
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://bu
Changes by Greg Ward :
Added file: http://bugs.python.org/file39083/fa4c6160c518.diff
___
Python tracker
<http://bugs.python.org/issue17445>
___
___
Python-bugs-list m
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
Changes by Greg Ward :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue17445>
___
___
Python-bugs-list
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'v
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
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 nic
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://
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 &q
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/issue28
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 enco
36 matches
Mail list logo
