On Mon, Jan 25, 2021, at 18:44, Chris Jerdonek wrote:
> But to issue a warning when a standard module is being overridden like
> I was suggesting, wouldn’t you also need to know whether the name of
> the module being imported is a standard name, which is what
> says.module_names provides?
I don
On Mon, Jan 25, 2021 at 2:05 PM Victor Stinner wrote:
> On Mon, Jan 25, 2021 at 6:37 PM Chris Jerdonek
> wrote:
> > On Mon, Jan 25, 2021 at 7:51 AM Ivan Pozdeev via Python-Dev <
> python-dev@python.org> wrote:
> >>
> >> Just _names_? There's a recurring error case when a 3rd-party module
> overr
On Mon, Jan 25, 2021 at 06:17:09PM +0100, Victor Stinner wrote:
> Hi Bernat,
>
> "stdlib_module_names" was my first idea but it looks too long, so I
> chose "module_names". But someone on Twitter and now you asked me why
> not "stdlib_module_names", so I wrote a PR to rename module_names to
> sys.
Fortunately for, you :) , all this argument is not against the feature per se but only against its use to blindly filter module lists for
automated bug reports.
On 26.01.2021 1:34, Victor Stinner wrote:
On Mon, Jan 25, 2021 at 11:22 PM Ivan Pozdeev via Python-Dev
wrote:
That's not possible.
On Mon, Jan 25, 2021 at 11:22 PM Ivan Pozdeev via Python-Dev
wrote:
> That's not possible.
>
> Stdlib can be arranged any way a user/maintainer wishes (zipped stdlib and
> virtual environments are just two examples), so there's no way to tell if the
> module's location is "right".
> Dowstream ch
That's not possible.
Stdlib can be arranged any way a user/maintainer wishes (zipped stdlib and virtual environments are just two examples), so there's no way to
tell if the module's location is "right".
Dowstream changes are also standard practice so there's no way to verify a
module's conten
On Mon, Jan 25, 2021 at 6:37 PM Chris Jerdonek wrote:
> On Mon, Jan 25, 2021 at 7:51 AM Ivan Pozdeev via Python-Dev
> wrote:
>>
>> Just _names_? There's a recurring error case when a 3rd-party module
>> overrides a standard one if it happens to have the same name. If you
>> filter such a module
On Mon, Jan 25, 2021 at 6:39 PM Ethan Furman wrote:
> > For packages, only sub-packages are listed, not sub-modules. For
> > example, ``concurrent`` package and ``concurrent.futures``
> > sub-package are listed, but not ``concurrent.futures.base``
> > sub-module.
>
> I'm not sure I
On 1/25/21 5:03 AM, Victor Stinner wrote:
I just added a new sys.module_names attribute, list (technically a
frozenset) of all stdlib module names
The list is opinionated and defined by its documentation
For packages, only sub-packages are listed, not sub-modules. For
example, ``co
On Mon, Jan 25, 2021 at 7:51 AM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:
> Just _names_? There's a recurring error case when a 3rd-party module
> overrides a standard one if it happens to have the same name. If you
> filter such a module out, you're shooting yourself in the foot
Hi Bernat,
"stdlib_module_names" was my first idea but it looks too long, so I
chose "module_names". But someone on Twitter and now you asked me why
not "stdlib_module_names", so I wrote a PR to rename module_names to
sys.stdlib_module_names:
https://github.com/python/cpython/pull/24332
At least
Hello,
In general, I love the idea and implementation. I'm not in love with the
name though, it makes it sound like it contains all module names
imported/available. We have sys.module already containing all module
imported. So without a deeper knowledge sys.modules_names is very close to
sys.modul
Hi Ivan,
On Mon, Jan 25, 2021 at 4:53 PM Ivan Pozdeev via Python-Dev
wrote:
> Just _names_? There's a recurring error case when a 3rd-party module
> overrides a standard one if it happens to have the same name. If you
> filter such a module out, you're shooting yourself in the foot...
Overridin
On Mon, Jan 25, 2021 at 06:46:51PM +0300, Ivan Pozdeev via Python-Dev wrote:
> There's a recurring error case when a 3rd-party module
> overrides a standard one if it happens to have the same name.
Any argument and expectation is off in this case. We shouldn't worry about such
scenarios.
--
Senth
Just _names_? There's a recurring error case when a 3rd-party module overrides a standard one if it happens to have the same name. If you
filter such a module out, you're shooting yourself in the foot...
On 25.01.2021 16:03, Victor Stinner wrote:
Hi,
I just added a new sys.module_names attribu
On Mon, Jan 25, 2021 at 4:18 PM Antoine Pitrou wrote:
>
> On Mon, 25 Jan 2021 14:03:22 +0100
> Victor Stinner wrote:
> >
> > The list is opinionated and defined by its documentation:
>
> So "the list is opinionated" means there can be false negatives, i.e.
> some stdlib modules which are not pres
Sounds good to me. Have you talked to Nick?
On Mon, Jan 25, 2021 at 07:07 Mark Shannon wrote:
> Hi,
>
> PEP 558 seems to be dormant, if not abandoned.
>
> There are at least two open issues for bugs resulting from the currently
> weird and inefficient behavior of `f_locals` and `locals()`.
> See
On Mon, 25 Jan 2021 14:03:22 +0100
Victor Stinner wrote:
>
> The list is opinionated and defined by its documentation:
So "the list is opinionated" means there can be false negatives, i.e.
some stdlib modules which are not present in this list?
This will probably make life harder for third-part
Hi,
PEP 558 seems to be dormant, if not abandoned.
There are at least two open issues for bugs resulting from the currently
weird and inefficient behavior of `f_locals` and `locals()`.
See https://bugs.python.org/issue30744 for an example of undesirable
behaviour.
PEP 588, or something like
Hi,
I just added a new sys.module_names attribute, list (technically a
frozenset) of all stdlib module names:
https://bugs.python.org/issue42955
There are multiple use cases:
* Group stdlib imports when reformatting a Python file,
* Exclude stdlib imports when computing dependencies.
* Exclude s
On Mon, Jan 25, 2021 at 1:30 AM Terry Reedy wrote:
> The Python Software Foundation currently has a shortfall of funds rather
> than a surplus.
I believe Mark's proposal suggested raising money specifically for the
project, not spending general PSF funds.
_
21 matches
Mail list logo
