[issue37935] Improve performance of pathlib.scandir()

Shai added the comment: I'm new to contributing here. I've never done benchmarking before. I'd appreciate it if you could provide a guide to benchmarking. You could look at the changes I made in the pull request (PR 15331). They're easy to follow and I think that removi

[issue37935] Improve performance of pathlib.scandir()

Shai added the comment: >From the docs (https://docs.python.org/3/library/os.html#os.scandir.close): "This is called automatically when the iterator is exhausted or garbage collected, or when an error happens during iterating. However it is advisable to call it explicitly or use

[issue37935] Improve performance of pathlib.scandir()

New submission from Shai : I recently have taken a look in the source code of the pathlib module, and I saw something weird there: when the module used the scandir function, it first converted its iterator into a list and then used it in a for loop. The list wasn't used anywhere else,

[issue31946] mailbox.MH.add loses status info from other formats

New submission from Shai Berger : In mailbox.py in the stdlib, the functions MH.add and MH.__setitem__ take a message object and dump it to a file in the MH folder, which is good and well. However, they only call self._dump_sequences() if the message was already an MHMessage. Since in the MH

[issue27286] str object got multiple values for keyword argument

Shai Berger added the comment: Following the last comment, and just as clarification for anyone else running into this and thinking like me: The bumped code is not included in v3.5.2, and v3.5.3 hasn't been released yet. Should it be undone? No, because the bump which was encountered by

[issue13936] datetime.time(0, 0, 0) evaluates to False despite being a valid time

Shai Berger added the comment: Just got bit by this. Tim Peters said: """ It is odd, but really no odder than "zero values" of other types evaluating to false in Boolean contexts. """ I disagree. Midnight is not a "zero value", it is jus

[issue18009] os.write.__doc__ is misleading

New submission from Shai Berger: At least on posix systems, os.write says it takes a string, but in fact it barfs on strings -- it needs bytes. $ python Python 3.3.1 (default, May 6 2013, 16:18:33) [GCC 4.7.2] on linux Type "help", "copyright", "credits" or

[issue17108] import silently prefers package over module when both available

Shai Berger added the comment: Oh, sure, this was unclear of me. I thought you were talking about Python 3.4. I wasn't really expecting this to be fixed in the stable branches. Thanks, Shai. -- ___ Python tracker <http://bugs.python.org/is

[issue17108] import silently prefers package over module when both available

Shai Berger added the comment: Hi, > the reason this stuff can't change [... is] backward compatibility. Thanks, but this is still unclear to me. The required fix for code that would break because of the change I propose, is removal of dead code which looks misleadingly alive.

[issue17108] import silently prefers package over module when both available

Shai Berger added the comment: Thanks for the quick response. If this isn't changing, I'd definitely want better documentation. In particular, the rationale behind this should be explained. I submitted the bug because a co-worker unintentionally caused a whole suite of tests to

[issue17108] import silently prefers package over module when both available

New submission from Shai Berger: Consider the following directory structure: a-\ __init__.py b.py b-| __init__.py Now, in Python (I checked 2.7.3 and 3.2.3, haven't seen the issue mentioned anywhere so I suspect it is also in later Pythons), if you import a.b, you always ge