Jeff McNeil added the comment:
Do we have a decision on this yet? I'm willing to rework bits that may need
it, but I'd like to know whether this is going to be a fruitful effort or not.
Thanks!
--
___
Python tracker
<http://bu
Jeff McNeil added the comment:
Fixing the underlying connect call should also address EINTR failing with a
"operation already in progress" when a connect+timeout fails due to a signal.
I can understand not addressing EINTR generically (though it is already
partially addresse
Jeff McNeil added the comment:
I'm not a big fan of the settimeout approach myself (and only did it because it
was mentioned as a possible approach). I think the existing implementations of
EINTR retry also suffer from the same issue in which the timeout isn't adjusted
per iter
Jeff McNeil added the comment:
Actually, never mind that suggestion. Now that I think a bit more about it,
that actually doesn't do anything since I'd still need to set the updated
timeout on the current socket object anyway. Whoops.
I'll leave it up to you as to whethe
Jeff McNeil added the comment:
Added a flag to allow for at least one run -- I know nothing of non-Linux clock
resolution. That should handle that.
As for the thread safety of the socket timeouts, yeah, that was why I didn't do
that initially, I assumed the suggestion to take that app
Jeff McNeil added the comment:
Updated to recalculate timeout at Python level. The current module already
works this way on recv() calls. See attached.
I'd be happy to churn through and fix the other modules (using the 3.5 work as
a guide), though I think only addressing the higher
Jeff McNeil added the comment:
So, yeah, that's right. In the attached patch, I'm closing the file descriptor
if the timeout/error happens on a non-blocking call. It fails with an EBADF on
reconnect at that point, but it doesn't potentially leave an FD in the proc's
file
Jeff McNeil added the comment:
Missed check on _ex func.
--
Added file: http://bugs.python.org/file38865/socket_eintr.2.patch
___
Python tracker
<http://bugs.python.org/issue23
Jeff McNeil added the comment:
Whoops. Accidentally attached the wrong patch that I generated during testing.
--
Added file: http://bugs.python.org/file38832/socket_eintr.1.patch
___
Python tracker
<http://bugs.python.org/issue23
Jeff McNeil added the comment:
mcjeff@mcjeff:~/cpython_clean$ hg summary
parent: 95416:fe34dfea16b0
Escaped backslashes in docstrings.
branch: 2.7
commit: 3 modified, 3 unknown
update: (current)
--
keywords: +patch
nosy: +gregory.p.smith
Added file: http://bugs.python.org/file38826
New submission from Jeff McNeil:
There are a collection of places in the socket module that do not correctly
retry on EINTR. Updated to wrap those calls in a retry loop. However, when
fixing connect calls, I noticed that when EINTR is retried on a socket with a
timeout specified, the retry
Jeff McNeil added the comment:
Ah, disregard. I followed up on the other bug. The legacy interface indeed
should have stayed consistant.
--
___
Python tracker
<http://bugs.python.org/issue10
Jeff McNeil added the comment:
Reverting of the len(block) back to 'bs' here aside, does it even make sense to
include block information at all?
That's the attempted read size, so it might not be an accurate representation
of the size of the data actually read. Thus the
Jeff McNeil added the comment:
Updated to pass in the parent context only actually, as it doesn't look like
all of the attributes on SSLSocket will be set if a context was initially
passed in.
--
Added file: http://bugs.python.org/file27784/ssl_context_2.
Jeff McNeil added the comment:
Ak! Yes, cut and paste error.
Python 3.4.0a0 (default:57a33af85407, Oct 27 2012, 21:26:30)
[GCC 4.4.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
New submission from Jeff McNeil:
mcjeff@martian:~/cpython$ ./python -V
Python 3.4.0a0
When an SSLSocket is created via SSLContext.wrap_socket, it is passed a
_context parameter directly. SSLSocket.__init__ sets self.context at this
point, but it does not set self.keyfile or self.certfile
Jeff McNeil added the comment:
Attached... worked in the way I've done it in the past and updated documents.
--
keywords: +patch
Added file: http://bugs.python.org/file27773/ssl_xmlrpc_server.patch
___
Python tracker
<http://bugs.py
Jeff McNeil added the comment:
I've hacked this support in myself a few times with a simple socket wrap call
in SimpleXMLRPCServer's __init__. I'd be happy to put a quick patch together
if that's a viable approach.
Is there any desire to support client authentication
Jeff McNeil added the comment:
Gave this a go myself...
$ ./python
Python 3.4.0a0 (default:57a33af85407, Oct 27 2012, 21:26:30)
[GCC 4.4.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>&g
Jeff McNeil added the comment:
Yeah clearly the wrong behavior on Winders.
I think that moving to 'normpath' instead of 'normcase' is likely the right
thing to do. Patch is attached, so if someone with commit powers could review
real quick I'll address whatever nee
Jeff McNeil added the comment:
Yeah, that's a good point too. I still personally favor the transport
encapsulation and related unit testing, but I think that's a call for someone
with a snake icon next to their tracker name.
Your English is
Jeff McNeil added the comment:
I went through the patch real quick and I noticed that your using single
element tuples in your string formatting. That makes sense in situations where
the argument might itself be a tuple, however, not on calls to len() as that
will return an integer
Jeff McNeil added the comment:
I would think it might make more sense just to make the change to the Transport
object. Since there's an argument for a transport on ServerProxy already, that
seems more straightforward and keeps the network layer isolated.
Otherwise, it seems sli
Jeff McNeil added the comment:
I looked at doing this. The empty() and full() methods are marked with a
disclaimer stating they're likely to be removed at some point?
I'm curious, does just checking the value of .unfinished_tasks satisfy
the requirement? It could still easily b
Jeff McNeil added the comment:
Quick little patch to change the default to None and update the corresponding
documentation.
--
keywords: +patch
nosy: +mcjeff
Added file: http://bugs.python.org/file25044/urllib_urlopen_default.patch
___
Python
Jeff McNeil added the comment:
Disregard. That was in concert with ntpath, which uses a funky approach to
testing.
--
___
Python tracker
<http://bugs.python.org/issue10
Jeff McNeil added the comment:
I was looking at a somewhat unrelated issue and I bumped up against a similar
situation with the warnings system.
I didn't look too much into it, but it appeared that warnings didn't get added
to __warningregistry__ correctly. Though, when I set
Jeff McNeil added the comment:
It doesn't seem to me that the right approach on either platform is to simply
downcase. Maybe just deprecate the call altogether as its not doing anything
normpath isn't if the .lower call is removed?
--
Jeff McNeil added the comment:
Here's a tiny patch that just changes normcase->normpath. This fixes the
casing issue at the 'gettempdir' level, though it doesn't address the
'normcase' function itself.
Note that *both* macpath.py and ntpath.py use .lower, w
Jeff McNeil added the comment:
I don't see why we'd need to make these _private -- they're just
accessors/mutators for the most part. I'd be happy to help clean this up if
you need it.
--
___
Python tracker
<http://bug
Jeff McNeil added the comment:
The normcase call isn't exactly a no-op in ntpath.py as it also swaps / for \\.
Removing the .lower() seems to simply make it a watered down version of
normpath.
There are a couple of options I guess. We could simply keep the altsep, or
u
Jeff McNeil added the comment:
The actual implementation calls os.path.normcase from
tempfile._get_default_tempdir. In this scenario here, that resolves to the
ntpath module & triggers a lowercase conversion.
On the other hand, the posixpath module is simply an identity function.
Now
Jeff McNeil added the comment:
I'd be happy to do that (URLopener, to begin with), though I'm not familiar
with the usual approach. Is it simply a matter of warning in __init__?
--
nosy: +mcjeff
___
Python tracker
<http://bu
Jeff McNeil added the comment:
Yeah, updated with different wording and proper caps. I left the piece in
regarding the use without the context manager as I think that's probably the
more common use case still.
--
Added file: http://bugs.python.org/file24832/urllib_request_doc.
Jeff McNeil added the comment:
Ah, understood. I kind of like the idea of having the added functionality
behind a custom callable, but if it's generally just a bug then copystat is a
good solution, too.
--
___
Python tracker
Jeff McNeil added the comment:
In an effort to walk through bugs in my nosy list, I dug into this and tried to
reproduce it to no avail.
Also, as the handle_error method is supposed to handle problems gracefully,
calling shutdown on handle_error exception is probably questionable. I'
Changes by Jeff McNeil :
--
nosy: -mcjeff
___
Python tracker
<http://bugs.python.org/issue10050>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeff McNeil added the comment:
Documentation patch to outline the use of context manager protocol attached.
Trying to cleanup any bugs with my name on them.
--
keywords: +patch
Added file: http://bugs.python.org/file24817/urllib_request_doc.patch
Jeff McNeil added the comment:
I made the change suggested in the last comment, patch is attached. Trying to
clean up any bugs I've got my name on!
--
keywords: +patch
Added file: http://bugs.python.org/file24816/makedirs_function.patch
___
P
Jeff McNeil added the comment:
Did this ever get committed? Is there anything left for me to do here?
--
___
Python tracker
<http://bugs.python.org/issue12
Changes by Jeff McNeil :
Added file: http://bugs.python.org/file23743/head-cgitb-display.patch
___
Python tracker
<http://bugs.python.org/issue12890>
___
___
Python-bug
Jeff McNeil added the comment:
Added everything to one file. Updated tests to also include a logdir argument
as that is required to trigger the original bug. Weeded out a spurious write
that occurred when format was set to text.
--
Added file: http://bugs.python.org/file23737/head
Jeff McNeil added the comment:
Test to ensure html isn't included when the formatting is text. I don't seem
to be able to update the stage.
--
Added file: http://bugs.python.org/file23731/head-cgitb-display-tests.patch
___
Python trac
Jeff McNeil added the comment:
I didn't add one initially as I was just changing output format and not actual
behavior. I guess I could add something to ensure it doesn't regress? I'll
make sure there's coverage to begin with.
--
__
Jeff McNeil added the comment:
Is there anything else needed here?
--
___
Python tracker
<http://bugs.python.org/issue12890>
___
___
Python-bugs-list mailin
New submission from Jeff McNeil :
If cgitb.enable is ran with a logdir set and a format='text' argument, then a
trailing message is printed that includes tags. This should only happen if
the format requested is HTML.
The following tiny script shows the problem:
import cgitb
cg
Jeff McNeil added the comment:
Isn't that snippet (contextlib.closing(...)) passing the result of
urllib.urlopen to closing? The urlopen call is a factory function of sorts, so
there's really no context to manage on its part? Maybe it's just a matter of
making that clear?
I
Jeff McNeil added the comment:
In looking at this again, I may have spoken too soon. It seems that addinfobase
& HTTPResponse already handle this. As this is what's returned by the opener,
then what I was shooting for should already be handled.
--
status: open
Changes by Jeff McNeil :
--
type: -> feature request
___
Python tracker
<http://bugs.python.org/issue12365>
___
___
Python-bugs-list mailing list
Unsubscri
New submission from Jeff McNeil :
Per discussion within Issue10050, URLopener ought to support the context
manager protocol. That allows more idiomatic usage and doesn't require calls to
contextlib.closing for use with the 'with' statement.
If agreed, I
Jeff McNeil added the comment:
I'd be happy to pick some of that stuff up. I'd like to address separately as
it keeps fewer concerns in this one patch. I'll grab them once they're created.
--
___
Python tracker
<http://bug
Jeff McNeil added the comment:
Just wanted to check so this doesn't sit with people waiting on me. Is there
anything else I need/should do to this patch? Little unclear on how to handle
the deprecation process.
--
___
Python tracker
Jeff McNeil added the comment:
I'm not exactly sure what the steps are with respect to the DeprecationWarning.
Is the common case just to raise the warning in the __init__ method? Are there
related documentation changes?
Thanks again! Learning a ton. Hopefully the next patch I submit wi
Jeff McNeil added the comment:
Take four! Includes Antoine's suggestions. I changed the callback to return
(block num, read size, file size) as opposed to (block num, block size, file
size) as this seems to make more sense.
I appreciate the back and forth. I'd be happy to cre
Jeff McNeil added the comment:
I'll make those changes, sure. I had the same thought re: block size, but I
was trying to keep inline with what the current function did.
--
___
Python tracker
<http://bugs.python.org/is
Jeff McNeil added the comment:
Made requested change to Synopsis/Description.
--
Added file: http://bugs.python.org/file21287/issue10050.patch
___
Python tracker
<http://bugs.python.org/issue10
Jeff McNeil added the comment:
Made recommended changes. Moved to NamedTemporaryFile. I don't think the
spooled file makes sense here as the existing protocol provides a filename in
the returned tuple, not a f.l.o.
As far as the description? Here are a couple suggestions:
1. URL Retr
Jeff McNeil added the comment:
Alright, attaching a patch that reworks urlretrieve to use urlopen internal to
urllib.request.
1. I dropped the local caching as it isn't turned on by default anyway (and
isn't really documented).
2. Updated documentation to reflect caching chan
Changes by Jeff McNeil :
--
nosy: +mcjeff
___
Python tracker
<http://bugs.python.org/issue10050>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeff McNeil added the comment:
Sounds good. I'll look at doing that, too.
--
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue11563>
___
___
Jeff McNeil added the comment:
So, it turned out to be more complicated than that. The HTTPConnection object
returns an HTTPResponse, but never closes the underlying socket after calling
makesock.
Since persistent connections aren't supported, nothing actually closes the
socket i
Jeff McNeil added the comment:
So, I've been meaning to get more into contributing back to Python and I found
this one somewhat interesting.
As it turns out, even the following simple script raises the same warning:
[jeff@martian cpython]$ ./python -c 'import urll
Changes by Jeff McNeil :
--
nosy: +mcjeff
___
Python tracker
<http://bugs.python.org/issue11563>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeff McNeil added the comment:
I entirely forgot I had signed up to look, my apologies.
I'm going through this w/ what's lying on Mercurial's tip, I can't reproduce it
at all. I can raise exceptions of various flavors from within the handle method
of a StreamRequestHand
Jeff McNeil added the comment:
I'll see if I can get it to reproduce and put a patch together.
--
___
Python tracker
<http://bugs.python.org/issue1429>
___
___
Jeff McNeil added the comment:
I was toying with adding Unix Socket support for one of our internal tools and
I thought I ran into a leak in my own code. Searched the bug tracker and found
this.
I tried to reproduce, but wasn't able to. Though, if you look at the
ThreadingMixIn
Jeff McNeil added the comment:
Attaching a patch against the trunk, unified format, changed to 'number' as per
suggestion.
--
versions: +Python 2.7 -Python 2.6
Added file: http://bugs.python.org/file17155/stdtypes.rst.trunk.patch
___
Pyth
Changes by Jeff McNeil :
--
nosy: +mcjeff -j_mcneil
___
Python tracker
<http://bugs.python.org/issue1666318>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeff McNeil :
I was going through the string formatting examples this evening and noticed
this:
print '%(language)s has %(#)03d quote types.' % \
{'language': "Python", "#": 2}
The example uses a '#' as a map key
Jeff McNeil added the comment:
I ran into this problem this afternoon as well. The same issue appears
to exist within the Basic & Digest Auth retry code (though it's much
less likely to surface).
I wound up making the suggested fixes to my local install so I'm
attaching the tiny
70 matches
Mail list logo