[issue45544] Close 2to3 issues and list them here
Change by Ashley Whetter : -- nosy: +AWhetter nosy_count: 6.0 -> 7.0 pull_requests: +27389 pull_request: https://github.com/python/cpython/pull/21296 ___ Python tracker <https://bugs.python.org/issue45544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41110] 2to3 reports some files as both not changing and having been modified
Change by Ashley Whetter : -- keywords: +patch pull_requests: +20445 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21296 ___ Python tracker <https://bugs.python.org/issue41110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41110] 2to3 reports some files as both not changing and having been modified
New submission from Ashley Whetter : Many of the fixers cause the tool to report a file as both unchanged and modified. For example when checking a file with the following contents: ``` s = "str" ``` using the following command: `python -m lib2to3 -f unicode unicode_test.py` The following is output: ``` RefactoringTool: No changes to unicode_test.py RefactoringTool: Files that need to be modified: RefactoringTool: unicode_test.py ``` When a fixer returns a node, even if it is the original node without changes, it is considered as a change to the code (https://github.com/python/cpython/blob/cf18c9e9d4d44f6671a3fe6011bb53d8ee9bd92b/Lib/lib2to3/refactor.py#L446-L447) and the file is later added to the list of modified files. I have not yet identified which fixers have this issue. The fix appears to be that fixers need to be aware of when they have not made a change and should `None` when that is the case. -- components: 2to3 (2.x to 3.x conversion tool) messages: 372299 nosy: AWhetter priority: normal severity: normal status: open title: 2to3 reports some files as both not changing and having been modified versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34938] Fix mimetype.init() to account for from import
Ashley Whetter added the comment: Yes I'm happy to make those changes as part of this. So clarify what needs to change in PR 16567: 1) Include a note in the docs for `inited` that outlines that if it is imported into the local scope, it will not be updated by calls to `init()`. Only `mimetypes.inited` will. 2) Add a clarification to the `add_type()` docs that changes made with `strict=True` means that they will persist after subsequent calls to `init()`. 3) Remove `_default_mime_types()` in favour of public global constants. The documentation currently refers to these globals as the "official MIME types". Should that wording change to use "default" instead of "official", or maybe should the names of the constants change to `OFFICIAL_SUFFIX_MAP` for example? -- ___ Python tracker <https://bugs.python.org/issue34938> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37701] shutil.copyfile raises SpecialFileError for symlink to fifo
Change by Ashley Whetter : -- keywords: +patch pull_requests: +17050 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16575 ___ Python tracker <https://bugs.python.org/issue37701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38957] Cannot compile with libffi from source on Windows
Ashley Whetter added the comment: Ah you're right. I was trying to install in the same way as previous versions. I didn't realise that calling prepare_*.bat was a separate step now. Sorry about that. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38957> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38957] Cannot compile with libffi from source on Windows
New submission from Ashley Whetter : get_externals.bat downloads and extracts libffi to a versioned directory (much like the other external libraries). See https://github.com/python/cpython/blob/v3.8.0/PCbuild/get_externals.bat#L55 However the binary release is downloaded to an unversioned directory. See https://github.com/python/cpython/blob/v3.8.0/PCbuild/get_externals.bat#L79 The visual studio project looks for the unversioned directory (https://github.com/python/cpython/blob/v3.8.0/PCbuild/python.props#L62), and so the binaries are always used. So it is possible to build from source, but you have to move libffi yourself after running `get_externals_bat --libffi-src`. I think the fix here is to make get_externals.bat and visual studio always use a versioned directory. -- components: Build, Windows messages: 357736 nosy: AWhetter, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Cannot compile with libffi from source on Windows versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38957> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34938] Fix mimetype.init() to account for from import
Ashley Whetter added the comment: Maybe updating the dictionaries isn't right at all. I think if you were experienced enough you would have the intuition that mutable attributes like this are not going to change in your local scope if you import them into it. But relying on this knowledge makes it difficult for newer users. Plus we all make mistakes ;) So a note in the docs sounds like a good idea to me. I think `init` does rebuild when `files` is `None` (https://github.com/python/cpython/blob/edb172a87296d9359593a23cd9a09f5867ea1f0e/Lib/mimetypes.py#L350) but it's not clear to me whether rebuilding should include any additional types registered with `add_type`. At the moment it says `the mapping will be added to the official MIME types`, but I think an additional note that this means that it will persist after subsequent calls to `init` would make that clear. As for importing `init` into the local scope, I think ideally we wouldn't use `global` at all. We should be able to make `init` import `mimetypes` locally and explicitly access attributes on the module? Another option is we make the module attributes accessible through a module level `__getattr__` which gets the attributes off of the global `Mimetypes` object stored in `mimetypes._db`. But that would still require usage of a `global _db`. -- nosy: +AWhetter ___ Python tracker <https://bugs.python.org/issue34938> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33714] module can set an exception in tp_clear
Ashley Whetter added the comment: I've just realised that this issue was specific to tp_clear on a module and not on objects. tp_clear on modules has already been fixed in https://bugs.python.org/issue33622. I think this is closable. -- ___ Python tracker <https://bugs.python.org/issue33714> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33714] module can set an exception in tp_clear
Ashley Whetter added the comment:
I've attached a reproduction case. Here's the setup.py that I used:
```
from distutils.core import Extension, setup
extension = Extension("breaky", ["breaky.c"])
setup(
name="tp_clear",
version="0.1.0",
ext_modules=[extension],
)
```
which I built and ran with:
```
python setup.py build_ext --inplace
python -c "import breaky, gc; a = breaky.Breaky(); a = 1"
```
--
nosy: +AWhetter
Added file: https://bugs.python.org/file48642/breaky.c
___
Python tracker
<https://bugs.python.org/issue33714>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
