[issue46148] Optimize pathlib

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue46148> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46118] Migrate importlib.resources into a package

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue46118> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46125] Test the preferred API instead of relying on legacy for coverage

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue46125> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46171] venv module produces spurious warning that location has moved

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue46171> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45413] Add install scheme for virtual environments

Filipe Laíns added the comment: I agree. -- ___ Python tracker <https://bugs.python.org/issue45413> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45413] Add install scheme for virtual environments

Filipe Laíns added the comment: I don't think the proposal is incompatible with what I discussed. I haven't been super clear on my opinions on the implementation, so let me try to clarify them. - I think that we should use a static scheme, accessible on all platforms. - If this sc

[issue45413] Add install scheme for virtual environments

Filipe Laíns added the comment: With PR 31034 merged, we can now mark this as resolved. As mentioned in the PR, there are still some concerns about maintainability and avoiding similar issues to happen in the future. That can be done later, as people find time to work on it. Thanks

[issue43850] unreproducible bytecode: set order depends on random seed for compiled bytecode

New submission from Filipe Laíns : Currently, the order of set or frozenset elements when saved to bytecode is dependent on the random seed. This breaks reproducibility. Example fail from an Arch Linux package: https://reproducible.archlinux.org/api/v0/builds/88454/diffoscope Let's ta

[issue43850] unreproducible bytecode: set order depends on random seed for compiled bytecode

Change by Filipe Laíns : -- keywords: +patch pull_requests: +24143 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25411 ___ Python tracker <https://bugs.python.org/issu

[issue43850] unreproducible bytecode: set order depends on random seed for compiled bytecode

Change by Filipe Laíns : -- nosy: +christian.heimes ___ Python tracker <https://bugs.python.org/issue43850> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43850] unreproducible bytecode: set order depends on random seed for compiled bytecode

Filipe Laíns added the comment: I just realized my fix is wrong because list.sort does not handle different types. Similarly to other reproducibility fixes, how does skipping the item randomization when SOURCE_DATE_EPOCH is set sound

[issue43850] unreproducible bytecode: set order depends on random seed for compiled bytecode

Filipe Laíns added the comment: Nevermind, AFAIK that depends on the hash seed, correct? So, the most viable option to me would be a sorting algorithm that could take type into account. Would that be an acceptable solution? -- ___ Python tracker

[issue43850] unreproducible bytecode: set order depends on random seed for compiled bytecode

Filipe Laíns added the comment: Sorry for the spam, I am trying to figure out the best option here, which is hard to do by myself. IMO it would be reasonable to create set objects with elements in the order they appear in the code, instead of based on the hash. I am not really sure where is

[issue37596] Reproducible pyc: frozenset is not serialized in a deterministic order

Filipe Laíns added the comment: Normal sets have the same issue, see bpo-43850. Would it be reasonable to make it so that sets are always created with the definition order? Looking at the set implementation, this seems perfectly possible. -- nosy: +FFY00

[issue37596] Reproducible pyc: frozenset is not serialized in a deterministic order

Filipe Laíns added the comment: > No, it would not. We would also have to maintain order across set operations > such as intersection which which would become dramatically more expensive if > they had to maintain order. For example intersecting a million element set > with a

[issue37596] Reproducible pyc: frozenset is not serialized in a deterministic order

Filipe Laíns added the comment: s/is can/can/ -- ___ Python tracker <https://bugs.python.org/issue37596> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41282] Deprecate and remove distutils

Change by Filipe Laíns : -- pull_requests: +24409 pull_request: https://github.com/python/cpython/pull/25718 ___ Python tracker <https://bugs.python.org/issue41

[issue43976] Introduce mechanism to allow Python distributors to add custom site install schemes

New submission from Filipe Laíns : As part of the distutils migration we plan to add a mechanism to let Python distributors to add site install schemes. Currently, Python distributors are patching distutils to add custom install schemes for their packages. I think most of the reasoning boils

[issue41282] Deprecate and remove distutils

Filipe Laíns added the comment: That is reasonable. I have created bpo-43976. -- ___ Python tracker <https://bugs.python.org/issue41282> ___ ___ Python-bug

[issue41282] Deprecate and remove distutils

Filipe Laíns added the comment: We have discussed this approach a little in a few bug trackers, but I opened https://discuss.python.org/t/mechanism-for-distributors-to-add-site-install-schemes-to-python-installations/8467. -- ___ Python tracker

[issue43976] Introduce mechanism to allow Python distributors to add custom site install schemes

Filipe Laíns added the comment: Making sysconfig look at sitecustomize seems like the wrong approach. It is behavior I would never expect, and there are use-cases where I still want the schemes to be present when the site module initialization is disabled. I would also argue that having this

