New submission from karl:
Adding the following to basic.css:
```css
dl {
margin-bottom: 15px;
word-wrap: break-word;
}
```
will solve the issue.
See https://github.com/webcompat/web-bugs/issues/1479
--
assignee: docs@python
components: Documentation
messages: 247803
nosy
karl added the comment:
>From https://www.djangoproject.com/foundation/cla/faq/
> Am I giving away the copyright to my contributions?
>
> No. This is a pure license agreement, not a copyright assignment. You
> still maintain the full copyright for your contributions. You are
&
karl added the comment:
About
> Actually, I realized that the best implementation of parsing rfc 3339
> is in django dateparse utils. To me it's the finest, the most
> elegant, and no other one can claim to be more robust since it's
> probably the #1 iso parsing functions us
karl added the comment:
Where should I propose a patch to help resolve this issue?
A pointer to the code in the repo and I will do it.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
karl added the comment:
@ezio.melotti
What is the next step for getting the patch accepted.
--
nosy: +karlcow
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
karl added the comment:
#8143 was fixed.
Python 2.7.10 (default, Feb 7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import urlli
karl added the comment:
I'm at Mozilla All Hands this week.
I'll check if my solution still makes sense next week and will make a pull
request and/or propose another solution.
Thanks for the reminder. adding to my calendar.
--
___
Python tracker
karl added the comment:
This issue should probably be addressed now on
https://github.com/python/python-docs-theme
--
nosy: +karlcow
___
Python tracker
<https://bugs.python.org/issue23
karl added the comment:
So I had time to look at it today.
And it would probably be better to solve
https://bugs.python.org/issue23312
which would make this one here useless and would actually provide a solution
for many people.
--
___
Python
karl added the comment:
I created https://github.com/python/python-docs-theme/issues/30
--
___
Python tracker
<https://bugs.python.org/issue23312>
___
___
Pytho
karl added the comment:
I created a PR following the recommendations of p-ganssle
https://github.com/python/cpython/pull/16507
--
nosy: +karlcow
___
Python tracker
<https://bugs.python.org/issue22
karl added the comment:
The current specification as of today documents
https://dom.spec.whatwg.org/#dom-document-createelementns
If you run this in the browser console,
var nsdoc = 'http://foo.bar/zoo';
var xmldoc = document.implementation.createDocument(nsdoc, 'Zoo', null);
var cpd
karl added the comment:
@gaurav The pull request
https://github.com/python/cpython/pull/10870
has been closed in favor of
https://github.com/python/cpython/pull/15773
which has already been merged.
So we can probably close here.
--
message_count: 7.0 -> 8.0
nosy: +karl
karl added the comment:
err… Errata on my previous comment.
"""
Simple implementation of the Level 1 DOM.
Namespaces and other minor Level 2 features are also supported.
"""
https://github.com/python/cpython/blob/c65119d5bfded03f80a9805889391b66fa7bf551/Lib/xm
karl added the comment:
@zach.ware
@r.david.murray
So I was looking at that issue. There is a lot of work.
I had a couple of questions, because there are different categories
# Empty tests for existing functions.
This seems to be straightforward as they would complete the module
karl added the comment:
Relevant spec
https://tools.ietf.org/html/rfc6265
--
nosy: +karlcow
___
Python tracker
<https://bugs.python.org/issue1375011>
___
___
karl added the comment:
Also this.
>>> import datetime
>>> d0 = datetime.datetime.strptime("2024-0-3 00:00:00", "%Y-%W-%w %H:%M:%S")
>>> d0.strftime("%Y-%W-%w %H:%M:%S")
'2024-01-3 00:00:00'
>>> d1 = datetime.datetime.strptim
karl added the comment:
Same on macOS 10.15.6 (19G73)
Python 3.8.3 (v3.8.3:6f8c8320e9, May 13 2020, 16:29:34)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
karl added the comment:
This should be closed. The PR has been merged and the doc is now up to date.
--
nosy: +karlcow
___
Python tracker
<https://bugs.python.org/issue36
karl added the comment:
@zach.ware
@r.david.murray
I'm going through the source currently.
I see that the test file is using:
class MinidomTest(unittest.TestCase):
def confirm(self, test, testname = "Test"):
self.assertTrue(test, testname)
Is there a specific rea
karl added the comment:
Ah no. They ARE used
through defproperty and minicompat.py
get = getattr(klass, ("_get_" + name))
--
___
Python tracker
<https://bugs.python.o
karl added the comment:
These methods are not used anywhere in the code.
https://github.com/python/cpython/blob/5c30145afb6053998e3518befff638d207047f00/Lib/xml/dom/minidom.py#L71-L80
What was the purpose when they were created… hmm maybe blame would give clue.
Ah they were added a long
Change by karl :
--
pull_requests: +22980
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/24152
___
Python tracker
<https://bugs.python.org/issu
New submission from karl :
In XPath 1.0
The function contains() is available
> Function: boolean contains(string, string)
> The contains function returns true if the first argument string contains the
> second argument string, and otherwise returns false.
In https://www.w3.org/TR
karl added the comment:
Converted into GitHub PR https://github.com/python/cpython/pull/24038
--
___
Python tracker
<https://bugs.python.org/issue4643>
___
___
karl added the comment:
@iritkatriel Github PR done.
https://github.com/python/cpython/pull/24034
--
___
Python tracker
<https://bugs.python.org/issue25
Change by karl :
--
nosy: +karlcow
nosy_count: 4.0 -> 5.0
pull_requests: +22878
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/24038
___
Python tracker
<https://bugs.python.org/
Change by karl :
--
keywords: +patch
nosy: +karlcow
nosy_count: 2.0 -> 3.0
pull_requests: +22875
pull_request: https://github.com/python/cpython/pull/24034
___
Python tracker
<https://bugs.python.org/issu
karl added the comment:
Status: The PR should be ready and completed
https://github.com/python/cpython/pull/24072
and eventually be merged at a point.
Thanks to ezio.melotti for the wonderful guidance.
--
___
Python tracker
<ht
Change by karl :
--
nosy: +karlcow
___
Python tracker
<https://bugs.python.org/issue28937>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
New submission from karl :
This comes up while working on issue 41748
browser input
data:text/html,text
browser output
text
Actual HTMLParser output
see https://github.com/python/cpython/pull/24072#discussion_r551158342
('starttag', 'div', [('class', 'bar'), ('class', 'foo')])]
Expected
karl added the comment:
> The getattr call here has a default value, so it should not raise
> AttributeError. It should also not raise any other exception because a valid
> implementation of __getattr__ should raise only AttributeError:
but probably the intent of the p
Change by karl :
--
keywords: +patch
pull_requests: +22904
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/24072
___
Python tracker
<https://bugs.python.org/issu
Change by karl :
--
title: HTMLParser: parsing error -> HTMLParser: comma in attribute values
with/without space
___
Python tracker
<https://bugs.python.org/issu
karl added the comment:
Ezio,
TL,DR: Testing in browsers and adding two tests for this issue.
Should I create a PR just for the tests?
https://github.com/python/cpython/blame/63298930fb531ba2bb4f23bc3b915dbf1e17e9e1/Lib/test/test_htmlparser.py#L479-L485
A: comma without spaces
karl added the comment:
Ah!
This is fixing it
diff --git a/Lib/html/parser.py b/Lib/html/parser.py
index 6083077981..790666 100644
--- a/Lib/html/parser.py
+++ b/Lib/html/parser.py
@@ -44,7 +44,7 @@
(?:\s*=+\s*# value indicator
karl added the comment:
The parsing rules for tokenization of html are at
https://html.spec.whatwg.org/multipage/parsing.html#tokenization
In the stack of open elements, there are specific rules for certain elements.
https://html.spec.whatwg.org/multipage/parsing.html#special
from a DOM
karl added the comment:
I wonder if the confusion comes from the name. The HTMLParser is kind of a
tokenizer more than a full HTML parser, but that's probably a detail. It
doesn't create a DOM Tree which you can access, but could help you to build a
DOM Tree (!= DOM Document object)
https
New submission from karl :
by copy a large file e.g.
-rwxrwxr-x 1 1002 1001 5359338160 Feb 9 2019 xxx_file_xxx.mdx
copy2 / sendfile / fastcopy fails with:
Traceback (most recent call last):
File "/usr/lib/python3.8/multiprocessing/pool.py", line 125, in worker
result = (
karl added the comment:
could not reproduce the error
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
karl added the comment:
Just to note that there is a maintained list of officially accepted schemes at
IANA.
https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
In addition there is a list of unofficial schemes on wikipedia
https://en.wikipedia.org/wiki/List_of_URI_schemes
karl karl+pythonb...@la-grange.net added the comment:
The rules for parsing and setting the cookies are different. Server should
always produce strict cookies only. So the production rules are to be done
accordingly to the specification.
Adam Barth is working right now on an update
karl karl+pythonb...@la-grange.net added the comment:
Ah the server is back the rules for the User Agents are defined here
http://tools.ietf.org/html/draft-ietf-httpstate-cookie#section-5
--
___
Python tracker rep...@bugs.python.org
http
karl karl+pythonb...@la-grange.net added the comment:
John: Ah sorry, if I misunderstood. The bug seems to say that it is about the
Cookie Name and legal chars for this cookie name. What I was trying to say is
that the processing of the Cookie Name is different depending if you are a
client
karl karl+pythonb...@la-grange.net added the comment:
agreed. :)
Then my question about parsing rules for libraries. Is interoperability a plus
here.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2193
karl karl+pythonb...@la-grange.net added the comment:
@aclover
see my comment http://bugs.python.org/issue2193#msg125423
Adam Barth is working for Google on Chrome.
The RFC being written is made in cooperation with other browser developers.
If you have comments about this RFC you are welcome
karl karl+pythonb...@la-grange.net added the comment:
The source of 3.1/lib/python3.1/xml/dom/__init__.py is correct
===
minidom -- A simple implementation of the Level 1 DOM with namespace
support added (based on the Level 2 specification) and other
minor Level 2
karl karl+pythonb...@la-grange.net added the comment:
This following markup creates the mistake as described earlier in the comments
element xmlns=
b class=foo alt=/
/element
This markup doesn't
element xmlns=bla
b class=foo alt=/
/element
It returns
?xml version=1.0 ?element xmlns=bla
b
New submission from karl karl+pythonb...@la-grange.net:
A very simple HTTP server
#!/usr/bin/python3
import http.server
from os import chdir
# CONFIG
ROOTPATH = '/Your/path/'
PORT = 8000
# CODE
def run(server_class=http.server.HTTPServer,
server_handler=http.server.SimpleHTTPRequestHandler
New submission from karl karl+pythonb...@la-grange.net:
The code has a set of old HTML templates. Here is a patch to change it to very
simple html5 templates.
--
components: Library (Lib)
files: server-html5.patch
keywords: patch
messages: 146641
nosy: karlcow, orsenthil
priority
karl karl+pythonb...@la-grange.net added the comment:
Ezio, Martin,
HTML 3.2, HTML 4.01 are not outdated. They have stable specifications. That
said their doctypes have not influence at all in browsers. The html5 doctype
!DOCTYPE html has been chosen because it was the minimal string
karl karl+pythonb...@la-grange.net added the comment:
Yup. I doesn't bring anything except putting the output in line with the
reality of browsers implementations. You may close it. I don't mind.
--
___
Python tracker rep...@bugs.python.org
http
karl karl+pythonb...@la-grange.net added the comment:
Eric,
Two possible solutions to explore:
Either the HEAD reports exactly the same thing than a GET without the body,
because it is the role of the GET, but that means indeed adding support for the
HEAD.
or creating a catch-all answer
karl added the comment:
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-7.1.1
quoting from HTTP 1.1 bis
Prior to 1995, there were three different formats commonly used by
servers to communicate timestamps. For compatibility with old
implementations, all three
karl added the comment:
I think it is now fixed by my patch in http://bugs.python.org/issue747320
--
nosy: +karlcow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7370
karl added the comment:
Made a mistake in the previous server.patch, use server.2.patch
--
Added file: http://bugs.python.org/file29241/server2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue747320
Changes by karl karl+pythonb...@la-grange.net:
Removed file: http://bugs.python.org/file29240/server.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue747320
karl added the comment:
This is a possible additional example for set_tunnel, modification of
python3.3/html/_sources/library/http.client.txt
Hope it helps.
--
nosy: +karlcow
Added file: http://bugs.python.org/file29243/http.client.patch
___
Python
New submission from karl:
Are there plans to develop an HTTP/2.0 library in parallel of the specification
development? It will not be ready before years, but it would be good to have an
evolving implementation. Or should it be done outside of python.org?
Reference: https://github.com/http2
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 rep...@bugs.python.org
http://bugs.python.org/issue17302
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 normal,
http
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 tracker
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 same
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
http
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
import
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
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 field value
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
Changes by karl karl+pythonb...@la-grange.net:
--
title: urllib.request add_header() currently allows trailing spaces -
urllib.request add_header() currently allows trailing spaces (and other weird
stuff)
___
Python tracker rep...@bugs.python.org
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.header_items()
[(' foo3', 'Ooops')]
req.headers
{' foo3': 'Ooops
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 rep...@bugs.python.org
http://bugs.python.org/issue12455
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:
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
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:
Ah thanks Eric, I will fix that.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11448
___
___
Python-bugs-list mailing
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 rep...@bugs.python.org
http://bugs.python.org/issue11448
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:
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:
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 / obs-fold )
field
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?)
2.b
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:
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 have a header factory
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 rep...@bugs.python.org
http
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 rep...@bugs.python.org
http://bugs.python.org/issue12921
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
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
Changes by karl karl+pythonb...@la-grange.net:
--
components: +Library (Lib), Tests
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17355
karl added the comment:
Senthil,
I created another bug reports for the tests which are fragile.
http://bugs.python.org/issue17355
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12921
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 new version
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:
check
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 rep...@bugs.python.org
http://bugs.python.org/issue8732
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 rep...@bugs.python.org
http://bugs.python.org/issue8450
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:
→ 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=C79F09C9F1304E7AA4FF7C211BEA2B9Bfn=main
→ python3.3
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012
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:
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:
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 stdin, line 1
m = message_from_string(Content-Disposition: attachment
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:
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 rep...@bugs.python.org
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 rep...@bugs.python.org
http://bugs.python.org/issue17375
1 - 100 of 232 matches
Mail list logo
