I'm working on this bug now, but can't get an SF login to update the bug report.
Jeremy
On 10/3/06, SourceForge.net [EMAIL PROTECTED] wrote:
Bugs item #1569998, was opened at 2006-10-03 14:04
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
Can you file a bug report for this? I'm guessing that the trace code
has some bad interaction with LOAD_LOCALS, such that a free variable
passed through the class gets treated as local instead. I can
reproduce this problem in Python 2.4, so it's a long-standing bug.
Also, as a matter of
Jeremy Hylton jhyl...@gmail.com added the comment:
Let me fix that.
--
nosy: +Jeremy.Hylton
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9997
Jeremy Hylton [EMAIL PROTECTED] added the comment:
It seems generally useful to have a helper function to replace a range
of nodes in a sequence of statements with another sequence of nodes. A
general API like that would allow you to insert or delete nodes as well
as replacing one node
On Mon, Nov 24, 2008 at 12:14 PM, David Turner [EMAIL PROTECTED] wrote:
David Turner [EMAIL PROTECTED] added the comment:
jhylton, keep in mind that this would require an additional parent
argument to each function which takes a stmt. Do you think this added
complexity is worth it?
Or we
Jeremy Hylton [EMAIL PROTECTED] added the comment:
This patch makes sense in principle, but some of the details need to
change. The _send_output() method is used by some clients, merely
because it can be used :-(. It's fairly easy to preserve this API for
backwards compatibility.
I am also
Jeremy Hylton [EMAIL PROTECTED] added the comment:
Just wanted to mention that the best solution is to update as much code
as possible to use HTTPConnection instead of HTTP. I'm not sure how
easy it is to do for xmlrpclib, since it exposes methods like
send_content(). I guess we can preserve
Jeremy Hylton [EMAIL PROTECTED] added the comment:
I haven't thought about the code in a while, but what code that
modifies the AST are we worried about? There are lots of
modifications in ast.c, since it is being created there. The case we
really care about is sequences, where we want
for efficiency.
Jeremy
On Mon, Nov 24, 2008 at 12:32 PM, Jeremy Hylton [EMAIL PROTECTED] wrote:
Jeremy Hylton [EMAIL PROTECTED] added the comment:
This patch makes sense in principle, but some of the details need to
change. The _send_output() method is used by some clients, merely
because it can
Jeremy Hylton [EMAIL PROTECTED] added the comment:
Python 2.4 is now in security-fix-only mode. No new features are being
added, and bugs are not fixed anymore unless they affect the stability
and security of the interpreter, or of Python applications.
http://www.python.org/download/releases
I think we're making progress, but I'm still not sure about the new
httplib api. My current worry is that endheaders() behaves very
differently when send_data is false. My chief concern is that the
__state variable is going to indicate that the request has been sent
when we're really depending
Jeremy Hylton [EMAIL PROTECTED] added the comment:
I did the simple part of the patch, where the request and headers are
sent at the same time. The applied patch didn't pass the test suite,
and I want to think about the buffering change a bit more. It's
definitely tricky.
Jeremy
On Fri, Nov
Jeremy Hylton [EMAIL PROTECTED] added the comment:
I don't think I understand this report. The TransportSubclassTestCase
class tests the behavior of overridable methods that don't exist in
Python 3.0. Is this really a Python 3.0 problem? I'm not sure why we
expect it to work there.
Jeremy
Jeremy Hylton [EMAIL PROTECTED] added the comment:
I submitted r67442, which combines the headers and body in a single
send() call. We should look at the buffering issue now, although I
probably won't have any time to check on it until Friday.
___
Python
Oops. I didn't think it translate the code in addinfobase to the new
style of iterators.
Jeremy
On Tue, Dec 9, 2008 at 7:50 AM, Senthil [EMAIL PROTECTED] wrote:
Senthil [EMAIL PROTECTED] added the comment:
I verified this bug in the Py3.0 and Py3.1. Shall come out with a patch
for it.
Does the same thing happen with 2.6?
Jeremy
On Thu, Dec 11, 2008 at 8:53 AM, Jean-Paul Calderone
rep...@bugs.python.org wrote:
Jean-Paul Calderone exar...@divmod.com added the comment:
The f65 is the chunk length for the first chunk returned when
requesting that URL. A proxy could easily
Changes by Jeremy Hylton jer...@alum.mit.edu:
--
assignee: - jhylton
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4631
___
___
Python-bugs-list
Jeremy Hylton jer...@alum.mit.edu added the comment:
I'm sorry that I didn't notice this bug report in September! The
chunked support does exist in the http package, but it doesn't work with
urllib. Tracking in 4631.
--
nosy: +jhylton
resolution: - duplicate
status: open - closed
Jeremy Hylton jer...@alum.mit.edu added the comment:
Brief update: The Python 2.x code works because readline() is provided
by socket._fileobject. The Python 3.x code fails because it grabs the
HTTPResponse.fp instance variable at the end of
AbstractHTTPHandler.do_open. That method needs
Jeremy Hylton jer...@alum.mit.edu added the comment:
I have a patch here that seems to work for the specific url and that
passes all the tests. Can anyone check whether it works for a larger
set of cases?
I'm a little concerned because I don't understand the new io library in
much detail
Jeremy Hylton jhyl...@gmail.com added the comment:
I'm trying to figure out the attached script. If I run Python 3.0, the script
doesn't run because of the undefined gc.DEBUG_OBJECTS. If I just remove that,
the script runs without error. Does that mean the problem is fixed? Or is
running
Jeremy Hylton jhyl...@gmail.com added the comment:
I spent some time to understand the example script today. The specific issue
is that a set of objects get put into the list of unreachable objects with
finalizers (both Immutable and Finalizer instances). When Cycle's __dict__ is
cleared
Jeremy Hylton jhyl...@gmail.com added the comment:
One last thought on this bug. The problem is that after we try to delete
garbage, we really can't know much about the state of the objects in the
finalizers list. If any of the objects that are cleared end up causing a
finalizer to run
Jeremy Hylton jhyl...@gmail.com added the comment:
Amaury-- I think that will work. I put together a small patch that seems to
pass all the tests, but it too messy. We need some care to make sure we don't
spin forever if there's some degenerate case where we never escape GC
I don't think the HTTPConnection class was designed to work with
sockets that don't follow the Python socket API. If you want to use a
different socket, you should create some wrapper that emulates the
Python socket ref count behavior.
Jeremy
On Mon, Feb 1, 2010 at 5:23 PM, Robert Buchholz
Jeremy Hylton jer...@alum.mit.edu added the comment:
On Fri, Feb 19, 2010 at 6:22 PM, R. David Murray rep...@bugs.python.org wrote:
R. David Murray rdmur...@bitdance.com added the comment:
But a goal is for the standard library to work with Python implementations
other than CPython
Jeremy Hylton jer...@alum.mit.edu added the comment:
On Sat, Feb 20, 2010 at 12:06 AM, R. David Murray
rep...@bugs.python.org wrote:
R. David Murray rdmur...@bitdance.com added the comment:
But the docs (which presumably describe the API) say that the socket is
unusable after the call
Jeremy Hylton jer...@alum.mit.edu added the comment:
In particular, I mean this part of the socket API:
socket.makefile([mode[, bufsize]])
Return a file object associated with the socket. (File objects are
described in File Objects.) The file object references a dup()ped
version of the socket
Jeremy Hylton jer...@alum.mit.edu added the comment:
On Sun, Feb 21, 2010 at 5:38 PM, Robert Buchholz rep...@bugs.python.org wrote:
Robert Buchholz r...@freitagsrunde.org added the comment:
almost... HTTPConnection is calling close() on the socket object, but
HTTPResponse still has an open
It's an interesting bug. Maybe the compiler shouldn't allow you to
use such a variable as a free variable in a nested function?
On Thu, Feb 11, 2010 at 9:09 PM, Craig McQueen rep...@bugs.python.org wrote:
Craig McQueen pyt...@craig.mcqueen.id.au added the comment:
There's also this one which
Jeremy Hylton jer...@alum.mit.edu added the comment:
On Mon, Feb 22, 2010 at 6:10 PM, Guido van Rossum
rep...@bugs.python.org wrote:
Guido van Rossum gu...@python.org added the comment:
All examples so far (*) have to do with our inability to have properly nested
blocks. If we did, I'd
Jeremy Hylton jer...@alum.mit.edu added the comment:
The patch looks pretty good.
I'd factor out the common error-checking code (common between
LOAD_DEREF and DELETE_DEREF) into a helper function.
It would also be good to add some test cases.
Jeremy
On Tue, Feb 23, 2010 at 9:38 AM, Guido van
Jeremy Hylton jer...@alum.mit.edu added the comment:
Is deferred blocker a higher priority?
Jeremy
On Tue, Feb 23, 2010 at 4:37 PM, Georg Brandl rep...@bugs.python.org wrote:
Georg Brandl ge...@python.org added the comment:
High is not high enough :)
--
priority: high - deferred
Jeremy Hylton jer...@alum.mit.edu added the comment:
On Sat, Dec 6, 2008 at 1:28 PM, Benjamin Peterson
rep...@bugs.python.org wrote:
Benjamin Peterson musiccomposit...@gmail.com added the comment:
I think I may have been merging add_ast_fields when I wrote the patch.
Here's a new patch
will change in a non-backwards compatible
way. I don't see how to do that given that we're also changing the
language spec. (Do you want to include the spec change in your
patch?)
Jeremy
On Tue, Feb 23, 2010 at 6:41 PM, Jeremy Hylton jer...@alum.mit.edu wrote:
On Sat, Dec 6, 2008 at 1:28 PM, Benjamin
Jeremy Hylton jer...@alum.mit.edu added the comment:
I guess there's some question about whether the syntax in the PEP was
considered carefully when it was approved. If so, I'm not sure that
we want to re-open the discussion. On the other hand, it's been a
long time since the PEP was approved
Jeremy Hylton jer...@alum.mit.edu added the comment:
Ok. I'll take a look, too.
Jeremy
On Sat, Feb 27, 2010 at 4:30 AM, Ezio Melotti rep...@bugs.python.org wrote:
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +orsenthil
status: pending - open
Jeremy Hylton [EMAIL PROTECTED] added the comment:
I'm working on the new urllib package.
--
nosy: +jhylton
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2775
Changes by Jeremy Hylton [EMAIL PROTECTED]:
--
nosy: +jhylton
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1346238
_
___
Python-bugs-list mailing list
Jeremy Hylton [EMAIL PROTECTED] added the comment:
I think we should move robotparser into the urllib package. Anyone
disagree?
Jeremy
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2775
Changes by Jeremy Hylton [EMAIL PROTECTED]:
--
nosy: +jhylton
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1348
__
___
Python-bugs-list mailing list
Unsubscribe
Jeremy Hylton [EMAIL PROTECTED] added the comment:
Oops. Let me look at this tomorrow. It was down to one failing test
that last time I checked.
Jeremy
On Wed, Jun 11, 2008 at 10:10 PM, Barry A. Warsaw
[EMAIL PROTECTED] wrote:
Barry A. Warsaw [EMAIL PROTECTED] added the comment
Changes by Jeremy Hylton [EMAIL PROTECTED]:
--
assignee: - jhylton
nosy: +jhylton
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3377
___
___
Python
Jeremy Hylton [EMAIL PROTECTED] added the comment:
Committed revision 65118.
I applied a simple version of this patch and added a unittest.
--
assignee: - jhylton
nosy: +jhylton
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http
Changes by Jeremy Hylton jhyl...@gmail.com:
--
nosy: +Jeremy.Hylton
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11549
___
___
Python-bugs-list
Jeremy Hylton jer...@alum.mit.edu added the comment:
I'm not sure I understand the part of the code that deals with binary
strings. I agree the current behavior is odd. RFC 2396 says that
non-ascii characters must be encoded as utf-8 and then percent escaped.
In the test case you started
Jeremy Hylton jer...@alum.mit.edu added the comment:
A plausible solution is to pick some core set of functionality that we
think people need and document that API. We can modify one or both of
the current implementations to include that functionality. What do we need
Changes by Jeremy Hylton jer...@alum.mit.edu:
--
assignee: - jhylton
nosy: +jhylton
resolution: - accepted
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5418
Jeremy Hylton jer...@alum.mit.edu added the comment:
Makes sense to me.
Committed revision 70625.
--
resolution: accepted - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5418
Jeremy Hylton jer...@alum.mit.edu added the comment:
I'm not sure what to do here. I guess changing to utf-8 is safe insofar
as the current code only accepts ascii, so the only code that breaks
will be code that depends on the encode() call raising an exception. It
seems like the client out
Jeremy Hylton jer...@alum.mit.edu added the comment:
Indeed, I think I confused some other character encoding issues related
to HTTP with the URI issue. The discussion in RFC 3986 is length and
only occasionally clarifying for this issue. That is, it doesn't say
anything definitive like
Jeremy Hylton jer...@alum.mit.edu added the comment:
The documentation is pretty vague on this point. If you send something
other than plain ascii, it gets a bit tricky to figure out what other
headers need to be added. It would be safer for the client to pick an
encoding (e.g. utf-8
Jeremy Hylton jer...@alum.mit.edu added the comment:
Ok. Discovered that RFC 2616 says that iso-8859-1 is the default
charset, so I will use that to encode strings instead of ascii. If you
want utf-8, you could encode the string yourself before calling
request(). Presumably, you should also
Jeremy Hylton jer...@alum.mit.edu added the comment:
Committed revision 70638.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5314
Changes by Jeremy Hylton jer...@alum.mit.edu:
--
assignee: - jhylton
nosy: +jhylton
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5542
Jeremy Hylton jer...@alum.mit.edu added the comment:
Wow! Old issue. This behavior was present in Greg's original version
of the code.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5542
Jeremy Hylton jer...@alum.mit.edu added the comment:
I think it makes sense to leave the socket open in this case. (In
general, I think httplib is too aggressive about closing the socket.)
I'm checking in a version for py3k, and will get around to backporting
it later.
Committed revision
Jeremy Hylton jer...@alum.mit.edu added the comment:
Seems like a reasonable feature request. I'm going to apply a variant
of the patch in 3.1 first.
--
assignee: - jhylton
nosy: +jhylton
resolution: - accepted
___
Python tracker rep
Changes by Jeremy Hylton jer...@alum.mit.edu:
--
nosy: +jhylton
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1153027
___
___
Python-bugs-list
Changes by Jeremy Hylton jer...@alum.mit.edu:
--
nosy: +jhylton
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue918368
___
___
Python-bugs-list
Jeremy Hylton jer...@alum.mit.edu added the comment:
The attached file is vaguely related to the current discussion. I'd
like to document the API for the urllib response, but I'd also like to
simplify the implementation on the py3k side. We can document the
simple API on the py3k side
Changes by Jeremy Hylton jer...@alum.mit.edu:
--
assignee: - jhylton
nosy: +jhylton
resolution: - accepted
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5578
Jeremy Hylton jer...@alum.mit.edu added the comment:
looks good to me
--
nosy: +jhylton
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4962
Jeremy Hylton jer...@alum.mit.edu added the comment:
looks good to me
--
nosy: +jhylton
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4675
Changes by Jeremy Hylton jer...@alum.mit.edu:
--
nosy: +jhylton
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1659410
___
___
Python-bugs-list
Jeremy Hylton jer...@alum.mit.edu added the comment:
Committed revision 70809 (trunk). Needs to be backported.
--
nosy: +jhylton
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4315
Jeremy Hylton jer...@alum.mit.edu added the comment:
The current docs cover this case:
http://docs.python.org/reference/executionmodel.html#interaction-with-dynamic-features
It basically says that code compiled via exec / eval can't access free
variables.
--
resolution: - wont fix
Changes by Jeremy Hylton jer...@alum.mit.edu:
--
assignee: - jhylton
nosy: +jhylton
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue991196
Jeremy Hylton jer...@alum.mit.edu added the comment:
This code behaves as intended. The module-level execution environment
is different than other environments. The global scope and local scope
are the same dictionary. Assignments at the top-level become globals
because of this behavior
Jeremy Hylton jer...@alum.mit.edu added the comment:
I think this bug ran out of steam. Python is behaving as intended, and
I think Georg addressed all of David's questions.
--
nosy: +jhylton
resolution: - works for me
status: open - closed
Jeremy Hylton jer...@alum.mit.edu added the comment:
exec is allowed in a class statement
--
resolution: accepted - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5578
Jeremy Hylton jer...@alum.mit.edu added the comment:
It doesn't seem helpful to leave this issue open, particularly since the
title suggest there's a problem with execfile being removed and that's
not going to change.
--
nosy: +jhylton
status: open - closed
Changes by Jeremy Hylton jer...@alum.mit.edu:
--
nosy: +jhylton
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4199
___
___
Python-bugs-list
Changes by Jeremy Hylton jer...@alum.mit.edu:
--
priority: high - normal
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1346238
___
___
Python-bugs
Changes by Jeremy Hylton jer...@alum.mit.edu:
--
nosy: +jhylton
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2344
___
___
Python-bugs-list
Jeremy Hylton jer...@alum.mit.edu added the comment:
Seemed like a good idea, but no one knew how to do it.
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2344
New submission from Jeremy Hylton jer...@alum.mit.edu:
import io
import urllib.request
f_bytes = urllib.request.urlopen(http://www.python.org/;)
f_string = io.TextIOWrapper(f_bytes, iso-8859-1)
print(f_string.read())
--
components: Library (Lib)
messages: 84840
nosy: jhylton
severity
Jeremy Hylton jer...@alum.mit.edu added the comment:
I just wanted to mention that the current head of py3k returns an
http.client.HTTPResponse and not a urllib.respone.addinfourl. That
doesn't mean it is the right thing to pass to TextIOWrapper. It's an
instance of RawIOBase
Jeremy Hylton jer...@alum.mit.edu added the comment:
Why did it change from 2.5 to 2.6? I'm not sure that the change makes
any sense. (Dreading the answer that I changed it...)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
79 matches
Mail list logo
