Karl Richter added the comment:
My initial description was imprecise. Clearification: The fact that in
#!/usr/bin/python
import threading
def debugging():
def __a_thread__():
print("2")
a_thread = threading.Thread(target=__a_thread__)
Karl Richter added the comment:
That's nice, thanks. Considering your last comment, some points
* If the issue can't go into the error message, than the essence of the
discussion here should go into the docs (in 0.5 to 1.5 sentences).
* It'd be nice if it was clear from th
Karl Richter added the comment:
Then, let the error message say "You are opening a just-created empty file.
The db type of the file cannot, therefore, be determined." which is much
clearer than "anydbm.error: db type could not be determined" which sounds like
a generic fa
Karl Richter added the comment:
EDIT 1: other examples, e.g.
import os
import shelve
curdir = os.path.dirname(__file__)
passwords = shelve.open(os.path.join(curdir, 'password_db'))
work, so there's need for usable
New submission from Karl Richter:
`shelve.open(tempfile.mkstemp()[1])` fails with error "anydbm.error: db type
could not be determined" which is not explainable with the docs. Traceback is
Traceback (most recent call last):
File "./cudaminer_param_checker.py
New submission from Karl Richter:
Due to the fact that `pdb` currently simply ignores breakpoints which are set
and hit in another than the main thread the docs need to contain a statement on
behavior in a multithreaded environment.
--
components: Library (Lib)
messages: 233409
nosy
karl added the comment:
OK I fixed the code. The issue is here
https://hg.python.org/cpython/file/1e1c6e306eb4/Lib/urllib/request.py#l656
newurl = urlunparse(urlparts)
Basically it reinjects the fragment in the new url. The fix is easy.
if urlparts.fragment
karl added the comment:
In class urlopen_HttpTests
https://hg.python.org/cpython/file/4f314dedb84f/Lib/test/test_urllib.py#l191
there is a test for invalid redirects
def test_invalid_redirect(self):
https://hg.python.org/cpython/file/4f314dedb84f/Lib/test/test_urllib.py#l247
And one for
karl added the comment:
Takahashi-san,
Ah sorry misunderstood which part your were talking about. I assume wrongly you
were talking about navigation.
Yes for the request which is sent to the server it should be
http://tools.ietf.org/html/rfc7230#section-5.3.1
So refactoring your example
karl added the comment:
This is the correct behavior
GET http://example.com/foo
with a response containing
302 and Location: /bar#test
must trigger
http://example.com/bar#test
Location is defined in
http://tools.ietf.org/html/rfc7231#section-7.1.2
7.1.2. Location
The "Loc
karl added the comment:
Where this is defined in the new RFC.
http://tools.ietf.org/html/rfc7230#section-3.1.2
status-line = HTTP-version SP status-code SP reason-phrase CRLF
Things to enforce
status-code= 3DIGIT
Response status code are now defined in
http://tools.ietf.org
karl added the comment:
Let's close this.
>>> "HTTP/1.1301 ".split(None, 2)
['HTTP/1.1', '301']
>>> "HTTP/1.1301 ".split(' ', 2)
['HTTP/1.1', '', ' 301 ']
I think it would be
Changes by karl :
Removed file: http://bugs.python.org/file36698/issue-5550-4.patch
___
Python tracker
<http://bugs.python.org/issue5550>
___
___
Python-bugs-list mailin
karl added the comment:
OK after fixing my repo (Thanks orsenthil) I got the tests running properly.
The inspection order of the two dictionary was not right, so I had to modify a
bit the patch.
→ ./python.exe -m unittest -v
karl added the comment:
Ah! the User-Agent (or anything which is in unredirected_hdrs) will not be
updated if it has already been set once.
https://hg.python.org/cpython/file/064f6baeb6bd/Lib/urllib/request.py#l1154
>>> headers = dict(request.unredirected_hdrs)
>>> he
karl added the comment:
ok let's see
→ ./python.exe -m unittest -v
Lib.test.test_urllib2net.OtherNetworkTests.test_custom_headers
test_custom_headers (Lib.test.test_urllib2net.OtherNetworkTests) ... FAIL
==
karl added the comment:
Opened issue #22478 for the tests failing. Not related to my modification.
--
___
Python tracker
<http://bugs.python.org/issue5
New submission from karl:
→ ./python.exe -V
Python 3.4.2rc1+
→ hg tip
changeset: 92532:6dcc96fa3970
tag: tip
parent: 92530:ad45c2707006
parent: 92531:8eb4eec8626c
user:Benjamin Peterson
date:Mon Sep 22 22:44:21 2014 -0400
summary: merge 3.4 (#22459
karl added the comment:
Ok my tests are ok.
→ ./python.exe -m unittest -v Lib/test/test_urllib2net.py
test_close (Lib.test.test_urllib2net.CloseSocketTest) ... ok
test_custom_headers (Lib.test.test_urllib2net.OtherNetworkTests) ... FAIL
test_file (Lib.test.test_urllib2net.OtherNetworkTests
karl added the comment:
Just a follow up for giving the stable version of the now new RFC version for
HTTP 1.1
HTTP header field names parsing
http://tools.ietf.org/html/rfc7230#section-3.2.4
--
___
Python tracker
<http://bugs.python.
karl added the comment:
And I had to do a typo in patch3. Submitting patch4. Sorry about that.
--
Added file: http://bugs.python.org/file36698/issue-5550-4.patch
___
Python tracker
<http://bugs.python.org/issue5
Changes by karl :
Removed file: http://bugs.python.org/file36695/issue-5550-3.patch
___
Python tracker
<http://bugs.python.org/issue5550>
___
___
Python-bugs-list mailin
karl added the comment:
Ok this is an attempt at solving the issue with lowercase. I find my get_header
a bit complicated, but if you have a better idea. :) I'll modify the patches.
I have try to run the tests on the mac here but I have an issue currently.
→ ./python.exe -V
Python 3.
New submission from Karl Richter:
Although the section
https://docs.python.org/2/library/multiprocessing.html#process-and-exceptions
(of the multiprocessing module documentation) is titled "... and exceptions" it
doesn't say anything about exceptions. I assume that it behaves
New submission from Karl Richter:
reproduction (on Ubuntu 14.04 amd64 with lxc 1.0.4) (with python 2.7.6 and
3.4.0)
# as root/with privileges
lxc-create -n ubuntu-trusty-amd64 -t ubuntu -- --arch amd64 --release trusty
lxc-stop -n ubuntu-trusty-amd64 # assert container isn
karl added the comment:
After inspections, the best library for parsing RFC3339 style date is
definitely:
https://github.com/tonyg/python-rfc3339/
Main code at
https://github.com/tonyg/python-rfc3339/blob/master/rfc3339.py
--
___
Python tracker
karl added the comment:
Noticed some people doing the same thing
https://github.com/tonyg/python-rfc3339
http://home.blarg.net/~steveha/pyfeed.html
https://wiki.python.org/moin/WorkingWithTime
--
___
Python tracker
<http://bugs.python.
karl added the comment:
On closer inspection, Anders Hovmöller proposal doesn't work.
https://github.com/boxed/iso8601
At least for the microseconds part.
In http://tools.ietf.org/html/rfc3339#section-5.6, the microsecond part is
defined as:
time-secfrac= "." 1*DIGIT
I
karl added the comment:
I had the issue today. I needed to parse a date with the following format.
2014-04-04T23:59:00+09:00
and could not with strptime.
I see a discussion in March 2014
http://code.activestate.com/lists/python-ideas/26883/ but no followup.
For references:
http
karl added the comment:
@Mark,
yup, I can do that.
I just realized that since my contribution there was a PSF Contributor
Agreement. This is signed.
I need to dive a bit again in the code to remember where things fail.
--
___
Python tracker
<h
karl added the comment:
Mark,
I'm happy to followup.
I will be in favor of removing any capitalization and not to change headers
whatever they are. Because it doesn't matter per spec. Browsers do not care
about the capitalization. And I haven't identified Web Compatibility is
karl added the comment:
→ python
Python 2.7.5 (default, Mar 9 2014, 22:15:05)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import robot
karl added the comment:
Note that one of the proposal is to just document in
https://docs.python.org/3/library/urllib.robotparser.html
the proposal made in msg169722 (available in 3.4+)
robotparser.URLopener.version = 'MyVersion'
--
karl added the comment:
Mark,
The code is using urllib for demonstrating the issue with wikipedia and other
sites which are blocking python-urllib user agents because it is used by many
spam harvesters.
The proposal is about giving a possibility in robotparser lib to add a feature
for
New submission from Karl Richter:
It would be useful to have a short statement in the docs
(https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions)
that the expression in a list comprehension isn't put into a block, but
evaluated against the same block where it is lo
Karl Richter added the comment:
@paul.j3 That's interesting [1]. Documenting argparse.register seems crucial to
me (-> reopen or file a new request?).
After dealing more with the very sophisticated and complex functionality of
argparse I'm sure that this is the only use case
New submission from karl:
There is a room for a consistent and good EXIF library for the Python Standard
Library.
--
components: Library (Lib)
messages: 216978
nosy: karlcow
priority: normal
severity: normal
status: open
title: Missing Generic EXIF library for images in the standard
Karl Richter added the comment:
That's a pity, I still think it's confusing. Thanks for your feedback!
--
___
Python tracker
<http://bugs.python.o
Karl Richter added the comment:
I've been mistaken about the behavior if no argument is specified (then the
argument value is None), so this is a bug!
--
___
Python tracker
<http://bugs.python.org/is
New submission from Karl Richter:
As arguments with type bool are the only ones whose values can be manipulated
without passing an option to the argument on CLI, the default behavior for
those should be changed from ignoring options to failing when options are
specified. Consider the
New submission from Karl Richter:
The explanation of namespaces in section 9.2 in documentation
(http://docs.python.org/3/tutorial/classes.html#python-scopes-and-namespaces)
is just so complicated without (at least one tiny) example. The example would
ease the comprehension of the section by
karl added the comment:
Eric,
what do you recommend to move forward with this bug and patches?
Need guidance.
Do you have an example for "(A minor thing: I would use “attribute” instead of
“variable” in the docstrings.)"
Also which code base I should use? A lot of water has gone
karl added the comment:
ooops right, my bad.
s/on port 8080. We first/on port 8080, we first/
better?
--
___
Python tracker
<http://bugs.python.org/issue11
New submission from Karl Palsson:
OpenSSL supports TLS-PSK which some people (myself obviously) find to be
substantially easier to use than setting up certs.
However, there's no way to use PSK via the current SSL api in python. It would
be very nice to be able to use PSK from python.
karl added the comment:
Yes case insensitive make sense. It seems it will require a lot of
modifications in the code. So I guess maybe the first step is to identify where
it could break.
--
___
Python tracker
<http://bugs.python.org/issue5
karl added the comment:
terry.reedy:
You said: "and that has_header and get_header *require* the .capitalize() form
and reject the .title() form."
I made a patch for these two.
See http://bugs.python.org/issue5550
--
___
Python trac
karl added the comment:
First, Sanity check for myself to be sure to understand.
==
→ python3.3
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 01:25:11)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright
karl added the comment:
orsenthil,
Added test for python 3.3 for testing the case insensitivity for has_header and
get_header. The tests fail as it should.
See issue-5550-test-1.patch
I will make a patch to urllib/request.py to make it work.
OK with you?
--
keywords: +patch
Added
karl added the comment:
The wireshark trace is a different domain than the code example. But let's see.
cocobear added:
headers = [("Content-Type","application/oct-stream"),]
with a "Content-Type", not the capitalized "Type".
BUT in the s
karl added the comment:
just a minor issue you made a mistake in the commit message. The issue number
is 12921
--
___
Python tracker
<http://bugs.python.org/issue12
karl added the comment:
Thanks! Yes we should open a separate issue. I will look at the current patch
and see what I can propose for the next step.
--
___
Python tracker
<http://bugs.python.org/issue12
karl added the comment:
Ezio: I'm talking about "HTML5 Parsing algorithm", not about about parsing
html* documents. :)
The only python parser I know who is closer of the HTML5 parser algorithm is
https://code.google.com/p/html5lib/
--
___
karl added the comment:
flying sheep: do you plan to make it easier to use the HTML5 algorithm?
http://www.w3.org/TR/html5/syntax.html#parsing
--
nosy: +karlcow
___
Python tracker
<http://bugs.python.org/issue17
karl added the comment:
The current status of RFC6265 is PROPOSED STANDARD
http://www.rfc-editor.org/info/rfc6265
Adam Barth is part of the Google Chrome Team. I do not want to talk for Adam.
So better ask him, I don't think he has the energy/will to push further through
the IETF pr
karl added the comment:
Yes the new RFC has been written by Adam Barth who wanted to describe things
matching the reality of HTTP and servers/browsers issues.
--
___
Python tracker
<http://bugs.python.org/issue17
karl added the comment:
Just a quick note that the new specification for HTTP State Mechanism (aka
cookies) is http://tools.ietf.org/html/rfc6265
keakon, Do you know why her cookie was ',BRIDGE_R=;'
--
nosy: +karlcow
___
Python trac
karl added the comment:
Ok after comments and review by Eric Araujo on the previous patch.
See issue-747320-3.patch
I have ran
→ ./python.exe Lib/test/test_httpservers.py
[…]
--
Ran 39 tests in 3.734s
OK
[137158 refs]
That
Changes by karl :
--
nosy: +vinay.sajip
___
Python tracker
<http://bugs.python.org/issue17376>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
karl added the comment:
Is it better like this? See the patch.
--
keywords: +patch
nosy: +karlcow
Added file: http://bugs.python.org/file29341/issue-17376-doc-3.3.patch
___
Python tracker
<http://bugs.python.org/issue17
karl added the comment:
Ah bummer! :) it was already done. :) Well it seems already well commented in
the review. :)
Closing this one as duplicate?
--
___
Python tracker
<http://bugs.python.org/issue17
karl added the comment:
Here an attempt at fixing it. See issue-17375-1.patch for Python 3.3
Hope it helps.
--
keywords: +patch
nosy: +karlcow
Added file: http://bugs.python.org/file29338/issue-17375-1.patch
___
Python tracker
<h
karl added the comment:
http://docs.python.org/3/library/xml.etree.elementtree.html#supported-xpath-syntax
20.5.2. XPath support
This module provides limited support for XPath expressions for locating
elements in a tree. The goal is to support a small subset of the abbreviated
syntax; a full
karl added the comment:
r.david.murray,
how did you enter the first without a syntax error?
>>> import email.message
>>> m = message_from_string("Content-Disposition: attachment;
>>> filename*0*="can't decode this filename")
File ""
karl added the comment:
orsenthil,
would that test work?
See issue-17324-test-1.patch
Here the result of the test which is FAIL as planned (given the current issue).
→ ./python.exe Lib/test/test_httpservers.py
test_header_buffering_of_send_error (__main__.BaseHTTPRequestHandlerTestCase
karl added the comment:
Setting a user agent string should be possible.
My guess is that the default library has been used by an abusive client (by
mistake or intent) and wikimedia project has decided to blacklist the client
based on the user-agent string sniffing.
The match is on anything
karl added the comment:
→ curl -sI http://kniznica.uniza.sk/opac
HTTP/1.1 302 Moved Temporarily
Date: Wed, 06 Mar 2013 03:23:06 GMT
Server: Indy/9.0.50
Content-Type: text/html
Location: ?fs=C79F09C9F1304E7AA4FF7C211BEA2B9B&fn=main
→ python3.3
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29
karl added the comment:
The issue with the current patch is that it is escaping more than only the
spaces, with possibly indirect border effect.
Anne van Kesteren is in the process of creating a parsing/writing specification
for URL. Not finished but putting it here for future reference.
http
karl added the comment:
Hmm no code.
I wonder if it's about this part.
http://hg.python.org/cpython/file/3.3/Lib/http/client.py#l321
--
nosy: +karlcow
___
Python tracker
<http://bugs.python.org/i
karl added the comment:
What was the content of http://support.github.com/discussions/site/1510
I can't find it. Is the issue still going on?
--
nosy: +karlcow
___
Python tracker
<http://bugs.python.org/i
karl added the comment:
R.david
Trying another patch just for understanding if it's what you meant.
What it does:
1. adding an 'explain' keyword
2. escaping the explain message for the body
3. checking for injection of newline in the reason phrase.
For the part 3, TODO:
che
karl added the comment:
hehe. No hard feelings. I still do not think it is a good idea to test the
"error code" and its associated message in the same test. :)
For example, in RFC2616, 414 is defined as
414 Request-URI Too Long
and in the HTTP1.1bis (which will not get a n
karl added the comment:
Senthil,
I created another bug reports for the tests which are fragile.
http://bugs.python.org/issue17355
--
___
Python tracker
<http://bugs.python.org/issue12
Changes by karl :
--
components: +Library (Lib), Tests
___
Python tracker
<http://bugs.python.org/issue17355>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from karl:
Some of the tests of the HTTP Test suite are checking for the full status-line,
instead of just the error code.
Why is it an issue?
1. The only mandatory part in the status-line is the error code. The phrase is
optional. For example the response is made of 3 parts
karl added the comment:
The culprit is here
http://hg.python.org/cpython/file/3.3/Lib/http/server.py#l320
That an application or a person decides to send another message is ok. Designer
choice. That the library is sending something optional as a test seems more
uncomfortable.
The list of
karl added the comment:
orsenthil,
When you have done a patch for testing I would love to see it. I could not find
a proper way of doing it. I'm eager to learn. Thanks.
--
___
Python tracker
<http://bugs.python.org/is
karl added the comment:
orsenthil,
I made a proper patch for it with hg diff. It is very short.
See issue-12921-2.patch
--
Added file: http://bugs.python.org/file29306/issue-12921-2.patch
___
Python tracker
<http://bugs.python.org/issue12
karl added the comment:
R. David.:
> A crazy idea that occurred to me was to create an "rfc822-style-header
> management" module, and share it between email, http, and urllib.
Yes it is basically what I had in mind when I said:
>Maybe the way forward in the future is to ha
karl added the comment:
R. David Murray,
You are right it is not specific to the client library. HTTP headers are part
of the message (Request/Response) with both the same constraints. Constraints
are put on receivers (receiving a message) and senders (sending a message) of
the message
karl added the comment:
OK. I'm inclined to think that we should both remove trailing and leading
spaces/tabs should be removed.
Reasons:
1. Production rules forbid them.
2. Trailing spaces
2.a Conformant servers will ignore with a 400 bad request (opportunity for
another bugs?)
karl added the comment:
Hello,
So I tested a bit. The production rules defined by the specification are clear.
Spaces before and after are forbidden.
header-field = field-name ":" OWS field-value BWS
field-name = token
field-value= *( field-content
karl added the comment:
tests in
http://hg.python.org/cpython/file/886df716cd09/Lib/test/test_wsgiref.py#l370
also checking that everything is case insensitive.
And the method to get the headers in wsgiref, make sure they are lower-case
http://hg.python.org/cpython/file/886df716cd09/Lib
karl added the comment:
Are there issues related to removing the capitalize() and title() appears?
# title()
* http://hg.python.org/cpython/file/886df716cd09/Lib/urllib/request.py#l1239
# capitalize()
* http://hg.python.org/cpython/file/886df716cd09/Lib/urllib/request.py#l359
* http
karl added the comment:
ok made a proper patch on the rst file with hg diff.
See issue-11448-1.patch
--
Added file: http://bugs.python.org/file29293/issue-11448-1.patch
___
Python tracker
<http://bugs.python.org/issue11
karl added the comment:
Ah thanks Eric, I will fix that.
--
___
Python tracker
<http://bugs.python.org/issue11448>
___
___
Python-bugs-list mailing list
Unsub
karl added the comment:
I created 4 tests for testing trailing and leading spaces on
* add_unredirected_header()
* add_header()
and modified the functions.
Tests passed.
→ ./python.exe Lib/test/test_urllib2net.py
[…]
test_headers_with_spaces (__main__.OtherNetworkTests) ... ok
karl added the comment:
http://hg.python.org/cpython/file/3.3/Lib/urllib/request.py#l359
def add_header(self, key, val):
# useful for something like authentication
self.headers[key.capitalize()] = val
and http://hg.python.org/cpython/file/3.3/Lib/urllib/request.py#l271
in
karl added the comment:
R. David Murray:
Sure. Is it better? issue-747320-1.patch
It seems there are already tests for gmt date format in
Lib/test/test_email/test_utils.py
--
Added file: http://bugs.python.org/file29279/issue-747320-1.patch
karl added the comment:
So looking at the casing of headers, I discovered other issues. I opened
another bug. http://bugs.python.org/issue17322
--
___
Python tracker
<http://bugs.python.org/issue12
karl added the comment:
Yet another one leading spaces :(
>>> req = urllib.request.Request('http://www.example.com/')
>>> req.header_items()
[]
>>> req.add_header(' Foo3', 'Ooops')
>>> req.he
Changes by karl :
--
title: urllib.request add_header() currently allows trailing spaces ->
urllib.request add_header() currently allows trailing spaces (and other weird
stuff)
___
Python tracker
<http://bugs.python.org/issu
New submission from karl:
For HTTP header field names parsing, see
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-22#section-3.2.4
No whitespace is allowed between the header field-name and colon. In
the past, differences in the handling of such whitespace have led to
karl added the comment:
Note that HTTP header fields are case-insensitive.
See http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging#section-3.2
Each HTTP header field consists of a case-insensitive field name
followed by a colon (":"), optional whitespace, and the f
karl added the comment:
Sentil:
About the PUT/POST, I would say:
A POST and PUT methods differs only by the
intent of the enclosed representation. In the
case of a POST, the target resource (URI) on
the server decides what is the meaning of the
enclosed representation
New submission from karl:
def send_response_only(self, code, message=None):
http://hg.python.org/cpython/file/3.3/Lib/http/server.py#l448
There is no type checking on code or if the code is appropriate. Let's take
==
#!/usr/bin/env python3.3
i
karl added the comment:
Read the thread. Thanks Antoine. Better understanding. I'm still discovering
how the community is really working.
Trying to fix a few things in the mean time
http://bugs.python.org/issue12921
http://bugs.python.org/issue747320
http://bugs.python.org/issue11448
karl added the comment:
ok I modify the code of server.py so that the server doesn't send the private
message but the one which is already assigned by the library as it should. If
there is a need for customization, there should be two separate variables, but
which could lead to the
karl added the comment:
OK I had understand a bit better.
self.send_error(code, msg) is used for
* The body
* The HTTP header
* and the log
That's bad, very bad.
I do not think it should be used for the HTTP Header at all.
--
___
Python tr
karl added the comment:
Testing your code in Listing 1
→ curl -sI http://localhost:9000/
HTTP/1.0 501 Unsupported method ('HEAD')
Server: BaseHTTP/0.6 Python/3.3.0
Date: Tue, 26 Feb 2013 23:38:32 GMT
Content-Type: text/html;charset=utf-8
Connection: close
So this is nor
karl added the comment:
agreed on HTTP/1.1, is there a plan to fix it too ;) because the current
http.server seems to be untouchable without breaking stuff all around :)
--
___
Python tracker
<http://bugs.python.org/issue17
101 - 200 of 233 matches
Mail list logo