[issue29753] [Linux] ctypes packs bitfields Incorrectly

Filipe Laíns added the comment: I forgot to ping here, the patch went in and should be available in 3.10, so this can be closed now. -- nosy: +jaraco ___ Python tracker <https://bugs.python.org/issue29

[issue43976] Allow Python distributors to add custom site install schemes

Filipe Laíns added the comment: FYI, I have change the implementation to split the extra install schemes and extra schemes activated on site. This still makes sense over sitecustomize because we want the packages to be included in site.getsitepackages -- we want the vendor packages to

[issue31526] Allow setting timestamp in gzip-compressed tarfiles

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue31526> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43976] Allow Python distributors to add custom site install schemes

Filipe Laíns added the comment: > My biggest concern is with the bare "import _vendor_config", which I'd prefer > to have restricted to a fixed location, rather than being influenced by > environment variables and other options. We already have an issue with > r

[issue41282] Deprecate and remove distutils

Filipe Laíns added the comment: I believe sysconfig.get_path('purelib') and sysconfig.get_path('platlib') should work for you. > sysconfig.get_path('purelib') /usr/lib/python3.9/site-packages > sysconfig.get_path('platlib') /usr/lib/python3.9/site

[issue41282] Deprecate and remove distutils

Filipe Laíns added the comment: If you are relying on the value of distutils.sysconfig.get_python_lib() as you shown in your system, you probably don't want to. That directory (dist-packages) should be for Debian provided packages only, so moving to sysconfig.get_path() would be a good

[issue43976] Allow Python distributors to add custom site install schemes

Filipe Laíns added the comment: We cannot change how `sudo pip install` fundamentally works because there are too many people depending on it, and even if we could, this is not the place :P I think we went a little off-topic here, so let's get back to the discussion. > The best op

[issue41282] Deprecate and remove distutils

Filipe Laíns added the comment: That always depends on the way distros patch Python, though all the major distros I know will add their schemes to sysconfig, which works what that approach. But yeah, that is what you probably want to be doing

[issue37596] Reproducible pyc: frozenset is not serialized in a deterministic order

Filipe Laíns added the comment: Another idea, would it be possible to add a flag to turn on reproducibility, sacrificing performance? This flag could be set when generating bytecode, where the performance hit shouldn't be that rel

[issue38693] Use f-strings instead of str.format within importlib

Filipe Laíns added the comment: Both importlib_metadata and importlib_resources have dropped support for Python 2.7 and 3.5, this should now be unblocked. -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue38

[issue44137] importlib.resources.path raises RuntimeError when FileNotFoundError is raise in context manager

Filipe Laíns added the comment: This was fixed in https://github.com/python/cpython/pull/22915. It can be closed now. -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue44

[issue43643] importlib.readers.MultiplexedPath.name is not a property

Filipe Laíns added the comment: For references, this was fixed in https://github.com/python/importlib_resources/commit/9822338e8de57e99aa3c26275ebdbf8925af7bc8#diff-811ea42dba2528e9a6cbedc91e993dc2a9d4b65626ad364c6ded7b03e0d0a1fa and should go into CPython in the next code sync

[issue44137] importlib.resources.path raises RuntimeError when FileNotFoundError is raise in context manager

Filipe Laíns added the comment: The supress(FileNotFoundError) context manager now is only active when fetching the file, not during importlib.resources.path. _path_from_resource_path is not longer a generator, so supress(FileNotFoundError) is promptly closed after the return, preventing its

[issue42516] Add function to get caller's name

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue42516> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44162] importlib.resources.path no longer supports directories

Filipe Laíns added the comment: Directories are not resources, the reason it previously worked was purely accidental. I assume you already found a solution in https://github.com/python/importlib_resources/issues/85, which would be importlib.resources.files(__package__) / 'dir' C

[issue44162] importlib.resources.path no longer supports directories

Filipe Laíns added the comment: Yes, it would be good to properly define resources in the current docs. Though, I am left questioning if that definition is still correct, I assume so given the implementation. I will open a new bug regarding the documentation of what is considered a resource

[issue44164] Document what are resources in importlib.resources

New submission from Filipe Laíns : It would be good to explain what constitutes a resource in the importlib.resources documentation. As per the current implementation, they should be defined as arbitrary files contained in the package. Is this correct? -- assignee: docs@python

[issue44195] importlib.abc.TraversableReader is not implemented

New submission from Filipe Laíns : 7f7e706d78ab968a1221c6179dfdba714860bd12 introduced the files() api and documented a importlib.abc.TraversableReader protocol, but it did not implement it. This class is documented and marked as introduced in 3.9, but it's actually mi

