[Python-Dev] Do we still need a support of non-type objects in issubclass()?

2020-10-03 Thread Serhiy Storchaka 
issubclass() accept types (extension types and new-style classes),
classic classes and arbitrary objects with the __bases__ attribute as
its arguments. The latter was added in issue464992 [1] to support the
Zope extension ExtensionClass.

I tested the current code of ExtensionClass [2], and seems it does not
need that special support. Tests are passed on modified master which
uses tp_bases instead of dynamical look up of __bases__,
ExtensionClass.ExtensionClass is a subclass of type and
ExtensionClass.Base is an instance of type, the code does not have the
__bases__ property and does not set the __bases__ attribute explicitly.

On other hand, the code in the Python core has a non-zero maintenance
cost. It was rewritten several times for 19 years, there is a gigantic
comment larger that the current code explaining it (and it is slightly
outdated), and there was several bugs related to it [3] [4].

Should we continue to support non-type objects with __bases__ in
issubclass()? If no, can we remove their support in 3.10 (it would fix a
crash in issue41909) or after passing a deprecation period?

[1] https://bugs.python.org/issue464992
[2] https://github.com/zopefoundation/ExtensionClass
[3] https://bugs.python.org/issue39382
[4] https://bugs.python.org/issue41909
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/2S2FM2J44H2FQTZZOC7MINFVMZMQKCOP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Do we still need a support of non-type objects in issubclass()?

2020-10-03 Thread Steven D'Aprano 
On Sat, Oct 03, 2020 at 11:41:16AM +0300, Serhiy Storchaka wrote:
> issubclass() accept types (extension types and new-style classes),
> classic classes and arbitrary objects with the __bases__ attribute as
> its arguments.

I didn't think classic classes were still possible in Python 3. How do 
you get them?


-- 
Steve
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/RQZMNNXXVQJIETT7HALTUYVOF52HJY5P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Do we still need a support of non-type objects in issubclass()?

2020-10-03 Thread Serhiy Storchaka 
03.10.20 12:45, Steven D'Aprano пише:
> On Sat, Oct 03, 2020 at 11:41:16AM +0300, Serhiy Storchaka wrote:
>> issubclass() accept types (extension types and new-style classes),
>> classic classes and arbitrary objects with the __bases__ attribute as
>> its arguments.
> 
> I didn't think classic classes were still possible in Python 3. How do 
> you get them?

They were originally in Python 2.2.2 code when the support of objects
with the __bases__ attribute was added. In Python 3 there are no classic
classes, but some code was written to support them.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/LWQTXQUGHTDCD7PU2RVW3VOQFOPSBEHP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Where it is decided whether "lib" or "lib64" ends up in sys.path on a POSIX (non MacOS) system?

2020-10-03 Thread Mikhail Golubev via Python-Dev 
Hi everyone!

First of all, sorry for bringing up, perhaps, a trivial matter, but since it's 
about the sources I guess it's better to ask it here.

I'm investigating a curious problem caused by the fact that in a user's 
virtualenv, created with the standard "venv" module, "lib64" directory, 
traditionally symlinked to "lib", gets included in sys.path
instead of "lib" itself.

```
$ python -msite

sys.path = [
'/current/working/directory'
'/usr/lib64/python36.zip',
'/usr/lib64/python3.6',
'/usr/lib64/python3.6/lib-dynload',
'/path/to/venv/lib64/python3.6/site-packages',
]
```

The user is on Gentoo, and, though the venv's layout is exactly the same, it's 
different from the typical result on a Debian-based distribution where it's the 
original "lib" in sys.path, not its "lib64" link. I'm wondering what's 
controlling this behavior. Modules/getpath.c doesn't mention 
architecture-dependent lib directories anywhere, at least at first glance. 
Could someone please give me a hint about where to look in the sources or, 
maybe, which build options are affecting this?

Thanks a lot!
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/5T72JDQG7D44CFYN7URPB5I5JATMD6AR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Do we still need a support of non-type objects in issubclass()?

2020-10-03 Thread Guido van Rossum 
Is this the only place where a non-class object with __bases__ is accepted?
Or do we have more such? I recall that long ago you could use certain
non-class objects as base classes.

I think all that hackery may predate (and may even have been an inspiration
for features of) new-style classes.

—Guido

On Sat, Oct 3, 2020 at 03:12 Serhiy Storchaka  wrote:

