[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames
CJ Kucera added the comment: Will do, thanks for the input! -- ___ Python tracker <https://bugs.python.org/issue36771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames
CJ Kucera added the comment: Yeah, I'd wondered that too (re: a separate function) but it seemed like an awful lot of duplicated code. The PR I'd put through just changes the datatypes within the `filenames` and `dirnames` lists... I'd been thinking that'd be sufficient since you wouldn't get that without specifying the optional boolean, but perhaps not. -- ___ Python tracker <https://bugs.python.org/issue36771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames
CJ Kucera added the comment: I've started up a Github PR for this, btw, though IMO it's not really in a mergeable state yet: 1) I wasn't sure what to do about os.fwalk(), since that *doesn't* already generate DirEntry objects, and this change would introduce a small inconsistency between the two, functionalitywise. 2) Also wasn't sure what to do about unit tests, though I'll ponder that some more once I've got some time later. 3) The actual implementation is pretty trivial, but could perhaps be handled differently. The systems's still processing my CLA signature, as well, so there's that too. :) -- ___ Python tracker <https://bugs.python.org/issue36771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames
New submission from CJ Kucera : It'd be nice to have an option to os.walk which would return DirEntry objects in its return tuple, as opposed to just the string filenames/dirnames. (Or failing that, an alternate function which does so.) The function already uses os.scandir() internally, so the DirEntry objects already exist -- I assume it'd be a pretty easy change. At the moment, if I want to be efficient and use os.scandir() myself, I've got to basically reimplement os.walk(), which seems silly since os.walk is already calling scandir itself. -- components: Library (Lib) messages: 341210 nosy: apocalyptech priority: normal severity: normal status: open title: Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue36771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14044] IncompleteRead error with urllib2 or urllib.request -- fine with urllib, wget, or curl
CJ Kucera added the comment: Ah, well, actually I suppose I'll rescind that a bit - other pages about this bug around the internet had been claiming that the 'requests' module uses urllib in the backend and was subject to this bug as well, but after experimenting myself, it seems like if that IS the case, they're working around it somehow, because using requests makes this succeed 100% of the time. I probably should've tried that first! So anyway, there's a reasonable workaround, at least. Sorry for the bugspam! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14044> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14044] IncompleteRead error with urllib2 or urllib.request -- fine with urllib, wget, or curl
CJ Kucera added the comment:
I've just encountered this problem on Python 3.6, on a different URL. The
difference being that it's not encountered with EVERY page load, though I'd say
it happens with at least half:
import urllib.request
html = urllib.request.urlopen('http://www.basicinstructions.net/').read()
print('Succeeded!')
I realize that the root problem here may be an HTTP server doing something
improper, but I've got no way of fixing someone else's webserver. It'd be
really nice if there was a reasonable way of handling this in Python itself.
As mentioned in the original report, other methods of retreiving this URL work
without fail (curl/wget/etc). As it is, the only way for me to be sure of
retreiving the entire page contents is by looping until I don't get an
IncompleteRead, which is hardly ideal.
--
nosy: +apocalyptech
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue14044>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