[issue44195] importlib.abc.TraversableReader is not implemented

Change by Filipe Laíns : -- keywords: +patch pull_requests: +24876 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26271 ___ Python tracker <https://bugs.python.org/issu

[issue42022] Allow ensurepip to work without bundled wheels

Filipe Laíns added the comment: Closing as the new --with-wheel-pkg-dir option provides an alternative mechanism. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue44196] Document that importlib.abc.Traversable's methods should raise FileNotFoundError

New submission from Filipe Laíns : ResourceReader used to have this requirement, Traversable does not. We cannot add a requirement as there might be users not doing this, but we can ask new users to do so. We should document that FileNotFoundError should be raised if a file is not found, but

[issue44195] importlib.abc.TraversableReader is not implemented

Change by Filipe Laíns : -- pull_requests: +24877 pull_request: https://github.com/python/cpython/pull/26272 ___ Python tracker <https://bugs.python.org/issue44

[issue44196] Document that importlib.abc.Traversable's methods should raise FileNotFoundError

Change by Filipe Laíns : -- keywords: +patch pull_requests: +24878 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26272 ___ Python tracker <https://bugs.python.org/issu

[issue25625] "chdir" Contex manager for pathlib

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue25625> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44200] Recommend importlib.abc.Traversable users to implement __fspath__

New submission from Filipe Laíns : The files()/Traversable api is meant to replace ResourceReader api, but it falls short in one dimension, tying the abstraction to a file system path. I propose to document that Traversable users *should* implement __fspath__ if the Traversable represents a

[issue44200] Recommend importlib.abc.Traversable users to implement __fspath__

Filipe Laíns added the comment: I am gonna wait until/if GH-26272 (#44196) gets merged because this would conflict with that. -- ___ Python tracker <https://bugs.python.org/issue44

[issue44200] Recommend importlib.abc.Traversable users to implement __fspath__

Change by Filipe Laíns : -- assignee: -> docs@python components: +Documentation nosy: +docs@python ___ Python tracker <https://bugs.python.org/issu

[issue44202] Add errors argument to importlib.abc.Traversable.read_text

New submission from Filipe Laíns : errors should be supported by Traversable.open and is currently supported in importlib.resources.open_text, but Traversable.read_text cannot do it, making it an unsuitable replacement for open_text. -- messages: 394088 nosy: FFY00, brett.cannon

[issue44202] Add errors argument to importlib.abc.Traversable.read_text

Filipe Laíns added the comment: I am gonna wait until/if GH-26272 (#44196) gets merged to submit a PR because it will conflict with that. -- components: +Library (Lib) versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue44

[issue44164] Document what are resources in importlib.resources

Change by Filipe Laíns : -- keywords: +patch pull_requests: +24886 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26280 ___ Python tracker <https://bugs.python.org/issu

[issue44210] Make importlib.metadata._meta.PackageMetadata public

New submission from Filipe Laíns : This protocol is needed to write type hints, so it should be public. -- components: Installation messages: 394150 nosy: FFY00, jaraco priority: normal severity: normal status: open title: Make importlib.metadata._meta.PackageMetadata public type

[issue44210] Make importlib.metadata._meta.PackageMetadata public

Change by Filipe Laíns : -- keywords: +patch pull_requests: +24902 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26299 ___ Python tracker <https://bugs.python.org/issu

[issue44210] Make importlib.metadata._meta.PackageMetadata public

Change by Filipe Laíns : -- components: +Library (Lib) -Installation ___ Python tracker <https://bugs.python.org/issue44210> ___ ___ Python-bugs-list mailin

[issue44195] importlib.abc.TraversableReader is not implemented

Filipe Laíns added the comment: We do implement the protocol, and not TraversableResources, in some places, such as DegenerateFiles for eg. It seems to me that maybe that is an issue and we actually want to inherit from TraversableResources. The question here is, are people supposed to be

[issue44196] Document that importlib.abc.Traversable's methods should raise FileNotFoundError

Filipe Laíns added the comment: Okay. Having a better look at it, I think we should only add this specification to open(). Traversable, by design, makes it totally plausible that open() cannot be performed. It could be a nonexistent path, the Traversable could represent object where open

[issue44196] Document that importlib.abc.Traversable's methods should raise FileNotFoundError

Filipe Laíns added the comment: That makes sense, I wish all these details were documented, but it is more than enough precedent to choose to not add such enforcements to the specification. -- resolution: -> rejected stage: patch review -> resolved status: open -&g

[issue44200] Recommend importlib.abc.Traversable users to implement __fspath__

Filipe Laíns added the comment: That's why I said it should be optional. If the object can implement it, it should. `pathlib.Path` certainly can, `zipfile.Path` can't, and that's alright. If the Traversable does not represent a path on the file-system, it does not make sen

[issue44200] Recommend importlib.abc.Traversable users to implement __fspath__

Filipe Laíns added the comment: CompatibilityFiles would use this. We could add a dispatch for that too, but that's 2 different cases now and `os.PathLike` would be able to handle both. -- ___ Python tracker <https://bugs.python.org/is

[issue44192] Annotations, Inheritance and Circular Reference

Filipe Laíns added the comment: The annotations will effectively become strings, instead of object references, in Python 3.11, which solves this issue. You can enable this behavior in holder Python version with `from __future__ import annotations`, see PEP 563[1]. >>> c

[issue44192] Annotations, Inheritance and Circular Reference

Filipe Laíns added the comment: s/holder/older/ Sorry, my dyslexia is acting up. -- ___ Python tracker <https://bugs.python.org/issue44192> ___ ___ Python-bug

[issue42654] Add folder for python customizations: __sitecustomize__

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue42654> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42043] zipfile.Path should support inheritance

Filipe Laíns added the comment: This can be closed now. -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue42043> ___ ___ Python-bugs-list mailin

[issue29468] zipfile should catch ValueError as well as OSError to detect bad seek calls

Filipe Laíns added the comment: That would not stay true to its meaning. AFAIK there are no implied exceptions in file objects. Given the meaning of ValueError, I'd say it is appropriate here. -- nosy: +FFY00 ___ Python tracker &

[issue43066] Zipfile with leading slashes

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue43066> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42112] ZipFIle.write remove slash at the beginning of member's path

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue42112> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37596] Reproducible pyc: frozenset is not serialized in a deterministic order

