[issue41122] functools.singledispatchfunction has confusing error message if no positional arguments are passed in
Change by mental : -- nosy: +mental nosy_count: 2.0 -> 3.0 pull_requests: +22111 pull_request: https://github.com/python/cpython/pull/23212 ___ Python tracker <https://bugs.python.org/issue41122> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40988] singledispatchmethod significantly slower than singledispatch
Change by mental : -- keywords: +patch nosy: +mental nosy_count: 1.0 -> 2.0 pull_requests: +22112 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23213 ___ Python tracker <https://bugs.python.org/issue40988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41987] singledispatchmethod raises an error when relying on a forward declaration
Change by mental : -- keywords: +patch nosy: +mental nosy_count: 5.0 -> 6.0 pull_requests: +22113 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/23216 ___ Python tracker <https://bugs.python.org/issue41987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39679] functools: singledispatchmethod doesn't work with classmethod
Change by mental : -- nosy: +mental ___ Python tracker <https://bugs.python.org/issue39679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41987] singledispatchmethod raises an error when relying on a forward declaration
mental added the comment: Interesting! thanks for the hint guido I'll try to investigate further. This sounds like a regression (to me at least), in that case should a separate issue & patch PR be opened on the bpo or should this issue be used instead? -- ___ Python tracker <https://bugs.python.org/issue41987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37661] venv activation scripts erroneously check if __VENV_PROMPT__ is defined
mental added the comment:
Brett, Vinay: mind if I handle this one? I'm looking for a good first issue to
tackle.
In terms of solutions I propose adding short circuiting logic to the checks for
custom prompts to test against the default case `({context.env_name})`
--
nosy: +mental
___
Python tracker
<https://bugs.python.org/issue37661>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37661] venv activation scripts erroneously check if __VENV_PROMPT__ is defined
Change by mental : -- keywords: +patch pull_requests: +14703 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14932 ___ Python tracker <https://bugs.python.org/issue37661> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37661] venv activation scripts erroneously check if __VENV_PROMPT__ is defined
mental added the comment: I've added a PR (#1492) since it was a simple fix. Please feel free to reject if this issue is reserved or some other fatal issue with the solution is found. Otherwise I'd love a review and a double check (mainly paranoia from not wanting to mess up). -- ___ Python tracker <https://bugs.python.org/issue37661> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37668] Allow individual test to be specified by "#" or "."
Change by mental : -- nosy: +ezio.melotti, michael.foord, rbcollins ___ Python tracker <https://bugs.python.org/issue37668> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37652] Multiprocessing shared_memory ValueError on race with ShareableList
mental added the comment: I have been able to reproduce the issue. I'm currently investigating to see what exactly inside the source of ShareableList is causing what appears to be miss synchronization. Currently I think the issue is the documentation failing to mention that ShareableList does not perform atomic operations. But I'm curious if a patch that adds some internal sync primitive is out of the question here? -- nosy: +mental ___ Python tracker <https://bugs.python.org/issue37652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37682] random.sample should support iterators
Change by mental : -- nosy: +mark.dickinson, rhettinger ___ Python tracker <https://bugs.python.org/issue37682> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37652] Multiprocessing shared_memory ValueError on race with ShareableList
mental added the comment: Interestingly enough the race only seems to occur when the mutator resets the index with an identical value (try replacing the setitem value with: `not X[0]` or populate from `[b'hi']` and with the mutator code use `X[0][::1]`. I can't help but think to implement an internal cache that would store the hash of the last modified value, then when another set occurs compare the two hashes and have the operation be a no-op if they match (thoughts?). In the meantime I'll continue investigating to see what exactly causes this quirk :) -- ___ Python tracker <https://bugs.python.org/issue37652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37652] Multiprocessing shared_memory ValueError on race with ShareableList
mental added the comment: > The root of the error is that struct.pack_into starts by memsetting the > underlying memory area with NULL bytes before filling the data with memcpy. I've had a fix spinning for about a day now, it introduced a `multiprocessing.Lock` and it was simply wrapped around any struct packing and unpacking calls. I've been reluctant to submit anything due to a suspicious resource warning I kept seeing about leaked shared_memory objects appearing spuriously and I wanted to rule out the possibility that other tests were causing a side effect. Also I wanted to hear an expert from the noisy list share their thoughts. > I'm not sure this should be done internally I agree, even with my patch not reproducing the issue I didn't like placing a lock around various components in the class. > +1 For a documentation addition. If there are no objections, I'll submit a PR with a doc update :) @Pierre mind if I cc' you for a review? -- ___ Python tracker <https://bugs.python.org/issue37652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37726] Tutorial should not recommend getopt
mental added the comment: It's nice to see the newcomer friendly tag being encouraged :thumbsup: I'm submitting a PR for a doc change (I'd appreciate a review :D). I've replaced any mention of getopt in the tutorial section with the argparse module. Additionally I have added several small examples of usage promoting its usability. Should the section recommend using other dedicated packages for parsing: fire, click, docopt? urllib.request does this for the requests package. -- nosy: +mental ___ Python tracker <https://bugs.python.org/issue37726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37726] Tutorial should not recommend getopt
Change by mental : -- keywords: +patch pull_requests: +14802 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15052 ___ Python tracker <https://bugs.python.org/issue37726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36298] Lib/pyclbr.py crashes when the package spec cannot be determined by importlib
New submission from mental : Hi folks! (apologies in advance if any of the code blocks come out irregular, this is my first issue) I was just exploring the `Lib` modules out of curiosity and I discovered `pyclbr` a peculiar artifact from the older days of the Python standard library. I noticed the module could be run directly and after attempting to run it withan invalid source target `python -m pyclbr somenonexistentfile` it raised ``` Traceback (most recent call last): File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "/usr/lib/python3.7/runpy.py", line 85, in _run_code exec(code, run_globals) File "/usr/lib/python3.7/pyclbr.py", line 405, in _main() File "/usr/lib/python3.7/pyclbr.py", line 380, in _main tree = readmodule_ex(mod, path) File "/usr/lib/python3.7/pyclbr.py", line 116, in readmodule_ex return _readmodule(module, path or []) File "/usr/lib/python3.7/pyclbr.py", line 169, in _readmodule if spec.submodule_search_locations is not None: AttributeError: 'NoneType' object has no attribute 'submodule_search_locations'``` I was running 3.7.2, although I assume this affects future versions and possibly some older versions. (I suspect the bug originates from importlib silently breaking backwards compatability) I thought it strange for a script to exit so loudly so after reading through the source I believe the intended behavior meant for an invalid target is to raise an `ImportError` although I admit I'm not convinced this is still the best way to exit from erroneous input (or even if the module is still relevant in todays code?) I believe this is a bug (but I would very much appreciate a second opinion) and I've identified it as a low priority easy fix, In which case I'd be more than happy to submit a fix :) -- messages: 337966 nosy: mental priority: normal severity: normal status: open title: Lib/pyclbr.py crashes when the package spec cannot be determined by importlib type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue36298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36298] Lib/pyclbr.py crashes when the package spec cannot be determined by importlib
Change by mental : -- type: crash -> behavior ___ Python tracker <https://bugs.python.org/issue36298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36298] Lib/pyclbr.py crashes when the package spec cannot be determined by importlib
mental added the comment: Thanks :) I've submitted a review for the patch. -- ___ Python tracker <https://bugs.python.org/issue36298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29553] Argparser does not display closing parentheses in nested mutex groups
mental added the comment: Can this issue be closed? It's been inactive for a while and all it needs is a contributor to merge and close. Seems to me it's been resolved with PRs 117 and 120, the difference between them being 120 drops the inner brackets for the format usage (imo 120 should be merged and 117 should be closed). -- nosy: +mental ___ Python tracker <https://bugs.python.org/issue29553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
