Change by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<https://bugs.python.org/issue24337>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
@xtreak sure, can do. May not have time to do so today but should be able to do
so over the next couple days.
--
___
Python tracker
<https://bugs.python.org/issue12
Change by Demian Brecht :
--
keywords: +patch, patch
pull_requests: +11617, 11618
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Demian Brecht :
--
keywords: +patch, patch, patch
pull_requests: +11617, 11618, 11619
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Demian Brecht :
--
keywords: +patch
pull_requests: +11617
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Demian Brecht :
--
nosy: -demian.brecht
___
Python tracker
<https://bugs.python.org/issue3430>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Demian Brecht :
--
nosy: -demian.brecht
___
Python tracker
<https://bugs.python.org/issue17251>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
>>> urlopen('https://example.com').info()
>>> urlopen('http://example.com').info()
>>> urlopen('ftp://speedtest.tele2.net').info()
>>> urlopen('file:///path/to/setup.py').info()
Demian Brecht added the comment:
@R. David Murray
Is this issue still valid? Running 3.6 it seems that http and ftp are
consistent at any rate (http returns http.client.HTTPMessage and ftp returns
email.message.Message). If it's still an issue, could you please elab
Change by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<https://bugs.python.org/issue12707>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
What if the docs for socket functions that took system-level flag parameters
had links to relevant online man pages? I don't think a single entry at the top
of the page would be optimal. I know that I tend to skip the preamble and just
go directly t
Change by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<https://bugs.python.org/issue20582>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<https://bugs.python.org/issue35292>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Demian Brecht :
--
keywords: +patch
pull_requests: +6369
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33399>
___
___
Py
New submission from Demian Brecht :
Echoing an email sent to python-list:
I recently ran into an issue using the site package and I wanted to confirm
that I'm not doing something wrong here before creating an issue:
I have a need to `git subtree` modules into a Django project and then ad
Demian Brecht added the comment:
> To me, your later throw-in comment about static analyzers might be the most
> persuasive point you made
Well, we're in agreement there :) As I'd mentioned, at best it's a minor
annoyance. I'm entirely on the fence about the use of t
Demian Brecht added the comment:
> BTW I think it is actually OPTIONS; see review comment.
Well, don't I feel silly. Fixed.
--
Added file: http://bugs.python.org/file41962/issue26380_2.patch
___
Python tracker
<http://bugs.python.org
Demian Brecht added the comment:
> I can see the advantage of using an enum over a plain string. But you only
> get an error at run time, not compile time, if you misspell it.
Sure, but at least you're giving static analysis utilities the chance to catch
it up front.
> And the
Demian Brecht added the comment:
> I don't have a firm opinion at this point -- can you give a few examples of
> how this will help in code?
It'll help solely with consistency across projects. Generally, using constants
are generally favored over using hardcoded values.
Demian Brecht added the comment:
If nobody's opposed to the addition, I'll run through the unit tests and
replace the hard coded strings.
--
keywords: +patch
Added file: http://bugs.python.org/file41947/issue26380.diff
___
Python trac
New submission from Demian Brecht:
Super minor annoyance that I've had over multiple projects is seeing either
hard coded strings being used (which is a bit of a no-no in terms of best
practices) or each project defining its own set of constants for http methods.
Why not just incl
Demian Brecht added the comment:
Yeah, agreed that it should be opt-in, at least until a major release.
I've run into a couple cases where higher level libraries use http.client (or
httplib) directly, but don't expose the client directly (not that they should
anyways). Because of t
Demian Brecht added the comment:
Actually had a few free minutes so stuck a couple minor comments in Rietveld.
Will have another go as soon as possible.
--
___
Python tracker
<http://bugs.python.org/issue23
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue24363>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue24209>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
FWIW, I was intending to address the issues Rolf raised. Also, I agree that a
patch shouldn't knowingly have negative knock-on effects to dependents.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Demian Brecht :
--
keywords: +easy
___
Python tracker
<http://bugs.python.org/issue24255>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
Thanks for the report Rolf. I'll look into your suggestion for this patch.
Antoine: Given beta is slated for the 24th and Martin's legitimate concerns, I
think it might be a little hasty to get this in before feature freeze. Knocking
it back to 3.6
New submission from Demian Brecht:
Far too many times have I wished that changing the logging output in
http.client was controllable through logging configuration rather than code
changes modifying a connection's debuglevel.
It would be nice if the http package was brought up to date an
Demian Brecht added the comment:
BTW, thanks for the reviews Martin and the nudge Antoine!
--
___
Python tracker
<http://bugs.python.org/issue12319>
___
___
Pytho
Demian Brecht added the comment:
Latest patch should address all outstanding comments.
--
Added file: http://bugs.python.org/file39447/issue12319_6.patch
___
Python tracker
<http://bugs.python.org/issue12
Demian Brecht added the comment:
Added comments to Rietveld.
--
___
Python tracker
<http://bugs.python.org/issue23377>
___
___
Python-bugs-list mailing list
Unsub
Demian Brecht added the comment:
> This needs a review from the people who created and applied the security
> patch.
+ Guido (committed https://hg.python.org/cpython/rev/9e765e65e5cb)
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.p
Demian Brecht added the comment:
> What's the status on this one? It looks like some review comments need
> addressing.
That's about it. Unfortunately I've been pretty tied up over the last month and
a bit. I'll try to get to hopefully closing this
Demian Brecht added the comment:
If nobody else gets to it first, I'll try to get to review this later today or
tomorrow. Apologies for the delay on the review Martin, a new baby (coming next
month), moving /and/ taking on a new job all at the same time seems to limit
free time a l
New submission from Demian Brecht:
http_proxy and https_proxy are common environment variables used cross
platform. Currently, urllib.request has support for it, but http.client does
not. It probably should.
If support is added to http.client, the handling of proxy environment variables
in
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue17849>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
LGTM, thanks for the patch!
--
nosy: +r.david.murray
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issu
Demian Brecht added the comment:
I left a small comment around indentation in Rietveld.
Also, for the sake of completeness (and for others taking part in this
review/commit), I dug through the relevant RFCs and none of them seem to define
time as having sub-section resolution
Demian Brecht added the comment:
Thanks for the follow up on that. In light of your findings, I agree with the
path you've taken in your patch (and yeah, you'd have to deal with conversions
in the output if you were to take my suggestion). I've left a couple minor
comments in
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue13567>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Demian Brecht:
There's a feature available via nose that might be nice to have in unittest:
package-level setup and teardown functions.
Using nose, I can define a setUpModule() method in a test package's __init__.py
and it will execute it during the test ru
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23930>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
Changing to "behavior" type as crash is generally used to indicate an
interpreter issue.
--
nosy: +orsenthil
stage: -> patch review
type: crash -> behavior
___
Python tracker
<http://bugs.py
Demian Brecht added the comment:
Although it's likely not going to be a high frequency issue (but would be
painful to track down when it does become an issue), by doing an
int(float(expires)), you're losing the sub-second portion of the expiry. Why
not something like this:
try:
Demian Brecht added the comment:
Vincent: The logic to determine content length is undergoing a bit of an
overhaul as part of #12319, which I'm hoping to wrap up in the next week or so.
--
___
Python tracker
<http://bugs.python.org/is
Demian Brecht added the comment:
> I think it's ok to slightly break a non-public API since it's required to fix
> an obvious bug.
To play devil's advocate here, /is/ this really non-public API? According to
documented Python naming conventions, HTTPResponse is part of
Demian Brecht added the comment:
A test really should be added for this. Otherwise, LGTM.
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23888>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
@Cory: my own plan was to use your implementation as the baseline and add
server support. If you take a crack at it that would be great!
--
___
Python tracker
<http://bugs.python.org/issue23
Demian Brecht added the comment:
+1 to the adding the support for HTTP/2. I would personally like to see a few
things happen before that though (which I've been putting some effort into as i
can)
+ refactor http.client to cleanly separate transport from application protocol
level
+ f
Demian Brecht added the comment:
This doesn't seem to be an issue in 3.4+, the following headers are injected in
a call to urlopen():
GET / HTTP/1.1
Accept-Encoding: identity
Host: example.com
User-Agent: Python-urllib/3.4
Connection: close
However, this is not the same behaviour in 2.7:
Demian Brecht added the comment:
Thanks for the report and follow up Vova. I've come across this line and it
puzzled me as well as to why it's hardcoded. Rather than the hardcoded approach
in your patch, I've attached a patch that uses _http_vsn_str which is
consistent with oth
Changes by Demian Brecht :
--
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue3566>
___
___
Python-bugs-list mai
Changes by Demian Brecht :
Added file: http://bugs.python.org/file38797/issue12319_5.patch
___
Python tracker
<http://bugs.python.org/issue12319>
___
___
Python-bug
Demian Brecht added the comment:
Agreed. However, I'm wondering if that should belong in a new issue geared
towards further clarifying behaviour of request body types. The patch
introduces the behaviour this specific issue was looking, with the largest
change being that iterators ma
Changes by Demian Brecht :
Added file: http://bugs.python.org/file38773/issue22931_2.patch
___
Python tracker
<http://bugs.python.org/issue22931>
___
___
Python-bug
Changes by Demian Brecht :
--
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue22931>
___
___
Python-bugs-list mai
Demian Brecht added the comment:
Set as closed, assuming there's no reason to keep this issue open.
--
status: open -> closed
___
Python tracker
<http://bugs.python.or
Demian Brecht added the comment:
If #12319 is accepted, the implementation for Content-Length should also likely
be migrated to this issue to be applied to maintenance branches as a bug fix.
--
status: pending -> open
___
Python tracker
&l
Demian Brecht added the comment:
The computation of Content-Length has also undergone some refactoring as part
of #12319. Setting this as pending until #12319 has been accepted or rejected.
If rejected, the implementation specific to generating Content-Length should be
migrated here
Changes by Demian Brecht :
Added file: http://bugs.python.org/file38772/issue12319_4.patch
___
Python tracker
<http://bugs.python.org/issue12319>
___
___
Python-bug
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23360>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
Thanks for following up on this David. The changes you've made all look good to
me.
--
___
Python tracker
<http://bugs.python.org/i
Demian Brecht added the comment:
> The current behaviour when no scheme is present is fairly sensible to me and
> should not be changed to do string concatenation nor raise an exception
Agreed. Defaulting to relative behaviour makes sense as I imagine that'll be
the general use
Demian Brecht added the comment:
As I understand it, the change should also be applied to security releases
as the regression manifested by a security related patch being applied.
That said, there may be some debate as there apparently isn't much (if
anything) in the way of precedence
Demian Brecht added the comment:
Updated patch should address review comments. I did run with David's suggestion
as I also noticed that my initial assessment was wrong (thanks for the
note/review Berker).
--
Added file:
http://bugs.python.org/file
Demian Brecht added the comment:
Sounds good to me.
--
___
Python tracker
<http://bugs.python.org/issue23778>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
I noted in #2211 that nested lists are supported by Sphinx, so that solves that
specific issue. Perhaps it /may/ still be useful to have this though in order
to support multiple paragraphs for more detailed change descriptions when
needed? That said, I'
Demian Brecht added the comment:
Problem (pretty much) solved. Nested unordered lists are supported. I've
updated the versionchanged information to use the list.
--
Added file:
http://bugs.python.org/file38690/http_cookies_morsel_deprecated_set_2.
Demian Brecht added the comment:
FWIW, I created #23778 to address the indentation issue.
--
___
Python tracker
<http://bugs.python.org/issue2211>
___
___
Pytho
New submission from Demian Brecht:
This came up during #2211, where a multiline versionchanged entry was
suggested. Currently, there is no visual distinction between any but the first
line of the description and the rest of the body of the docs. The attached
patch adds a consistent level of
Demian Brecht added the comment:
> it would be better to consolidate the three adjacent versionchanged entries
> into one
I created the three versionchanged items because there's no visual distinction
between the second and third lines and the rest of the doc tests in the
rend
Demian Brecht added the comment:
I'm also +1 to handling this generically and agree that a well thought out and
researched proposal would be required.
I did mention in #18228 (http://bugs.python.org/issue18828#msg238363) that I
think that a short term solution to this problem could
Demian Brecht added the comment:
Thanks for the review Martin.
> However I understand Rolf specifically wanted chunked encoding to work with
> the existing urlopen() framework, at least after constructing a separate
> opener object. I think that should be practical with the
Changes by Demian Brecht :
Added file: http://bugs.python.org/file38670/issue12319_3.patch
___
Python tracker
<http://bugs.python.org/issue12319>
___
___
Python-bug
Demian Brecht added the comment:
FWIW, I've done some additional work to request/send in issue #12319 where I've
added support for chunked request encoding.
@David
> if an iterable is passed in, it must be an iterable of bytes-like objects
This specific issue is addressed in
Demian Brecht added the comment:
@Serhiy:
> Content-Length shouldn't be calculated for lists, tuples, and other
> non-bytes-compatible sequences.
I'd agree with this if it wasn't relatively trivial to calculate. There's no
reason that I can think of to exclude
Changes by Demian Brecht :
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.python.org/issue23662>
___
___
Python-bugs-list mailing list
Unsubscribe:
Demian Brecht added the comment:
> idmap was removed in 14b65de9b798, translate was removed in 99027c2b3fd2 when
> their became unnecessary.
I'd venture to say they slipped through the cracks. Following the deprecation
procedure here would be favourable IMHO as to give users a
Demian Brecht added the comment:
One super minor comment left in Rietveld (py3 patch). Otherwise LGTM.
--
___
Python tracker
<http://bugs.python.org/issue23
Demian Brecht added the comment:
The attached patch reverts back to the old set() API, ignoring the parameter
and adding a deprecation warning. I've also added a few versionchanged and
deprecated tags in the Morsel docs. Other than the deprecation note in
whatsnew/3.5.rst that was added
Demian Brecht added the comment:
Yep, that's a lot cleaner and tests pass. I've updated the patch with that
line. Thanks.
--
Added file: http://bugs.python.org/file38573/issue23703_1.patch
___
Python tracker
<http://bugs.python.o
Demian Brecht added the comment:
Also, I would suggest still including the doc changes proposed by Madison in
all versions prior to 3.5.
--
___
Python tracker
<http://bugs.python.org/issue18
Demian Brecht added the comment:
>>>> urljoin('mailto:foo@', 'bar.com')
> 'mailto:bar.com'
>
> which seems fairly sensible to me.
This is where joining arbitrary protocols gets tricky. Does it make sense to
merge non-hierarchical protocols su
Demian Brecht added the comment:
Nice work tracking down the commit, thanks for that. I've attached a fix.
--
keywords: +patch
stage: -> patch review
Added file: http://bugs.python.org/file38563/issue23703.patch
___
Python tracke
Demian Brecht added the comment:
Thanks for the follow up Serhiy, LGTM.
--
___
Python tracker
<http://bugs.python.org/issue2211>
___
___
Python-bugs-list mailin
Changes by Demian Brecht :
--
stage: -> patch review
versions: +Python 3.5
___
Python tracker
<http://bugs.python.org/issue18828>
___
___
Python-bugs-list mai
Demian Brecht added the comment:
> I haven’t heard any arguments against this option yet, and it didn’t break
> any tests.
Pre patch:
>>> urljoin('mailto:foo@', 'bar.com')
'bar.com'
Post patch:
>>> urljoin('mailto:foo@', '
Changes by Demian Brecht :
--
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue2211>
___
___
Python-bugs-list mai
Demian Brecht added the comment:
Thanks for the updates Serhiy. All look good to me.
--
___
Python tracker
<http://bugs.python.org/issue2211>
___
___
Python-bug
Demian Brecht added the comment:
Updated patch changes the following:
+ Removes support for trailers in requests as they're not supported
+ If Transfer-Encoding is explicitly set by the client, it's assumed that the
caller will handle all encoding (backwards compatibility)
+ Fixed a
Changes by Demian Brecht :
Added file: http://bugs.python.org/file38525/issue22931_1.patch
___
Python tracker
<http://bugs.python.org/issue22931>
___
___
Python-bug
Changes by Demian Brecht :
Removed file: http://bugs.python.org/file38522/issue22931_1.patch
___
Python tracker
<http://bugs.python.org/issue22931>
___
___
Python-bug
Demian Brecht added the comment:
Thanks for the report Mark, updating this patch to be more backwards compatible
was on my to-do list. I've attached a new patch that simply adds the new
characters to the legal value set.
It does look like that's the commit that introduced this issu
Demian Brecht added the comment:
+1 to the change, but I'd propose maybe "value of *scheme*" given the tables
are inline with both urlsplit and urlparse docs?
--
nosy: +demian.brecht
___
Python tracker
<http://bugs.pyt
Demian Brecht added the comment:
> I cannot imagine some existing code (other than an exploit) that would be
> broken by restoring the empty “//” component; do you have an example?
You're likely right about the usage (I can't think of a plausible use case at
any rate).
Demian Brecht added the comment:
> I avoided making them positional parameters, as they are not part of the
> underlying tuple object.
Ignore me, I was off my face and you're absolutely correct.
--
___
Python tracker
<http://b
Demian Brecht added the comment:
>>>> urlsplit("evil.com").netloc
> ''
>>>> urlsplit("evil.com").has_netloc
> True
>>>> urlunsplit(urlsplit("evil.com")) # Adds “//” back
> 'evil.com'
Demian Brecht added the comment:
I've done an initial pass in Rietveld and left some comments, mostly around
docs. Here are some additional questions though:
Given has_* flags can be inferred during instantiation of *Result classes, is
there a reason to have them writable, meaning is th
1 - 100 of 434 matches
Mail list logo