> 03.10.20 12:45, Steven D'Aprano пише:
>
> > On Sat, Oct 03, 2020 at 11:41:16AM +0300, Serhiy Storchaka wrote:
>
> >> issubclass() accept types (extension types and new-style classes),
>
> >> classic classes and arbitrary objects with the __bases__ attribute as
>
> >> its arguments.
>
> >
>
> > I didn't think classic classes were still possible in Python 3. How do
>
> > you get them?
>
>
>
> They were originally in Python 2.2.2 code when the support of objects
>
> with the __bases__ attribute was added. In Python 3 there are no classic
>
> classes, but some code was written to support them.
>
> ___
>
> Python-Dev mailing list -- [email protected]
>
> To unsubscribe send an email to [email protected]
>
> https://mail.python.org/mailman3/lists/python-dev.python.org/
>
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/LWQTXQUGHTDCD7PU2RVW3VOQFOPSBEHP/
>
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
--Guido (mobile)
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/EAGYV55LGYU3GBSDNXQF6RDPUSPQKNBE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Do we still need a support of non-type objects in issubclass()?

2020-10-03 Thread Serhiy Storchaka 
03.10.20 18:15, Guido van Rossum пише:
> Is this the only place where a non-class object with __bases__ is
> accepted? Or do we have more such? I recall that long ago you could use
> certain non-class objects as base classes.

The only other place is object.__dir__(). It recursively iterates the
__class__.__bases__ chain, and __class__ can be a non-type object.

The code of object.__dir__() is very old, it predates new-style classes,
and currently it gathers names using different algorithm than used in
object.__getattr__(), so object.__dir__() does not always return a list
of names accepted by object.__getattr__().

> I think all that hackery may predate (and may even have been an
> inspiration for features of) new-style classes.

I wonder whether it should pass with Python 2.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/GRSFMWDHH55KN4KZSDXSJLKWWYDF2FKE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Do we still need a support of non-type objects in issubclass()?

2020-10-03 Thread Guido van Rossum 
On Sat, Oct 3, 2020 at 9:28 AM Serhiy Storchaka  wrote:

> 03.10.20 18:15, Guido van Rossum пише:
> > Is this the only place where a non-class object with __bases__ is
> > accepted? Or do we have more such? I recall that long ago you could use
> > certain non-class objects as base classes.
>
> The only other place is object.__dir__(). It recursively iterates the
> __class__.__bases__ chain, and __class__ can be a non-type object.
>
> The code of object.__dir__() is very old, it predates new-style classes,
> and currently it gathers names using different algorithm than used in
> object.__getattr__(), so object.__dir__() does not always return a list
> of names accepted by object.__getattr__().
>

Would anything break if we changed `dir()` to use `__mro__` instead of
`__bases__`? It would probably be simpler.


> > I think all that hackery may predate (and may even have been an
> > inspiration for features of) new-style classes.
>
> I wonder whether it should pass with Python 2.
>

I suppose you meant "pass" as in "die". I agree.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/2PYPN5NM2A2Q75YPB5TD5OCDT2L4ZZG6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Where it is decided whether "lib" or "lib64" ends up in sys.path on a POSIX (non MacOS) system?

2020-10-03 Thread Nick Coghlan 
The sysconfig & site modules cover the addition of non-stdlib directories
to sys.path, but be aware that many Linux distros patch that logic to
better align with the conventions of that particular distro.

So your discrepancy is likely coming from either build process differences
between the Debian & Gentoo packages, or else patches in one distro but not
the other have actually altered the behaviour.

Cheers,
Nick.

On Sun., 4 Oct. 2020, 12:41 am Mikhail Golubev via Python-Dev, <
[email protected]> wrote:

> Hi everyone!
>
> First of all, sorry for bringing up, perhaps, a trivial matter, but since
> it's about the sources I guess it's better to ask it here.
>
> I'm investigating a curious problem caused by the fact that in a user's
> virtualenv, created with the standard "venv" module, "lib64" directory,
> traditionally symlinked to "lib", gets included in sys.path
> instead of "lib" itself.
>
> ```
> $ python -msite
>
> sys.path = [
> '/current/working/directory'
> '/usr/lib64/python36.zip',
> '/usr/lib64/python3.6',
> '/usr/lib64/python3.6/lib-dynload',
> '/path/to/venv/lib64/python3.6/site-packages',
> ]
> ```
>
> The user is on Gentoo, and, though the venv's layout is exactly the same,
> it's different from the typical result on a Debian-based distribution where
> it's the original "lib" in sys.path, not its "lib64" link. I'm wondering
> what's controlling this behavior. Modules/getpath.c doesn't mention
> architecture-dependent lib directories anywhere, at least at first glance.
> Could someone please give me a hint about where to look in the sources or,
> maybe, which build options are affecting this?
>
> Thanks a lot!
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/5T72JDQG7D44CFYN7URPB5I5JATMD6AR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/YVTWU2XGJYCNFSCO6E3XQISJGY3YM24D/
Code of Conduct: http://python.org/psf/codeofconduct/