I see a bunch of similar -- but not quite the same -- use cases.
I feel like instead of a set, it should be a dict pointing to an object with
attributes that describe the module in various ways (top-level vs subpackage,
installed on this machine or not, test module or not, etc). I'll
I probably wouldn't think of that on my own, but the need is rare enough that
having the recipe in the documentation (preferably including the docstring)
might be enough. (Or it might not.)
___
Python-Dev mailing list -- python-dev@python.org
To
On Wed, Jan 27, 2021 at 1:16 AM Steven D'Aprano wrote:
> Right. This is (I think) Steve's point: the list is inaccurate, because
> the existence of 'winsound' in the stdlib_module_names doesn't mean that
> the module 'winsound' exists.
This point is addressed by the definition of the list:
Hi Steven,
That makes sense to me: I wrote
https://github.com/python/cpython/pull/24353 to exclude sub-package.
The change removes 12 sub-packages from sys.stdlib_module_names and
len(sys.stdlib_module_names) becomes 300 :-)
-"concurrent.futures",
-"ctypes.macholib",
-"distutils.command",
On Wed, Jan 27, 2021 at 10:44:00AM +0100, Antoine Pitrou wrote:
> Ok, then "stdlib_package_names"? :-)
Heh :-)
I see your smiley, and I'm not going to argue about the name any
further. I have my preference, but if the consensus is
stdlib_module_names, so be it.
But I think the inconsistency
On Wed, 27 Jan 2021 11:05:28 +1100
Steven D'Aprano wrote:
> On Tue, Jan 26, 2021 at 12:08:03PM -0800, Brett Cannon wrote:
> > On Tue, Jan 26, 2021 at 1:26 AM Antoine Pitrou wrote:
>
> [...]
> > > Disagreed. This is niche enough that it warrants a long but explicit
> > > name, rather than
On Tue, Jan 26, 2021 at 10:56:57AM +0100, Victor Stinner wrote:
> On Tue, Jan 26, 2021 at 12:44 AM Steven D'Aprano wrote:
[...]
> > Your first instinct that it is too long is correct. Just call it
> > "stdlib" or "stdlib_names". The fact that it is a frozen set of module
> > names will be
On Tue, Jan 26, 2021 at 11:19:13PM +0100, Victor Stinner wrote:
> On Tue, Jan 26, 2021 at 10:04 PM Steve Dower wrote:
> >
> > On 1/26/2021 8:32 PM, Steve Holden wrote:
> > > If the length of the name is any kind of issue, since the stdlib
> > > only contains modules (and packages), why not just
On Tue, Jan 26, 2021 at 12:08:03PM -0800, Brett Cannon wrote:
> On Tue, Jan 26, 2021 at 1:26 AM Antoine Pitrou wrote:
[...]
> > Disagreed. This is niche enough that it warrants a long but explicit
> > name, rather than some ambiguous shortcut.
> >
>
> I agree w/ Antoine that a more descriptive
On Mon, Jan 25, 2021 at 10:23 PM Random832 wrote:
> 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
On Tue, Jan 26, 2021 at 10:04 PM Steve Dower wrote:
>
> On 1/26/2021 8:32 PM, Steve Holden wrote:
> > If the length of the name is any kind of issue, since the stdlib
> > only contains modules (and packages), why not just sys.stdlib_names?
>
> And since the modules can vary between platforms and
On 1/26/2021 8:32 PM, Steve Holden wrote:
If the length of the name is any kind of issue, since the stdlib
only contains modules (and packages), why not just sys.stdlib_names?
And since the modules can vary between platforms and builds, why
wouldn't this be sysconfig.stdlib_names rather than
If the length of the name is any kind of issue, since the stdlib
only contains modules (and packages), why not just sys.stdlib_names?
On Mon, Jan 25, 2021 at 5:18 PM Victor Stinner wrote:
> Hi Bernat,
>
> "stdlib_module_names" was my first idea but it looks too long, so I
> chose
On Tue, Jan 26, 2021 at 1:26 AM Antoine Pitrou wrote:
> On Tue, 26 Jan 2021 10:36:10 +1100
> Steven D'Aprano wrote:
> > 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
On Tue, Jan 26, 2021 at 12:44 AM Steven D'Aprano wrote:
>
> 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
On Mon, 25 Jan 2021 23:05:07 +0100
Victor Stinner wrote:
>
> This is a different use case which requires a different solution.
> sys.module_names solve some specific use cases (that I listed in my
> first email).
>
> In Python 3.9, you can already check if a module __file__ is in the
>
On Tue, 26 Jan 2021 10:36:10 +1100
Steven D'Aprano wrote:
> 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
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
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
>
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
>
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
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
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
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
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,
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
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
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...
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.
--
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
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
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
34 matches
Mail list logo