Filipe Laíns added the comment: I would not expect SOURCE_DATE_EPOCH to sacrifice performance. During packaging, SOURCE_DATE_EPOCH is always set, and sometimes we need to perform expensive operations. We only need this behavior during cache generation, making the solution not optimal

[issue37596] Reproducible pyc: frozenset is not serialized in a deterministic order

Filipe Laíns added the comment: What about normal sets? They also suffer from the same issue. -- ___ Python tracker <https://bugs.python.org/issue37596> ___ ___

[issue40551] PRs should be rebased on top of master before running the build/tests

Change by Filipe Laíns : -- resolution: -> works for me stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue37596] Reproducible pyc: frozenset is not serialized in a deterministic order

Filipe Laíns added the comment: Ah, my bad! Though, thinking about it, it does make sense. If that's the case, then the argument Raymond provided against preserving order does not seem that relevant, as we would only need to preserve the order in the creation operation. What do you thin

[issue37596] Reproducible pyc: frozenset is not serialized in a deterministic order

Filipe Laíns added the comment: I understand, the proposal would be to make frozensets keep the creation order. -- ___ Python tracker <https://bugs.python.org/issue37

[issue24132] Direct sub-classing of pathlib.Path

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue24132> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42125] linecache cannot get source for the __main__ module with a custom loader

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue42125> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40350] modulefinder chokes on numpy - dereferencing None in spec.loader

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue40350> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44262] tarfile: some content different output

Filipe Laíns added the comment: I modified the script to keep the both Python generated tarballs and ran diffoscope, which presents the issue very clearly: $ diffoscope py.gz py2.gz --- py.gz +++ py2.gz ├── filetype from file(1) │ @@ -1 +1 @@ │ -gzip compressed data, was "py", las

[issue21550] Add Python implementation of the tar utility

Filipe Laíns added the comment: Given the addition of the tarfile CLI and the seeming lack of interest, can this be closed? -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue21

[issue44262] tarfile: some content different output

Filipe Laíns added the comment: tarfile will keep the mtime from the file, the issue is that you are touching the files in the beginning of the script. When you write to the files, you change the mtime (last modified time), which produces a different TarInfo. If you comment out the code that

[issue44262] tarfile: some content different output

Filipe Laíns added the comment: Yeah, I understand. What you want is achieved by making sure the mtime from the tar archive, and files on the archive, is reproducible, like I demonstrated here. Can this be closed? -- ___ Python tracker <ht

[issue44262] tarfile: some content different output

Change by Filipe Laíns : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44262> ___ ___

[issue44340] Add support for building cpython with clang thin lto

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue44340> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44395] email.message as_string() not writing unixfrom

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue44395> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44445] Add `site-include` install scheme path in sysconfig

