Change by Ben Hoyt :
--
keywords: +patch
pull_requests: +26853
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28452
___
Python tracker
<https://bugs.python.org/issu
Ben Hoyt added the comment:
For reference, here's a repro case:
$ python3.10 -c 'import email.utils; \
email.utils.parsedate_tz("Wed, 3 Apr 2002 12.34.56.78+0800")'
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/
New submission from Ben Hoyt :
In going through some standard library code, I found that the
email.utils.parsedate_tz() function
(https://docs.python.org/3/library/email.utils.html#email.utils.parsedate_tz)
has a bug if the time value is in dotted format and has more than 2 dots in it,
for
Ben Hoyt added the comment:
GitHub PR link with changes and commit notes attached.
--
___
Python tracker
<https://bugs.python.org/issue34712>
___
___
Python-bug
Change by Ben Hoyt :
--
keywords: +patch
pull_requests: +8784
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34712>
___
___
Python-
New submission from Ben Hoyt :
There are a couple of examples in the "Input and Output" section of the
tutorial that use an unusual / non-PEP 8 Python style or whitespace. I think
our examples, especially in the tutorial, should reflect good, PEP 8 style.
I'll fix these in
Ben Hoyt added the comment:
I don't think this is a good idea. I still use time.clock() out of habit (on
Windows), and from the PR it's clear that the standard library and tests do
too. I wouldn't be at all surprised to find others do as well.
I realize it's been depre
New submission from Ben Hoyt:
The documentation for namedtuple._replace() needs a tweak: currently its
signature shows "kwargs" without the ** notation, indicating it's a single,
positional argument. It should have the ** to indicate it's actually any number
of keyword ar
Ben Hoyt added the comment:
Agreed. Seems much the same as other argument constants,
like pickle.HIGHEST_PROTOCOL for the "protocol" argument. These are not
changing the API, just adding a helper constant to avoid the magic values.
-Ben
On Tue, Mar 14, 2017 at 12:24 PM, Brett Can
Ben Hoyt added the comment:
I definitely agree with Reuben here -- I just ran into this issue while
creating a "production quality" tool, and the help message produced by argparse
with nargs='*' confused me too. It's pretty clear that this is a simple bug in
argp
Changes by Ben Hoyt :
--
nosy: +benhoyt
___
Python tracker
<http://bugs.python.org/issue28609>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ben Hoyt added the comment:
I agree with the confusion (PR proposes separators=COMPACT, issue compact=True).
I like the concept but not either of the APIs proposed. I *much* more often
want to get pretty output -- if I had a dime for every time I've written
"json.dumps(obj, sort
Ben Hoyt added the comment:
Good call. Additionally, it's weird to me that the docstring for str.find()
says "Return -1 on failure." because the string not being found is not a
"failure". Like the docs
(https://docs.python.org/3.5/library/stdtypes.html#str.find) say,
Ben Hoyt added the comment:
Removing that whole example sounds good to me, thanks.
--
___
Python tracker
<http://bugs.python.org/issue27719>
___
___
Python-bug
Ben Hoyt added the comment:
Okay, patch attached -- I think it's best to simply remove that sentence.
Side note: this is why GitHub is so good -- click edit, remove the sentence,
click create pull request (approx time 30 seconds). I've got a new machine
since I last did Python devel
Ben Hoyt added the comment:
Note that I added the committers from issue 1692335 to the Nosy List --
probably overzealous and probably not the folks who maintain the docs, but oh
well. :-)
--
___
Python tracker
<http://bugs.python.org/issue27
New submission from Ben Hoyt:
In the official tutorial in the "User-defined Exceptions" section
(https://docs.python.org/3.5/tutorial/errors.html#user-defined-exceptions)
there's a note about a user-defined Exception subclass as follows:
"In this example, the default __i
Ben Hoyt added the comment:
Seeing this has been merged (thanks Victor), can this issue be closed? Guido,
are you happy with the changes given your comments at
http://bugs.python.org/issue26032#msg257665?
--
___
Python tracker
<h
Ben Hoyt added the comment:
Thanks, Victor!
--
___
Python tracker
<http://bugs.python.org/issue26248>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ben Hoyt added the comment:
Guido, I've made some tweaks and improvements to the DirEntry docs here:
http://bugs.python.org/issue26248 -- the idea is to fix the issues you
mentioned to clarify when system calls are required with symlinks, mentioning
that the results are cached separatel
New submission from Ben Hoyt:
Per Guido's comment about DirEntry documentation on Issue 26032, especially
http://bugs.python.org/issue26032#msg257665, it'd be good to improve the docs
of the scandir DirEntry methods with regard to symlinks and caching.
Attaching my stab at a documen
Changes by Ben Hoyt :
--
nosy: +benhoyt
___
Python tracker
<http://bugs.python.org/issue26111>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ben Hoyt added the comment:
Nice! Good to see scandir() getting used to speed up other functions, functions
that folks are using a ton already, like glob().
--
___
Python tracker
<http://bugs.python.org/issue25
Ben Hoyt added the comment:
Guido, it's true that in almost all cases you get the speedup (no system call),
and it's very much worth using. But the idea with the docs being non-committal
is because being specific would make the docs fairly complex. I believe it's as
follows for
Ben Hoyt added the comment:
I'm not sure this is actually a leak, because (looking at the code)
ScandirIterator_close() is called not just in the destructor, but also at the
end of iterating, just before raising StopIteration. Is the issue that if an
exception is raised or you stop iter
Ben Hoyt added the comment:
Just to clarify what Victor and Zachary mentioned: bytes filenames have been
deprecated only *on Windows* since Python 3.3; bytes filenames are still fine
on POSIX.
--
___
Python tracker
<http://bugs.python.
New submission from Ben Hoyt:
Victor Stinner's documentation for os.scandir and DirEntry is a great start
(https://docs.python.org/dev/library/os.html#os.scandir), however there are a
few mistakes in it, and a few ways I think it could be improved. Attaching a
patch with the following ov
Ben Hoyt added the comment:
Yep, I'm good -- go ahead and close!
--
___
Python tracker
<http://bugs.python.org/issue23605>
___
___
Python-bugs-list m
Ben Hoyt added the comment:
Thanks for the explanation (and the comment fix).
> What's your point about complexity? Would you like to drop os.scandir
> changes in os.walk(), or do you have a simpler version to propose?
No, not at all! I was just noting it and trying to brainstorm
Ben Hoyt added the comment:
Victor, great work on pushing this out, especially with the "modifying the
directories" fix. (And thanks Serhiy for pushing on correctness here.)
Couple of comments/questions about your new os.walk() implementation.
1) The new implementation is more c
Ben Hoyt added the comment:
> I don't understand your benchmark. Do you mean that os.walk() is slower
> with fast_bottom-up.patch because islink() is called or because I replaced
> "for entry in scandir(top):" with "entry = next(scandir_it)"?
No, sorry, I w
Ben Hoyt added the comment:
Thanks, Victor.
I haven't quite grokked all the changes here -- it's gotten somewhat more
complicated with the scandir_it and manual next() call -- but I ran some
benchmarks (via a hacked version of my scandir project's benchmark.py). The
results
Ben Hoyt added the comment:
Note specifically in the unsymlink() example Serhiy gave, you probably don't
*want* os.walk() to recurse into a
symlink-to-a-directory-that's-changed-to-a-directory, and you probably haven't
thought about it doing so, so maybe the new be
Ben Hoyt added the comment:
To Victor and Serhiy:
1) Serhiy's point about not needing to build the symlinks set when followlinks
is True is a good one, because it'll never get used. Just a "if not
followlinks: ..." around that try/except would do it. Though this is a small
Ben Hoyt added the comment:
@Scott Dial: just a response about this benchmark: note that this benchmark
isn't really valid, as it says "Using slower ctypes version of scandir", which
is the slow all-Python version. You want it to be saying "Using Python 3.5&#
Ben Hoyt added the comment:
Thanks. Will do!
--
___
Python tracker
<http://bugs.python.org/issue22524>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ben Hoyt added the comment:
Hi Victor. I'm attaching a patch to the What's New doc. I know it's a minor
thing, but I really read the What's New in Python x.y page whenever it comes
out, so making this as specific as possible is good. The changes are:
1. Be more speci
Ben Hoyt added the comment:
Same exact issue here. I didn't have a Python 3.5 alpha 1 previously installed,
and I tried running the installer normally and also (after uninstalling) with
right-click, "Run as administrator".
Both do the same thing for me: pop up a dialog bo
Ben Hoyt added the comment:
Attaching a first cut at this -- basically the implementation I use for walk()
in scandir.py on GitHub.
One thing that's really weird to me: are the os.walk() unit tests actually
being run? In test_os.py, I notice everything's in WalkTest.setUp, which
Ben Hoyt added the comment:
Oops, I'm sorry re previous comment -- looks like I forgot to attach
scandir-8.patch. Now attached. Please re-read my previous comment and review.
:-)
--
Added file: http://bugs.python.org/file38374/scandir-8.
Ben Hoyt added the comment:
Updated version of the patch after Victor's code review of scandir-7 and a
couple of his comments offline. Full commit log is available on my GitHub
project in posixmodule_scandir_main.c if anyone's interested. Again, I haven't
looked closely at th
Ben Hoyt added the comment:
Sorry, but this is operating as designed and documented. See the docs here:
https://docs.python.org/3.4/library/os.path.html#os.path.join
"On Windows ... since there is a current directory for each drive,
os.path.join("c:", "foo") represen
Ben Hoyt added the comment:
Okay, here's the next version of the patch. I've updated scandir-2.patch with a
number of modifications and several fixes to the C code.
This includes Victor's scandir-6.patch test suite (with minor mods) and my
original documentation. Note that I ha
Ben Hoyt added the comment:
Note that this (or a very similar issue) also affects os.listdir() on Windows:
os.listdir(bytes_path_with_nul) raises ValueError as expected, but
os.listdir(unicode_path_with_nul) does not. Test case:
>>> import os
>>> os.mkdir('foo')
Ben Hoyt added the comment:
BTW, I replied to Victor privately, but for the thread: no worries, and apology
accepted! :-) I'm working on updating my C patch with his feedback, and will
update this issue hopefully in the next few days.
--
___
P
Ben Hoyt added the comment:
Akari: yes, I'm aware of this, and it's definitely a concern to me -- it may be
that scandir has a bug with counting the size of certain non-file directory
entries, or my implementation of os.walk() via scandir is not quite correct.
I'll look at it
Ben Hoyt added the comment:
To continue the actual "which implementation" discussion: as I mentioned last
week in http://bugs.python.org/msg235458, I think the benchmarks above show
pretty clearly we should use the all-C version.
For background: PEP 471 doesn't add any new fun
Ben Hoyt added the comment:
Hi Victor, I thank you for your efforts here, especially your addition of
DirEntry.inode() and your work on the tests.
However, I'm a bit frustrated that you just re-implemented the whole thing
without discussion: I've been behind scandir and written
Ben Hoyt added the comment:
Victor, I'd love to push forward with this (I doubt it's going to make alpha 1
on February 8, but hopefully alpha 2 on March 8).
It seems pretty settled that we need to use the all-C version I've created,
especially for Linux.
Can you please review
Ben Hoyt added the comment:
Akira, note the "Using slower ctypes version of scandir" -- this is the older,
ctypes implementation of scandir. On Linux, depending on file system etc, that
can often be slower. You need to at least be using the "fast C version" in
_scandir.c,
Ben Hoyt added the comment:
Attaching updated patch (scandir-2.patch) per Victor's code review here:
http://bugs.python.org/review/22524/diff/13005/Modules/posixmodule.c
Note that I haven't included test_scandir.py this time, as I haven't made any
changes there, and it's
Ben Hoyt added the comment:
I dunno, I'd be happy if you implement this, but it does mean *more* C code,
not less. :-) I feel this would be a nice-to-have, but we should get the thing
working first, and then do the multiple-OS-calls-in-one optimization.
In any case, if you implement th
Ben Hoyt added the comment:
Thanks, Victor and Antone. I'm somewhat surprised at the 2-3x numbers you're
seeing, as I was consistently getting 4-5x in the Linux tests I did. But it
does depend quite a bit on what file system you're running, what hardware,
whether you're
Ben Hoyt added the comment:
Here are the actual numbers (instead of just from memory) running on my Windows
laptop, which happens to have an SSD drive, so os.walk() with scandir is
particularly good here.
python 3.4: benchmark.py -c python (all implemented in Python using ctypes):
os.walk
Ben Hoyt added the comment:
Thanks for the initial response and code review, Victor. I'll take a look and
respond further in the next few days.
In the meantime, however, I'm definitely open to splitting scandir out into its
own C file. This will mean a little refactoring (m
Ben Hoyt added the comment:
Attaching my first patch here. It includes docs, the implementation of scandir
and DirEntry in posixmodule.c, and tests in test_scandir.py. It does not yet
include the changes for os.walk() to use scandir; I'm hoping to do that in a
separate patch for easier
Ben Hoyt added the comment:
Okay, I've opened http://bugs.python.org/issue22524, but I don't have the
permissions to close this one, so could someone with bugs.python.org
superpowers please do that?
--
___
Python tracker
<http://bu
New submission from Ben Hoyt:
Opening this to track the implementation of PEP 471: os.scandir() [1]. This
supercedes Issue #11406 (and possibly others)?
The implementation is most of the way there, but not yet done as a CPythono 3.5
patch. Before I have a proper patch, it's availab
Ben Hoyt added the comment:
Yes, PEP 471 has been accepted, and I've got a mostly-finished C implementation
of os.scandir() for CPython 3.5, as well as tests and docs. If you want a sneak
preview, see posixmodule_scandir*.c, test/test_scandir.py, and os.rst here:
https://github.com/be
Ben Hoyt added the comment:
I really like this idea (and am needing this functionality), but I don't think
this API (or implementation) is very nice:
1) It means you have to change your function signature to use the timeout
feature.
2) Specifying the interval in minutes seems odd
Ben Hoyt added the comment:
Mark, are you referring to part 3 of this issue, the image/pjpeg type of
problem? This was fixed in Python 2.7.6 -- see changeset
http://hg.python.org/cpython/rev/e8cead08c556 and
http://bugs.python.org/issue15207
Ben Hoyt added the comment:
Nick -- sorry, already posted to python-dev before seeing your latest. However,
I think it's the right place, as there's already been a fair bit of hashing
this idea and API out on python-ideas first and then also python-dev. See links
in the PEP
Ben Hoyt added the comment:
Thanks! Will post the PEP to python-dev in the next day or two.
--
___
Python tracker
<http://bugs.python.org/issue11406>
___
___
Pytho
Ben Hoyt added the comment:
Raymond, there are very compelling timings/benchmarks for this -- not so much
the original issue here (generator vs list, that's not really an issue) but
having a scandir() function that returns the stat-like info from the OS so you
don't need extra
Ben Hoyt added the comment:
BTW, thanks for the mention in "What's New in Python 3.5":
https://docs.python.org/3.5/whatsnew/3.5.html#os
Can I make one small suggestion for a tweak there? A link to the docs for
os.stat() would be good. So maybe instead of mentioning "os.st
Ben Hoyt added the comment:
Great, thanks for committing!
--
___
Python tracker
<http://bugs.python.org/issue21719>
___
___
Python-bugs-list mailing list
Unsub
Ben Hoyt added the comment:
Uploading a (hopefully final! :-) patch to fix Zach Ware's points from the code
review:
1) use stat.FILE_ATTRIBUTE_DIRECTORY constant in test_os.py
2) break line length in stat.rst doc source
--
Added file: http://bugs.python.org/file35632/issue21
Ben Hoyt added the comment:
> The idea is that _stat.c will use system-provided values wherever
> possible, but stat.py should be as accurate as we can make it to
> provide a backup for when _stat isn't around (either when it's just
> not built, which isn't an issu
Ben Hoyt added the comment:
Updated patch attached based on code reviews.
I'm replying to the code review here as when I tried to reply on
bugs.python.org/review I got a Python exception, "AttributeError: NoneType has
no attribute something or other". FYI, it seems Django is
Ben Hoyt added the comment:
Cool, thanks for applying. Out of curiosity, how often is the online devguide
HTML updated?
--
___
Python tracker
<http://bugs.python.org/issue21
Ben Hoyt added the comment:
Full patch to add this to Python 3.5 attached:
* code changes to posixmodule.c and _stat.c
* tests added in test_os.py and test_stat.py
* docs added to os.rst and stat.rst
--
keywords: +patch
Added file: http://bugs.python.org/file35615/issue21719.patch
Changes by Ben Hoyt :
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue21745>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Ben Hoyt:
Per my email on core-mentorship, the instructions for compiling CPython on
Windows at
https://docs.python.org/devguide/setup.html#windows are good, however I did
have one issue where the dev guide didn't help. During the link
step, I got this error:
LINK :
Ben Hoyt added the comment:
I've got a patch for this. Need to finish the docs and add tests, and then I'll
post here.
--
___
Python tracker
<http://bugs.python.o
Ben Hoyt added the comment:
Fair call -- "st_file_attributes" sounds good to me, and matches the prefix of
the FILE_ATTRIBUTES_* constants better too.
--
___
Python tracker
<http://bugs.python.o
New submission from Ben Hoyt:
I asked recently on python-dev [1] about adding a "st_winattrs" attribute to
stat result objects on Windows, to return the full set of Windows file
attribute bits, such as "hidden" or "compressed" status. Copying from that
thre
Ben Hoyt added the comment:
All looks great. I like what you've done with default_encoding now. Thanks, Tim
(and Dave for the original report).
--
___
Python tracker
<http://bugs.python.org/is
Ben Hoyt added the comment:
Thanks, Tim! Works for me! A couple of code review comments:
1) On 2.7, guess_type(s)[0] is a byte string as usual if the type doesn't exist
in the registry, but it's a unicode string if it came from the registry. Seems
like it should be a byte string in
Ben Hoyt added the comment:
> Please bring this up on python-dev.
Good idea. Thread started:
http://mail.python.org/pipermail/python-dev/2013-May/126119.html
--
___
Python tracker
<http://bugs.python.org/issu
Ben Hoyt added the comment:
> A normal "caller" would never expect a stat object to be partially populated:
> if a function has a prototype returning a stat object, then I definitely
> expect it to be a regular stat object, with all the fields guaranteed by
> POSI
Ben Hoyt added the comment:
Yeah, I very much agree with what Nick says -- we really want a way to expose
what the platform provides. It's less important (though still the ideal), to
expose that in a platform-independent way. Today the only way to get access to
opendir/readdir on Linu
Ben Hoyt added the comment:
> I find iterdir_stat() ugly :-) I like the scandir name, which has some
> precedent with POSIX.
Fair enough. I'm cool with scandir().
> scandir() cannot return (name, stat), because on POSIX, readdir() only
> returns d_name and d_type (the type
Ben Hoyt added the comment:
That's right: if we have a separate scandir() that returns (name, stat) tuples,
then a plain iterdir() is pretty much unnecessary -- callers just ignore the
second stat value if they don't care about it.
I'd slightly prefer the name iterdir_stat(),
Ben Hoyt added the comment:
Thanks. I thought about that -- but I think I *want* to benchmark it when
they're cached, so that we're comparing apples with apples, cached system
calls with cached systems calls. The benchmark would almost certainly be a
lot "better" (BetterWalk
Ben Hoyt added the comment:
2.7 fix works for me, thanks! Just curious -- why the different fix for 3.3
(addition of __getstate__ instead of removal of __dict__)?
--
___
Python tracker
<http://bugs.python.org/issue15
Ben Hoyt added the comment:
Some folks have asked about benchmarks. I don't know about iterdir() vs
listdir() -- I kind of suspect the speed gains there wouldn't be big.
However, the reason I'm keen on iterdir_stat() is that I'm seeing it speed up
os.walk() by a facto
Ben Hoyt added the comment:
Ah, this is great. I definitely like the idea of a generator version of
os.listdir(). And I like the name iterdir() -- it fits with iteritems() etc.
They've gone in 3.x, of course, but listdir didn't change to an iterator, so...
See also Betterwalk,
Ben Hoyt added the comment:
I just hit this issue in a big way -- would have been nice for this fix to go
into Python 2.7.4. :-)
It was quite hard to track down (as in, a day or two of debugging :-) because
the symptoms didn't point directly to namedtuple. In our setup we
pickle/unp
Ben Hoyt added the comment:
Okay, I'm looking at the diff between mt-tip-noregistry.txt and
mt-tip-newregistry.txt, and I've attached a file showing the lines that are
*different* between the two, as well as the Apache mime.types value for that
file extension.
In most cases, noregi
Ben Hoyt added the comment:
Any update on this, Tim or other Windows developers?
--
___
Python tracker
<http://bugs.python.org/issue15207>
___
___
Python-bug
Ben Hoyt added the comment:
Actually, I was suggesting using the hardcoded types for Windows only (i.e.,
only removing read_windows_registry). Several bugs have been opened on problems
with the Windows registry mimetypes, but as far as I know this isn't an issue
on Linux -- in other word
Ben Hoyt added the comment:
Either way -- this needs to be reverted or fixed. It's a nasty gotcha for folks
writing Python web services at the moment. I'm still for reverting, per my
reasons above.
Dave Chambers, I'm not for "faster but broken" but for "faster
Ben Hoyt added the comment:
Ah, thanks for making this an issue of its own! As I commented over at
Issue10551, it's a serious problem, and makes mimetypes.guess_type() unusable
out of the box on Windows.
Yes, the fix in Issue4969 uses "MIME\Database\Content Type", which
Ben Hoyt added the comment:
This is definitely a real issue, and makes mimetypes.guess_type() useless out
of the box on Windows.
However, I believe the reason it's broken is that the fix for Issue4969 doesn't
actually work, and I'm not sure this is possible with the Windows reg
Ben Hoyt added the comment:
Oops, didn't intend to change the type, changing back.
--
type: feature request -> behavior
___
Python tracker
<http://bugs.python.or
Changes by Ben Hoyt :
--
nosy: +benhoyt
type: behavior -> feature request
___
Python tracker
<http://bugs.python.org/issue6689>
___
___
Python-bugs-list mai
96 matches
Mail list logo
