Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue28086>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I think this bug actually is fixed now. I've tried my previously failing case
in Python 3.5 and 3.6 head and I don't get the error.
--
resolution: -> out of date
status: open -> closed
___
Pytho
Barry A. Warsaw added the comment:
Thanks Steve! Closing.
--
nosy: +barry
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue16700>
___
_
Barry A. Warsaw added the comment:
Two things: is it worth fixing this bug given the impending move to github?
Also, why is this reported here and not the pydotorg tracker?
https://github.com/python/pythondotorg/issues
Given that the last comment was 2014, I'm going to go ahead and
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue28160>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I'm -1 also, mostly on the grounds that it's not (IME) a very common need and
it does clutter up the API.
--
nosy: +barry
___
Python tracker
<http://bugs.python.o
New submission from Barry A. Warsaw:
Sometimes we want to control the order of arguments printed by an argparse
defined cli. In practice, arguments are printed in the order in which they are
added via add_argument(), but I don't think this is documented and thus should
be consider
New submission from Barry A. Warsaw:
I'd love to sneak this into 3.6, but I can accept being too late. In any case,
_MutuallyExclusiveGroup.__init__() should accept title and description
arguments and pass them to the super class. Otherwise, you can't great a
mutually exclusive
Barry A. Warsaw added the comment:
Hmm, it might be more complicated than that, so let's ignore 3.6
--
versions: -Python 3.6
___
Python tracker
<http://bugs.python.org/is
Barry A. Warsaw added the comment:
The workaround is to do something like:
group = parser.add_argument_group(title, description)
me_group = group.add_mutually_exclusive_group()
me_group.add_argument(...blah blah blah...)
--
___
Python tracker
<h
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue17218>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Sep 24, 2016, at 05:06 PM, R. David Murray wrote:
>Barry, would you care to render an opinion on this proposed fix?
I think the general approach is probably the best you can do. I noticed a
couple of things though with RDM's v.2 patch.
First, I
Barry A. Warsaw added the comment:
While I was reviewing
https://gitlab.com/mailman/mailman/merge_requests/197/diffs I noticed the
KeyError and it made me thing "hmm, I wonder if this should be turned into one
of the email package e
New submission from Barry A. Warsaw:
This might also affect other Python version; I haven't checked, but I know it
affects Python 3.5.
In Mailman 3, we have a subclass of WSGIRequestHandler for our REST API, and we
got a bug report about an error condition returning a 400 in the body o
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue10721>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue26578>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Oct 28, 2016, at 10:42 PM, Martin Panter wrote:
>I think you should be able to reproduce this without Mailman or tox, by just
>running “python -m http.server”.
Yep, indeed.
>The problem is the “HTTP/0.9” protocol that Python is assuming does not
Barry A. Warsaw added the comment:
On Oct 28, 2016, at 10:57 PM, Martin Panter wrote:
>Parsing the version from words[-1] rather than words[2] may be a minor
>improvement however.
Indeed; I thought about that too.
--
___
Python tracker
Barry A. Warsaw added the comment:
On Oct 29, 2016, at 02:20 AM, Martin Panter wrote:
>Here is a patch to parse the version from the request in more cases. Since it
>is more of a cosmetic improvement for handling erroneous requests, I would
>probably only apply it to the next Pytho
Barry A. Warsaw added the comment:
FWIW, this breaks Mailman 3.1 (and probably 2.1)
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue27030>
___
___
Barry A. Warsaw added the comment:
Specifically, point #2; undefined combinations of \ + ASCII becoming an error.
--
___
Python tracker
<http://bugs.python.org/issue27
Barry A. Warsaw added the comment:
On Nov 22, 2016, at 04:13 PM, Serhiy Storchaka wrote:
>Could Mailman be fixed? Undefined combinations of \ + ASCII emitted warnings
>in 3.5. And now they emit warnings even just in string literals
>(issue27364). If Mailman use undefined escape combina
Changes by Barry A. Warsaw :
--
nosy: +ned.deily
priority: normal -> release blocker
status: closed -> open
___
Python tracker
<http://bugs.python.org/i
Barry A. Warsaw added the comment:
I disagree that the documentation is at fault. This is known to break existing
code, e.g. http://bugs.python.org/msg281496
I think it's not correct to change the documentation but leave the
error-raising behavior for 3.6 because the deprecation was
Changes by Barry A. Warsaw :
--
priority: release blocker -> normal
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue27030>
___
___
Barry A. Warsaw added the comment:
On Nov 22, 2016, at 07:28 PM, Serhiy Storchaka wrote:
>The reason for disallowing some undefined escapes is the same as in pattern
>strings: this would allow as to introduce new special escape sequences.
I'll note that technically speaking, yo
2701 - 2726 of 2726 matches
Mail list logo