New submission from Filipe Laíns : During the distutils deprecation, we have identified that there is no good replacement for the distutils `headers` install path. This path defines where packages are supposed to install headers on the system. The setuptools equivalent would be `include

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Change by Filipe Laíns : -- nosy: +iritkatriel ___ Python tracker <https://bugs.python.org/issue6> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Change by Filipe Laíns : -- keywords: +patch nosy: +FFY00 nosy_count: 4.0 -> 5.0 pull_requests: +25366 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26781 ___ Python tracker <https://bugs.python.org/i

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Filipe Laíns added the comment: I bissected this to 088a15c49d99ecb4c3bef93f8f40dd513c6cae3b and submitted a patch making traceback.FrameSummary take into consideration that lineno might be None, I believe this is probably the correct fix

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Change by Filipe Laíns : -- pull_requests: +25367 pull_request: https://github.com/python/cpython/pull/26782 ___ Python tracker <https://bugs.python.org/issue44

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Filipe Laíns added the comment: Upon further investigation, there are actually two issues here. The first would be the one I identified already, traceback.FrameSummary not being prepared for lineno being None, but there is also a regression in lineno being invalid in this situation in the

[issue44446] linecache.getline TypeError when formatting tracebacks in stacks containing an async list comprehension

Filipe Laíns added the comment: The issue that made the line number be missing is fixed, but GH-26781 is needed to account for 088a15c49d99ecb4c3bef93f8f40dd513c6cae3b, even though it is no longer triggered in this situation. -- ___ Python tracker

[issue29753] [Linux] ctypes packs bitfields Incorrectly

Change by Filipe Laíns : -- pull_requests: +25633 pull_request: https://github.com/python/cpython/pull/27085 ___ Python tracker <https://bugs.python.org/issue29

[issue29753] [Linux] ctypes packs bitfields Incorrectly

Filipe Laíns added the comment: Unfortunately, the fix has some unforeseen side-effects, so we'll have to revert it :/ -- resolution: fixed -> status: closed -> open versions: +Python 3.11 ___ Python tracker <https://bugs.python.

[issue29753] [Linux] ctypes packs bitfields Incorrectly

Filipe Laíns added the comment: Sorry for not posting a link here, see https://github.com/python/cpython/pull/19850#issuecomment-869410686. The issue is not legacy behavior, it's that the fix messed up the functionality and that was not caught by tests. I don't have much time to

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

Change by Filipe Laíns : -- nosy: +FFY00 stage: -> needs patch type: -> behavior ___ Python tracker <https://bugs.python.org/issue44603> ___ ___ Pyth

[issue42854] OpenSSL 1.1.1: use SSL_write_ex() and SSL_read_ex()

Filipe Laíns added the comment: https://twitter.com/geofft/status/1417167982665551877 -- nosy: +FFY00 resolution: fixed -> status: closed -> open ___ Python tracker <https://bugs.python.org/i

[issue44717] Improve AttributeError on circular imports of submodules

New submission from Filipe Laíns : Consider the following $ tree a a ├── b │ ├── c.py │ └── __init__.py └── __init__.py 1 directory, 3 files $ cat a/b/__init__.py import a.b.c $ cat a/b/c.py import a.b a.b $ python Python 3.9.6 (default, Jun 30 2021, 10:22:16) [GCC 11.1.0] on linux Type

[issue44717] Improve AttributeError on circular imports of submodules

Change by Filipe Laíns : -- keywords: +patch pull_requests: +25842 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27299 ___ Python tracker <https://bugs.python.org/issu

[issue39632] variadic function call broken on armhf when passing a float argument

Filipe Laíns added the comment: #28491 is now resolved, so the PR should be unblocked. Would you mind rebasing it on main to retrigger the CI? -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue39

[issue44717] Improve AttributeError on circular imports of submodules

Change by Filipe Laíns : -- pull_requests: +25881 pull_request: https://github.com/python/cpython/pull/27338 ___ Python tracker <https://bugs.python.org/issue44

[issue44717] Improve AttributeError on circular imports of submodules

Change by Filipe Laíns : -- pull_requests: +25886 pull_request: https://github.com/python/cpython/pull/27344 ___ Python tracker <https://bugs.python.org/issue44

[issue44777] Create mechanism to contact buildbot worker owners

Change by Filipe Laíns : -- nosy: +FFY00 ___ Python tracker <https://bugs.python.org/issue44777> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44771] Adopt changes from importlib_resources 5.2

Change by Filipe Laíns : -- pull_requests: +26000 pull_request: https://github.com/python/cpython/pull/27484 ___ Python tracker <https://bugs.python.org/issue44

  1   2   3   >