Daniel Kluev dan.kl...@gmail.com writes:
On Sun, May 22, 2011 at 2:49 AM, John J Lee j...@pobox.com wrote:
Here's my wishlist (not really in any order):
How come pony is not listed there? Language cannot be better than
python without pony!
Pony, absolutely. I took that as read
Andrew Berg bahamutzero8...@gmail.com writes:
This is probably somewhat off-topic, but where would I find a list of
what each error code in WindowsError means? WindowsError is so broad
that it could be difficult to decide what to do in an except clause.
Fortunately, sys.exc_info()[1][0] holds
Walter Chang weidezhang2...@gmail.com writes:
Hi
is there any open source library for python that can allow application
level monitoring ? For example,application can send per request level/
aggregated monitoring events and some remote server dump it and show
in the monitoring graph in real
Bastian Ballmann ba...@chaostal.de writes:
Hi,
the project sounds like the exact tool that i need but regarding the
user manual one has to mark the points on the graph manually. Therefore
it's more work to get the data out than doing it without a tool. Or may
I miss something here?
Greets
Gregory Ewing greg.ew...@canterbury.ac.nz writes:
Hans Georg Schaathun wrote:
0 is a number as real and existent as any other,
one would think that the empty list is also as real and existent as
any other list.
0 does have some special properties, though, such as
being the additive
/troll
I still like Python after using it for over a decade, but there are
things I don't like.
What are your favourite up-and-coming languages of the moment?
Here's my wishlist (not really in any order):
* A widely used standard for (optional) interface declaration -- or
something better.
John J Lee jj...@users.sourceforge.net added the comment:
I agree with And Clover that Carsten Klein's comments in #msg127366 are not
correct, for the reason that And stated.
Also, Carsten repeats again the idea that the trac issue is about the trac
server failing to generate appropriate
John J Lee jj...@users.sourceforge.net added the comment:
karl: I'm not clear precisely what it is that you want to draw our attention
to. Note this bug is about parsing of Cookie headers by servers, not
production of Set-Cookie headers by servers
John J Lee jj...@users.sourceforge.net added the comment:
Again, I don't think this is relevant, because the bug is about servers parsing
Cookie: headers. Note that that string (the value of the Cookie: header) may
be generated by a different server than the server that parses it (see
John J Lee jj...@users.sourceforge.net added the comment:
Yes, interoperability is good. Do you have a specific concern about the change
that I proposed?
If not, and you're instead just trying to ensure conformance, by all means read
the draft specification that you pointed out and look
John J Lee jj...@users.sourceforge.net added the comment:
Yes, interoperability is good. Do you have a specific concern about the change
that I proposed?
If not, and you're instead just trying to ensure conformance, by all means read
the draft specification that you pointed out and look
John J Lee jj...@users.sourceforge.net added the comment:
Oops, I hadn't noticed that max_redirections isn't part of the API. In that
case, I agree that it's not strictly a bug. I'd also agree it's not very
important.
FWIW: want[ing] to see all redirects is not the same thing as printing
John J Lee jj...@users.sourceforge.net added the comment:
That's silly. A justification of the need for a new feature isn't needed,
because this is already-implemented feature that simply does the wrong thing at
the edge case.
It's not high priority, but it is a bug
John J Lee jj...@users.sourceforge.net added the comment:
Why not?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1520831
___
___
Python-bugs
John J Lee jj...@users.sourceforge.net added the comment:
dstanek Would it be better to file bugs against buggy implementations instead
of changing Python's implementation to be more lenient?
No. Another app running on the same domain that knows nothing about RFC 2109
(and why should
John J Lee jj...@users.sourceforge.net added the comment:
What I said in 2007 re commas could be well out of date (might well have been
so even then, in fact). Somebody should check what browsers do now...
--
___
Python tracker rep
John J Lee jj...@users.sourceforge.net added the comment:
Looks like a bug. Here's the trac bug that this caused -- trac fixed their bug
by working around this bug in a really ugly way:
http://trac.edgewall.org/ticket/2256
It would be nice to notify the trac developers if/when this is fixed
John J Lee jj...@users.sourceforge.net added the comment:
Hmm, I never tested with Python 3, though I assume the forward-port was
straightforward. The patch was created against (2.x) trunk, so indeed it
should be committed there also.
Deselecting 2.6 since I assume no more maintenance
John J Lee jj...@users.sourceforge.net added the comment:
My patch should be applied.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3704
John J Lee jj...@users.sourceforge.net added the comment:
This is a duplicate of issue3924
--
nosy: +jjlee
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8975
John J Lee jj...@users.sourceforge.net added the comment:
There is code in PyPI project mechanize that implements this feature. That
code is marked experimental though, due to lack of testing.
--
nosy: +jjlee
___
Python tracker rep
John J Lee jj...@users.sourceforge.net added the comment:
Is deprecation really necessary? lynx still uses that format. lynx doesn't
write the header that MozillaCookieJar insists on being present, but a trivial
subclass can read cookies files written by lynx
John J Lee jj...@users.sourceforge.net added the comment:
Suggest removing the comment that Terry refers to. That referenced MSIE code
doesn't have an automated test, I've no idea whether it still works on modern
Windows OSes, mechanize no longer supports use with urllib2, and I don't think
John J Lee jj...@users.sourceforge.net added the comment:
What specific breakage do you expect resulting from my patch being backported?
There is no behaviour change here, except to the minimal extent that all bug
fixes involve behaviour change. This seems a clear-cut backport candidate
John J Lee jj...@users.sourceforge.net added the comment:
I'll upload a patch when I'm back home (bugs.python.org went down yesterday).
Will turn docstring into comment.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3704
John J Lee jj...@users.sourceforge.net added the comment:
Just re-read your comment, Tres. Since when do docstrings determine whether a
stdlib function is public? If it's documented in the docs, it's public. If
not, it's not. This function isn't, so it's not public. It's also
Changes by John J Lee jj...@users.sourceforge.net:
Added file: http://bugs.python.org/file17285/issue3704.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3704
John J Lee jj...@users.sourceforge.net added the comment:
Didn't bother changing docstring to comment, since that would be inconsistent
with rest of module.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3704
John J Lee jj...@users.sourceforge.net added the comment:
FWIW, the certain semantics that request_path promises are 1. that it
returns the RFC 2965 request-URI (which has never been true -- it returns the
path component of the request-URI instead) and 2. that that request-URI is as
defined
John J Lee jj...@users.sourceforge.net added the comment:
It looks to me that it's just request_path that's wrong, so no need to add
extra arguments to that function. It should discard the query and fragment
(still keeping the parameters -- using urlparse.urlsplit instead
John J Lee jj...@users.sourceforge.net added the comment:
Jon,
If you want to get these changes applied you need to:
1. Split up these three separate issues
2. Most important: explain in full detail exactly how you used cookielib, what
you expected it to do, and what it actually did
John J Lee jj...@users.sourceforge.net added the comment:
Shouldn't module time be changed to use a cross-platform implementation that
uses a 64 bit time_t-like type? Apparently Perl 6 has made the equivalent
change.
Admittedly there seems to be no sign of that actually happening
John J Lee jj...@users.sourceforge.net added the comment:
To make sure I understood something Antoine said: By per-request, I assume
you mean the same kind of thing as the current use of .redirect_dict -- the
multiple urllib2.Request instances that may result from a single request passed
John J Lee jj...@users.sourceforge.net added the comment:
Yes,it currently does not handle chained redirects via cache. I dont know
RFC's stance on it. RFC does not say anything about 301 chained redirects
I don't see anything in the RFC that prevents us caching chained 301
redirections
John J Lee jj...@users.sourceforge.net added the comment:
If you have a feature request, please open a separate ticket. This one
is about an alleged bug.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1424148
John J Lee jj...@users.sourceforge.net added the comment:
This issue is not a bug, and should be closed. It was discussed at
length many years ago (different bug tracker ticket), and resolved.
Since then the same issue seems to come up every year or so,
apparently raised by people who
John J Lee jj...@users.sourceforge.net added the comment:
A patch for this bug is attached to issue1375011.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1372650
Changes by John J Lee jj...@users.sourceforge.net:
--
nosy: -jjlee
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1172011
___
___
Python-bugs-list
Changes by John J Lee jj...@users.sourceforge.net:
--
nosy: -jjlee
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue991266
___
___
Python-bugs-list
John J Lee jj...@users.sourceforge.net added the comment:
Mike's list is missing one more character, % itself. So, the
replacement should be:
quote(newurl, safe=%/:=?~#+!$,;'@()*[])
The replacement should be done in the .open() method, not in the code
that handles redirects
John J Lee jj...@users.sourceforge.net added the comment:
A suitable test would be to derive a urllib.URLOpener subclass that has
an open_spam(url) method which records the URL. Then call
.open(spam://) in the test and verify that the URL has been quoted
John J Lee jj...@users.sourceforge.net added the comment:
Uh, that should have beeen something like
.open(spam://example.com/%2E/) of course.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue918368
John J Lee jj...@users.sourceforge.net added the comment:
Why?
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1660009
___
___
Python-bugs-list mailing list
John J Lee jj...@users.sourceforge.net added the comment:
This bug refers to urllib. Issue 1153027 refers to urllib2. It's the
same problem in each case, though.
--
nosy: +jjlee
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
John J Lee jj...@users.sourceforge.net added the comment:
This bug refers to urllib2. Issue 918368 refers to urllib. It's the
same problem in each case, though.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1153027
John J Lee [EMAIL PROTECTED] added the comment:
This fix was applied in the wrong place.
URI path components, and HTTP URI path components in particular, *can*
be empty. See RFC 3986. So the comment in the code that was inserted
with the fix for this bug that says possibly malformed
John J Lee [EMAIL PROTECTED] added the comment:
I agree this is a bug.
Senthil -- re 1), the paragraph you refer to (quoted by the OP) is
relevant. The fact that it doesn't specifically mention redirection is
not relevant.
Re 2): I don't know how digest auth works, but the paragraph you quote
John J Lee [EMAIL PROTECTED] added the comment:
This is fixed in trunk r61034 by issue #900744 . Please use that issue
for any discussion re whether this should be fixed in 2.5.
--
nosy: +jjlee
___
Python tracker [EMAIL PROTECTED]
http
John J Lee [EMAIL PROTECTED] added the comment:
urlopen() raises URLError, .read() may raise other errors. I don't
think that's a bug in itself, though no doubt:
1. The documentation of exceptions raised could and should be improved
2. The exceptions that can be raised are likely still
John J Lee [EMAIL PROTECTED] added the comment:
Can somebody close this? It's fixed on trunk in #900744 .
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1123695
New submission from John J Lee [EMAIL PROTECTED]:
The fix for #900744 tried to close the connection when a bad chunk
length was received. The comment inserted with that fix close the
connection as protocol synchronisation is probably lost is incorrect:
self.close() in _read_chunked does
John J Lee [EMAIL PROTECTED] added the comment:
The fix for this doesn't actually close the connection as the comment in
the fix claims -- I've raised #4492 to track that.
--
nosy: +jjlee
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org
John J Lee [EMAIL PROTECTED] added the comment:
For the record, I think my worry in msg49366 was a non-issue: the only
time .readline() will return is when the connection has closed (so I
think the fix that eventually applied is correct).
___
Python tracker
John J Lee [EMAIL PROTECTED] added the comment:
Please close: this is already fixed on trunk and release25-maint
(r60747, issue #1966) (and on release26-maint, which was branched after
the fix).
--
nosy: +jjlee
___
Python tracker [EMAIL PROTECTED
John J Lee [EMAIL PROTECTED] added the comment:
This bug was known before the release -- unfortunately the original
author of the patch didn't fix them in time. This and some other
unresolved issues listed are listed on #2451. Somebody should raise
bugs about the rest of them too, and fix them
Changes by John J Lee [EMAIL PROTECTED]:
--
nosy: +facundobatista
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4079
___
___
Python-bugs-list mailing
New submission from John J Lee [EMAIL PROTECTED]:
As required by RFC 2616 section 3.2.2, for all HTTP requests sent by
urllib2, the path component of the URI should be normalized to /
before the Request-URI derived from it gets passed to httplib (or
something functionally equivalent
John J Lee [EMAIL PROTECTED] added the comment:
I've raised #4493 about the issue I raised in my previous comment.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2464
New submission from John J Lee [EMAIL PROTECTED]:
r54137 replaced a comment in urllib2.py with a misleading comment. The
comment now implies the .insort() in question achieves the goal
specified in the new comment. That's not true, which was the reason the
original comment
Changes by John J Lee [EMAIL PROTECTED]:
--
components: +Library (Lib)
nosy: +facundobatista
versions: +Python 2.7, Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4496
John J Lee [EMAIL PROTECTED] added the comment:
I think this was actually not a bug, and the fix should not have been
applied. I guess this comment is just for the record, as the fix is
probably cruft that can't be removed now, since people will have started
relying on it.
The only way
John J Lee [EMAIL PROTECTED] added the comment:
I have attached a patch that just:
* Improves doctests a bit
* Changes .get_headers() and .has_header() to be case-insensitive
* Documents .get_header() and .header_items(), fixes some
incorrectly-documented argument names, and notes the case
Changes by John J Lee [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file11887/issue2775-problems.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2275
John J Lee [EMAIL PROTECTED] added the comment:
I agree there is a bug here: clearly the methods on the Request class
are inconsistent with AbstractHTTPHandler.do_open() . I think Facundo's
patch is good, though it needs a test.
The general principle when fixing earlier bugs has been
John J Lee [EMAIL PROTECTED] added the comment:
Patch with tests attached. The patch is slightly different to my first
suggestion: in the patch, invalid version values cause the cookie to be
ignored (but double quotes around valid versions are fine).
--
keywords: +patch
Added file
John J Lee [EMAIL PROTECTED] added the comment:
The bug is present on trunk and on the py3k branch, so I've selected
versions Python 2.7 and Python 3.0
This is a straightforward bug, so I selected 2.5.3 and 2.6 also, to
indicate this is a candidate for backport.
--
components: +Library
John J Lee [EMAIL PROTECTED] added the comment:
Forgot to add: if somebody else does the work, I'm happy to agree to the
code being used in Python stdlib. Perhaps it would be necessary to get
the author of the original Perl code from which this MSIE class is
derived to sign a contributor
John J Lee [EMAIL PROTECTED] added the comment:
Here they are:
http://bugs.python.org/issue1500504
http://bugs.python.org/issue1462525
http://bugs.python.org/issue1591035
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3647
John J Lee [EMAIL PROTECTED] added the comment:
Hmm, I see you've already commented on some of those, Senthil. Perhaps
you could add a comment to this bug explaining how your patch relates to
the others. Should it replace them? (why?) Should one of those patches
be applied also?
Also, my
John J Lee [EMAIL PROTECTED] added the comment:
Note that the code on wwwsearch.sf.net only reads cookies, and does not
write them. Also, the approach used is fragile to changes to MS's
index.dat database, which was the reason why that code was not
included when cookielib was added. As far
John J Lee [EMAIL PROTECTED] added the comment:
Sorry I turned up rather late here (is there a way to subscribe to
changes to all bugs whose comments or title contain a given string?)
If it works with Firefox and not with cookielib it's almost certainly a
bug. However, it's not clear to me
John J Lee [EMAIL PROTECTED] added the comment:
I think firefox 3 no longer writes cookies.txt (it writes cookies.sqlite
instead).
Can anybody point out a version of firefox that wrote this HttpOnly
information to cookies.txt, so the patch can be tested
New submission from John J Lee [EMAIL PROTECTED]:
Just adds a note to the cookielib documentation to point out that
Firefox 3 no longer writes cookies.txt, the file format understood by
cookielib.MozillaCookieJar (firefox now maintains persistent cookie
state in an sqlite database
John J Lee [EMAIL PROTECTED] added the comment:
Do we have an RFC 3986 URI parser in the stdlib now? It would be better
to use that if so, but I don't see one. Failing that, an implementation
of the relevant part of that RFC is only about four lines of code, so
that would be better than
John J Lee [EMAIL PROTECTED] added the comment:
The sensible fix for this is to strip the quotes off, defaulting to
version 0 on failure to parse the version cookie-attribute. It's not
necessary to retain the original version string.
By the way, what you posted warning rather than a strictly
John J Lee [EMAIL PROTECTED] added the comment:
I was responding to your comment of 2008-10-08 03:08, not to the opening
comment. I already responded to the opening comment.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1028088
John J Lee [EMAIL PROTECTED] added the comment:
The Cookie: header does not have a secure flag (The Set-Cookie: header
does).
I don't strongly object to the issue identified in the original comment
being fixed.
___
Python tracker [EMAIL PROTECTED]
http
Changes by John J Lee [EMAIL PROTECTED]:
--
nosy: +jjlee
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2190
___
___
Python-bugs-list mailing list
John J Lee [EMAIL PROTECTED] added the comment:
You haven't said what the specific problem is. Note that the
SimpleCookie class really represents a set of cookies, and the Morsel
class represents a single cookie. It seems that setting special
value-less cookie-attributes like secure works
New submission from John J Lee [EMAIL PROTECTED]:
./configure --prefix=DIR make make install tries to install files
in directories outside of DIR. This happens both with trunk (r66412)
and 2.6b3. This is a problem for users of GNU stow, for example. I
know that certainly this worked fairly
John J Lee [EMAIL PROTECTED] added the comment:
OK, this was because I had a .pydistutils.cfg file containing the
following (ironically, put there following somebody's recipe for
installing setuptools packages using stow):
[install]
install_lib=~/lib/python$py_version_short/site-packages
On Mon, 1 Sep 2008, bruce wrote:
[...]
how can i
[...]
libxml2dom
[...]
Just a general point: try lxml.etree instead? Friendlier API.
John
--
http://mail.python.org/mailman/listinfo/python-list
On Tue, 2 Sep 2008, bruce wrote:
[...]
using mechanize/Browser, i can easily do a url/get, and process submitting a
form that uses a GET as the action. however, I'm not quite sure how to
implement the submittal of a form, that uses the POST action.
[...]
Same way as any other form.
The HTTP
On Wed, 3 Sep 2008, bruce wrote:
[...]
and get the number of total nodes...
by subtracting, i can get the number of nodes, without text.. is there an
easier way??!!
[...]
Yes -- don't use XPath :-)
John
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, 29 Aug 2008, bruce wrote:
Hi john.
Thanks for your reply. I tried your suggestion of using RobustFactory, and
still get a badly maligned html back!!! The html is listed below. I would
That's expected -- this affects the parsing of the HTML. It does not
modify the HTML.
have
On Fri, 29 Aug 2008, bruce wrote:
[...]
does the page (test.html) need to be completely valid html?
No, but there are certainly (poorly-defined) limitations.
I haven't tried to understand your script or the HTML, but did you try
this:
br = mechanize.Browser(mechanize.RobustFactory())
...
New submission from John J Lee [EMAIL PROTECTED]:
The tutorial says:
The Python interpreter is usually installed as /usr/local/bin/python on
those machines where it is available
Shouldn't that be python3 or python-3.0? And the same throughout
the rest of the tutorial?
make install seems
John J Lee [EMAIL PROTECTED] added the comment:
make install actually installs as python3.0 (and not as
python-3.0, nor python3, nor python).
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3577
John J Lee [EMAIL PROTECTED] added the comment:
The CaseInsensitive dict class fails to preserve its invariants (implied
invariants, since there are no tests for it). There are also problems
with the documentation in the patch. I will submit a modified patch, I
hope later this week
John J Lee [EMAIL PROTECTED] added the comment:
By the way, this is a feature addition, not a bug fix. The first beta
releases for 2.6 and 3.0 came out some time ago, so according to PEP
361, this change should not be committed to trunk until after the 2.6 /
3.0 maintenance branches have been
John J Lee [EMAIL PROTECTED] added the comment:
With respect to point 1), I assume that we all agree upon that headers
should stored in Titled-Format instead of Capitalized-format.
I would probably choose to store the headers in Capitalized-form,
because that makes implementing .headers
John J Lee [EMAIL PROTECTED] added the comment:
Of course, that along the lines of suggestion isn't quite right: None
does not have a .title() method.
(and, to spell it out, I'm assuming in that suggestion that .headers is
the dict of headers with .capitalize()d keys, i.e. unchanged from Python
John J Lee [EMAIL PROTECTED] added the comment:
There already is a test for the breakage, but the patch changes the
expected output to match the new return value of .header_items():
-[('Foo-bar', 'baz'), ('Spam-eggs', 'blah')]
+[('Foo-Bar', 'baz'), ('Spam-Eggs', 'blah')]
Code
John J Lee [EMAIL PROTECTED] added the comment:
* The patch to the docs seems to muddy the waters even further (than the
current slightly murky state) about whether and why .headers is to be
preferred over the methods, or vice-versa. I think .headers should
remain undocumented
John J Lee [EMAIL PROTECTED] added the comment:
Just to quickly note that by providing case-insensitive lookup I don't
necessarily mean via .headers. But it's you who's providing the patch,
so I'll wait for your next suggestion rather than discuss how I might
change the code
John J Lee [EMAIL PROTECTED] added the comment:
* The patch looks like it will break code that uses .header_items(),
which is not acceptable.
* The patch to the docs seems to muddy the waters even further (than the
current slightly murky state) about whether and why .headers is to be
preferred
John J Lee [EMAIL PROTECTED] added the comment:
Facundo, are you going to review this?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2451
__
___
Python-bugs-list mailing list
Christian Heimes [EMAIL PROTECTED] writes:
Gabriel Genellina schrieb:
On the last line, str(x), I would expect 'abc' - same as str(x, 'ascii')
above. But I get the same as repr(x) - is this on purpose?
Yes, it's on purpose but it's a bug in your application to call str() on
a bytes object
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
So I need to recursively grep a bunch of gzipped files. This can't be
easily done with grep, rgrep or zgrep. (I'm sure given the right
pipeline including using the find command it could be donebut
seems like a hassle).
So I figured I'd find
j vickroy [EMAIL PROTECTED] writes:
Hello all,
I am using py.test (http://codespeak.net/py/dist/test.html) to perform
unit testing. I would like to include test coverage analysis using
coverage.py (http://nedbatchelder.com/code/modules/coverage.html), but
I do not know how to
1 - 100 of 576 matches
Mail list logo
