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
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
Filipe Laíns added the comment:
I agree.
--
___
Python tracker
<https://bugs.python.org/issue45413>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue46171>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue46125>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue46118>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue46148>
___
___
Python-bugs-list mailing list
Unsubscribe:
Filipe Laíns added the comment:
Can you share the link? I haven't seen anything recent. Is it under other
thread?
--
___
Python tracker
<https://bugs.python.org/is
Change by Filipe Laíns :
--
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issue45653>
___
___
Python-bugs-list mailing list
Un
Filipe Laíns added the comment:
I have already opened up the PR, but I can change if desired.
--
stage: patch review -> needs patch
___
Python tracker
<https://bugs.python.org/issu
Change by Filipe Laíns :
--
keywords: +patch
pull_requests: +27599
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/29331
___
Python tracker
<https://bugs.python.org/issu
Filipe Laíns added the comment:
I just tested partially freezing the package, and it seems to working fine :)
--
___
Python tracker
<https://bugs.python.org/issue45
Change by Filipe Laíns :
--
keywords: +patch
pull_requests: +27598
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/29329
___
Python tracker
<https://bugs.python.org/issu
Filipe Laíns added the comment:
That is good to know. This isn't very high on my priority list, but I will try
to explore when I have some time.
--
___
Python tracker
<https://bugs.python.org/is
New submission from Filipe Laíns :
It would be helpful to have a pathlib-compatible object in tarfile, similarly
to zipfile.Path.
--
components: Library (Lib)
messages: 405194
nosy: FFY00, jaraco
priority: normal
severity: normal
status: open
title: Add tarinfo.Path
type: enhancement
Filipe Laíns added the comment:
Okay, I think that makes sense to me. Thank you!!
--
___
Python tracker
<https://bugs.python.org/issue45591>
___
___
Python-bug
Filipe Laíns added the comment:
Thank you for clarifying, that does work. This is surprising behavior to me, do
you recall what was the reasoning for this design? Or is there some discussion
you can point me to? And sorry for bothering, I know I am asking too many
questions, but I'd li
Change by Filipe Laíns :
--
pull_requests: +27483
pull_request: https://github.com/python/cpython/pull/29220
___
Python tracker
<https://bugs.python.org/issue45
Filipe Laíns added the comment:
s/if we can chdir/if we can't chdir/
--
___
Python tracker
<https://bugs.python.org/issue45545>
___
___
Python-bugs-list m
Filipe Laíns added the comment:
Alternatively, can't we just os.chdir(self._old_cwd) in __enter__ and
preemptively fail? IMO it's probably better to just straight up fail if we can
chdir back to the original directory than to have relatively fragile recov
Filipe Laíns added the comment:
Ah, this was not obvious to me! I did not specify a path, but as it defaults to
`sys.path` and `namespace.a` is available there, I was expecting it to find it.
One of the things that threw me off was the first arguments being called
`fullname`, which I assumed
New submission from Filipe Laíns :
NamespaceLoader currently does not implement create_module or exec_module,
which is problematic since load_module is deprecated.
The create_module docstring is the same as _LoaderBasics:
```
def create_module(self, spec):
"""Use defaul
New submission from Filipe Laíns :
```
$ tree namespace
namespace/
└── a.py
0 directories, 1 file
```
```
$ ./python
Python 3.9.7 (default, Oct 10 2021, 15:13:22)
[GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more informat
Filipe Laíns added the comment:
I opened up a new PR that should fix this properly. The root issue was that
PathFinder was not setting the loader attribute for namespace packages in the
spec, which it should. After fixing that, _find_module just needed to be
updated to deal with
Change by Filipe Laíns :
--
pull_requests: +27465
pull_request: https://github.com/python/cpython/pull/29196
___
Python tracker
<https://bugs.python.org/issue40
Filipe Laíns added the comment:
I can help out, but would like to wait until we get a resolution in GH-25718 as
it will likely conflict.
--
___
Python tracker
<https://bugs.python.org/issue11
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue40899>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue45364>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue45272>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue45020>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue22789>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue1353344>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue11602>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
pull_requests: +27464
pull_request: https://github.com/python/cpython/pull/29194
___
Python tracker
<https://bugs.python.org/issue45
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue33439>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
pull_requests: +27461
pull_request: https://github.com/python/cpython/pull/29190
___
Python tracker
<https://bugs.python.org/issue45
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue45582>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
pull_requests: +27460
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/29189
___
Python tracker
<https://bugs.python.org/issu
Filipe Laíns added the comment:
FROZEN_EXCLUDED is set when frozen modules have no code associated with them,
and the _freeze_module tool doesn't seem to be able to produce such output.
We could remove it and replace it with an assert, but that does not give us
much benefit, so we s
Change by Filipe Laíns :
--
keywords: +patch
pull_requests: +27454
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/29180
___
Python tracker
<https://bugs.python.org/issu
Filipe Laíns added the comment:
I was looking at the code and it seems PyImport_ImportFrozenModuleObject does
not set an error on FROZEN_BAD_NAME, it just returns 0, is this intended? If I
pass a bogus object, it will just return 0.
This does not seem right.
Currently, FROZEN_BAD_NAME is
Change by Filipe Laíns :
--
pull_requests: +27447
pull_request: https://github.com/python/cpython/pull/29174
___
Python tracker
<https://bugs.python.org/issue45
Change by Filipe Laíns :
--
pull_requests: +27446
pull_request: https://github.com/python/cpython/pull/29173
___
Python tracker
<https://bugs.python.org/issue45
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue45545>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
title: Modenize the importlib loaders -> Modernize the importlib loaders
___
Python tracker
<https://bugs.python.org/issu
New submission from Filipe Laíns :
ResourceLoader[1] is deprecated in favor of ResourceReader, which itself is
surpassed by TraversableResources.
Would it make sense to replace ResourceLoader usages with ResourceReader in the
importlib loaders?
And perhaps, would it make sense to replace them
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue33277>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> enhancement
___
Python tracker
<https://bugs.python
Change by Filipe Laíns :
--
nosy: +eric.smith
___
Python tracker
<https://bugs.python.org/issue45520>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
keywords: +patch
pull_requests: +27318
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/29047
___
Python tracker
<https://bugs.python.org/issu
Change by Filipe Laíns :
--
keywords: +patch
pull_requests: +27317
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/29046
___
Python tracker
<https://bugs.python.org/issu
Change by Filipe Laíns :
--
pull_requests: +27316
pull_request: https://github.com/python/cpython/pull/29045
___
Python tracker
<https://bugs.python.org/issue45
Filipe Laíns added the comment:
Actually, since TraversableResources is simply implementing ResourceReader, the
protocol is documented. We could reference ResourceReader in the docstring
though.
--
___
Python tracker
<https://bugs.python.
Change by Filipe Laíns :
--
keywords: +patch
pull_requests: +27310
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/29039
___
Python tracker
<https://bugs.python.org/issu
Change by Filipe Laíns :
--
assignee: docs@python
components: Documentation
nosy: FFY00, docs@python
priority: normal
severity: normal
status: open
title: Add protocol description to the Traversable and TraversableResources
documentation
___
Python
Change by Filipe Laíns :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue44210>
___
___
Pyth
Change by Filipe Laíns :
--
nosy: +dstufft, ncoghlan, pradyunsg
___
Python tracker
<https://bugs.python.org/issue45131>
___
___
Python-bugs-list mailing list
Unsub
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue42174>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> enhancement
versions: +Python 3.11
___
Python tracker
<https://bugs.python
Filipe Laíns added the comment:
*realize I did *not* point this out
:facepalm: sorry!
--
___
Python tracker
<https://bugs.python.org/issue45427>
___
___
Pytho
Filipe Laíns added the comment:
Just to clarify, as I realize I did point this out in my reply,
Traversable[1][2] is the protocol that objects returned by
importlib.resources.files implement.
[1] https://docs.python.org/3/library/importlib.html#importlib.abc.Traversable
[2]
https
Filipe Laíns added the comment:
The Traversable protocol does not guarantee you access to the file-system path.
pathlib.Path happens to give you that information, but other traversables are
not required to.
The main reasoning for this is that traversables do not need to exist on the
file
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue45486>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue45379>
___
___
Python-bugs-list mailing list
Unsubscribe:
Filipe Laíns added the comment:
Just to clarify: some type checkers will still allow using them as type hints
in Python versions before 3.9, but `from __future__ import annotations` needs
to be used so that we don't error out at ruu
New submission from Filipe Laíns :
Since 3.9, the types in collections.abc are subscriptable and can be used as
type hints, but this is not documented.
We should write something similar to what's on the typing module documentation
for the deprecated types.
--
assignee: docs@p
Filipe Laíns added the comment:
Yes, we could have several schemes, but I think having only one is more
sensible.
The implementation would be fairly easy. We would just copy the "nt" scheme if
on Windows, otherwise "posix_prefix".
--
__
New submission from Filipe Laíns :
Python 3.10 introduced sysconfig._get_preferred_schemes[1], a mechanism to
allow downstream distributors to overwrite the default install scheme.
This is done to support downstream modifications where distributors change the
installation layout (eg. different
Change by Filipe Laíns :
--
title: Add install scheme for virtual environment -> Add install scheme for
virtual environments
___
Python tracker
<https://bugs.python.org/issu
Filipe Laíns added the comment:
The fix that was merged seems a bit hacky to me -- it changes the _is_gcc check
so that it returns True on clang.
Even though distutils is deprecated and no longer synced externally, if someone
needs to issue a similar fix, this might trip them over.
I would
Filipe Laíns added the comment:
> Without disagreeing with the general sentiment, just note that you can always
> do Ctrl-D.
That is true, but there are a couple setups where that doesn't work (those
keypresses are consumed by something else). I may not be a good data po
Filipe Laíns added the comment:
> In my view, that's exactly why it _shouldn't_ have a special treatment. After
> all, site can add many more builtins. Do you want all of them to have
> autocall?
No, and I did not suggest anything of the sort. I just want the exit becau
Filipe Laíns added the comment:
One technical argument on why it would be beneficial to have custom handling
like this for exit is that exit is a site-builtin, not a builtin.
$ python -S
Python 3.9.7 (default, Aug 31 2021, 13:28:12)
[GCC 11.1.0] on linux
>>> exit()
Traceback (most re
Change by Filipe Laíns :
--
nosy: +FFY00
nosy_count: 8.0 -> 9.0
pull_requests: +26830
pull_request: https://github.com/python/cpython/pull/28271
___
Python tracker
<https://bugs.python.org/issu
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue40080>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
pull_requests: +26691
pull_request: https://github.com/python/cpython/pull/28271
___
Python tracker
<https://bugs.python.org/issue25
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue45127>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue45078>
___
___
Python-bugs-list mailing list
Unsubscribe:
Filipe Laíns added the comment:
Matthias, can you check if bpo-44982 solves your issues related to the
conflicts you were experiencing for the Debian patching?
If so, it would unblock this issue.
I am probably gonna discuss this proposal with the conda-forge folks next week,
to get some
Filipe Laíns added the comment:
> I am unsure if having two different interpreters is a good solution, and it
> certainly requires some cooperation with distros.
That is not the goal with this!
I think both this issue and the PEP are parallel. My goal here is to streamline
the
New submission from Filipe Laíns :
In the effort of making the UX better with vendored Python versions, I think it
would make sense to track and expose vendor information.
Initially, the vendor information would be comprised of two fields, the vendor
string (eg. `Debian`) and the vendor name
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue44981>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
keywords: +patch
pull_requests: +26244
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27769
___
Python tracker
<https://bugs.python.org/issu
Filipe Laíns added the comment:
Hi Jason, thank you.
I already tried 1), but could not convince Matthias on an alternative way to
achieve the result that Debian wants. If you want, maybe you and I could try
restarting those discussions.
2) is fine, but I am not the one that will me
Filipe Laíns added the comment:
distutils will install the headers to
{base}/include/python{py_version_short}{abiflags}/{dist_name}, and I think
probably the best option would be to do the same. So, I think we could add a
site-include scheme like I described and have the installers append a
Filipe Laíns added the comment:
Yes, but in the process of deprecating disutils, some internals were changed to
stop relying on it. This will cause a lot of downstream patches to break.
I you are not modifying CPython, you don't need to worry, but if you are, then
you should have a loo
Filipe Laíns added the comment:
s/still/stay/
--
___
Python tracker
<https://bugs.python.org/issue43976>
___
___
Python-bugs-list mailing list
Unsubscribe:
Filipe Laíns added the comment:
I find it very difficult. I would be a bit anxious merging the code this close
to the final release, so I imagine the release managers would be much more.
Anyway, this is the current state of this issue from my perspective:
As far as I understand, progress is
New submission from Filipe Laíns :
There are select use-cases where hash randomization is undesirable, having a
CLI option to switch it off would be very helpful.
One example would be packaging, where hash randomization will make the bytecode
unreproducible.
Currently, we have to set
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue42839>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue35673>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
nosy: +FFY00
nosy_count: 5.0 -> 6.0
pull_requests: +26013
pull_request: https://github.com/python/cpython/pull/27484
___
Python tracker
<https://bugs.python.org/issu
Change by Filipe Laíns :
--
pull_requests: +26000
pull_request: https://github.com/python/cpython/pull/27484
___
Python tracker
<https://bugs.python.org/issue44
Change by Filipe Laíns :
--
nosy: +FFY00
___
Python tracker
<https://bugs.python.org/issue44777>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Filipe Laíns :
--
pull_requests: +25886
pull_request: https://github.com/python/cpython/pull/27344
___
Python tracker
<https://bugs.python.org/issue44
Change by Filipe Laíns :
--
pull_requests: +25881
pull_request: https://github.com/python/cpython/pull/27338
___
Python tracker
<https://bugs.python.org/issue44
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
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
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
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
1 - 100 of 249 matches
Mail list logo